大约一年前，我们发布了基于二维纠错码的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数量。
