大約一年前，我們釋出了基於二維糾錯碼的FullDAS設計，針對每個插槽32MB資料（256個數據塊），包含以下要素：
用於分散到託管的高效協議，使用
用於從託管中取樣的快速輕量級協議，使用
- 單元級訊息傳遞
- 本地隨機性以提高取樣安全性
- 從託管快速傳遞樣本
- 使用LossyDAS改進和自適應取樣
基於行和列ID的新對等節點發現結構以消除連線延遲
事實上，設計的幾個部分自2022年以來就在開發中，首次在EthereumZurich'2023上展示。
[翻譯已完成，由於篇幅限制，只顯示了部分內容。如需完整翻譯，請告知。]另一個問題是，隨機係數分佈在整個單元ID空間中，沒有部分修復。一個節點需要收集與結構中單元數量相同的（至少）原始單元的線性組合。這就是為什麼許多基於線性組合（甚至簡單的異或）的編碼會限制用於構建組合的原始元素（單元）的數量和範圍。可以想象大多數係數被強制為0，只有少數被允許隨機選擇。這以輕微降低編碼效率為代價，實現了部分修復。例如，LT碼使用這個技巧來實現高效解碼。我們將這個概念稱為受限隨機線性組合（R-RLC）。
同樣，我們可以將RLC限制在列（或行），僅使用給定列的單元的線性組合，並將這些組合傳送到擁有該列的節點。這將使節點在獲得足夠的列單元時能夠進行恢復，這是一種部分恢復。然而，我們仍然無法在行和列之間進行交叉轉發，因為列單元的線性組合對行分佈沒有幫助。即使解碼列後，交叉轉發也會受限：解碼相同列的節點將擁有行的相同元素，而不是不同的線性組合。
另一個可能想到的選擇是使用類似於二維裡德-所羅門碼的線性組合，具有預定義的擴充套件因子，並使係數取決於行和列ID……但是透過這種方式，我們基本上是複製了我們的裡德-所羅門碼所做的事情。
那麼我們可以用RLC做什麼呢？以下是設計空間中的幾個選項及其優缺點。請注意，這仍在進行中，所以不要期待比我們基線（二維裡德-所羅門編碼）更好的明確解決方案。
基於RLC的設計第1種
我們保持行和列分佈不變，使用二維裡德-所羅門碼，但我們改變取樣以獲得線性組合。這裡的想法是賦予取樣節點在恢復情況下做更多事情。
優點：
在可能的重建中，單個樣本現在更有用。它不僅僅是一個單元，而是給定列（或行）的所有單元的隨機線性組合。這意味著我們需要更少的樣本來恢復一列或整個塊，因為沒有兩個樣本是相同的。構建機率模型很容易（我們留待以後），但更重要的是，欺騙節點變得更加困難。在裡德-所羅門情況下，我們可以選擇255（或N-K-1）個單元，並分發任意多的副本，重建仍然是不可能的。在RLC情況下，一旦分發了256個NI-RLC副本，解碼就是有保證的。
缺點：
我們v1 FulDAS設計中取樣快速的原因之一是，託管節點可以在接收到單元時立即轉發。這使得采樣在託管層面上僅落後於分散1跳延遲。在新設計中，樣本只能在節點擁有整個列（或行）的託管權後才能傳送。這更慢。
基於RLC的設計第2種
我們保持基於行和列的分佈，但使用RLC進行。塊構建者向對託管列（或行）感興趣的節點發送受限且可驗證的NI-RLC，這些節點以點對點方式轉發，例如使用GossipSub。
然後我們按照第1種設計進行基於RLC的取樣。
優點：
- 我們沒有混合使用裡德-所羅門和RLC。
缺點：
- 與第1種設計一樣，我們減慢了取樣速度。
- 基於RLC的行/列分佈意味著我們無法在行和列之間交叉轉發，這導致擴散較慢，可用性放大程度降低。
基於RLC的設計第3種
在這種設計中，我們改變了包括驗證者和全節點在內的所有人的託管和取樣概念。
在我們最初的設計中，節點託管blob資料的整行和整列。然而，為了獲得機率保證，情況不必如此。具有可驗證的目標依賴隨機性的線性組合可以履行相同的角色。
這種設計的問題是，應該由誰建立這些組合，只有塊構建者或擁有所有blob的節點才有資料來執行此操作。因此我們將失去點對點重分發，轉而採用客戶端-伺服器模型。顯然這不是我們想要的。
優點：
- 我們擁有更強的個性化樣本，沒有重疊。這比二維裡德-所羅門給我們的更強，意味著我們需要從網路收集更少的片段來重組原始資料。
缺點：
- 我們失去了點對點網路效應，塊構建者基本上作為伺服器為整個網路提供服務。
- 節點只有線性組合，但沒有人擁有原始資料的實際片段。雖然理論上這已經足夠，但實踐中擁有資料本身（如系統編碼如裡德-所羅門）有其優勢。
由於沒有點對點重分發，這不是一個真正可行的選項，只是通向第4種選項的序曲
基於RLC的設計第4種
我們能否更好地結合基於RLC的機率保證、目標強制線性組合和點對點重分發？
我們認為可以，透過構建受限線性組合（R-RLC）的分層結構，但對此我們計劃進行專門的撰寫。
當然，存在GossipSub開銷，但是正如討論的推拉技術，可以將這種開銷降低2倍甚至更多，且不會顯著增加延遲。
那麼瓶頸在哪裡？
基於單元的模型中，最可能的瓶頸在於每條訊息的開銷。這包括處理開銷，如訊息驗證和擦除編碼，以及網路開銷，如報頭和訊息ID傳播。
對於後者，我們提出了使用結構化訊息ID和IHAVE/IWANT點陣圖。這仍有待具體說明和實施。
對於處理開銷，我們應該審查我們的網路堆疊並改進批次驗證等方面。我們可能最終不得不使用多單元訊息而不是單一單元作為折中方案。混合模型，即同時使用列級和單元級訊息，也正在討論中。
結論
FullDAS仍在不斷發展，設計很可能會改變，但我們已經有一系列技術可以逐步引入，以增量方式擴大blob數量。這些變化中的許多是正交的，能夠成倍地提高我們支援的blob數量，使我們能夠快速擴充套件以太坊的blob數量。
