Avail 测试网现已上线。随着用户开始将 Avail 集成到他们的链设计中，经常出现的一个问题是：“Avail 能处理多少交易？”这是关于扩展性系列文章的最后一篇，将讨论 Avail 目前的性能以及其短期和长期的扩展能力。你可以在这里阅读第一部分，这里阅读第二部分。
下面的模型描述了一种架构，在这个架构中，提出和构建区块的行为（决定哪些交易/数据块包含在区块中）被分开，并由不同的参与者执行。
通过创建这种新的区块构建者实体，生成行承诺（row commitments）和生成单元证明（cell proofs）所需的计算工作可以在不同的参与者之间分担。
Avail 的核心功能是接收数据并输出有序数据。可以将其想象成一个 API。Avail 使任何人都能够对数据的可用性进行抽样。
在强调我们能改进的地方之前，我们首先详细说明 Avail 在当前状态下对区块提议者和验证者/完整节点的要求。
1. 区块生产者创建区块主体
收集交易（数据提交）
将这些交易排序到 Avail 数据矩阵中，该矩阵成为区块主体
2. 区块生产者创建区块头
为矩阵的每一行生成承诺
使用多项式插值扩展这些承诺（生成的和扩展的承诺成为区块头）
3. 区块生产者传播区块（主体 + 头）
4. 验证者和完整节点接收区块
5. 验证者和完整节点对区块进行解码、重构和验证
重建数据矩阵
重建承诺
扩展承诺
验证他们收到的所有数据是否与他们生成的承诺相匹配
第五步，要求完整节点重新生成区块头，在像 Avail 这样的系统中是不必要的。
完整节点目前之所以这样做，是因为 Avail 继承了传统区块链的架构，而传统区块链需要验证者来确认执行操作是否正确完成。Avail 不处理执行操作。区块提议者、验证者和轻客户端只关心数据的可用性。这意味着 Avail 网络中的所有参与者都可以选择使用数据可用性抽样来无需信任地确认数据的可用性。
由于验证者和完整节点可以通过抽样来检查数据的可用性，他们无需重建整个区块来保证网络的安全性。
验证者无需通过重做生产者所做的所有事情来检查每件事是否真实。相反，他们可以通过少量抽样来检查。就像轻客户端那样，当达到数据可用性的统计保证（8 - 30 次抽样后），验证者可以将该区块添加到链上。因为 Avail 不处理数据执行，所以可以安全地执行此操作。
数据抽样为验证者提供了一种比繁琐的 1:1 验证过程快得多的替代方案。Avail 的神奇之处在于，通过仅使用区块头，任何人（在这种情况下是验证者）都可以达成共识，认为他们正在遵循正确的链。
如果我们能做到这一点，我们就可以用几次抽样来替代整个区块头重建步骤。
本文将探讨在我们对验证者的要求上的转变，以及其他一些改进。我们将描述一个改进的系统，在这个系统中，区块提议者（仍然）创建并传播区块，但所有其他网络参与者通过数据可用性抽样与网络进行交互。然后，我们将引入一个更进一步的系统，它将区块构建和区块提议分开，由两个不同的网络参与者进行操作。
需要注意的是，这些变化相对更高级，目前仍在积极研究中。
对于 Avail 来说，一个更有效的模型是由单个节点构建并向网络传播承诺。然后，所有其他参与者将生成并验证证明。
这是我们首次使不仅是轻客户端，而且任何链的部分都能做到这一点。我们允许验证者以与轻客户端相同的方式进行抽样。
这种模型中，单个验证节点提出区块，为数据矩阵的所有行创建承诺，然后只提出区块头。
步骤 1：提议者只传播区块头的信息。
步骤 2：由于验证者只接收到头部信息，他们无法解码或重构区块。但由于他们可以进行数据可用性抽样，所以他们不需要这么做。
在这种情况下，其他验证者的行为类似于轻客户端。
这些其他验证者将使用承诺进行数据可用性抽样，并且只有在达到可用性保证时才接受区块。
在这个世界中，所有节点都将类似于轻客户端一样运行。验证者可以避免使用区块体来重新生成承诺，以确保区块提议者的正确计算。
当验证者可以简单地依赖证明验证时，生成用于证明计算的承诺是不必要的。
由于我们不需要全节点验证区块的有效执行（Avail 不执行执行操作！），所以全节点仅凭头部信息就可以确定他们正在跟随正确的链。我们只需要可用性的证明，头部信息（结合少量随机样本）可以提供这一点。这使我们能够减少成为验证者所需的计算量。
这还有可能降低通信时间的额外好处。
复杂性
我们犹豫是否能在短期内完成这个模型，因为它需要从 Substrate 的基本结构中脱离出来。我们需要移除外部根（extrinsic root），这打破了对 Substrate 工具的所有访问，尽管这是我们正在积极探索的改进。
另一种模型借鉴了 EIP-4844 中的分片 blob 模型。https://eips.ethereum.org/EIPS/eip-4844?ref=blog.availproject.org
想象一下这个系统：
1. 区块数据矩阵的每一行由不同的构建者建立，同时包括该行的相关多项式承诺。
构建者将他们的行与 p2p 网络共享，并将承诺传递给提议者。
2. 头部创建：单个区块提议者收集这些承诺。
提议者从构建者（和 p2p 网络）中抽样，以确认给定的承诺在抹除编码承诺之前可以生成有效的开放证明。这个原始承诺 + 扩展承诺的组合成为头部。
3. 提议者将这个头部与验证者共享。
4. 提议者和验证者通过从 p2p 网络（或构建者）中抽样随机单元，并确认数据生成有效的开放证明来执行数据可用性抽样。
5. 一旦验证者达到可用性的统计保证，区块头部就被添加到链上。
区块提议者不需要做太多工作，因为承诺是由许多参与者生成的。
懒惰提议者模型有一个区块的单一提议者。然后，参与者可以像上述提议者-构建者分离方式一样被划分。
可以有多个构建者创建区块的小块。他们都将这些块发送给一个实体（提议者），该实体对每个部分进行随机抽样，以构建它提出的头部。
区块体是用逻辑结构构建的。
一个例子
使懒惰提议者模型不同的是，区块构建者和区块提议者是独立的实体。
假设有四个区块构建者，每个人都有数据矩阵的一行。每个构建者使用该行创建一个承诺。
然后，每个构建者将他们的行和构建的承诺发送给指定的提议者，提议者从区块体中抽样数据，以确认给出的承诺。然后，提议者对承诺进行多项式插值，以便他们不仅有四个原始构建的承诺，而且还有八个承诺。数据矩阵现在已经被抹除编码和扩展了。
这八行和八个承诺由同一个提议者验证。
在查看整个矩阵时，我们可以看到，一半的行是由提议者构建的（通过抹除编码），另一半是提供给他们的。
然后，制作者提出一个区块头，每个人都接受。这导致的区块看起来与 Avail 测试网当前正在生产的区块相同，尽管它们构建得更高效。
Avail 的懒惰提议者模型更有效率，但也相当复杂。虽然还有其他更加容易的优化整个系统机会，但 Avail 团队很高兴探索实施这种模型。
对比传统区块链交易与懒惰提议者模型
懒惰提议者模型与今天非 Avail 区块链上处理的个别区块链交易的方式并无太大不同。
如今，当任何人在几乎任何链上进行交易时，他们会向所有节点发送这笔交易的通知。很快，每个节点的内存池中都会有这笔交易。
那么区块生产者会做什么呢？
区块生产者从他们的内存池中取出交易，将它们聚集在一起，生成一个区块。这是区块生产者的典型角色。
在 Avail 中，数据块和它们的承诺被类似地处理为个别交易。这些数据块+承诺组合在系统上传播，就像个别交易在传统链上发送一样。
很快，每个人都会拥有对这些数据块的承诺。有了这些承诺，提议者就可以开始随机抽样以确保数据的可用性。通过足够的抽样信心，节点将扩展这些承诺，接受正文中的数据，并构建区块头 —— 从而创建下一个区块。
结语
这些为 Avail 提出的架构方案旨在展示将数据可用性层与区块链的其他核心功能分离的重要性。
当数据可用性单独处理时，可以进行优化，将数据可用性作为一个独立的层来对待，这比将数据可用性与执行等其他区块链功能绑定在一起时能够带来更大的改进。
无论它们被称为第三层解决方案、模块化区块链还是链下扩展解决方案，我们很高兴看到团队们利用这个专门的数据可用性层所构想出的新奇想法。团队们可以放心，Avail 将能够直接与在其之上构建的任何链或应用同步扩展。随着我们构建一个包含数百个验证者、数千个轻客户端以及许多即将到来的新链的模块化区块链网络，我们预计在满足需求方面不会有任何问题。
",