저자: ArcBlock 창업자 겸 CEO Robert Mao

이 글은 누구나 자유롭게 전재·공유할 수 있도록 허가되었습니다. 이 업계 자구의 호소를 더 많은 사람이 보게 되기를 바랍니다.

크립토는 이대로 계속될 수 없습니다. 거듭된 대규모 탈취로 빼앗긴 것은 자산만이 아니라 참여자들이 이 업계 전체에 품는 신뢰입니다. 우리가 스스로를 구해야 합니다.

2026년 10월 29일, 바이낸스에서 중대한 보안 사고가 발생했습니다. 바이낸스의 초기 공지는 약 63억 달러 규모의 자산이 영향을 받은 것으로 추정되며, 영향받은 자산 중 약 30억 달러가 이미 동결되었다고 밝혔습니다. 조사는 처음에는 DevOps 엔지니어의 노트북을 가리켰으나, 이후 다른 침해 가능 지점도 발견되었습니다. 바이낸스는 동시에 지갑 개인키 유출의 증거는 아직 발견되지 않았다고 밝혔습니다. 영향을 받은 금액은 최종 순손실이 아니며, 전체 공격 사슬은 여전히 조사 중입니다.[[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)

이 제안은 Ethereum, Solana 등 블록체인 프로젝트의 빌더들에게, 그리고 Binance, Coinbase, Kraken은 물론 참여할 의사가 있는 모든 거래소·지갑·프로토콜·보안 빌더들에게 보냅니다: 함께 자산을 보호하는 기반을 다시 세웁시다. 저는 참여하고자 하며, 더 많은 이들이 함께 행동하기를 바랍니다.

이미 충분히 무겁습니다. 하지만 제가 더 걱정하는 것은 이번 사건이 또 얼마나 많은 사람의 크립토에 대한 신뢰를 꺾어놓을지, 그리고 얼마나 많은 공격자에게 이 업계를 계속 노려볼 만한 표적으로 보이게 할지입니다. 설령 나중에 누군가 손실을 부담한다 해도, 배상이 사용자의 신뢰를 자동으로 회복시켜 주지는 않으며, 같은 종류의 파괴가 멈추게 하지도 못합니다.

바이낸스는 오늘 우리가 문제를 마주하지 않을 수 없게 만든 계기일 뿐입니다. 시선을 돌리면 거래소, 브리지, 온체인 프로토콜, 지갑에는 이미 긴 상처 목록이 남아 있습니다. 새로운 네트워크와 제품이 계속 등장하지만, 오래된 고장 패턴은 반복해서 재현됩니다. 우리는 공지 하나를 내고 한동안 기다린 뒤 다음 사고마저 일상으로 받아들일 수는 없습니다.

우리는 또한 사기와, 개념만 만들어내고 건설의 책임은 지지 않는 방식이 이 업계를 너무 오래 해쳐 왔다는 점을 인정해야 합니다. 기술과 인프라를 진지하게 만드는 팀들도 신뢰 상실의 결과를 함께 떠안고 있습니다. 사람들이 크립토 전체를 사기로 보게 되면, 정말로 지킬 가치가 있는 기술과 탐구까지 함께 포기될 수 있습니다.

ArcBlock의 founder로서, 또 크립토와 블록체인 업계 종사자로서 저는 이런 결말을 받아들이고 싶지 않습니다. 저는 이 업계에 지킬 가치가 있다고 믿으며, 우리가 우리 자신의 보안 기반에 책임을 져야 한다고 생각합니다. 다음 사고를 소극적으로 기다리기만 한다면, 거듭된 출혈이 결국 우리가 함께 세운 모든 것을 무너뜨릴 수 있습니다.

그래서 이 제안을 내놓고자 합니다: 거래소, 지갑, 블록체인의 빌더들이 함께 자산 통제와 보안 검증의 기반을 다시 세우고, 한 번의 침해가 만들어내는 파괴 범위를 제약해야 합니다. 아래의 연대기는 왜 바뀌어야 하는지를 보여주고, 뒤에 이어지는 기술 방안은 제가 시작할 수 있다고 보는 작업입니다.

이 사고 연대기는 이미 너무 길다

2008년, 사토시 나카모토는 신뢰할 수 있는 중개자에 대한 의존을 줄이려는 점대점 전자화폐 시스템을 제안했습니다.[[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) 그러나 이후의 중대한 사고들은 자금과 권한, 소프트웨어 의존이 다시 집중되는 문제를 끊임없이 드러냈습니다.

아래는 중앙화 거래소(CEX), 탈중앙화 거래소(DEX), 브리지, 지갑 등 분야의 대표적 사건을 시간순으로 정리한 것입니다. 완전한 사고 데이터베이스도, 연도별 손실 통계도 아닙니다. 금액이 제시된 경우 사고 당시의 대략적인 총 영향액을 뜻하며, 도난·동결·이후 회수는 각각 따로 설명되므로 이를 합산해 영구 손실로 삼을 수는 없습니다.

2008 · Bitcoin 백서

기점
Bitcoin 백서는 금융기관의 중개가 필요 없는 점대점 결제를 제안했습니다.
출처

2011–2014 · Mt. Gox 장기 도난

CEX
Mt. Gox는 장기간 도난을 겪다 결국 영업을 중단했습니다. 미국 법무부의 이후 기소는 2011–2014년 사이 약 64만 7,000 BTC가 도난당했다고 주장합니다. 이는 2014년 하루에 일어난 단일 공격이 아닙니다.
출처

2012 · Bitcoinica와 Bitfloor

CEX／커스터디 인프라
Bitcoinica의 Linode 호스팅 환경이 뚫렸고, 같은 해 Bitfloor의 암호화되지 않은 지갑 백업이 공격 진입점이 되었습니다. 플랫폼 뒤의 서버와 백업도 자산 보안의 경계입니다.
출처

2015 · Bitstamp 핫월렛

CEX
Bitstamp 핫월렛이 침해당한 뒤 운영 환경을 재구축했습니다. 회사는 사고 범위를 오프라인 준비금과 구분해 설명하며, 격리가 노출 범위를 제한할 수 있음을 보여주었습니다.
출처

2016 · Bitfinex

CEX
Bitfinex에서 약 12만 BTC가 도난당했습니다. 다중서명 구성이라도 여전히 엔드투엔드 독립 권한 부여와 검증이 필요합니다.
출처 1 · 출처 2

2016 · The DAO

온체인 프로토콜
The DAO 컨트랙트가 재진입 공격을 받아 약 360만 ETH가 자식 DAO로 이동했고, 이후 Ethereum 포크를 촉발했습니다. 합법적인 실행 경로가 파국적인 비즈니스 결과를 낳을 수 있습니다.
출처 1 · 출처 2

2017 · Parity 공유 지갑 라이브러리

컨트랙트 지갑
Parity 공유 지갑 라이브러리가 파괴되어 약 51만 3,000 ETH가 동결되었습니다. 이체되지는 않았지만 공통 코드 의존 때문에 사용 능력을 잃을 수도 있습니다.
출처

2018 · Coincheck

CEX
Coincheck의 NEM 핫월렛이 도난당했습니다. 오프라인 준비금, 핫월렛 권한, 업무 요구 사이의 경계가 다시 문제로 드러났습니다.
출처

2019 · Binance

CEX
바이낸스는 7,000 BTC가 한 건의 거래로 인출되었다고 공지했습니다. 대규모 자산 유출은 서명 이전 단계에서 제약되어야 합니다.
출처

2020 · KuCoin

CEX
KuCoin 핫월렛 사고로, 이후 다자 협력을 통해 대량의 자산이 회수되었습니다. 총 도난액과 최종 손실은 같은 숫자가 아닙니다.
출처

2021 · Poly Network

크로스체인 프로토콜
Poly Network의 약 6억 1,200만 달러 상당 자산이 이체되었다가 이후 순차적으로 반환되었습니다. 크로스체인 권한 부여와 자산 통제는 정상 업무 경로만으로 성립해서는 안 됩니다.
출처

2022 · Ronin 브리지

브리지
Ronin의 검증자 권한이 뚫려 173,600 ETH와 2,550만 USDC가 이체되었습니다. 여러 검증자의 키도 동일한 공격 사슬에 들어갈 수 있습니다.
출처

2022 · Slope 지갑

지갑
Solana 생태계의 Slope 지갑 사건입니다. Solana 측은 개인키 정보가 실수로 애플리케이션 모니터링 서비스로 전송된 것이며, Solana의 합의가 뚫린 것은 아니라고 밝혔습니다.
출처

2023 · Euler

대출 프로토콜
Euler의 약 1억 9,700만 달러 상당 자산이 프로토콜 취약점으로 이체되었다가 이후 회수되었습니다. 단일 거래의 복잡한 조합이 비즈니스 로직 결함을 증폭시킬 수 있습니다.
출처

2023 · Ledger Connect Kit

지갑 연결 도구
Ledger Connect Kit가 공급망 공격을 받아 악성 코드가 애플리케이션 프런트엔드로 유입되었습니다. 하드웨어 기기의 보안이 거래 내용 검증을 대체할 수 없습니다.
출처

2024 · DMM Bitcoin

CEX
DMM Bitcoin의 약 3억 800만 달러가 도난당했습니다. FBI 등 기관은 이후 관련 인원과 서명 경로를 겨냥한 사회공학 공격을 공개했습니다.
출처

2024 · Radiant Capital

대출 프로토콜／서명
Radiant Capital의 약 5,000만 달러가 도난당했고 여러 개발자 기기가 침해되었습니다. 다수가 서명하더라도 오염된 거래 정보에 함께 의존할 수 있습니다.
출처

2025 · Bybit／Safe

CEX／지갑 프런트엔드
Bybit의 약 15억 달러 사고로, 공격은 Safe 개발자 환경과 프런트엔드에 관련되었으며 서명자들은 지갑 통제 로직을 바꾸는 거래를 승인했습니다.
출처 1 · 출처 2

2025 · Cetus DEX

DEX
Sui 기반 Cetus의 약 2억 2,300만 달러 사고로, 연구자들은 수학 라이브러리 결함을 지적했습니다. 비 EVM 환경 역시 코드와 자산 노출 범위를 검증해야 합니다.
출처

2026-07 · COLDCARD 난수 결함

하드웨어 지갑 / 시드 생성
펌웨어 결함이 시드 생성을 약화시켜, 공격자는 기기가 오프라인인 상태에서도 관련 개인키를 재구성할 수 있었습니다. 업그레이드로는 이미 생성된 취약 시드를 고칠 수 없으며 공지에 따라 이전해야 합니다.
출처

2026-10 · Ledger 하드웨어 이식

하드웨어 지갑 / 유통 공격
Ledger는 정품 기기가 개조되어 동남아 유통 채널을 통해 흘러나왔고, 이식된 부품이 초기화 시점에 복구 단어를 탈취했다고 확인했습니다. 제조사는 칩과 운영체제, 서버는 뚫리지 않았다고 밝혔습니다.
출처

2026 · Binance 멀티체인 사고

CEX／멀티체인
바이낸스는 약 63억 달러 규모의 자산이 영향을 받은 것으로 초기 추정했고, 다른 침해 가능 지점에 대한 조사는 계속 진행 중입니다. 단일 운영 체계는 여러 네트워크의 자산을 동시에 노출시킬 수 있습니다.
출처 1 · 출처 2 · 출처 3

여기에는 CEX도 있고 탈중앙화 거래소, 대출 프로토콜, 브리지도 있습니다. 자산이 도난당한 사례도, 동결된 사례도 있습니다. 공격은 서로 다른 계층에서 일어나고, 고치는 방법도 다릅니다. 저는 이 모든 것을 "사용자가 개인키를 잘 보관하지 못했다"는 한마디로 환원하는 데 반대합니다. 어떤 도구의 개발 환경이나 어떤 공유 라이브러리, 혹은 이해할 수 없는 한 건의 권한 승인이 자신의 전 자산으로 통하는 입구가 된다는 사실을 사용자가 어떻게 알 수 있겠습니까?

분산 네트워크는 이미 많은 일을 해냈지만, 자산 통제의 장애 격리는 여전히 턱없이 부족합니다. 온체인 실행이 한 건의 거래를 충실히 완료했다는 사실이, 그 거래가 왜 이렇게 많은 것을 옮길 권한이 있는지를 대신 답해주지는 않습니다.

서로 다른 기술 노선이 함께 보안 기반을 세우도록

Ethereum의 기여는 큽니다. 더 많은 사람이 온체인 애플리케이션을 작성할 수 있게 했고, 풍부한 도구와 개발 경험을 만들어냈습니다. 그러나 오늘날 많은 신규 체인과 L2(2차 확장 네트워크)가 EVM 호환을 최우선 목표로 삼고 있습니다. Ethereum 스마트 컨트랙트를 실행하는 가상 머신인 EVM은 널리 복제되는 기술적 전제가 되어가고 있습니다. 호환은 분명히 애플리케이션 이전을 편하게 해줍니다. Unichain 등 프로젝트의 문서는 Ethereum 도구를 재사용하는 동등한 실행 환경의 가치를 명확히 내세우고 있습니다.[[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)

EVM 호환을 업계의 기본 답으로 삼는 것이 구조적인 위험 집중을 만들어내고 있다고 저는 봅니다. 네트워크 이름은 여러 개일 수 있고 검증자도 다를 수 있지만, 개발자는 같은 컨트랙트를 거듭 배포하고 같은 권한 부여 관행을 쓰며 같은 소프트웨어 라이브러리에 의존할 수 있습니다. 공통 의존 속의 오류는 다른 체에 배포했다고 해서 사라지지 않습니다. 이는 기술 노선에 대한 판단이며, 모든 EVM 구현이 반드시 같은 취약점을 갖는다는 말은 아닙니다.

제가 Ethereum을 비판하는 지점도 여기입니다. 범용 컨트랙트 실행 능력이 전이 가능한 자산에 직접 연결되어, 막대한 책임을 애플리케이션 코드와 지갑 상호작용에 넘깁니다. 컨트랙트는 컨트랙트를 호출할 수 있고, 권한 승인은 오래 남을 수 있으며, 평범해 보이는 한 번의 확인이 이후의 계정 통제 방식을 바꿀 수 있습니다. 보안은 갈수록 모든 개발팀이 이런 조합을 올바로 이해하고, 모든 사용자가 자신이 무엇에 서명했는지 올바로 이해하는 데 의존하게 됩니다.

EIP-7702는 이 문제를 아주 선명하게 보여줍니다. 일반 이체는 "이번에 누구에게 얼마를 보내는가"이고, 위임 승인은 "앞으로 이 코드가 내 계정을 대신해 작업을 실행하게 한다"일 수 있습니다. 사용성 개선과 권한 세분화라는 목표가 있지만, 위임을 설정하는 것 자체가 광범위한 실행 권한을 부여하며, 세분화된 권한은 위임 코드가 올바로 구현해야 합니다.[[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) Minfeng Qi 등의 프리프린트 《EIP-7702 Phishing Attack》은 이런 승인에 서명하도록 유도한 뒤 계정을 지속적으로 통제하는 경로를 연구했습니다.[[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) 편의가 늘어날 때 보안 책임도 함께 늘어나며, 앞의 것만 사용자에게 넘길 수는 없습니다.

이번 바이낸스 사고는 여러 체에 걸쳐 있고 조사도 끝나지 않았으므로, 전체 영향을 EIP-7702나 EVM에 직접 귀속시킬 수 없습니다. 재진입, 서명 서비스 침해, 프런트엔드 변조도 같은 취약점이 아닙니다. 그러나 이런 구분이 아키텍처에 대한 질문을 멈추는 변명이 되어서는 안 됩니다: 왜 하위 계층은 상위 계층의 오류에 대비해 쉽게 우회되지 않는 제약을 더 남겨두지 않았는가?

MEV 역시 저를 불편하게 합니다. MEV는 참여자가 거래의 포함·배제·순서 배열을 이용해 추가 가치를 얻는 공간을 뜻합니다. 제게 순서권을 이용해 사용자 거래를 끼워 넣어(샌드위치) 체결 결과를 악화시키는 일은 고쳐야 할 버그로 다뤄져야 하며, 누군가 돈을 벌 수 있다는 이유로 지킬 가치가 있는 기능으로 포장되어서는 안 됩니다. Ethereum 자체 문서도 샌드위치 공격이 사용자에게 주는 피해와 MEV가 네트워크 안정성에 주는 위험을 명확히 인정합니다.[[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV는 Ethereum 고유의 것이 아니고 차익거래와 청산 등 다른 활동도 포함하며, 업계에는 이미 완화 연구가 있습니다. 제 비판은 네트워크를 유지하는 인센티브가 사용자의 거래 조건을 희생하는 이유가 될 수 없다는 것입니다. 더 나은 거래 체계는 최소 체결 결과와 허용 수수료를 권한 승인에 적어 넣고, 순서 배열자가 미체결 정보로 사용자에게 피해를 주는 공간을 제한해야 합니다.

저는 늘 Ethereum이 크립토에 미친 영향이 PHP가 인터넷에 미친 영향과 조금 닮았다고 느껴 왔습니다. 많은 사람이 무언가를 만들어낼 수 있게 했지만, 오래 갚아야 할 엔지니어링 부채도 남겼습니다. PHP는 2026년 10월에도 여전히 심각한 원격 코드 실행 취약점을 고쳐야 했습니다. 성숙과 보편화는 지속적인 강화를 대신할 수 없습니다.[[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) 인터넷의 소중한 점은 언어와 프레임워크, 클라우드 서비스가 각각 진화할 수 있다는 것입니다. 우리도 서로 다른 자산 모델과 실행 방식이 계속 발전하도록 허용해야 하며, "같은 가상 머신과 호환되는 것"을 생태계에 참여하는 입장권으로 삼아서는 안 됩니다.

따라서 저는 Bitcoin, Solana, Ripple／XRP Ledger 생태계, 그리고 ArcBlock을 포함한 빌더들이 공동의 보안 기반 건설에 진지하게 참여할 것을 촉구합니다. 표준과 상호운용에 참여하기 위해 먼저 자신을 Ethereum으로 바꿀 필요는 없습니다. 다양성은 자산 통제와 검증 방식에서 실현되어야 하고, 공개적인 검증을 받아야 합니다. Slope와 Cetus 사고는 비 EVM 환경에도 안전 면제가 없다는 것을 이미 일깨워 주었습니다.

제가 만들고자 하는 것은 서로 다른 실행 환경이 모두 채택할 수 있는 보안 규범입니다. 동일한 자산 제한과 검증 요건을 EVM과 다른 노선이 각각 구현하고, 각자의 보장과 비용을 공개적으로 검증하는 것입니다.

시작할 수 있는 일곱 가지 강화 작업

1. 하위 계층의 리스크 통제가 자산 처분권을 제약하도록

대액 지갑은 수취 화이트리스트, 누적 지출 상한, 신규 수취인에 대한 대기 기간을 설정할 수 있어야 합니다. 핵심은 이런 규칙을 일상 거래 키 하나로 즉시 해제할 수 없어야 한다는 점입니다. 규칙을 바꾸려면 독립적인 권한 부여가 필요하고, 모니터링과 철회를 위한 시간도 확보되어야 합니다.

기존 스마트 계정에는 이미 구현 기반이 있습니다. 예컨대 Safe Guards는 다중서명 외에 거래 제한을 추가할 수 있습니다.[[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) 우리는 이것을 더 쉽게 도입되고 모든 자산 통제 경로를 커버하는 기본 역량으로 만들어야 합니다. 직접 이체만 제한하면서 무한 승인이나 모듈, 업그레이드를 통한 우회를 허용하면 보호는 허사가 됩니다. 화이트리스트 컨트랙트를 업그레이드할 수 있는지, 수취인 권한에 변화가 있는지도 검증 범위에 들어와야 합니다.

Apple의 Activation Lock은 일상에서 얻을 수 있는 시사점을 줍니다. 도난 기기의 재활성화를 제한하고 일부 도난 부품의 보정을 제한하는 것으로, 목적은 훔친 뒤 활용할 수 있는 가치를 낮추는 것입니다.[[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) 지갑도 이 방향으로 설계할 가치가 있습니다. 공격자가 키 하나를 얻어도 현금화할 수 있는 자산 범위가 여전히 제한적이라면 공격의 기대 수익은 낮아질 수 있습니다. 서비스 파괴 같은 위험은 여전히 별도로 다뤄야 합니다.

이것이 제가 말하는 자산 보안의 "헌법"입니다: 운영 권한은 침해될 수 있어도 경계를 수정하는 권한은 여전히 독립적으로 유지되어야 합니다. 복구 절차 역시 제약을 받아야 하며, 한 번의 잘못된 설정이 자산을 영구히 잠그는 일을 막아야 합니다.

2. 지갑이 니모닉만 넘기는 것이 아니라 보안 책임을 지도록

오늘날의 지갑 체계에 저는 강한 불만이 있습니다. 어떤 제품이 일반인에게 단어 목록을 받아 적게 하고, 평생 유출하지도 잃어버리지도 속지 말라고 요구한 다음, 이후의 모든 실패를 사용자 책임으로 돌린다면 저는 그것이 무책임한 설계라고 생각합니다. 자기 보관은 사람에게 통제권을 주어야 하고, 동시에 실제로 쓸 수 있는 보호와 복구 능력도 주어야 합니다. 모든 사용자가 먼저 보안 전문가가 되기를 요구해서는 안 됩니다. 이것 또한 크립토가 더 많은 일반 사용자에게 다가가기 위해 반드시 넘어야 할 문턱입니다.

최근의 사고는 이 문제를 아주 직접적으로 드러냈습니다. Ledger는 2026년 10월, 공격자가 정품 기기를 개조해 동남아 유통 채널을 통해 다시 시장에 내보냈고, 이식된 부품이 초기화 시점에 복구 단어를 탈취했다고 확인했습니다. Ledger는 이를 기기 출하 이후의 국소적 유통 공격으로 규정했으며, 칩이나 운영체제, 서버가 뚫린 것은 아니라고 했습니다.[[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) COLDCARD의 7월 사고는 펌웨어가 시드 생성을 약화시킨 사례로, 기기가 원격으로 제어되지 않아도 공격자가 관련 개인키를 재구성할 수 있었습니다. 펌웨어 업데이트가 고치는 것은 앞으로의 생성 과정이며, 이미 생성된 취약 시드는 여전히 이전해야 합니다.[[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)

두 사고는 같은 종류의 취약점은 아니지만 함께 이렇게 말해줍니다: 사용자가 단어를 정성껏 적고 기기를 오프라인으로 보관하더라도, 난수와 완전한 공급망을 제조사를 대신해 검증할 수는 없습니다. 기기에 백업 단어를 표시하는 것은 오프라인 복구라는 용도가 있지만, 동시에 완전한 복구 비밀을 보호가 필요한 표시·백업 경로에 통과시키는 일이기도 합니다. 칩 보안이 기기 전체와 전달 과정에 대한 검증을 대체할 수 없습니다.

개선의 목표는 완전한 지갑 생애주기여야 합니다. 키가 어떻게 생성되고, 거래가 어떻게 설명되며, 권한이 어떻게 분리되고, 기기를 잃었을 때 어떻게 복구되는가. 계정이 프로그래머블 규칙으로 권한 부여를 검증하도록 허용하는 계정 추상화와 SLIP-39 같은 임계 백업에는 이미 표준과 구현 기반이 있습니다. 업계에 아무도 하지 않는 일이라고 말할 수는 없습니다.[[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) 그러나 우리는 이런 역량을 검증을 거치고 쓰기 쉬운 보호로 만들어야 하며, 사용자가 복잡한 방안을 스스로 조립하게 해서는 안 됩니다.

니모닉의 단순한 난독화로는 부족합니다. 더 신뢰할 만한 방향은 감사를 거친 암호화 백업, 임계 복구, 독립 기기 권한 부여이며, 사용자가 대액 자산을 예치하기 전에 복구 리허설을 마치게 하는 것입니다. 백업 샤드와 다중서명은 서로 다른 계층입니다. 전자는 복구 시점에 같은 비밀을 다시 조합할 수 있고, 후자는 여러 독립 서명자가 거래를 승인하도록 요구합니다. 복구 서비스가 슬며시 새로운 마스터 키가 되어서도 안 되고, 추가 비밀번호가 또 하나의 "잃으면 복구 불가" 함정이 되어서도 안 됩니다.

개인 지갑과 거래소의 지갑 시스템은 거래 설명, 서명 요청, 자산 제한, 복구 절차에 대한 보안 규범을 공유하되 서로 다른 한도와 승인 정책을 쓸 수 있습니다. Bitcoin의 PSBT는 이미 도구 간에 서명 대기 거래를 전달하는 형식을 제공했으며, 이런 공통 인터페이스는 계속 발전시킬 가치가 있습니다.[[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) 공통인 것은 검사 가능한 보안 요건이고, 각 체인은 여전히 자신의 적응 규칙을 명확히 해야 합니다. 지갑은 이번 서명으로 무엇이 이전되고 누구에게 얼마만큼의 후속 권한이 부여되는지 분명히 제시해야 하며, 독립 정책이 경계를 넘는 작업을 거부해야 합니다. 더 예쁜 확인 페이지로는 충분하지 않습니다.

3. 최소 필요 공개로 검증 가능하게 하기

어떤 조건이 성립함을 증명할 때 항상 사용자에게 모든 기초 데이터를 공개하도록 요구해서는 안 됩니다. 선택적 공개, 영지식 증명, 필요할 때 부여되는 감사 접근은 인프라의 정상적인 선택지가 되어야 합니다. 이는 자산 안전과도 연결됩니다. 공개된 신원과 자산 관계는 표적형 기만의 단서가 될 수 있고, 업무에 필요 없는 데이터는 가능한 한 적게 노출해야 합니다.

W3C의 검증 가능한 자격 증명 체계에는 이미 선택적 공개를 위한 기술 경로가 있습니다. 다만 증명 입력의 진실성, 자격 증명의 유효성, 상태를 어떻게 폐기하는지는 여전히 명확히 해야 합니다.[[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) 영지식 증명(ZK)을 도입한다고 해서 거래 금액과 관계가 자동으로 숨겨지는 것도 아닙니다. 확장 증명과 프라이버시 보호는 서로 다른 목표입니다.

예를 들어 어떤 업무가 참여 자격의 확인만 필요하다면, 사용자는 신뢰할 수 있는 기관이 발급한 유효한 자격 결론을 제시하고 전체 재무 자료는 공개하지 않을 수 있습니다. 숨겨진 값이 조건을 만족함을 증명해야 할 때는 그에 맞는 증명 메커니즘을 사용합니다. 자격 증명의 신뢰 출처와 폐기 상태는 여전히 검증해야 합니다.

제 제안은 "누가 무엇을 검증해야 하는가"를 먼저 분명히 하고, 그다음에 반드시 공개해야 하는 데이터를 설계하자는 것입니다. 자격을 확인하는 사람은 자격 결론만 필요할 수 있고, 특정 감사 책임을 진 사람은 제한된 증거를 받을 수 있습니다. 공개적으로 검증 가능한 제약이되, 모든 사람에게 영구히 노출되는 개인정보는 최소화해야 합니다.

4. 거래 서비스를 가능한 한 중앙 커스터디에서 떼어내기

거래 매칭, 경로 탐색, 자산 결제 완료는 분리해서 설계해야 합니다. 거래 진입점을 제공하는 서비스는 가능한 한 현재 결제에 필요한 권한만 얻어야 하고, 나머지 시간 동안 사용자 자산은 각자의 통제 아래 남아야 합니다. 기존의 거래 의도 기반 프로토콜이 이미 일부 경로를 탐구했으며, 업계는 이를 완성해 나갈 수 있습니다.[[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)

사용자가 동의해야 하는 것은 명확한 결제 조건입니다. 무엇을 지급하고, 최소한 무엇을 받고, 언제 효력이 만료되며, 허용되는 수수료는 얼마인지. 거래 서비스가 뚫린 뒤 공격자는 서비스 거부를 할 수는 있어도 이런 조건을 마음대로 바꿀 수는 없어야 합니다. 여전히 중앙 커스터디가 필요한 업무라면 준비금과 운영 권한을 분리하고, 핫월렛 노출과 자동 보충 한도를 제한해야 합니다.

IBIT는 iShares의 비트코인 상장지수상품으로, 시장에서 거래되는 것은 그 지분입니다. 그 구조는 국소적 격리의 한 예를 보여줍니다. 지분과 기초 Bitcoin은 따로 기록되고, Vault Balance(커스터디 잔액)의 관련 개인키는 콜드 스토리지에 둡니다. 지분 거래 기록이 바뀐다고 해서 기초 Bitcoin이 매 건 따라 이동할 필요는 없습니다.[[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) 참고할 것은 거래권과 준비금 처분권의 분리입니다. 그 Trading Balance(거래 서비스 잔액)는 다른 구조를 갖고 있고 커스터디 자체에도 위험이 있습니다. 콜드 스토리지는 반드시 독립된 지시와 서명 검증과 결합되어야 합니다.

제가 거래 진입점을 라우터(router)에 비유하는 것은, 그것이 교체 가능하고 전체 사용자 자산의 마스터 스위치를 지니지 않기를 바라기 때문입니다. 결제는 패킷 전달보다 복잡하며, 자산 인도와 권한 부여는 여전히 독립적으로 검증되어야 합니다. 서비스를 비수탁으로 만들어 놓고 다시 무한 출금 권한을 부여하면 중앙화 위험을 되불러올 뿐입니다.

5. 계층형 아키텍처로 장애를 격리하고 교체 능력을 지키기

우리에게는 독립적으로 진화할 수 있는 신원·권한 인터페이스, 자산 정책, 결제 검증 방식이 필요합니다. 서로 다른 체인은 자신의 실행 모델을 유지하면서 명확한 인터페이스로 연결될 수 있습니다. 인터페이스가 설명해야 하는 것은 보안 보장과 그 조건이며, "호출 성공"만 말해서는 안 됩니다.

인터넷의 경험은 이런 사고를 뒷받침합니다. Mark Nottingham은 RFC 9518 《Centralization, Decentralization, and Internet Standards》에서 중앙화가 도움이 될 수 있는 경우를 따로 다루고, 그것이 낳는 권력과 위험도 분석했습니다.[[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) 이것이 참고할 만한 태도입니다. 아키텍처가 어떤 책임을 중앙화할 수 있고 어느 정도까지 중앙화하며, 그 권력의 확장을 어떻게 막을지 답하게 하는 것. 한 서비스가 이상 징후를 중앙에서 식별하되 자산에 접촉하는 권한은 제한할 수 있고, 사용자는 자신의 자산 정책과 검증 기록을 잃지 않고 서비스를 교체할 수 있어야 합니다.

가장 중요한 수용 기준 질문은 이것입니다. 업무 서비스가 뚫린 뒤 어떤 독립 계층이 여전히 그것을 거부할 수 있는가? 모든 계층이 하나의 관리 키를 공유한다면, 이른바 계층 분리는 배포도 위의 그림에 불과합니다.

이 목표를 다섯 계층의 책임으로 볼 수 있습니다. 거래 서비스가 요청을 제출하고, 지갑이 사용자 의도를 표현하고, 독립 정책이 자산 처분권을 제한하고, 검증 컴포넌트가 작업과 증거를 확인하고, 결제 계층이 제약을 강제하고 검증 가능한 기록을 제공합니다. 이들은 서로 다른 팀이 구현할 수 있고, 의존성과 침해 조건도 각각 설명해야 합니다.

이 글에서 제안하는 목표 아키텍처. 결제 계층은 반드시 자산 정책을 강제해야 하며, 지갑 안의 안내 문구가 이 제약을 대신할 수 없습니다. 일상 서명, 규칙 변경, 복구 권한은 분리되어야 하고 우회 테스트를 받아야 합니다.

6. 사용자가 자기 자산을 가볍게 검증할 수 있도록

일반인이 자기 잔액과 입금을 검증하기 위해 체인 전체의 모든 이력을 저장하고 실행해야 해서는 안 되며, 지갑 뒤의 서버 하나만 믿어야 해서도 안 됩니다. 사토시 나카모토는 백서 8절에서 이미 SPV, 즉 간이 지불 검증을 제시했습니다. Bitcoin의 BIP-157은 클라이언트가 필터를 내려받아 자신과 관련된 블록을 찾는 방향을 계속 탐구했고, Ethereum에도 라이트 클라이언트 설계가 있습니다.[[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) 그러므로 문제는 아무도 생각해보지 않았다는 것이 아니라, 명확한 보안 조건을 갖춘 검증 능력을 사용자가 매일 쓰는 지갑에 넣어야 한다는 것입니다.

계정 상태 증명을 지원하는 체인을 예로 들면, 잔액을 조회할 때 서버는 잔액과 함께 증명을 반환해야 합니다. 지갑은 먼저 해당 체인의 규칙에 따라 짧은 블록 요약, 즉 블록 헤더를 검증한 다음, 이 잔액이 그 요약이 약속한 데이터와 일치하는지 확인합니다. 서버가 답을 제공하고 지갑이 그 답을 검증하는 것입니다. Bitcoin의 SPV는 관련 거래가 포함되었다는 증거를 검증하는 방식이라, 이 잔액 증명을 그대로 옮겨 올 수는 없습니다. 지갑은 또한 어디까지 동기화되었고 어떤 정보가 검증되었는지 분명히 표시해야 하며, 증명이 없거나 데이터가 오래되었거나 출처가 모순될 때는 경고하거나 그 정보에 의존하는 고위험 작업을 중단해야 하고, 조용히 맹목적 신뢰로 되돌아가서는 안 됩니다.

가벼운 검증에도 조건이 있습니다. 한 거래가 블록에 포함되었음을 증명하는 것이 그 블록의 모든 거래가 합법임을 직접 확인한 것과 같지는 않습니다. 방식에 따라 다수 해시파워의 정직성이나 신뢰할 수 있는 초기 기록, 즉 체크포인트에 의존할 수 있고, 서버가 데이터를 은폐하거나 사용자를 낡은 체인 기록에 고립시키는 일도 막아야 합니다. 조회 자체가 사용자가 관심 있는 주소를 노출하는지도 다뤄야 합니다. 풀 노드와 블록 생산자는 같은 역할이 아니며, 오늘날 Ethereum의 블록 생산은 채굴자가 아니라 검증자를 사용합니다.

더 중요한 것은, "온체인에서 실제로 이 이체가 일어났다"는 증명이 "이것이 바로 사용자가 원한 이체"임을 증명하지는 않는다는 점입니다. 라이트 클라이언트는 앞서 말한 자산 제한과 서명 검증을 대체할 수 없습니다. 라이트 클라이언트는 사용자가 검증할 수 없는 답변에 덜 의존하게 만들고, 자산 정책은 유효한 서명 하나로도 자산을 무한히 처분할 수 없게 만듭니다. 두 계층을 함께 세워야 검증 능력이 참여자들의 손에 분산됩니다.

7. 이상 탐지와 보안 검증을 공공 기반으로 만들기

거래 전에 누군가는 이 작업이 자산 정책에 맞는지, 이력상 갑작스러운 행동 변화가 있는지 점검해야 합니다. 명백한 이상은 일시 중지나 추가 심사를 촉발할 수 있고, 권한 확대는 또 다른 독립 경로를 필요로 합니다. AI가 판단에 참여할 수는 있지만 하드 규칙을 넘어서는 통행권을 얻어서는 안 됩니다.

동시에 우리는 공격 사례와 권한 테스트, 반복 실행 가능한 검증 도구를 함께 유지해야 합니다. 규범을 공유하고 구현과 검증을 독립적으로 유지해야 공통 고장을 줄일 수 있습니다. 재단과 거래소는 이미 보안에 투자하고 있습니다. 예컨대 Ethereum Foundation의 Trillion Dollar Security Initiative가 있습니다.[[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) 다음 질문은 그 투자가 다른 팀도 채택하고 검사할 수 있는 공공 기반으로 전환될 수 있는가입니다.

이 일곱 가지 작업은 절대적인 안전을 보장하지 못합니다. 이들이 전달해야 하는 것은 검사 가능한 경계입니다. 어떤 권한 침해 조건에서 자산이 최대 얼마나 노출되고, 이상이 얼마나 빨리 발견되며, 복구가 여전히 누구에게 의존하는가.

AI가 강화한 소프트웨어 엔지니어링: 우리의 A New Hope

여기까지 읽고 누군가는 이렇게 말할 수 있습니다. 방향은 다 맞는 것 같은데, 업계가 이미 이렇게 오래 걸어왔고 재구축에는 얼마나 많은 사람과 시간이 필요한가? 이건 결국 이상주의가 아닌가?

여전히 과거의 소프트웨어 생산 방식으로 추산한다면 이 의문은 매우 현실적입니다. 하지만 2026년에 이르러 저는 코딩 에이전트와 AI가 강화한 소프트웨어 엔지니어링이 우리가 동원할 수 있는 건설 능력을 이미 바꾸어 놓았다고 생각합니다. 여기서 코딩 에이전트란 개발 환경에서 코드를 읽고 쓰며, 도구를 호출하고, 테스트를 실행하고, 피드백에 따라 계속 작업할 수 있는 AI 프로그래밍 어시스턴트를 말합니다. 빌더는 목표를 제시하고 보안 경계를 정하며, 이 도구들로 시스템을 구현하고 검사하고, 결과에 책임을 집니다.

과거에는 큰 팀이 반복해서 구현하고 적응시키고 유지해야 했던 작업을, 이제 작은 팀이 이런 새로운 엔지니어링 방식으로 시도할 수 있습니다. 한 팀이 한 계층을 맡아 명확한 인터페이스를 중심으로 컴포넌트를 전달하고, 다른 팀이 그것을 검사하고 조합합니다. 사람의 아키텍처 판단, 코딩 에이전트의 구현 능력, 독립적인 보안 검증을 함께 조직하는 것이 제가 진지하게 재평가할 가치가 있다고 보는 건설 경로입니다.

Anthropic과 PNNL의 연구는 구체적인 사례를 제공합니다. 제한된 핵심 인프라 시뮬레이션 환경에서 연구자들은 공격 재구성에 수 주가 걸릴 수 있던 것이 약 3시간으로 단축되었다고 보고했습니다.[[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) 이것이 작은 팀이 이미 업계 전체를 안전하게 다시 쓸 수 있음을 증명하지는 않지만, 과거에 비쌌던 검증과 공방 작업에 새로운 비용 조건이 나타날 수 있음을 보여줍니다.

지금 시작할 수 있는 조직 방식 하나는 Build in Public 방식의 AI Factory를 함께 만드는 것입니다. 업계 전문가와 학자, 종사자가 요구사항과 수용 기준(spec)을 공개적으로 작성해 무엇을 보호하고 어떤 작업을 허용하며 어떤 권한이 침해된 뒤에도 어떤 경계를 지켜야 하는지 밝히고, 이 요구사항을 수용 테스트로 옮깁니다. 코딩 에이전트 그룹이 주요 코딩과 테스트, 오류 탐색을 맡고, 서로 다른 팀이 설계와 결과를 검사하며, 사람이 판단과 수용의 책임을 집니다.

참여자는 아이디어와 기기, 컴퓨팅 파워, 그리고 모델 호출 한도 즉 AI 토큰을 기여할 수 있습니다. AI와 클라우드 기업도 모델 크레딧과 컴퓨팅 자원, 도구 지원으로 이 공공 건설을 지원할 수 있습니다. Spec과 프로토타입 코드, 에이전트 워크플로, 테스트 환경, 검증 결과가 공동으로 유지되는 기반이 되어 다음 팀이 곧바로 이어서 작업할 수 있습니다. 목표는 개발 능력을 재사용 가능한 공공 시설로 만들어, 특정 개인의 시간이나 특정 팀에 대한 의존을 줄이는 것입니다.

공격자도 AI를 쓰고 있으므로, 우리가 방어를 과거의 생산 방식에 남겨둘 이유는 이미 없습니다.[[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) 다만 코드가 빨리 생성되는 것은 출발점일 뿐입니다. 제약을 분명히 쓰고, 테스트를 반복 실행할 수 있게 하고, 하나의 컴포넌트를 검사하고 교체할 수 있게 만드는 것이 AI의 능력을 인프라 개선으로 바꿔 놓습니다.

독립적인 빌더들이 코딩 에이전트와 AI 도구로 함께 작업합니다. 우주 작업장은 공공 건설의 은유입니다.

저는 특히 여전히 무언가를 만들기를 사랑하는 사람들에게 이 호소를 전하고 싶습니다. 여기서 해커란 시스템이 어떻게 작동하는지 알아내기를 좋아하고, 발견한 것을 기꺼이 공유하며, 다른 사람이 자기 작품을 검증하기를 기꺼이 허락하는 사람입니다. 그런 정신이 인터넷을 이끌어 왔고, 오늘날 크립토도 이끌 수 있습니다.

저는 이 업계에 똑똑한 사람이 부족하다고 믿지 않고, 크립토와 AI 업계가 이 작업을 뒷받침할 자원을 찾지 못한다고도 믿지 않습니다. 더 어려운 것은 인재와 자금, 지속적인 책임을 하나로 조직하는 일입니다. 재단과 역량 있는 기업은 직접 수익을 내지는 않지만 모든 사람에게 이득이 되는 기반 작업에 장기적인 비용을 부담하려는 의지를 보여야 합니다.

저는 모두가 힘을 모아 세계가 함께 공유하는 암호 인프라를 만들어내기를 바랍니다. 서로 다른 네트워크와 팀이 공통의 보안 제약 아래 협업하고, 각자 구현하고 서로 검증하며, 사용자는 선택하고 이전할 수 있습니다. 컴포넌트 하나에서 시작할 수 있지만 방향은 충분히 커서 업계 전체가 함께 건설할 수 있어야 합니다. ArcBlock을 포함한 참여자 모두가 검증 가능한 기여를 내놓아야 합니다.

우리는 함께 이런 인프라를 세워야 합니다. 어딘가가 이미 침해되었더라도 자산에는 경계가 남아 있고, 다른 시스템은 여전히 오류를 거부할 수 있으며, 사용자에게는 여전히 복구하고 떠날 수 있는 경로가 있는 인프라입니다. 《스타워즈》의 제목을 빌리자면, 이것이 우리의 A New Hope입니다.[[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) 희망은 행동하기를 원하는 평범한 빌더들에게서, 그리고 코딩 에이전트와 새로운 엔지니어링 방식이 그들에게 더 많은 건설 작업을 맡길 수 있게 된 이 순간에서 옵니다.

지금 행동에 나섭시다

저는 Ethereum, Solana, Bitcoin, XRP Ledger 등 프로젝트의 빌더들에게, Binance, Coinbase, Kraken 등 거래소에, 그리고 지갑·프로토콜·보안 연구·AI·클라우드 팀에 초대를 보냅니다: 범위가 분명한 하나의 파일럿에서 시작해, 다른 팀도 채택하고 검증할 수 있는 개선을 함께 만들어냅시다.

열거된 이름은 예시일 뿐이며 선후를 뜻하지 않습니다. 규모나 어떤 기술 노선을 택했는지와 무관하게 참여를 환영합니다. 이 초대에는 이 글에서 비판한 기술 노선의 빌더도 포함됩니다. 자산 안전을 함께 개선하는 일은 각자의 생태계 경계를 넘어설 가치가 있습니다.

저 자신도 참여해 우리가 가진 기반 아키텍처와 소프트웨어 엔지니어링, AI 협업 실천을 기여할 의향이 있습니다. 우리는 업계의 작은 팀이며 할 수 있는 일이 제한적이므로, 하나의 프로토타입과 한 세트의 반복 실행 가능한 테스트에서 시작하고자 합니다.

실제 운영 경험이 있는 사람은 비식별화된 공격 시나리오를 제공하고, 지갑과 프로토콜 팀은 보호를 구현하며, 독립 연구자는 그것을 우회하려 시도할 수 있습니다. 각 팀이 감당할 수 있는 부분을 맡고, 함께 방안을 검증하고 다음 단계를 결정합니다.

저는 이 글의 자산 제한과 복구 요건을 첫 번째 공개 spec으로 정리하는 일에 참여하고, 관련 기술과 엔지니어링 실천을 기여하며, 다른 참여자들과 함께 이 파일럿을 위한 공공 AI Factory를 세우고자 합니다. 먼저 아주 구체적인 문제 하나를 고릅시다. 일상 거래 키가 이미 침해되었다면, 어떻게 하면 공격자가 지갑을 한 번에 비워내지 못하게 할 수 있는가? 허용되는 손실 범위, 규칙 변경 권한, 복구 조건을 수용 테스트로 작성하고, 개발 에이전트들이 프로토타입을 구현하며, 다른 에이전트 그룹과 독립 연구자가 우회 경로를 찾게 합니다. 데이터 서버가 잘못된 잔액을 반환하는 경우나 기기 분실 후 복구도 점차 테스트에 추가할 수 있습니다. 프로토타입이 무엇을 해냈고 어디서 실패했으며 어떤 의존성이 남았는지 공개적으로 밝히고, 증거에 따라 다음 단계를 결정합니다.

참여하고자 하는 분은 X에서 이 제안을 공개적으로 공유하거나 인용하고 @mave99a를 태그해, 해결하고 싶은 문제나 비식별화된 공격 사례, 또는 기여할 수 있는 자원을 알려주시기 바랍니다. 논의가 공개적으로 진행되어 더 많은 빌더가 보고 이어서 참여하기를 바랍니다.

크립토는 이대로 계속될 수 없습니다. 함께하고자 하는 분들은 지금 행동에 나서, 실제로 만들어낼 수 있고 검증을 견디는 개선 하나에서 시작합시다.

Binance, 초기 공지 공식 게시물 및 후속 조사 공식 업데이트, 2026-10-30; TRM 멀티체인 분석. 본고의 확인은 2026-10-30 기준이며, 조사와 회수 상태는 변할 수 있습니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap, Unichain EVM Equivalence. 공통 의존의 위험 집중은 이 글 저자의 판단이며, 해당 문서의 결론이 아닙니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, 2024-05-07 작성. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, arXiv v1 프리프린트이며, 이번 바이낸스 사고의 감정 결과가 아닙니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maximal extractable value (MEV), 순서 배열 메커니즘과 여러 유형 및 부정적 영향; "버그로 고쳐야 한다"는 것은 사용자에게 피해를 주는 행위에 대한 저자의 엔지니어링 주장입니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
PHP 공식 2026 뉴스 아카이브; CISA 2026-10-26 알려진 악용 취약점 업데이트, CVE-2026-109618, CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe, Guards 및 Modules, 기능과 권한 위험 설명. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11; 현재 부품 잠금 지원 설명. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)
Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, 유통 단계 공격에 대한 제조사 설명; Joe Grand, 하드웨어 이식 리버스 엔지니어링 연구. 제조사가 확인하지 않은 네트워크 손실 추정을 확정된 사실로 쓰지 않습니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Current COLDCARD Security Status, 2026-10-30 열람, 계속 갱신되는 2026년 7월 사고와 복구 기록; 업그레이드와 시드 이전은 서로 다른 작업입니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, 임계 복구, 호환성, 추가 패스프레이즈 위험. 기존 메커니즘은 건설의 기반이며, 모든 배포가 신뢰할 만하다는 뜻은 아닙니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)
BIP-174: Partially Signed Bitcoin Transaction Format, 서명 대기 거래 교환 형식이며 크로스체인 범용 자산 정책 규범은 아닙니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Verifiable Credentials Overview v1.0, 2026-07-30 Group Note; Ethereum 프라이버시 설명. 개요가 설명하는 기술의 표준 상태는 각각 별개입니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
CoW Protocol 문서, 거래 의도와 솔버 메커니즘; 이 글은 특정 배포에 대한 전면적인 보안 보증을 제공하지 않습니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, IBIT 2025 연차 보고서, PDF 8–10쪽 커스터디 구조 및 45쪽 위험 설명. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Centralization, Decentralization, and Internet Standards, 2023-12, 독립 제출된 설명형 RFC이며 표준 트랙 규범이 아닙니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Bitcoin 백서 8절 Simplified Payment Verification; BIP-157: Client Side Block Filtering; Ethereum, Light clients. 라이트 클라이언트마다 검증 범위와 신뢰 조건이 다릅니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation, Announcing the Trillion Dollar Security Initiative, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, AI to defend critical infrastructure, 2026-01-08, PNNL과 협력한 제한 환경 연구. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Mapping AI-enabled cyber threats, 실제 악용 사례 연구. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; 이 글은 작품 제목과 공동 자구의 이미지를 빌려왔습니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)

크립토는 이대로 계속될 수 없다: 한 블록체인 업계 종사자의 업계 자구 제안서