模塊化結構下 EIP-4844 的設計邏輯

本文介紹了 Proto-danksharding 的基本設計，以及如何配合 rollup 的擴容髮展。

編輯： EthereumCN

封面： Photo by Shubham's Web3 on Unsplash

注：本文基於 Optimism 團隊研究員、前以太坊基金會研究員 Protolambda 於今年 7 月在 EthCC Paris 所做的演講進行編譯，並參考了其他優秀的文章進行整理 (在文末列出)。

引入

合併 (The Merge) 的關鍵里程碑已於 9 月 15 日完成，根據 Vitalik 在 2021 年底發布的以太坊協議開發路線圖，下一個重要階段是 The Surge —— 解決以太坊可擴展性問題，降低交易費並提高吞吐量。The Surge 圍繞以 rollup 為中心的路線圖開發，在繼承以太坊網絡安全性的同時，進一步提高 L2 rollup 的可擴展性。

本文主要介紹這一技術路線圖中的一個關鍵工作：EIP-4844 Proto-danksharding，它如何使得 rollup 所需要使用的數據變得更加便宜以及獲得更多存儲數據的容量 (capacity)。EIP-4844 是對以太坊網絡的一次升級，它將使得 rollup 的開銷降低 10-100 倍。它通過向以太坊引入一種新的交易類型來實現，這種交易類型攜帶短暫存在的 blob 數據。這種新的數據存儲方式是為了存放 rollup 的一些數據，它會比目前 calldata 的方式便宜得多。此外，4844 是完整版 Danksharding (在前面的基礎上再擴容 10-100 倍！) 的前提條件。

以太坊分片技術路線圖

對於以太坊分片設計的現狀，前以太坊基金會開發者 Protolambda 做了一個簡潔的描述：

帶有 “crosslink” 的可執行的 “分片鏈” 已被淘汰，而是更新為：在信標鏈中實現 EVM；使用 “數據可用性採樣” 的以 rollup 為中心的以太坊路線圖，擴容以太坊基礎層而無需增加應用環境的複雜性。

之所以做這樣的簡化，主要有兩個原因：

避免添加更多的 L1 複雜性。分片的規範已重寫多次，許多研究都過於抽象乃至實現的日子遙遙無期，並且讓 L1 變得僵化。

而如果能夠巧用封裝複雜性和應用區塊鏈模塊化結構，以太坊基礎層作為 rollup 的數據可用性層，將計算的重任交給作為執行層的 L2。這樣 L1 只專注於解決數據問題，不同的 rollup 團隊解決各自的開發問題，從而大大地提升擴容的效率。

封裝複雜性和模塊化在以太坊上的應用

模塊化區塊鍊是擴容中一個非常重要的概念。模塊化意味著 “封裝複雜性”，這允許我們在不同的模塊中添加可擴展性。根據 Vitalik 的文章《協議設計中的封裝複雜性和系統複雜性權衡》中的解釋，當一個系統包含著一些複雜的子系統，但對外提供一個簡單的 “接口” 時，就會出現 “封裝複雜性”；當系統的不同部分甚至不能完全分離，並且相互之間具有復雜作用時，就會出現 “系統複雜性”。

2020 年 10 月，Vitalik 發布了文章《以 Rollup 為中心的以太坊路線圖》，確定了為 L2 rollup 擴容協議保駕護航的基本思路：將執行層 (L2) 和數據層 (L1) 分離，以太坊共識層 (L1) 為其提供安全保障。

分離執行層和數據層的好處是，數據層的發展可以保持相對穩定，而執行層 (即 rollup) 則可以更加多自主性、更加創新地快速迭代，無需獲得 L1 核心開發者社區的的許可進行升級。

上面簡單介紹了以 rollup 為中心的以太坊路線圖中的區塊鏈分層情況，那在 PoW 與 PoS、L1 與 L2 之間的模塊化架構是怎樣的呢？

圖中展示了合併前的單一型 PoW 鏈 vs. 合併後的 L1 共識層 (PoS) 和 L1 執行層 (EVM) 之間的模塊化關係。而 PoS 和 EVM 之間的合併技術是通過一個叫做”Engine API“ 的東西實現的。下圖是合併後完整客戶端的樣子，中間的 API 使得以太坊共識層 (PoS) 和執行層 (PoW) 之間可以實現通信。這是以太坊主網上的首個模塊化設計。

那麼 L1 和 L2 之間是如何連接的呢？

可以看到上圖中，L1 和 L2 之間會有一個 API，它們分別是兩套軟件。

這是以太坊加上欺詐證明和有效性證明之後的示意圖，相當於將 L2 作為一個執行層連接以太坊 EVM，然後你維持當前的 L2 執行層。但這也會有一個問題，因為就算可以堆疊執行層，但是這樣效率不高，所以我們需要一個數據層。

如上示意圖，L1 作為數據層，L2 負責執行計算。

數據可用性是擴容的關鍵瓶頸

以太坊目前面臨的一大瓶頸就是數據可用性，這是我們接下來一年裡增加可擴展性所需要提高的範疇。

首先我們看一筆 rollup 交易包含哪些開銷：

執行開銷 (網絡中所有節點執行交易並且驗證其有效性的開銷)

存儲/狀態開銷 (使用新的值更新區塊鏈 “數據庫” 的開銷)

數據可用性開銷 (將數據發布至 L1 的開銷)

其中，前兩筆開銷都是 Rollup 網絡上的花費，佔總開銷的比例非常低。而數據可用性開銷才是擴容的關鍵瓶頸。

我們為什麼需要這種數據呢？

保證數據的可用性可以讓任何人都可以無需許可地重構狀態。

L2 提供的可擴展性是通過將執行檢查和保證數據安全這兩項工作分離而獲得的。這讓我們有機會同步以及獲取驗證狀態的數據，而這個過程中定序器不會對其有直接影響。

目前，rollup 上傳數據到 L1 都是以 calldata 的形式。這種方式非常貴，calldata 是一種沒有修剪過的非常沒有效率的數據形式，需要以一種迂迴的方式將數據存放在以太坊，一個非 0 字節就需要花費 16 gas。所以出現了兩種粗暴的降低這種開銷的方法：

calldata 壓縮，不少 rollup 項目都已經開始研究壓縮 calldata 的算法並集成到他們的系統中。

EIP-4488，將每個非 0 字節的 calldata 開銷從 16 gas 降低到 3 gas。

但是使用 calldata 的方式始終是不可持續的，因為這會帶來 L2 不需要的遺留開銷。那麼有沒有更優雅的方法呢？

數據可用性、數據可恢復性、長期數據可用性等等這些不同類型的名詞，它們之間的差異就是可用性的時長各不同。譬如說，你希望這些數據的可用時間足夠長來挑戰定序者、重構狀態。事實上，你不需要數據是永遠可用的。在以太坊的假設中，存儲超過一年的數據，用戶可能在某個地方找到它，可能會將它同步到某個點，而不需要一直追溯到創世區塊。

而 EIP-4844 這個提案則是讓我們能夠對數據做一些修剪，因為在這個提案下，數據只需要保留其可用性足夠長的時間，讓誠實的網絡參與者重構完整狀態並且挑戰定序器。

EIP-4844 Proto-danksharding

EIP-4844 提議什麼呢？

將數據可用性添加至以太坊且不會破壞可組合性，也就是說我們可以在 L1 有一個執行層，同時可以在上面添加數據可用性。

如圖所示，我們現在有 L1 共識層、L1 執行層、L1 數據層、L2 執行層。在這樣的分層架構下，我們獲得了封裝性，然後我們不同的團隊可以針對不同的問題，並單獨地提高某一層的可擴展性。

引入新的交易類型 Blob-carrying Transaction

EIP-4844 引入一種新的交易類型，這種交易類型與普通以太坊交易相比多了一個 blob 的位置用來存放 L2 的數據。比較獨特的是，Blob 數據在一個月之後就會被節點刪除，從而很大地節省了存儲空間。

那麼我們如何添加這種數據呢？

我們稱這種數據為 “blob”，這是一種非常模糊的數據形式，類似於一種字符串。“Blob” 會被附加到一筆交易中，這筆交易就像其他交易一樣在以太坊系統中運行。

但附加的內容具有自己的生命週期。請看上圖圖示：首先，rollup 運營者會納入普通的交易，生成 L2 交易捆，目前是通過 calldata 的方式將交易 batch 直接發送至 L1。而有了 4844 之後，新增了一種攜帶 “blob” 數據的交易類型 “blob 交易”。這個 “blob 交易” 負責支付交易費，將承諾 (commitment) 包含進交易中以有效地證明該 blob 中存在的任意數據。但是附加的內容 (即 blob 數據) 本身是與 “blob 交易” 分離的，可以把這種數據看作是一個挎鬥 (sidecar)。

(Sidecar 在不改變主應用的情況下，會起來一個輔助應用，來輔助主應用做一些基礎性的甚至是額外的工作。這個 sidecar 通常是和主應用部署在一起，所以在同樣環境下運行。這其中還有一些性能上的考慮，sidecar 如果和主程序網絡通信上有延遲就會造成性能問題。這個輔助應用不一定屬於應用程序的一部分，而只是與應用相連接。這就像是挎鬥摩托車，每個摩托車都有自己獨立的輔助部分，它隨著主應用啟動或停止。因為 sidecar 其實是一個獨立的服務，我們可以在上面做很多東西，例如 sidecar 之間相互通信、或者通過統一的節點控制 sidecar ，形成網絡服務 Service Mesh。來源：https://blog.csdn.net/lxlmycsdnfree/article/details/126286243)

blob data vs. calldata

要想知道兩者的區別，我們首先要了解以太坊合併前以及合併後的區塊組成。

上圖為合併後的信標區塊，執行層被包裹在共識層裡，而 EL 最核心的部分就是 ExecutionPayload (執行負載)。

EL 和 CL 分別負責兩個主要功能，前者執行 EVM，後者負責 PoS 共識。信標區塊中包含 EL 的 ExecutionPayload，外層的狀態根為信標鏈狀態的更新，EL 內的狀態根則是 EVM 賬戶狀態更新。

現在我們重新來看 Calldata 和 blob data 之間的區別。

首先，這兩種數據類型有不同的生命週期。Calldata 存在於 “execution payload” 中 (普通的 L1 交易)，而 blob 數據存儲於共識層中。也就是說 “blob” 存儲在一個 Prysm 節點或者 Lighthouse 節點中，而不是在 Geth 中。然後這些共識層節點會在特定一段時間之後對 blob 數據進行修剪。

“Blob” 在網絡的運作流程如下圖所示：

定序器提供數據->

L1 敲定數據->

將 Blob sidecar 從 Blob 交易中分離出來->

Blob 交易中的執行發生在 Execution Payload 中->

rollup 驗證狀態所需要的數據則去到另一側的數據庫中，L2 驗證者可以下載這些 sidecar 並同步 L2。

Blob 有兩個顯著的特點：

第一就是不被合約讀取，下圖是一筆 blob 交易的樣子，可以看到 EVM 不會讀取 blob。

就像前面所介紹那樣，blob data 存儲在共識層節點中，和 calldata 需要被合約讀取所消耗的資源相比要便宜得多。

第二就是，一個月後，共識層節點會對 blob 內的值進行刪除。區塊空間一直以來主要都由交易占用著，而隨著 L2 的發展，L1 基礎層轉而成為 L2 的數據層，calldat 就會佔用更多的區塊空間。能夠定期刪除 blob 數據的話，可以很好地解決 L1 狀態膨脹的問題。

總結

隨著 Rollup 技術的逐漸完善，數據可用性成為各個解決方案更進一步擴容的瓶頸。而 L1 作為一個為 Rollup 保駕護航的基礎層，它不僅可以為 rollup 提供安全保障，還可以充當 rollup 的數據層，讓可擴展性實現指數級的提升。Proto-danksharding 作為完整版 Danksharding 的前提條件，通過引入攜帶 “blob data” 的交易類型這樣的一個新設計，讓基礎層更無壓力地存放 L2 數據，同時不影響數據可用性的安全性。

閱讀更多

OP in Paris: Protolambda 介紹 EIP-4844

https://www.youtube.com/watch?v=KQ_kIlxg3QA

《以太坊分片設計的歷史回顧和未來路線圖》

https://www.ethereum.cn/Eth2/sharding-design-history

《Rollup 的大補帖：Proto-Danksharding（一）》

https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6

EIP-4844 提案規範

https://eips.ethereum.org/EIPS/eip-4844

以 Rollup 為中心的以太坊路線圖

https://www.ethereum.cn/a-rollup-centric-ethereum-roadmap

ECN 的翻譯工作旨在為中國以太坊社區傳遞優質資訊和學習資源，文章版權歸原作者所有，轉載須註明原文出處以及 ethereum.cn，若需長期轉載，請聯繫 eth@ecn.co 進行授權。

免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。文章內的信息僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。