OP Stack 执行层开发指南：op-reth、Deposit 交易（0x7E）与 L1 费用模型深度解析

OP Stack 执行层开发指南op-reth、Deposit 交易0x7E与 L1 费用模型深度解析【免费下载链接】optimismOptimism is Ethereum, scaled.项目地址: https://gitcode.com/GitHub_Trending/op/optimism本篇技术指南聚焦 OP Stack 的执行层Execution Layer开发EVM 执行、状态转换、块处理以及 OP Stack 在上游 Ethereum 执行之上叠加的 L2 专属修改。读完本文你将掌握三个执行层客户端op-reth、kona-client、op-geth的职责边界与选型依据、Deposit 交易类型0x7E的编码格式与实现位置、L1 数据费用L1 fee在 Ecotone/Fjord 两个硬分叉下的计算公式以及执行层开发必须遵守的四条不变量Deposit 必成功、L1 费用精确、确定性、Gas 上限执行。执行层客户端三大实现及其分工OP Stack 仓库中同时存在三个执行层客户端文档 docs/ai/execution-layer.md 明确了各自的定位op-reth主要的执行层实现位于 monorepo 的rust/op-reth目录构建在 reth 下的 crate 划分体现了对上游 reth 的完整覆盖chainspec链规格、hardforks硬分叉定义、evmEVM 执行封装、payload区块构建、exex外部执行、txpool、storage、trie等说明 op-reth 不是简单包一层而是对整条执行链路都做了 OP 化改造。kona-client携带自己的执行路径服务于故障证明fault proofs未来包括 zk proofs。关键点在于它不内嵌 op-reth证明程序通过kona-executor位于 rust/kona/crates/proof/executor直接使用op-revm和op-alloy执行区块从而保持证明二进制最小化。更多细节见 fault-proofs 文档。op-geth已弃用的执行层客户端ethereum-optimism/op-gethgo-ethereum 的 fork正在被移除以让位于 op-reth。OP-Stack 专属代码正从 op-geth 中被抽取到 monorepo 的op-core/*目录使 monorepo 能够直接依赖上游 go-ethereum。只有在做 op-geth 解耦 / op-core 抽取工作时才需要阅读 opgeth-decoupling 文档常规执行层开发无需理会。这一抽取到 op-core的工作已经在仓库中留下了清晰的痕迹op-core/types/deposit_tx.go中的注释明确说明这些辅助函数只存在于解耦过渡期一旦构建从 op-geth 切换到上游 go-ethereum届时0x7E类型在解码时会被拒绝这些代码即被移除。执行层的范围界定执行层覆盖的内容是EVM 执行、状态转换、区块处理以及 OP Stack 在上游 Ethereum 执行之上添加的 L2 专属修改。这四者共同构成执行层开发的核心工作面——任何触碰 EVM 语义、状态根计算、区块执行流程或 L2 差异化逻辑的改动都属于执行层开发范畴。核心概念Deposit 交易0x7EDeposit 交易是 OP Stack 最具代表性的 L2 定制它们是系统级交易type0x7E源自 L1 存款由 L1 侧或为网络升级生成而非用户签名。在 Go 侧规范类型定义于 op-core/types/deposit_tx.go类型字节定义为// DepositTxType is the EIP-2718 type byte of OP Stack deposit transactions. const DepositTxType 0x7EDepositTx结构体包含以下字段值得逐一看懂字段含义SourceHash唯一标识存款来源的哈希From发送方地址由存款来源决定而非签名决定To接收方nil表示创建合约Mint在 L2 铸造L1 锁定的数量nil表示不铸造。注意nil与零的线上编码相同解码后均为零Value从 L2 余额转移的价值在 Mint如有之后执行GasGas 上限IsSystemTransaction标记为系统交易时豁免 L2 Gas 上限Data调用数据其规范编码为DepositTxType || RLP(fields)即 EIP-2718 标准格式首字节类型标识 后续 RLP 编码的字段体与 op-geth 的types.DepositTx线上格式保持一致交易哈希即该规范编码的 keccak-256。解码入口为UnmarshalDepositTx它会校验首字节必须为0x7E。在 Rust 执行侧OP 的 EVM 封装位于 rust/op-revm/src/evm.rsOpEvm通过 newtype 包裹 revm 的Evm类型构造时以OpSpecIdOP 专属的规格/硬分叉标识选择指令集与预编译/// Optimism EVM extends the Evm type with Optimism specific types and logic. pub struct OpEvmCTX, INSP, I, P, F(pub EvmCTX, INSP, I, P, F); pub fn new(ctx: CTX, inspector: INSP) - Self { let spec: OpSpecId ctx.cfg().spec().into(); Self(Evm { ctx, inspector, instruction: EthInstructions::new_mainnet_with_spec(spec.into()), precompiles: OpPrecompiles::new_with_spec(spec), ... }) }这解释了为什么 kona-client 与 op-reth 都基于op-revmOpEvm是共享的、最小化的 OP EVM 抽象两条执行路径链上执行与证明执行都复用它这正是确定性不变量的工程保障见下文。核心概念L1 费用计算L2 上每笔交易除常规 gas 外还需支付一个基于其 L1 数据成本的附加费用组件。该计算的 Go 参考实现位于 op-core/fees/fees.go包注释说明它覆盖从 Bedrock 到 Fjord 的 L1 成本函数以及 Isthmus 和 Jovian 的 operator-fee 公式且是纯粹针对字节数和大整数的算术便于跨实现复现。关键数据结构与常量// L1 表示所需字节计数 type RollupCostData struct { Zeroes, Ones uint64 FastLzSize uint64 } // Ecotone 与 Fjord 下定价数据可用性的 L1 基础费、blob 基础费及标量 type L1FeeParams struct { L1BaseFee *big.Int L1BlobBaseFee *big.Int BaseFeeScalar *big.Int BlobFeeScalar *big.Int } // Fjord 线性回归系数由 FastLZ 尺寸估计压缩后 DA 尺寸 L1CostIntercept big.NewInt(-42_585_600) L1CostFastlzCoef big.NewInt(836_500) // Fjord 下 DA 尺寸估计的钳制下限 MinTransactionSize big.NewInt(100)从源码可以看出各硬分叉的费用模型演进常量ecotoneDivisor 1_000_000 * 16与fjordDivisor 1_000_000_000_000分别对应 Ecotone 与 Fjord 的成本除数100% 与 1%体现了 Fjord 将标量单位从百万分之一缩小到万亿分之一的历史演进Fjord 不再按原始字节计数而是用 FastLZ 压缩长度做线性回归L1CostInterceptL1CostFastlzCoef来估计压缩后的 DA 尺寸并钳制到MinTransactionSize100 字节下限一个重要的费用豁免TxRollupCostData中明确deposit 交易不产生任何 DA 成本if tx.Type() types.DepositTxType { return RollupCostData{} }且成本数据从交易的完整二进制编码而非仅 calldata派生。L1FeeParams的注释指出这些参数从 L1-block-info 属性或 L1Block / gas-price-oracle 预部署中一并读取——即链内每条 L2 交易执行时L1 基础费与标量来自本块携带的 L1 块信息而非外部查询这是保证执行确定性的关键设计。核心概念Sequencer Fee Vault 与 EIP 实现Sequencer Fee VaultL2 执行费用的归集器。L2 上常规 gas 费用不再像 L1 那样销毁而是进入该金库供排序器运营方/治理提取。EIP 实现以 L2 适配的方式承接上游 EIP。OP Stack 并不原封不动地应用上游以太坊的升级而是在移植时叠加 L2 特化修改例如 Deposit 交易对 gas 语义的影响这也是执行层开发中最容易引入分叉语义差异的部分。执行层开发必须遵守的不变量文档 docs/ai/execution-layer.md 列出了四条不可违背的不变量它们是代码评审与回归验证的底线Deposit 必成功Deposit 交易在执行层面永远不会因 gas 而 revert且 Deposit 处理不得破坏标准 EVM 执行路径。这一不变量与DepositTx.IsSystemTransaction字段系统交易豁免 L2 gas 上限共同构成了 deposit 与普通交易在 gas 语义上的差异边界。L1 费用精确性L1 费用计算必须与链上 L1 oracle完全一致——op-core/fees作为纯算术参考实现正是为了可以对着它做逐值比对测试。确定性状态转换函数是确定性的同样的输入在 op-reth 与 kona-client 执行路径之间必须产生完全相同的结果。从源码结构看两条路径共享op-revmOpEvm/OpSpecId与op-alloy并刻意让 kona 证明二进制不内嵌 op-reth正是为了缩小两条路径产生分歧的攻击面。Gas 上限执行区块 gas 上限的强制执行必须把 Deposit 交易考虑在内尤其系统 deposit 豁免 L2 gas 上限的规则。与上游执行层的关键差异相对上游 Ethereum 执行OP Stack 的差异集中在四点Deposit 交易类型0x7E的处理——类型定义、编码与解码见 op-core/types/deposit_tx.go费用模型修改L1 数据费与 operator fee参考实现见 op-core/fees/fees.go排序器专属的区块构建sequencer-specific block buildingOP 硬分叉调度Canyon、Ecotone、Fjord、Granite、Holocene、Isthmus 等。分叉名称与排序在 op-core/forks/forks.go 中定义All列表按Bedrock, Regolith, Canyon, Ecotone, Fjord, Granite, Holocene, Isthmus排列From/Until等辅助函数用于计算分叉区间的激活范围。Rust 侧对应rust/op-reth/crates/hardforkscrate 与op-revm的OpSpecId规格映射。测试要求执行层改动的测试门禁与仓库中op-core/fees/fees_test.go、op-core/types/transaction_json_test.go、op-core/forks/forks_test.go等既有测试对应上游执行测试套件必须持续通过——OP 化不能破坏标准以太坊执行语义Deposit 交易测试覆盖所有边界情况mint、system 交易、gas 上限豁免等L1 费用计算测试对照已知参考值做逐值验证状态转换一致性测试op-reth 与 kona-client 执行路径之间的执行结果必须一致。在仓库中定位执行层代码主题路径主执行层客户端Rustrust/op-rethcrateschainspec / hardforks / evm / payload / exex / txpool 等OP EVM 与规格定义rust/op-revm/src/evm.rs、rust/op-revm/src/spec.rs故障证明执行路径rust/kona/crates/proof/executorDeposit 交易类型Go 参考实现op-core/types/deposit_tx.goL1 费用参考实现op-core/fees/fees.goOP 硬分叉定义op-core/forks/forks.go、rust/op-reth/crates/hardforks相关 AI 文档docs/ai/fault-proofs.md、docs/ai/opgeth-decoupling.md需要特别说明的适用前提本文所有事实均以当前仓库快照为准。其中 op-geth 处于被移除、代码向 op-core 抽取的过渡状态——op-core/types中的*go-ethereum辅助函数明确标注为过渡期代码未来切换到上游 go-ethereum 后会被移除涉及 op-geth 解耦的改动请额外阅读 opgeth-decoupling.md。【免费下载链接】optimismOptimism is Ethereum, scaled.项目地址: https://gitcode.com/GitHub_Trending/op/optimism创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考