Avail 的扩展能力:接下来我们可以改进什么

本文是关于 Avail 如何通过增加区块大小来实现扩展性的系列文章的第二篇,探讨了增加区块大小对承诺生成、证明生成和验证的影响,并给出了实验结果。文章还讨论了 Avail 的设计如何保证低交易价格,以及验证者在网络增长中的激励机制。

Avail 主网现在已经上线。当用户开始将 Avail 纳入他们的链设计时,经常出现一个问题:“Avail 可以处理多少交易?” 这是三部分系列文章的第二篇,将讨论 Avail 当前的性能,以及它在短期和长期内的扩展能力。你可以在这里阅读第一部分。

在本系列的第一部分中,我们探讨了 Avail 目前的运作方式。在第 2 部分中,我们将明确我们可以相当快地扩展(通过增加区块大小)。我们将准确地了解如何以及为什么这是可能的。我们将介绍一些概念,这些概念将使我们能够将 Avail 扩展到简单的区块大小增加之外。并且我们将准确地介绍在 Avail 区块生产和验证过程中,哪些干预措施将用于提高吞吐量。

那么,让我们来探索扩展 Avail 最直接的方法:增加区块大小。

当前的实验结果

当我们尝试 Avail 的不同区块大小时,我们了解到 Avail 数据矩阵中的行和列必须区别对待。

在 Avail 区块中:

  • 行数 = 要构建的多项式承诺的数量
  • 列数 = 多项式的阶数(构建每个单独承诺的复杂程度)

在轻客户端可以达到数据可用性保证之前,必须完成以下三件事:

  1. 必须构建承诺 - 正如本系列第一部分中提到的,承诺由区块生产者生成,并且使用 Avail 矩阵中的整行数据构建。
  2. 必须生成证明 - 证明是为 Avail 数据矩阵中的每个单元格生成的。虽然生成单个证明很快,但我们必须意识到添加更多行和列对需要生成的证明数量的影响。
  3. 需要验证证明 - 在 Avail 当前的模型中,轻客户端下载单元格的值、单元格的证明,并将它们与该单元格行的承诺中包含的信息进行比较,以验证他们下载的是否是匹配的数据。

问题是,构建承诺所需的时间与处理证明所需的时间之间存在恒定的权衡。随着 Avail 区块大小的增加,这一点变得尤为突出。

增加 Avail 的区块大小

增加 Avail 区块大小时的主要矛盾可以描述为承诺生成(由验证者执行)与证明生成和验证(分别由完整节点和轻客户端执行)。

区块数据矩阵中包含的行越多,区块生成时间就越长。这是因为更多的行意味着生产者必须创建更多的承诺(将承诺视为更高级的状态根)。

相反,列越多,构建和验证证明所需的时间就越长,因为我们处理的是更高阶的多项式。有关支持 Avail 架构的 KZG 多项式承诺方案的内部运作的更多详细信息,Dankrad Feist 的这篇文章分享了更多信息。

例如,目前 Avail 有一个 256x256 的矩阵(~65K 个单元格)。为了使区块大小加倍,我们可以:

  • 将列数加倍,使其变为 256x512
  • 将行数加倍,使其变为 512x256
  • 中间的其他一些比例

区块大小加倍应始终产生约 131K 个单元格,是现在 65K 的两倍。

考虑到这一点,我们可以把 Avail 区块的大小从目前的 2 MB 增加到 32 MB。在不久的将来,这是完全可以实现的。例如,一个 1024x1024 (32 MB) 的 Avail 区块需要 4 秒来生成承诺,4 毫秒来构建证明,以及 620 毫秒来验证证明。这些数字表明,一个 32 MB 的区块可以在当前 20 秒的区块限制内生成承诺,构建所有证明并进行验证。

而且,还有足够的计算空间可以将区块大小增加到 32 MB 以上。一个尺寸为 64x65,536 的 128 MB Avail 区块需要 7.25 秒来生成承诺,174 毫秒来构建证明,以及 55 毫秒来验证证明。

这为我们提供了一个现实的计算限制,即生产者生成承诺以及完整节点在 20 秒内生成单元格证明可以完成什么。

然而,当区块大小约为 128 MB 时,整个网络开始遇到带宽限制。以典型的互联网速度传播那么大的区块开始带来真正的挑战。这是所有数据可用性层都将面临的常见扩展瓶颈。

下面的数字显示了我们对区块大小为 2 MB、32 MB 和 128 MB 且行与列比率不同的实验结果。你可以在此处找到更多我们的结果

Avail 的设计如何保证低价格

在本系列文章中,我们一直专注于我们可以实施的技术方法,以使 Avail 网络能够每秒处理越来越多的交易。在任何基于区块链的系统中,同样重要的是要考虑扩展的激励措施

随着网络的增长,验证者将承担扩展的成本。如果 Avail 变得足够去中心化,验证者将拥有独立于 Avail 的自身利益。

请放心,随着 Avail 去中心化和增长,验证者将有动力保持价格低廉。随着每个吞吐量限制的达到,增长使得通过寻租验证者提高 gas 费成为可能。

然而,Avail 的设计促进了交易吞吐量的持续增长(以及交易成本的可承受性),即使在完全去中心化的系统中也是如此。

如果在增加区块大小的同时保持每次交易的成本不变,验证者最终有机会赚取更多的钱。验证者可以访问越来越大的用户池。我们不必像处理执行的区块链那样限制 Avail 可以支持的用户数量。计算约束不再是增长的限制因素。这意味着只要价格保持低廉,交易总数就会继续增加。

随着网络的增长,验证者能够捕获价值,验证者还可以利用规模经济。

因此,我们使用 Avail 创建的“市场”是可以为验证者网络提供持续增长,同时为用户提供持续低成本的交易。


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

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

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

  • 原文链接: blog.availproject.org/av...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
Avail Project
Avail Project
Build with Avail DA, the validity proven data availability layer unifying Web3