--- title: "富薩卡 🦓" metaTitle: Fulu-Osaka (富薩卡) description: 了解富薩卡協定升級 lang: zh-tw template: upgrade authors: ["Nixo", "馬里奧·哈維爾"] --- **以太坊備受期待的富薩卡升級已於 2025 年 12 月 3 日上線** 富薩卡網路升級接續在 [佩克特拉](/roadmap/pectra/) 之後，帶來了更多新功能，並改善了每位 [以太坊](/) 使用者與開發者的體驗。其名稱由執行層升級 Osaka（大阪）與以 Fulu（附路星）命名的共識層版本組成。以太坊的這兩個部分都獲得了升級，將以太坊的擴展性、安全性和使用者體驗推向未來。 富薩卡升級只是以太坊長期發展目標中的一步。了解更多關於[協定路線圖](/roadmap/)與[先前的升級](/ethereum-forks/)。 ## 富薩卡升級的改進 {#improvements-in-fusaka} ### 擴展資料塊 (blob) {#scale-blobs} #### PeerDAS {#peerdas} 這是富薩卡分叉的_重頭戲_，也是本次升級中加入的主要功能。第二層 (L2) 目前以資料塊的形式將其資料發佈到以太坊，這是專為第二層 (L2) 建立的短暫資料類型。在富薩卡之前，每個全節點都必須儲存每個資料塊，以確保資料存在。隨著資料塊吞吐量上升，必須下載所有這些資料變得極度消耗資源且難以維持。 透過[資料可用性取樣 (DAS)](https://notes.ethereum.org/@fradamt/das-fork-choice)，每個節點將只負責資料塊資料的一個子集，而不需要儲存所有的資料塊資料。資料塊在網路中的節點之間均勻隨機分佈，每個全節點僅持有 1/8 的資料，因此理論上可實現高達 8 倍的擴展。為了確保資料的可用性，任何部分的資料都可以從現有 50% 的整體資料中重建，這些方法將錯誤或遺失資料的機率降低到密碼學上可忽略的程度（約 1020 分之一到 1024 分之一）。 這使得節點的硬體和頻寬要求保持在可承受範圍內，同時實現資料塊擴展，從而為第二層 (L2) 帶來更大的擴展性與更低的費用。 [了解更多關於 PeerDAS 的資訊](/roadmap/fusaka/peerdas/) **資源**： - [EIP-7594 技術規範](https://eips.ethereum.org/EIPS/eip-7594) - [DappLion 談 PeerDAS：今日擴展以太坊 | ETHSofia 2024](https://youtu.be/bONWd1x2TjQ?t=328) - [學術：以太坊 PeerDAS 文件 (PDF)](https://eprint.iacr.org/2024/1362.pdf) #### 僅限資料塊參數 (Blob-Parameter-Only) 分叉 {#blob-parameter-only-forks} 第二層 (L2) 擴展了以太坊——隨著其網路的發展，它們需要向以太坊發佈更多資料。這意味著隨著時間推移，以太坊將需要增加可供它們使用的資料塊數量。雖然 PeerDAS 實現了資料塊資料的擴展，但這需要逐步且安全地進行。 因為以太坊是在數千個獨立節點上運行的程式碼，這些節點需要對相同的規則達成共識，我們不能像部署網站更新那樣，簡單地引入增加資料塊數量等變更。任何規則變更都必須是一次協調的升級，每個節點、客戶端和驗證者軟體都必須在同一個預定區塊之前進行升級。 這些協調的升級通常包含許多變更，需要大量測試，而這需要時間。為了更快地適應不斷變化的第二層 (L2) 資料塊需求，僅限資料塊參數分叉引入了一種機制，可以在不需等待該升級時程的情況下增加資料塊。 僅限資料塊參數分叉可以由客戶端設定，類似於 Gas 限制等其他配置。在以太坊的重大升級之間，客戶端可以同意將 `target` 和 `max` 資料塊增加到例如 9 和 12，然後節點營運者將進行更新以參與這個微小的分叉。這些僅限資料塊參數分叉可以隨時進行配置。 當資料塊在 Dencun 升級中首次被加入網路時，目標是 3。在佩克特拉中增加到了 6，而在富薩卡之後，現在可以獨立於這些重大網路升級，以可持續的速度增加。 ![Chart showing average blob count per block and increasing targets with upgrades](./average-blob-count-per-block.webp) 圖表來源：[Ethereum Blobs - @hildobby, Dune Analytics](https://dune.com/hildobby/blobs) **資源**：[EIP-7892 技術規範](https://eips.ethereum.org/EIPS/eip-7892) #### 受執行成本限制的 blob 基礎費用 {#blob-base-fee-bounded-by-execution-costs} 第二層 (L2) 在發佈資料時需要支付兩筆費用：blob 費用以及驗證這些資料塊所需的執行燃料。如果執行燃料佔主導地位，blob 費用拍賣可能會急劇下降至 1 Wei，並失去作為價格訊號的作用。 EIP-7918 在每個資料塊下固定了一個成比例的底價。當底價高於名目 blob 基礎費用時，費用調整演算法會將該區塊視為超出目標，停止壓低費用，並允許其正常增加。結果是： - blob 費用市場始終會對網路擁塞做出反應 - 第二層 (L2) 至少為其強加於節點的運算支付了有意義的份額 - 執行層 (EL) 上的基礎費用飆升不再會使 blob 費用停滯在 1 Wei **資源**： - [EIP-7918 技術規範](https://eips.ethereum.org/EIPS/eip-7918) - [Storybook 解說](https://notes.ethereum.org/@anderselowsson/AIG) ### 擴展第一層 (L1) {#scale-l1} #### 歷史記錄過期與更簡單的收據 {#history-expiry} 在 2025 年 7 月，以太坊執行客戶端[開始支援部分歷史記錄過期](https://blog.ethereum.org/2025/07/08/partial-history-exp)。這丟棄了早於[合併](https://ethereum.org/roadmap/merge/)的歷史記錄，以在以太坊持續增長的過程中，減少節點營運者所需的磁碟空間。 這個 EIP 被放在「核心 EIP」之外的獨立部分，因為該分叉實際上並未實施任何變更——這是一個通知，要求客戶端團隊必須在富薩卡升級前支援歷史記錄過期。實際上，客戶端可以隨時實施這一點，但將其加入升級中，具體地將其列入了他們的待辦事項清單，並使他們能夠結合此功能來測試富薩卡的變更。 **資源**：[EIP-7642 技術規範](https://eips.ethereum.org/EIPS/eip-7642) #### 設定 MODEXP 的上限 {#set-upper-bounds-for-modexp} 到目前為止，MODEXP 預編譯合約幾乎接受任何大小的數字。這使得它難以測試、容易被濫用，並對客戶端穩定性構成風險。EIP-7823 設定了明確的限制：每個輸入數字最長只能是 8192 位元（1024 位元組）。任何更大的數字都會被拒絕，交易的燃料將被銷毀，且不會發生任何狀態變更。它非常輕鬆地涵蓋了現實世界的需求，同時消除了使 Gas 限制規劃和安全審查複雜化的極端情況。這項變更提供了更高的安全性和 DoS 保護，而不會影響使用者或開發者的體驗。 **資源**：[EIP-7823 技術規範](https://eips.ethereum.org/EIPS/eip-7823) #### 交易 Gas 限制上限 {#transaction-gas-limit-cap} EIP-[7825](https://eips.ethereum.org/EIPS/eip-7825) 為每筆交易增加了 16,777,216 (2^24) 燃料的上限。這是一種主動的 DoS 強化措施，透過在我們提高區塊 Gas 限制時，限制任何單一交易的最壞情況成本。它使驗證和傳播更容易建模，讓我們能夠透過提高 Gas 限制來解決擴展問題。 為什麼剛好是 2^24 燃料？它明顯小於目前的 Gas 限制，但對於實際的合約部署和繁重的預編譯合約來說已經足夠大，而且 2 的次方使其易於在各個客戶端中實作。這個新的最大交易大小類似於佩克特拉之前的平均區塊大小，使其成為以太坊上任何操作的合理限制。 **資源**：[EIP-7825 技術規範](https://eips.ethereum.org/EIPS/eip-7825) #### `MODEXP` 燃料成本增加 {#modexp-gas-cost-increase} MODEXP 是一個預編譯合約內建函數，用於計算模冪運算，這是一種用於 RSA 簽章驗證和證明系統的大數數學。它允許合約直接執行這些計算，而無需自行實作。 開發者和客戶端團隊認為 MODEXP 是提高區塊 Gas 限制的主要障礙，因為目前的燃料定價通常低估了某些輸入所需的運算能力。這意味著一筆使用 MODEXP 的交易可能會佔用處理整個區塊所需的大部分時間，從而拖慢網路速度。 此 EIP 透過以下方式更改定價以符合實際運算成本： - 將最低收費從 200 提高到 500 燃料，並在一般成本計算中移除 EIP-2565 的三分之一折扣 - 當指數輸入非常長時，更大幅度地增加成本。如果指數（作為第二個參數傳遞的「次方」數字）長度超過 32 位元組 / 256 位元，每增加一個位元組，燃料收費的攀升速度會快得多 - 對較大的底數或模數也收取額外費用。另外兩個數字（底數和模數）假設至少為 32 位元組——如果其中任何一個更大，成本將按其大小比例上升 透過使成本更符合實際處理時間，MODEXP 不再會導致區塊驗證時間過長。這項變更是旨在確保未來安全提高以太坊區塊 Gas 限制的幾項措施之一。 **資源**：[EIP-7883 技術規範](https://eips.ethereum.org/EIPS/eip-7883) #### RLP 執行區塊大小限制 {#rlp-execution-block-size-limit} 這為區塊允許的最大尺寸設定了上限——這是對透過網路_傳送_內容的限制，與限制區塊內_工作量_的 Gas 限制是分開的。區塊大小上限為 10 MiB，並保留了少量額度 (2 MiB) 給共識資料，以便所有內容都能順利容納並乾淨地傳播。如果出現大於此限制的區塊，客戶端將會拒絕它。 這是必要的，因為非常大的區塊需要更長的時間在網路上傳播和驗證，可能會產生共識問題或被濫用為 DoS 攻擊媒介。此外，共識層的 gossip 協定已經不會轉發超過約 10 MiB 的區塊，因此將執行層與該限制對齊，可以避免出現「某些節點看到，其他節點丟棄」的奇怪情況。 具體細節：這是對 [RLP](/developers/docs/data-structures-and-encoding/rlp/) 編碼的執行區塊大小的上限。10 MiB 總共，其中保留 2 MiB 的安全餘裕用於信標區塊框架。實際上，客戶端定義了 `MAX_BLOCK_SIZE = 10,485,760` 位元組和 `SAFETY_MARGIN = 2,097,152` 位元組， 並拒絕任何 RLP 負載超過以下值的執行區塊： `MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN` 目標是限制最壞情況下的傳播/驗證時間，並與共識層 gossip 行為保持一致，在不改變燃料計算的情況下降低區塊鏈重組/DoS 風險。 **資源**：[EIP-7934 技術規範](https://eips.ethereum.org/EIPS/eip-7934) #### 將預設 Gas 限制設定為 6000 萬 {#set-default-gas-limit-to-60-million} 在 2025 年 2 月將 Gas 限制從 3000 萬提高到 3600 萬（隨後提高到 4500 萬）之前，這個數值自合併（2022 年 9 月）以來就沒有改變過。此 EIP 旨在將持續擴展作為優先事項。 EIP-7935 協調執行層 (EL) 客戶端團隊，在富薩卡升級中將預設 Gas 限制提高到目前 4500 萬以上。這是一個資訊型 EIP，但它明確要求客戶端在開發網上測試更高的限制，收斂到一個安全值，並在他們的富薩卡版本中發布該數字。 開發網規劃的目標是約 6000 萬的壓力測試（帶有合成負載的滿區塊）和迭代提升；研究表明，最壞情況下的區塊大小病態問題不應在約 1.5 億以下受到限制。推出時應搭配交易 Gas 限制上限 (EIP-7825)，這樣在限制提高時，就不會有單一交易佔據主導地位。 **資源**：[EIP-7935 技術規範](https://eips.ethereum.org/EIPS/eip-7935) ### 改善使用者體驗 (UX) {#improve-ux} #### 確定性提案者預視 {#deterministic-proposer-lookahead} 透過 EIP-7917，信標鏈將能預先知道下一個紀元即將到來的區塊提案者。對哪些驗證者將提案未來區塊擁有確定性的視角，可以實現[預先確認 (preconfirmations)](https://ethresear.ch/t/based-preconfirmations/17353)——這是一種與即將到來的提案者達成的承諾，保證使用者的交易將被包含在他們的區塊中，而無需等待實際區塊產生。 此功能有利於客戶端實作和網路安全，因為它防止了驗證者可能操縱提案者排程的極端情況。預視功能也降低了實作的複雜度。 **資源**：[EIP-7917 技術規範](https://eips.ethereum.org/EIPS/eip-7917) #### 計算前導零 (CLZ) 操作碼 {#count-leading-zeros-opcode} 此功能加入了一個小型的 EVM 指令：**計算前導零 (CLZ)**。EVM 中的幾乎所有內容都表示為 256 位元的值——這個新的操作碼會回傳前面有多少個零位元。這是許多指令集架構中的常見功能，因為它能實現更有效率的算術運算。實際上，這將現今手動編寫的位元掃描簡化為一個步驟，因此尋找第一個設定的位元、掃描位元組或解析位元欄位變得更簡單且成本更低。該操作碼成本低且固定，經基準測試與基本加法相當，這縮減了位元組碼，並為相同的工作節省了燃料。 **資源**：[EIP-7939 技術規範](https://eips.ethereum.org/EIPS/eip-7939) #### 支援 secp256r1 曲線的預編譯合約 {#secp256r1-precompile} 在固定地址 `0x100` 引入內建的、通行密鑰風格的 secp256r1 (P-256) 簽章檢查器，使用許多第二層 (L2) 已經採用的相同呼叫格式並修復了極端情況，因此為這些環境編寫的合約可以在第一層 (L1) 上運作而無需修改。 使用者體驗升級！對使用者而言，這解鎖了裝置原生的簽署和通行密鑰。錢包可以直接利用 Apple Secure Enclave、Android 金鑰庫、硬體安全模組 (HSM) 以及 FIDO2/WebAuthn——無需助記詞，入門引導更順暢，且多因素流程感覺就像現代應用程式一樣。這帶來了更好的使用者體驗、更簡單的復原方式，以及與數十億裝置已經在做的事情相符的帳戶抽象化模式。 對開發者而言，它接受 160 位元組的輸入並回傳 32 位元組的輸出，使得移植現有函式庫和第二層 (L2) 合約變得容易。在底層，它包含了無窮遠點和模數比較檢查，以消除棘手的極端情況，而不會破壞有效的呼叫者。 **資源**： - [EIP-7951 技術規範](https://eips.ethereum.org/EIPS/eip-7951) - [更多關於 RIP-7212 的資訊](https://www.alchemy.com/blog/what-is-rip-7212) _（請注意，EIP-7951 已取代 RIP-7212）_ ### 元資料 (Meta) {#meta} #### `eth_config` JSON-RPC 方法 {#eth-config} 這是一個 JSON-RPC 呼叫，允許您詢問您的節點正在執行什麼分叉設定。它會回傳三個快照：`current`、`next` 和 `last`，以便驗證者和監控工具可以驗證客戶端是否已為即將到來的分叉做好準備。 實際上，這是為了解決 2025 年初佩克特拉分叉在 Holesky 測試網上線時發現的一個缺點，當時輕微的配置錯誤導致了無法最終確定的狀態。這有助於測試團隊和開發者確保重大分叉在從開發網轉移到測試網，以及從測試網轉移到主網時，能如預期般運作。 快照包含：`chainId`、`forkId`、計畫的分叉啟用時間、哪些預編譯合約處於活動狀態、預編譯合約地址、系統合約依賴項，以及分叉的資料塊排程。 這個 EIP 被放在「核心 EIP」之外的獨立部分，因為該分叉實際上並未實施任何變更——這是一個通知，要求客戶端團隊必須在富薩卡升級前實作這個 JSON-RPC 方法。 **資源**：[EIP-7910 技術規範](https://eips.ethereum.org/EIPS/eip-7910) ## 常見問題 (FAQ) {#faq} ### 這次升級會影響所有以太坊節點和驗證者嗎？ {#does-this-upgrade-affect-all-ethereum-nodes-and-validators} 是的，富薩卡升級需要同時更新[執行客戶端和共識客戶端](/developers/docs/nodes-and-clients/)。所有主要的以太坊客戶端都將發布支援該硬分叉的版本，並標記為高優先級。您可以透過客戶端的 GitHub 儲存庫、他們的 [Discord 頻道](https://ethstaker.org/support)、[EthStaker Discord](https://dsc.gg/ethstaker)，或訂閱以太坊部落格的協定更新，來掌握這些版本何時可用。為了在升級後保持與以太坊網路的同步，節點營運者必須確保他們執行的是受支援的客戶端版本。請注意，關於客戶端發布的資訊具有時效性，使用者應參考最新更新以獲取最新詳細資訊。 ### 硬分叉後如何轉換 ETH？ {#how-can-eth-be-converted-after-the-hardfork} - **您的 ETH 無需採取任何行動**：在以太坊富薩卡升級之後，您不需要轉換或升級您的 ETH。您的帳戶餘額將保持不變，且您目前持有的 ETH 在硬分叉後仍將以現有形式保持可用。 - **小心詐騙！** **任何指示您「升級」ETH 的人都是企圖詐騙您。** 關於這次升級，您不需要做任何事情。您的資產將完全不受影響。請記住，保持資訊靈通是防範詐騙的最佳防線。 [更多關於識別和避免詐騙的資訊](/security/) ### 斑馬是怎麼回事？ {#whats-with-the-zebras} 斑馬是開發者為富薩卡選擇的「吉祥物」，因為它的條紋反映了 PeerDAS 基於欄位的資料可用性取樣 (DAS)，其中節點保管特定的欄位子網，並從每個對等節點的時槽中取樣其他幾個欄位，以檢查資料塊資料是否可用。 2022 年的合併[使用熊貓](https://x.com/hwwonx/status/1431970802040127498)作為吉祥物，象徵執行層與共識層的結合。從那時起，每個分叉都會非正式地選擇吉祥物，並在升級時以 ASCII 藝術的形式出現在客戶端日誌中。這只是一種有趣的慶祝方式。 ### 包含了哪些針對第二層 (L2) 擴展的改進？ {#what-improvements-are-included-for-l2-scaling} [PeerDAS](/roadmap/fusaka/peerdas) 是該分叉的主要功能。它實作了資料可用性取樣 (DAS)，為匯總解鎖了更多擴展性，理論上可將資料塊空間擴展至目前大小的 8 倍。blob 費用市場也將得到改善，以有效應對網路擁塞，並保證第二層 (L2) 為資料塊強加於節點的運算和空間支付有意義的費用。 ### BPO 分叉有何不同？ {#how-are-bpo-forks-different} 僅限資料塊參數 (Blob Only Parameter) 分叉提供了一種機制，在 PeerDAS 啟用後持續增加資料塊數量（包括目標值和最大值），而無需等待完整的協調升級。每次增加都被硬編碼，預先配置在支援富薩卡的客戶端版本中。 身為使用者或驗證者，您不需要為每個 BPO 更新您的客戶端，只需確保跟隨像富薩卡這樣的重大硬分叉即可。這與以前的做法相同，不需要採取特殊行動。仍然建議在升級和 BPO 期間監控您的客戶端，並在主要版本之間保持更新，因為硬分叉後可能會進行修復或最佳化。 ### BPO 的時程表為何？ {#what-is-the-bpo-schedule} BPO 更新的確切時程將隨富薩卡版本發布而定。請關注[協定公告](https://blog.ethereum.org/category/protocol)以及您客戶端的發行說明。 它可能看起來像這樣（範例）： - 富薩卡之前：目標 6，最大 9 - 富薩卡啟用時：目標 6，最大 9 - BPO1，富薩卡啟用後幾週：目標 10，最大 15，增加三分之二 - BPO2，BPO1 後幾週：目標 14，最大 21 ### 這會降低以太坊（第一層）的費用嗎？ {#will-this-lower-gas} 這次升級不會降低第一層 (L1) 的燃料費用，至少不會直接降低。主要重點是為匯總資料提供更多資料塊空間，從而降低第二層 (L2) 的費用。這可能會對第一層 (L1) 費用市場產生一些副作用，但預計不會有重大變化。 ### 身為質押者，我需要為升級做些什麼？ {#as-a-staker-what-do-i-need-to-do-for-the-upgrade} 與每次網路升級一樣，請確保將您的客戶端更新到標記為支援富薩卡的最新版本。關注郵件清單中的更新以及[以太坊基金會部落格上的協定公告](https://blog.ethereum.org/category/protocol)，以獲取有關版本的資訊。 為了在富薩卡於主網啟用之前驗證您的設定，您可以在測試網上執行驗證者。富薩卡會[較早在測試網上啟用](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement)，為您提供更多空間來確保一切運作正常並回報錯誤。測試網分叉也會在郵件清單和部落格中宣佈。 ### 「確定性提案者預視」(EIP-7917) 會影響驗證者嗎？ {#does-7917-affect-validators} 這項變更不會改變您驗證者客戶端的運作方式，但是，它將提供更多關於您未來驗證者職責的洞察。請確保更新您的監控工具以跟上新功能。 ### 富薩卡如何影響節點和驗證者的頻寬要求？ {#how-does-fusaka-affect-bandwidth-requirements-for-nodes-and-validators} PeerDAS 在節點傳輸資料塊資料的方式上做出了重大改變。所有資料被分成稱為欄位的片段，分佈在 128 個子網中，節點只訂閱其中一部分。節點必須保管的子網欄位數量取決於其配置和連接的驗證者數量。實際的頻寬要求將取決於網路中允許的資料塊數量和節點類型。在富薩卡啟用時，資料塊目標保持與以前相同，但透過 PeerDAS，節點營運者可以看到其資料塊的磁碟使用量和網路流量減少。隨著 BPO 在網路中配置更多數量的資料塊，所需的頻寬將隨著每個 BPO 而增加。 即使在富薩卡 BPO 之後，節點要求仍在[建議的範圍內](https://eips.ethereum.org/EIPS/eip-7870)。 #### 全節點 {#full-nodes} 沒有任何驗證者的一般節點將只訂閱 4 個子網，提供原始資料 1/8 的保管。這意味著在資料塊資料量相同的情況下，節點下載它們的頻寬將減少八 (8) 倍。一般全節點的資料塊磁碟使用量和下載頻寬可能會減少約 80%，降至僅幾 Mb。 #### 獨立質押者 {#solo-stakers} 如果節點用於驗證者客戶端，它必須保管更多欄位，因此需要處理更多資料。加入驗證者後，節點至少訂閱 8 個欄位子網，因此處理的資料量是一般節點的兩倍，但仍少於富薩卡之前。如果驗證者餘額超過 287 ETH，將會訂閱越來越多的子網。 對於獨立質押者來說，這意味著他們的磁碟使用量和下載頻寬將減少約 50%。然而，要在本地建立區塊並將所有資料塊上傳到網路，則需要更多的上傳頻寬。在富薩卡時期，本地建構者將需要比以前高 2-3 倍的上傳頻寬，而在 BPO2 目標為 15/21 個資料塊的情況下，最終所需的上傳頻寬將必須高出約 5 倍，達到 100Mbps。 #### 大型驗證者 {#large-validators} 訂閱的子網數量會隨著節點中加入更多餘額和驗證者而增加。例如，在餘額約為 800 ETH 時，節點保管 25 個欄位，將需要比以前多約 30% 的下載頻寬。所需的上傳頻寬與一般節點類似地增加，至少需要 100Mbps。 在 4096 ETH（2 個最大餘額驗證者）時，節點將成為「超級節點」，保管所有欄位，因此會下載並儲存所有內容。這些節點透過貢獻遺失的資料來主動修復網路，但也需要更多的頻寬和儲存空間。由於最終的資料塊目標比以前高出 6 倍，超級節點將必須儲存約 600GB 的額外資料塊資料，並擁有約 20Mbps 的更快持續下載頻寬。 [閱讀更多關於預期要求的詳細資訊。](https://ethpandaops.io/posts/fusaka-bandwidth-estimation/#theoretical-requirements) ### 實作了哪些 EVM 變更？ {#what-evm-changes-are-implemented} 富薩卡透過新的微小變更和功能鞏固了 EVM。 - 為了在擴展時確保安全，單一交易的最大大小將被[限制為 1670 萬](https://eips.ethereum.org/EIPS/eip-7825)燃料單位。 - EVM 中加入了[新的操作碼計算前導零 (CLZ)](https://eips.ethereum.org/EIPS/eip-7939)，這將使智能合約語言能夠更有效率地執行某些操作。 - [`ModExp` 預編譯合約的成本將會增加](https://eips.ethereum.org/EIPS/eip-7883)——使用它的合約在執行時將收取更多燃料。 ### 新的 1600 萬 Gas 限制對合約開發者有何影響？ {#how-does-new-16m-gas-limit-affects-contract-developers} 富薩卡引入了一項限制，將[單一交易的最大大小限制為 1670 萬](https://eips.ethereum.org/EIPS/eip-7825) (2^24) 燃料單位。這大約是以前平均區塊的大小，使其足夠大以容納會消耗整個區塊的複雜交易。此限制為客戶端提供了保護，防止未來在更高的區塊 Gas 限制下發生潛在的 DoS 攻擊。擴展的目標是讓更多交易進入區塊鏈，而不會有單一交易消耗整個區塊。 一般使用者的交易遠未達到此限制。某些極端情況，如大型且複雜的去中心化金融 (DeFi) 操作、大型智能合約部署或針對多個合約的批次交易，可能會受到此變更的影響。這些交易將必須被分割成較小的交易，或以其他方式進行最佳化。在提交可能達到限制的交易之前，請使用模擬。 RPC 方法 `eth_call` 不受限制，將允許模擬比實際區塊鏈限制更大的交易。RPC 方法的實際限制可由客戶端營運者配置，以確保防止濫用。 ### CLZ 對開發者意味著什麼？ {#what-clz-means-for-developers} 像 Solidity 這樣的 EVM 編譯器將在底層實作並利用這個計算零的新功能。如果新合約依賴這類操作，可能會從節省燃料中受益。請關注智能合約語言的版本發布和功能公告，以獲取有關潛在節省的說明文件。 ### 我現有的智能合約會有任何改變嗎？ {#what-clz-means-for-developers-2} 富薩卡沒有任何會破壞現有合約或改變其行為的直接影響。引入執行層的變更具有向後相容性，但是，請始終留意極端情況和潛在影響。 [隨著 `ModExp` 預編譯合約成本的增加](https://eips.ethereum.org/EIPS/eip-7883)，依賴它的合約在執行時將消耗更多燃料。如果您的合約嚴重依賴此功能，並對使用者變得更加昂貴，請重新考慮其使用方式。 如果執行您合約的交易可能會達到類似的大小，請考慮[新的 1670 萬限制](https://eips.ethereum.org/EIPS/eip-7825)。 ## 進一步閱讀 {#further-reading} - [以太坊路線圖](/roadmap/) - [Forkcast：富薩卡](https://forkcast.org/upgrade/fusaka) - [富薩卡 Meta EIP](https://eips.ethereum.org/EIPS/eip-7607) - [富薩卡測試網部落格公告](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement) - [Bankless：富薩卡與佩克特拉將為以太坊帶來什麼](https://www.bankless.com/read/what-fusaka-pectra-will-bring-ethereum) - [Bankless：以太坊的下一次升級：富薩卡、格蘭斯特丹及未來 (與 Preston Van Loon 對談)](https://x.com/BanklessHQ/status/1956017743289020633?t=502) - [富薩卡檔案 (The Fusaka Files)](https://www.youtube.com/playlist?list=PL4cwHXAawZxpz-erUbKKUnnGoQNdF8s7Z) - [PEEPanEIPs 解說](https://www.youtube.com/playlist?list=PL4cwHXAawZxoIenfk7OJry4rxcqX-eqBt)