3天后，以太坊將迎接這些重大變化

golem

Odaily资深作者

@web3_golem

2025-11-30 09:55

本文約15884字，閱讀全文需要約23分鐘

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

原文來自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 提案。

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 消耗也不得超過1,670 萬。其目的是確保每個區塊可以容納多筆交易，而不是讓單筆交易佔據整個區塊。

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

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

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

這項EIP 也維持了與現有Gas 機制的兼容性。大多數用戶不會注意到這項變化，因為幾乎所有現有交易消耗的Gas 都遠低於1,600 萬。驗證者和區塊創建者仍然可以創建總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 簽名。