原文：《如何降低Layer2費用100倍？一文讀懂EIP-4844 》
作者：Chuan Lin
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的數據大小可以非常大，高達125KB。
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.5TB的數據存儲對於有心人而言只是小問題。另外，其它各種去中心化存儲解決方案也會是一種選擇，不過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的安全性和性能。
APP 
