ERC-8074 自描述字节：往 bytes 参数里塞结构体时贴一个类型标签

智能合约接口里最模糊的一类参数是 bytes：里面可能是一段 ABI 编码的结构体、一段签名、一段序列化配置，甚至什么都不装。调用方和解码方必须靠文档默契对齐，文档缺失或版本错配时，轻则交易 revert，重则把 A 结构当成 B 结构解析成功、静默出错。ERC-8074 的对策很工程化：在 bytes 开头放一个紧凑类型选择器，取自 EIP-712 类型字符串的哈希，让任何拿到字节的程序都能先问一句这是什么再决定怎么解。按照以太坊 ercs 仓库的记录，这份提案名为 Self-Describing Bytes via EIP-712 Selectors，状态为 Draft，创建于 2025 年 10 月 30 日。

标签从哪来、放哪儿

标签的生成路径复用 EIP-712 已有的机制：对目标结构体的类型字符串（形如 Struct(type1 field1,type2 field2) 的规范化文本）做哈希，取前若干字节作为选择器。由于 EIP-712 的类型字符串本身就是生态里对结构体的通用身份证，这套标签不需要另建注册表——同一结构在任意合约、任意链上得到同一个选择器。编码规则是选择器前置、后接标准 ABI 载荷；解码方先读选择器、再按对应结构解码。提案同时定义了一个多载荷包装器：一个 bytes 里可以顺序装多个带标签的载荷，附带长度与前缀规则，使一次调用能携带一组异构数据。

这解决的是哪一类真实故障

一类常见的合约层事故可以对照理解。用户调用一个把参数打包进 bytes 的通用接口（聚合器、批量执行、元交易封装都很典型），字段顺序或类型与目标合约预期不一致，而目标合约只是把 bytes 原样转发或按位置解码。如果两侧都遵循 ERC-8074，那么解码在第一步就会因选择器不匹配而失败——错误暴露在最早的环节，而不是以一次内容错位的形式成交。这也是标准描述自描述的价值时的核心逻辑：让兼容性问题显式失败，而不是静默成功。

它不是序列化标准

需要澄清三条边界。第一，载荷内部编码仍是 Solidity ABI，本标准只在外面加标签，不改变字段排列。第二，标签是类型指纹不是校验和——它认结构不认内容，内容对不对仍要合约业务逻辑自己检查。第三，标签冲突的处理交给标准之外的命名规范：两个语义不同但结构完全相同的类型，会算出同一个标签，这类歧义要靠约定类型命名或字段填充来避免。所以对读代码的人，选择器匹配只意味着我们说是同一个东西这个约定成立，不代表数据合法。

会先在哪里落地

从钱包弹窗看采用的真实收益

假设元交易工具全面采用这套标签，用户侧最直接的收益是签名预览的质量跃迁：钱包读到选择器认出载荷类型，就能把一笔多调用批量渲染成转 A 币给某地址、领某 NFT、撤销某授权这样的人话清单，而不是五个不可读的 bytes 块。反过来说，这也是检验某个聚合器是否真用了标准的试金石——同一个批量操作，在老实实现里预览应当逐项可读，在贴牌实现里你只会看到一串十六进制。开发者社区的采用路径也大体类似历史上其他编码约定：先在类型化签名库与开发框架里出现，再由钱包跟进渲染，最后才轮到普通用户感受到差异。评估自己使用的工具处于哪一阶段，办法就是拿一次复杂批量调用去对比预览粒度，眼见为实。

这类底层编码约定不太会出现在面向用户的产品说明里，它的落地点在接口库与工具链：元交易包装器、跨合约批量执行、钱包的安全预览（钱包若能认出 bytes 里的类型，才谈得上把它渲染成人话）。判断一个采用该约定的生态是否成熟，可以看一条：调试工具能否在遇到未知标签时给出明确提示而不是猜。若可以，说明标签集有索引、维护真实存在；若不可以，采用多半只停留在库函数层面。按 ercs 仓库口径该提案为 Draft，属实现约定层草案。本文为机制说明，不构成任何投资建议。