选择合适的数据可用性层指南

首次发布于 2023 年 10 月 12 日，截至 2025 年 8 月 4 日最新更新。

选择合适的数据可用性层可能是一个困难、令人困惑且耗时的过程。有很多需要考虑，并且你希望确保做出正确的决定。在本指南中，我们剔除噪音，将 DA 层并排比较，以比较它们的功能和优势，并帮助你更轻松地做出决定。

无论你是在比较功能，还是专注于性能，我们都在这个并排比较中分解了 Avail, Celestia, EigenDA 和 Ethereum 的优势。

这个博客正在积极维护。要请求更新此帖子中的数值和/或引用，请通过 此主题 联系。

目录

• 性能
  • 数据吞吐量和可扩展性
  • 区块时间和轻客户端验证
• 主要特点
  • 数据可用性采样 (DAS)
  • 纠删码
  • 网络去中心化
  • 全节点依赖性
  • 证明机制
  • 共识机制

1. 性能

1.1 数据吞吐量和可扩展性

在本节中，我们比较当前的数据可用性吞吐量，并讨论每个 DA 随时间增加吞吐量的能力。

Avail DA

Avail 的当前吞吐量为 每个区块 4MB，这已在主网上线。Avail DA 支持可扩展的区块空间，从而能够随着对数据可用性容量的需求增加而增加吞吐量。基准测试已成功将吞吐量提高到 128MB/区块，是当前吞吐量的 32 倍，而不会牺牲网络活跃度或传播。

Celestia

Celestia 的当前吞吐量为 每个区块 8MB，已在主网上线。当前的实现有一个 硬编码限制，即每个区块 100MB，比今天的吞吐量水平提高 12.5 倍。Celestia 支持可扩展的区块空间，并已表示有未来实现 1GB 区块的雄心。

EigenDA

Eigen 已经发布了其软件的 V2 版本，该版本实现了每秒 100MB 的吞吐量。EigenDA 之所以能达到这个吞吐量水平，是因为它的架构。与本次比较中的其他解决方案不同，EigenDA 是一个数据可用性委员会（DAC），而不是一个公开验证的区块链。

DAC 移除了一些由更强大的、基于区块链的解决方案（如 Avail DA、Celestia 和 Ethereum）实施的验证要求。这使得像 EigenDA 这样的 DAC 能够达到更高的吞吐量，同时引入信任假设。这些将在 1.2、2.3、2.5 和 2.6 节中更详细地讨论。

EigenDA 可以提高吞吐量，但因为它不是区块链，所以可扩展的区块空间不适用。然而，它确实有 明确的目标 是将吞吐量提高到每秒 1GB。

Ethereum

在所有比较的 DA 提供商中，以太坊的数据吞吐量是最低的。这是有道理的，因为对新的数据可用性解决方案的需求源于扩展以太坊吞吐量的需要。

随着 proto-danksharding 和 Pectra 升级的上线，增加以太坊 DA 容量的下一个主要里程碑是 完整的 Danksharding。此升级会将每个区块的 blob 数量从 9 增加到 64，从而产生约 8.2MB/区块的吞吐量。预计此次升级距离实施仍有几年时间，最终目标 是在以太坊上达到 16MB/区块的吞吐量。

1.2 区块时间和轻客户端验证

虽然上一节探讨了 DA 吞吐量容量，但区块时间和通过轻客户端独立验证 DA 保证所需的时间也是决定使用哪种数据可用性解决方案时要考虑的重要因素。 这是因为一旦区块最终确定，并不一定意味着 DA 保证也最终确定。

DA 最终性保证决定了系统中最终确定的速度，因为其他应用程序或用户只有在 DA 最终性得到保证且不可逆转时才能有信心地前进。 从轻客户端验证 DA 保证所需的时间取决于 DA 层的实施方式，我们将在下面探讨。

Avail DA

Avail 的区块时间为 20 秒，区块在约 2 个区块或 40 秒内完成。 Avail DA 使用基于有效性证明的架构，该架构使 轻客户端 能够在区块完成时提供 DA 最终性。 这导致数据可用性验证时间约为 40 秒。 这比下一个最快的解决方案 Celestia 快约 15 倍。

Celestia

Celestia 在 6 秒内创建并最终确定区块。 Celestia 的实施使用基于欺诈证明的架构，这意味着区块最终确定时不会达到 DA 最终性。 相反，DA 最终性受挑战期的限制。 一旦此挑战期过去，并且没有提出有效的欺诈证明，Celestia 就可以提供 DA 最终性，这需要大约 10 分钟。

EigenDA

由于 EigenDA 并非基于其自身的区块链，因此本节中的值基于 EigenDA 智能合约在以太坊上最终确定的区块时间和结算时间。 由于 EigenDA 是 DAC，因此它无法让任何人公开验证数据实际上是否可用。 EigenDA 只能提供检查成员是否_同意_通过以太坊智能合约保持数据可用的能力。 这对于某些用例来说可能还可以，但可能导致资产丢失或冻结。

运行 EigenDA 软件的数据可用性委员会成员承诺代表网络保持数据可用。 当他们收到数据时，他们会签署一条消息，说明他们已存储该数据。 来自委员会成员的签名被收集在一起以创建证书，然后将其发送到以太坊。 该证书在约 15 分钟内最终确定。

EigenDA 仅依赖于经济保证，通过削减来惩罚不当行为。 本次比较中的其余 DA 提供商除了提供可公开验证的数据可用性保证外，还提供经济保证。

Ethereum

以太坊的平均区块时间为 12 秒，区块最终确定时间为 15 分钟。 虽然以太坊有轻客户端，但它还没有数据可用性采样。 DA 保证会在区块最终确定时在以太坊上最终确定，从而在大约 15 分钟内生成数据可用性保证。

2. 主要特点

2.1 数据可用性采样 (DAS)

数据可用性采样 是数据可用性解决方案提供的一项非常强大的功能。 它就像区块链中的一个窗口，可以从低功耗设备（例如用户的手机甚至浏览器中）检查和验证 DA 保证。 这种级别的最终用户验证使得构建一个网络成为可能，在该网络中，分布在世界各地的用户可以独立检查重建区块链所需的数据是否随时可用。

其工作方式是，系统将对随机数据块进行采样，检查数据是否可用，然后计算其余数据是否可用的置信度得分。 随着每个连续样本，DAS 使系统能够提高其置信度。 例如，在 Avail DA 上，可以在 8-30 个样本中实现接近 100% 的置信度。

Avail DA & Celestia

Avail 和 Celestia 都支持来自 轻客户端 的数据可用性采样，这些客户端足够小，几乎可以在任何地方运行。 这为最终用户提供了从手机上的应用程序中独立验证数据可用性的能力，而无需下载整个区块。

Avail DA 和 Celestia 还利用 DAS 来形成一个轻客户端的 P2P 网络，该网络有助于支持 更大的区块。 然而，Avail DA 是唯一能够从其 P2P 网络进行采样的 DA 层，从而增加了进一步的弹性。

Ethereum & EigenDA

以太坊的完整 Danksharding 路线图计划支持 DAS。 EigenDA 目前不支持 DAS，但 建议 将来可以支持它。

2.2 纠删码

纠删码是计算中广泛使用的保护数据的技术。 它通过复制数据，将其分成块，然后将这些块分散并存储在不同的位置，从而增加了数据的弹性。 这样，如果某个特定数据损坏，也没关系，因为有多个数据副本存储在不同的位置以重建整个数据集。 它也是帮助启用数据可用性采样的非常有用的组件。

具有 proto-danksharding 的以太坊不支持纠删码，但计划通过完整的 danksharding 支持它。

2.3 网络去中心化

你所需的去中心化程度可能取决于你的预期用例。 如果你希望保护数十亿美元的资金，那么网络去中心化将是一个非常高的优先级功能。 但是，如果你想跟踪用户在链上游戏中的移动，那么你可能不需要相同程度的去中心化。

比较不同网络的去中心化程度的一个非常有用的但不完整的指标是比较它们的 Nakamoto 系数。 Nakamoto 系数是可共同采取行动关闭区块链的最小数量的独立实体的度量。 总的来说，数字越高，网络越去中心化和强大。

Avail

Avail 区块链能够实现非常高的 Nakamoto 系数（总体排名第二）。 这是因为它使用提名权益证明 (NPoS)。 NPoS 有一个内置机制，可以自动保证权益在验证者之间均匀分布。 这避免了验证者中心化风险，使得任何人都难以控制网络。 NPoS 通过一种称为 Phragmén 选举算法 在验证者之间分配权益。 Avail 区块链目前已在主网上线，具有一个活动的 验证者集，预计将增长到 1,000，这将大大提高 Nakamoto 系数。 这是一个很棒的 可视化。

Celestia

Celestia 的区块链也提供良好的去中心化保证，但更容易出现验证者中心化风险，因为它采用委托权益证明 (DPoS) 系统。 委托权益证明的设计奖励权益越高的验证者更多的代币，从而导致权益集中和少数验证者节点的投票权。 在像 Celestia 这样更新兴的基于 DPoS 的区块链中，这种情况进一步加剧。 Celestia 目前有 100 个验证者，Nakamoto 系数为 6。

EigenDA

EigenDA 的去中心化特性很差。 在 EigenDA 的数据可用性委员会中，运营商组成一个受信任的委员会，他们承诺提供交易数据。 但是，最终用户和应用程序无法亲自独立验证这一点。 他们拥有的唯一保证是由削减风险形成的经济保证。 EigenDA 架构目前还具有一个中心化组件，该组件发挥着非常重要的作用，称为 disperser。

Ethereum

以太坊有超过 100 万个验证者。 然而，由于 ETH 质押者之间的中心化，它的 Nakamoto 系数非常低，这主要是由于像 Lido 和 Coinbase 这样的机构过度集中了质押份额。 虽然它总体上拥有最多的验证者，但网络的权益分配更加集中。

2.4 全节点依赖性

从历史上看，运行区块链全节点是独立验证区块链状态正确性的唯一方法。 这使得全球共识成为可能。 然而，随着时间的推移，并且区块链变得越来越大，任何人都可以简单地运行全节点变得越来越困难。

Avail DA & Celestia

Avail DA 和 Celestia 都对传统的轻客户端架构进行了重大改进，通过使轻客户端能够独立检查和验证数据是否可用。 这减少了对全节点作为真实来源的依赖，因为轻客户端可以验证数据是否可用。 运行轻客户端的计算要求非常低，这意味着用户可以在应用程序、笔记本电脑、手机或其他低功耗设备中验证 DA 保证。

Ethereum

以太坊对全节点的依赖性很高。 虽然以太坊中存在轻客户端，但它们完全依赖于全节点，因为它们无法在不依赖它们的情况下验证数据是否可用。

2.5 证明机制

证明用于有效地验证系统中数据是否可用。 这大大减少了生成数据可用性保证所需的资源。

有效性证明需要付出更多努力才能生成，但验证起来快速有效。 Avail DA、EigenDA 和 Ethereum 都使用 KZG 承诺 和有效性证明，但它们以不同的方式使用它们。

Avail

Avail 验证者在将新区块添加到 Avail 区块链时，会为每个区块生成一个 KZG 承诺。 这些 KZG 承诺可以由轻客户端通过数据可用性采样来验证，只要 DA 最终确定。 这是一种独特而强大的组合，尤其适用于 ZK rollup。 这是因为执行证明和 DA 证明都可以从手持设备上非常快速地验证，而无需挑战期。

Celestia

Celestia 是本次比较中唯一使用欺诈证明的数据可用性层。 这种方法采取了一种更乐观的观点，假设数据是有效和可用的，除非被欺诈证明证明不是这样。 Celestia 利用安全哈希函数，该函数比 KZG 承诺生成速度更快，但是需要经过挑战期才能向应用程序和用户提供数据可用性保证。

EigenDA

在 EigenDA 中，Disperser 收集数据 blob 并将它们发送到 Operator 节点。 Rollup 可以运行自己的 disperser 或使用 disperser 服务。 Disperser 目前是 Eigen 架构的 中心化组件。 Disperser 还生成一个 KZG 承诺，并将其与数据块一起发送到 Operator 节点。 当 Operator 节点从 disperser 接收到数据块时，它们会验证 KZG 承诺，然后再签名并将证明返回给数据可用性委员会。

Ethereum

在以太坊中，数据 blob 被提交，并生成一个关于提交数据的 KZG 承诺。 当需要检查数据是否可用时，EVM 会检查 KZG 承诺的 版本化哈希 以验证数据是否可用。 以太坊尚不支持数据可用性采样，但计划将其作为完整 Danksharding 路线图的一部分。 KZG 承诺在启用 DAS 方面起着关键作用。

2.6 共识机制

达成共识是使区块链能够继续运行并生成新区块的原因。 在共识机制设计方面，在实现活跃性和安全性之间存在一个基本的 决定。 活跃性确保交易不断得到处理且网络保持运行，而安全性确保交易准确且安全。

比较中的所有数据可用性层都使用不同的共识机制，但是我们将在下面讨论一些相似之处和不同之处。

Avail DA & Ethereum

虽然 Avail 和以太坊使用的共识机制不同，但它们确实有一些相似之处。 两者都将生成区块和最终确定区块的角色分开。

生成区块是维护活跃性的原因，并使交易能够继续进行。 最终确定区块是所有节点同意特定区块并将其提交到区块链的过程。

这种设计选择为网络增加了一些弹性，使其能够在验证者节点之间最终确定共识的同时继续运行。

Celestia

Celestia 使用 Tendermint 作为其共识协议，该协议具有单Slot最终性。 这意味着只要达成共识，区块就会立即最终确定，这通常需要大约 15 秒。 基于 Tendermint 的链的权衡是，当超过三分之一的运营商或验证者关闭时，它们可能会停止运行。

EigenDA

EigenDA 运营商共同组成一个受信任的数据可用性委员会，这是一组证明数据可用的节点。 最终用户和应用程序无法亲自独立验证这一点。

结论

我们希望本指南可以帮助你更轻松地决定选择哪个 DA 层。 如果你发现有机会改进或更新此帖子中的任何信息，请通过 此论坛 联系。

对比 Avail DA 数据可用性 可扩展性

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