繼 Pectra 升級之後，Fusaka 的重大硬分叉升級做了什麼，對 Layer 2 鏈有什麼影響

繼 2025 年 5 月的 Pectra 升級之後，以太坊於 2025 年 12 月 3 日正式啟動了名為 Fusaka 的重大硬分叉升級。

「Fusaka」這個名字結合了共識層升級 Fulu（星名）與執行層升級 Osaka（大阪）。如果說 Pectra 升級是為了優化「錢包與質押體驗」，那麼 Fusaka 升級則是以「工程優化與大幅擴容」為核心。

以下是 Fusaka 升級的四大核心技術亮點：

1. PeerDAS (對等數據可用性採樣) — — 核心技術

這是 Fusaka 最重要的改進（EIP-7594）。

• 解決的問題： 以前節點必須下載完整的「Blob 數據」才能驗證交易，這限制了以太坊能處理的數據量。
• 實現方式： 節點現在只需「抽樣驗證」。就像檢查一本書是否完整，你不需要讀完每一頁，只需隨機檢查幾頁即可。
• 結果： 讓普通節點在不增加硬體負擔的情況下，支持更多的 Blob。

2. Blob 容量提升 8 倍

得益於 PeerDAS，以太坊大幅調高了 Blob 的容量上限。

• 目標： 讓每個區塊可容納的 Blob 數量提升約 8 倍（從目前的 3 個提升至更高水平）。
• 對用戶的影響： 這是 Layer 2（如 Arbitrum, Optimism, Base）的重大利多。L2 的數據存儲成本將進一步暴跌，交易手續費可能降至幾近於零，真正實現「每秒 10 萬筆交易」的目標。

3. L1 吞吐量與 Gas Limit 調整

Fusaka 對以太坊主網（L1）的性能也進行了優化。

• Gas Limit 提升： 將區塊的 Gas Limit 目標值大幅提升（部分提案建議調至 60M 甚至更高），這意味著主網單個區塊能處理的交易量增加了。
• 防止 DoS 攻擊： 通過 EIP-7825 等提案，對特定的重負載操作設置上限，防止惡意用戶透過發送超大交易來癱瘓網路。

4. 用戶體驗與安全性改進

• 硬體簽名支持 (EIP-7951)： 讓開發者更容易集成手機安全晶片（如 iPhone 的 FaceID/Passkeys）進行交易簽名。這意味著未來你可能不再需要手打助記詞，用臉部識別就能安全操作錢包。
• 費用市場平滑化 (EIP-7918)： 優化了 Blob 的定價機制，防止因短期流量激增導致手續費暴漲暴跌，讓 L2 的費用更穩定。

5. 小結：以太坊升級的階梯

在 2025 年的 Pectra 與 Fusaka 兩大升級後，Layer 2 (L2) 應用程式的開發環境經歷了從「堪用」到「原生好用」的質變。如果您是開發者或對技術細節感興趣，以下是針對 L2 應用的具體改良點：

1. 數據可用性 (DA) 的量變與質變：PeerDAS

在 2024 年 Dencun 升級引入 Blob 後，L2 的成本已經降低了不少，但 Fusaka 升級 (2025.12) 引入的 PeerDAS (EIP-7594) 才是真正的殺手鐧：

數據採樣 (Sampling)：

• 節點不再需要下載完整的 Blob，只需隨機抽樣。這讓以太坊能安全地將 Blob 數量從 3–6 個提升到 14–21 個以上。

開發者紅利： L2 的數據發布成本進一步暴跌。這意味著開發者可以開發那些「數據密集型」的應用，例如：

• 高頻鏈上遊戲 (On-chain Games)：玩家的操作可以更密集且廉價。
• 全鏈社交媒體 (SocialFi)：發文、點讚的成本接近於零，不再需要依賴中心化數據庫。

2. 毫秒級的「即時感」：Preconfirmations (預確認)

L2 雖然快，但用戶往往要等幾秒鐘看到交易「成功」。

• 技術改良： 隨著 Fusaka 升級對提議者機制的優化，L2 排序器（Sequencer）可以提供 預確認 (Preconf)。
• 用戶體驗： 交易提交後，排序器能在 100 毫秒內 給出具備經濟擔保的確認回覆。這讓 L2 應用的交互感變得跟 Solana 或 Web2 網頁 一樣流暢，不再有「等待轉圈」的焦慮。

3. 互操作性與同步組合成性 (Synchronous Composability)

2025 年被視為「互操作性元年」。

• 基於 L1 的排序 (Based Rollups)： 像 Taiko 這種 Based Rollups 利用以太坊 L1 進行排序。這讓多個不同的 L2 之間，透過某些機制（如 Shared Preconfirmations）能實現同步交互。
• 開發範例： 你在 Arbitrum 上的合約，可以直接在「同一筆交易」中調用 Base 上的合約功能，而不需要透過緩慢的跨鏈橋。這解決了流動性破碎的問題。

4. 新的密碼學原語 (Precompiles)

• EIP-2537 (BLS12–381)： 這個預編譯合約讓 ZK-Rollups 的證明驗證（Verification）變得極其便宜。
• EIP-7951 (Passkeys 支持)： 原生支持手機安全晶片常見的簽名算法。開發者現在可以讓用戶「刷臉 (FaceID) 登入」並發起交易，完全不需要處理私鑰與助記詞。

Blob (Binary Large Object) 是以太坊擴容路徑中的核心技術，正式名稱為 EIP-4844 (Proto-Danksharding)。你可以把它想像成掛在以太坊主鏈（機車）旁邊的「側車（Sidecar）」。

1. Blob 是什麼？為什麼比以前便宜？

在 Blob 出現之前，L2（如 Arbitrum, Optimism）必須將交易數據存放在以太坊的 Calldata 區域。

• Calldata 的問題： 它被視為以太坊執行層（EVM）的一部分，會永久存在於鏈上，且必須由所有節點下載並處理，因此極其昂貴。
• Blob 的解決方案： Blob 是一種專門為 L2 數據設計的「臨時存儲空間」。
• 不被 EVM 讀取： 以太坊虛擬機 (EVM) 只能看到 Blob 的「承諾（Commitment）」，無法讀取裡面的具體內容。
• 定期刪除： 數據僅在共識層（Beacon Chain）存放約 18 天，之後就會被節點自動刪除。這大幅減輕了節點的存儲壓力。

2. Blob 如何運作？（技術核心）

Blob 的運作依賴於一種稱為 KZG 承諾 (KZG Commitments) 的密碼學技術：

1. 封裝數據： L2 定序器（Sequencer）將成千上萬筆交易打包成一個約 128 KB 的數據塊，這就是一個 Blob。

2. 生成承諾： 定序器對 Blob 進行數學處理，生成一個很小的「指紋」（KZG 承諾）。

3. 提交交易： L2 發送一個 Type-3 交易（攜帶 Blob 的交易）到以太坊。交易包含：

• 傳統的交易資訊。
• Blob 的承諾（Commitment）。
• Blob 數據本身（作為 Sidecar 跟隨區塊傳播）。

4. 驗證可用性： 以太坊驗證者不需要讀取 Blob 內容，只需驗證「承諾」是否正確，並確保該 Blob 數據確實已在網路上廣播（Data Availability）。

3. Layer 2 如何利用 Blob？

1. 數據發布： L2 將用戶的交易數據壓縮後放入 Blob。
2. 費用節省： 由於 Blob 有獨立的「費用市場」，不與主網的一般交易（轉帳、鑄造 NFT）競爭 Gas，這讓 L2 的數據存儲成本降低了 90% 以上。
3. 安全性： 即使 Blob 在 18 天後被刪除，這段時間也足夠挑戰者（Prover）下載數據並檢查 L2 是否有作弊行為。18 天後，若無異議，該批次交易即視為最終確認。

4. Blob 運作時序圖

這個圖表展示了從用戶在 L2 發起交易，到 Blob 在以太坊上被刪除的完整生命週期：

5. 小結：Blob 的影響

• 對用戶： L2（如 Base, Arbitrum）的手續費從 0.5~1 美元降至 0.01 美元以下。
• 對以太坊： 成功將「計算」與「數據存儲」分離，主網專注於結算與安全，L2 負責處理海量交易。
• 未來擴容： 隨著 Fusaka 升級 引入 PeerDAS，以太坊每個區塊能攜帶的 Blob 數量將從目前的 3–6 個提升到 20 個以上，進一步降低成本。

「狀態（State）」與「數據（Data）」在區塊鏈中是兩個不同的概念。

即便你不去還原（Restore）那些存在 Blob 裡的原始數據，你依然可以透過以下三種層次來得知 L2 的用戶狀態。

1. 透過 L2 節點的「狀態樹」 (State Tree)

這是最直接的方法。雖然 L2 會把原始交易數據打包丟到以太坊（L1）的 Blob 裡，但 L2 自己的節點（Full Nodes） 內部會維護一個完整的數據庫。

• 機制： L2 節點在執行每一筆交易後，會更新一個巨大的數據結構（通常是 Merkle Patricia Tree）。這個樹的頂端有一個「狀態根（State Root）」。
• 查詢方式： 當你打開錢包看餘額時，錢包是向 L2 的 RPC 節點（例如 rpc.arbitrum.io）發送請求。這個節點直接讀取它本地的磁碟數據庫（如 LevelDB 或 RocksDB），並告訴你結果。
• 結論： 你不需要去 L1 找 Blob，因為 L2 節點已經幫你把 Blob 裡的內容「執行」並「存儲」好了。

2. 透過 L1 上的「狀態承諾」 (State Commitment)

L2 會定期（大約每幾分鐘一次）將最新的「狀態根（State Root）」發布到以太坊 L1 的合約中。

• 它是什麼： 這是一個 32 字節的哈希值，代表了那一個瞬間 L2 上所有帳戶、餘額、合約代碼的指紋。
• 如何驗證： 如果你想在不信任 L2 節點的情況下證明你有 100 個 ETH，你可以提供一個 Merkle Proof（梅克爾證明）。只要這個證明的哈希值一路向上能對應到 L1 上存儲的那個 State Root，就能證明你的餘額是真實的。
• 重要性： 這是 L2 安全性的基石。即使 L2 節點騙你，只要 L1 上的 Root 是對的，你就擁有法律級別的證明。

3. 如果 L2 節點消失了？（數據可用性的真正用途）

這就是你問題的核心：「如果我不還原 Blob，我能不能知道狀態？」

答案是：在正常情況下可以，但在災難情況下不行。

Blob 存在的唯一理由是為了 「數據可用性（Data Availability）」。假設有一天 Arbitrum 或 Optimism 的公司倒閉了，所有的 L2 節點全部關機，這時：

1. 狀態消失了： 沒有 RPC 節點可以告訴你餘額。
2. L1 Root 還在： 但你沒有證據（Proof）來對應它。
3. 解決方案： 這時，任何一個志願者可以去 L1 下載那 18 天內的所有 Blob，重新運行一遍裡面的交易（Replay）。

• 從 Block 0 開始一筆一筆算，直到還原出最新的狀態。
• 這就像是你弄丟了銀行的存摺（狀態），但你找回了所有的原始提款單和存款單（Blob 數據），你就能算回你現在還剩多少錢。

4. 技術對比表：數據 vs 狀態

5. 小結

在正常開發或使用 DApp 時，你完全不需要去還原 Blob。你只需要信任 L2 節點（或多個節點組成的共識）。

Blob 就像是以太坊為 L2 投保的「黑盒子飛行記錄器」。只有當飛機（L2 節點）失事時，我們才需要把它找出來，讀取裡面的數據來重建一切。

要從以太坊 L1 節點中調取尚未被刪除（還在 18 天/4096 個 Epoch 窗口內）的 Blob 數據，你需要直接與共識層（Consensus Layer，簡稱 CL）節點的 API 進行交互，而不是執行層（Geth/Nethermind）。

以下是具體的技術步驟與方法：

1. 使用標准的 Beacon Node API

以太坊官方定義了標准的 REST API 接口來獲取這些數據。最核心的端點是：

端點路徑： GET /eth/v1/beacon/blob_sidecars/{block_id}

• {block_id}：可以是區塊的高度（Slot Number）、區塊哈希（Root），或者是關鍵字 head（最新區塊）。

使用 curl 範例：

如果你本地運行了一個 Beacon 節點（例如 Lighthouse、Prysm 或 Teku），默認端口通常是 5051 或 3500。

# 獲取最新區塊的所有 Blob Sidecars
curl http://localhost:5051/eth/v1/beacon/blob_sidecars/head

回傳內容： 你會得到一個 JSON 對象，其中包含：

• index: Blob 的索引（0, 1, 2...）。
• **blob: 這是最關鍵的部分，是以 Hex (十六進制)** 編碼的原始數據（約 128 KB）。
• kzg_commitment: 該 Blob 對應的 KZG 承諾。
• proof: 用於驗證數據完整性的 KZG 證明。

2. 進階：指定索引調取

如果一個區塊包含多個 Blob，而你只需要其中一個，可以使用查詢參數：

curl "http://localhost:5051/eth/v1/beacon/blob_sidecars/head?indices=0"

3. 使用常用的客戶端工具

如果你不想手寫 API 請求，可以使用以下開發者工具：

A. JavaScript/TypeScript (使用 viem)

viem 是目前對 EIP-4844 支持最好的庫之一。

import { createPublicClient, http } from 'viem'
import { mainnet } from 'viem/chains'

const client = createPublicClient({
  chain: mainnet,
  transport: http('你的節點RPC地址')
})

// 獲取特定區塊的 Blob 數據
const sidecars = await client.getBlobSidecars({ blockNumber: 19426589n })
console.log(sidecars[0].blob)

B. Python (使用 requests)

import requests

def get_blobs(slot):
    url = f"http://localhost:5051/eth/v1/beacon/blob_sidecars/{slot}"
    response = requests.get(url)
    return response.json()['data']

# 調用範例
blobs = get_blobs("head")

4. 需要注意的技術細節

1. 存儲時效性： 只有在 18 天內 的數據可以透過此 API 調取。如果超過 4096 個 Epoch，節點會自動進行「修剪 (Pruning)」，屆時 API 會回傳 404。
2. 節點配置： 確保你的 Beacon Node 開啟了 API 服務。如果是自行架設，啟動參數通常需要包含 --http 或相關標誌。
3. 數據格式： 調取出來的 blob 數據是經過編碼的。如果你需要還原 L2 提交的原始原始碼，通常需要對應 L2 協議（如 Optimism 或 Arbitrum）的解壓/解碼邏輯。
4. 存檔節點 (Archive Node)： 即使是普通的存檔節點，預設也不會永久保存 Blob。要獲取過期 Blob，你必須去訪問專門的 Blob Indexer（如 blobscan.com 的 API）或第三方數據庫（如 Google BigQuery 的加密貨幣數據集）。

5. 如果你沒有自己的節點

你可以使用提供 Beacon API 的服務商：

• QuickNode / Infura / Alchemy：現在大多數都已支持 eth/v1/beacon 相關端點。
• Beaconcha.in API：提供網頁端與 API 查詢 Blob 歷史。

在 2025 年以後的以太坊路線圖中，「同步可組合性 (Synchronous Composability)」 被視為打破 L2 孤島效應、實現「萬鏈歸一」體驗的聖杯。

1. 什麼是「同步可組合性」？

在目前的 L2 環境中，我們擁有的是異步可組合性 (Asynchronous Composability)。

• 現狀 (異步)： 你在 Optimism 上的資產和在 Arbitrum 上的合約是處於不同時空的。要讓它們互動，你需要透過跨鏈橋，這需要等待幾分鐘到幾十分鐘，且過程不是「原子性」的（可能這邊扣款成功，那邊卻失敗卡住）。
• 目標 (同步)： 就像在以太坊主網 L1 上一樣，你可以在同一筆交易中，同時調用 Uniswap 和 Aave。即使它們在不同的 L2 上，也能在同一個區塊時間內完成互動，且要嘛全部成功，要嘛全部失敗（原子性）。

2. 實現機制：共享排序器 (Shared Sequencing)

要實現不同鏈之間的同步，核心在於它們必須對「交易的先後順序」達成一致。這需要引入一個新的關鍵角色：共享排序器 (Shared Sequencer)。

核心原理：

1. 放棄單獨排序： 各個 L2（如 Chain A 和 Chain B）不再堅持使用自己中心化的排序器來決定區塊內容。
2. 外包排序權： 它們選擇接入同一個去中心化的「共享排序器網絡」（例如 Espresso, Astria，或是直接使用以太坊 L1）。
3. 原子交易包 (Atomic Bundle)： 用戶發起一個特殊的交易包，裡面包含：「在 Chain A 上賣出 ETH」和「在 Chain B 上買入 NFT」。
4. 統一定序： 共享排序器接收到這個包，並保證將這兩個操作分別放入 Chain A 和 Chain B 的下一個區塊中，且順序優先於其他衝突交易。

為什麼這能實現同步？

因為這個共享的「指揮官」同時控制了兩條鏈的「時間節奏」。它擔保：如果 Chain A 的操作因故無法執行，那麼它也不會讓 Chain B 的操作執行。這就實現了跨鏈的原子性。

3. 哪些 Layer 2 鏈支持？（現狀與未來）

目前，「同步可組合性」正在從理論走向實踐。完全成熟的主網應用預計會在 2025 年 Fusaka 升級前後爆發，但基礎設施正在建立中。

主要分為三大陣營：

a. Based Rollups（最原生的支持者）

這類 L2 直接使用以太坊 L1 的驗證者作為共享排序器。

• 代表鏈： Taiko (太鼓)。
• 特點： Taiko 天生就與以太坊 L1 具備同步可組合性，並且任何其他 Based Rollup 之間也能輕易實現同步。這是最符合以太坊價值觀的路徑。

b. 超級鏈生態 (Superchain / Hyperchains)

大型 L2 項目方建立自己的生態圈，讓圈內的鏈共享基礎設施。

• 代表鏈 (OP Stack)： Optimism, Base, Zora, Worldcoin。
• 現狀： Optimism 正在推動「超級鏈 (Superchain)」願景。他們計畫讓所有基於 OP Stack 的鏈最終都接入同一個共享排序層，從而實現生態內部的同步互操作。

c. 聚合層與 ZK 生態

• 代表鏈 (Polygon)： Polygon AggLayer (聚合層)。
• 現狀： Polygon 不僅依賴排序器，還通過聚合零知識證明 (ZK-Proofs) 的方式。只要不同的鏈接入 AggLayer，它們的狀態就可以被統一證明，從而實現跨鏈的統一流動性。
• 代表鏈 (ZKsync)： ZKsync 的 Elastic Chain 架構也致力於讓其生態內的 Hyperchains 實現無縫互操作。

4. 小結

同步可組合性是 L2 發展的終極形態。它將使「跨鏈」這個概念對用戶隱形。

• 現在： 你需要知道你在用哪條鏈，並手動跨鏈。
• 未來 (同步時代)： 你只需要一個錢包，面對一個統一的「以太坊網路」。你發起一筆交易，背後可能同時調用了 Base 的流動性和 Taiko 的合約，而這一切都在幾百毫秒內同步完成。

Base 正在努力實現「同步可組合性」，而 BSC（BNB Smart Chain）在本質上與以太坊是「異步」的。

1. Base：超級鏈（Superchain）的一員

Base 是由 Coinbase 開發的 Layer 2，它使用了 Optimism 的 OP Stack 技術棧。

同步可組合性的路徑：

Base 與 Optimism、Zora、World Chain 等鏈共同構成了「超級鏈 (Superchain)」。

如何實現？

• 這些鏈計畫共享同一個互操作層（Interoperability Layer）。
• 透過共享的 L1 結算合約和未來可能的共享排序器，Base 用戶將能夠在一次交易中與 Optimism 上的協議互動，實現原子級別的資產轉移與調用。

現狀：

雖然目前大部分跨鏈仍是異步的，但 Base 已經在測試網上展示了「原子跨鏈轉帳」，這是實現同步可組合性的第一步。

2. BSC (BNB Smart Chain)：獨立的 Layer 1

雖然 BSC 兼容 EVM（可以使用 Metamask），但它不是以太坊的 Layer 2，而是一條獨立的 Layer 1。

為什麼無法實現「同步」？

• 不同的時鐘： BSC 有自己的驗證者節點和共識機制（PoSA），它的區塊產生速度與以太坊完全不同步。
• 沒有共同的指揮官： BSC 不會將數據交給以太坊的共享排序器，因此它無法與以太坊或 Base 達成「原子性」的共識。

互操作方式：

• BSC 與以太坊/Base 之間的互動永遠是異步 (Asynchronous) 的。你必須透過跨鏈橋（如 LayerZero, Wormhole, Stargate），等待 BSC 確認後，再等待以太坊確認。這通常需要幾分鐘，且存在「一邊成功、一邊失敗」的風險。

註： 幣安生態中的 opBNB 才是 Layer 2，它在未來有可能在 BNB 生態內部實現同步，但與以太坊主網之間仍是異步的。

opBNB 是 BNB Chain 生態系為了應對高頻交易（如遊戲、社交、小額支付）而推出的 Layer 2 (L2) 擴容方案。它的底層技術完全採用了以太坊生態中的 OP Stack，但將其「嫁接」在了 BSC (BNB Smart Chain) 之上。

你可以把 BSC 想像成「地基與金庫（L1）」，而 opBNB 就是蓋在上面的「高速專線（L2）」。

a. opBNB 是如何運作的？

opBNB 採用 Optimistic Rollup（樂觀捲疊） 技術，其核心運作邏輯如下：

1. 離鏈執行 (Off-chain Execution)： 當你在 opBNB 上發起交易時，交易是在 opBNB 的定序器（Sequencer）中處理的，這比 BSC 快得多且便宜。

2. 批次打包 (Batching)： 定序器會將成千上萬筆交易壓縮成一個「數據包」。

3. 提交至 BSC (L1)： opBNB 會定期將這些數據包發佈到 BSC 上。

• 狀態根 (State Root)： 提交到 BSC 上的智能合約進行結算。
• 原始數據 (DA)： 提交到 BSC 作為數據可用性層，確保任何人都可以驗證。

4. 樂觀驗證： 系統預設所有交易都是正確的。除非有人在「挑戰期」（通常為 7 天）內提出證據證明某筆交易有誤，否則交易會自動在 BSC 上達成最終確認。

b. opBNB 如何與 BSC 一起運作？

這兩條鏈的關係非常緊密，與以太坊 L2 不同的是，它們在「經濟」與「入口」上幾乎是統一的。

• 共用原生代幣 ($BNB)： 這是 opBNB 最強大的優點。在 opBNB 上支付手續費（Gas）使用的是 $BNB，而不是像其他鏈需要發行新幣。這降低了用戶進入的門檻。
• 資產橋接： 透過官方的 opBNB Bridge，資產可以在 BSC 和 opBNB 之間轉移。從 BSC 到 opBNB 只需要幾分鐘，但從 opBNB 回到 BSC（如果是官方橋）則需要等待 7 天的挑戰期。
• 數據可用性 (DA)： opBNB 利用 BSC 作為它的數據存儲庫。這意味著只要 BSC 還在運行，opBNB 的數據就不會丟失。

c. 治理模式：分開還是統一？

這是一個關鍵問題。答案是：技術上獨立運行，戰略上統一治理。

治理架構：One BNB 策略，目前 BNB Chain 官方推行的是 "One BNB" 策略。

• 決策者： 主要由 BNB Chain 核心開發團隊 與 社區驗證者 決定。opBNB 的重大升級（例如引入 EIP-4844 或是性能優化）通常會透過 BEP (BNB Evolution Proposals) 提案進行討論。
• 治理代幣： 兩者都受 $BNB 的持有者和驗證者的間接治理。

運作細節的差異：雖然治理大方向一致，但它們的節點運作是分開的。

• 驗證者集： BSC 擁有一套由 21+ 驗證者組成的共識層。而 opBNB 的定序器目前較為中心化（由官方或指定合作夥伴運行），這與大多數 OP Stack 鏈初期狀況一致。
• 參數設定： opBNB 擁有比 BSC 高得多的 Gas Limit（每秒可處理 1 億 Gas），這需要專門的硬體節點來運行。

3. 跨生態互動流程圖

這張圖展示了為什麼 Base 之間可以同步，而與 BSC 只能異步：

• Base 是以太坊「家族內部」的成員，透過升級（如 Pectra, Fusaka）和 OP Stack 的演進，它能與其他家族成員（L2s）實現像同一條鏈一樣的同步操作。
• BSC 則是另一個「國家」，雖然大家說同樣的語言（EVM），但處理公文（交易）必須透過外交部（跨鏈橋），這永遠是異步且緩慢的。