Blob 上也能验签名：ERC-8180 认证消息的分层注册

坎昆升级之后的 Blob 空间便宜得快，越来越多协议把数据往那里放。但 Blob 里只有字节，谁写的、可不可信，没有任何内建答案。ERC-8180（Blob Authenticated Messaging）想补的正是这一环：让 Blob 里的消息可以被任何读取者验证“确实由某地址签发”。按 ercs 仓库记录，提案状态为 Draft（草稿），创建于 2026 年 2 月 21 日，建立在 EIP-4844 与 ERC-8179（Blob 空间分段）之上。

解码与验签分家

这套标准最核心的设计决策，是把“把字节变成消息”和“证明消息是谁发的”拆给两个合约。解码器是一个不受信的链上合约，负责从载荷里提取消息结构；签名登记处是一个受信合约，负责验证签名。规范把理由写得很直白：坏掉或恶意的解码器造不出冒充他人的效果——它顶多产出错误消息，而这些消息过不了受信登记处的签名验证。接口因此分三块：IERC_BAM_Core 提供 registerBlobBatch 与 registerCalldataBatch（以及批量版本 registerBlobBatches），登记一批消息及其所在 Blob 段坐标、解码器地址、登记处地址；IERC_BAM_Decoder 只有一个 decode(payload)；IERC_BAM_SignatureRegistry 报告签名方案（schemeId、schemeName、密钥与签名长度），支持公钥注册（带存在性证明 popProof）、getKey 查询、verify 与 verifyWithRegisteredKey 验证，还能声明是否支持聚合签名。

calldata 与 Blob 双通道

注册函数同时提供 calldata 版本，这不是装饰：同一条消息可以按需放进昂贵的 calldata 或便宜的 Blob，消费者用同一套接口读取，只是段坐标不同。对 Layer2 排序器、跨链中继、活动公告这类高频小消息，这提供了成本分层空间——大额关键公告走 calldata 求长久可得，海量日常消息走 Blob 省钱，验证语义保持一致。

信任的账本该记在哪

读这份标准时要把三本账分开。解码器：不受信，但要选公开可审的实现，它错误只污染可读性。登记处：受信中枢，谁的公钥算谁的、密钥怎么轮换、有没有作弊惩罚，全看登记处实现——规范提供了注册接口，没有规定治理。签名方案：聚合签名一类的优化会改变验证成本与失败模式，supportsAggregation 返回 true 不等于你可以不看方案细节。还有一个容易被忽略的事实：Blob 数据有保留期，过期之后节点不再保存原始载荷，届时“认证消息”的可重读性取决于有没有人把数据留档——ERC-8180 管验证，不管永久归档。

对普通用户意味着什么

签名域与所有权证明

链编号被编进了签名域：消息签名按 keccak256(abi.encodePacked("ERC-BAM.v1", chainId)) 构造域分隔符，A 链上签发的消息在 B 链重放会直接失效。密钥注册环节强制附带“所有权证明”——注册者要用私钥签一份证明回执，防止在 BLS 类聚合方案里用他人公钥冒充的 rogue key 攻击；register 在证明无效时必须以 InvalidProofOfPossession 回滚。规范还留了一个诚实的边角：同一把公钥允许被两个地址同时注册——两者都能交出所有权证明——要不要限制由登记处自己的政策决定。把这两处细节合起来读：验证链上消息的“链身份”“签名者身份”各自都有一道闸，而闸的钥匙在登记处的治理手里，不在接口文本里。

读档与验证是两件事

对数据消费者还要补一句：Blob 有保留期，过期后共识节点不再保存原始载荷，链上留下的批登记与坐标只是“曾经存在”的证据。届时重读消息要靠留档服务或该协议的自建网关，重放一遍解码与验签才能重建内容。换句话说，ERC-8180 给的是验证路径，不是保管义务——评估任何“数据上链”宣传时，“链上多久之后还能不能读回原文”是必须单独追问的一项。

这份 2026 年的草案主要服务于协议与工具开发者，普通用户暂时不会直接调用它。但它预示的读法值得提前养成：以后看到“链上可验证的公告/证明/名单”，可以多问一句它宣称走哪条路径——事件日志、calldata 还是 Blob 加登记处；有没有公开的解码器与登记处地址；数据过期后去哪个存档站重读。可验证性的每一层都是具体合约，而不是“上了链”三个字。验证永远发生在读的一方手里，标准只负责让你读得起。本文为机制说明，不构成任何投资建议。