延迟执行和免费数据可用性
如今，免费数据可用性并不是一个问题。每个交易发送者必须为交易执行期间消耗的所有资源付费。链上放置的数据，包括 calldata 中的数据或 EIP-2930 访问列表中列出的条目，都会产生 gas 成本，使得发布数据时无法不支付费用。
以太坊目前通过要求验证者在对区块进行见证之前完全执行和验证区块中的每笔交易来保证每个区块的有效性。如果一笔交易在执行时没有足够的余额支付所需的 gas，则包含该交易的整个区块将变为无效。
然而，引入延迟执行（EIP-7886）修改了这个过程。在延迟执行下：
- 验证者在完全执行交易之前就对区块的有效性进行见证，依赖于预先检查。
- 因此，即使最初看似能够支付成本的交易在实际执行时缺乏足够资金，区块也必须保持有效。
例如，想象两个账户 A 和 B，各自提交交易（a 和 b）。交易 'a' 在区块中的顺序在 'b' 之前。如果交易 'a' 耗尽账户 B 的余额，那么交易 'b'，尽管最初看似有资金，在执行时变得无法支付，从而使区块无效。
查看最初设计的帖子此处。
延迟执行设计空间
引入延迟执行开启了几种设计可能性。
不同的变体各有其优点和缺点，以下我们主要关注以下类别：
- 发送者用户体验
- 构建者复杂性
- 分叉选择复杂性
- 静态验证
- FOCIL兼容性
- 区块打包效率
2.3 不退还 gas_left
取消 gas_left 退款将使伪造大量gas使用在经济上不可行，因为用户必须全额支付他们声明的gas限额，无论实际消耗多少。
这解决了FOCIL中的攻击，即构建者包含看似大型的交易——声明高gas限额——但最终执行成本很低，实际上是伪造了一个完整的区块以绕过包含列表。
显然，这个选项是一个相当激进的用户体验变更。
2.4 保留 gas_left 退款并使用乐观 gas_used
解决FOCIL不兼容性的另一种方法是通过结合预先验证和乐观证明。在这种方法中，我们引入一个新的区块头字段 block_gas_used，构建者必须设置该字段。执行后，我们验证 block_gas_used 是否与实际使用的gas匹配。如果不匹配，则区块被视为无效，必须被重组。
这将有利于FOCIL，因为验证者可以可靠地检查包含列表中的交易是否可以被添加到区块，基于声明的gas使用情况。
然而，与乐观证明相关的分叉选择复杂性仍然存在。一个 block_gas_used 不正确的区块不会成为规范区块，但我们可能仍然希望允许对这种区块的证明影响分叉选择。
| 方法 | 发送方用户体验 | 构建者复杂性 | 分叉选择复杂性 | 静态验证 | FOCIL兼容性 | 需要sum(tx.gas) < 区块gas限制 |
|---|---|---|---|---|---|---|
| (1) |  相同 | 相同 |  更高^ | 否 | 低（两阶段执行） | 否 |
| (2) 不退还gas_left | 始终支付全部tx.gas | 相同 | 无 | 是 | 是 | 是 |
| (2) 退还gas_left | 相同 | 相同 | 无 | 是 | 低（两阶段执行） | 是 |
| (2) 退还gas_left + (1)（乐观gas_used） | 相同 | 相同 | 更高^ | 否 | 是 | 否 |
| (2) 退还gas_left + (3) 针对声明的gas_used | 相同 | 资助coinbase | 无 | 是^^ | 是 | 否 |
| (3) 针对包含成本 | 相同 | 资助coinbase | 无 | 是 | 低（两阶段执行） | 否 |
| (4) | 相同 | 相同 | 无 | 是 | 低（两阶段执行） | 否 |
| (2) 退还gas_left + (4) 针对gas_used | 相同 | 相同 | 无 | 是 | 是 | 否 |
