727 Finance사건은 자산만 앗아가는 것이 아니라 신뢰도 앗아갑니다. 크립토는 이대로 계속될 수 없습니다. 우리 스스로를 구해야 합니다.
저자: Robert Mao, ArcBlock 창립자 겸 CEO
이 글은 누구나 자유롭게 복제하고 전달할 수 있도록 허가되었으며, 더 많은 사람들이 업계가 스스로를 구해야 한다는 이 호소를 보게 되기를 바랍니다.
크립토는 이렇게 계속될 수 없습니다. 거대한 도난 사건이 거듭되면서 빼앗기는 것은 자산만이 아니라 참여자들의 업계 전체에 대한 신뢰입니다. 우리는 스스로를 구해야 합니다.
2026년 10월 29일, Binance에서 중대한 보안 사고가 발생했습니다. 잠정 발표에 따르면 약 63억 달러의 자산이 영향을 받은 것으로 추정되며, 영향받은 자산 중 약 30억 달러가 동결되었습니다. 조사는 초기에 DevOps 엔지니어의 노트북을 지목했고, 이후 다른 가능한 침입 지점도 발견되었습니다. Binance는 또한 지갑 개인 키 유출의 증거를 발견하지 못했다고 밝혔습니다. 영향받은 금액은 최종 순손실이 아니며, 전체 공격 체인은 여전히 조사 중입니다. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
이 이니셔티브는 Ethereum, Solana 등 블록체인 프로젝트의 빌더들과, 그리고 Binance, Coinbase, Kraken 및 모든 거래소, 지갑, 프로토콜, 보안 빌더들 중 참여할 의향이 있는 모든 이들에게 전합니다: 우리 함께 자산 보호의 기반을 재건합시다. 저는 기꺼이 참여할 것이며, 더 많은 사람들이 함께 행동하기를 바랍니다.
이것만으로도 이미 충분히 무겁습니다. 하지만 저를 더 걱정하게 하는 것은 이 사건이 크립토에 대한 신뢰를 얼마나 파괴할지, 그리고 얼마나 많은 공격자들이 이 업계를 여전히 계속 공격할 가치가 있는 표적으로 보게 될지입니다. 누군가 결국 손실을 부담한다 해도, 보상은 사용자들의 신뢰를 자동으로 복구할 수 없으며, 같은 종류의 파괴가 다시 일어나는 것을 막을 수도 없습니다.
Binance는 오늘 우리가 문제를 직면하게 만든 진입점일 뿐입니다. 시선을 돌리면 거래소, 브리지, 온체인 프로토콜, 지갑은 오래전부터 긴 상처의 흔적을 남겨왔습니다. 새로운 네트워크와 제품이 계속 등장하지만, 오래된 실패 방식은 거듭 반복됩니다. 우리는 공지 하나 내고, 잠시 기다린 뒤, 다음 사건을 일상적인 일로 처리할 수 없습니다.
우리는 또한 사기와, 책임 있는 구축 없이 개념만 만드는 관행이 이 업계를 너무 오랫동안 해쳐왔음을 인정해야 합니다. 기술과 인프라를 진지하게 구축하는 팀들도 신뢰 상실의 결과를 함께 부담해야 합니다. 사람들이 크립토 전체를 사기로 보게 될 때, 진정으로 보존할 가치가 있는 기술과 탐구도 함께 버려질 수 있습니다.
ArcBlock의 창립자이자 크립토와 블록체인의 실천가로서, 저는 그러한 결과를 받아들이고 싶지 않습니다. 저는 이 업계에 보호할 가치가 있다고 믿으며, 우리가 우리 자신의 보안 기반에 책임을 져야 한다고 믿습니다. 만약 우리가 계속 수동적으로 다음 사건을 기다린다면, 반복되는 출혈은 결국 우리가 함께 구축한 모든 것을 파괴할 수 있습니다.그래서 저는 이 이니셔티브를 발표하고자 합니다: 거래소, 지갑, 블록체인 구축자들이 자산 통제와 보안 검증의 기반을 공동으로 재구축하여 단일 침입으로 인한 피해 범위가 제한되도록 해야 합니다. 아래의 타임라인은 왜 변화가 필요한지를 설명하며, 뒤따르는 기술 제안은 우리가 시작할 수 있다고 믿는 작업입니다.
2008년, 사토시 나카모토는 신뢰할 수 있는 중개자에 대한 의존도를 낮추는 것을 목표로 하는 P2P 전자 화폐 시스템을 제안했습니다. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) 그러나 그 이후의 주요 사건들은 자금, 권한 부여, 소프트웨어 의존성이 다시 집중되는 문제를 반복적으로 드러냈습니다.
아래는 중앙화 거래소(CEX), 탈중앙화 거래소(DEX), 브리지, 지갑 등의 영역에서 발생한 대표적인 사건들의 연대순 목록입니다. 이는 완전한 사건 데이터베이스도 아니고 연도별 손실 통계도 아닙니다. 금액이 기재된 경우, 이는 사건 발생 당시의 대략적인 총 영향을 의미하며, 도난, 동결, 이후의 회수는 별도로 설명되며 영구적 손실로 합산될 수 없습니다.
2008 · 비트코인 백서
출발점
비트코인 백서는 금융 기관을 중개자로 두지 않는 P2P 결제를 제안했습니다.
출처
2011–2014 · Mt. Gox 장기 도난
CEX
Mt. Gox는 장기적인 도난을 겪었고 결국 운영을 중단했습니다. 이후 미국 법무부 기소장에서는 2011년에서 2014년 사이에 약 647,000 BTC가 도난당했다고 주장했습니다. 이는 2014년의 단일 일일 공격이 아니었습니다.
출처
2012 · Bitcoinica와 Bitfloor
CEX / 수탁 인프라
Bitcoinica의 Linode 호스팅 환경이 침해되었고, 같은 해 Bitfloor의 암호화되지 않은 지갑 백업이 공격 진입점이 되었습니다. 플랫폼 뒤의 서버와 백업도 자산 보안 경계의 일부입니다.
출처
2015 · Bitstamp 핫 월렛
CEX
Bitstamp의 핫 월렛이 침해되었고, 운영 환경은 이후 재구축되었습니다. 사건 범위와 오프라인 준비금에 대한 공식적인 구분은 격리가 노출 범위를 제한할 수 있음을 보여주었습니다.
출처
2016 · Bitfinex
CEX
Bitfinex에서 약 120,000 BTC가 도난당했습니다. 다중 서명 방식도 여전히 종단 간 독립적인 권한 부여와 검증이 필요합니다.
출처 1 · 출처 2
2016 · The DAO
온체인 프로토콜
The DAO 컨트랙트는 재진입 공격을 받았고, 약 360만 ETH가 하위 DAO로 이체되어 이후 이더리움 포크를 촉발했습니다. 정당한 실행 경로가 치명적인 비즈니스 결과를 초래할 수 있습니다.
출처 1 · 출처 2
2017 · Parity 공유 지갑 라이브러리
컨트랙트 지갑
Parity 공유 지갑 라이브러리가 파괴되어 약 513,000 ETH가 동결되었습니다. 이체되지 않았더라도 공유 코드 의존성 때문에 자금이 사용 불가능해질 수 있습니다.
출처
2018 · Coincheck
CEXCoincheck의 NEM 핫월렛이 도난당했다. 오프라인 준비금, 핫월렛 권한, 비즈니스 요구 사이의 경계가 다시 한번 문제로 드러났다.
출처
2019 · Binance
CEX
Binance는 단일 거래에서 7,000 BTC가 인출되었다고 발표했다. 대규모 자산 유출은 서명 전에 제약되어야 한다.
출처
2020 · KuCoin
CEX
KuCoin 핫월렛 사건으로, 이후 다자간 협력을 통해 대량의 자산이 회수되었다. 총 도난 금액과 최종 손실액은 같은 숫자가 아니다.
출처
2021 · Poly Network
크로스체인 프로토콜
약 6억 1,200만 달러 상당의 자산이 Poly Network에서 이체되었고 이후 단계적으로 반환되었다. 크로스체인 권한 부여와 자산 통제는 정상적인 비즈니스 경로만으로는 유지될 수 없다.
출처
2022 · Ronin 브리지
브리지
Ronin 검증자 권한이 침해되어 173,600 ETH와 2,550만 USDC가 이체되었다. 여러 검증자의 키도 동일한 공격 체인에 빠질 수 있다.
출처
2022 · Slope 월렛
월렛
Solana 생태계의 Slope 월렛 사건. Solana 측은 개인키 정보가 실수로 애플리케이션 모니터링 서비스로 전송되었다고 밝혔으며, 이는 Solana 합의의 침해가 아니었다.
출처
2023 · Euler
렌딩 프로토콜
프로토콜 취약점으로 인해 약 1억 9,700만 달러 상당의 자산이 Euler에서 이체되었고 이후 회수되었다. 단일 거래 내 복잡한 조합은 비즈니스 로직 결함을 증폭시킬 수 있다.
출처
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 / 월렛 프런트엔드
약 15억 달러 규모의 Bybit 사건은 Safe 개발자 환경과 프런트엔드와 관련되었으며, 서명자들은 월렛 통제 로직을 변경하는 거래를 승인했다.
출처 1 · 출처 2
2025 · Cetus DEX
DEXSui의 Cetus에서 약 2억 2,300만 달러 규모의 사건이 발생했으며, 연구자들은 수학 라이브러리의 결함을 지적했다. 비EVM 환경에서도 마찬가지로 코드와 자산 노출 범위를 점검해야 한다.
출처
2026-07 · COLDCARD 난수 결함
하드웨어 월렛 / 시드 생성펌웨어 결함으로 시드 생성이 약화되어, 공격자가 기기가 오프라인 상태일 때 관련 개인 키를 재구성할 수 있었다. 업그레이드로는 이미 생성된 약한 시드를 고칠 수 없으며, 권고에 따른 마이그레이션이 여전히 필요하다.
출처
2026-10 · Ledger 하드웨어 이식
하드웨어 지갑 / 유통 공격
Ledger는 정품 기기가 개조되어 동남아시아 유통 채널을 통해 유통되었으며, 이식된 부품이 초기화 과정에서 복구 문구를 탈취했다고 확인했다. 벤더는 자사 칩, 운영체제, 서버는 침해되지 않았다고 밝혔다.
출처
2026 · Binance 멀티체인 사건
CEX / 멀티체인
Binance는 초기 추정으로 약 63억 달러 상당의 자산이 영향을 받았다고 밝혔으며, 다른 가능한 침입 지점에 대한 조사는 계속 진행 중이다. 단일 운영체제가 여러 네트워크에 걸친 자산을 동시에 노출시킬 수 있다.
출처 1 · 출처 2 · 출처 3
여기에는 CEX뿐 아니라 탈중앙화 거래소, 대출 프로토콜, 브리지도 있다. 탈취된 자산도 있고 동결된 자산도 있다. 공격은 서로 다른 계층에서 발생하며, 치료 방법도 다르다. 나는 이 모든 것을 "사용자가 개인 키를 제대로 보호하지 못했다"는 한 문장으로 축소하는 것에 반대한다. 사용자가 어떻게 특정 도구의 개발 환경, 특정 공유 라이브러리, 또는 이해할 수 없는 권한 부여가 자신의 모든 자산으로 통하는 진입점이 될 것임을 알 수 있겠는가?
분산 네트워크는 이미 많은 일을 해냈지만, 자산 통제에 대한 장애 격리는 아직 충분하지 않다. 온체인 실행은 트랜잭션을 충실히 완료하지만, 그 트랜잭션이 왜 그렇게 많은 자산을 이동할 권한을 가지는지는 우리 대신 답해주지 못한다.
이더리움의 기여는 크다. 더 많은 사람이 온체인 애플리케이션을 작성할 수 있게 했고, 풍부한 도구와 개발 경험을 키웠다. 그러나 오늘날 많은 신규 체인과 L2(레이어2 확장 네트워크)는 EVM 호환성을 최우선 목표로 삼는다. 이더리움 스마트 계약을 실행하는 가상 머신인 EVM은 널리 복제되는 기술적 전제가 되고 있다. 호환성은 애플리케이션 마이그레이션을 편리하게 해주며, Unichain 같은 프로젝트의 문서는 동등한 실행 환경의 가치로 이더리움 도구 재사용을 명시적으로 언급한다. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
나는 EVM 호환성을 업계의 기본 답안으로 삼는 것이 구조적 위험 집중을 낳고 있다고 본다. 네트워크 이름은 많을 수 있고 검증자는 다를 수 있지만, 개발자는 동일한 계약을 반복 배포하고, 동일한 권한 부여 습관을 사용하며, 동일한 소프트웨어 라이브러리에 의존할 수 있다. 공유 의존성의 오류는 다른 체인에 배포한다고 해서 사라지지 않는다. 이는 기술 경로에 대한 판단이며, 모든 EVM 구현이 반드시 동일한 취약점을 가진다는 주장이 아니다.이것이 바로 제가 이더리움에 비판을 제기하는 지점이기도 합니다. 범용 컨트랙트 실행 능력이 전송 가능한 자산과 직접 연결되면서, 애플리케이션 코드와 지갑 상호작용에 막대한 책임이 부여됩니다. 컨트랙트는 컨트랙트를 호출할 수 있고, 권한 부여는 장기간 지속될 수 있으며, 평범해 보이는 확인 한 번이 계정의 이후 통제 방식을 바꿀 수 있습니다. 보안은 갈수록 모든 개발 팀이 이러한 조합을 정확히 이해하고, 모든 사용자가 자신이 서명한 내용을 정확히 이해하는 것에 의존하게 됩니다.
EIP-7702는 이 문제를 매우 명확하게 드러냅니다. 일반 전송은 "이번에 누구에게 얼마"이지만, 위임 권한 부여는 "지금부터 이 코드 조각이 내 계정을 대신하여 작업을 실행하도록 하라"일 수 있습니다. 이는 사용자 경험 개선과 권한 세분화라는 목표를 가지고 있지만, 위임을 설정하는 것 자체가 광범위한 실행 능력을 부여하며, 세분화된 권한은 여전히 위임된 코드에 의해 올바르게 구현되어야 합니다. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) Minfeng Qi 등의 프리프린트 "EIP-7702 피싱 공격"은 이러한 권한 부여에 서명하도록 유도한 후 계정을 지속적으로 통제하는 경로를 연구합니다. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) 편의성이 증가함에 따라 보안 책임도 증가하며, 전자를 단순히 사용자에게 넘길 수는 없습니다.
이번 바이낸스 사건은 여러 체인에 걸쳐 있고 조사가 아직 완료되지 않았으므로, 전체 영향을 EIP-7702나 EVM에 직접 귀속시킬 수는 없습니다. 재진입, 서명 서비스 침해, 프런트엔드 변조 역시 동일한 취약점이 아닙니다. 그러나 그러한 구분이 아키텍처에 대한 의문 제기를 중단하는 변명이 되어서는 안 됩니다. 왜 하위 계층은 상위 계층의 오류를 대신하여 쉽게 우회할 수 없는 더 많은 제약을 유지하지 않는 것일까요?
MEV 역시 저를 불만족스럽게 합니다. 이는 참여자들이 트랜잭션의 포함, 제외, 순서 지정을 통해 추가 가치를 얻는 공간을 의미합니다. 제게 순서 지정 권한을 사용하여 사용자 트랜잭션을 샌드위치 공격하고 실행 결과를 악화시키는 것은 수정해야 할 버그로 취급되어야 하며, 누군가 이익을 얻을 수 있다는 이유만으로 보존할 가치가 있는 기능으로 포장되어서는 안 됩니다. 이더리움 자체 문서도 트랜잭션 샌드위치 공격이 사용자에게 미치는 해악과 MEV가 네트워크 안정성에 미치는 위험을 명시적으로 인정하고 있습니다. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV는 이더리움 고유의 것이 아니며 차익 거래와 청산 등 다양한 활동을 포함하고, 업계에는 이미 완화 연구가 존재합니다. 제 비판은 네트워크를 유지하려는 인센티브가 사용자의 거래 조건을 희생하는 이유가 되어서는 안 된다는 것입니다. 더 나은 거래 시스템은 최소 전달 결과와 허용 수수료를 권한 부여에 명시하고, 주문자가 미체결 정보를 이용해 사용자에게 해를 끼칠 수 있는 공간을 제한해야 합니다.저는 이더리움이 크립토에 미친 영향이 인터넷에 대한 PHP의 영향과 어느 정도 비슷하다고 늘 느껴 왔습니다. 그것은 많은 사람이 무언가를 만들 수 있게 해 주었고, 동시에 갚는 데 오랜 시간이 걸릴 엔지니어링 부채도 남겼습니다. PHP는 2026년 10월에도 심각한 원격 코드 실행 취약점을 여전히 수정해야 했습니다. 성숙함과 인기는 지속적인 강화를 대체할 수 없습니다. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) 인터넷의 가치 있는 점은 언어, 프레임워크, 클라우드 서비스가 각각 따로 진화할 수 있다는 것입니다. 우리는 서로 다른 자산 모델과 실행 방식도 계속 발전하도록 허용해야 하며, "동일한 가상 머신과의 호환성"을 생태계 참여의 입장권으로 취급해서는 안 됩니다.
따라서 저는 비트코인, 솔라나, 리플/XRP 레저 생태계와 ArcBlock을 포함한 빌더들이 공동의 보안 기반 구축에 진지하게 참여할 것을 촉구합니다. 표준과 상호운용성에 참여하는 데 먼저 자신을 이더리움으로 다시 만들 필요는 없습니다. 다양성은 자산 통제와 검증 방식에서 구현되어야 하며 공개적 검토에 열려 있어야 합니다. 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) 지갑도 이런 방향으로 설계할 가치가 있습니다. 공격자가 키를 획득하더라도 현금화할 수 있는 자산 범위는 여전히 제한되며, 공격의 기대 수익은 감소할 수 있습니다. 서비스 중단과 같은 위험은 별도로 처리해야 합니다.
이것이 제가 말하는 자산 보안의 "헌법"입니다. 운영 권한은 침해될 수 있지만, 경계를 수정하는 권한은 독립적으로 유지되어야 합니다. 복구 프로세스도 제약되어야 하며, 단일 오설정으로 자산이 영구적으로 잠기는 것을 방지해야 합니다.
II. 지갑이 니모닉 단어를 넘겨주는 것이 아니라 보안 책임을 져야 합니다
저는 오늘날의 지갑 시스템에 강한 불만을 가지고 있습니다. 제품이 일반인에게 단어 세트를 적어 두라고 요구하고, 절대 유출하거나 분실하거나 속아서 넘겨주지 말라고 요구한 뒤, 이후의 모든 실패를 사용자 책임으로 돌린다면, 저는 이것을 무책임한 설계라고 생각합니다. 자기 보관(Self-custody)은 사람들에게 통제권을 주어야 하고, 사용 가능한 보호와 복구 역량도 주어야 합니다. 모든 사용자가 먼저 보안 전문가가 되기를 요구해서는 안 됩니다. 이것은 또한 Crypto가 더 많은 일반 사용자에게 다가가기 위해 넘어야 할 문턱입니다.최근의 사건들은 이 문제를 정면으로 수면 위로 끌어올렸습니다. 2026년 10월, Ledger는 공격자들이 정품 기기를 개조한 뒤 동남아시아의 유통 채널을 통해 시장으로 다시 내보냈으며, 삽입된 부품이 초기화 과정에서 복구 단어를 탈취했다고 확인했습니다. 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) 그러나 우리는 이러한 기능을 사용자가 스스로 복잡한 방식을 조립하는 것이 아니라 테스트되고 사용하기 쉬운 보호 수단으로 만들어야 합니다.
니모닉 단어의 단순한 난독화로는 충분하지 않습니다. 더 신뢰할 수 있는 방향으로는 검토된 암호화 백업, 임계값 복구, 독립 기기 권한 부여가 있으며, 사용자가 대량의 자산을 예치하기 전에 복구 훈련을 완료하도록 하는 것입니다. 백업 샤드와 다중 서명은 서로 다른 계층입니다. 전자는 복구 시 동일한 비밀로 재결합될 수 있는 반면, 후자는 여러 독립 서명자가 거래를 승인해야 합니다. 복구 서비스가 조용히 새로운 마스터 키가 되어서는 안 되며, 추가 비밀번호가 분실하면 복구할 수 없는 손실을 의미하는 또 다른 함정이 되어서도 안 됩니다.개인 지갑과 거래소 지갑 시스템은 거래 설명, 서명 요청, 자산 제한 및 복구 프로세스에 대한 보안 사양을 공유할 수 있으면서도 서로 다른 한도와 승인 정책을 채택할 수 있습니다. 비트코인의 PSBT는 이미 서명되지 않은 거래를 도구 간에 전달하는 형식을 제공하고 있으며, 이 공통 인터페이스는 계속 구축할 가치가 있습니다. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) 공통적인 것은 검증 가능한 보안 요구사항이며, 각 체인은 여전히 자체적인 적응 규칙을 명확히 해야 합니다. 지갑은 이 서명이 무엇을 이전하고 누구에게 얼마만큼의 후속 권한을 부여하는지 명확히 제시해야 하며, 독립적인 정책은 범위를 벗어난 작업을 거부해야 합니다. 더 예쁜 확인 페이지만으로는 충분하지 않습니다.
III. 최소한의 필요 공개로 검증 가능성 달성
조건이 성립함을 증명하는 데 항상 사용자가 모든 기초 데이터를 공개해야 하는 것은 아닙니다. 선택적 공개, 영지식 증명, 요청 시 부여되는 감사 접근 권한은 인프라의 일반적인 옵션이 되어야 합니다. 이는 자산 보안과도 관련이 있습니다. 공개된 신원과 자산 관계는 표적 사기의 단서를 제공할 수 있으므로, 비즈니스에 필요하지 않은 데이터는 최대한 적게 노출해야 합니다.
W3C의 검증 가능한 자격 증명 시스템은 이미 선택적 공개를 위한 기술적 경로를 갖추고 있으나, 입력이 진본인지, 자격 증명이 유효한지, 상태가 어떻게 철회되는지는 여전히 명확히 해야 합니다. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) 영지식 증명(ZK)을 채택한다고 해서 거래 금액과 관계가 자동으로 숨겨지는 것은 아니며, 증명 확장과 프라이버시 보호는 서로 다른 목표입니다.
예를 들어, 비즈니스가 참여 자격만 검증하면 되는 경우, 사용자는 완전한 금융 자료를 공개하지 않고도 신뢰할 수 있는 기관이 발급한 유효한 자격 결론을 제시할 수 있습니다. 숨겨진 값이 조건을 충족함을 증명해야 할 때는 적절한 증명 메커니즘을 사용할 수 있습니다. 자격 증명의 신뢰할 수 있는 출처와 철회 상태는 여전히 검증해야 합니다.
나의 이니셔티브는 먼저 "누가 무엇을 검증해야 하는지"를 명확히 하고, 그다음 공개해야 하는 데이터를 설계하는 것입니다. 자격을 검증하는 사람은 자격 결론만 필요할 수 있으며, 특정 감사 책임을 지는 사람은 제한된 증거를 얻을 수 있습니다. 공개적으로 검증 가능한 제약은 모든 사람에게 영구적으로 노출되는 개인 정보를 최소화해야 합니다.
IV. 거래 서비스를 가능한 한 중앙화된 수탁에서 자유롭게 만들기거래 매칭, 경로 탐색, 자산 결제는 별도로 설계되어야 한다. 거래 진입점을 제공하는 서비스는 가능한 한 현재 결제를 완료하는 데 필요한 권한만 획득해야 하며, 그 외의 시간에는 사용자 자산이 각자의 통제 아래 유지되도록 해야 한다. 기존의 의도 기반 거래 프로토콜은 이미 경로의 일부를 탐구했으며, 업계는 이를 계속 완성해 나갈 수 있다. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
사용자가 동의하는 것은 명확한 결제 조건이어야 하며, 여기에는 무엇을 지불하는지, 최소한 무엇을 받는지, 언제 만료되는지, 허용되는 수수료가 포함된다. 거래 서비스가 침해된 후 공격자는 서비스 거부를 할 수 있지만, 이러한 조건을 임의로 변경할 수는 없다. 여전히 중앙화된 보관이 필요한 기업도 준비금 권한과 운영 권한을 분리하고, 핫월렛 노출과 자동 보충 한도를 제한해야 한다.
IBIT는 iShares의 비트코인 상장지수상품이며, 시장에서 거래되는 것은 그 주식이다. 그 구조는 부분적 격리의 예를 제공한다: 주식과 기초 비트코인은 별도로 기록되며, Vault Balance(보관 잔액)에 대한 관련 개인 키는 콜드 스토리지에 보관된다. 주식 거래 기록의 변경은 기초 비트코인이 각 거래마다 함께 이동할 것을 요구하지 않는다. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) 여기서 배울 수 있는 것은 거래 권한과 준비금 처분 권한의 분리이다. Trading Balance(거래 서비스 잔액)는 다른 구조를 가지며, 보관 자체도 위험을 수반하므로 콜드 스토리지는 독립적인 지시와 서명 검증과 함께 이루어져야 한다.
나는 거래 진입점을 라우터에 비유하는데, 이는 모든 사용자 자산에 대한 마스터 스위치를 지니지 않고 교체될 수 있기를 바라기 때문이다. 결제는 패킷 포워딩보다 복잡하며, 자산 전달과 권한 부여는 여전히 독립적으로 검증되어야 한다. 서비스를 비수탁형으로 만들고 나서 무제한 출금 권한을 부여하는 것은 중앙화 위험을 다시 불러올 뿐이다.
V. 계층형 아키텍처를 사용하여 장애를 격리하고 교체 가능성을 보존하라우리는 독립적으로 진화할 수 있는 신원 및 권한 부여 인터페이스, 자산 정책, 결제 검증 방법이 필요하다. 서로 다른 체인은 자체 실행 모델을 유지하면서 명확한 인터페이스를 통해 연결될 수 있다. 인터페이스는 단순히 "호출이 성공했다"고 말하는 것이 아니라 보안 보장과 그 조건을 명시해야 한다.인터넷 경험은 이러한 접근을 뒷받침한다. RFC 9518, "중앙화, 탈중앙화, 그리고 인터넷 표준"에서 Mark Nottingham은 중앙화가 도움이 될 수 있는 상황을 구체적으로 논의하고, 그것이 가져오는 권력과 위험도 분석한다. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) 이것이 바로 배울 가치가 있는 태도다: 어떤 책임이 중앙화될 수 있는지, 어느 정도까지 가능한지, 그리고 그 권력이 확장되는 것을 어떻게 방지할지를 아키텍처가 답하게 하라. 서비스가 이상 징후를 중앙에서 식별하도록 허용할 수 있지만, 자산에 접촉할 권한은 제한되어야 한다. 사용자는 자신의 자산 정책과 검증 기록을 잃지 않고 서비스를 전환할 수 있어야 한다.
가장 중요한 수용 질문은 이것이다: 비즈니스 서비스가 침해된 후, 어떤 독립 계층이 여전히 이를 거부할 수 있는가? 모든 계층이 하나의 관리 키를 공유한다면, 소위 계층화는 배포 다이어그램 위의 계층화에 불과하다.
이 목표는 다섯 계층의 책임으로 볼 수 있다: 거래 서비스는 요청을 제출하고, 지갑은 사용자 의도를 표현하며, 독립 정책은 자산 처분에 대한 권한을 제한하고, 검증 구성 요소는 작업과 증거를 확인하며, 결제 계층은 제약을 강제하고 검증 가능한 기록을 제공한다. 이들은 서로 다른 팀에 의해 구현될 수 있으며, 그 의존성과 실패 조건도 별도로 설명되어야 한다.
이 글에서 주장하는 목표 아키텍처. 결제 계층은 자산 정책을 강제해야 하며, 지갑의 프롬프트가 이 제약을 대체할 수 없다. 일상 서명, 규칙 변경, 복구 권한은 격리되어야 하며 우회 테스트를 받아야 한다.
6. 사용자가 자신의 자산을 가볍게 검증하도록 하라
일반 사람들은 자신의 잔액과 영수증을 검증하기 위해 전체 체인의 전체 이력을 저장하고 실행할 필요가 없어야 하며, 지갑 뒤의 단일 서버만 신뢰해서도 안 된다. 사토시 나카모토는 이미 백서 8절에서 SPV, 즉 간편 결제 검증을 제안했다. 비트코인의 BIP-157은 클라이언트가 필터를 다운로드하고 자신과 관련된 블록을 찾도록 하는 탐구를 계속하고 있으며, 이더리움에도 라이트 클라이언트 설계가 있다. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) 따라서 문제는 아무도 생각해 본 적이 없다는 것이 아니라, 명확한 보안 조건을 갖춘 검증 능력을 사용자가 매일 사용하는 지갑에 여전히 구축해야 한다는 것이다.계정 상태 증명을 지원하는 체인을 예로 들어 보자. 잔액을 조회할 때 서버는 잔액과 증명을 함께 반환해야 한다. 지갑은 먼저 해당 체인의 규칙에 따라 짧은 블록 다이제스트, 즉 블록 헤더를 검증한 다음, 이 잔액이 그 다이제스트가 커밋한 데이터와 일치하는지 확인한다. 서버가 답을 제공하고, 지갑은 그 답을 검증할 수 있다. 비트코인의 SPV는 관련 트랜잭션이 포함되었다는 증거를 검증하는 것이며, 이를 그대로 잔액 증명으로 복사할 수는 없다. 지갑은 또한 자신이 어디까지 동기화되었는지, 어떤 정보가 검증되었는지를 명확히 표시해야 하며, 증명이 누락되었거나 데이터가 오래되었거나 출처가 충돌할 경우 경고하거나 이 정보에 의존하는 고위험 작업을 중단해야 하며, 조용히 맹목적 신뢰로 후퇴해서는 안 된다.
라이트 검증에도 조건이 있다. 트랜잭션이 블록에 포함되었음을 증명하는 것은 블록 내 모든 트랜잭션이 유효함을 스스로 확인하는 것과 같지 않다. 서로 다른 방식은 과반수의 해시 파워가 정직하다는 것에 의존하거나, 신뢰할 수 있는 초기 기록, 즉 체크포인트에 의존할 수 있다. 또한 서버가 데이터를 은닉하거나 사용자를 오래된 체인 기록에 고립시키는 것도 방어해야 한다. 조회 자체가 사용자가 관심 있는 주소를 노출하는지도 처리해야 한다. 풀 노드와 블록 생산자는 같은 역할이 아니며, 오늘날 이더리움은 블록 생산에 채굴자가 아닌 검증자를 사용한다.
더 중요하게는 "이 전송이 실제로 온체인에서 발생했다"는 것을 증명하는 것이 "이것이 바로 사용자가 원한 전송"임을 증명할 수는 없다. 라이트 클라이언트는 앞서 말한 자산 한도와 서명 검사를 대체할 수 없다. 라이트 클라이언트는 사용자가 검증할 수 없는 답에 덜 의존하게 해주며, 자산 정책은 유효한 서명이라도 자산을 무제한으로 처분할 수 없도록 보장한다. 이 두 계층을 함께 구축해야만 검증 능력이 참여자들 사이에 분산될 수 있다.
7. 이상 식별과 보안 검증을 공공 인프라로 구축하라
트랜잭션 전에 누군가는 해당 작업이 자산 정책을 준수하는지, 역사적 행동을 갑자기 바꾸는지 확인해야 한다. 명백한 이상은 일시 중지나 에스컬레이션 검토를 촉발할 수 있으며, 권한 확장에는 또 다른 독립적 경로가 필요하다. AI는 판단에 참여할 수 있지만, 하드 규칙을 무시하는 통행권을 받아서는 안 된다.
동시에 우리는 반복 실행 가능한 공격 사례, 권한 테스트, 검증 도구를 공동으로 유지해야 한다. 규격을 공유하고 독립 구현과 독립 검증을 보존해야만 공통 모드 실패를 줄일 수 있다. 재단과 거래소는 이미 보안 투자를 하고 있으며, 예를 들어 이더리움 재단의 Trillion Dollar Security Initiative가 있다. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) 다음으로 물어야 할 질문은 그 투자가 다른 팀도 채택하고 검사할 수 있는 공공 인프라로 전환될 수 있는가이다.이 일곱 가지 작업 항목 중 어느 것도 절대적인 보안을 보장할 수는 없습니다. 이들이 제공해야 하는 것은 검사 가능한 경계입니다. 즉, 어떤 권한 침해 조건에서 최대 얼마만큼의 자산이 노출되는지, 이상 징후를 얼마나 빨리 발견할 수 있는지, 그리고 복구가 여전히 누구에게 의존하는지입니다.
이쯤에서 누군가는 이렇게 말할 수 있습니다. 방향은 맞는 것 같지만, 업계는 이미 수년간 이어져 왔는데, 재구축에는 얼마나 많은 사람과 시간이 필요할까? 이것 역시 이상주의가 아닌가?
과거의 소프트웨어 생산 방식에 따라 추정한다면, 이 의문은 매우 현실적입니다. 그러나 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 및 클라우드 컴퓨팅 기업들도 모델 쿼터, 컴퓨팅 자원, 도구를 통해 이러한 공공 구축을 지원할 수 있습니다. 사양, 프로토타입 코드, 에이전트 워크플로, 테스트 환경, 검증 결과 모두 공동으로 유지 관리되는 인프라가 되어 다음 팀이 그곳에서 바로 이어서 작업할 수 있게 할 수 있습니다. 목표는 개발 역량을 재사용 가능한 공공 시설로 구축하고, 특정 개인의 시간이나 특정 팀에 대한 의존도를 줄이는 것입니다.
공격자들도 AI를 사용하고 있으며, 우리는 더 이상 방어를 과거의 생산 방식에 맡겨둘 이유가 없습니다. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) 그러나 코드 생성이 빠르다는 것은 시작점일 뿐입니다. 제약 조건을 명확히 작성하고, 테스트를 반복 실행 가능하게 하며, 컴포넌트를 검사 및 교체 가능하게 만들어야만 AI 역량이 인프라 개선으로 전환될 수 있습니다.
독립 빌더들은 코딩 에이전트와 AI 도구의 도움을 받아 협력합니다. 우주 워크숍은 공공 구축의 은유입니다. 저는 특히 여전히 구축을 사랑하는 사람들에게 이 호소를 전하고 싶습니다. 여기서 "해커"는 시스템이 어떻게 작동하는지 파악하려 하고, 발견한 것을 공유하려 하며, 다른 사람들이 자신의 작업을 테스트하도록 허용하려는 사람을 의미합니다. 그 정신은 한때 인터넷을 앞으로 나아가게 했으며, 오늘날에는 Crypto를 앞으로 나아가게 할 수 있습니다.
저는 이 업계에 똑똑한 사람들이 부족하다고 믿지 않으며, Crypto와 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 협업 관행을 기여할 의향이 있습니다. 우리는 업계의 작은 팀일 뿐이고 할 수 있는 일은 제한적입니다. 프로토타입 하나와 재현 가능한 테스트 세트부터 시작하고자 합니다.
실무 운영 경험이 있는 분들은 비식별화된 공격 시나리오를 제공하고, 지갑과 프로토콜 팀은 보호 조치를 구현하며, 독립 연구자들은 이를 우회하려 시도할 수 있습니다. 각 팀이 감당할 수 있는 부분을 맡아 해결책을 함께 테스트하고 다음 단계를 결정합니다.
저는 이 글의 자산 제한 및 복구 요구사항을 첫 번째 공개 명세로 정리하는 일에 참여할 의향이 있으며, 관련 기술 및 엔지니어링 관행을 기여해 다른 참여자들과 함께 이 파일럿을 위한 공공 AI Factory를 구축할 의향도 있습니다. 먼저 아주 구체적인 문제 하나를 선택합시다. 일상 거래 키가 이미 유출된 상황에서, 공격자가 지갑을 한 번에 비우는 것을 어떻게 막을 수 있을까요? 허용 손실 범위, 규칙 수정 권한, 복구 조건을 인수 테스트로 작성한 뒤, 개발 에이전트가 프로토타입을 구현하고, 또 다른 에이전트 그룹과 독립 연구자들이 우회 경로를 찾도록 합니다. 잘못된 잔액을 반환하는 데이터 서버, 기기 분실 후 복구도 점차 테스트에 추가할 수 있습니다. 프로토타입이 달성한 것, 실패한 지점, 남은 의존성은 모두 공개적으로 설명하고, 증거에 기반해 다음 단계를 결정해야 합니다.
참여 의향이 있는 분들은 X에서 이 이니셔티브를 공개적으로 리포스트하거나 인용하고 @mave99a를 태그해, 해결하고 싶은 문제, 비식별화된 공격 사례, 또는 기여할 수 있는 자원을 이야기해 주시기 바랍니다. 논의가 공개적으로 진행되어 더 많은 빌더들이 보고 참여할 수 있기를 바랍니다.
크립토는 이대로 계속될 수 없습니다. 함께할 의향이 있는 분들, 지금 행동합시다. 구축 가능하고 테스트를 견딜 수 있는 개선 하나부터 시작해서요.바이낸스, 최초 발표 공식 게시물 및 후속 조사 공식 업데이트, 2026-10-30; TRM 멀티체인 분석. 본 초안은 2026-10-30 기준으로 검증되었으며, 조사 및 복구 상태는 변경될 수 있습니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
사토시 나카모토, 비트코인: 피어 투 피어 전자 화폐 시스템, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
유니스왑, 유니체인 EVM 동등성. 공유 의존성의 위험 집중은 본 문서에서 필자의 판단이며, 해당 문서의 결론이 아닙니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
비탈릭 부테린, 샘 윌슨, 안스가르 디트릭스, 라이트클라이언트, EIP-7702: EOA용 코드 설정, 2024-05-07 작성. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
민펑 치, 친 왕, 루이창 리, 톈칭 주, 스핑 천, EIP-7702 피싱 공격, 2025-12-13, arXiv v1 프리프린트; 본 바이낸스 사건의 특정을 의미하지 않음. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
이더리움, 최대 추출 가능 가치(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)
세이프, 가드 및 모듈, 기능 및 권한 위험 설명. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
애플, 애플, 중고 정품 부품 지원으로 수리 옵션 확대, 2024-04-11; 현재 부품 페어링 지원 설명. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)레저, 하드웨어 임플란트 공격에 대한 레저의 대응, 2026-10, 유통 체인 내 공격에 관한 벤더 성명; 조 그랜드, 하드웨어 임플란트에 관한 리버스 엔지니어링 연구. 검증되지 않은 네트워크 손실 추정치를 확정적 결론으로 제시하지 마십시오. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
코인카이트, 현재 콜드카드 보안 상태, 2026-10-30 접속, 2026년 7월 사건 및 재발 방지에 관한 지속 업데이트 기록; 업그레이드와 시드 마이그레이션은 서로 다른 두 가지 작업입니다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: 대체 멤풀을 사용한 계정 추상화; 트레저, SLIP39 FAQ, 임계값 복구, 호환성 및 추가 패스프레이즈 위험. 기존 메커니즘은 구축을 위한 기반이며, 모든 배포가 신뢰할 수 있음을 의미하지는 않습니다. [↩](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, 검증 가능한 자격 증명 개요 v1.0, 2026-07-30 그룹 노트; 이더리움 프라이버시 노트. 개요에서 설명하는 기술의 표준 지위는 각각 독립적이다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
CoW 프로토콜 문서, 트랜잭션 인텐트 및 솔버 메커니즘; 본 문서는 특정 배포에 대한 포괄적인 보안 보증을 제공하지 않는다. [↩](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: 중앙화, 탈중앙화, 인터넷 표준, 2023-12, 독립 제출, 정보성 RFC, 표준 트랙 명세 아님. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
비트코인 백서 제8절 간이 지불 검증; BIP-157: 클라이언트 측 블록 필터링; 이더리움, 라이트 클라이언트. 라이트 클라이언트마다 검증 범위와 신뢰 조건이 다르다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
이더리움 재단, 1조 달러 보안 이니셔티브 발표, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, 핵심 인프라 방어를 위한 AI, 2026-01-08, PNNL과 협력한 제한 환경 연구. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, AI 기반 사이버 위협 매핑, 실제 악용 샘플 연구. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, 스타워즈: 새로운 희망(에피소드 IV), 1977; 본 문서는 제목과 공동 자구의 이미지를 차용한다. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)