Polygon Avail

Avail——未来区块链如何运作的全新方式的重要组成部分。Avail 是一个通用的、可扩展的、以数据可用性为中心的区块链，适用于独立链、侧链和链外扩展解决方案。

Avail 通过使用极其安全的数学原语提供了一个强大的数据可用性层——使用具有关键创新的纠删码进行数据可用性检查——我们使用 Kate 多项式承诺来创建一个二维数据可用性方案，避免欺诈证明，不需要诚实的多数假设，并且不依赖诚实的全节点来获得数据可用的信心。

Avail 提供了一个通用的数据可用性层，可供不同的执行环境使用，例如独立链、侧链和链下扩展解决方案。从长远来看，它将支持在执行环境方面和最终实施方面的各种实验，而无需团队和项目自行启动自己的安全性。使用 Polygon SDK、Cosmos SDK 或 Substrate 创建的链可以受益于为此目的使用 Avail。

Avail 将交易执行和有效性与共识层解耦，因此共识只负责 a) 对交易进行排序和 b) 保证其数据可用性。

主要目标

· 启用具有任意执行环境的独立链或侧链，以通过保证交易数据可用性来引导验证器安全性，而无需创建和管理自己的验证器集

· Validiums 等二层（Layer 2）解决方案通过将 Avail 用作链下数据可用性层来提供更高的可扩展性吞吐量

自 2020 年底以来，我们一直在秘密研究 Avail，目前，它处于 Devnet 阶段。测试网正在开发中。可以在参考文档中找到有关问题、架构和解决方案的更多详细信息，包括对代码库的引用。

背景

在当今类似以太坊的生态系统中，主要有三种类型的节点：

· 验证节点

· 全节点

· 轻客户端

一个区块由验证器节点附加到区块链，该节点从内存池收集交易，执行它们，在通过网络传播之前生成区块。该区块包含一个小区块头，其中包含与该区块中包含的交易相关的摘要和元数据。整个网络的全节点接收该区块并通过重新执行该区块中包含的交易来验证其正确性。轻客户端仅根据需要从相邻的全节点获取区块头和交易细节。区块头中的元数据使轻客户端能够验证接收到的交易细节的真实性。

虽然这种架构非常安全并已被广泛采用，但它有一些严重的实际限制。由于轻客户端不会下载整个区块，因此它们可能会被诱骗接受底层数据不可用的区块。区块生产者可能会在一个区块中包含恶意交易，而不会将其全部内容透露给网络。这被称为数据可用性问题，对轻客户端构成严重威胁。更糟糕的是，数据不可用是一种不可归因的故障，这使我们无法添加欺诈证明结构，该结构允许全节点以令人信服的方式通知轻客户端丢失数据。

现有区块链对比Polygon Avail

相比之下，Avail 采取了不同的方法来解决这个问题——它不是验证应用程序状态，而是专注于确保发布的交易数据的可用性，并确保交易排序。只有当该区块背后的数据可用时，具有共识的区块才被认为是有效的。这是为了防止区块生产者在不释放区块头背后的数据的情况下释放区块头，这将阻止客户端读取计算其应用程序状态所需的交易。

Avail 将区块验证的问题简化为数据可用性验证，这可以使用数据可用性检查以恒定成本高效完成。数据可用性检查利用纠删码，在数据冗余设计中大量使用。

数据可用性检查要求每个轻客户端从链中的每个区块中采样非常少量的随机区块。一组轻客户端可以以这种方式对整个区块链进行集体采样。一个很好的思维模型是像 Torrent 这样的 p2p 文件共享系统这样的系统，其中不同的节点通常只存储文件的某些部分。

请注意，这些技术将在 Ethereum 2.0 和 Celestia（以前称为 LazyLedger）等系统中大量使用。

这也导致了一个有趣的结果：网络中存在的非共识节点越多，您可以安全地拥有的区块大小（以及吞吐量）就越大。这是一个有用的属性，因为它意味着非共识节点也可以为网络的吞吐量和安全性做出贡献。

KZG 基于承诺的方案

在 Avail 使用的基于 KZG 承诺的方案中，主要有三个特点：

· 数据冗余使出块者很难隐藏区块的任何部分。

· 无欺诈保证正确纠删码

· 向量承诺，允许全节点使用简洁的证明说服轻节点包含交易。

简单来说，一个区块中的整个数据被排列成一个二维矩阵。通过对矩阵的每一列进行擦除编码以将原始列的大小加倍来引入数据冗余。Kate 承诺用于提交每一行，并且承诺包含在区块头中。该方案可以轻松捕获数据隐藏尝试，因为任何只能访问区块头的轻客户端都可以查询矩阵的随机单元格并获得可以根据区块头检查的简短证明（多亏 Kate 承诺）。数据冗余迫使区块生产者隐藏区块的大部分，即使它只想隐藏单个交易，使其容易被随机抽样捕获。我们避免了欺诈证明的需要，因为 Kate 承诺的约束性使得区块生产者构建错误的承诺而不被抓住在计算上是非常不可行的。此外，可以使用 KZG 承诺方案的同态属性计算扩展行的承诺。

KZG 承诺方案

尽管我们在这里提到了 Avail 构造的主要功能，但还有其他功能，例如部分数据获取和协作可用性保证。我们在这里省略了细节，并将在后续文章中重新讨论它们。

现在可能是举个例子并演练实际用例的好时机。假设一个新的应用程序想要托管一个特定于应用程序的独立链。它使用 Polygon SDK 或任何其他类似框架（如 Cosmos SDK 或 Substrate）启动新的 PoS 链，并将业务逻辑嵌入其中。但它面临着通过验证者质押获得足够安全性的引导问题。

为了避免这种情况，它使用 Avail 进行交易排序和数据可用性。应用程序用户向 Polygon SDK 链提交交易，这些交易会自动转发到 Avail，并在那里自行维护订单。有序的事务由一个（或多个）操作员拾取，并根据业务逻辑构建最终的应用程序状态。应用程序用户可以放心，有序数据是可用的，并且可以自己在任何时候重建应用程序状态，使他们能够使用由 Avail 提供的强大安全保证的链。

虽然上面的例子讨论了一个使用 Avail 来保证安全的新独立链，但该平台是通用的，任何现有的链也可以使用它来确保数据可用性。在下一节中，我们将简要提及 Avail 如何帮助现有汇总扩展以太坊。

关于以太坊链下扩展解决方案数据可用性的说明

已经提出了各种各样的以太坊 Layer 2 解决方案，例如 Optimistic Rollup、ZK Rollup 和 Validiums。这些解决方案将执行移到链下，同时确保应用程序验证和数据在链上的可用性。虽然基于链下执行的架构提高了吞吐量，但它仍然受到像以太坊这样的主链可以处理的数据量的限制。这是因为虽然执行是链下的，但验证或争议解决是严格在链上进行的。交易数据在以太坊上作为 calldata 提交，以确保数据可用于未来的重建。这是极其重要的。

在 Optimistic Rollup 的情况下，操作者可能会提交无效交易，然后向整个区块链压制部分区块。这样，系统中的其他全节点将无法验证提交的断言是否正确。由于缺乏数据，他们将无法产生任何欺诈证明/挑战来证明该断言确实无效。

在基于零知识的 Rollup 的情况下，ZKP 稳健性确保接受的交易是有效的。然而，即使有这样的保证，不透露支持交易的数据也会产生严重的副作用。

这可能会导致其他验证者无法计算系统的当前状态，以及用户被排除在系统之外并且他们的余额被冻结，因为他们没有访问该余额所需的信息（见证人）。

我们认识到，为了实现更高的吞吐量，我们不仅需要将执行置于链下，还需要有一个可扩展的数据托管层来保证数据可用性。

这种区块链设计需要解决以下部分：

· 数据托管和排序：这部分将接收事务数据并对其进行排序，无需任何执行。然后它将存储数据并以分散的方式确保完整的数据可用性。这是 Avail 的关键。

· 执行：执行组件应该从 Avail 中获取有序交易并执行它们。它应该创建一个检查点/断言/证明并将其提交给数据验证层。我们称之为执行层。

· 验证/争议解决：这部分代表系统锚定的主链。设计的安全性取决于该部分的稳健性和安全属性。执行层提交的检查点/断言/证明由该层处理，以保证系统中仅接受有效的状态转换（前提是数据可用）。我们将这部分称为数据验证层。