相比之下，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 中获取有序交易并执行它们。它应该创建一个检查点/断言/证明并将其提交给数据验证层。我们称之为执行层。验证/争议解决：这部分代表系统锚定的主链。设计的安全性取决于该部分的稳健性和安全属性。执行层提交的检查点/断言/证明由该层处理，以保证系统中仅接受有效的状态转换（前提是数据可用）。我们将这部分称为数据验证层。 
Polygon