Avail 的扩展能力：我们目前的进展

这是三篇文章系列的第一篇，将讨论 Avail 目前的性能，以及它在短期和长期内的扩展能力。

Avail 测试网现已上线。随着用户开始将 Avail 整合到他们的链设计中，一个经常出现的问题是，“Avail 可以处理多少笔交易？” 我们已经发表了一些文章，概述了 Avail 在技术上是如何实现的。首先，我们将比较以太坊和 Avail 在当前架构下的吞吐量。

Avail vs Ethereum

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

在同一个区块中结合执行、结算和数据可用性是单体区块链架构的核心问题。Layer-2 (L2) rollups 通过允许在单独的链上处理执行，开始了模块化区块链的运动，这些区块专门用于执行。Avail 通过解耦数据可用性，并允许链上的区块专门用于数据可用性，从而使模块化设计更进一步。

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

更重要的是，Avail 可以始终如一地将区块填满到存储限制，并根据需要增加大小。我们可以利用许多手段——许多手段可以很快实现——在需要时将这个数字提高到每个区块 500,000 笔交易以上（每秒 25,000 笔交易）。

我们可以提高吞吐量吗？

为了提高吞吐量（特别是每秒交易数），链架构师要么需要增加区块大小，要么需要减少区块时间。

为了添加到链中，每个区块必须生成 commitments，构建 proofs，传播它们，并让所有其他节点验证这些 proofs。这些步骤总是需要时间的，并且对区块时间有一定的限制。

因此，我们不能简单地将区块时间减少到一秒左右。将没有足够的时间来生成 commitments，生成 proofs，并将这些信息传播给整个网络中的所有参与者。在理论上的 1 秒区块时间下，即使每个网络参与者都运行最强大的机器，可以瞬间生成 commitments 和 proofs，瓶颈仍然是数据的传播。由于互联网速度的限制，网络无法足够快地将区块传达给所有完整节点。因此，我们必须确保区块时间足够长，以便在达成共识后，允许数据在网络上传播。

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

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

首先，让我们看看向链中添加一个区块需要什么。向链中添加每个区块需要三个主要步骤：生成区块的时间、传播区块的时间和验证区块的时间。

1. 区块生产

此步骤包括收集和排序 Avail 交易、构建 commitments 和扩展（纠删码）数据矩阵所需的时间。

区块生产衡量了生成一个区块所需的时间，因为它总是需要一些时间。因此，我们不仅必须考虑最佳情况下的时间，还必须考虑不同机器的平均情况和最坏情况下的时间。

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

2. 传播延迟

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

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

例如，如果我们将 Avail 增加到支持 128 MB 的区块，计算可能会扩展（约 7 秒）。然而，瓶颈就变成了在网络上发送和下载这些区块所需的时间。

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

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

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

3. 区块验证

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

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

相反，吞吐量的提高将来自于了解向 Avail 链中添加一个区块需要哪些步骤，以及哪些步骤可以优化。

目前，使用 Avail 的验证者会获取整个区块，并重现提议者生成的所有 commitments，以验证该区块。这意味着区块生产者和所有验证者都执行上述图形中的每个步骤。

每个验证者重新创建整个区块是单体区块链中的默认设置。然而，这在像 Avail 这样的链上是不必要的，因为交易不被执行。因此，我们可以优化 Avail 的一种方法是允许验证者通过抽样而不是区块重现来达到他们自己对数据可用性的保证。这使得验证者所需的资源低于要求他们重现所有 commitments 的情况。更多内容将在以后的文章中介绍。

探索数据可用性抽样如何工作

在 Avail 中，轻客户端使用三个核心工具来确认数据可用性：samples、commitments 和 proofs。

1. Samples 目前由轻客户端执行，包括它们向 Avail 网络请求特定单元格的值，以及该单元格的相关有效性证明。他们采集的 samples 越多，他们就越有信心所有数据都是可用的。
2. Commitments 由区块提议者生成，并总结 Avail 区块中整行的数据。（提示：这是我们将在本系列的后面部分中优化的步骤。）
3. Proofs 是为网络中的每个单元格生成的。Proofs 与 commitment 结合使用，由轻客户端验证提供给轻客户端的单元格的值确实是正确的。

使用这些工具，轻客户端然后执行三个步骤。

1. 决定： 所需的可用性置信度决定了轻客户端执行多少 samples。他们不需要很多 samples（8-30 个 samples）就能达到高于 99.95% 的可用性保证。
2. 下载： 轻客户端然后请求这些 samples 以及它们相关的 proofs，并从网络（从完整节点或其他轻客户端）下载它们。
3. 验证： 然后他们查看区块头中的 commitment（轻客户端始终可以访问），并根据 commitment 验证每个单元格的 proof。

仅凭这些，轻客户端就能够确认区块中所有数据的可用性，而无需下载超过区块的一小部分。轻客户端执行的其他步骤有助于提高 Avail 的安全性，但未在此处列出。例如，如果轻客户端需要，它们能够与其他轻客户端共享它们下载的 samples 和 proofs。但这就是轻客户端确认数据可用性的过程！

在本系列的第二部分中，我们将探讨在短期内提高 Avail 吞吐量的方法。我们将解释为什么我们有信心 Avail 能够增长以满足未来一年中任何网络的需求，以及我们如何改进网络以适应未来几年。

Avail 测试网已经上线，更新版本正在路上。随着 Avail 朝着主网努力，我们有兴趣与任何希望在其链上实施数据可用性解决方案的团队合作。如果你想了解更多关于 Avail 的信息，或者只是想直接向我们提问，我们很乐意听到你的消息。查看 我们的存储库，加入 我们的 Discord 服务器。

本文最初发表在 Polygon 的官方博客上。

开发者 Avail DA 可扩展性 区块链可扩展性 KZG 模块化区块链

• 原文链接： blog.availproject.org/av...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～