选择合适的数据可用性层 - 深入分析Celestia、Polygon Avail和EigenDA

简要概括

• 数据可用性（DA）确保任何人都能够检索验证区块链或 rollup 所需的必要信息（交易）。
• 将所有 rollup 数据发布在以太坊上是安全的，但成本非常高，并且受到以太坊吞吐量的限制。
• Celestia、Polygon Avail 和 EigenDA 各自以不同的方式处理链下数据可用性，在信任、吞吐量、最终性和成本之间权衡。
• 通过了解每种解决方案的工作原理（以及它如何将证明锚定到以太坊），你可以为你的 rollup 或 L2 项目选择最佳的 DA 层。

背景：为什么数据可用性重要

Rollup 压缩交易，并且必须将交易数据发布到某个地方，以便需要时任何人都可以重建它（用于欺诈证明、验证等）。传统上，这些数据作为 calldata 发布在以太坊上——信任最小化但成本极高。数据可用性（DA）层旨在以更低成本存储 rollup 数据，同时保留任何诚实方检索数据的能力。每个 DA 解决方案——Celestia、Polygon Avail、EigenDA——以不同的方式平衡成本、吞吐量、信任假设和最终性。

快速对比表

以下是 Celestia、Polygon Avail 和 EigenDA 在一些关键指标上的简要对比：

Celestia

Celestia 是一个模块化区块链（基于 Cosmos SDK/Tendermint 构建），专门用于排序交易并确保数据可用性，但不执行这些交易。

完整的数据可用性流程

sequenceDiagram
    participant R as Rollup Sequencer (DA User)
    participant V as Celestia Validator (Block Producer)
    participant F as Celestia Full Node (Validator/Bridge Node)
    participant L as Celestia Light Node
    %% Data Submission
    R ->> V: Submit transaction blob (rollup data)
    V ->> V: Erasure-code blob into 2D matrix (Reed-Solomon coding) 
    V ->> V: Compute Namespaced Merkle roots for each row/column, derive block data root 
    V ->> V: Include data root in block header and sign block (attests data availability)
    V -->> F: Broadcast block data (shares) and header to all full nodes
    Note over V,F: Full nodes receive all shares. Validators finalize block after getting data (ensuring availability).
    %% Sampling and Verification
    L ->> F: Request random data share *i* with its Merkle proof 
    F -->> L: Return share *i* and Merkle proof (against data root)
    L ->> L: Verify share *i* against block's data root (Merkle proof matches) 
    alt Additional Samples
        L ->> F: Repeat for other random shares (sampling multiple pieces)
        F -->> L: Provide requested shares with proofs
        L ->> L: All samples verified (high probability data is fully available) 
    end
    L ->> L: Mark block as Available (no missing shares detected)
    L ->> Network: Gossip received shares to help reconstruct full data 
    Note over L,F: If any sample fails (missing/invalid share), availability is suspect, fraud proof can be initiated.

图表解释：

• 纠删码和 NMT：Celestia 验证者将数据编码为多个份额，并将它们提交到命名空间 Merkle 树中。值得注意的是，Celestia 将数据排列在 2D 矩阵中，并包括行和列的根。
• 轻节点随机抽样份额。如果它们能够检索到有效份额，它们会假设（高概率）整个区块是可用的。
• 欺诈证明：如果任何份额缺失，可以提出欺诈证明以罚没或惩罚提议者。

由于这种乐观方法，Celestia 的最终性包括短暂的等待——通常约 10 分钟——以确保没有发现数据被扣留。

流程步骤：

1. 数据提交：Rollup 排序器或用户将交易块（作为数据blob）提交到 Celestia 的数据可用性网络。Celestia 验证者（区块提议者）获取此 blob 并将其拆分为较小的份额，将它们排列成 2D 矩阵。然后，它执行纠删码（Reed-Solomon）以扩展数据矩阵，增加奇偶校验份额，有效地将其大小加倍。这种冗余意味着即使某些份额缺失，也可以从其余份额中重建完整数据。

2. 通过 Merkle 根提交：验证者为扩展矩阵的每一行和每一列计算命名空间 Merkle 树（NMT）根，然后将这些根组合成一个单一的根提交，包含在区块头中。区块头中的此 Merkle 根绑定整个区块的数据。通过签署和发布区块头，Celestia 验证者证明他们已存储并见证了完整数据（除非他们收到所有份额，否则他们不会签署区块）。区块及其数据传播到网络中的所有 Celestia 全节点。

3. 数据可用性抽样：轻节点（资源有限的客户端）不下载完整区块，但它们下载每个区块头（包含数据根）。为了验证数据可用性，每个轻节点对份额进行随机抽样。轻节点在扩展数据矩阵中随机选择一个索引（或多个索引），并要求全节点提供该索引处的份额及其包含的 Merkle 证明。提供请求的全节点返回请求的份额及其 Merkle 证明（到区块头中根的路径）。

4. 份额验证：轻节点使用证明检查返回的份额与区块头的 Merkle 根。如果证明有效且份额数据匹配，轻节点会对此区块的这部分数据可用性增加信心。轻节点对多个随机份额重复此过程（协议确保只需要少量样本）。如果所有抽样份额都正确验证，则整个区块的数据可用性有高概率保证。这是因为如果区块的任何重要部分缺失，随机抽样很可能会命中缺失的份额并检测到它。

5. Gossip 和恢复：每次轻节点获得有效份额和证明时，它会将该份额传播给其他对等节点。在网络中，轻节点集体传播它们检索到的不同份额。只要诚实节点获得足够数量的唯一份额（至少原始数据大小的 k 份额），网络最终可以重建完整区块。这种去中心化的 gossip 作为额外的保障：即使区块提议者试图扣留某些数据，抽样过程也会捕获它，诚实节点可以从份额中拼凑出完整数据。

6. 处理不可用性：Celestia 使用乐观假设，即区块是可用的。如果轻节点的抽样失败（例如，它无法获得特定份额或证明无效），这是数据被扣留的证据。Celestia 然后允许欺诈证明或挑战。例如，如果发现区块的纠删码数据计算错误或份额缺失，可以提交不当行为的证明。Celestia 的设计包括一个挑战期，在此期间可以提交错误生成数据的欺诈证明，导致区块（和恶意验证者）被拒绝或罚没。实际上，通过数据可用性抽样和纠删码，这种情况极为罕见——诚实节点将以压倒性概率检测到不可用性。

以太坊锚定过程

sequenceDiagram
    participant C as Celestia Validators (DA Network)
    participant B as DA Bridge Contract (Ethereum)
    participant RL as Relayer/Orchestrator
    participant RC as Rollup Contract (Ethereum L1)
    participant CH as Challenger (Watcher)
    %% Bridging Celestia DA to Ethereum
    C ->> C: Finalize Celestia block with data blob (attested by 2/3 validators)
    C -->> RL: Emit block header (data root + signatures)
    RL ->> B: Submit block data root & validator signatures 
    B ->> B: Verify signatures against Celestia validator set (BFT quorum)
    B ->> B: Store attested data root (available off-chain)
    %% Rollup referencing DA on Ethereum
    RC ->> B: Look up data root for new rollup state update (by block height or ID)
    B -->> RC: Return proof of data availability (validated root exists) 
    RC ->> RC: Accept rollup block (data availability proven via Celestia)
    %% Challenge or Fallback
    alt Data unavailable or invalid
        CH ->> B: Challenge attested data (e.g., missing blob)
        B ->> B: Reject or flag the root (data unverified), alert rollup contract
        RC ->> RC: Trigger fallback (e.g., post data on Ethereum) or revert state update
    end

图表解释：

• 中继器将最终化的 Celestia 头和验证者签名转发到以太坊合约。
• Rollup 合约检查数据根在 Celestia 上有效，从而避免在以太坊上发布大量数据。
• 如果检测到不可用性，系统会回退到更昂贵的链上发布或停止。

流程步骤：

1. Celestia 区块最终化：当 Celestia 将 rollup 的数据 blob 包含在区块中时，其验证者运行共识（基于 Tendermint）以最终化该区块。Celestia 验证者的绝大多数（≥66%）签署区块头，其中包含数据的 Merkle 根承诺。此验证者签署的数据根是区块数据可用且有效的证明。最终化后，区块头（带有签名）准备中继到以太坊。

2. 数据根中继到以太坊：Celestia 使用桥接机制（以太坊上的 Quantum Gravity Bridge 合约）将数据可用性证明发布到以太坊。专门的中继器（可能是 Celestia 桥接节点之一或验证者联盟）获取最终化的 Celestia 区块头并将其提交到以太坊桥接合约。提交包括区块的数据根和一组验证者签名，证明该根。本质上，Celestia 网络表示“这是数据的密码学承诺，由我们的验证者签署。”

3. 以太坊上的验证：以太坊上的 DA 桥接合约维护 Celestia 验证者集（公钥）和所需的法定人数阈值。在接收到头和签名后，合约验证足够多数的 Celestia 验证者已签署数据根。如果签名有效并满足法定人数，合约接受此作为数据已发布在 Celestia 上的证明。桥接合约然后在以太坊上存储数据根（以及相关的区块高度或 ID），实际上将 Celestia 的数据可用性证明锚定在以太坊上。

4. Rollup 合约检查点：当 rollup 想要在以太坊上最终化状态更新时（例如，L2 区块或 epoch 的结束），它引用存储在 Celestia 上的数据，而不是在以太坊上发布所有交易数据。Rollup 的以太坊智能合约可能会调用或查询桥接合约，使用标识符（例如 Celestia 区块高度或预期的数据根哈希）来确认相应的数据确实发布在 Celestia 上并被证明可用。桥接合约返回存储的数据根或布尔值，指示数据可用性证明存在。这使得 rollup 合约能够验证链下数据可用性：如果桥接合约中找到并验证了数据根，rollup 知道其数据已安全发布在 Celestia 上。

5. 状态更新最终化：在桥接合约确认后，rollup 合约在以太坊上最终化 L2 状态更新。换句话说，以太坊确认新状态（例如，新的 L2 状态根），因为底层交易数据已证明在 Celestia DA 层上可用。这种设计使 rollup（有时称为Celestiums，当它们使用 Celestia 进行 DA 时）能够使用 Celestia 作为数据账本，同时依赖以太坊进行结算和争议解决。它显著降低了成本，因为 rollup 不需要将所有数据作为以太坊 calldata 发布——它只需发布对 Celestia 数据的廉价证明/引用。

6. 挑战机制和回退：在极少数情况下，如果 Celestia 的数据可用性证明被质疑或缺失，安全机制会启动。如果桥接合约没有预期的数据的有效证明（例如，如果 Celestia 未能最终化区块或扣留数据），rollup 无法在以太坊上最终化该状态。挑战者（观察者）甚至 rollup 合约本身可以检测到这一点。Rollup 可能会启动回退，例如将原始数据发布到以太坊 L1（以确保可用性，尽管成本更高）或停止更新。在乐观情况下，如果某种欺诈证明通过（例如，验证者签署了根，但后来发现数据不可用），可以在定义的期限内提出挑战。桥接合约将标记该数据根为无效，rollup 将忽略该链下数据，回退到链上解决方案或回滚状态。Celestia 的设计通过在其自身方面使用欺诈证明来最小化这种风险，并通过经济激励（验证者会在 Celestia 上因不当行为被罚没）。此外，集成 Celestia 的 rollup 通常包括以太坊回退机制——如果 Celestia 的 DA 失败，它们确保数据发布到以太坊，以保持可用性。

与以太坊 DA 的权衡

• 优点
  • 低成本和灵活的区块大小（2 MB → 8 MB → 未来 100-1000 MB）。
  • 完全去中心化：任何节点都可以抽样以验证可用性。
• 缺点
  • 需要信任另一条链（Celestia 的 ~100 验证者，DPoS）。
  • ~10 分钟的最终性等待以确认没有扣留数据（欺诈证明窗口）。
  • 没有直接的以太坊强制执行（除非桥接解决方案成熟）。

使用 Celestia 的项目

Celestia 仅在 2023 年底推出其主网，但已有多个项目在其上构建。

• Celestia Rollkit SDK 允许开发者启动使用 Celestia 进行 DA 的 rollup，开销最小。例如，AltLayer 已集成 Celestia 的 DA 层，使其 rollup 更具可扩展性和经济性（blog.altlayer.io）。
• Eclipse 和 Saga 正在开发可定制的 rollup（用于 Solana VM 等），可以插入 Celestia 进行数据可用性。
• 在 Cosmos 生态系统中，Dymension 正在创建“RollApps”，它们在 Cosmos 中心上结算，同时使用 Celestia 作为其数据层。
• 甚至以太坊中心框架如 OP Stack 也有“Celestium”模型的原型（使用 Celestia 而不是在以太坊上发布 calldata）。例如，Arbitrum 的 Conduit 计划允许任何人启动 Arbitrum Stylus 链，Celestia 提供 DA。

这些早期采用者被 Celestia 的低成本和吞吐量所吸引：一项分析指出，在测试期间，Celestia 每 MB 的成本比以太坊的 proto-danksharding blobs 低约 64%（conduit.xyz）。权衡之处在于接受 Celestia 的独立信任域进行 DA。

数据保留说明：在 Celestia 中，全节点在链上存储数据，但旧数据（2 周以上）可能会在某个挑战窗口后被修剪。轻节点只需要区块头和随机抽样来确认新区块。如果需要扩展验证，归档节点可以保留旧数据。

Polygon Avail

Polygon Avail 是另一个独立的 DA 链（最初在 Polygon 孵化），专注于 KZG 多项式承诺，提供比 Celestia 的欺诈证明方法更快的最终性。基于 Substrate 构建，它使用 BABE 进行区块生产，使用 GRANDPA 进行最终性（~40 秒）。

完整的数据可用性流程

sequenceDiagram
    participant S as Sequencer / Block Proposer (Avail)
    participant VA as Avail Validators (Full Nodes)
    participant LA as Avail Light Client
    %% Block creation with erasure coding and commitments
    S ->> VA: Propose block with queued transactions & rollup data
    S ->> S: Arrange transactions into 2D matrix, perform erasure coding on columns 
    S ->> S: Compute KZG polynomial commitment for each row, include in block header 
    VA ->> VA: Validate block data and KZG commits (recompute to verify) 
    VA ->> VA: Finalize block (BABE/GRANDPA consensus) once data integrity confirmed
    %% Data availability sampling by light clients
    LA ->> VA: Request random block chunk (share) and its KZG proof 
    VA -->> LA: Provide chunk data + opening proof for commitment
    LA ->> LA: Verify chunk against KZG commitment in header (proof checks out) 
    alt Multiple Samples
        LA ->> VA: Sample additional random chunks with proofs 
        VA -->> LA: Return chunks with valid KZG openings
        LA ->> LA: All samples match commitments (block available)
    end
    LA ->> LA: Mark block as available (no fraud proof needed, validity proven)
    Note over LA,VA: Light clients form P2P network, collectively sample and share to ensure data availability.

图表解释：

• 数据在列上进行纠删码，每行通过 KZG 提交。
• 验证者在 ~40 秒内最终化区块。KZG 充当每个区块完整性的“零知识”证明。
• 如果 KZG 正确，则无需等待期——区块在密码学上被证明是可用的。

流程步骤：

1. 区块提议和纠删码：Polygon Avail 是一个专门构建的数据可用性区块链。当交易和 rollup 数据提交到 Avail 时，区块提议者（排序器）将它们收集到新区块中。提议者将区块的交易数据（包括任何 L2 blob）组织成 2D 矩阵格式，然后对数据列应用纠删码。这意味着为每列数据添加额外的奇偶校验块，扩展区块大小（例如，2 MB 的区块可能会扩展到 4 MB，增加冗余）。纠删码确保即使某些数据块缺失，也可以从其余部分重建原始数据。

2. 区块头中的 KZG 承诺：对于扩展数据矩阵的每一行，Avail 计算一个 KZG 多项式承诺，并将这些承诺插入区块头中。KZG 承诺是对多项式（在此情况下表示一行的数据）的密码学承诺，允许使用简洁的证明验证任何数据块。通过在头中绑定多个 KZG 承诺（每行一个），Avail 提供了所有区块数据的强密码学指纹。与 Celestia 的 Merkle 树（需要下载许多哈希进行验证）不同，KZG 承诺允许对任何数据块进行非常短的恒定大小证明。这消除了对缺失数据的欺诈证明的需求——如果某块数据缺失或不正确，证明将立即失败。

3. 验证者验证和共识：Avail 验证者（全节点）接收提议的区块及其数据。它们独立地重新计算纠删码和 KZG 行承诺，以确保区块数据正确并与头匹配。这充当完整性检查：如果提议者包含任何错误的承诺或损坏的数据，诚实的验证者将检测到它。Avail 使用共识机制（例如，Polkadot 的 BABE 进行区块生产，GRANDPA 进行最终性）在绝大多数验证者同意数据和承诺有效后最终化区块。结果是最终化的区块，其数据可用性通过承诺固有地验证——无需“假设”可用性然后稍后挑战，因为承诺作为数据正确和完整的有效性证明。

4. 轻客户端抽样：与 Celestia 类似，Avail 支持轻客户端的数据可用性抽样（DAS）。轻客户端只下载区块头（带有 KZG 承诺），而不是完整数据。为了验证区块的数据可用性，轻客户端随机请求区块的少量数据块。对于每个请求的块，Avail 全节点提供该块及其 KZG 开放证明——一个简短的证明，证明该块与头中的多项式承诺一致。轻客户端使用 KZG 承诺（从头中）验证块的证明。如果证明通过，该块被确认存在于区块中且正确。

5. 高概率保证：轻客户端对几个随机选择的块重复此过程（确切样本数可以很少——KZG 承诺允许即使恒定数量的样本也能提供强保证。如果所有抽样的块都产生有效证明，客户端高度确信整个区块的数据是可用的。由于纠删码，恶意验证者必须隐藏区块的大部分才能使数据不可用；如此大的差距几乎肯定会被随机抽样捕获。Avail 的设计因此为轻客户端提供了接近 100% 的数据可用性保证，而无需任何对抗性挑战过程。换句话说，如果 Avail 区块最终化，客户端可以信任数据已发布并可用，因为任何不一致都会通过承诺和抽样检测到。

6. 点对点轻客户端网络：Avail 通过鼓励强大的 P2P 轻客户端网络来区分自己。这些轻客户端协调抽样每个区块的不同部分。如果轻客户端获得一个块及其证明，它可以与其他客户端共享此信息。这种协作抽样意味着即使某些轻客户端抽样不同的随机块，它们集体覆盖了区块的大部分。Avail 的轻客户端甚至可以充当全节点的备份：如果某些全节点离线，轻客户端网络拥有块并可以帮助重建数据。这种方法确保了冗余和弹性——即使在网络中断期间，数据仍然可用，这是 Avail 可用性层的关键设计目标。

以太坊锚定过程

sequenceDiagram
    participant A as Avail Network (Validators)
    participant AB as Avail Attestor (Bridge Agent)
    participant BC as Avail Bridge Contract (Ethereum)
    participant LR as L2 Rollup Sequencer
    participant L2C as Rollup Contract (Ethereum)
    %% Off-chain data publication on Avail
    LR ->> A: Publish rollup tx data to Avail DA chain
    A ->> A: Finalize block with rollup data (KZG commitments attested)
    %% Attestation bridge to Ethereum
    A -->> AB: Emit finalized block info (block hash, data commitments)
    AB ->> BC: Post data availability attestation for block (proof or signature) 
    BC ->> BC: Verify attestation (e.g. zkSNARK or validator sigs) 
    BC ->> BC: Record Avail block reference as available (on Ethereum)
    %% Rollup contract verification on Ethereum
    L2C ->> BC: Query attestation for rollup data (by block ID or hash)
    BC -->> L2C: Confirm data availability proof (attestation exists)
    L2C ->> L2C: Accept rollup state update (L2 data proven available off-chain)
    %% (Optional) Challenge / fallback
    alt Attestation missing or invalid
        L2C ->> L2C: Pause rollup finality, require fallback (post data on L1)
    end

图表解释：

• Avail 通过密码学保证（KZG）最终化区块。
• 桥接将认证发布到以太坊。L2 rollup 合约检查该认证，确认链下数据。
• 如果认证未出现，rollup 可能会等待，回退到链上数据，或暂停。

流程步骤：

1. Rollup 数据发送到 Avail：使用 Avail 进行数据可用性的以太坊 Layer-2（或 Layer-3）rollup（例如，Validium 或任何链下数据存储方案）首先将其交易数据发送到 Avail 网络。Rollup 的排序器通过将其提交给 Avail 的验证者，将 L2 交易 blob 包含在 Avail 区块中。此数据被包含在 Avail 链上的区块中，具有上述所有完整性和可用性保证（纠删码，通过 KZG 提交，并由 Avail 的共识验证）。

2. Avail 区块最终化：Avail 网络最终化包含 rollup 数据的区块。此时，数据已在 Avail 上证明可用（通过 KZG 承诺和验证者检查）。现在，重要的是将此事实传达给以太坊。Avail 最初被设想为以太坊的“数据认证桥”，用于链下数据。在其当前架构中，Avail 作为独立的 DA 链运行，但它向以太坊提供认证，即“rollup X 在时间 Y 的数据在 Avail 上可用。”

3. 数据认证桥：一旦 Avail 区块最终化，链下过程或实体（此处标记为 Avail Attestor）准备以太坊的数据可用性认证。这可以是两种方法之一：

   • 验证者签名：一组 Avail 验证者（或专门的桥接委员会）签署包含 Avail 区块 ID 和数据根的消息，确认数据可用。
   • zkSNARK 证明：或者，可以生成 zkSNARK（零知识证明）以证明某个数据承诺存在于 Avail 链的状态中，或者 Avail 共识最终化了该区块。Avail 的团队引入了 VectorX 桥，它使用 zkSNARK 在 Avail 和以太坊之间进行高效、信任最小化的消息桥接。

   认证者将此证明/认证提交到部署在以太坊上的 Avail Bridge Contract。

4. 以太坊上的验证：以太坊上的 Avail Bridge Contract 验证认证。如果是一组签名，合约检查足够多的授权 Avail 验证者已签署（类似于多签或轻客户端的工作方式）。如果是 zkSNARK，合约使用证明确认认证有效（例如，它对应于具有给定数据根的真实 Avail 区块）。一旦验证，合约现在具有链上记录，表明特定的 Avail 区块（以及其中的 rollup 数据）可用。本质上，以太坊通过此合约获得密码学保证，即 rollup 的数据存在于链下并已正确发布。

5. Rollup 合约集成：Rollup 的以太坊智能合约（处理其状态转换和欺诈证明）与桥接合约交互以确认数据可用性。例如，当 rollup 排序器向 rollup 合约发布新的 L2 状态根时，它还将提供对 Avail 上存储数据的引用（例如 Avail 区块号或哈希）。Rollup 合约可以调用桥接合约以检查该引用的认证是否存在。桥接合约返回确认，表明数据确实在 Avail 上被认证为可用。有了此确认，rollup 合约可以安全地接受新状态根，知道底层交易在需要时可以链下访问。

6. 在以太坊上最终化 L2 状态：一旦数据可用性证明被确认，rollup 的状态更新在以太坊上最终化。在 Optimistic Rollup 上下文中，这意味着区块可以进入挑战期，数据可用于欺诈证明；在 Validium 上下文中，以太坊有保证数据由 Avail 安全保存。这种在 L1 上的锚定认证取代了在以太坊上发布完整交易数据的需求，从而节省 gas，同时仍保持安全性（任何争议 rollup 的人可以从 Avail 检索数据并在必要时提出欺诈证明）。

7. 挑战或回退（如果需要）：如果 Avail 的认证未出现在以太坊上（例如，如果 Avail 的网络未及时生成或传输证明），rollup 必须有回退以避免安全漏洞。通常，rollup 不会在没有可用性证明的情况下最终化状态根。它可能会延迟最终化，并最终回退到在以太坊上发布数据（以更高的成本确保可用性）。在极端情况下，如果 Avail 被认为被破坏或无法提供数据，rollup 可以切换到紧急模式，在链上发布数据或暂停操作。桥接的目标是通过可靠地向以太坊提供数据可用性证明来防止这种情况。Avail 的设计，凭借其强大的密码学承诺和验证者认证，使得无效或虚假认证的可能性极低。由于 Avail 是一个具有自己经济学的独立链，没有直接的“在以太坊上罚没”Avail 的验证者，但任何虚假认证都意味着 Avail 安全性的灾难性失败。实际上，认证桥旨在最小化信任并可靠，因此以太坊可以信任 Avail 的数据可用性。

与以太坊 DA 的权衡

• 优点
  • 通过 KZG 在最终性时立即提供数据可用性（无挑战期）。
  • 比 Celestia 的 ~10 分钟更快的最终性（~40 秒）。
  • 灵活的桥接方法，可选 zk 证明。
• 缺点
  • 独立链安全性：依赖 Avail 的 PoS 验证者集。
  • 当前桥接到以太坊是“乐观的”（需要观察者）。
  • 不如以太坊“经过实战检验”。

使用 Avail 的项目

Avail 相对较新（其代币于 2023 年上线），但它已被定位为 Polygon 生态系统及更广泛领域的 DA 解决方案。

• Polygon 的 zkEVM 团队讨论了提供 validium 模式——Avail 可以作为 zkEVM 或未来 Polygon 链的链下 DA 层，以提高吞吐量而无需以太坊费用。Avail 的数据认证桥被设计为通用的，因此任何 EVM rollup（Optimistic 或 ZK）都可以集成它。例如，Avail 可以被 zkSync 或 StarkNet 在“volition”模式（用户选择链上或链下数据）中使用，以提供去中心化的链下选项，而不是中心化委员会。
• Avail 团队明确提到支持 Starkware 风格的 Volitions 和 zkPorter 类似场景（forum.celestia.org）（blog.availproject.org）。
• 除了以太坊，Avail 的技术也适用于需要可靠 DA 后备的特定应用链或侧链。截至 2025 年初，具体部署正在测试中；例如，Polygon Supernets（应用链）预计将提供 Avail 作为 DA 层。此外，Avail 已与 dWallet（用于比特币 rollup）等项目合作（dailycoin.com），表明其用例的广泛性。

愿景是 Avail 将充当 Web3 的“统一层”——不同生态系统的多个 rollup 都可以使用 Avail 作为共同的 DA 中心，每个 rollup 将其证明锚定到自己的 L1，但共享相同的数据层。虽然仍处于早期阶段，Avail 的轨迹是成为广泛采用的 DA 骨干，特别是对于那些已经在 Polygon 生态系统中的人。

数据保留说明：Avail 将所有数据存储在其链上，验证者通过 KZG 确认它。随着时间的推移，旧区块可能会被修剪，但链必须保留足够的数据以满足桥接的挑战窗口和潜在的重新检查。Avail 还培养了一个 P2P 轻客户端网络，以确保冗余。

EigenDA

EigenDA 是 EigenLayer 上的数据可用性服务，以太坊验证者重质押 ETH 以存储链下数据。本质上，它是一个受信任的委员会，通过罚没确保诚实，但它与以太坊的经济安全紧密对齐。

完整的数据可用性流程```mermaid

sequenceDiagram participant R2 as Rollup Sequencer participant OP as EigenDA Operators (Restaked ETH validators) participant E as EigenDA Service Contract (Ethereum) participant W as Watcher (Verifier) %% 数据分发到 EigenDA 节点 R2 ->> OP: 将 rollup 区块数据分发到 EigenDA 操作节点（分片 blob） loop 每个操作者 OP ->> R2: 签署接收到的数据块的收据（保管证明） end R2 ->> R2: 聚合操作者的签名（存储证明） R2 ->> E: 使用聚合证明注册数据 blob（blob ID，承诺） E ->> E: 验证集体签名（法定人数存储数据） E ->> E: 在链上记录 blob ID 和数据根（声明可用性） %% Rollup 发布对 Ethereum 的引用 R2 ->> L2C2: 发布新的 rollup 状态根 + EigenDA blob ID 到 Rollup 合约 L2C2 ->> E: 通过检查 blob ID 记录验证数据可用性 E -->> L2C2: 确认 blob 已存储并达到法定人数（如果缺失则标记） L2C2 ->> L2C2: 最终化 rollup 区块（链下数据可用性已确认） %% 持续可用性和惩罚 W ->> OP: 随机请求存储的数据块（抽查可用性） OP -->> W: 根据请求提供数据块（证明保管） alt 操作者未能提供数据 W ->> E: 提交挑战（操作者 X 行为不当） E ->> E: 惩罚操作者 X 的质押（违反数据可用性承诺） end

**图表解释：**
- 操作者签署他们拥有每个分片。法定人数的签名在 Ethereum 上聚合。  
- 一旦 Ethereum 将 blob 记录为“可用”，rollup 就可以依赖它。  
- 惩罚机制确保那些声称存储但未能提供数据的操作者受到惩罚。

**流程步骤：**

1. **选择加入 Ethereum 验证者作为 DA 操作者**：EigenDA 是建立在 Ethereum 的 EigenLayer 协议上的特殊数据可用性层。EigenDA 没有自己独立的验证者集合，而是利用 Ethereum 现有的验证者（或其他 ETH 质押者），他们选择加入并重新质押他们的 ETH 以成为 EigenDA 操作者。这些操作者形成一个去中心化网络，负责存储和提供链下数据。他们不通过新的共识机制生成区块；相反，他们共同持有数据并证明其可用性。安全假设是大多数这些 EigenDA 操作者是诚实的（或者至少不会全部串通隐藏数据），类似于 Ethereum 自身的安全假设。

2. **数据分发（分片 blob）**：当 rollup 排序器想要使用 EigenDA 发布一批交易时，它不会直接将数据放在 Ethereum 上。相反，排序器将 rollup 区块数据（通常称为“blob”）分发到 EigenDA 操作节点。实际上，数据 blob 可能会被分成块（分片），并可能进行编码（使用类似于 danksharding 的技术——例如，多项式承诺和纠删码——以方便证明）。排序器（或专用的分发组件）将每个块发送到不同的 EigenDA 操作者或多个操作者。在此步骤结束时，没有任何单一实体拥有整个 blob（除非使用冗余），但网络共同持有所有数据片段。

3. **操作者证明（保管证明）**：每个接收到数据块的 EigenDA 操作者必须证明它已存储该块。EigenDA 实现了保管证明的概念：例如，操作者可能会签署数据块的加密哈希值（或某些只有在拥有该块时才能生成的派生值）。在上面的序列中，每个操作者向排序器发送一个签名的收据，确认他们拥有他们的数据部分。这些签名通常结合了加密技巧，以防止操作者在没有实际存储数据的情况下签署收据（以便他们以后撒谎时可以被惩罚）。所有这些签名收据的集合构成了“EigenDA 操作者网络拥有整个 blob”的证明。

4. **聚合证明和链上注册**：rollup 排序器（或分发器）将操作者的签名聚合成一个紧凑的证明（这可能是通过 BLS 签名聚合以提高效率）。然后它调用 Ethereum 上的 EigenDA 智能合约（通常称为 EigenDA 服务管理器合约）来注册数据 blob。排序器向合约提供：(a) 唯一的 blob ID 或引用，(b) 数据的承诺（例如，整个 blob 的 Merkle 根或多项式承诺），以及 (c) 证明 EigenDA 操作者正在存储该数据的聚合签名。Ethereum 合约根据已知的 EigenDA 操作者集合（其身份来自重新质押的验证者集合）验证聚合签名。如果签名检查通过——意味着法定人数的操作者（可能是全部或阈值，例如 2/3）已签署——合约接受此作为 blob 存储在链外的证明。

5. **链上确认可用性**：在成功验证后，EigenDA 合约在链上记录 blob 的 ID 和数据承诺，将其标记为可用。这可能包括存储数据的根哈希值，可能还包括签名者集合或纪元号。从此时起，Ethereum（通过此合约）拥有一个权威记录，即“Blob X 由 EigenDA 网络持有，并具有有效的证明”。此链上记录对于 rollup 的安全性至关重要：它可以在争议解决中被引用。值得注意的是，此过程发生得很快，并且只有少量数据（聚合签名和哈希值）被发布到 Ethereum，这比发布整个 blob 便宜得多。

6. **Rollup 引用 EigenDA 数据**：rollup 在 Ethereum 上的智能合约现在与 EigenDA 的合约交互以利用链下数据。当 rollup 排序器提交状态根（执行 L2 交易的结果）时，它还提供包含相应交易的 EigenDA blob ID。rollup 合约可以调用 EigenDA 合约来验证此 blob ID 是否具有有效的可用性证明。EigenDA 合约响应（可能返回存储的承诺或布尔值）表明数据已正确存储和证明。有了该确认，rollup 合约可以安全地最终化 L2 状态根，知道如果任何人需要挑战该 rollup 块的有效性，数据可以从 EigenDA 获得。

7. **提供数据和观察者验证**：数据可用性保证不仅仅在证明时结束；数据必须保持可检索。EigenDA 操作者被期望在某个时间窗口内根据请求提供数据。观察者或挑战者（任何相关方，可能是其他 Ethereum 验证者或用户）可以向 EigenDA 操作者查询随机数据块作为抽查（这类似于数据可用性采样，但在这里每个操作者都有特定的块）。如果操作者是诚实的，他们将响应请求的数据。此链下查询可以由 rollup 挑战者执行，以在需要验证欺诈证明时实际获取完整的 rollup 数据。

8. **不可用性的惩罚**：EigenDA 引入了一种基于惩罚的机制来惩罚未能履行其存储职责的操作者。假设一个操作者签署了它拥有一个块（因此其签名在链上聚合），但后来拒绝或未能提供该块——这是对其承诺的违反。EigenDA 的合约允许挑战：观察者可以提交证据证明特定操作者未提供数据。一种方式是交互式协议，观察者证明他们请求了该块，而操作者未响应（或响应了无效数据）。另一种方式使用加密技巧：例如，在证明期间，操作者可能承诺了一个从块派生的随机秘密（保管证明）。合约可以挑战操作者揭示该秘密；未能做到这一点证明他们从未拥有该块。如果挑战成功，违规操作者将被惩罚（他们在 EigenLayer 上质押的 ETH 将被罚没）。这强烈激励操作者实际存储和提供他们签署的数据。

9. **数据可用性得到保证**：由于操作者面临失去质押的风险，他们有动力在所需的时间内可靠地存储数据。因此，EigenDA 提供了一种具有加密经济保证的去中心化存储：只要大多数重新质押的验证者是诚实的（并且响应），数据将保持可用。该系统类似于 Ethereum 即将推出的 danksharding 方法（也涉及数据可用性采样和分片的保管证明），但作为选择加入的服务在链外实现。关键区别在于 EigenDA 不是共识层；它是由观察者/操作者合作持有数据的法定人数，由 Ethereum 的安全性（惩罚条件）锚定。

### 与 Ethereum DA 的权衡

- **优点**  
  - **“Ethereum 对齐的安全性”**（ETH 重新质押）。  
  - **极高的吞吐量**（跨多个操作者的分片）。  
  - **最小的桥接开销**——一切都在 Ethereum L1 上。  
- **缺点**  
  - 用户必须信任一个**链下委员会**（除非他们运行一个完整的 EigenDA 节点）。  
  - 如果大多数串通，可能会中心化。  
  - 依赖于 EigenLayer 智能合约的正确性，这是新代码。

### 使用 EigenDA 的项目

EigenDA 于 2024 年在 Ethereum 主网上正式推出，并正在被多个 rollup 项目测试。

- **OP Stack（Optimism）** 已添加对替代 DA 层的支持，EigenLayer 团队发布了一个集成了 EigenDA 的 OP Stack 分支（[blog.eigenlayer.xyz](https://www.blog.eigenlayer.xyz/announcing-eigenda-x-op-stack-support/#:~:text=Announcing%20EigenDA%20x%20OP%20Stack,sizes%20and%20cheaper%20DA)）。例如，OP Craft（一个实验性 rollup 游戏）和 OP Labs 的测试网已使用 EigenDA 作为 DA 提供者，允许更大的 L2 区块，同时只在 Ethereum 上留下很小的足迹。
- **AltLayer**，一个 rollup 即服务平台，在 Sepolia 上运行了一个“OP EigenDA”测试网：L2 交易被发布到 EigenDA，只有简短的 blob 引用被放在 Ethereum L1 上（[docs.altlayer.io](https://docs.altlayer.io/altlayer-documentation/public-testnets/op-eigenda-testnet#:~:text=OP%20EigenDA%20testnet%20is%20an,as%20its%20data%20availability%20layer)）。这展示了 L2 的显著降低成本（因为昂贵的部分——数据——在链外由 EigenDA 处理）。
- 我们可以期待新兴的 L2 网络和应用链采用 EigenDA，特别是那些希望最大化吞吐量但仍希望在 Ethereum 上结算的项目。Optimism “Superchain” 和 OP Stack 链也有兴趣：企业或高容量用例的项目可能会使用 EigenDA 来避免 Ethereum 的费用。
- 另一个例子是 zkSync 的 HyperChains 或 Polygon 即将推出的网络考虑使用 EigenLayer/EigenDA 作为其数据层（这是推测性的，但两个团队都讨论了模块化链下 DA 的方法）。
- 总的来说，EigenDA 被视为需要 Ethereum 级别安全性的大规模 rollup 的主要候选者。

> **关于数据保留的说明**：EigenDA 操作者承诺在争议期间存储数据。一旦该期间过去（例如，如果乐观 rollup 的挑战窗口为 1 或 2 周），他们可以删除旧数据。如果需要用于欺诈证明，观察者必须在删除之前检索数据。

## 优缺点总结

### Celestia

- **优点**  
  - 三者中**最去中心化**（任何人都可以通过采样验证 DA）；每个区块的吞吐量高度可扩展  
  - 发布数据的成本非常低（适合小型 rollup）  
  - 简单设计，利用经过验证的 BFT 共识和欺诈证明  
- **缺点**  
  - 需要信任一个新的独立链（100 个验证者，正在增长）  
  - DA 最终性等待时间较长（挑战期约几分钟）  
  - 没有直接的 Ethereum 强制执行（需要外部假设或未来的桥接）  
  - 由于 DPoS 模型，可能导致质押中心化。

### Polygon Avail

- **优点**  
  - **即时** DA 证明在最终性时（得益于 KZG 承诺）  
  - 快速确认（约 40 秒）  
  - 强大的验证者去中心化计划（NPoS，许多验证者）  
  - 内置到 Ethereum 的桥接以实现问责  
  - 对乐观和 ZK rollup 都灵活（validium/volition 支持）  
- **缺点**  
  - 也是一个新链（安全性尚不成熟，但随着更多验证者加入而改善）；当前的 Ethereum 桥接是乐观的（需要挑战观察者）  
  - 尚未像 Ethereum 或 Polygon 的 PoS 链那样经过实战考验；更高的复杂性（维护 KZG 仪式/承诺的信任设置等）

### EigenDA 

- **优点**  
  - **Ethereum 对齐的安全性**：使用 ETH 惩罚不当行为，吸引那些信任 Ethereum 经济的人  
  - 极高的吞吐量潜力（水平扩展）  
  - 对 rollup 来说成本低（只在 L1 上发布简短的 blob 引用）  
  - 无需管理单独的代币或 L1，利用现有的 Ethereum 验证者；与主要 rollup 框架（OP Stack）的集成正在进行中，使其易于采用  
- **缺点**  
  - 本质上是一个**有激励的信任委员会**——用户无法在不运行完整节点的情况下验证 DA，这是信任的中心化  
  - 恶意多数可能会欺骗系统（尽管困难），并且在链上检测并不简单；目前有一个中心化组件（分发器），这是一个弱点，直到去中心化  
  - 依赖于 EigenLayer 智能合约的正确性（合约风险）；Ethereum 依赖意味着你继承了 Ethereum 的延迟（以及其中的任何问题）

## 关键要点与结论

每个解决方案——Celestia、Polygon Avail、EigenDA——针对**数据可用性频谱**的不同部分。以下是它们通常的适用场景：

- **Celestia**：  
  - 非常适合寻求低费用和**模块化链设计**的**主权 rollup**。  
  - 通过采样完全去中心化的 DA 检查，代价是较长的最终性等待（约 10 分钟）和对新链的依赖。  
  - 使用行+列承诺（命名空间 Merkle 树）和欺诈证明的纠删码。

- **Polygon Avail**：  
  - 使用 KZG 承诺为每行优化快速数据最终性（约 40 秒）。  
  - 在 Polygon 生态系统内或其他希望介于原始 Ethereum DA 和 Celestia 外部链之间的 EVM rollup 中理想。  
  - 允许通过数据证明桥接，使用验证者签名或 zkSNARK 方法。

- **EigenDA**：  
  - 使用重新质押的 ETH 和惩罚将数据可用性**嵌入 Ethereum 的安全性**中。  
  - 潜在的巨大吞吐量，但从用户的角度来看，实际上是一个**链下委员会**。  
  - 非常适合希望获得**“超大规模”**数据容量的以 Ethereum 为中心的大型 L2，尽管它依赖于 EigenLayer 的新智能合约。

在实践中，没有一个单一的 DA 层是普遍最好的。一个游戏 rollup 可能会优先考虑最低成本（Celestia），一个拥有数十亿美元 TVL 的 DeFi 链可能希望 Ethereum 的惩罚安全性（EigenDA），而一个基于 Polygon 的 L2 可能会选择 Avail 以实现协同效应和快速最终性。一些项目甚至可能混合多种模式（volition）。

随着 rollup 的不断发展，选择正确的数据可用性层可能会决定成本和安全性。无论你更喜欢 Celestia 的**模块化理念**、Avail 的**快速最终性**，还是 EigenDA 的**Ethereum 对齐方法**，理解它们的核心机制和权衡是在多链世界中构建可扩展、安全的 L2 的关键。

## 参考文献

1. Celestia 文档与论坛  
   - [Celestia 文档 – 数据可用性 FAQ](https://docs.celestia.org/learn/how-celestia-works/data-availability-faq)  
   - [Celestia 论坛：DA 层比较](https://learnblockchain.cn/article/6208)  
   - [Celestia 论坛：使用 Celestia 进行 Validiums](https://forum.celestia.org/t/validiums-settling-transaction-data-on-celestia/66)

2. Polygon Avail 资源  
   - [Avail FAQs：DAS、纠删码、KZG](https://docs.availproject.org/docs/faqs)  
   - [Avail 博客：选择正确的数据可用性层指南](https://blog.availproject.org/a-guide-to-selecting-the-right-data-availability-layer)  
   - [Avail 的数据证明桥接](https://blog.availproject.org/data-attestation-bridge)

3. EigenDA / EigenLayer  
   - [EigenDA GitHub 规范](https://github.com/Layr-Labs/eigenda/blob/master/docs/spec/overview.md)  
   - [EigenLayer 博客：EigenDA 简介](https://www.blog.eigenlayer.xyz/intro-to-eigenda-hyperscale-data-availability-for-rollups)  
   - [AltLayer：OP EigenDA 测试网](https://docs.altlayer.io/altlayer-documentation/public-testnets/op-eigenda-testnet)

4. 一般比较  
   - [The Rollup 通讯：DA 层概述](https://therollup.co/research/exploring-the-data-availability-layer)  
   - [MT Capital 研究报告：Celestia vs EigenDA](https://m.theblockbeats.info/en/news/50536)  
5. KZG  
   - [掌握 KZG PCS](https://learnblockchain.cn/article/13341)

>- 原文链接： [github.com/thogiti/thogi...](https://github.com/thogiti/thogiti.github.io/blob/master/_posts/2025-02-25-Choosing-Right-DA-Layer-Celestia-Polygon-Avail-Eigen.md)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～