EIP-7808 解读：为 Rollup 改进提案（RIP）预留 EIP-2718 交易类型区间
EIP-7808 解读为 Rollup 改进提案RIP预留 EIP-2718 交易类型区间【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7808 是一份 Meta 类型的以太坊改进提案它把 EIP-2718 类型化交易信封Typed Transaction Envelope中0x40到0x7f的交易类型区间整体划拨给 Rollup 改进提案Rollup Improvement ProposalRIP流程使用。通过本文你将理解交易类型命名空间TransactionType namespace的由来与边界、EIP 与 RIP 两大提案流程如何共享这一空间而不互相冲突以及这一区间预留治理模式与预编译地址预留EIP-7587之间的呼应关系。本文以仓库中 EIPS/eip-7808.md 为骨架结合 EIP-2718、EIP-7587 等关联文档展开。提案概览一份为 L2 生态划定命名空间的 Meta EIPEIP-7808 的标题是Reserve Tx-Type Range for RIPs为 RIP 预留交易类型区间其描述直截了当为 RIP 流程预留交易类型区间供其使用。提案由 Carl Beekhuizen、Yoav Weiss 与 Ansgar Dietrichs 共同撰写创建于 2024-11-04当前状态为Stagnant停滞类型为Meta并声明依赖requiresEIP-2718。从 EIP 分类体系看Meta 类提案是仍需要某种共识的杂项改进它不直接修改共识协议本身而是规范 EIP 流程与命名空间的治理方式。EIP-7808 正是这样的定位它不引入新的交易类型而是为谁来分配交易类型编号划定清晰边界让 L2Layer 2二层网络通过 RIP 流程发展的新交易类型不会与 L1 主网的 EIP 交易类型发生编号冲突。背景基石EIP-2718 类型化交易信封与 TransactionType 命名空间要理解 EIP-7808 划拨的0x40–0x7f区间必须先回到它的依赖 EIP-2718 Typed Transaction Envelope状态 FinalCore 类。EIP-2718 提出了类型化交易信封格式TransactionType || TransactionPayload其中||表示字节/字节数组的拼接操作符TransactionType是一个介于0与0x7f之间的正无符号 8 位整数标识交易的格式TransactionPayload则是不透明字节数组其解释取决于TransactionType由未来的 EIP 定义。交易收据Receipt同样遵循TransactionType || ReceiptPayload格式且收据的TransactionType必须与同索引交易的TransactionType一致。EIP-2718 之所以把上限设定在0x7fRationale 部分给出了两个关键理由避免与传统交易冲突Legacy传统RLP 编码交易总是以 0xc0的字节开头因此[0, 0x7f]区间可以安全地用于标识新交易类型客户端仅凭首字节即可区分两者为未来扩展留白0x7f之上还保留了高位置位continuation bit等扩展思路而0xff被保留作为未来的扩展哨兵值extension sentinel。从 EIP-6404 中也可以看到该文档将TransactionType明确描述为EIP-2718 交易类型范围[0x00, 0x7F]即整个 EIP-2718 命名空间共有 128 个可用编号0x00–0x7f。当前已分配的交易类型速览结合仓库内各标准文档EIP-2718 命名空间低端已被逐步占用主要分布如下交易类型对应标准说明0x00Legacy传统 RLP 交易非类型化信封0x01EIP-2930带访问列表的交易Optional access lists0x02EIP-1559引入优先费机制的 Type-2 交易0x03EIP-4844Blob 携带交易Proto-Danksharding见 EIP-8142 的定义0x04EIP-7377迁移交易的TransactionType为0x04见 eip-7377.md0x05EIP-7702账户授权authorization交易0x06EIP-8164原生密钥账户native-key accounts交易类型见 eip-8164.md这组已占用编号全部落在0x00–0x06的低端区间为后续 EIP 预留了从0x07起的大量低端编号同时也让0x40–0x7f的高端区间在语义上天然适合整体划拨给另一套流程。动机L2 需要自己的交易类型编号空间EIP-7808 的 Motivation 部分陈述了核心动机为了让 L2 能够使用新的交易类型有必要为 RIP 流程预留一个交易类型区间以确保 RIP 与 EIP 各自使用的交易类型之间不发生冲突。随着 Rollup 生态成熟越来越多的 L2 希望在自己的链上引入 EIP-2718 类型化交易——例如为特定 Rollup 定制的费用模型、账户抽象方案或数据可用性优化。若这些 L2 交易类型与 L1 主网上的 EIP 交易类型编号重叠就会引发两类问题语义冲突同一TransactionType编号在不同链上代表完全不同的交易格式导致跨链工具、钱包与浏览器难以正确解析治理混乱EIP 流程需要为并非在主网使用的交易类型维护注册表负担沉重且责任边界模糊。RIPRollup Improvement Proposal是面向 Rollup 生态的改进提案流程其目标是让 L2 以类似 EIP 的方式标准化各自链上的改进。EIP-7808 正是为 RIP 流程划出独立编号空间从源头杜绝上述冲突。规范预留0x40至0x7f区间含两端EIP-7808 的 Specification 只有一条言简意赅交易类型由 EIP-2718 定义中从0x40到0x7f含两端的区间预留给 RIP 流程使用。这一区间共包含多少个编号0x40即十进制 640x7f即十进制 127因此0x40–0x7f恰好是 64 个交易类型编号127 − 64 1 64。结合 EIP-2718 的完整命名空间[0x00, 0x7f]共 128 个编号EIP-7808 的划分结果是区间数量归属0x00–0x3f64 个EIP 流程含已分配的0x01–0x060x40–0x7f64 个RIP 流程预留给 Rollup 生态也就是说EIP 与 RIP 两大流程在 EIP-2718 命名空间中各占半壁江山互不侵犯。EIP 流程仍保有 64 个类型编号用于自身发展同时无需再为 RIP 使用的类型维护注册表。Rationale划清边界各司其职EIP-7808 的 Rationale 解释了为什么选择预留区间而非其他方案通过为 RIP 预留交易类型区间RIP 流程得以维护自己的交易类型注册表这些类型不必necessarily在 L1 主网使用与此同时EIP 流程从维护 RIP 交易类型注册表的负担中解放出来同时仍保有 64 个交易类型编号供自身使用。这段表述揭示了预留区间模式的两个核心价值注册表职责分离L1 与 L2 的交易类型生态差异巨大硬要让 EIP 流程统一管理既不符合实际很多 RIP 类型永远不会在主网部署也会拖慢两条线的演进节奏。划区之后RIP 流程自行管理0x40–0x7f的分配EIP 流程只需管理0x00–0x3f。对称的自治空间两端各 64 个编号的设计保证了两套流程都有充足的长期发展空间短期内不会触碰边界。与 EIP-7587 的呼应同一种治理模式的两次实践值得特别指出的是EIP-7808 并非孤例它与姊妹提案 EIP-7587 Reserve Precompile Address Range for RIPs状态 Final采用了完全相同的治理思路只是作用对象不同EIP-7587将0x0000000000000000000000000000000000000100至0x00000000000000000000000000000000000001ff的预编译地址区间预留给 RIP 流程共 256 个地址其依据是 EIP-1352 将0x0000–0xffff划为预编译/系统合约保留地址区。EIP 流程仍保有 255 个预编译地址。EIP-7808将0x40–0x7f的交易类型区间预留给 RIP 流程其依据是 EIP-2718 的[0, 0x7f]命名空间。EIP 流程仍保有 64 个交易类型编号。两者叠加构成了 RIP 在 L2 上部署新原语precompile 与 transaction type时所需的完整命名空间保障。这种区间预留已成为仓库中 RIP 相关提案遵循的既定事实例如 EIP-8052Falcon 预编译在确定预编译地址时就明确避开 EIP-7587 为 RIP 预留的0x0100–0x01FF区间。同理未来任何新的 EIP 若引入交易类型都应避开0x40–0x7f区间。向后兼容性与安全考量EIP-7808 对向后兼容性的评估为未发现向后兼容问题No backward compatibility issues found。这一结论是合理的预留区间本身不改变任何交易格式、区块结构或客户端行为它只是编号分配层面的约定截至提案发布2024-11已分配的交易类型0x01–0x06全部位于0x00–0x3f低端0x40–0x7f区间尚无任何 EIP 占用划拨出去不会影响存量标准与 EIP-7587 不同EIP-7808 不需要修改 EIP-1352 那样的基础地址约定因此兼容性风险更低。安全考量方面提案给出的是 Nil无。从协议安全角度也可以印证交易类型编号本身只是信封标识其安全性主要取决于各类型交易的签名与载荷设计EIP-2718 强烈建议将TransactionType作为签名数据的首字节以防签名重用编号归属权划分并不引入新的攻击面。实践启示如何遵循 EIP-7808 的约定对开发者而言EIP-7808 提供了三条可直接落地的行动准则提出新的 L1 交易类型 EIP 时优先使用0x07之后的低端编号且不要占用0x40–0x7f区间把高端区间留给 RIP 生态为 Rollup 设计交易类型时应在0x40–0x7f内选择编号并通过 RIP 流程注册避免与 L1 类型冲突实现客户端/工具时解析TransactionType首字节时可依据区间归属判断其语义来源——[0x00, 0x3f]对应 EIP 流程[0x40, 0x7f]对应 RIP 流程 0xc0为传统 RLP 交易依据 EIP-2718 的向后兼容性说明。总结EIP-7808 用一条简洁的规范——将 EIP-2718 命名空间中的0x40–0x7f共 64 个编号预留给 RIP 流程——解决了 L1 与 L2 交易类型编号的治理冲突问题。它与 EIP-7587 一起构成了 RIP 生态在交易类型与预编译地址两大命名空间上的自治基础。虽然该提案当前处于 Stagnant 状态其区间预留、注册表分离的设计思路已被后续提案如 EIP-8052实际遵循是理解以太坊与 Rollup 生态如何共享基础设施命名空间的必读材料。本文基于仓库内 EIPS/eip-7808.md 编写关联文档与源码依据见 EIPS/eip-2718.md、EIPS/eip-7587.md、EIPS/eip-1352.md、EIPS/eip-6404.md、EIPS/eip-7377.md 与 EIPS/eip-8164.md。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考