來源| @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 抗女巫的技術，但現在來說似乎還遠著。
點擊“閱讀原文”獲取文章內部鏈接！
原文鏈接： https://twitter.com/protolambda/status/1584105020697432064
ECN的翻譯工作旨在為中國以太坊社區傳遞優質資訊和學習資源，文章版權歸原作者所有，轉載須註明原文出處以及ETH中文站。若需長期轉載，請聯繫eth@ecn.co進行授權。
