深度解讀 EIP-4844：如何降低 Layer2 費用100倍？

原文作者：Chuan Lin

原文來源：A\&T Capital

01、引子

Vitalik 於 2022 年 11 月 5 日發布了更新後的以太坊路線圖，相比於之前 2021 年 12 月 2 日發布的路線圖，其中即將到來的 The Surge 階段的更新無疑是最值得關注的。

如下圖所示，這一階段的更新明顯添加了更多細節 ------ 我們可以明顯看到，為了實現"基本的 Rollup 擴容"，以太坊社區提出了 EIP-4844 ：Proto-Danksharding。這個提案將於 2023 年 5 月到 6 月初落地，屆時 Rollup 的費用花費將降低 100 倍，這將非常大的優化以太坊L2的用戶體驗。如此大的優化，勢必會成為Web3社區討論和關注的焦點。

原來以太坊相關的問題在哪？EIP-4844 是用什麼思路和方案解決這一問題的？本文就將幫助大家簡明扼要的理解 EIP-4844 。

如果你希望跟上以太坊底層的架構更新，實時跟上社區的討論，就請不要錯過本文！

02、正文

一、EIP-4844 起源：數據可用性引起的L2費用瓶頸

1.1 當前有關L2與L1數據交互的基本情況

當前以太坊L2大多以 Rollup 為基本的技術路線，Vitalik 更是將以太坊的更新用"A Rollup-Centric Roadmap"描述，可見 Rollup 基本已經一統L2江湖。

而 Rollup 運行的基本原理，是將一捆交易在以太坊主鏈外執行，執行完後將執行結果和交易數據本身經過壓縮後發回到L1上，以便其他人去驗證交易結果的正確性。顯然，如果其他人沒有辦法讀取數據，那就無法完成驗證。因此讓其他人能夠獲取交易原始數據這一點非常重要，它也被稱為"數據可用性"（Data Availability）。

而受限於以太坊當前的架構，L2向L1的傳輸的數據，是儲存在交易的 Calldata 裡面的。然而，Calldata 在最初以太坊設計的時候只是個智能合約函數調用的參數，是所有節點必須同步下載的數據。如果 Calldata 膨脹，將造成以太坊網絡節點的高負載，因此 Calldata 的費用是比較昂貴的。這也是造成當前L2費用的主要因素。

1.2 問題的改進思路

讀者不妨思考一下，如果讓你來針對這個問題設計優化方案，你會朝哪個方向去做改進？

其實我們可以觀察到，L2的交易壓縮數據的上傳，只是為了讓它能夠被其他人所下載驗證，並不需要被L1所執行。而 Calldata 費用之所以高，是因為它作為一個函數調用的參數，是默認可能被L1執行的，因此需要全網的節點進行同步。

這就造成了一種不匹配：打個比方，就像我明明只想把數據傳個網盤，讓有需要的其他人在一段時間內能夠去下載；結果，你卻把我的數據做了個我並不需要的全網廣播同步，強制所有人必須在限定時間內完成下載，然後反過來因為這個服務向我收取高昂的費用。這明顯是不合適、需要改進的。

那怎麼改進呢？我們可以把L2傳過來的數據單獨設計一個數據類型，把它和L1的 Calldata 分開。這種數據類型只需要滿足能在一定時間內被有需要的其他人所訪問下載即可，無需做全網的同步。實際上，這點也被眾多以太坊技術社區的成員所想到了。

EIP-4844 的改進，其實就是圍繞著這個脈絡進行的。

二、EIP-4844 的核心：帶 Blob 的交易

如果用一句話來概括 EIP-4844 究竟做了什麼，那就是：引入了"攜帶 blob 的交易"這一新的交易類型。Blob 就是上文提到的，為L2的數據傳輸所專門設計的數據類型。

因此，將有關 blob 的細節理解清楚，就可以說基本搞明白了 EIP-4844 。

2.1 Blob 的本體：一個用於放置L2壓縮數據的"大數據塊"，存在共識層的節點中

Blob 這個名字，其實是 Binary Large Object 的簡稱，直譯"二進制大數據塊"。它被設計出來，就是為了承載L2的原始交易壓縮數據，相當於之前L2的這些數據放到 Calldata，現在就放到 Blob 裡面。相比於 Calldata，Blob 的數據大小可以非常大，高達 125 KB。

Blob 是由共識層的節點進行存儲的，而不是像 Calldata 那樣在會直接上主鏈，這也帶來了 Blob 的兩個核心特點：

• 不能像 Calldata 那樣被 EVM 所讀取

• 有生命周期，在 30 天之後將被刪除

更細節一點的說，Blob 本身，是一個由 4096 個元素所構成的向量（Vector）。這個向量每個維度都是一個可以非常大的數字，取值範圍在 0 到 52435875175126190479447740508185965837690552500527637822603658699938581184513 之間 ------ 這個非常大的數字是一個質數，它是和椭圓曲線密碼學算法相關的。

而這個向量的每個維度的數字，可以把它看做是一個不高於 4096 階的有限域多項式的各個係數，比如第 i 維的數字就是 w\^i 前面的係數，其中 w 為常數且滿足 w\^ 4096 = 1 。這個結構設計，是為了方便 KZG 多項式承諾的生成。

2.2 與 Blob 相關的架構設計：Sidecar

在理解 Blob 架構之前，先需要說明一個概念：Execution Payload（執行負載）。在以太坊合併之後，分出了 Consensys Layer 和 Execution Layer，它們分別負責兩個主要功能: 前者負責 PoS 共識，後者執行 EVM。而 Execution Payload 可以簡單認為是 EL 層裡面普通的L1交易。

Blob 和現在以太坊架構的融合，可以類比為摩托車本體和摩托車挎斗（Sidecar）之間的關係，就像這樣：（左邊的就是摩托車的 Sidecar）

Sidecar（摩托車挎斗）是一個官方比喻。它的含義，其實就是 Blob 的運轉雖然依賴於主鏈，但某種程度上也平行於主鏈、具備相當的獨立性。

如下圖所示，接下來就讓我們來過一遍 Blob 相關的執行流程，以更好的理解這一比喻：

• 首先，L2 Sequencer 確定交易，將交易的結果和相關證明（黃色部分）和數據包（Blob，藍色部分）傳到L1的交易池中

• L1的節點（Beacon Proposer）看到了交易，它會在新的區塊提議（Beacon Block）裡面執行相關交易並進行廣播；但在廣播的時候，它會把 Blob 分離出來留在共識層 CL 中，並不會把它放到執行層的新區塊裡面

• 其它L1節點（Beacon Peer）會收到了新的區塊提議和交易結果。如果它們有需要成為L2驗證者，它們可以去 Blobs Sidecar 下載相關的數據。

下圖是從另一個角度對 Blob 生命周期的闡述，我們可以清晰地看到 blob 數據不會上L1主鏈，只會存在共識層節點之中，並且它有著不一樣的生命周期。

因此，這也不難理解為什麼 Blob 無法被 EVM，也就是L1的智能合約所直接讀取：能被讀取的都是被傳到執行層的東西，既然 Blob 僅僅留在共識層，那麼肯定就沒有這個功能了。而事實上，這種分離，也正是 Rollup 費用能因此降低的原因。

2.3 Blob 的存儲：新的 Fee Market

前文提到，Blob 數據將存在共識層節點之中，並且具備生命周期。但顯然這種服務也不是免費的，因此它將會帶來一個獨立於L1 Gas 費的新費用市場，這也是 Vitalik 所倡導的 Multi-dimensional Fee Market。這個 Fee Market 的相關細節還在迭代完善之中，詳見 Github 的相關討論與更新：https://github.com/ethereum/EIPs/pull/5707

另外，如果節點層面只能短期存儲這些數據，那麼如何實現長期的儲存呢？對此，Vitalik 表示解決方案其實很多。因為這裡的安全假設要求不高，是" 1 of N 信任模型"，只需有人能夠完成真實數據的存儲即可。在大的存儲硬件只需要 20 美元每 TB 的當下，每年 2.5 TB 的數據存儲對於有心人而言只是小問題。另外，其它各種去中心化存儲解決方案也會是一種選擇，不過 Vitalik 在這裡並沒有提到具體的項目。

三、EIP-4844 的影響

在架構層面，EIP-4844 引入了新的交易類型 Blob-carrying Transaction，這是以太坊第一次為L2單獨構建數據層，也是之後 Full Danksharding 實現的第一步。

在經濟模型層面，EIP-4844 將為 blob 引入新的 Fee Market，這也會是以太坊邁向 Multi-dimensional Market 的第一步。

在用戶體驗層面，用戶最直觀的感知就是L2費用的大幅降低，這個底層的重要改進，將為L2以及其應用層的爆發提供重要基礎。

四、EIP-4844 後的展望：Fully Danksharding

目前，EIP-4844 已經明確包含在以太坊上海升級系列之中，按照目前社區成員給出的時間表，預計將於明年 5 月至六月初完成。

而 EIP-4844 只是"Proto-Danksharding"，意為 Danksharding 的原型。完整版 Danksharing 的構想如下圖所示，每個節點都可以直接通過數據可用性採樣（Data Availability Sampling），實現對L2數據正確性的實時驗證。這將會進一步提高L2的安全性和性能。