以太坊分片設計簡史:從Block到Blob

從“Block” 到“Blob”,這其中涵義深刻。

來源: @protolambda推文

作者:Protolambda

從“Block” 到“Blob”,這其中涵義深刻。

帶有“crosslink” 的可執行的“分片鏈” 被淘汰了:在信標鏈中實現EVM;使用“數據可用性採樣” 的以rollup 為中心的以太坊路線圖,擴容以太坊基礎層而無需增加應用環境的複雜性。但是,你如何在沒有區塊元數據的情況下調用分片內容呢?

好吧,這就是“blob” 派上用場的地方。 “Blobspace” 真是一個不錯的叫法!

讓我來分享一些以太坊分片設計的歷史吧:

分片(或“階段1”) 按之前的計劃應該是在“階段2” (即信標鏈執行環境) 推出。但在“階段0” (信標鏈啟動) 之前,主網EVM 具有優先權這一情況變得清晰,而“階段2” 執行層(ewasm?) 的推出遙遙無期。

“階段1” 的規範在信標鏈之前已經重寫了多次:

  • 更少的分片(1024 ->64)

  • 借助理想的跨分片通信(crosslinks) 實現自由騎行

  • 新的託管證明設計(去掉託管部分,轉而採用罕見的故意證明丟失)

更別說更早期的分片研究工作了,實話說,那些研究都非常抽像以及雄心勃勃:跨域消息傳遞、帶有ewasm 的執行環境、動態訪問的無狀態性、分片委員會等等都讓L1 變得更加複雜。而L1 已經開始僵化了。

但是,如果L1 只專注於解決數據問題,那麼上述提到的大多數問題都轉化為L2 的開發問題。而採樣(sampling) 正好解決了L1 數據問題。如果我們可以在網絡層支持額外的功能…會如何呢?

因此在2020 年10 月14 日,開發者就”階段1 的網絡連接問題(networking)“ 進行了一次電話會議。討論下來可以得出:gossipsub 熱度很高+ DHTs 似乎很慢。但在當時,這些為時還早—— 每一個網絡開發者都還在忙著為信標鏈的發布做準備(12 月1 日!),而且由於當時的最新情況,網絡層存在很明顯的偏向。

當時的偏向:

  • Gossipsub = 炙手可熱,主網準備就緒(除了一些DoS 問題之外,沒有多大問題了。並且這些問題也在主網啟動之前發現/披露了)

  • Discv5 = 不完整,需要在主網啟動前從5.0 ->5.1進行實時網絡遷移

(https://github.com/protolambda/discv5-catdog)

但方向似乎很明確:減少L1 複雜性,信標鏈已經夠複雜了。只通過數據提高可擴展性,長期來看使用“數據可用性採樣”方案,並擁抱L2 擴容解決方案。因此Vitalik 將其描述為《以rollup 為中心的以太坊路線圖》 (中文版)。

然而,當實現者忙於信標鏈的發佈時,研究人員已經忙於發布後的工作了:Vitalik/Dankrad 當時致力於一些早期的數據可用性設計草案,試圖讓實現者更加容易理解這些原理。

同時,我們啟動了Zinken、Toledo 和Pyrmont 測試網+ 檢查更多的啟動事項(檢查漏洞等)。並且我們嘗試跟上研究的進度,並開始針對網絡層上的東西添加設計文檔。就當時來說,關注這些問題還太早了,但DAS (數據可用性採樣) 實在太好了,沒辦法忽視。

基於gossipsub 的一些東西,我確實寫了一些想法,把它用於DAS。事後看來,我現在倒認為DHTs 比Gossipsub 更加適合DAS,也許除了初始分配。

當時我期望一些DAS 的規範能夠被實現和模擬。我想這是“blob” 首次被提到?我們確實在“分片數據blob” 這樣的上下文中使用過它,而且那時分片的規範中還沒出現過這個詞。

信標鏈發布之後,又有了更多的時間,然後我寫了一個草案,在Vitalik 和Dankrad 寫的採樣規範草案中加入了更多typing 和網絡層的內容。將blob 命名引入分片的規範:)

2021 年一些事情發生了改變:為其設計的理想的p2p 結構太複雜了,所以我轉而嘗試為它貢獻工具(go-kzg) 和參與早期的合併工作(rayonism)。然後在夏天再次嘗試加入分片的研究工作,而不是參與Altair/London 升級的開發工作。

Blob 又出現了,這次它的結構更加PBS 化—— 聚合了blob-構建者和blob-提議者的BLS 簽名。但還是太複雜了:因此,分片設計的演進方向變得主要“以信標提議者為中心”,這樣設計使得其“僅” 成為一個網絡層的問題。

這在某種程度上就像是對分片的第五次設計?極簡主義要捨棄掉很多東西,但結果確是美麗且強大的:更多的模塊化設計、封裝以及可選的複雜性。 Rollup 引起了我的注意,尤其是Optimism。

2022 年底,EIP 4488 (注意不要搞混了,不是4844!) 和4490 出現了:人們開始變得不耐煩,calldata 的成本必須快速降低以保持競爭力!倫敦升級之後的All Core devs 上對這些話題的討論也變得很熱烈。但在我看來這是不可持續的,因為calldata 帶有L2 不需要的傳統開銷。

同時,Vitalik 和Dankrad 繼續研究一些新的分片設計:更加以信標鍊為中心、只通過數據進行擴容、專注於採樣方案。我覺得“danksharding” 在21 年底/22 年初真正公開出來?不是很確定第一個版本是哪個了,Dankrad 一直都在研究分片。

22 年初,Vitalik 提出了兩種方法,我們可以在不使用採樣的情況下,向完整的danksharding 發展:簡單版本和復雜版本。雖然在我看來,這其實就是“重EL (執行層)” 以及“EL 和CL 分離,更容易和未來兼容” 之間的區別。

我喜歡第二個方案,然後在EthDenver 2022 期間,我們實現了EIP-4844:我和@lightclients 致力於Geth;@asn_d6 幫助研發KZG;@adietrichs 致力於費用市場的研究;並且都和Vitalik/Dankrad 一起起草一份EIP。 Prysm 團隊構建了首個CL 原型。

現在4844 被命名為”proto-danksharding”:實現完整分片的前提條件。但是“blobspace” 才是真正的模因:經過許多次分片的設計迭代之後,這是比任何其他分片設計都更接近達到以太坊願景的一個版本。

對我來說,Serenity 這個階段就是完成所有PoS 和分片設計以及迭代更新的工作。我們已經在信標鏈以及類似於協議外PBS 這些開發上獲得一些進展,讓我們在PoS 方面有了一個不錯的開始。我想現在是時候對分片進行首次升級了:4844!

還有一些對未來danksharding 的熱點:

  • L1 數據包含延遲對L2 的影響被高估了。

  • 為了獲得更多數據可用性的帶寬,值得權衡的設計空間。

  • Gossip 和TCP DHTs 不好,UDP DHT 類的覆蓋很好:這都是關於輕節點的計數(什麼時候進行discv5 擴展?)

更多danksharding 的熱點:

  • 採樣很大程度上依賴於良好的對等節點,希望看到更多評分優先但健壯的設計。

  • 寧願選擇輕量級的通信和更多的女巫,而不是缺乏p2p 上的驗證者隱私。

  • ZK 可以成為未來p2p 抗女巫的技術,但現在來說似乎還遠著。

展開全文打開碳鏈價值APP 查看更多精彩資訊

Total
0
Shares
Related Posts