加密货币史上最大盗窃案——Bybit以太坊冷钱包被盗15亿美元——不是零日漏洞，也不是私钥泄露。这笔交易由多位持有硬件钱包的授权签名者批准，他们当时根本不清楚自己在批准什么。同样模式，也就是盲签，还让Radiant Capital损失5000万美元，Drift Protocol也被攻击。2026年5月12日，以太坊基金会联合多家厂商工作组推出Clear Signing这一开放标准，直指这一致命缺陷。对于在以太坊上搭建应用、写Solidity合约或发布dApp的开发者，这将是今年必须吃透的关键安全基础设施升级。
在硬件钱包上授权交易时，设备接收到的是原始调用数据，一串十六进制字符串，然后要求用户确认。举个例子，这是目前在硬件钱包上看到的、一个Safe多签钱包包装Aave v3存入1 USDC的片段：
0x6a76120200000000000000000000000087870bca3f3fd6335c3f4ce8392d69350b4fa4e2
00000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000001400000000000
……后面还有几百字节。要解读这段数据，用户得解析四字节函数选择器，从合约的ABI中查找函数名，按ABI类型解码每个参数，解析代币地址和ENS域名，还要结合合约状态推理调用的实际效果。一个熟练的工程师在工位上借助工具、花些时间可以完成这些步骤。但一个多签签名者在一块三行OLED屏幕、顶着压力操作时，无论如何也做不到。
业内最初的对策是将十六进制替换为更可读的短语，比如“向vitalik.eth发送100 USDC”。不过，要让这种形式既安全又不仅止于用户友好，远比看上去复杂得多。很多人会想，拥有ABI不就能解码了吗？拿到ABI之后，可以把字节流解码成类似execTransaction(0x87870Bca..., 0, 0x617ba037..., ...)的形式，再把每个参数展示出来。但这套方案依然有两个致命缺陷。
第一，函数名会误导人。Solidity允许开发者随意给函数命名。一个合约可以把提款函数命名为deposit，把恶意升级叫pause，把资金抽取例程叫作claimRewards。如果钱包只是根据函数名来判断意图，那任何合约部署者都可以为你的钱包定义任意意图。第二，参数缺乏语义上下文。一个uint256 amount只是一个数字。它到底代表Wei？还是带6位小数的微USDC？是时间戳？以秒为单位的持续时长？或者是基点费用？没有协议专属知识，“amount: 1000000”不过是一串没那么吓人的十六进制而已。ABI提供的是类型，不是语义。ABI解码给出了一个更可读的十六进制版本，却没有提供一个真实的版本。正是这个差别，导致了Bybit和Radiant Capital的巨额失窃。
Clear Signing协议栈正是为此而生。它不再让硬件钱包去猜测交易意图，而是由dApp在签名前先行计算交易的真实影响，并将结构化的、带语义的摘要发送给钱包。这个摘要不是合约自己声称的，而是由协议层根据链上状态和经过验证的合约接口生成。硬件钱包则只负责展示这些可信的摘要，签名者看到的是“从Aave v3提取1000 USDC至0x...”之类的明确信息，而不是不可辨识的十六进制串。这种端到端的意图验证，把交易授权的安全边界从“相信合约说辞”拉到了“验证可计算的事实”上。
对于构建以太坊应用的团队来说，这意味着需要在合约层面注册描述符，并在调用时附加清晰的元数据。标准工作组已经提供了Solidity库和前端SDK，让适配成本尽可能低。同时，Clear Signing不强制所有交易都走新流程，而是为高风险操作（比如资金转移、合约升级、权限变更）提供一道必过的清晰签名检查。可以说，它正在补齐以太坊交易签名链上缺失的那一环：让签名者真正知道自己签了什么。从15亿美元的教训出发，这或许是近些年最不性感但却最急迫的基础设施升级。
热门跟贴