类型爆炸的隐痛
以太坊的交易类型体系靠 EIP-2718 撑起：每种新能力诞生一个新的顶层类型号——blob 交易是一个类型，带授权列表的是另一个类型。问题在于组合：一个用户同时想要通行密钥签名、blob 费和 set-code 授权时，按老路子只能再造一个把前面几个字段全抄一遍的新类型，N 项能力两两组合会炸出指数级个类型号。EIP-8202（2026年3月起草，Draft 状态）提出一个收敛方案：类型 0x05 的 SchemedTransaction，一份 EIP-1559 风格的费头加一份 to/value/data 执行载荷，其余能力全部以扁平组件的形式挂在两个列表里——授权（authorizations）和扩展（extensions），不再递归嵌套交易。
签名方案成为一种能力
这份提案最核心的词是”方案敏捷”：谁能签名、用什么签，本身被建模为授权能力而不是交易种类。首发定义了一个顶层授权角色 SENDER 和两种签名方案：经典的 secp256k1 ECDSA，以及一次性密钥版 secp256k1——后者的地址由整串密钥序列的 Merkle 根派生，密钥轮换后身份地址保持稳定，为需要前向安全的场景留了位置。为不同方案派生非 secp256k1 地址时，方案编号会被哈希进地址，防止两套方案在不同算法下撞出同一个 20 字节地址。经典 secp256k1 的地址派生规则则原样保留，存量地址不受任何影响。
扩展怎么挂
两个初始扩展对应两坨已有的复杂性：blob 扩展直接携带 EIP-4844 的交易局部 blob 字段；set-code 扩展携带 EIP-7702 风格的执行前授权。扩展按 ID 去重、平铺挂载，未来还能继续加——提案举例说 EIP-8141 式的执行帧也可以作为扩展挂上同一个信封，而不必再发明顶层类型。验证逻辑因此可以一遍过：先验外层、再逐组件验能力，不需要处理”交易套交易”的递归结构。
快速问答
问：这是不是又一个造新类型的提案？ 答：恰恰相反，它立论就是”停止为组合造顶层类型”——0x05 大概率是最后一批大信封之一，后续能力进扩展注册表。
问：跟抗量子迁移有什么关系？ 答：方案注册表天然是迁移轨道：新增一种抗量子签名方案等于注册新 scheme_id，钱包可按地址持有的能力渐进切换，而不必等一个把签名算法焊死的硬分叉。
一笔对照账
设想三种能力：通行密钥、blob、set-code。按现状至少需要枚举 2 的 3 次方减 1 共 7 个组合场景来决定交易类型；按 0x05 的写法，是一个信封、三个组件，组合矩阵从协议层挪进注册表。维护成本从每加一能力乘以类型数，降为查一次表。
为什么先做加法再做减法
回看 EIP-2718 的历史，交易类型编号本意是解耦：每个类型一个号，客户端按号分发解析。实践中类型号渐渐被理解为”产品版本号”，用户与工具问的却是”支持不支持我的组合”。EIP-8202 的选择是把分发单位从”类型号”改成”能力集合”：验证者先看 0x05 信封，再依次核对费头、执行载荷、授权列表与扩展列表。对钱包开发者，多出来的工作量是本地要维护一份 scheme 与 extension 的注册表镜像；对协议维护者，换来的是新增能力走注册流程而不是走顶层类型的社交动员。注册表机制与 EIP-7932 签名方案注册表的思路一致，两份提案在文档里互相引用，能否同期推进仍是变数——这也是读组合类提案必须留意的依赖关系：能力模型的落地速度取决于最慢的那块拼图。
一个容易忽略的细节
方案注册对地址学还有一个连锁反应值得点名：以太坊地址本是公钥哈希的后二十字节，跨算法复用时，两把不同算法的公钥理论上可能哈希出同一地址。把方案编号哈希进非经典算法的地址派生，等于给每种算法划出互不相交的地址空间——老地址继续属于 secp256k1，新算法的产物不会与它重合。这类”算法域分离”的做法在签名与哈希标准里早有惯例（例如不同上下文的域分隔前缀），EIP-8202 把它搬进地址派生，是组合安全的地基，比任何性能数字更值得先读懂。
风险提示：本文为协议提案的科普介绍，EIP-8202 截至撰写时未在主网激活，字段与注册表细节以提案原文为准；不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。