Polygon 的新版 Avail 测试网现已上线

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

这是介绍 Polygon Avail 当前性能及其近期和长期扩展能力的系列文章中的第一篇。我们已经发布了一些文章，概述了 Avail 在技术上是如何实现的。首先，我们将比较 Ethereum 和 Avail 的吞吐量，考虑到两条链的当前架构。

Polygon Avail 对比以太坊

以太坊区块最多可容纳 1.875 MB，区块时间约为 13 秒。然而，以太坊区块通常不会被填满。几乎每个区块都会在达到数据限制之前达到气体限制，因为执行和结算都需要消耗气体。因此，每个块存储的数据量是可变的。

需要在同一个区块中结合执行、结算和数据可用性是单体区块链架构的核心问题。第 2 层 (L2) 汇总通过允许在单独的链上处理执行来启动模块化区块链运动，块专门用于执行。 Polygon Avail 还通过解耦数据可用性，并允许使用专门用于数据可用性的块的链，使模块化设计更进一步。

目前，Avail 的区块时间为 20 秒，每个区块能够容纳大约 2 MB 的数据。假设平均交易大小为 250 字节，那么今天每个 Polygon Avail 区块可以容纳大约 8,400 笔交易（每秒 420 笔交易）。

更重要的是，Avail 可以始终如一地填充块直到达到存储限制，并根据需要增加大小。我们可以拉动许多杠杆——很多都非常快——以便在需要时使每个区块的交易数量超过 500,000 笔交易（每秒 25,000 笔交易）。

我们可以增加吞吐量吗？

为了增加吞吐量（具体来说，每秒交易数），链架构师要么需要增加块大小，要么减少块时间。

要添加到链中，每个块必须产生承诺、构建证明、传播它们，并让所有其他节点验证证明。这些步骤总是需要时间，并且会限制出块时间。

因此，我们不能仅仅将出块时间减少到一秒左右。几乎没有足够的时间来产生承诺、产生证明并将这些部分传播给整个网络中的所有参与者。在理论上一秒的出块时间，即使每个网络参与者都运行最强大的机器，可以立即产生承诺和证明，瓶颈还是数据的传播。由于互联网速度限制，网络无法足够快地将块传送到所有完整节点。因此，我们必须确保出块时间足够长，以允许在达成共识后通过网络分发数据。

相反，增加吞吐量将通过增加块大小来实现——增加我们可以包含在每个块中的数据量。

当前架构：向链中添加一个块

首先，让我们看一下将区块添加到链中需要什么。将每个区块添加到链中需要三个主要步骤。生成一个块、传播该块并验证该块所花费的时间。

1. 出块

此步骤包括收集和订购 Avail 交易、建立承诺和扩展（纠删码）数据矩阵所需的时间。

块生产测量生产块所需的时间，因为它总是至少需要一些时间。因此，我们不仅要考虑最佳情况时间，还要考虑不同机器的平均和最坏情况时间。

能够参与新区块生产的最弱机器是在平均情况下容量达到最大值的机器。所有较慢的机器都不可避免地会落后，因为它们无法赶上更快的机器。

2.传播延迟

传播延迟衡量的是将区块从生产者传播到验证者和点对点网络所需的时间。

目前，Avail 有 2 MB 的块。这种大小的块可以在当前的 20 秒块时间限制内传播。较大的块大小使传播更加棘手。

例如，如果我们要增加 Polygon Avail 以支持 128 MB 块，则计算可能能够扩展（~7 秒）。然而，瓶颈就变成了通过网络发送和下载这些块所花费的时间。

在 5 秒内通过对等网络在全球范围内发送 128 MB 的块可能是目前可以完成的极限。

128 MB 的限制与数据可用性或我们的承诺方案无关，而是通信带宽限制的问题。

这种考虑传播延迟的需要为我们提供了我们当前的 Polygon Avail 理论块大小限制。

3.区块验证

一旦传播，参与的验证者就不会简单地信任区块提议者提供给他们的区块——他们需要验证产生的区块是否确实有数据生产者所说的。

这三个步骤彼此之间存在一些紧张关系。我们可以让所有验证者强大的机器通过同一个数据中心的优秀网络紧密连接——这将减少生产和验证时间，并让我们传播更多的数据。但是因为我们还想要一个分散的、多样化的网络，有不同类型的参与者，所以这不是一个理想的方法。

相反，通过了解将块添加到 Avail 链需要哪些步骤以及可以优化哪些步骤，可以提高吞吐量。

目前，使用 Polygon Avail 的验证者获取整个区块并复制提议者生成的所有承诺，以验证区块。这意味着块生产者和所有验证者都执行上图中的每个步骤。

每个验证者对整个区块的重新创建是整体区块链中的默认设置。但是，在像 Avail 这样不执行交易的链上就没有必要了。因此，我们可以优化 Avail 的一种方法是允许验证者通过采样来达到他们自己的数据可用性保证，而不是重新创建块。与要求验证器重现所有承诺相比，这对验证器的资源要求更低。