ERC-8213让每一次签名都“可验证”引言2026年Bybit被盗14亿美元WazirX损失2亿美元Radiant Capital被黑5000万美元。这些攻击有一个惊人的共同点用户签署了他们实际上无法验证的交易。硬件钱包显示的是长达数百字符的原始十六进制calldata或者EIP-712结构体分散在几十个屏幕上。用户面临一个不可能的选择逐字符比对或者盲目信任。ERC-8213的出现正是因为行业在“盲目信任”这条路上走得太远代价已经摆在了桌面上。这个标准并不承诺让每一笔交易都变得“人类可读”。它做了一件更根本的事给用户一个机会去验证他们正在签署什么——无论他们使用的网站是否已被入侵。一、ERC-8213 标准化了什么ERC-8213定义了五个具有精确规范名称的密码学摘要Digest1. ERC-191 DigestERC-191摘要即personal_sign消息的哈希值ERC-191 Digest keccak256(\x19Ethereum Signed Message:\n || len(message) || message)这是最终被签名的那条消息的哈希。2. EIP-712 DigestEIP-712摘要即ECDSA签名者实际签署的EIP-712 typed data的哈希值EIP-712 Digest keccak256(\x19\x01 || domainSeparator || hashStruct(message))这是EIP-712签名中“最终被签名”的那个值。3. Domain Hash域哈希Domain Hash hashStruct(eip712Domain)DApp声称身份的指纹。4. Message Hash消息哈希Message Hash hashStruct(message)被签名的结构化消息本身的指纹。5. Calldata DigestCalldata摘要这是ERC-8213引入的新概念——交易calldata的摘要Calldata Digest keccak256(uint256(len(calldata)) || calldata)其中len(calldata)是calldata的字节长度编码为32字节的大端序uint256。特别注意Calldata Digest故意不包含 chainId或其他交易信封字段。这意味着相同的calldata在任何链上、任何时候产生的摘要都是一样的。二、核心价值为什么这很重要2.1 不依赖信任的验证路径ERC-8213最核心的价值在于用户可以用独立的设备、脚本或工具自行计算这些摘要然后与钱包显示的值进行比对。如果匹配说明交易载荷与用户预期签署的内容字节级完全一致如果不匹配说明数据已被篡改——无论篡改来自被入侵的网站、恶意的浏览器扩展还是中间人攻击。对于管理数百万美元的金库来说这不是一个“便利功能”而是一个安全需求。2.2 终结术语混乱当前生态中的术语是混乱的。OpenZeppelin称之为“typed data hash”Safe{Wallet}在不同上下文中使用safeTxHash、SafeMessageHash、safeMessageMessage等不同名称。ERC-8213给了整个生态一套共享的词汇表。当每个钱包都显示“EIP-712 Digest”和“Calldata Digest”时用户和开发者可以无歧义地沟通他们在签署什么。在安全关键场景中术语不清本身就是一种错误向量。2.3 ERC-7730的补充而非替代ERC-7730通过JSON描述符提供了人类可读的交易展示路径。但ERC-7730无法覆盖所有场景新部署的未验证合约、闭源合约、无法通过ABI解码的自定义打包编码、无法获取链下元数据的离线硬件钱包。ERC-8213就是所有这些场景的字节级后备方案。ERC-7730说“这笔交易用大白话来说是这样的”ERC-8213说“这是一个你可以独立验证的短指纹”。它们是互补的不是竞争的。三、代码实现到底有多简单这是ERC-8213最让人欣赏的一点——实现复杂度极低。以下是用TypeScript基于viem实现Calldata Digest的完整代码import{keccak256}fromviemfunctioncalldataDigest(calldata:0x${string}):0x${string}{constbyteshexToBytes(calldata)constlengthbytes.lengthconstlengthPrefixednewUint8Array(4length)// 大端序 uint256 表示长度constviewnewDataView(lengthPrefixed.buffer)view.setUint32(0,length,false)lengthPrefixed.set(bytes,4)returnkeccak256(lengthPrefixed)}EIP-712 Digest同样直接functioneip712Digest(domainSeparator:0x${string},hashStruct:0x${string}):0x${string}{constprefix0x1901returnkeccak256(concat(prefix,domainSeparator,hashStruct))}任何已经实现了EIP-712和ERC-191的钱包都可以用极少的额外代码来计算这些摘要。为了确保跨库的一致性官方仓库还提供了与cyfrin/chain-toolsethers实现的交叉验证测试确保两个库对相同输入产生字节级完全一致的输出。四、生态影响4.1 对钱包开发者对钱包实现者来说ERC-8213的采用门槛很低。计算只是简单的keccak256哈希。真正的工作不在计算层面而在UI设计——钱包需要决定在哪里以及如何展示这些摘要。提案建议将Calldata Digest放在钱包界面的底部。但好的UX不只是把哈希“甩”到屏幕上。用户需要知道摘要代表什么、如何验证、以及为什么这很重要。4.2 对安全工具生态ERC-8213开启了一类全新的验证工具。独立的摘要计算器可以作为浏览器扩展、命令行工具或移动应用构建。多签签名者可以通过跨设备比对摘要来协调签名。安全审计人员可以将摘要验证纳入工作流。4.3 对用户教育这是最难的部分。ERC-8213不是让所有人都能安全交易的“魔法子弹”。它是给有安全意识、理解密码学摘要是什么以及为什么重要的用户使用的工具。标准文档本身针对四类受众好奇的用户、钱包开发者、签名者、数学爱好者。行业需要对这一局限性保持诚实。ERC-8213解决的是可验证性问题不是可用性问题。这是两件不同的事。五、关键弱点与挑战5.1 人的因素密码学摘要仍然是32字节的十六进制字符串。比对两个64字符的字符串不是大多数用户会做、甚至知道如何做的事。标准自己也承认“许多用户甚至懒得检查calldata”。ERC-8213让验证变得可能但没有让验证变得容易。要让这个标准发挥真正的价值钱包需要把验证工作流内置到界面中允许用户粘贴预期的摘要、扫描第二台设备上的二维码、或者用 companion app 自动计算和比对摘要。标准提供了密码学基础行业需要在之上构建用户体验。5.2 采用速度ERC-8213目前是Draft标准。草案标准保护不了用户。钱包必须实现这个标准才能产生价值。大钱包有工程资源会先采用小钱包可能滞后造成碎片化的用户体验。Clear Signing计划2026年5月启动已将ERC-8213作为核心组件多个钱包供应商正在参与。但生态级的采用需要时间在过渡期内标准的好处对大多数用户来说仍是理论上的。5.3 ERC-7730的关系ERC-8213被定位为ERC-7730不可用时的后备方案。这是合理的但也意味着ERC-8213是第二好的选择。用户永远会更喜欢人类可读的交易展示而非密码学摘要。如果ERC-7730的采用变得广泛ERC-8213的使用可能会受限。但这低估了后备方案的重要性。ERC-7730需要合约被验证、元数据可用。对于新合约、未验证合约、自定义打包编码ERC-7730根本无法工作。ERC-8213覆盖了那些永远不会有可读描述符的长尾交易。5.4 哈希碰撞的隐忧社区中有人提出疑问Calldata Digest是否应该包含版本前缀或域特定标签以防止跨协议的哈希碰撞误用。当前规范没有包含这样的前缀。这是一个有意识的设计选择但随着标准在实际场景中的应用这一点值得持续关注。六、可行性及落地场景6.1 多签金库这是最主要的应用场景。管理数百万美元的多签签名者需要在签署前验证每一笔交易。ERC-8213允许每个签名者独立计算摘要并与钱包显示的值比对。如果所有签名者的摘要一致交易即被验证。如果某个签名者看到不同的摘要说明出了问题。6.2 硬件钱包用户硬件钱包是气隙隔离的或有意隔离的。提取calldata进行验证很困难。ERC-8213给硬件钱包用户一个短的摘要可以与独立计算的值比对。硬件钱包直接从USB或蓝牙发送的原始字节计算摘要。6.3 安全审计人员与高级用户审计人员在审查交易时可以将摘要计算纳入工作流。管理个人投资组合的高级用户可以在签署高价值交易前进行验证。标准提供了一条不依赖于信任签名流水线中任何单一组件的验证路径。6.4 DeFi协议交互许多DeFi协议为了节省gas而打包数据导致calldata无法解码。ERC-8213为这些交易提供了验证路径——即使人类可读的解码完全不可能。七、总结ERC-8213不是用户体验的革命。它不会让以太坊交易变得让你的祖母也能读懂。但它做了一件更重要、更可实现的事给用户一个密码学工具来验证他们正在签署什么——不依赖于对任何单一方的信任。这个标准在技术上是扎实的实现复杂度极低解决了一个真实而紧迫的安全问题。近期的交易所黑客事件已经证明盲目签名不是一个抽象威胁而是一个已经让行业损失了数十亿美元的具体漏洞。ERC-8213提供了一个实用的、可落地的缓解方案。弱点确实存在但都是可管理的。用户教育会是一个挑战。采用需要时间。标准不能替代更好的UX。但它提供了一个可以构建更好UX的基础。对钱包开发者来说实现成本低安全收益高。对管理重要价值的用户来说标准提供了一条之前不存在的验证路径。对整个生态来说ERC-8213代表了迈向这样一个未来的一步签署交易不再需要盲目信仰。密码学摘要是短的。验证是可复现的。标准已经准备好了。问题在于生态会在下一个十亿美元级别的黑客攻击发生之前采用它吗参考资源ERC-8213 提案原文https://eip.tools/eip/8213社区讨论https://ethereum-magicians.org/t/erc-8213-wallet-signature-and-calldata-digest-display/24295