727財經一次事故帶走的不只是資產，還有信任。Crypto 不能再這樣下去，我們必須自救。
作者：ArcBlock創始人兼首席執行官 Robert Mao
本文授權任何人自由轉載、轉發，希望讓更多人看到這份行業自救的呼籲。
Crypto 不能再這樣下去。一次次大規模失竊，被奪走的不只是資產，還有參與者對整個行業的信任。我們必須自救。
2026 年 10 月 29 日，幣安發生重大安全事件。其初步公告估計約 63 億美元資產受到影響，約 30 億美元受影響資產已被凍結；調查最初指向 DevOps 工程師的筆記本，隨後又發現其他可能入侵點。幣安同時表示，尚未發現錢包私鑰洩露的證據。受影響金額不是最終淨損失，完整攻擊鏈仍待調查。[[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
這份倡議，寫給 Ethereum、Solana 等區塊鏈項目的建設者，也寫給 Binance、Coinbase、Kraken，以及所有願意參與的交易所、錢包、協議和安全建設者：讓我們一起重建保護資產的基礎。我願意參與，也希望更多人一起行動。
這已經足夠沈重。但我更擔心，這次事件又會打掉多少人對 Crypto 的信心，又會讓多少攻擊者把這個行業視為值得繼續下手的目標。即使最後有人承擔損失，賠付也不能自動修復用戶的信任，更不能讓同一種破壞停止發生。
幣安只是今天讓我們不得不面對問題的切口。把視線移開，交易所、網橋、鏈上協議和錢包早已留下了一長串傷口。新的網絡和產品不斷出現，舊的故障模式卻反復重演。我們不能發佈一份公告、等待一陣，然後把下一次事故也當成日常。
我們也必須承認，騙局與只製造概念、不承擔建設責任的做法，已經傷害了這個行業太久。認真做技術和基礎設施的團隊，也要共同承受信任流失的後果。等到人們把整個 Crypto 都看成騙局，真正值得保留的技術與探索，也可能被一起放棄。
作為 ArcBlock 的 founder，一個 Crypto 與 Blockchain 從業者，我不願接受這樣的結局。我相信這個行業有值得保護的價值，也認為我們必須為自己的安全基礎承擔責任。如果繼續消極地等待下一次事故，反復失血最終可能摧毀我們共同建設的一切。
所以，我想發出這份倡議：交易所、錢包和區塊鏈的建設者，應當共同重建資產控制與安全驗證的基礎，讓一次入侵的破壞範圍受到約束。下面的時間線說明瞭為甚麼必須改變；後面的技術方案，是我認為可以開始做的工作。
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 萬 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 萬 ETH 凍結。沒有被轉走，也可能因為共同代碼依賴失去使用能力。
來源
2018 · Coincheck
CEX
Coincheck 的 NEM 熱錢包被盜。離線儲備、熱錢包權限與業務需求之間的邊界再次成為問題。
來源
2019 · Binance
CEX
幣安公告 7,000 BTC 在一筆交易中被提走。大規模資產流出需要在簽名前受到約束。
來源
2020 · KuCoin
CEX
KuCoin 熱錢包事故，後續通過多方協作追回大量資產。毛被盜額與最終損失不是一個數字。
來源
2021 · Poly Network
跨鏈協議
Poly Network 約 6.12 億美元資產被轉出，隨後陸續返還。跨鏈授權與資產控制不能只靠正常業務路徑成立。
來源
2022 · Ronin 網橋
網橋
Ronin 驗證者權限遭攻破，173,600 ETH 與 2,550 萬 USDC 被轉出。多個驗證者的鑰匙也可能落入同一攻擊鏈。
來源
2022 · Slope 錢包
錢包
Solana 生態的 Slope 錢包事件。Solana 官方指出私鑰信息被意外傳至應用監控服務；不是 Solana 共識被破解。
來源
2023 · Euler
借貸協議
Euler 約 1.97 億美元資產因協議漏洞被轉出，後續追回。單筆交易的複雜組合可以放大業務邏輯缺陷。
來源
2023 · Ledger Connect Kit
錢包連接工具
Ledger Connect Kit 遭供應鏈攻擊，惡意代碼進入應用前端。硬件設備安全不能替代交易內容驗證。
來源
2024 · DMM Bitcoin
CEX
DMM Bitcoin 約 3.08 億美元被盜。FBI 等機構後續披露了針對相關人員和簽名鏈路的社工攻擊。
來源
2024 · Radiant Capital
借貸協議／簽名
Radiant Capital 約 5,000 萬美元被盜，多個開發者設備遭攻破。多人簽名仍可能共同依賴受污染的交易信息。
來源
2025 · Bybit／Safe
CEX／錢包前端
Bybit 約 15 億美元事故，攻擊涉及 Safe 開發者環境和前端，簽名者批准了改變錢包控制邏輯的交易。
來源 1 · 來源 2
2025 · Cetus DEX
DEX
Sui 上的 Cetus 約 2.23 億美元事故，研究者指出數學庫缺陷。非 EVM 環境同樣必須檢驗代碼與資產暴露範圍。
來源
2026-07 · COLDCARD 隨機數缺陷
硬件錢包 / 種子生成
固件缺陷削弱種子生成，攻擊者能在設備離線時重建相關私鑰。升級不能修復已經生成的弱種子，仍需按公告遷移。
來源
2026-10 · Ledger 硬件植入
硬件錢包 / 分銷攻擊
Ledger 確認真設備被改裝並通過東南亞經銷渠道流通，植入組件在初始化時竊取恢復詞。廠商稱其芯片、操作系統和服務器未被攻破。
來源
2026 · Binance 多鏈事故
CEX／多鏈
幣安初估約 63 億美元資產受影響，其他可能入侵點的調查仍在進行。單一運營體系可以讓多個網絡上的資產同時暴露。
來源 1 · 來源 2 · 來源 3
這裡有 CEX，也有去中心化交易所、借貸協議和網橋；有資產被盜，也有資產凍結。攻擊發生在不同層，修復方法也不同。我反對把這些都歸結為一句「用戶沒保管好私鑰」。用戶怎樣才能知道，某個工具的開發環境、某個共享庫，或者一筆看不懂的授權，會成為自己全部資產的入口？
分布式網絡已經做了很多事，資產控制的故障隔離卻遠遠不夠。鏈上執行忠實地完成了一筆交易，不能替我們回答這筆交易為甚麼有權搬走這麼多東西。
Ethereum 的貢獻很大。它讓更多人能編寫鏈上應用，形成了豐富的工具和開發經驗。但今天，許多新鏈與 L2（二層擴展網絡）都把 EVM 兼容當成首要目標。EVM，也就是執行 Ethereum 智能合約的虛擬機，正在成為一種被廣泛複製的技術前提。兼容確實方便應用遷移；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 也讓我不滿。它指的是參與者利用交易納入、排除與排序取得額外價值的空間。對我來說，利用排序權夾擊用戶交易、惡化其成交結果，應當被當成需要修復的 bug，不能因為有人能從中賺錢，就包裝成值得保留的 feature。Ethereum 自己的文檔也明確承認夾擊交易對用戶的傷害，以及 MEV 對網絡穩定性的風險。[[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV 並非 Ethereum 獨有，也包含套利和清算等不同活動；行業已有緩解研究。我的批評是，維護網絡的激勵不能成為犧牲用戶交易條件的理由。更好的交易體系應當把最低交割結果與允許費用寫進授權，並限制排序者利用未成交信息傷害用戶的空間。
我一直覺得 Ethereum 對 Crypto 的影響，有一點像 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 和其他路線分別實現，再公開檢驗各自的保證與代價。
一、讓底層風控約束資產處置權
大額錢包應當能設置收款白名單、累計支出上限，以及新收款方的等待期。關鍵是，這些規則不能被同一把日常交易鑰匙立即取消。修改規則需要獨立授權，還要給監測和撤銷留下時間。
現有智能賬戶已經有實現基礎，例如 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) 錢包也值得朝這個方向設計。攻擊者拿到一把鑰匙，能夠變現的資產範圍仍然有限，攻擊的預期收益就可能下降；破壞服務等風險仍需另外處理。
這是我所說的資產安全「憲法」：操作權限可以失陷，修改邊界的權限仍應保持獨立。恢復流程也必須受約束，防止一次錯誤配置永久鎖死資產。
二、讓錢包承擔安全責任，而不只是交出助記詞
我對今天的錢包體系有一個很強的不滿：如果一個產品讓普通人抄下一組詞，要求他永遠不能洩露、不能遺失、不能被騙，然後把此後的失敗全部歸結為用戶責任，我認為這是一種不負責任的設計。自我保管應該給人控制權，也應該給人可用的保護與恢復能力。它不該要求每個使用者先成為安全專家。這也是 Crypto 走向更多普通用戶必須跨過的一道門檻。
最近的事故把這個問題擺得很直接。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) 共同的是可檢查的安全要求，各條鏈仍需明確自己的適配規則。錢包應清楚呈現這次簽名會轉移甚麼、授予誰多少後續權限，並由獨立策略拒絕越界操作；一張更漂亮的確認頁面還不夠。
三、以最小必要披露實現可驗證
證明一個條件成立，不應總是要求用戶公開全部底層數據。選擇性披露、零知識證明，以及按需授予的審計訪問，應該成為基礎設施的正常選項。這也與資產安全有關：公開的身份與資產關係，可能為定向欺騙提供線索；業務不需要的數據，應該盡量少暴露。
W3C 的可驗證憑證體系已經有選擇性披露的技術路徑；但證明輸入真實、憑證仍然有效、以及狀態如何撤銷，仍需明確。[[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) 採用零知識證明（ZK）也不自動隱藏交易金額和關係，擴容證明與隱私保護是不同目標。
例如，一項業務只需要核驗參與資格時，用戶可以出示受信任機構簽發的有效資格結論，而不公開完整財務材料。需要證明隱藏數值滿足條件時，再使用適當的證明機制。憑證的可信來源與撤銷狀態仍要驗證。
我的倡議是把「誰需要驗證甚麼」先說清，再設計必須公開的數據。驗證資格的人可能只需要資格結論；承擔特定審計職責的人可以獲得受限證據。公開可驗證的約束，盡量減少對所有人永久暴露的個人信息。
四、讓交易服務盡量擺脫集中托管
交易撮合、尋找路徑和完成資產交割，應當分開設計。一個提供交易入口的服務，應當盡量只取得完成當前交割所必需的權限，讓用戶資產在其餘時間保留在各自控制下。現有基於交易意圖的協議已經探索部分路徑，行業可以繼續把它做完整。[[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），是希望它可以被替換，而不攜帶全體用戶資產的總開關。結算比數據包轉發更複雜，資產交付和授權仍要獨立驗證。把服務做成非托管以後，再授予它無限提款權，只會把集中風險重新帶回來。
五、用分層架構隔離故障，保留替換能力
我們需要能獨立演進的身份與授權接口、資產策略和結算驗證方式。不同鏈可以保留自己的執行模型，通過明確的接口連接。接口要說明的是安全保證及其條件，不能只說「調用成功」。
互聯網經驗支持這種思路。Mark Nottingham 在 RFC 9518《Centralization, Decentralization, and Internet Standards》中專門討論了中心化可以有幫助的情形，也分析了它帶來的權力和風險。[[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) 這正是值得借鑒的態度：讓架構回答哪些職責可以集中、集中到甚麼程度，以及怎樣防止這份權力擴張。 可以讓一個服務集中識別異常，同時限制它接觸資產的權限；用戶應能更換服務，而不丟失自己的資產策略和驗證記錄。
最重要的驗收問題是：業務服務被攻破以後，哪個獨立層還能拒絕它？如果所有層共用一把管理鑰匙，所謂分層只是部署圖上的分層。
可以把這個目標看成五層職責：交易服務提交請求，錢包表達用戶意圖，獨立策略限定資產處置權，驗證組件檢查操作與證據，結算層執行約束並提供可核驗的記錄。它們可以由不同團隊實現，也要分別說明依賴和失陷條件。
本文倡議的目標架構。結算層必須強制執行資產策略；錢包里的提示不能替代這道約束。日常簽名、規則變更與恢復權限需要隔離，並接受繞過測試。
六、讓用戶能夠輕量驗證自己的資產
普通人不應為了驗證自己的餘額和收款，就必須保存並執行整條鏈的全部歷史；也不應只能相信錢包背後的一個服務器。中本聰在白皮書第八節已經提出 SPV，即簡化支付驗證。Bitcoin 的 BIP-157 繼續探索讓客戶端下載過濾器、查找與自己有關的區塊；Ethereum 也有輕客戶端設計。[[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) 所以問題不是從來沒人想過，而是我們還需要把帶有明確安全條件的驗證能力，做進用戶每天使用的錢包。
以支持賬戶狀態證明的鏈為例，查詢餘額時，服務器應當同時返回餘額和證明。錢包先按這條鏈的規則核驗一份簡短的區塊摘要，也就是區塊頭，再檢查這個餘額是否與摘要所承諾的數據一致。服務器提供答案，錢包能夠核驗答案。Bitcoin 的 SPV 核驗的是相關交易被收錄的證據，不能直接照搬這種餘額證明。錢包還應明確顯示同步到了哪裡、哪些信息已經核驗；證明缺失、數據過期或來源矛盾時，應當提示或停止依賴這些信息的高風險操作，不能悄悄退回盲目信任。
輕驗證仍有條件。證明一筆交易被收進區塊，不等於自己檢查了區塊里所有交易都合法。不同方案可能依賴多數算力誠實，或一個可信的初始記錄，也就是檢查點；還要防範服務器隱瞞數據，或者把用戶隔離在一份過期的鏈記錄上。查詢本身會不會暴露用戶關注的地址，也需要處理。全節點與出塊者不是同一個角色，Ethereum 今天的出塊使用驗證者，而不是礦工。
更重要的是，證明「鏈上確實發生了這筆轉賬」，不能證明「這正是用戶想要的轉賬」。輕客戶端不能替代前面的資產限制與簽名檢查。它讓用戶少依賴一個無法核驗的答復，而資產策略讓一筆有效簽名也不能無限處置資產。兩層一起建設，才是在把驗證能力分散到參與者手裡。
七、把異常識別和安全驗證建成公共基礎
交易之前，應當有人檢查這筆操作是否符合資產策略、是否突然改變歷史行為。明顯異常可以觸發暫停或升級審核；擴大權限需要另一條獨立路徑。AI 可以參與判斷，但不應獲得越過硬規則的通行證。
與此同時，我們需要共同維護攻擊案例、權限測試和可重復運行的驗證工具。共享規範，保留獨立實現與獨立驗證，才能降低共同故障。基金會和交易所已經有安全投入，例如 Ethereum Foundation 的 Trillion Dollar Security Initiative。[[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) 下一步要追問的是，投入能否轉化成其他團隊也能採用和檢查的公共基礎。
這七項工作都不能保證絕對安全。它們要交付的是可檢查的邊界：在甚麼權限失陷的條件下，資產最多暴露多少，異常多久能被發現，恢復還依賴誰。
讀到這裡，可能有人會說：方向聽起來都對，但行業已經走了這麼多年，重構需要多少人、多少時間？這不還是理想主義嗎？
如果仍按過去的軟件生產方式估算，這個疑問非常現實。但到了 2026 年，我認為 coding agents 和 AI 賦能的軟件工程，已經改變了我們能動用的建設能力。這裡說的 coding agents，是能夠在開發環境中讀寫代碼、調用工具、運行測試，並依據反饋繼續工作的 AI 編程助手。建設者提出目標、划定安全邊界，借助這些工具實現和檢查系統，並對結果負責。
過去需要大團隊反復實現、適配和維護的工作，現在小團隊可以借助這種新的工程方式去嘗試。一個團隊守住一層，圍繞清楚的接口交付組件，再由其他團隊檢查和組合。把人的架構判斷、coding agents 的實現能力，以及獨立的安全驗證組織起來，才是我認為值得認真重估的建設路徑。
Anthropic 與 PNNL 的研究給出一個具體例子：在限定的關鍵基礎設施模擬環境里，研究者報告，攻擊重建從可能需要數周縮短到約三小時。[[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) 它不能證明一個小團隊已經能安全重寫整個行業，卻說明過去昂貴的驗證與攻防工作，可以出現新的成本條件。
一個可以現在啓動的組織方式，是共同建設一座 Build in Public 的 AI Factory。行業專家、學者和從業者公開編寫需求與驗收規範（spec），說明要保護甚麼、允許哪些操作、哪些權限失陷以後仍要守住甚麼邊界，再把這些要求寫成驗收測試。成組的 coding agents 承擔主要的編碼、測試和查錯工作；不同團隊檢查設計與結果，人承擔判斷和驗收責任。
參與者可以貢獻想法、機器、算力，以及模型調用額度，也就是 AI tokens。AI 和雲計算公司也可以通過模型額度、計算資源與工具支持這項公共建設。Spec、原型代碼、agent 工作流程、測試環境與驗證結果都可以成為共同維護的基礎，讓下一支團隊直接接著做。目標是把開發能力建設成可重復使用的公共設施，減少對某一個人的時間、某一支團隊的依賴。
攻擊者同樣在使用 AI，我們已經沒有理由把防守留在過去的生產方式里。[[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) 但代碼生成得快，只是起點。把約束寫清楚，讓測試可以反復運行，讓一個組件可以被檢查和替換，才會把 AI 的能力轉化為基礎設施的改善。
獨立的建設者借助 coding agents 與 AI 工具共同工作。太空工坊是公共建設的隱喻。
我尤其想把這份呼籲送給那些仍然熱愛建造的人。這裡的 hacker，是願意弄明白系統怎樣工作、願意分享發現、也願意讓別人檢驗自己作品的人。這樣的精神曾經推動了互聯網，今天也能推動 Crypto。
我不相信這個行業缺少聰明人，也不相信 Crypto 和 AI 行業找不到支持這項工作的資源。更難的是把人才、資金和持續的責任組織到一起。基金會和有能力的企業，應該願意為那些不直接帶來收入、卻讓所有人受益的基礎工作承擔長期成本。
我希望大家能共同做出一套全球共享的加密基礎設施。不同網絡和團隊能夠在共同的安全約束下協作，各自實現、相互檢驗，用戶能夠選擇和遷移。它可以從一個組件開始，但方向應該足夠大，容得下整個行業共同建設。包括 ArcBlock 在內，參與者都應拿出可以被驗證的貢獻。
我們應當共同建出一種基礎設施：即使某處已經失陷，資產仍有邊界，其他系統仍能拒絕錯誤，用戶仍有恢復和離開的路徑。借用《星球大戰》的名字，這就是我們的 A New Hope。[[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars)希望來自願意行動的普通建設者，也來自 coding agents 與新的工程方式讓他們能夠承擔更多建設工作的這個時刻。
我想向 Ethereum、Solana、Bitcoin、XRP Ledger 等項目的建設者，向 Binance、Coinbase、Kraken 等交易所，也向錢包、協議、安全研究、AI 和雲計算團隊發出邀請：從一個範圍明確的試點開始，共同做出其他團隊也能採用和檢驗的改進。
列名僅作舉例，不分先後。無論規模大小、採用哪條技術路線，都歡迎參與。這份邀請也包括本文批評的技術路線的建設者；共同改善資產安全，值得我們跨過各自生態的邊界。
我自己願意參與，貢獻我們已有的基礎架構、軟件工程與 AI 協作實踐。 我們只是行業里的一支小團隊，能做的有限，希望從一個原型和一組可重復運行的測試開始。
有實際運營經驗的人可以提供經過脫敏的攻擊場景，錢包與協議團隊實現保護，獨立研究者嘗試繞過它。每個團隊承擔力所能及的部分，共同檢驗方案、決定下一步。
我願意參與把本文的資產限制與恢復要求整理成第一份公開 spec，也願意貢獻相關技術和工程實踐，和其他參與者搭起面向這個試點的公共 AI Factory。 先選一個很具體的問題：日常交易鑰匙已經失陷，怎樣讓攻擊者仍然無法把錢包一次掏空？把允許的損失範圍、修改規則的權限和恢復條件寫成驗收測試，再由開發 agents 實現原型，讓另一組 agents 與獨立研究者尋找繞過路徑。數據服務器返回錯誤餘額、設備遺失後的恢復，也可以逐步加入測試。原型做到了甚麼、哪裡失敗、還有哪些依賴，都公開說明，再依據證據決定下一步。
願意參與的人，歡迎在 X 上公開轉發或引用這份倡議，並 @mave99a，說說想解決的問題、經過脫敏的攻擊案例，或能貢獻的資源。我希望討論公開進行，讓更多建設者看到並接著參與。
Crypto 不能再這樣下去。願意一起做的人，讓我們現在就行動起來，從一項做得出來、經得起檢驗的改進開始。
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)，排序機制、不同類型及負面影響；「應作為 bug 修復」是作者對傷害用戶行為的工程主張。 [↩](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)