以太坊 Fusaka 主網升級本週啟動，深入解析 9 大 EIP

硬核詳解 Fusaka 升級的 9 大 EIP 提案。

原文標題：“Ethereum Fusaka Hard Fork: What’s Changing?“
作者：Sahil Sojitra
編譯：Odaily 星球日報 Golem（@web 3_golem）

計劃於 2025 年 12 月 3 日激活的 Fusaka 硬分叉是以太坊繼 Pectra 之後的又一次重大網路升級，標誌著這家加密巨頭又向擴容邁出了重要一步。

Pectra 升級的 EIP 專注於提升性能、安全性和開發者工具。Fusaka 升級的 EIP 則注重擴容、操作碼更新和執行安全性等方面。

PeerDAS（EIP-7594）透過允許節點在無需下載所有數據的情況下驗證 Blob，提高了數據可用性。多項升級也加強了執行安全性，包括限制 ModExp（EIP-7823）、限制交易 Gas 限額 (EIP-7825) 以及更新 ModExp Gas 成本 (EIP-7883)。此次 Fusaka 升級還透過確定性提議者前瞻機制 (EIP-7917) 改進了區塊生成，並透過設置與執行成本掛鉤的「保留價格」來保持 Blob 費用的穩定 (EIP-7918) 。

其他增強功能包括限制 RLP 格式的區塊大小 (EIP-7934)、添加新的 CLZ 操作碼以加快位操作速度 (EIP-7939)，以及引入 secp256r1 預編譯 (EIP-7951) 以更好地兼容現代密碼學和硬體安全密鑰。

Fusaka 是 Fulu（執行層）和 Osaka（共識層）的組合名稱。它代表著以太坊向高度可擴展、數據豐富的未來邁出的又一步，在這個未來中，Layer 2 Rollup 可以以更低的成本和更快的速度運行。

本篇文章將深入剖析 Fusaka 硬分叉的 9 大核心 EIP 提案。

Table of Contents

EIP-7594：PeerDAS ——節點數據可用性採樣

以太坊需要這項提案，因為網路希望為用戶（尤其是 Rollup 用戶）提供更高的數據可用性。

然而，在目前的 EIP-4844 設計下，每個節點仍然需要下載大量的 blob 數據才能驗證是否已發布。這造成了擴展性問題，因為如果所有節點都必須下載所有數據，網路的頻寬和硬體需求就會增加，去中心化程度也會受到影響。為了解決這個問題，以太坊需要一種方法，讓節點無需下載所有數據即可確認數據是否可用。

數據可用性採樣 (DAS) 透過允許節點僅檢查少量隨機數據來解決這個問題。

但以太坊還需要一種與現有 Gossip 網路相容的 DAS 方法，並且不會為區塊生產者增加繁重的運算負擔。 PeerDAS 的創建正是為了滿足這些需求，並在保持節點需求較低的情況下安全地提高 blob 吞吐量。

PeerDAS 是一種網路系統，它允許節點僅下載少量數據片段來驗證完整數據是否已發布。節點無需下載全部數據，而是利用常規的 gossip 網路共享數據，發現哪些節點持有特定部分的數據，並僅請求所需的小樣本。其核心思想是，透過僅下載數據片段中隨機的小部分，節點仍然可以確信整個數據片段的存在。例如，節點可能只下載大約 1/8 的數據，而不是下載完整的 256 KB 數據片段——但由於許多節點會採樣不同的部分，因此任何缺失的數據都會很快被發現。

為了實現取樣，PeerDAS 使用一種基本的糾刪碼對 EIP-4844 中的每個數據片段進行擴展。糾刪碼是一種添加額外冗餘數據的技術，即使某些數據片段缺失，也能恢復原始數據——類似於拼圖即使丟失幾塊也能拼完整。

blob 會變成一個「行」，其中包含原始數據以及一些額外的編碼數據，以便後續能夠重建數據。然後，這一行會被分割成許多稱為「單元格」的小塊，單元格是與 KZG 承諾關聯的最小驗證單元。所有「行」隨後會被重新組織成「列」，每列包含來自所有行的相同位置的儲存格。每列都被分配到一個特定的 gossip 子網。

節點負責根據其節點 ID 儲存某些列，並在每個時隙從對等節點採樣一些列。如果一個節點收集到至少 50% 的列，它就可以完全重建數據。如果收集到的列少於 50%，它需向對等節點要求缺少的列。這確保了如果數據確實已發布，則始終可以重建。簡而言之，如果總共有 64 列，一個節點只需要大約 32 列即可重建完整的 blob。它自己保留一些列，並從對等節點下載一些列。只要網路中存在一半的列，節點就能重建所有內容，即使某些列缺失。

此外，EIP-7594 還引入了一條重要規則：任何交易都不能包含超過 6 個 blob。此限制必須在交易驗證、gossip 傳播、區塊創建和區塊處理期間強制執行。這有助於減少單個交易導致 blob 系統過載的極端情況。

PeerDAS 增加了一種稱為「單元 KZG 證明」的功能。單元 KZG 證明表明 KZG 承諾確實與 blob 中的一個特定 cell（一小單元）匹配。這使得節點可以僅下載它想要採樣的 cell。在保證數據完整性的前提下，獲取完整的 blob，這對於數據可用性採樣至關重要。

但是，生成所有這些單元證明的成本很高。區塊生產者需要對許多 blob 反覆計算這些證明，這使得速度太慢。不過，證明驗證的成本非常低，因此，EIP-7594 要求 blob 交易發送者預先生成所有單元證明，並將其包含在交易包裝器中。

正因如此，交易 gossip（PooledTransactions）現在使用了一個修改過的包裝器：

rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])

在新包裝器中，cell_proofs 只是一個列表，其中包含每個 blob 的每個單元的所有證明（例如：[cell_proof_0, cell_proof_1, …]）。其他字段 tx_payload_body、blobs 和 commitments 與 EIP-4844 中的完全相同。差異在於，原有的單個「proofs」字段被移除，並替換為新的 cell_proofs 列表，同時新增了一個名為 wrapper_version 的字段，用於指示當前使用的包裝器格式。

PeerDAS 使以太坊能夠在不增加節點工作量的情況下提高數據可用性。如今，一個節點只需採樣大約 1/8 的總數據。未來，這一比例甚至可能降至 1/16 或 1/32，從而提升以太坊的可擴展性。該系統運行良好，因為每個節點都擁有眾多對等節點，因此，如果某個對等節點無法提供所需數據，該節點可以向其他對等節點請求。這自然地建立了冗餘機制，並提高了安全性，節點還可以選擇儲存超出實際需求的數據，這進一步增強了網路的安全性。

驗證節點比普通全節點承擔更多責任。由於驗證節點本身運行著效能更強的硬件，PeerDAS 會根據驗證節點的總數，為其分配相應的數據託管負載。這確保始終有穩定的節點組可用於儲存和共享更多數據，從而提升網路的可靠性。簡而言之，如果有 90 萬個驗證節點，則每個驗證節點可能被分配一小部分總數據進行儲存和服務。由於驗證節點擁有更強大的機器，網路可以信任它們能夠確保數據的可用性。

PeerDAS 使用列採樣而非行採樣，因為這樣可以大幅簡化數據重建。如果節點對整行（整個 blob）進行採樣，則需要創建原本不存在的額外「擴展 blob」，這會減慢區塊生產者的速度。

透過列採樣，節點可以預先準備額外的行數據，並且由交易發送者（而非區塊生產者）計算必要的證明。這可以保持區塊創建的速度和效率。例如：假設一個 blob 是一個 4×4 的單元格網格。行採樣意味著從一行中取出所有 4 個單元格，但某些擴展行尚未準備就緒，因此區塊生產者必須現場生成它們；列採樣則是從每一行（每一列）中抽取一個單元格，重建所需的額外單元格可以預先準備好，這樣節點就可以在不減慢區塊生成速度的情況下驗證數據。

EIP-7594 與 EIP-4844 完全相容，因此不會破壞以太坊上的任何現有功能。所有測試和詳細規則都包含在共識和執行規範中。

任何 DAS 系統的主要安全風險是「資料隱藏攻擊」，即區塊生產者假裝數據可用，但實際上隱藏了部分資料。PeerDAS 透過使用隨機抽樣來防止這種情況：節點檢查數據的隨機部分。抽樣的節點越多，攻擊者就越難作弊。EIP-7594 甚至提供了一個公式，可以根據節點總數 (n)、樣本總數 (m) 和每個節點的樣本數 (k) 來計算此類攻擊成功的可能性。在擁有約 10,000 個節點的以太坊主網上，攻擊成功的機率極低，因此 PeerDAS 被認為是安全的。

EIP-7823：為 MODEXP 設置 1024 字節上限

這項提案的必要性在於，以太坊目前的 MODEXP 預編譯機制多年來導致了許多共識漏洞。這些漏洞大多源於 MODEXP 允許輸入數據量極其龐大且不切實際，導致客戶端必須處理無數異常情況。

由於每個節點都必須處理交易提供的所有輸入，因此沒有上限使得 MODEXP 更難測試、更容易出錯，並且更容易在不同的客戶端上表現不同。過大的輸入數據也使得 gas 成本公式難以預測，因為當數據量可以無限成長時，很難對其進行定價。這些問題也使得未來使用 EVMMAX 等工具將 MODEXP 替換為 EVM 級別的代碼變得困難，因為如果沒有固定的限制，開發者就無法創建安全且優化的執行路徑。

為了減少這些問題並提高以太坊的穩定性，EIP-7823 為 MODEXP 輸入數據量添加了嚴格的上限，從而使預編譯過程更加安全、易於測試且更可預測。

EIP-7823 引入了一條簡單的規則：MODEXP 使用的所有三個長度字段（基數、指數和模數）都必須小於等於 8192 位，即 1024 字節。MODEXP 輸入遵循 EIP-198 中定義的格式：<len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS>，因此該 EIP 僅限制長度值。如果任何長度超過 1024 字節，預編譯將立即停止，返回錯誤並消耗所有 gas。

例如，如果有人嘗試提供一個 2000 字節長的基數，則調用將在任何工作開始之前失敗。這些限制仍然能夠滿足所有實際應用場景。RSA 驗證通常使用 1024 位、2048 位或 4096 位等密鑰長度，這些長度都在新限制範圍內。橢圓曲線運算使用較小的輸入大小，通常小於 384 位，因此也不受影響。

這些新的限制也有助於未來的升級。如果未來使用 EVMMAX 將 MODEXP 重寫為 EVM 代碼，開發者可以為常見的輸入大小（例如 256 位元、381 位或 2048 位）添加優化路徑，並為罕見情況使用較慢的回退方案。透過固定最大輸入大小，開發者甚至可以為非常常見的模數添加特殊處理。先前，由於輸入大小不受限制，設計空間過於龐大，難以安全管理，因此這些都無法實現。

為了確認此更改不會破壞過去的交易，作者分析了從區塊 5,472,266（2018 年 4 月 20 日）到區塊 21,550,926（2025 年 1 月 4 日）的所有 MODEXP 使用情況。結果顯示，歷史上所有成功的 MODEXP 調用都沒有使用過超過 513 字節的輸入，遠低於新的 1024 字節限制。大多數實際調用都使用了較小的長度，例如 32 字節、128 字節或 256 字節。

存在一些無效或損壞的調用，例如空輸入、填充了重複字節的輸入，以及一個非常大但無效的輸入。這些調用在新限制下的行為也是無效的，因為它們本身就是無效的。因此，雖然 EIP-7823 在技術上是一個重大變更，但實際上它不會改變任何過去交易的結果。

從安全角度來看，減少允許的輸入大小並不會帶來新的風險。相反，它消除了先前導致客戶端之間出現錯誤和不一致的不必要極端情況。透過將 MODEXP 輸入限制在合理的大小範圍內，EIP-7823 使系統更具可預測性，減少了奇怪的極端情況，並降低了不同實現之間出錯的機率。這些限制也有助於做好準備，如果未來的升級（例如 EVMMAX）引入了最佳化的執行路徑，則該系統能夠實現更平滑的過渡。

EIP-7825：交易 1670 萬 Gas 上限

以太坊確實也需要這項提案，因為目前單筆交易幾乎可以消耗整個區塊的 Gas 上限。

這會造成幾個問題：一筆交易可能消耗掉區塊的大部分資源，導致類似 DoS 攻擊的緩慢延遲；耗費大量 Gas 的操作會過快地增加以太坊的狀態更新；區塊驗證速度變慢，節點難以跟上。

如果一個用戶提交了一筆幾乎消耗所有 Gas 的巨額交易（例如，一筆在 4000 萬 Gas 的區塊中消耗 3800 萬 Gas 的交易），那麼其他普通交易就無法放入該區塊，每個節點都必須花費額外的時間來驗證該區塊。這會威脅到網路的穩定性和去中心化，因為驗證速度變慢意味著效能較弱的節點會落後。為了解決這個問題，以太坊需要一個安全的 Gas 上限，限制單筆交易可以使用的 Gas 數量，從而使區塊負載更加可預測，降低 DoS 攻擊的風險，並使節點的負載更加平衡。

EIP-7825 引入了一條硬性規則：任何交易消耗的 Gas 不得超過 16,777,216 (2²⁴)。這成為協議層面的上限，意味著它適用於所有環節：用戶發送交易、交易池檢查交易以及驗證者將交易打包進區塊。如果有人發送的 Gas 上限超過此值，用戶端必須立即拒絕該交易，並返回類似 MAX_GAS_LIMIT_EXCEEDED 的錯誤。

此上限與區塊 Gas 上限完全獨立。例如，即使區塊 Gas 上限為 4,000 萬，任何單筆交易的 Gas 消耗也不得超過 1670 萬。其目的是確保每個區塊可以容納多筆交易，而不是讓單筆交易佔據整個區塊。

為了更好地理解這一點，假設一個區塊可以容納 4000 萬 Gas。如果沒有此上限，有人可能會發送一筆消耗 3500 萬到 4000 萬 Gas 的交易。該交易會壟斷區塊，不給其他交易留下任何空間，就像一個人包下整輛巴士，其他人都無法上車一樣，新的 1670 萬 Gas 上限將使區塊自然容納多筆交易，從而避免此類濫用行為。

該提案還對客戶端如何驗證交易提出了具體要求。如果交易的 Gas 超過 16,777,216，交易池必須拒絕該交易，這意味著此類交易甚至不會進入隊列。在區塊驗證過程中，如果區塊中包含超過上限的交易，則該區塊本身必須被拒絕。

選擇 16,777,216 (2²⁴) 這個數字是因為它是一個清晰的 2 的冪次方邊界，便於實現，而且它仍然足夠大，可以處理大多數實際交易。例如智慧合約部署、複雜的 DeFi 交互或多步驟合約調用。這個值大約是典型區塊大小的一半，這意味著即使是最複雜的交易也能輕鬆控制在這個限制範圍內。

這項 EIP 也保持了與現有 Gas 機制的兼容性。大多數用戶不會注意到這項變化，因為幾乎所有現有交易消耗的 Gas 都遠低於 1600 萬。驗證者和區塊創建者仍然可以創建總 Gas 超過 1670 萬的區塊，只要每筆交易都遵守新的上限即可。

唯一受影響的交易是之前試圖使用超過新限制的超大交易。這些交易現在必須拆分成多個較小的操作，類似於將一個非常大的文件上傳拆分成兩個較小的文件。從技術上講，這項更改對於這些罕見的極端交易並不向下兼容，但預計受影響的用戶數量將非常少。

在安全性方面，Gas 上限使以太坊更能抵禦基於 Gas 的 DoS 攻擊，因為攻擊者無法再強迫驗證者處理超大交易。它還有助於保持區塊驗證時間的可預測性，從而使節點更容易保持同步。主要極端情況是，少數規模非常大的合約部署可能無法滿足上限要求，需要重新設計或分割為多個部署步驟。

整體而言，EIP-7825 旨在加強網路防範濫用，保持節點需求合理，提高區塊空間使用的公平性，並確保隨著 Gas 上限提高，區塊鏈仍能保持快速穩定運作。

EIP-7883：ModExp Gas 費用上漲

以太坊需要這項提案的原因是，ModExp 預編譯（用於模冪運算）的價格與其實際消耗的資源相比一直偏低。

在某些情況下，ModExp 操作所需的計算量遠遠超過用戶目前支付的費用。這種不匹配會帶來風險：如果複雜的 ModExp 調用價格過低，它們可能會成為瓶頸，使網路難以安全地提高 Gas 上限。因為區塊生產者可能被迫以極低的成本處理極其繁重的操作。

為了解決這個問題，以太坊需要調整 ModExp 的定價公式，讓 Gas 消耗能夠準確反映客戶端實際完成的工作量。因此，EIP-7883 引入了新的規則，提高了最低 Gas 成本、提高了總 Gas 成本，並使輸入數據量較大的操作（尤其是超過 32 字節的指數、底數或模數運算）更加昂貴，從而使 Gas 定價與實際所需的計算量相匹配。

該提案透過幾個重要方面提高了成本，從而修改了最初在 EIP-2565 中定義的 ModExp 定價算法。

首先，最低 Gas 消耗從 200 提高到 500，並且總 Gas 消耗不再除以 3，這意味著總 Gas 消耗實際上增加了三倍。例如，如果先前一個 ModExp 調用需要消耗 1200 gas，那麼在新公式下，它現在將需要消耗大約 3600 gas。

其次，指數大於 32 字節的運算成本翻倍，這是因為乘數從 8 增加到了 16。舉例來說，如果指數長度為 40 字節，EIP-2565 會將迭代次數增加 8 × (40 − 32) = 64 次，而 EIP-7883 現在使用 16 × (40 − 32) = 128 次，成本翻了一番。

第三，定價現在假定最小基數/模數大小為 32 字節，並且當這些值超過 32 字節時，計算成本會急劇增加。例如，如果模數為 64 字節，則新規則應用雙倍複雜度 (2 × words²)，而不是以前更簡單的公式，從而反映了大數運算的實際成本。這些更改共同確保了小型 ModExp 運算支付合理的最低費用，並且大型、複雜的運算的成本會根據其大小進行適當的調整。

該提案定義了一個新的 Gas 計算函數，更新了複雜度和迭代次數規則。乘法複雜度現在對基數/模數長度不超過 32 字節的情況使用預設值 16，而對於更大的輸入，則切換到更複雜的公式 2 × words²，其中「words」指的是 8 字節塊的數量。迭代次數也進行了更新，使得 32 字節或更小的指數使用其位長度來確定複雜度，而大於 32 字節的指數則會增加更大的 Gas 懲罰。

這確保了實際計算成本很高的超大指數現在具有更高的 Gas 成本。重要的是，返回的最小 Gas 成本被強制設定為 500，而不是先前的 200，這使得即使是最簡單的 ModExp 調用也更加合理。

這些價格上漲的動機源於基準測試，該測試顯示在許多情況下 ModExp 預編譯的定價明顯偏低。修訂後的公式將小型操作的 Gas 費用提高 150%，典型操作提高約 200%，而大型或不平衡操作的 Gas 費用則提高更多倍，有時甚至超過 80 倍，具體取決於指數、底數或模數的大小。

此舉的目的並非改變 ModExp 的工作原理，而是為了確保即使在資源消耗最大的極端情況下，它也不會再威脅網路穩定性或阻礙未來區塊 Gas 上限的提升。由於 EIP-7883 更改了 ModExp 所需的 Gas 數量，因此它不向後相容，但 Gas 重定價在以太坊中已多次發生，並且已被充分理解。

測試結果表明，此次 Gas 費用的提升幅度非常顯著。大約 99.69% 的歷史 ModExp 調用現在要麼需要 500 Gas（之前為 200 Gas），要麼需要之前價格的三倍。但某些高負載測試用例的 Gas 費用漲幅更大。例如，在一個「指數運算密集型」測試中，Gas 消耗從 215 躍升至 16,624，大約增加了 76 倍，這是因為現在對極大指數的定價更加合理。

在安全性方面，該提案不會引入新的攻擊途徑，也不會降低任何運算的成本。相反，它著重於防範一個重要的風險：定價過低的 ModExp 運算可能使攻擊者能夠以極低的成本在區塊中填充極其繁重的計算。唯一可能的缺點是某些 ModExp 運算的價格可能會過高，但這遠比目前定價過低的問題要好得多。該提案沒有引入任何接口變更或新功能，因此現有的算術行為和測試向量仍然有效。

EIP-7917：準確預言下一提議者

以太坊需要這項提案，因為網路下一 epoch 的提議者調度無法完全預測。即使在第 N 個 epoch 已知第 N+1 個 epoch 的 RANDAO 種子，實際的提議者列表仍然可能因第 N 個 epoch 內的有效餘額 (EB) 更新而發生變化。

這些 EB 變化可能來自罰沒、懲罰、超過 1 ETH 的獎勵、驗證者合併或新的存款，尤其是在 EIP-7251 將最大有效餘額提高到 32 ETH 以上之後。這種不確定性給那些依賴於提前知道下一個提議者的系統（例如基於預確認的協議）帶來了問題，這些系統需要穩定且可預測的時間表才能順利運作。驗證者甚至可能試圖「刷」或操縱其有效餘額，以影響下一個 epoch 的提議者。

由於這些問題，以太坊需要一種方法來使提議者時間表在未來幾個 epoch 內完全確定，使其不會因最後一刻的 EB 更新而改變，並且易於被應用層訪問。

為了實現這一點，EIP-7917 引入了一種確定性的提議者前瞻機制，即在每個 epoch 開始時預先計算並儲存接下來 MIN_SEED_LOOKAHEAD + 1 個 epoch 的提議者調度。簡單來說，信標狀態現在包含一個名為 `prosoperer_lookahead` 的列表，該列表始終涵蓋兩個完整週期的提議者（總共 64 個時隙）。

例如，當 epoch N 開始時，該列表已經包含了 epoch N 和 epoch N+1 中每個時隙的提議者。然後，當網路進入週期 N+1 時，該列表會向前移動：移除週期 N 的提議者條目，將週期 N+1 的條目移到列表前面，並在列表末尾新增週期 N+2 的新提議者條目。這使得調度固定、可預測，並且客戶端可以直接讀取，而無需每個時隙都重新計算提議者。

為了保持更新，列表會在每個 epoch 邊界處向前移動：移除上一個 epoch 的數據，並計算下一個未來 epoch 的一組新的提議者索引並添加到列表中。該過程使用與之前相同的種子和有效餘額規則，但現在調度計算得更早，從而避免了在種子確定後有效餘額變化對其產生影響。分叉後的第一個區塊也會填滿整個前瞻範圍，以確保所有未來的 epoch 都擁有正確初始化的調度。

假設每個 epoch 有 8 個槽位而不是 32 個（為了簡化起見）。如果沒有這項 EIP，在第 5 個 epoch 期間，雖然您知道第 6 個 epoch 的種子，但如果驗證者被罰沒或獲得足夠的獎勵以改變其在第 5 個 epoch 期間的有效餘額，則第 6 個 epoch 的槽位 2 的實際提議者仍然可能發生變化。有了 EIP-7917，以太坊會在第 5 個 epoch 開始時預先計算第 5、6 和 7 個 epoch 的所有提議者，並按順序存儲在 `prosopers_lookahead` 中。那麼即使餘額在第 5 個 epoch 後期發生變化，第 6 個 epoch 的提議者列表也保持固定且可預測。

EIP-7917 修復了信標鏈設計中長期存在的缺陷。它保證一旦先前 epoch 的 RANDAO 可用，未來 epoch 的驗證者選擇就無法更改。這也防止了「有效餘額刷取」，即驗證者在看到 RANDAO 後試圖調整其餘額以影響下一個 epoch 的提議者列表。確定性前瞻機制消除了整個攻擊向量，大大簡化了安全分析。它還使共識客戶端能夠提前了解誰將提議即將到來的區塊，這有助於實現，並允許應用層透過信標根的默克爾證明輕鬆驗證提議者日程。

在此提案之前，客戶端僅計算當前時隙的提議者。有了 EIP-7917，它們現在會在每個 epoch 轉換期間一次性計算下一個 epoch 所有時隙的提議者列表。這會增加少量工作，但計算提議者索引非常輕量級，主要涉及使用種子對驗證者列表進行採樣。然而，客戶端需要進行基準測試，以確保此額外計算不會導致效能問題。

EIP-7918：Blob 基礎費用受執行成本限制

以太坊需要這項提案，因為目前的 Blob 費用系統（源自 EIP-4844）在執行 Gas 成為 Rollup 的主要成本時會失效。

目前，大多數 Rollup 支付的執行 Gas（將 Blob 交易包含在區塊中的成本）遠高於實際的 Blob 費用。這造成了一個問題：即使以太坊不斷降低 Blob 基礎費用，Rollup 的總成本實際上並沒有改變，因為成本最高的部分仍然是執行 Gas。因此，Blob 基礎費用會持續下降，直到達到絕對最低值（1 wei），此時協議將無法再利用 Blob 費用來控制需求。然後，當 Blob 使用量突然上升時，Blob 費用需要經過大量區塊才能恢復到正常水準。這使得價格不穩定，對用戶而言難以預測。

例如，假設一個 Rollup 想要發布其數據：它需要支付大約 25,000,000 gwei 的執行 Gas（大約 1,000,000 gas 需要 25 gwei），而 Blob 費用僅約為 200 gwei。這意味著總成本約為 25,000,200 gwei，其中幾乎全部成本都來自執行 Gas，而非 Blob 費用。如果以太坊持續降低 Blob 費用，例如從 200 gwei 降至 50 gwei，再降至 10 gwei，最終降至 1 gwei，總成本幾乎也不會改變，仍然保持在 25,000,000 gwei。

EIP-7918 透過引入一個基於執行基礎費用的最低「保留價格」來解決這個問題，從而防止 Blob 價格過低，並使 Rollup 的 Blob 定價更加穩定和可預測。

EIP-7918 的核心思想很簡單：Blob 的價格永遠不應低於一定數量的執行 Gas 成本（稱為 BLOB_BASE_COST）。 calc_excess_blob_gas() 的值被設定為 2¹³，該機制透過對 calc_excess_blob_gas() 函數進行微小的修改來實現。

通常，該函數會根據區塊使用的 blob gas 是否高於或低於目標值來增加或減少 Blob 基礎費用。根據此提案，如果 Blob 相對於執行 Gas 變得「過低」，該函數將停止扣除目標 blob gas。這使得多餘的 blob gas 成長得更快，從而防止 Blob 基礎費用進一步下降。因此，Blob 基礎費用現在有一個最小值，等於 BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB。

為了理解為什麼需要這樣做，我們可以看看 Blob 的需求。Rollup 關注的是它支付的總成本：執行成本加上 blob 成本。如果執行 Gas 費用非常高，例如 20 gwei，那麼即使 Blob 費用從 2 gwei 降到 0.2 gwei，總成本也幾乎不變。這意味著降低 Blob 基礎費用對需求幾乎沒有影響。在經濟學中，這被稱為「費用缺乏彈性」。它造成了一種需求曲線幾乎垂直的情況：降低價格不會增加需求。

在這種情況下，Blob 基礎費用機制會變得盲目——即使需求沒有反應，它也會繼續降低價格。這就是為什麼 blob 基礎費用經常會降到 1 gwei 的原因。然後，當實際需求稍後增加時，協議需要一個小時或更長時間的幾乎滿區塊才能將費用提升到合理的水平。EIP-7918 透過建立與執行 Gas 掛鉤的儲備價格來解決這個問題，從而確保即使執行成本占主導地位，Blob 費用仍然有意義。

添加此保留價格的另一個原因是，節點需要做很多額外的工作來驗證 Blob 資料的 KZG 證明。這些證明保證了 Bob 中的數據與其承諾相符。在 EIP-4844 下，節點只需驗證每個 Blob 的一個證明，成本很低。但在 EIP-7918 中，節點需要驗證的證明數量更多。這全是因為在 EIP-7594 (PeerDAS) 中，blob 被分割成許多稱為 cell 的小塊，每個 cell 都有自己的證明，這使得驗證工作量大大增加。

從長遠來看，EIP-7918 也有助於以太坊為未來做好準備。隨著技術的進步，儲存和共享資料的成本自然會降低，以太坊預計會隨著時間的推移允許儲存更多 Blob 數據。當 Blob 容量增加時，Blob 費用（以 ETH 計）自然會下降。該提案支持這一點，因為保留價格與執行 Gas 價格掛鉤，而不是一個固定值，因此它可以根據網路的成長進行調整。

隨著 Blob 空間和執行區塊空間的擴展，它們的價格關係將保持平衡。只有在極少數情況下，以太坊大幅增加 Blob 容量但未增加執行 Gas 容量時，保留價格才可能過高。在這種情況下，Blob 費用最終可能會高於實際所需。但以太坊沒有計劃以這種方式擴展——Blob 空間和執行區塊空間預計將同步增長。因此，所選值 (BLOB_BASE_COST = 2¹³) 被認為是安全且平衡的。

當執行 Gas 費用突然飆升時，需要了解一個小細節。由於 Blob 的價格取決於執行基礎費用，執行成本的突然上升可能會暫時使 Blob 費用進入一種由執行成本主導的狀態。例如，假設執行 Gas 費用在一個區塊內突然從 20 gwei 躍升至 60 gwei。由於 Blob 的價格與該數值掛鉤，Blob 費用無法跌破新的更高水準。如果 Blob 仍在被使用，其費用仍會正常增長，但協議不會允許其下降，直到其增長到足以匹配更高的執行成本為止。這意味著在幾個區塊內，Blob 費用的成長速度可能會慢於執行成本。這種短暫的延遲並無害處——它實際上可以防止 Blob 價格出現劇烈的波動，並使系統更加平穩。

作者也對 2024 年 11 月至 2025 年 3 月的實際區塊交易活動進行了實證分析，應用了保留價格規則。在高執行費時期（平均約 16 gwei），與舊機制相比，儲備閾值顯著提高了區塊基礎費用。在低執行費時期（平均約 1.3 gwei），區塊費用幾乎保持不變，除非計算出的區塊基礎費用低於儲備價格。透過比較數千個區塊，作者表明，新機制在維持對需求自然響應的同時，也能創造更穩定的定價。四個月的區塊費用直方圖顯示，儲備價格防止區塊費用暴跌至 1 gwei，從而降低了極端波動。

就安全性而言，此變更也不會引入任何風險。基本區塊費用始終會等於或高於執行 Gas 的 BLOB_BASE_COST 單位成本。這是安全的，因為該機制僅提高了最低費用，而設定價格下限不會影響協議的正確性。它只是確保了健康的經濟運作。

EIP-7934：RLP 執行區塊大小限制

在 EIP-7934 之前，以太坊對 RLP 編碼的執行區塊的大小沒有嚴格的上限。理論上，如果區塊包含大量交易或非常複雜的數據，則其大小可能會非常大。這造成了兩個主要問題：網路不穩定和拒絕服務 (DoS) 攻擊風險。

如果區塊過大，節點下載和驗證它所需的時間就會更長，這會減慢區塊傳播速度並增加區塊鏈臨時分叉的可能性。更糟糕的是，攻擊者可以故意創建一個非常大的區塊來使節點過載，導致延遲甚至使其離線——這是一種典型的拒絕服務攻擊。同時，以太坊的共識層（CL）Gossip 協議已經拒絕傳播任何超過 10MB 的區塊，這意味著過大的執行區塊可能無法在網路中傳播，從而造成鏈上的碎片化或節點間的分歧。鑑於這些風險，以太坊需要一條清晰的協議級規則來防止區塊過大，並保持網路的穩定和安全。

EIP-7934 透過引入協議層級的 RLP 編碼執行區塊大小上限來解決這個問題。允許的最大區塊大小（MAX_BLOCK_SIZE）設置為 10 MiB（10,485,760 字節），但由於信標區塊也會佔用一些空間（SAFETY_MARGIN），以太坊在此基礎上增加了 2 MiB（2,097,152 字節）。

這意味著實際允許的最大 RLP 編碼執行區塊大小為 MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE – SAFETY_MARGIN。如果編碼後的塊大於此限制，則該塊將被視為無效，節點必須拒絕它。有了這條規則，區塊生產者必須檢查他們建立的每個區塊的編碼大小，驗證者必須在區塊驗證期間驗證此限制。此大小上限獨立於 Gas 限制，這意味著即使區塊「低於 Gas 限制」，如果其編碼大小過大，仍然會被拒絕。這確保了 Gas 使用量和實際字節大小限制都得到遵守。

選擇 10 MiB 的上限是有意為之，因為它與共識層 gossip 協議中現有的限制相匹配。任何大於 10 MiB 的數據都不會在網路中廣播，因此此 EIP 使執行層與共識層的限制保持一致。這確保了所有組件的一致性，並防止了由於 CL 拒絕傳播而導致有效執行區塊「不可見」的情況。

此變更不向下相容大於新限制的區塊，這意味著礦工和驗證者必須更新其客戶端以遵守該規則。然而，由於超大區塊本身就存在問題，且在實際運作中並不常見，因此影響微乎其微。

在安全性方面，EIP-7934 透過確保任何參與者都無法創建會使網路癱瘓的區塊，顯著增強了以太坊抵禦針對特定區塊大小的 DoS 攻擊的能力。總而言之，EIP-7934 增加了一條重要的安全邊界，提高了穩定性，統一了執行邏輯 (EL) 和 CL 的行為，並防止了與超大區塊的創建和傳播相關的多種攻擊。

EIP-7939：計算前導零 (CLZ) 操作碼

在此 EIP 之前，以太坊沒有內置的操作碼來計算 256 位數字中前導零的位數。開發者不得不使用 Solidity 手動實現 CLZ 函數，這需要大量的位移操作和比較。

這是一個很大的問題，因為自定義實現速度慢、成本高，而且會佔用大量字節碼，從而增加 Gas 消耗。對於零知識證明系統來說，成本更高，右移操作的證明成本極高，因此像 CLZ 這樣的操作會顯著降低零知識證明電路的運行速度。由於 CLZ 是一個非常常見的底層函數，廣泛應用於數學庫、壓縮算法、位圖、簽名方案以及許多加密或數據處理任務中，以太坊需要一種更快、更經濟的運算方法。

EIP-7939 透過引入一個名為 CLZ (0x1e) 的新操作碼解決了這個問題。此操作碼從棧中讀取一個 256 位的值，並傳回前導零的個數。如果輸入數字為零，則操作碼返回 256，因為一個 256 位的零有 256 個前導零。

這與 ARM 和 x86 等許多 CPU 架構中 CLZ 的工作方式一致，在這些架構中，CLZ 操作是原生支援的。添加 CLZ 可以顯著降低許多算法的開銷：lnWad、powWad、LambertW、各種數學函數、字節串比較、位圖掃描、調用數據壓縮/解壓縮以及後量子簽名方案等操作都能受益於更快的先行零檢測。

CLZ 的 gas 成本設定為 5，與 ADD 類似，並且略高於先前的 MUL 價格，以避免定價過低而導致拒絕服務 (DoS) 攻擊的風險。基準測試表明，CLZ 的計算量與 ADD 大致相同，並且在 SP1 rv32im 證明環境中，CLZ 的證明成本實際上比 ADD 更低，從而降低了零知識證明的成本。

EIP-7939 完全向後相容，因為它引入了一個新的操作碼，並且沒有修改任何現有行為。

總體而言，EIP-7939 透過添加一個現代 CPU 已支援的簡單高效的原語，使以太坊運行速度更快、成本更低，並且對開發者更加友好——降低 Gas 費用、減小字節碼大小，並降低許多常見操作的零知識證明成本。

EIP-7951：支援現代硬體的簽名

在此 EIP 之前，以太坊沒有安全、原生的方式來驗證使用 secp256r1 (P-256) 曲線建立的數位簽名。

該曲線是 Apple Secure Enclave、Android Keystore、HSM、TEE 和 FIDO2/WebAuthn 安全密鑰等現代設備使用的標準。由於缺少這種支持，應用程式和錢包無法輕鬆地使用設備級硬體安全進行簽名。先前曾有過一次嘗試 (RIP-7212)，但它存在兩個嚴重的安全漏洞，分別與無窮遠點處理和錯誤的簽名比較有關。這些問題可能導致驗證錯誤，甚至可能導致共識失敗。EIP-7951 修復了這些安全問題，並引入了一個安全、原生的預編譯程序，使以太坊最終能夠安全高效地支援來自現代硬體的簽名。

EIP-7951 在地址 0x100 處添加了一個名為 P256VERIFY 的新預編譯合約，該合約使用 secp256r1 曲線執行 ECDSA 簽名驗證。與直接在 Solidity 中實現該算法相比，這使得簽名驗證更加快速且成本更低。

EIP-7951還定義了嚴格的輸入驗證規則。如果存在任何無效情況，預編譯將傳回失敗，且不會回滾，消耗的 Gas 與成功調用相同。驗證算法遵循標準的 ECDSA：它計算 s⁻¹ mod n，重建簽名點 R’，如果 R’ 為無窮遠則拒絕，最後檢查 R’ 的 x 座標是否與 r (mod n) 匹配。這修正了 RIP-7212 中的錯誤，RIP-7212 直接比較了 r’，而不是先將其模 n 化簡。

該操作的 Gas 費用設定為 6900 gas，高於 RIP-7212 版本，但與 secp256r1 驗證的實際效能基準相符。重要的是，該接口與已部署 RIP-7212 的 Layer 2 網路完全相容（地址相同，輸入/輸出格式相同），因此現有的智慧合約將繼續正常運行，無需任何變更。唯一的區別在於修正後的行為和更高的 Gas 費用。

從安全角度來看，EIP-7951 恢復了 ECDSA 的正確行為，消除了預編譯級別的可塑性問題（將可選檢查留給應用程式），並明確指出預編譯不需要恆定時間執行。secp256r1 曲線提供 128 位安全性，並已獲得廣泛的信任和分析，因此可安全應用於以太坊。

簡而言之，EIP-7951 旨在安全地將現代硬體支援的身份驗證引入以太坊，修復早期提案的安全問題，並提供一種可靠、標準化的方式來驗證整個生態系統中的 P-256 簽名。