EIP-2242 Transaction Postdata 深度解析为 Layer 2 数据可用性设计的链上数据发布通道【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-2242Transaction Postdata是 2019 年提出的一项 Ethereum 核心层Core共识修改提案核心思路是在交易中新增一个可选的postdata字段用于把数据发布到链上、但不允许 EVM 读取。本文基于本仓库 EIPS/eip-2242.md 的完整规范结合仓库内 EIP-2028、EIP-2718、EIP-4844 等关联提案从设计动机、交易格式、RLP 编码结构、gas 计费到兼容性与后续演进系统讲解这条数据可用性通道的技术全貌帮助读者理解数据上链 ≠ 数据可被合约读取这一范式的来龙去脉。一、提案背景区块链作为数据可用性与仲裁层EIP-2242 的提出背景源自当时以太坊社区正在发生的一场范式转变。在 Eth 2.0 的研究中Execution Environments执行环境 与 stateless clients无状态客户端 概念的兴起让区块链的角色从通用计算平台开始向安全的数据可用性与仲裁层转变数据可用性层为上层系统提供一个全球公认的、随时可检索的数据来源仲裁层处理欺诈证明fraud proofs或有效性证明validity proofs以及数据可用性证明。作者 John Adler 认为这一范式同样可以应用到 Eth 1.x 上不引入 Execution Environments而是用**信任最小化的侧链trust-minimized side chains**来替代。EIP-2242 正是为这种侧链方案提供底层支撑的共识层修改。值得注意该提案创建于 2019-08-16当时采用的字段命名startGas、gasPrice是 EIP-1559 落地前的传统交易字段风格反映了其历史语境。二、动机遵循不为用不到的东西付费原则2.1 EIP-2028 的铺垫calldata 降费提案首先引用了同仓库的 EIPS/eip-2028.mdTransaction data gas cost reduction状态为 Final。EIP-2028 将 calldata 的非零字节 gas 成本从 68 gas/字节降至 16 gas/字节是鼓励使用历史数据而非状态数据的正确方向On-Chain Scalabilitycalldata 带宽的提升意味着单块可容纳更多数据Layer 2 扩展STARKs/SNARKs 证明、欺诈证明的 Merkle 路径传输以及把数据通过 calldata 发布到主链以作数据可用性data availability都能受益无状态客户端同样的模型可用于定价状态访问成本。2.2 问题EVM 其实不需要看到所有链上数据EIP-2028 降低的是 calldata 的读取成本但一个更深层的问题被 EIP-2242 指出并非所有发布到链上的数据都需要被 EVM 执行逻辑处理。例如侧链区块的数据只是需要被证明其可用而不是被主链合约逐字节解读。因此遵循dont pay for what you dont use不为用不到的东西付费原则需要一种全新的、独立于 EVM 的数据发布方式——这正是postdata字段的使命。2.3 适用范围欺诈证明侧链而非有效性证明侧链提案对适用场景做了明确界定基于欺诈证明的信任最小化侧链只需要确保侧链区块提议者已证明某些数据确实可用数据的真伪可以在欺诈证明流程中事后验证。这类方案可以直接受益于本提案基于有效性证明的侧链要求对发布的数据立即完成认证因此无法使用本提案的机制需要留待未来的 EIP 专门处理即多线程数据可用性方向。三、规范Specificationpostdata字段的完整设计EIP-2242 提出一项自FORK_BLKNUM起生效的共识修改。以下内容完整继承自 EIPS/eip-2242.md 的规范章节。3.1 序列化交易的新格式在现有交易上追加一个可选字段postdata序列化后的交易格式为from: bytes20, to: bytes20, startGas: uint256, gasPrice: uint256, value: uint256, data: bytes, nonce: uint256, [postdata: bytes],要点postdata是可选字段方括号表示可选仅在需要时追加到交易末尾见证人witness即签名者对上述结构的 RLP 编码 进行签名——即postdata也纳入被签名的数据范围postdata中的数据被发布到链上供 Layer 2 系统后续按历史数据检索主链 EVM 不参与解读。3.2postdata的内部 RLP 结构postdata本身是一个 RLP 编码的两元组twoplepostdata RLP(version: uint64, data: bytes)version版本号当前规范要求取值为0。引入版本号是为了给未来扩展留出空间——不同的version值可以由未来的 EIP 定义不同的数据解释方案data一个 RLP 编码的二进制数据列表。本 EIP不解释data的任何内部结构仅将其视为二进制大块binary blob原样上链。3.3 Gas 成本规则postdata的 gas 计费规则非常简洁发布数据的成本为1 gas/字节该成本从交易的startGas中扣除若扣除后剩余 gas非正non-positive交易立即以out of gas 异常回滚revert。对比可见1 gas/字节远低于 EIP-2028 降价后的 calldata 成本非零字节 16 gas、零字节 4 gas体现了仅发布、不计算、不读取的定价逻辑——正因为 EVM 无需处理这些数据其 gas 成本可以显著更低。四、设计权衡RationaleEIP-2242 的设计哲学在 Rationale 一节中概括为以对现有 EVM 和交易格式最小且无破坏性的方式实现目标同时通过版本号version机制为未来可能的扩展如多线程数据可用性方案保留兼容空间。具体体现为三点设计取舍设计决策权衡考量可选字段而非必填字段现有交易完全不受影响实现向后兼容只有需要数据发布能力的 Layer 2 系统才追加该字段独立字段而非复用 calldataEVM 无需为无法读取的数据消耗 calldata 的 gas 与处理路径符合不为用不到的东西付费版本号先行当前version0不解释数据未来 EIP 可基于不同版本号引入新的数据解释/认证方案避免规范反复改动五、向后兼容性Backwards CompatibilityEIP-2242 明确给出了兼容性边界向后兼容backwards compatible新的postdata字段只是可选追加到现有交易末尾不改变既有交易的编码与语义因此旧客户端视角下交易格式不变不向前兼容not forwards-compatible该改动属于共识层修改必须通过硬分叉hard fork引入无法在软分叉框架内完成。六、从仓库看 EIP-2242 的思路延续与演进脉络EIP-2242 虽然最终停留在 Stagnant 状态但数据上链但 EVM 不可读的思路在以太坊后续提案中被以更成熟的形态继承和发展。以下关联提案均可在本仓库EIPS/目录下找到原文6.1 EIP-2718类型化交易信封Typed Transaction EnvelopeEIPS/eip-2718.md状态 Final定义了TransactionType || TransactionPayload的交易信封结构用首字节类型标识符区分不同交易类型。它解决了 EIP-2242 时代新字段只能通过位打包塞进旧编码的困境——后续所有新交易类型包括 blob 交易都基于此信封演进。6.2 EIP-4844Shard Blob Transactions——思路的最终实现EIPS/eip-4844.md状态 Final是这一范式的直接继承者引入携带 blob 的交易blob-carrying transactions其中包含大量 EVM 执行无法访问、但其承诺commitment可以被访问的数据。其动机陈述与 EIP-2242 一脉相承——Rollup 需要低成本的数据可用性空间blob 交易提供了目标约 0.375 MB/块、上限约 0.75 MB/块的专用数据空间。对比可见 EIP-2242 与 EIP-4844 的核心一致性维度EIP-2242postdataEIP-4844blobEVM 可读性不可读仅发布不可访问仅承诺KZG 承诺可读用途信任最小化侧链的数据可用性Rollup 的数据可用性计费1 gas/字节固定独立 blob gas 市场EIP-1559 风格费用机制状态StagnantFinal已随 Deneb 升级上线需要说明的是这是从仓库两份提案文本中可确认的事实性对应关系EIP-2242 本身并未在正文中预告 EIP-4844二者分别成文于 2019 与 2022 年属于同一研究脉络下的先后演进。6.3 EIP-7623calldata 成本调整的后续EIPS/eip-7623.md状态 Final在 2024 年进一步调整 calldata 定价以压缩区块最大尺寸、引导 Rollup 从 calldata 迁移到 blob。它引用 EIP-2028 指出calldata 成本自 EIP-2028 以来未变并明确 EIP-4844 的 blob 已成为首选的 DA 方案——从侧面印证了独立于 EVM 的数据发布通道这一方向的最终落地形态正是 blob而非交易内嵌字段。七、状态评估与未完成项7.1 Test Cases 与 Implementation 均为 TODOEIP-2242 规范中的Test Cases与Implementation两个章节均标注为TODOTest Cases 缺失提案未给出任何测试向量如postdata的 RLP 编码示例、gas 扣除边界的测试用例这使其规范难以被客户端实现直接验证Implementation 缺失未提供任何客户端如 Geth、Parity的参考实现链接也没有交易池、签名验证、RLP 解码等层面的实现草案。这两项空白是提案长期停留在草案状态的重要原因——缺少可执行验证路径的共识提案难以进入评审流程。7.2 Stagnant 状态的含义根据本仓库 EIPS/eip-1.mdEIP Purpose and Guidelines对状态机的定义Stagnant- Any EIP inDraftorRevieworLast Callif inactive for a period of 6 months or greater is moved toStagnant. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back toDraftor its earlier status.即任何处于 Draft / Review / Last Call 状态、超过 6 个月无活动的 EIP 会被移入 Stagnant 状态作者或编辑可将其移回 Draft 或更早状态以复活。EIP-2242 目前即处于该状态FORK_BLKNUM从未被任何以太坊网络采用。读者在引用时应将其视为历史性研究提案而非已生效的共识规范。八、总结EIP-2242 Transaction Postdata 是一个设计上小而美的共识层提案以最小侵入性的方式追加可选字段实现了数据发布与 EVM 计算解耦的目标用 1 gas/字节的低成本定价和版本号机制为信任最小化侧链提供了数据可用性通道。尽管它因缺少测试用例与参考实现而停滞Stagnant但其核心洞察——区块链的价值不仅在于计算更在于作为不可篡改的全球数据可用性层——深刻影响了以太坊后续的数据可用性演进路线从 EIP-2028 的 calldata 降费到 EIP-2718 的类型化交易信封再到最终落地为 EIP-4844 的 blob 交易与 EIP-7623 的定价收敛。阅读 EIP-2242是理解以太坊 DA 路线图历史逻辑的一条重要线索。本提案版权依据 LICENSE.mdCC0声明放弃相关权利。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
EIP-2242 Transaction Postdata 深度解析：为 Layer 2 数据可用性设计的链上数据发布通道
EIP-2242 Transaction Postdata 深度解析为 Layer 2 数据可用性设计的链上数据发布通道【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-2242Transaction Postdata是 2019 年提出的一项 Ethereum 核心层Core共识修改提案核心思路是在交易中新增一个可选的postdata字段用于把数据发布到链上、但不允许 EVM 读取。本文基于本仓库 EIPS/eip-2242.md 的完整规范结合仓库内 EIP-2028、EIP-2718、EIP-4844 等关联提案从设计动机、交易格式、RLP 编码结构、gas 计费到兼容性与后续演进系统讲解这条数据可用性通道的技术全貌帮助读者理解数据上链 ≠ 数据可被合约读取这一范式的来龙去脉。一、提案背景区块链作为数据可用性与仲裁层EIP-2242 的提出背景源自当时以太坊社区正在发生的一场范式转变。在 Eth 2.0 的研究中Execution Environments执行环境 与 stateless clients无状态客户端 概念的兴起让区块链的角色从通用计算平台开始向安全的数据可用性与仲裁层转变数据可用性层为上层系统提供一个全球公认的、随时可检索的数据来源仲裁层处理欺诈证明fraud proofs或有效性证明validity proofs以及数据可用性证明。作者 John Adler 认为这一范式同样可以应用到 Eth 1.x 上不引入 Execution Environments而是用**信任最小化的侧链trust-minimized side chains**来替代。EIP-2242 正是为这种侧链方案提供底层支撑的共识层修改。值得注意该提案创建于 2019-08-16当时采用的字段命名startGas、gasPrice是 EIP-1559 落地前的传统交易字段风格反映了其历史语境。二、动机遵循不为用不到的东西付费原则2.1 EIP-2028 的铺垫calldata 降费提案首先引用了同仓库的 EIPS/eip-2028.mdTransaction data gas cost reduction状态为 Final。EIP-2028 将 calldata 的非零字节 gas 成本从 68 gas/字节降至 16 gas/字节是鼓励使用历史数据而非状态数据的正确方向On-Chain Scalabilitycalldata 带宽的提升意味着单块可容纳更多数据Layer 2 扩展STARKs/SNARKs 证明、欺诈证明的 Merkle 路径传输以及把数据通过 calldata 发布到主链以作数据可用性data availability都能受益无状态客户端同样的模型可用于定价状态访问成本。2.2 问题EVM 其实不需要看到所有链上数据EIP-2028 降低的是 calldata 的读取成本但一个更深层的问题被 EIP-2242 指出并非所有发布到链上的数据都需要被 EVM 执行逻辑处理。例如侧链区块的数据只是需要被证明其可用而不是被主链合约逐字节解读。因此遵循dont pay for what you dont use不为用不到的东西付费原则需要一种全新的、独立于 EVM 的数据发布方式——这正是postdata字段的使命。2.3 适用范围欺诈证明侧链而非有效性证明侧链提案对适用场景做了明确界定基于欺诈证明的信任最小化侧链只需要确保侧链区块提议者已证明某些数据确实可用数据的真伪可以在欺诈证明流程中事后验证。这类方案可以直接受益于本提案基于有效性证明的侧链要求对发布的数据立即完成认证因此无法使用本提案的机制需要留待未来的 EIP 专门处理即多线程数据可用性方向。三、规范Specificationpostdata字段的完整设计EIP-2242 提出一项自FORK_BLKNUM起生效的共识修改。以下内容完整继承自 EIPS/eip-2242.md 的规范章节。3.1 序列化交易的新格式在现有交易上追加一个可选字段postdata序列化后的交易格式为from: bytes20, to: bytes20, startGas: uint256, gasPrice: uint256, value: uint256, data: bytes, nonce: uint256, [postdata: bytes],要点postdata是可选字段方括号表示可选仅在需要时追加到交易末尾见证人witness即签名者对上述结构的 RLP 编码 进行签名——即postdata也纳入被签名的数据范围postdata中的数据被发布到链上供 Layer 2 系统后续按历史数据检索主链 EVM 不参与解读。3.2postdata的内部 RLP 结构postdata本身是一个 RLP 编码的两元组twoplepostdata RLP(version: uint64, data: bytes)version版本号当前规范要求取值为0。引入版本号是为了给未来扩展留出空间——不同的version值可以由未来的 EIP 定义不同的数据解释方案data一个 RLP 编码的二进制数据列表。本 EIP不解释data的任何内部结构仅将其视为二进制大块binary blob原样上链。3.3 Gas 成本规则postdata的 gas 计费规则非常简洁发布数据的成本为1 gas/字节该成本从交易的startGas中扣除若扣除后剩余 gas非正non-positive交易立即以out of gas 异常回滚revert。对比可见1 gas/字节远低于 EIP-2028 降价后的 calldata 成本非零字节 16 gas、零字节 4 gas体现了仅发布、不计算、不读取的定价逻辑——正因为 EVM 无需处理这些数据其 gas 成本可以显著更低。四、设计权衡RationaleEIP-2242 的设计哲学在 Rationale 一节中概括为以对现有 EVM 和交易格式最小且无破坏性的方式实现目标同时通过版本号version机制为未来可能的扩展如多线程数据可用性方案保留兼容空间。具体体现为三点设计取舍设计决策权衡考量可选字段而非必填字段现有交易完全不受影响实现向后兼容只有需要数据发布能力的 Layer 2 系统才追加该字段独立字段而非复用 calldataEVM 无需为无法读取的数据消耗 calldata 的 gas 与处理路径符合不为用不到的东西付费版本号先行当前version0不解释数据未来 EIP 可基于不同版本号引入新的数据解释/认证方案避免规范反复改动五、向后兼容性Backwards CompatibilityEIP-2242 明确给出了兼容性边界向后兼容backwards compatible新的postdata字段只是可选追加到现有交易末尾不改变既有交易的编码与语义因此旧客户端视角下交易格式不变不向前兼容not forwards-compatible该改动属于共识层修改必须通过硬分叉hard fork引入无法在软分叉框架内完成。六、从仓库看 EIP-2242 的思路延续与演进脉络EIP-2242 虽然最终停留在 Stagnant 状态但数据上链但 EVM 不可读的思路在以太坊后续提案中被以更成熟的形态继承和发展。以下关联提案均可在本仓库EIPS/目录下找到原文6.1 EIP-2718类型化交易信封Typed Transaction EnvelopeEIPS/eip-2718.md状态 Final定义了TransactionType || TransactionPayload的交易信封结构用首字节类型标识符区分不同交易类型。它解决了 EIP-2242 时代新字段只能通过位打包塞进旧编码的困境——后续所有新交易类型包括 blob 交易都基于此信封演进。6.2 EIP-4844Shard Blob Transactions——思路的最终实现EIPS/eip-4844.md状态 Final是这一范式的直接继承者引入携带 blob 的交易blob-carrying transactions其中包含大量 EVM 执行无法访问、但其承诺commitment可以被访问的数据。其动机陈述与 EIP-2242 一脉相承——Rollup 需要低成本的数据可用性空间blob 交易提供了目标约 0.375 MB/块、上限约 0.75 MB/块的专用数据空间。对比可见 EIP-2242 与 EIP-4844 的核心一致性维度EIP-2242postdataEIP-4844blobEVM 可读性不可读仅发布不可访问仅承诺KZG 承诺可读用途信任最小化侧链的数据可用性Rollup 的数据可用性计费1 gas/字节固定独立 blob gas 市场EIP-1559 风格费用机制状态StagnantFinal已随 Deneb 升级上线需要说明的是这是从仓库两份提案文本中可确认的事实性对应关系EIP-2242 本身并未在正文中预告 EIP-4844二者分别成文于 2019 与 2022 年属于同一研究脉络下的先后演进。6.3 EIP-7623calldata 成本调整的后续EIPS/eip-7623.md状态 Final在 2024 年进一步调整 calldata 定价以压缩区块最大尺寸、引导 Rollup 从 calldata 迁移到 blob。它引用 EIP-2028 指出calldata 成本自 EIP-2028 以来未变并明确 EIP-4844 的 blob 已成为首选的 DA 方案——从侧面印证了独立于 EVM 的数据发布通道这一方向的最终落地形态正是 blob而非交易内嵌字段。七、状态评估与未完成项7.1 Test Cases 与 Implementation 均为 TODOEIP-2242 规范中的Test Cases与Implementation两个章节均标注为TODOTest Cases 缺失提案未给出任何测试向量如postdata的 RLP 编码示例、gas 扣除边界的测试用例这使其规范难以被客户端实现直接验证Implementation 缺失未提供任何客户端如 Geth、Parity的参考实现链接也没有交易池、签名验证、RLP 解码等层面的实现草案。这两项空白是提案长期停留在草案状态的重要原因——缺少可执行验证路径的共识提案难以进入评审流程。7.2 Stagnant 状态的含义根据本仓库 EIPS/eip-1.mdEIP Purpose and Guidelines对状态机的定义Stagnant- Any EIP inDraftorRevieworLast Callif inactive for a period of 6 months or greater is moved toStagnant. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back toDraftor its earlier status.即任何处于 Draft / Review / Last Call 状态、超过 6 个月无活动的 EIP 会被移入 Stagnant 状态作者或编辑可将其移回 Draft 或更早状态以复活。EIP-2242 目前即处于该状态FORK_BLKNUM从未被任何以太坊网络采用。读者在引用时应将其视为历史性研究提案而非已生效的共识规范。八、总结EIP-2242 Transaction Postdata 是一个设计上小而美的共识层提案以最小侵入性的方式追加可选字段实现了数据发布与 EVM 计算解耦的目标用 1 gas/字节的低成本定价和版本号机制为信任最小化侧链提供了数据可用性通道。尽管它因缺少测试用例与参考实现而停滞Stagnant但其核心洞察——区块链的价值不仅在于计算更在于作为不可篡改的全球数据可用性层——深刻影响了以太坊后续的数据可用性演进路线从 EIP-2028 的 calldata 降费到 EIP-2718 的类型化交易信封再到最终落地为 EIP-4844 的 blob 交易与 EIP-7623 的定价收敛。阅读 EIP-2242是理解以太坊 DA 路线图历史逻辑的一条重要线索。本提案版权依据 LICENSE.mdCC0声明放弃相关权利。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考