从钱包导出原始交易时，第一眼看是十六进制 RLP 列表、还是开头一个 02 或 03 的小字节，等于在给这笔交易断代：后者就坐在 EIP-2718 定义的封套格式上。这份 2020 年 6 月提出的规范没有发明任何新交易，它只干了一件事——宣布交易长什么样子由第一个字节说了算，其余格式留给未来的 EIP 自由填写。此后 1559 定价交易、blob 交易能各起炉灶互不打架，靠的都是这层薄封套。
封套之前：兼容是比特层面的难题
规范动机部分回忆了旧日子。早年每加一种交易，都必须保证编码后的字节串在旧客户端眼里不可能被误认成已有类型，最典型的例子是 EIP-155 把链标识符 bit 打包进 v 字段这种抠门操作。当链上同时排着队——让普通账户直接执行代码的类型、让别人代付 gas 的类型、账户抽象相关类型——每种都要设计一套与所有其他提案互不碰撞的编码，这套约束对提案作者是负担，对同时实现多种类型的客户端软件更是灾难。封套把这个 NP 问题换成一个更简单的登记问题：格式差异集中到类型编号，客户端按号分发即可。
格式定义与首字节划界
按规范正文：交易是 TransactionType 拼接 TransactionPayload，或者干脆就是原样的旧式交易；Receipt 同理。类型编号是 0 到 0x7f 之间的无符号整数，载荷是按类型解释的不透明字节数组，具体定义留给后续 EIP。首字节怎么做到新旧一眼分开？旧式交易的 RLP 列表首字节必然落在 0xc0 到 0xfe 区间，新类型全部在 0x7f 以下，两个区间不重叠；0xff 被留作未来的扩展哨兵。区块头里的交易树和回执树都要求按索引存对应的封套形式，且回执的类型必须与同索引交易的类型一致——这条一致性检查堵住了打包器在不同树上做手脚的空间。类型编号上限停在 0x7f 的理由也很务实：给高位留出扩展余地，顺便避开与 RLP 开头的碰撞。
签名必须把类型签进去
规范用 SHOULD 强调：所有新交易类型的签名，都应把类型字节作为被签数据的第一字节。安全考量部分说得更重——强烈建议这么做，否则同一份签名可能跨类型串用。设想载荷编码恰好兼容两种类型解释的极端情形：一笔为 A 类型签好的交易，换个解析器就能以 B 类型的身份执行，权限与资金语义完全错位。把类型编号烧进签名哈希后，跨类型重放从设计层面被关死。后来的 EIP-1559 为 2 号交易定义的签名、blob 交易为 3 号交易设计的签名，都严格继承这条纪律。
生态影响：登记编号的时代
封套生效之后，新增交易类型的成本结构变了：提案者不再需要发明防碰撞编码，只需要声明一个新编号并保证载荷自描述。EIP-2718 随 2021 年的柏林升级进入以太坊主网，同年稍晚的伦敦升级激活了坐在封套之上的 EIP-1559，之后各条兼容链的分叉几乎全盘保留这套框架——钱包解析交易字节流时按首字节分发，已经是行业默认动作。顺带一提，签名领域的孪生问题是链标识与交易序号，分别在 EIP-155 和账户 nonce 规则里解决，与封套各司其职：链标识防止一条签名在别的链上重放，序号防止同一笔在自己链上被反复执行，封套则管同一链内不同类型间的串用，三者叠加才凑齐一笔交易的防重放边界。读交易原始数据、排查跨链工具的解析报错时，回到这张首字节地图通常就能定位问题：首字节落在 RLP 区间就是旧式交易，落在低位区间则按登记表找对应 EIP 的载荷定义。本文只谈格式标准，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。