本文提出了一種新穎的數據可用性採樣 (DAS) 和分片 Blob 內存池設計，旨在增強可擴展性的同時保持去中心化。傳統的 Danksharding 策略假設一個區塊構建者/提議者創建區塊，對其進行糾刪碼處理，然後將完整數據分發到整個對等 (P2P) 網絡。這對網絡帶寬的要求非常高，尤其是對於The Block構建者和提議者是同一節點的小型家庭權益質押者 (home-staker) 而言。本文中的提案通過實現分佈式區塊構建 (DBB) 解決了這個問題，並採用了兩個新思路：i) 分片 Blob 內存池，以及 ii) 部分列傳播。
本文的其餘部分安排如下。首先，闡明作為此新設計基礎的基本假設。然後，介紹當前的 DAS 和 blob 內存池設計。最後，闡述擬議的設計及其帶來的優勢。
假設
以下是我們在這項工作中採用的主要假設。
網絡規模：目前以太坊的網絡規模估計約為 10,000 個節點。本文假設網絡規模將保持在 5,000 到 50,000 個節點之間，但未來幾年可能會有所變化。
塊結構：我們假設所有數據塊都由 512 字節元素組成，稱為“單元”，然後使用擦除編碼（Reed Solomon）進行分組和擴展以創建二維矩陣。
槽位吞吐量：我們的目標吞吐量為256 個 128KB 的 blob ，在使用糾刪碼擴展之前，每個槽位總計 32 MB。因此，在二維糾刪碼擴展之後，大小為 128MB。
數據傳播：Gossipsub 用於在 P2P 網絡內的多個通道上傳播共識層 (CL) 的數據。我們假設 Gossipsub 可以擴展到一千個主題甚至更多。
DAS 和內存池的舊設計
槽週期
一個塊及其 blob 的整個時隙週期可以用以下四個步驟來描述。
1. 內存池
在以太坊網絡中，blob 通過類型 3 ( 0x03 ) 交易提交。該交易可以包含一個或多個 blob，自 Pectra 以來最多可包含 9 個。類型 3 交易通過 devP2P 網絡進行傳播。這意味著，首先將交易的哈希值推送到所有對等點，然後節點可以決定提取交易和相關的 blob 數據，這些數據在BlobTxSidecar中傳輸。如果節點不需要，則無需下載類型 3 交易或 blob 數據。想要構建和提議區塊的驗證者節點應監視網絡交易（包括類型 3），並將所有 blob 下載到其內存池中。Blob 數據進入執行層 (EL) blob 內存池，等待被納入區塊。當選擇節點提議區塊時，它將包含其內存池中的一些 blob，前提是它們的可用性已經過驗證。任何節點都可以選擇下載所有 blob 數據用於其他目的（例如監控、研究）。
2. 建築
一個區塊由兩部分組成：執行有效載荷和 blob 數據。執行有效載荷不包含 blob 數據，它僅通過 type3 交易引用 blob。The Block構建者/提議者選擇要包含在The Block中的 blob 及其順序。在滿負荷情況下，它每個 slot 最多選擇 256 個 blob（每個 128KB），因此在糾刪碼之前，總共約有 32MB 的 blob 數據。The Block構建者通過 Reed-Solomon 編碼水平和垂直擴展這些數據，最終生成一個 128MB 的區塊。
3.傳播
The Block構建者 / 提議者將執行負載廣播到網絡進行驗證，並通過 Gossipsub 通道傳播整行和整列。CL 節點僅保管（即存儲）The Block中所有行和列的一小部分。保管的行數和列數由每個節點決定，但每個節點都必須保管最少數量的行和列。一些節點可以決定保管所有行和列，使它們成為超級節點。CL 節點通過 Gossipsub 接收執行負載以及它們保管的整行和整列。CL 節點在其以太坊名稱記錄（ENS）中告知其他節點其保管的大小。行和列是從節點 ID 確定得出的，因此任何節點都可以知道其對等節點保管哪些行和列。
4. 採樣
CL 節點共同確保所有 blob 均可檢索，而無需每個節點都存儲完整區塊 (128MB)。由於 blob 使用糾刪碼進行擴展，因此，如果數據足夠，即使是部分 blob 數據也可以完全重建。CL 節點執行隨機採樣以驗證數據可用性。每個節點都會從其對等節點中選擇一定數量的隨機單元進行採樣。它知道哪些對等節點保管哪些列/單元，因此可以向這些對等節點發出請求。或者，它可以將請求發送給多個對等節點，並讓任何節點響應。
這種設計的缺點
- 想要構建/提議區塊的驗證器節點必須將所有 blob 下載到其內存池中。
- The Block構建者/提議者在生成區塊時需要傳播（即上傳）所有擦除編碼的 blob 數據（128MB）。
- Blob 在 EL 和 CL 上傳播（作為行），導致冗餘和帶寬浪費。
- 整行和整列都通過網絡傳播
新設計
想法和理由
這一新設計的主要目標有三方面：
- 減少 EL 節點需要在 blob 內存池中下載的數據量，
- 消除 EL 和 CL 之間存在的網絡冗餘
- 減少需要上傳並由 CL 節點保管的數據量。
在本節中，我們介紹此新設計中引入的新概念。
水平分片的 Blob 內存池
每隔幾秒下載幾十MB的blob數據會對互聯網帶寬有限的家庭權益持有者造成壓力。因此，我們提出了一種水平分片的內存池設計，以便EL節點只需下載部分blob。主要思想是根據節點ID和它們將存儲的blob的類型3交易的哈希值對節點進行分片：當且僅當類型3交易哈希值的最後4位與其節點ID的最後4位匹配時，節點才應該下載類型3交易及其相關blob。這將創建16個不同的分片，其中所有類型3交易和blob都是不相交的。EL節點下載到其內存池中的相同blob是CL節點必須保管的相同行，因此無需通過CL網絡下載行；可以通過從EL到CL的getBlobs獲取它們。這意味著，對於每個時隙，節點將根據類型 3 交易的哈希值保管不同的行。儘管如此，根據對等節點的節點 ID 和時隙的執行有效負載，計算出對等節點在給定時隙保管的行 ID 應該相當簡單。在本例中，我們使用了 4 個比特（16 個分片），但不一定非得是 4 個；它可以是任意數量的比特B ，用於對我們希望每個區塊擁有的 256 個 blob 進行分片。這減少了網絡帶寬，同時加速了The Block創建後 CL 層的數據傳播。
需要強調幾點。由於行託管基於類型 3 交易哈希，因此節點需要存儲的 blob/行數在不同時隙之間並不相同，因為它取決於哈希值和每個交易的 blob 數量。但是，平均而言，所有節點在統計上存儲的數據量相同。相反，對於給定的時隙，並非所有節點都存儲相同數量的行。儘管如此，所有 blob 都會在節點之間平均分佈並進行穩健複製。此策略通過消除 CL 處的 blob/行傳播來避免 EL 和 CL 冗餘。另一個可用的策略是驗證者託管：要存儲的 blob/行數可以與節點中的驗證者數量成正比。例如，對節點的最低要求可以是匹配節點 ID 的最後B位，而對於具有驗證者的節點，則可以匹配最後B-1位。具有更多驗證者的節點可能會更頻繁地提議區塊；因此，在 Blob 內存池中擁有更多 Blob 有助於他們更快地構建區塊。此外，從經濟角度來看，擁有多個驗證者的節點可能擁有足夠的硬件和網絡資源來保管更多 Blob/行。
部分專欄傳播
列與 blob 的不同之處在於，它們僅在The Block構建後才為人所知。因此，只有在The Block構建者/提議者決定包含哪些 blob 及其順序後，才能傳播列，即使是部分傳播。在本提案中，CL 節點需要保管多個列，並且這些列的確切索引由節點 ID 確定，與之前的設計相同。這些列索引在節點的整個生命週期內保持不變。這意味著，**與行相反，節點在每個 slot 始終存儲相同數量的列，並且始終是相同的列。行和列之間的這種差異對於優化網絡帶寬利用率至關重要。同時，它能夠實現穩健的數據保管和快速採樣。
與整列傳輸相反，部分列傳輸是此新設計的關鍵部分，因為在水平分片的內存池中，大多數節點在收到執行負載時將無法傳播整列。因此，部分列傳輸對於傳播部分數據和加速區塊擴散至關重要。例如，如果 blob 內存池被分成 16 個分片，那麼為了獲得整列，節點需要通過該列的 gossipsub 主題接收 16 條部分列消息。通過在每個節點收到執行負載後立即傳播部分列，網絡無需依賴The Block構建者/提議者的上傳速度來獲取其各自的列。當The Block提議者是上傳帶寬有限的本地抵押者時，這一點尤為重要。此外，即使所有 EL 節點都擁有其內存池中的所有 blob 並共享整列以避免The Block提議者的瓶頸，它們仍然需要上傳整列。相比之下，這種設計允許每個節點僅發送 1/16 列，從而減少帶寬消耗。
新設計老虎機週期
1. 內存池
此設計與現有設計之間的主要區別在於引入了分片內存池。在此設計中，節點僅下載一定數量的類型 3 交易和相關的 Blob Sidecar（即 Blob 數據） 。每個節點必須保管的 Blob 是根據節點 ID 以確定性方式計算出來的，這樣每個節點都可以知道自己要下載哪些 Blob，還可以知道其對等節點保管哪些 Blob。每個節點都應該下載並存儲在其 Blob 內存池中的類型 3 交易的最小數量。具有驗證器的節點可以在其 Blob 內存池中保管更多 Blob，類似於驗證器保管。節點可以選擇將每個 Blob 下載到其 Blob 內存池中，因為它們有許多驗證器，或者因為它們需要它來完成其任務（例如，區塊構建器、彙總器、瀏覽器）。
2. 建築
目標是在每個 slot 中引入 256 個 128 KB 的 Blob，總計 32 MB 的 Blob 數據，在糾刪碼之前。在這種新設計下，The Block構建者/提議者擁有一個有限的（即分片的）類型 3 交易列表，可以將其附加到其區塊中。它可以決定只附加來自其受限列表的 Blob。然而，還有另一種策略。由於區塊提議者是預先已知的，因此需要在下一個週期提議區塊的節點可以暫時更改其 Blob 內存池的行為，開始下載所有類型 3 交易和 Blob，直到The Block被提議，屆時它們可以恢復到標準的 Blob 內存池行為。
3.傳播
The Block構建者/提議者應該傳播的第一件事是執行有效負載，其中包括附加到The Block的3 類交易和 blob 的列表。
CL 節點需要保管（即存儲）EC 擴展區塊中的若干行和列。在此設計中，我們建議 CL 需要保管的行應該與 EL 節點下載到其內存池中的 Blob 相同。這樣一來，我們確保無論The Block中包含哪些 Blob，每個遵循協議的 CL 節點都無需通過網絡接收任何水平行，因為它們的 Blob 內存池中已經擁有這些行。相反，它們可以通過糾刪碼技術進行水平擴展，並將其從 EL 節點的 Blob 內存池轉移到 CL 保管存儲。在這種情況下，任何節點（即使是The Block構建者）都不應通過 CL 網絡推送水平行，因為水平傳播發生在 EL 節點，因此沒有必要這樣做。如果由於某種原因（例如網絡或硬件故障），某個節點的 Blob 內存池中沒有應有的 Blob，它可以通過拉取操作向其他節點請求這些 Blob。
關於列傳播，當 CL 節點接收到The Block的執行有效載荷時，它知道哪些 blob 要包含在The Block中。由於該節點擁有The Block的部分行，因此它也擁有節點負責的列的部分單元格，但不是全部。因此，節點不會發送整個列（除非它是超級節點），而是通過 Gossipsub 主題傳播部分列。這應該能夠從列主題中的所有對等節點快速檢索列。一旦節點從非擴展列中接收到所有單元格，它就會使用糾刪碼垂直擴展該列。此時，網絡中的所有節點都應將其相應的行和列分配給託管。
4. 採樣
新設計中採樣沒有顯著變化。一切與之前的設計相同。
一些數字
假設在任何給定時間，大約有 1000 個類型 3 的交易可供區塊構建者選擇在下一個區塊中引入哪些交易。對於希望將所有 Blob 都放入其 Blob 內存池中的區塊構建者來說，這將導致 Blob 內存池的大小約為 128MB。假設沒有驗證者的節點保管以與其節點 ID 相同的 4 位結尾的 Blob，那麼它們將持有這些 Blob 的 1/16。也就是說，平均 1024 個 Blob 中，有 64 個 Blob（約 8MB）。假設一個網絡包含 8,000 個節點，並且節點 ID 均勻分佈，那麼每個 Blob 將存儲在大約 500 個節點上，從而提供足夠的冗餘和穩健性。藉助我們的爬蟲，我們獲取了當前網絡中的 EL 節點列表，並按照此設計對它們進行了分片。上圖顯示了每個分片中存在的節點數量。
我們還分析了從 Pectra（5 月 22 日）到 6 月 3 日（6107 個 epoch）的所有類型 3 交易，並根據它們各自的分片繪製了圖表，以檢查它們的分佈均勻性。總共有 254,097 筆類型 3 交易分佈在 16 個分片上，如下所示。
類似地，我們驗證了 707,923 個 blob 也均勻分佈在各個分片中。
這不包括多驗證器節點和超級節點。
實施這一新設計
為了實現本文提出的水平分片 blob 內存池設計， EL 節點在拉取類型 3 交易之前只需要進行一次額外檢查，即驗證匹配的哈希值。
對於列傳播，我們需要實現部分列傳輸，以便傳播部分列。這可以簡單到發送一個較短的（1/16）列以及單元格在該列中的位置列表。
討論
其他一些策略可以補充這一建議：
我們可以添加一個Blob 內存池票據，用於將 Blob 引入 Blob 內存池。該票據可以通過拍賣獲得。Blob 內存池票據的目的是限制注入內存池的 Blob 數量，從而防止 DoS 攻擊。然而，在本設計中，Blob 內存池是水平分片的，因此 Blob 內存池票據的需求並不大。
The Block構建者/提議者可以“盡力而為”地傳播所有數據（行和列）。雖然大多數數據列將通過部分傳播從其他對等節點到達，但來自The Block構建者的列可以作為備份策略。
節點應使用 IDONTWANT 消息來減少接收單元時的帶寬。請注意，部分傳播將始終傳播完全相同的部分消息，因為分片是不相交的且具有確定性。因此，IDONTWANT 消息在部分傳播的環境下仍然有效。
由於列傳播從所有節點同時開始，我們可以實施推拉相變策略，同時最大限度地減少匿名性問題。
致謝
這項研究由Codex 團隊完成。我們感謝@dankrad和其他 DAS 研究人員的反饋和貢獻。
