原文作者：Chuan Lin，AnT Capital
圖片來源：由無界版圖AI 工俱生成
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 江湖。
（詳見筆者之前關於L2 的研究：萬字長文：ETH 合併當下，對Layer2 的回顧與展望 ）
而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 本身理解到這一層已經足夠了）
更細節一點的來說，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 交易。
（來源：OP in Paris: OP Lab’s Protolambda walks us through EIP-4844）
Blob 和現在以太坊架構的融合，可以類比為摩托車本體和摩托車挎鬥（Sidecar）之間的關係，就像這樣：（左邊的就是摩托車的Sidecar）
Sidecar（摩托車挎鬥）是一個官方比喻。它的含義，其實就是Blob 的運轉雖然依賴於主鏈，但某種程度上也平行於主鏈、具備相當的獨立性。
如下圖所示，接下來就讓我們來過一遍Blob 相關的執行流程，以更好的理解這一比喻：
（來源：OP in Paris: OP Lab’s Protolambda walks us through EIP-4844）
首先，L2 Sequencer 確定交易，將交易的結果和相關證明（黃色部分）和數據包（Blob，藍色部分）傳到L1 的交易礦池中
L1 的節點（Beacon Proposer）看到了交易，它會在新的區塊提議（Beacon Block）裡面執行相關交易並進行廣播；但在廣播的時候，它會把Blob 分離出來留在共識層CL 中，並不會把它放到執行層的新區塊裡面
其它L1 節點（Beacon Peer）會收到了新的區塊提議和交易結果。如果它們有需要成為L2 驗證者，它們可以去Blobs Sidecar 下載相關的數據。
下圖是從另一個角度對Blob 生命週期的闡述，我們可以清晰地看到blob 數據不會上L1 主鏈，只會存在共識層節點之中，並且它有著不一樣的生命週期。
（來源：OP in Paris: OP Lab’s Protolambda walks us through EIP-4844）
因此，這也不難理解為什麼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 的安全性和性能。
（來源：Frequently Asked Questions Written by Vitalik Buterin）
資訊來源：由0x資訊編譯自8BTC。版權歸作者所有，未經許可，不得轉載