以太坊已經轉向以 rollup 為中心的路線圖。
原文：The Hitchhiker's Guide to Ethereum（Delphi Digital）
作者： Jon Charbonneau
編譯： zCloak Network
原用標題（譯後）：以太坊漫遊指南（中篇）
封面：William Tempest（Ethereum）
第一部分：通往 Danksharding 之路，前文內容詳見——以太坊漫遊指南（上篇）
Danksharding
PBS（出塊者-區塊打包者分離）的設計最初只是為了削弱驗證者集群的 MEV 中心化力量。然而，Dankrad 最近利用這一設計解鎖了一個更好的分片結構—— Danksharding。
Danksharding 利用特定的區塊打包者來創建更緊密的信標鏈執行區塊和分片集成。如果沒有 PBS ，Danksharding 就無法實現，因為常規的驗證者無法處理充滿 rollup 數據 blob 的區塊佔用的巨大帶寬，所以現在我們有專門創建整個區塊的區塊打包者、在某時刻對該區塊進行投票的委員會，以及出塊者。
分片 1.0 有 64 個獨立的委員會和出塊者，因此每個分片都可能單獨不可用。但在 Danksharding 中，信標鏈執行區塊和分片之間更緊密的集成能夠一次性確保數據可用性。本質上 Danksharding 中的數據仍然是"分片化的"，但實際使用者會感覺更像是大區塊，這是一件好事。
Danksharding – 誠實多數驗證
驗證者證明數據的可用性，如下所示：
這依賴於驗證者中大多數誠實—— 單個驗證者檢測到的行和列的可用性不足以讓該驗證者在統計上相信整個區塊是可用的，驗證者中大多數誠實決定整個區塊是否可用，這也是為什麼去中心化驗證如此重要。
這與我們之前討論的 75 個隨機樣本有所不同。隱私隨機抽樣是資源匱乏的個體檢查可用性時使用的方法（例如，我可以運行一個數據可用性抽樣輕節點並知道區塊是可用的），但是，驗證者將繼續使用檢查行和列的方法來檢查可用性以及引導區塊重構。
Danksharding – 重構
只要單個行或列的 50% 是可用的，那麼數據可用性抽樣驗證者就可以輕易地、完整地重構該行或列。當它們重構行或/和列中缺失的數據塊時，它們會將這些數據塊重新分配到正交線上。這有助於其它驗證者根據需要從相交的行和列中重建任何丟失的數據塊。
重構一個行或/和列中可用數據塊的安全假設是：
- 有足夠多的節點執行採樣請求，以便它們共同擁有足夠的數據來進行重構
- 用於節點間廣播各自區塊碎片的同步假設
那麼，多少個節點是足夠的呢？粗略估計大約需要 64,000 個實例（目前有超過 380,000 個實例）。這也是一個非常悲觀的計算，因為它假設同一驗證者運行的節點沒有交叉（這與節點被限制為 32 個 ETH 實例的情況相去很遠）。如果你的採樣超過 2 行和 2 列，你就會因為交叉而增加集體檢索到用於重構的數據的機率，這會以平方擴展—— 如果有 10 個或 100 個驗證者正在運行，需要的實例可以減少幾個數量級。
如若在線驗證者的數量非常低，可以通過設置 Danksharding 來自動減少分片數據 blob 計數。因此，安全假設就會被降低到安全水平。
Danksharding - 惡意多數安全與隱私隨機抽樣
我們看到，Danksharding 驗證依賴於誠實多數對區塊進行證明，單個驗證者無法通過下載幾行和幾列來證明一個區塊是否可用，但隱私隨機抽樣允許單個驗證者在無需信任任何人的情況下確保某區塊是可用的，這就是前面討論的節點檢查 75 個隨機樣本。
隱私隨機抽樣在網絡方面是一個非常難解決的問題，所以 Danksharding 在初始階段不會包含該組件。
"隱私"是尤其重要的，如果攻擊者對你進行去匿名化處理，他們就能欺騙少量的採樣節點。攻擊者可以只返回驗證者請求的數據塊，扣留其餘的請求不作回應，所以驗證者無法從自己的抽樣中知道是否所有的數據都是可用的。
Danksharding – 關鍵要點
Danksharding 除了名字好聽，其性能也令人難以置信。它可以實現以太坊統一結算和數據可用層的願景。這種信標區塊和分片的緊密耦合本質上是假裝沒有分片。
讓我們明確一下為什麼 Danksharding 甚至被認為是"分片"。“分片" 唯一剩下的部分就是驗證者不負責下載所有數據，而這就是為什麼 Proto-danksharding 不被認為是"分片的" 的原因（儘管它的名字裡有"分片 sharding"）。Proto-danksharding 要求每個驗證者完整地下載所有分片 blob ，以驗證它們的可用性；Danksharding 則隨後將引入抽樣，單個驗證者只需下載分片 blob 的片段。
值得慶幸的是，最小分片是比分片 1.0 更簡單的設計（所以有更快的交付不是嗎？）。更簡單的意思是：
- 與分片 1.0 規範相比，Danksharding 規範少了數百行代碼（客戶端少了數千行）
- 不再有分片委員會基礎設施，委員會只需在主鏈上投票
- 不再追踪獨立分片 blob 的確認，因為現在它們都在主鏈上得到確認，或者不被確認。
這樣做的一個好處是合併了數據收費市場。分片 1.0 中，獨立出塊者們各自提交不同的區塊使數據收費市場非常零碎。
取消分片委員會也加強了反賄賂性。Danksharding 的驗證者每個週期對整個區塊投票一次，因此數據會立即被整個驗證者集的 1/32 確認（每個週期有 32 個槽）。雖然分片 1.0 的驗證者同樣是每個週期投票一次，但每個分片的委員會都會被輪換，因此每個分片只被 1/2048 的驗證者集（64 個分片中所有驗證者的 1/32）確認。
區塊與二維 KZG 承諾方案相結合也大大提高了數據可用性採樣的效率。分片 1.0 需要 60KB/s 的帶寬來檢查所有分片的全部數據可用性，而 Danksharding 只需要 2.5KB/s。
Danksharding 還保留了 ZK-rollups 和 L1 以太坊執行之間的同步調用，也就是說，來自分片 blob 的交易可以立即被確認並寫入 L1，因為一切都發生在同一個信標鏈區塊中，這實在太棒了。但在分片 1.0 中，由於獨立分片各自確認，使得其不具備這種可能性。這形成了一個令人興奮的設計空間，對共享流動性（如 dAMM）等可能是非常有價值的。
Danksharding – 區塊鏈可擴展性的限制
模塊化的基礎層可以優雅地擴展—— 更大程度的去中心化帶來了更多的擴展，向數據可用性層添加更多節點可以安全地增加數據吞吐量（即上面有更多的空間進行 rollup)。這與我們今天看到的情況有本質性區別。
雖然區塊鏈的可擴展性仍將受到限制，但相比目前的情況，我們可以將區塊鏈的可擴展性提高幾個數量級。安全和可擴展的基礎層允許執行量的激增，並且隨著時間的推移，數據存儲和帶寬的改進也將允許更高的數據吞吐量。
想要超越這裡考慮的數據可用性吞吐量是有完全可能的，但很難預估這個最大值最終會達到多少。這裡沒有一條明確的界限，只有一個包含一些讓人感到不舒服的假設的區域:
- 數據存儲—— 這與數據可用性和數據可檢索性有關。共識層的作用不是無限期地保證數據可檢索性，而是讓數據在足夠長的時間內可用，讓任何想下載它的人都能下載，以滿足我們的安全假設，然後數據可以被轉儲到任何其它地方，因為歷史是 N 個信任假設中的 1 個，而且從整體局面來看我們實際上不會談論這麼多的數據。不過，幾年後，隨著吞吐量的指數級增加，這可能依然會成為人們非常關注的一個問題。
- 驗證者—— 數據可用性抽樣需要足夠多的節點來共同重構區塊，否則攻擊者可以在周圍侍機而待，僅對他們收到的查詢做出回應。如果提供的這些查詢不足以重構區塊，攻擊者可以扣留其餘的數據，那麼重構就沒戲了。為了安全地增加吞吐量，我們需要增加更多的數據可用性抽樣節點或提高它們的數據帶寬要求，這些對於這裡討論的吞吐量來說是合理的。不過，如果吞吐量在這個設計的基礎上再增加幾個數量級，可能就會變得棘手不那麼容易處理了。
請注意，區塊打包者並不是重構的瓶頸。如果你需要為 32MB 的數據快速生成 KZG 證明，最好有一個 GPU 或相當強大的 CPU 加上至少 2.5G Bit/s 的帶寬。當然，區塊打包者是一個專門的角色，對他們而言，上面提到的這些都是可以忽略不計的業務成本。
Proto-danksharding (EIP-4844)
好東西總是值得耐心等待，比如 Danksharding。Proto-danksharding 旨在幫助我們渡過這個等待期—— 為過渡期提供數量級的擴展，Proto-danksharding 實現了必要的向前兼容步驟（指上海硬分叉），以加速通往 Danksharding。然而，它實際上還沒有實現數據分片（驗證者目前還是需要逐一下載所有的數據）。
Rollups 現在使用 L1 "calldata " 進行鏈上永久存儲。但 rollups 只是在一些合理的時間段內執行數據可用性，以便任何對數據可用性感興趣的人都有足夠的時間下載它們。
EIP-4844 引入了新的攜帶 blob 的交易格式，rollups 將使用這種格式進行數據存儲。Blob 攜帶的大量數據（~ 125KB）比相同數量的 calldata 便宜得多。由於數據 blob 將在一個月後從節點上被刪除，所以有足夠的時間來滿足數據可用性安全假設，同時刪除數據 blob 也降低了存儲需求。
在擴容語境下，目前以太坊區塊的平均大小通常為~ 90 KB（calldata 佔用其中的~10 KB）。由於數據 blob 在一個月後會被刪除，所以 Proto-danksharding 為 blob 釋放了更多的數據可用性帶寬（目標是~1MB，最大為~2MB），不會對節點造成永久性的拖累。
一個 blob 是一個包含 4096 個字段元素的矢量，每個字段元素有 32 字節。Proto-danksharding 允許每個區塊最多有 16 個 blob ，而 Danksharding 會將其提升到 256 個。
Proto-danksharding 數據可用性帶寬= 4096 x 32 x 16 = 每區塊 2 MiB，目標是 1 MiB
Danksharding 數據可用性帶寬= 4096 x 32 x 256 = 每區塊 32 MiB，目標是 16 MiB
每一步都是數量級級別的擴展。Proto-danksharding 仍然需要共識節點來完整地下載數據，所以它比較保守。Danksharding 在驗證者之間分配存儲和傳播數據的負載。
以下是 EIP-4844 在通往 Danksharding 的道路上引入的一些好東西：
- 攜帶數據 blob 的交易格式
- 對 blob 的 KZG 承諾
- Danksharding 所需的所有執行層邏輯
- Danksharding 所需的所有執行/共識交叉驗證邏輯
- 信標區塊驗證和數據可用性抽樣 blob 之間的層分離
- Danksharding 所需的大部分信標區塊邏輯
- Blob 有可以自我調節的獨立 gas 價格（具有指數定價規則的多維 EIP-1559）。
緊接著，Danksharding 將進一步增加：
- PBS（出塊者-區塊打包者分離）
- 數據可用性抽樣
- 二維 KZG 方案
- 監管證明（Proof-of-custody）或類似的協議內條件，以使每個驗證者都能驗證每個區塊中分片數據特定部分的可用性（可能需要一個月左右的時間）。
注意這些數據 blob 是作為鏈上執行的新交易類型引入的，但它們不會給執行方帶來的額外要求。EVM 只查看附在 blob 上的承諾。使用 EIP-4844 進行的執行層更改也向前兼容 Danksharding ，在這方面不需要進行更多的改動。從 Proto-danksharding 升級到 Danksharding 只需要更改共識層。
數據 blob 由共識客戶端在 Proto-danksharding 中完整下載。Blob 目前在信標區塊體中被引用，但沒有被完全編碼。Blob 的內容以 “sidecar” 的形式單獨傳播，而不是將其全部嵌入區塊體。在 Proto-danksharding 中完整下載的每個區塊都有一個 blob sidecar，Danksharding 驗證者將在這上面執行數據可用性抽樣。
我們在前面討論瞭如何使用 KZG 多項式承諾對 blob 進行承諾。然而，EIP-4844 沒有直接使用 KZG，但實現了我們實際需要的東西—— 帶版本哈希。這是一個單一的 0x01 字節（表示版本），後面接著 KZG 的 SHA256 哈希的最後 31 字節。
這樣做是為了更容易地實現 EVM 兼容和向前兼容：
- EVM 兼容—— KZG 承諾有 48 字節，而 EVM 更自然地使用 32 字節的值。
- 前向兼容性—— 如果我們從 KZG 轉向其它東西（比如可用於抗量子的 STARKs），承諾可以繼續是 32 字節的。
多維 EIP-1559
Proto-danksharding 最終創造了一個量身定制的數據層—— 數據 blob 將擁有自己獨特的收費市場，即有獨立浮動的 gas 價格和限制。因此，即使某個 NFT 項目在 L1 上賣了一堆猴子土地，你的 rollup 數據成本也不會增加（儘管證明結算成本會增加），這也承認了現在任何 rollup 項目的主要成本來自於將其數據發佈到 L1（而不是證明）。
gas 費市場不變，新增數據 blob 市場：
Blob 費是以 gas 收取的，但它是一個根據自身 EIP-1559 機制的可變的金額。每個區塊的長期平均 blob 數量應等於目標數量。
驗證者實際上在並行運行兩個拍賣—— 一個用於計算，一個用於數據可用性。這是高效資源定價的一個巨大飛躍。
這裡有一些有趣的設計，例如，將目前的 gas 和 blob 定價機制從線性 EIP-1559 改為新的指數 EIP-1559 機制，這或許是合理的。目前的實現在實踐中並沒有平均到我們的目標區塊大小，今天的基本費用還沒有完全穩定下來，所以觀察到的塊均 gas 消耗平均超過目標值~3%。
（因本文篇幅過長，後續詳見下篇）
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。本文內容僅用於信息分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
