延遲執行和免費資料可用性
如今，免費資料可用性並不是一個問題。每個交易傳送者必須為交易執行期間消耗的所有資源付費。鏈上放置的資料，包括 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 | 相同 | 相同 | 無 | 是 | 是 | 否 |
