EIP-3534 深度解析受限链上下文交易类型Restricted Chain Context Transactions【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-3534 是 Ethereum Improvement Proposal 仓库EIPs中一份状态为Stagnant、类别为 Standards Track / Core 的核心协议提案它基于 EIP-2718 类型化交易信封定义了一种全新的交易类型0x4允许交易通过chainContext字段对祖先区块、区块生产者矿工、区块时间戳等链上下文施加约束。阅读本文后你将完整掌握该交易类型的 RLP 编码结构、四种链上下文子类ancestorId、eligibleMinerList、ineligibleMinerList、expiry的语义与组合规则、校验逻辑以及设计者在chainId冗余、哈希截断安全性等关键问题上的取舍论证。一、提案定位一份受限链上下文核心交易类型提案本文所解析的 eip-3534.md 位于仓库EIPS/目录是一份面向以太坊核心共识协议Core 类别的标准跟踪提案。其元数据信息如下EIP 编号3534标题Restricted Chain Context Type Transactions受限链上下文类型交易作者Isaac Ardiswhilei状态Stagnant停滞即未被采纳推进类型/类别Standards Track / Core创建时间2021-04-20依赖EIP-2718、EIP-2930提案的核心诉求Simple Summary一句话可以概括为定义一种新的交易类型使其能够对祖先区块哈希、区块作者miner和/或区块时间戳施加约束从而让交易有资格进入的链上下文chain context被精确限定。二、抽象0x4类型交易的编码格式与四种上下文子类提案引入一种新的 EIP-2718 交易类型其编码格式为0x4 || rlp([chainId, chainContext, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS])其中0x4即TRANSACTION_TYPE_NUMBER是 EIP-2718 信封格式中的TransactionType||为字节/字节数组拼接运算符。对应的ReceiptPayload为rlp([status, cumulativeGasUsed, logsBloom, logs])新增的chainContext元素对交易的有效性施加约束——交易只有在其链上下文满足所引用的值时才有效。提案定义了该类型的四个上下文子类subclass子类语义segmentId即ancestorId约束交易只能进入以某祖先区块为前缀的链段eligibleMinerList约束包含该交易的区块的受益人beneficiary必须在白名单地址集合中ineligibleMinerList约束包含该交易的区块的受益人不得在黑名单地址集合中expiry约束包含该交易的区块时间戳必须小于给定值过期时间这些上下文可以被任意组合使用被注解的上下文值组合通过chainContext上的一个复合整数前缀ANNOTATION_COMPOSITE_PREFIX来标识。三、动机让交易能够表达与区块链数据的关系约束提案的动机是建立一种基于协议的机制让交易能够明确表达对合格链上下文的约束。从消费者交易发起方视角看这些约束赋予交易描述其与区块链数据及其来源provenance关系的能力具体包括四类诉求将交易适用性限制在当前主观视图下可用且可推理的链上下文——让交易能够表达对其当前链视图的依赖将交易适用性限制在某个先前区块及其交易之后的链上下文——在宏观区块级层面表达祖先依赖间接地只要依赖交易位于不同的区块中就可以让一笔交易依赖另一笔交易的存在将交易适用性限制在使某个偏好/厌恶的矿工地址受益或不受益的区块——为矿工竞争消费者交易创造机会/市场。在现状下从消费者视角看矿工的交易处理服务几乎是完全同质的限制交易的适用时间跨度——提供一种不同于现状的、让交易从交易池txpool中失效/被逐出的替代方式。四、规范Specification4.1 参数FORK_BLOCK_NUMBERTBD待定TRANSACTION_TYPE_NUMBER0x4参见 EIP-2718自FORK_BLOCK_NUMBER起引入一个TransactionType为TRANSACTION_TYPE_NUMBER即0x4的新 EIP-2718 交易。其TransactionPayload与ReceiptPayload如上文所述。4.2 定义chainContext交易仅对满足全部ALL OF注解的区块链数据有效。ANNOTATION_COMPOSITE_PREFIX一个介于1与0xff之间的正整数表示chainContext中子类注解的集合即提供的值应作用于哪些链上下文子类。其值应为各子类ANNOTATION_PREFIX之和。ANNOTATION_PREFIX为各子类定义的、以八进制派生的正整数限定于集合2^0, 2^1, 2^2, 2^3, 2^4, 2^5, 2^6, 2^7即1, 2, 4, 8, 16, 32, 64, 128。chainContext值应具有如下形式ANNOTATION_COMPOSITE_PREFIX || [{subclass value}...]其中...表示左侧元素的零个或多个||为字节/字节数组拼接运算符。最终编码为ANNOTATION_COMPOSITE_PREFIX || rlp[{subclass value}...]4.3 校验Validation下述各子类定义的值构成对特定链上下文下交易有效性的约束。交易若定义了其链上下文不满足的约束则应被判定为无效包含无效交易的区块按现状status quo同样应被判定为无效区块。4.4 子类组合Subclass Combination当chainContext注解了多个子类引用时各值必须按以下顺序提供ANCESTOR_IDELIGIBLE_MINER_LISTINELIGIBLE_MINER_LISTEXPIRY同时ANNOTATION_COMPOSITE_PREFIX应为所指定子类ANNOTATION_PREFIX的和。4.5 四个子类的完整规格ancestorId祖先区块 IDANNOTATION_PREFIX1ANCESTOR_IDbytes长度为 4 至 12 字节的字节数组ANCESTOR_ID通过拼接区块号block number的字节表示与该区块哈希的前 4 字节来引用一个特定区块区块号应以大端序big endian编码且应移除左侧填充的 0当引用创世区块时区块号部分可以省略ANCESTOR_ID值应被 RLP 编码为字节数组用于哈希与传输。eligibleMinerList合格矿工白名单ANNOTATION_PREFIX2ELIGIBLE_MINER_LIST[address...]地址列表MAX_ELEMENTS3可提供的地址最大数量ELIGIBLE_MINER_LIST是唯一、有效地址的数组。任何包含使用该值交易的区块其区块受益人block beneficiary必须包含在此集合中。值的类型为[{20 bytes}]表示左侧元素的一个或多个不允许重复值。该值应 RLP 编码后用于哈希与传输。ELIGIBLE_MINER_LIST值不得与INELIGIBLE_MINER_LIST值相邻出现。ineligibleMinerList不合格矿工黑名单ANNOTATION_PREFIX4INELIGIBLE_MINER_LIST[address...]地址列表MAX_ELEMENTS3INELIGIBLE_MINER_LIST是唯一、有效地址的数组。任何包含使用该值交易的区块其区块受益人不得包含在此集合中。类型同样为[{20 bytes}]不允许重复值应 RLP 编码后用于哈希与传输。INELIGIBLE_MINER_LIST值不得与ELIGIBLE_MINER_LIST值相邻出现。expiry过期时间ANNOTATION_PREFIX8EXPIRYinteger一个正的、无符号标量EXPIRY是一个标量等于包含该交易的区块的最大有效timestamp。该值应作为整数 RLP 编码后用于哈希与传输。五、设计理由Rationale深度解读5.1 子类高概念独立性 任意 AND 组合子类被设计为具有高度的概念独立性可以独立于本 EIP 进行修改和/或扩展。它们的规格定义允许任意互斥与AND组合。这一设计意图是在提供一套具体规范的同时保留足够的灵活性以便日后扩展或修改。5.2ANNOTATION_PREFIX八进制派生值的组合术ANNOTATION_PREFIX使用八进制派生值1, 2, 4, 8, 16, 32, 64, 128遵循一种从有限集合中唯一且简洁地表示组合的经典模式例如 Unix 风格的文件权限位。本 EIP 定义了八个可能子类中的四个为未来增长留足了空间。若该上限被触及或超过则因为会改变交易校验方案属于共识协议层面的变更而事实上需要硬分叉届时再修订该方案也只是附带的小事。5.3ancestorId与chainId的冗余关系ancestorId通过引用先前的规范区块按区块号和哈希来约束交易的有效性——交易仅当被包含在以该注解区块为祖先的区块中时有效。实际上被指定的合格链段可以理解为从0..ancestorId含的区块段。该模式可视为 EIP-155 中chainId规范的相关物correlateEIP-155 限制了交易在链之间的适用性交易只能应用于标注了对应 ChainID 的链而ancestorId进一步将交易应用限制在一条链的某个子段。从这一约束层级来看实现ancestorId可以在概念上使chainId变得冗余。那为什么还要保留chainId提案给出五点论证本 EIP 提出的交易类型是可选使用的这意味着chainId在协议基础设施和工具链中对遗留交易和其他交易类型仍有持续的必要性本 EIP 交易类型中的ancestorId也是可选的若 RCC 交易未填充该值则对chainId的需求依然存在chainId对ancestorId并非必然冗余——在分叉导致两条链并存的场景中尤为如此。例如引用区块1_919_999的ancestorId在以太坊Ethereum与以太坊经典Ethereum Classic之间会产生歧义也可以规定在ancestorId被使用时省略chainId但这会增加基础设施复杂度仅仅为了省去chainId通常占用的几个字节设计者认为这笔交易不划算。且chainId参与交易签名方案中v值的计算v,r,s移除或修改它会牵连到比编码字段更底层的复杂度ancestorId的设计并不提供完美精度以换取字节大小的节省在极小的概率下值可能产生歧义此时chainId仍为交易的链特异性提供万无一失的保证。5.4eligibleMinerList/ineligibleMinerList交易仅当被包含在etherbase区块受益人位于注解地址列表中的区块时有效交易仅当被包含在etherbase不在注解地址列表中的区块时有效白名单eligibleMinerList与黑名单ineligibleMinerList并用在逻辑上不一致因此不允许二者并用MAX_ELEMENTS 3的选择是为了在限制交易潜在体积与为用户提供足够的表达能力之间取得平衡。提案写作时以太坊前 3 大矿工按区块计以已知公开地址衡量产出了全部区块的 52%——3 个地址足以覆盖这一头部份额。5.5expiry交易仅当被包含在timestamp小于注解值的区块中时有效。使用正整数是因为它对应区块头中timestamp字段规定的类型。5.6 子类组合的完整推导由于各子类的ANNOTATION_PREFIX基于八进制值在假定注解基数即顺序的前提下它们可以通过求和被区分性地组合。例如前缀1仅ancestorId前缀2仅eligibleMinerList前缀4仅ineligibleMinerList前缀8仅expiry前缀123组合ancestorId与eligibleMinerList前缀145组合ancestorId与ineligibleMinerList前缀189组合ancestorId与expiry前缀12811组合ancestorId、eligibleMinerList与expiry前缀14813组合ancestorId、ineligibleMinerList与expiry前缀246不允许会组合eligibleMinerList与ineligibleMinerList前缀124815不允许会组合eligibleMinerList与ineligibleMinerList以及ancestorId与expiry由于多值时必须且必须遵循既定顺序被注解的引用仍可区分。原文给出两个可读示例chainContext3[e4e1c0e78b1ec3,[Df7D7e053933b5cC24372f878c90E62dADAD5d42]]交易只能被包含在满足以下条件的区块中——存在编号为15_000_000、哈希前缀为字节e78b1ec3的规范祖先区块且包含区块的受益人为Df7D7e053933b5cC24372f878c90E62dADAD5d42。chainContext10[[Df7D7e053933b5cC24372f878c90E62dADAD5d42],1619008030]交易只能被包含在满足以下条件的区块中——以Df7D7e053933b5cC24372f878c90E62dADAD5d42为etherbase受益人且时间戳大于16190080302021-04-21 07:27:10 CDT。注前缀10 2 8即eligibleMinerList与expiry的组合两个值按顺序[ELIGIBLE_MINER_LIST, EXPIRY]排列与 4.4 节规定的顺序一致。5.7 EIP-2930 继承与签名目标提案以 EIP-2930 Optional Access List Type Transaction 作为假定的基座交易类型——唯一的差别在于accessList字段这是与 post-EIP-155 遗留交易字段的唯一差异且该字段可以方便地移除。这是一种非概念性依赖站在 EIP-2930 的肩膀上只是为了支持并推进下一代交易的采用。签名目标方面签名覆盖交易类型0x4以及交易数据本身。这是为了确保交易不能被重新解释为另一种类型的交易与 EIP-2718 中所有未来交易类型的签名都应包含TransactionType作为签名数据的首字节的建议见 eip-2718.md 中All signatures for future transaction types SHOULD include the TransactionType as the first byte of the signed data保持一致。六、向后兼容性提案声明没有已知的向后兼容性问题There are no known backward compatibility issues。七、测试用例ANCESTOR_ID编码向量提案给出了segmentId即ancestorId的核心测试向量验证区块号 区块哈希前 4 字节的拼接编码规则区块号大端序、去左侧填充 0、创世区块可省略区块号Segment IDBlock NumberCanonical Block Hashe78b1ec300xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e5801e78b1ec310xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58e4e1c0e78b1ec315_000_0000xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58e8d4a50fffe78b1ec3999_999_999_9990xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e587fffffffffffffffe78b1ec392233720368547758070xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58可以验证其编码规律创世区块区块号0直接省略区块号只保留哈希前 4 字节e78b1ec3区块号1编码为单字节0115_000_0000xe4e1c0编码为 3 字节e4e1c0最大 64 位整数值92233720368547758070x7fffffffffffffff编码为 8 字节。所有 Segment ID 均以哈希前缀e78b1ec3收尾且整体长度落在 412 字节的规格范围内。原文档注明更多测试用例TODO。八、安全考量Security Considerations8.1 为什么ancestorId只用 4 字节哈希就足够安全TL;DR无效ancestorId即碰撞的几率约为 40 亿分之一到 400 亿分之一之间更大的概率出现在蓄意重复场景如恶意重组中。若碰撞真的发生意味着交易将在两个链段上都有效——这与现状status quo下的情形一致不会引入比现状更糟的结果选择 4 字节而非完整哈希32 字节仅仅是为了减少实现该值所需跨网络传输的信息量。使用完整哈希将得到完美安全的实现而每增加一个字节碰撞概率都呈指数级下降ancestorId的目标是在链段之间做消歧让交易能以足够精度定义其所需链。当交易的ancestorId引用某个区块时需要相当确信该引用不会与交易作者所想的那个区块之外的区块混淆设计者假设碰撞抗性对区块哈希值的所有可能子集均匀适用因此选择前 4 字节是任意的与任何等长子集在功能上等价碰撞概率计算1/(16^8 4_294_967_296)乘以等价编号区块在替代链上存在的概率。假设任一区块存在公开叔块uncle的概率为慷慨的 10%1/10则得到(1/4_294_967_296) * 1/10。注意此估算假设正常的链与网络行为在存在长期并存的竞争链段时该值升至 100%1。8.2eligibleMinerList的生态与经济考量未被列入eligibleMinerList的矿工应预期会立即将该交易从其交易池中移除悲观预期下这些不合格节点也可能不会转发rebroadcast这些交易从而可能影响交易向其目标矿工的传播可用性。另一方面矿工有动力让自己对这类交易的接收保持可达且无论是链上还是链外都有多种实现途径使用eligibleMinerList的交易作者必须接受此类交易的区块链状态数据库一般可用性将低于非受限交易因为只有矿工子集能处理该交易关于白名单矿工的交易处理顺序经济学无白名单的交易乍看更具竞争力、应优先处理。但遵循该策略的矿工可能发现自身声誉受损最坏情况下交易作者的偏好将转向其竞争对手而脱离其掌控。8.3ineligibleMinerList的规避成本除上述eligibleMinerList的担忧外ineligibleMinerList有一个独特问题矿工实体要避免被黑名单排除只需使用一个临时的 adhoc 地址作为区块受益人原则上这是不可避免的。但规避者要承担相关成本创建账户需要时间与精力虽然可以在任何方便的时间与场合完成可能边际成本很小但非零从多个账户转移资金需要相应数量的交易。由于区块奖励在交易处理之后才发放矿工无法在自己挖出的同一区块内将资金从临时账户转移到目标账户否则会是免费交易使用 adhoc 地址规避黑名单时矿工也可能同时失去处理同期白名单交易的资格。8.4 校验成本矿工列表与expiry依赖易于缓存且上下文可用的条件即所在区块头强制执行这些校验的基础设施开销预计可以忽略。而ancestorId的校验要求按区块号断言一次正向数据库命中从而交叉引用存储区块的哈希该查找可以或许已经被缓存但由于查找值是任意的必须预期缓存命中率达不到 100%。不过使用深层ancestorId的交易其边际价值递减因此可以预期大多数使用该字段的交易将使用相对较小、较浅、缓存友好的值集合。8.5 交易体积增加与垃圾交易新增字段可能增加交易体积。这些字段不关联任何 gas 成本即没有协议层面的经济手段来抑制潜在垃圾交易。然而被矿工认为不合意的交易可以直接从交易池中丢弃并忽略。九、提案在 EIP 体系中的坐标与 EIP-2718 / EIP-2930 / EIP-155 的关系理解 EIP-3534 需要对它赖以存在的协议骨架有清晰认识这些骨架文档均在本仓库中EIP-2718 Typed Transaction EnvelopeFinal定义TransactionType || TransactionPayload为合法交易、TransactionType || ReceiptPayload为合法收据见 eip-2718.md 的 Abstract。TransactionType是介于0与0x7f之间的正无符号 8 位数TransactionPayload是不透明字节数组其解释取决于交易类型。EIP-3534 的0x4正是这一信封下的具体类型编号。客户端通过首字节区分交易类型[0, 0x7f]为新类型[0xc0, 0xfe]为遗留类型。EIP-2930 Optional Access ListsFinal定义了格式0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])的访问列表交易。EIP-3534 在此基础上插入了chainContext字段将字段序列扩展为[chainId, chainContext, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS]——这正是两 EIP 在编码层面的直接血缘关系。EIP-155 Simple Replay Attack ProtectionFinal在签名哈希中纳入chainid使v的计算变为{0,1} CHAIN_ID * 2 35见 eip-155.md 的 Specification。EIP-3534 将ancestorId视为 EIP-155 在链段层面的深化并论证了为何仍保留chainId。十、总结与实现要点EIP-3534 提出了一类携带约束的类型化交易其要点可归纳为编码0x4 || rlp([chainId, chainContext, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS])chainContext为ANNOTATION_COMPOSITE_PREFIX || rlp[{subclass value}...]四种约束子类ancestorId前缀14–12 字节祖先区块引用、eligibleMinerList前缀2最多 3 个白名单地址、ineligibleMinerList前缀4最多 3 个黑名单地址、expiry前缀8最大有效区块时间戳组合规则前缀按八进制位求和1/2/4/8多值时按固定顺序排列ANCESTOR_ID → ELIGIBLE_MINER_LIST → INELIGIBLE_MINER_LIST → EXPIRY且黑白名单不得并用校验语义约束不满足即交易无效含无效交易的区块无效与现状共识规则一致安全边界4 字节哈希前缀在正常网络行为下碰撞概率约1/(4_294_967_296 * 10)碰撞时交易退化为在两条链段均有效不劣于现状。值得注意的是该提案状态为StagnantFORK_BLOCK_NUMBER仍为TBD且ancestorId的校验要求按区块号的正向数据库命中——这些都是评估其落地可行性时需要认知的前提。作为一份完整定义交易类型编码、约束语义、测试向量与安全模型的标准提案EIP-3534 为让交易表达链上下文偏好这一方向提供了清晰的协议级参考设计。版权说明本提案版权及相关权利依据 LICENSE.mdCC0放弃。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-3534 深度解析：受限链上下文交易类型（Restricted Chain Context Transactions）
EIP-3534 深度解析受限链上下文交易类型Restricted Chain Context Transactions【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-3534 是 Ethereum Improvement Proposal 仓库EIPs中一份状态为Stagnant、类别为 Standards Track / Core 的核心协议提案它基于 EIP-2718 类型化交易信封定义了一种全新的交易类型0x4允许交易通过chainContext字段对祖先区块、区块生产者矿工、区块时间戳等链上下文施加约束。阅读本文后你将完整掌握该交易类型的 RLP 编码结构、四种链上下文子类ancestorId、eligibleMinerList、ineligibleMinerList、expiry的语义与组合规则、校验逻辑以及设计者在chainId冗余、哈希截断安全性等关键问题上的取舍论证。一、提案定位一份受限链上下文核心交易类型提案本文所解析的 eip-3534.md 位于仓库EIPS/目录是一份面向以太坊核心共识协议Core 类别的标准跟踪提案。其元数据信息如下EIP 编号3534标题Restricted Chain Context Type Transactions受限链上下文类型交易作者Isaac Ardiswhilei状态Stagnant停滞即未被采纳推进类型/类别Standards Track / Core创建时间2021-04-20依赖EIP-2718、EIP-2930提案的核心诉求Simple Summary一句话可以概括为定义一种新的交易类型使其能够对祖先区块哈希、区块作者miner和/或区块时间戳施加约束从而让交易有资格进入的链上下文chain context被精确限定。二、抽象0x4类型交易的编码格式与四种上下文子类提案引入一种新的 EIP-2718 交易类型其编码格式为0x4 || rlp([chainId, chainContext, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS])其中0x4即TRANSACTION_TYPE_NUMBER是 EIP-2718 信封格式中的TransactionType||为字节/字节数组拼接运算符。对应的ReceiptPayload为rlp([status, cumulativeGasUsed, logsBloom, logs])新增的chainContext元素对交易的有效性施加约束——交易只有在其链上下文满足所引用的值时才有效。提案定义了该类型的四个上下文子类subclass子类语义segmentId即ancestorId约束交易只能进入以某祖先区块为前缀的链段eligibleMinerList约束包含该交易的区块的受益人beneficiary必须在白名单地址集合中ineligibleMinerList约束包含该交易的区块的受益人不得在黑名单地址集合中expiry约束包含该交易的区块时间戳必须小于给定值过期时间这些上下文可以被任意组合使用被注解的上下文值组合通过chainContext上的一个复合整数前缀ANNOTATION_COMPOSITE_PREFIX来标识。三、动机让交易能够表达与区块链数据的关系约束提案的动机是建立一种基于协议的机制让交易能够明确表达对合格链上下文的约束。从消费者交易发起方视角看这些约束赋予交易描述其与区块链数据及其来源provenance关系的能力具体包括四类诉求将交易适用性限制在当前主观视图下可用且可推理的链上下文——让交易能够表达对其当前链视图的依赖将交易适用性限制在某个先前区块及其交易之后的链上下文——在宏观区块级层面表达祖先依赖间接地只要依赖交易位于不同的区块中就可以让一笔交易依赖另一笔交易的存在将交易适用性限制在使某个偏好/厌恶的矿工地址受益或不受益的区块——为矿工竞争消费者交易创造机会/市场。在现状下从消费者视角看矿工的交易处理服务几乎是完全同质的限制交易的适用时间跨度——提供一种不同于现状的、让交易从交易池txpool中失效/被逐出的替代方式。四、规范Specification4.1 参数FORK_BLOCK_NUMBERTBD待定TRANSACTION_TYPE_NUMBER0x4参见 EIP-2718自FORK_BLOCK_NUMBER起引入一个TransactionType为TRANSACTION_TYPE_NUMBER即0x4的新 EIP-2718 交易。其TransactionPayload与ReceiptPayload如上文所述。4.2 定义chainContext交易仅对满足全部ALL OF注解的区块链数据有效。ANNOTATION_COMPOSITE_PREFIX一个介于1与0xff之间的正整数表示chainContext中子类注解的集合即提供的值应作用于哪些链上下文子类。其值应为各子类ANNOTATION_PREFIX之和。ANNOTATION_PREFIX为各子类定义的、以八进制派生的正整数限定于集合2^0, 2^1, 2^2, 2^3, 2^4, 2^5, 2^6, 2^7即1, 2, 4, 8, 16, 32, 64, 128。chainContext值应具有如下形式ANNOTATION_COMPOSITE_PREFIX || [{subclass value}...]其中...表示左侧元素的零个或多个||为字节/字节数组拼接运算符。最终编码为ANNOTATION_COMPOSITE_PREFIX || rlp[{subclass value}...]4.3 校验Validation下述各子类定义的值构成对特定链上下文下交易有效性的约束。交易若定义了其链上下文不满足的约束则应被判定为无效包含无效交易的区块按现状status quo同样应被判定为无效区块。4.4 子类组合Subclass Combination当chainContext注解了多个子类引用时各值必须按以下顺序提供ANCESTOR_IDELIGIBLE_MINER_LISTINELIGIBLE_MINER_LISTEXPIRY同时ANNOTATION_COMPOSITE_PREFIX应为所指定子类ANNOTATION_PREFIX的和。4.5 四个子类的完整规格ancestorId祖先区块 IDANNOTATION_PREFIX1ANCESTOR_IDbytes长度为 4 至 12 字节的字节数组ANCESTOR_ID通过拼接区块号block number的字节表示与该区块哈希的前 4 字节来引用一个特定区块区块号应以大端序big endian编码且应移除左侧填充的 0当引用创世区块时区块号部分可以省略ANCESTOR_ID值应被 RLP 编码为字节数组用于哈希与传输。eligibleMinerList合格矿工白名单ANNOTATION_PREFIX2ELIGIBLE_MINER_LIST[address...]地址列表MAX_ELEMENTS3可提供的地址最大数量ELIGIBLE_MINER_LIST是唯一、有效地址的数组。任何包含使用该值交易的区块其区块受益人block beneficiary必须包含在此集合中。值的类型为[{20 bytes}]表示左侧元素的一个或多个不允许重复值。该值应 RLP 编码后用于哈希与传输。ELIGIBLE_MINER_LIST值不得与INELIGIBLE_MINER_LIST值相邻出现。ineligibleMinerList不合格矿工黑名单ANNOTATION_PREFIX4INELIGIBLE_MINER_LIST[address...]地址列表MAX_ELEMENTS3INELIGIBLE_MINER_LIST是唯一、有效地址的数组。任何包含使用该值交易的区块其区块受益人不得包含在此集合中。类型同样为[{20 bytes}]不允许重复值应 RLP 编码后用于哈希与传输。INELIGIBLE_MINER_LIST值不得与ELIGIBLE_MINER_LIST值相邻出现。expiry过期时间ANNOTATION_PREFIX8EXPIRYinteger一个正的、无符号标量EXPIRY是一个标量等于包含该交易的区块的最大有效timestamp。该值应作为整数 RLP 编码后用于哈希与传输。五、设计理由Rationale深度解读5.1 子类高概念独立性 任意 AND 组合子类被设计为具有高度的概念独立性可以独立于本 EIP 进行修改和/或扩展。它们的规格定义允许任意互斥与AND组合。这一设计意图是在提供一套具体规范的同时保留足够的灵活性以便日后扩展或修改。5.2ANNOTATION_PREFIX八进制派生值的组合术ANNOTATION_PREFIX使用八进制派生值1, 2, 4, 8, 16, 32, 64, 128遵循一种从有限集合中唯一且简洁地表示组合的经典模式例如 Unix 风格的文件权限位。本 EIP 定义了八个可能子类中的四个为未来增长留足了空间。若该上限被触及或超过则因为会改变交易校验方案属于共识协议层面的变更而事实上需要硬分叉届时再修订该方案也只是附带的小事。5.3ancestorId与chainId的冗余关系ancestorId通过引用先前的规范区块按区块号和哈希来约束交易的有效性——交易仅当被包含在以该注解区块为祖先的区块中时有效。实际上被指定的合格链段可以理解为从0..ancestorId含的区块段。该模式可视为 EIP-155 中chainId规范的相关物correlateEIP-155 限制了交易在链之间的适用性交易只能应用于标注了对应 ChainID 的链而ancestorId进一步将交易应用限制在一条链的某个子段。从这一约束层级来看实现ancestorId可以在概念上使chainId变得冗余。那为什么还要保留chainId提案给出五点论证本 EIP 提出的交易类型是可选使用的这意味着chainId在协议基础设施和工具链中对遗留交易和其他交易类型仍有持续的必要性本 EIP 交易类型中的ancestorId也是可选的若 RCC 交易未填充该值则对chainId的需求依然存在chainId对ancestorId并非必然冗余——在分叉导致两条链并存的场景中尤为如此。例如引用区块1_919_999的ancestorId在以太坊Ethereum与以太坊经典Ethereum Classic之间会产生歧义也可以规定在ancestorId被使用时省略chainId但这会增加基础设施复杂度仅仅为了省去chainId通常占用的几个字节设计者认为这笔交易不划算。且chainId参与交易签名方案中v值的计算v,r,s移除或修改它会牵连到比编码字段更底层的复杂度ancestorId的设计并不提供完美精度以换取字节大小的节省在极小的概率下值可能产生歧义此时chainId仍为交易的链特异性提供万无一失的保证。5.4eligibleMinerList/ineligibleMinerList交易仅当被包含在etherbase区块受益人位于注解地址列表中的区块时有效交易仅当被包含在etherbase不在注解地址列表中的区块时有效白名单eligibleMinerList与黑名单ineligibleMinerList并用在逻辑上不一致因此不允许二者并用MAX_ELEMENTS 3的选择是为了在限制交易潜在体积与为用户提供足够的表达能力之间取得平衡。提案写作时以太坊前 3 大矿工按区块计以已知公开地址衡量产出了全部区块的 52%——3 个地址足以覆盖这一头部份额。5.5expiry交易仅当被包含在timestamp小于注解值的区块中时有效。使用正整数是因为它对应区块头中timestamp字段规定的类型。5.6 子类组合的完整推导由于各子类的ANNOTATION_PREFIX基于八进制值在假定注解基数即顺序的前提下它们可以通过求和被区分性地组合。例如前缀1仅ancestorId前缀2仅eligibleMinerList前缀4仅ineligibleMinerList前缀8仅expiry前缀123组合ancestorId与eligibleMinerList前缀145组合ancestorId与ineligibleMinerList前缀189组合ancestorId与expiry前缀12811组合ancestorId、eligibleMinerList与expiry前缀14813组合ancestorId、ineligibleMinerList与expiry前缀246不允许会组合eligibleMinerList与ineligibleMinerList前缀124815不允许会组合eligibleMinerList与ineligibleMinerList以及ancestorId与expiry由于多值时必须且必须遵循既定顺序被注解的引用仍可区分。原文给出两个可读示例chainContext3[e4e1c0e78b1ec3,[Df7D7e053933b5cC24372f878c90E62dADAD5d42]]交易只能被包含在满足以下条件的区块中——存在编号为15_000_000、哈希前缀为字节e78b1ec3的规范祖先区块且包含区块的受益人为Df7D7e053933b5cC24372f878c90E62dADAD5d42。chainContext10[[Df7D7e053933b5cC24372f878c90E62dADAD5d42],1619008030]交易只能被包含在满足以下条件的区块中——以Df7D7e053933b5cC24372f878c90E62dADAD5d42为etherbase受益人且时间戳大于16190080302021-04-21 07:27:10 CDT。注前缀10 2 8即eligibleMinerList与expiry的组合两个值按顺序[ELIGIBLE_MINER_LIST, EXPIRY]排列与 4.4 节规定的顺序一致。5.7 EIP-2930 继承与签名目标提案以 EIP-2930 Optional Access List Type Transaction 作为假定的基座交易类型——唯一的差别在于accessList字段这是与 post-EIP-155 遗留交易字段的唯一差异且该字段可以方便地移除。这是一种非概念性依赖站在 EIP-2930 的肩膀上只是为了支持并推进下一代交易的采用。签名目标方面签名覆盖交易类型0x4以及交易数据本身。这是为了确保交易不能被重新解释为另一种类型的交易与 EIP-2718 中所有未来交易类型的签名都应包含TransactionType作为签名数据的首字节的建议见 eip-2718.md 中All signatures for future transaction types SHOULD include the TransactionType as the first byte of the signed data保持一致。六、向后兼容性提案声明没有已知的向后兼容性问题There are no known backward compatibility issues。七、测试用例ANCESTOR_ID编码向量提案给出了segmentId即ancestorId的核心测试向量验证区块号 区块哈希前 4 字节的拼接编码规则区块号大端序、去左侧填充 0、创世区块可省略区块号Segment IDBlock NumberCanonical Block Hashe78b1ec300xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e5801e78b1ec310xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58e4e1c0e78b1ec315_000_0000xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58e8d4a50fffe78b1ec3999_999_999_9990xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e587fffffffffffffffe78b1ec392233720368547758070xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58可以验证其编码规律创世区块区块号0直接省略区块号只保留哈希前 4 字节e78b1ec3区块号1编码为单字节0115_000_0000xe4e1c0编码为 3 字节e4e1c0最大 64 位整数值92233720368547758070x7fffffffffffffff编码为 8 字节。所有 Segment ID 均以哈希前缀e78b1ec3收尾且整体长度落在 412 字节的规格范围内。原文档注明更多测试用例TODO。八、安全考量Security Considerations8.1 为什么ancestorId只用 4 字节哈希就足够安全TL;DR无效ancestorId即碰撞的几率约为 40 亿分之一到 400 亿分之一之间更大的概率出现在蓄意重复场景如恶意重组中。若碰撞真的发生意味着交易将在两个链段上都有效——这与现状status quo下的情形一致不会引入比现状更糟的结果选择 4 字节而非完整哈希32 字节仅仅是为了减少实现该值所需跨网络传输的信息量。使用完整哈希将得到完美安全的实现而每增加一个字节碰撞概率都呈指数级下降ancestorId的目标是在链段之间做消歧让交易能以足够精度定义其所需链。当交易的ancestorId引用某个区块时需要相当确信该引用不会与交易作者所想的那个区块之外的区块混淆设计者假设碰撞抗性对区块哈希值的所有可能子集均匀适用因此选择前 4 字节是任意的与任何等长子集在功能上等价碰撞概率计算1/(16^8 4_294_967_296)乘以等价编号区块在替代链上存在的概率。假设任一区块存在公开叔块uncle的概率为慷慨的 10%1/10则得到(1/4_294_967_296) * 1/10。注意此估算假设正常的链与网络行为在存在长期并存的竞争链段时该值升至 100%1。8.2eligibleMinerList的生态与经济考量未被列入eligibleMinerList的矿工应预期会立即将该交易从其交易池中移除悲观预期下这些不合格节点也可能不会转发rebroadcast这些交易从而可能影响交易向其目标矿工的传播可用性。另一方面矿工有动力让自己对这类交易的接收保持可达且无论是链上还是链外都有多种实现途径使用eligibleMinerList的交易作者必须接受此类交易的区块链状态数据库一般可用性将低于非受限交易因为只有矿工子集能处理该交易关于白名单矿工的交易处理顺序经济学无白名单的交易乍看更具竞争力、应优先处理。但遵循该策略的矿工可能发现自身声誉受损最坏情况下交易作者的偏好将转向其竞争对手而脱离其掌控。8.3ineligibleMinerList的规避成本除上述eligibleMinerList的担忧外ineligibleMinerList有一个独特问题矿工实体要避免被黑名单排除只需使用一个临时的 adhoc 地址作为区块受益人原则上这是不可避免的。但规避者要承担相关成本创建账户需要时间与精力虽然可以在任何方便的时间与场合完成可能边际成本很小但非零从多个账户转移资金需要相应数量的交易。由于区块奖励在交易处理之后才发放矿工无法在自己挖出的同一区块内将资金从临时账户转移到目标账户否则会是免费交易使用 adhoc 地址规避黑名单时矿工也可能同时失去处理同期白名单交易的资格。8.4 校验成本矿工列表与expiry依赖易于缓存且上下文可用的条件即所在区块头强制执行这些校验的基础设施开销预计可以忽略。而ancestorId的校验要求按区块号断言一次正向数据库命中从而交叉引用存储区块的哈希该查找可以或许已经被缓存但由于查找值是任意的必须预期缓存命中率达不到 100%。不过使用深层ancestorId的交易其边际价值递减因此可以预期大多数使用该字段的交易将使用相对较小、较浅、缓存友好的值集合。8.5 交易体积增加与垃圾交易新增字段可能增加交易体积。这些字段不关联任何 gas 成本即没有协议层面的经济手段来抑制潜在垃圾交易。然而被矿工认为不合意的交易可以直接从交易池中丢弃并忽略。九、提案在 EIP 体系中的坐标与 EIP-2718 / EIP-2930 / EIP-155 的关系理解 EIP-3534 需要对它赖以存在的协议骨架有清晰认识这些骨架文档均在本仓库中EIP-2718 Typed Transaction EnvelopeFinal定义TransactionType || TransactionPayload为合法交易、TransactionType || ReceiptPayload为合法收据见 eip-2718.md 的 Abstract。TransactionType是介于0与0x7f之间的正无符号 8 位数TransactionPayload是不透明字节数组其解释取决于交易类型。EIP-3534 的0x4正是这一信封下的具体类型编号。客户端通过首字节区分交易类型[0, 0x7f]为新类型[0xc0, 0xfe]为遗留类型。EIP-2930 Optional Access ListsFinal定义了格式0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])的访问列表交易。EIP-3534 在此基础上插入了chainContext字段将字段序列扩展为[chainId, chainContext, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS]——这正是两 EIP 在编码层面的直接血缘关系。EIP-155 Simple Replay Attack ProtectionFinal在签名哈希中纳入chainid使v的计算变为{0,1} CHAIN_ID * 2 35见 eip-155.md 的 Specification。EIP-3534 将ancestorId视为 EIP-155 在链段层面的深化并论证了为何仍保留chainId。十、总结与实现要点EIP-3534 提出了一类携带约束的类型化交易其要点可归纳为编码0x4 || rlp([chainId, chainContext, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS])chainContext为ANNOTATION_COMPOSITE_PREFIX || rlp[{subclass value}...]四种约束子类ancestorId前缀14–12 字节祖先区块引用、eligibleMinerList前缀2最多 3 个白名单地址、ineligibleMinerList前缀4最多 3 个黑名单地址、expiry前缀8最大有效区块时间戳组合规则前缀按八进制位求和1/2/4/8多值时按固定顺序排列ANCESTOR_ID → ELIGIBLE_MINER_LIST → INELIGIBLE_MINER_LIST → EXPIRY且黑白名单不得并用校验语义约束不满足即交易无效含无效交易的区块无效与现状共识规则一致安全边界4 字节哈希前缀在正常网络行为下碰撞概率约1/(4_294_967_296 * 10)碰撞时交易退化为在两条链段均有效不劣于现状。值得注意的是该提案状态为StagnantFORK_BLOCK_NUMBER仍为TBD且ancestorId的校验要求按区块号的正向数据库命中——这些都是评估其落地可行性时需要认知的前提。作为一份完整定义交易类型编码、约束语义、测试向量与安全模型的标准提案EIP-3534 为让交易表达链上下文偏好这一方向提供了清晰的协议级参考设计。版权说明本提案版权及相关权利依据 LICENSE.mdCC0放弃。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考