在 OP Mainnet 的区块浏览器里点开任意一个 L2 区块，你会看到一列交易的第一名签名栏空空如也：没有发件人签名，交易类型也不是常见的 0 到 2 型。它是充值交易（deposited transaction），规范给它的类型前缀是 0x7E。这类交易不是”某个人发到 L2 的一笔签名交易”，而是从以太坊某个区块推导出来的协议产物——理解这一点，OP Stack 的充值延迟和区块结构就都通了。
定义：发起于 L1、执行于 L2 的第二种交易
OP Stack 规范把交易分成两大方向：L2 发到 L1 的叫 withdrawal，L1 发进 L2、作为 L2 交易执行的叫 deposit。规范术语里，deposited transaction 特指那笔最终的 L2 交易本身。它有三个与普通 L2 交易不同的硬性质：第一，它由 L1 区块推导而来，协议要求每个 L2 区块必须包含这些交易，出块方无权跳过；第二，它不做签名验证，因为授权已经在 L1 上发生过——你在 L1 上转进 Portal 合约的那一刻，意图就已经被记录；第三，它的 L2 gas 是在 L1 上购买的，且不予退还。
字段表：0x7E 交易里装着什么
按规范定义，一笔 deposit 交易按顺序装着这些字段（RLP 编码）：sourceHash（唯一标识这笔充值来源的源哈希）、from（发送方地址）、to（接收方地址，若为空地址则表示这是一次合约创建）、mint（要在 L2 上铸造的 ETH 数额）、value（转账金额）、gas（L2 交易的 gas 上限），以及 isSystemTx（标记它是否是不占用区块 gas 池的系统交易）。用户普通充值的 isSystemTx 为 false，会正常消耗区块 gas 预算。sourceHash 的存在让每一笔充值交易都能回溯到 L1 上的具体事件来源，这是”推导”得以对账的锚点。
每个区块的第一笔：L1 属性交易
规范还定了一条硬规则：每个 L2 区块的第一笔交易必须是一笔 L1 属性充值交易（L1 attributes deposited transaction）。它的作用是把 L1 侧的关键上下文——那个 L1 区块的高度、时间戳、区块哈希、序列者费用相关数据——注入 L2 的执行环境，让 L2 的状态始终锚定在一条确定的 L1 历史之上。可以把它理解为每个区块自带的”时钟与坐标校准”。在这笔校准交易之后，才是零或多笔用户充值交易，而且规范限定：用户充值交易只出现在一个 L2 epoch 的第一个区块里——L1 上产生的一批事件，会集中进入 L2 对应时间段的开头。
事件即队列：交易从哪条日志里长出来
用户充值的源头，是 L1 上存根合约（deposit feed，即 OptimismPortal）发出的 TransactionDeposited 事件。事件里带着源哈希、from、to、mint 值、gas、是否创建合约、isSystemTx 以及一个递增的 depositNonce。L2 节点在推导区块时读取这些事件，逐条还原成 L2 交易执行，充值者的 Calldata 或初始化代码按其是否为合约创建分别处理。这里有一个对账实用的细节：depositNonce 会出现在交易的收据 JSON 里，当某笔充值是合约部署时，合约地址的推导也要靠这个 nonce 才能对上——因为这笔交易没有常规意义上的账户 nonce 可以借用。
和提款的分岔：一快一慢为什么合理
方向相反，机制代价完全不同。充值路径上，L1 事件一旦出现，节点推导区块时必须执行，所以充值是”确定性进场”，通常等 L1 确认加 L2 出块节奏就到了；提款则要走证明、挑战期、最终化三段（另一条流程），因为 L2 状态是否可信还需要时间检验。这也是排查时该分的第一岔：查充值不到，沿 L1 事件、目标 L2 区块、交易执行结果三步走；查提款不到，沿证明、挑战期、finalization 三步走。两条链路的每一步都在链上有对应对象可查，任何一方”处理慢”都可以被定位到具体环节而不是诉诸猜测。
风险提示：本文内容为区块链协议机制的科普性介绍，不构成任何投资建议、收益承诺或买卖时机判断。链上操作涉及资产安全，跨链与提现流程受协议版本、网络状态与合约升级影响，操作前请以官方文档和链上实际状态为准，并通过小额测试验证路径。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。