Polygon Avail 的未来扩展能力-第三章lg...

Polygon Avail 测试网目前已经上线。当用户开始将 Avail 纳入他们的链设计中时，经常出现的一个问题是，“Avail 可以处理多少交易？“

这是Avail系列文章中的最后一篇，在这篇文章当中，我们将讨论 Polygon Avail 当前的性能，以及它在短期和长期的扩展能力。

下面的模型描述了一种架构，其中提议和创建区块的行为（决定将哪些事务/blob 包含在块中）是由不同的参与者分开执行的。

通过创建这个新的工作群体，生成每行承诺和生成单元证明所需的计算工作可以在不同的参与者之间进行分配。

Avail 完成了一件很核心的工作：它接收杂乱的数据，然后输出有序的数据。把它想象成一个 API。Avail 使任何人都可以对数据可用性进行采样。

在强调我们可以改进的地方之前，我们先来阐述一下 Avail 在当前状态下向区块提议者和验证者/完整节点提出的具体要求。 

1. 区块生产者创建区块体

• 累积交易（数据提交）

• 将这些交易排序到 Avail 数据矩阵中，该矩阵成为区块体

2. 区块生产者创建区块头

• 为矩阵的每一行生成承诺

• 使用多项式插值扩展这些承诺（生成+扩展的承诺成为区块头）

3. 区块生产者传递区块（区块体 + 区块头）

4. 验证者和全节点接收区块

5. 验证者和全节点解码、重构和验证块

• 重新创建数据矩阵

• 重新创建承诺

• 延长承诺

• 验证他们收到的所有数据是否与他们生成的承诺相匹配

在像 Avail 这样的系统中，要求全节点重新生成区块头的步骤 5 是不必要的。

全节点目前这样做只是因为 Avail 继承了传统区块链的架构，传统区块链需要验证者来确认执行是否正确。Avail 不处理执行。区块提议者、验证者和 light clients 轻节点都只需要操心可用性。这意味着 Polygon Avail 网络中的所有参与者都可以选择使用数据可用性采样来无需信任地确认数据可用性。

因为验证者和全节点可以抽样检查可用性，他们不需要重新创建整个块来保证网络安全。

验证者不需要通过重做生产者所做的所有事情来检查一切是否正确。相反，他们可以通过几次抽样来检查一切是否正确。就像 light clients 一样，当统计数据满足可用性时（在检查 8 到 30 个样本之后），验证者就可以将该块添加到链中。由于 Avail 不处理数据执行，因此可以安全地执行此操作。

与费力的一对一验证过程相比，数据抽样为验证者提供了更快的选择。Polygon Avail 的神奇之处在于，通过单独使用区块头，任何人（在本例中为验证者）都可以达成共识用同一条正确的链。

如果我们能做到这一点，我们就可以用几次采样来替换整个区块头创建步骤。

我们对验证者的要求的这种转变，以及一些其他的改进是本文将要探讨的内容。我们将描述一个改进的系统，其中区块提议者（仍然）创建和传播区块，但所有其他网络参与者通过数据可用性采样与网络交互。然后，我们将介绍一个更进一步的系统，该系统将区块构建和区块提议分开，以便由两组不同的网络参与者进行。

需要注意的是，这些变化在某种程度上更加先进，并且仍在积极研究中。

对于 Avail 来说，一个更有效的模型是由一个节点建立承诺并传播到网络。然后，所有其他参与者将生成并验证证明。

这是第一次我们不仅让 ligth client 做到这一点，而是让一个链的任何部分都能做到这一点。我们允许验证者用与 light client 相同的方式进行采样。

这个模型有一个单一的验证者节点，它为数据矩阵的所有行进行区块创建的承诺，然后只提议区块头。

第一步：提议者只传播区块头

第二步：因为验证者只接收到区块头，所以他们无法解码或重建区块。但是因为他们可以执行数据可用性抽样，所以他们并不需要（解码或重建区块）。

此场景中的其他验证者的行为类似于轻节点 light client

其他验证者将对这些承诺进行数据可用性抽样，并且仅在达到可用性保证时才接受区块。

在这个世界中，所有节点的行为都类似于 light client。验证者可以不用为了确保区块生产者进行正确的计算而使用区块体来重新生成承诺。

当验证者可以简单地依赖证明验证时，生成承诺来证明计算就不必要了。

仅使用区块头来选择正确的链对于全节点来说当然也是可能的，因为我们不需要完整节点来验证区块的有效执行；Avail 不进行执行！我们只需要可用性证明，而这一证明区块头（结合一些随机样本）就可以提供。这使我们能够减少成为验证者所需的计算量。

这还有一个好处，就是有可能降低计算时间。

一些问题

我们对在短期内采用这种模式有些犹豫，因为它需要脱离 Substrate 的基本结构。我们需要删除外部根，这会破坏对 Substrate 工具的所有访问权限，尽管这是我们正在积极探索的一项改进。

另一个模型从 EIP-4844 借用了 shard blob 模型。

对于这个系统，想象一下：

1. 区块数据矩阵的每一行都由不同的构建者结合该行的相关多项式承诺构建。

• 构建者与 p2p 网络共享他们的行以及他们对提议者的承诺。

2. 区块头创建：单一区块的提议者收集承诺。

• 提议者从构建者（和p2p网络）中取样，以确认给定的承诺产生有效的开口，然后对承诺进行擦除编码。这个原始承诺+扩展承诺的组合成为区块头。

3. 提议者与验证者共享此区块头。

4. 提议者和验证者通过从 p2p 网络（或构建者）中随机抽样来执行数据可用性抽样检查，并确认数据生     成一个与每个单元的行承诺对应的有效开口。

5. 一旦验证者达到统计学上的可用性保证，区块头就会被添加到链上。

   区块提议者不需要做很多工作，因为承诺是由许多参与者共同产生的。

惰性的提议者模型则是有一个区块的单一提议者。然后，执行者可以以类似于上述的提议者-构建者分离的方式进行。

也可以有多个构建者来各自创建区块的一小部分。他们都把这些部分块发送到一个实体（提议者），该实体对每个区块进行随机抽样，以建立它所提议的区块头。

区块体是用逻辑结构构建的。

实例

惰性提议者模型的特别之处在于区块构建者和区块提议者是分开的。

假设四个块构建者各有数据矩阵的一行，每个构建者使用该行创建一个承诺。

然后，每个构建者将他们的行和构造的承诺发送给指定的提议者，后者从区块体中采样数据以认证承诺。提议者然后对承诺执行多项式插值，以便它们不仅具有四个最初构建的承诺，而是有八个承诺。数据矩阵现在已被删码和扩展。

这八行和八个承诺由同一个提议者验证。 

在查看整个矩阵时，我们可以看到一半的行是由提议者构建的（通过纠删码），另一半是提供给他们的。 

然后，生产者提出一个区块头，而每个人都接受了。这导致区块看起来与 Avail 测试网当前生成的区块相同，尽管它们的构建效率更高。

Avail 的惰性提议者模型效率更高，但也相当复杂。虽然还有其他容易实现的机会来优化整个系统，但 Avail 团队很希望探索实施目前这种模型。

传统的区块链Txns和惰性提议者模式的比较

惰性提议者模型与当今处理非 Avail 区块链上的单个区块链交易的方式没有什么不同。

今天，当任何人在几乎任何一条链上进行交易时，他们都会向所有节点发送该交易的记录。很快，每个节点的内存池中都会有这个交易。

那么区块生产者是做什么的呢？

区块生产者从他们的内存池中获取交易，将它们整理在一起，并产生一个区块。这是区块生产者的典型角色。

在 Avail 中，对于数据 blob 及其承诺的处理方式与单个交易类似。这些 blob+承诺的组合在系统上传播，就像在传统链上发送单个交易的方式一样。

很快，每个人都会对 blob 做出承诺。通过承诺，提议者可以开始随机抽样以确保数据可用性。有了足够的抽样置信度，节点将扩展这些承诺，接受区块体中的数据，并构造区块头——从而创建下一个区块。

最后

Avail 的这些架构建议旨在展示将数据可用性层从区块链的其他核心功能中分离出来有多大影响。

当数据可用性被单独处理时，可以进行优化，将数据可用性视为一个独立层，提供远远大于数据可用性与其他区块链功能（如执行）绑定时的改进。

无论它们被称为 Layer3 解决方案、模块化区块链，还是链外扩展解决方案，我们都很高兴看到团队利用这个专用的数据可用性层的想法。团队很有信心，Avail 将有能力直接与任何链或建立在其上的应用程序一起扩展。随着我们建立起一个由100多个验证者、数千个 light client 以及许多新链组成的模块化区块链网络，我们预计在扩展方面不会出现问题，以满足需求。

Avail 测试网已经上线，并且更新版本即将推出。随着 Polygon 致力于 Avail 主网发布，我们有兴趣与任何希望在其链上实施数据可用性解决方案的团队合作。

来源：金色财经