作者：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) 下一步要追问的是，投入能否转化成其他团队也能采用和检查的公共基础。

这七项工作都不能保证绝对安全。它们要交付的是可检查的边界：在什么权限失陷的条件下，资产最多暴露多少，异常多久能被发现，恢复还依赖谁。

AI 赋能的软件工程：我们的 A New Hope

读到这里，可能有人会说：方向听起来都对，但行业已经走了这么多年，重构需要多少人、多少时间？这不还是理想主义吗？

如果仍按过去的软件生产方式估算，这个疑问非常现实。但到了 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)