Subscribe to Textile Blog & Newsletter
>300 subscribers
Subscribe to Textile Blog & Newsletter
>300 subscribers
Share Dialog
Share Dialog
Data Availability (”DA”) is a hot topic now that EIP-4844 is live! There are a few major players in the space, and all of them take similar approaches but with a few differences. We'll take a look at EigenDA, Celestia, Avail, and Arbitrum AnyTrust. But first, let's start off with a bit of background information.
DA layers ensure that block data is provably published so that applications and rollups can know what the state of the chain is—but once the data is published, DA layers do not guarantee that historical data will be permanently stored and remain retrievable. DAs either deploy a validity proof or a fraud/fault proof (validity proofs are more common). Data availability sampling (”DAS”) by light clients is also a common feature to ensure data can be recovered. However, the term DA typically refers to simple blocks/transaction data, so it differs from large, arbitrary, long-term data availability and storage.
The following section outlines common terms across DA protocols. Skip if familiar.
To clarify, here's a quick recap of what DAs implement:
Validity proofs: ensure that all data and transactions are valid before they are included onchain via zk-SNARKs/STARKs.
Computationally intensive but provides strong security guarantees.
Fraud/fault proofs: allow data to be posted onchain before guaranteed valid—and use a challenge period for tx dispute resolution.
Less computationally intensive but lower security guarantees (i.e., requires the network to actively generate fraud proofs).
KZG commitment scheme: data redundancy via erasure encoding—and correctness thereof without needing a fraud proof.
E.g., full nodes to prove transaction inclusion to light nodes using succinct proof.
Erasure encoding: reduce per-node storage requirements by splitting data up across many nodes while ensuring the original data can be recovered if lost.
This involves decreasing an individual node’s storage requirement by increasing the total size of a piece of data (splitting into blocks & adding additional redundancy/erasure encoded blocks).
Then, distribute the blocks across many nodes. If you need the original data, it should be recoverable by piecing blocks back together from the network—assuming some defined tolerance threshold is held.
Data availability sampling: ensure data availability without requiring nodes to hold the entire dataset; complements erasure encoding to he
lp guarantee data is available.
I.e., randomly sampled pieces of erasure-coded block data to assure the entire block is available in the network for reconstruction—else, slash nodes.
Data availability committee: a trusted set of nodes—or validators in a DA PoS network—that store full copies of data and publish onchain attestations to prove ownership.
The following section outlines common L2s and how they approach DA.
According to Avail, there are a few different approaches that L2s take to DA. Note this is in the sense of block/transaction DA and differs from the “arbitrary” / large DA approach Textile focuses on with Basin and object storage:
Post proofs (validity or fraud) onchain along with state commitments.
All data and computation, except for deposits, withdrawals, and Merkle roots, to be kept offchain.
Adaptation of Optimistic rollups that also take data availability offchain while using fraud proofs for verification.
I.e., differs from traditional rollups in that transaction data is entirely in offchain storage.
E.g., Optimism offers a “plasma mode” where data is uploaded to the DA storage layer via plain HTTP calls
Adaptation of ZK rollups that shift data availability offchain while continuing to use validity proofs.
E.g., Starknet posts a STARK validity proof and also sends a state diff, which represents the changes in the L2 state since the last validity proof was sent (updates/modifications made to the network's state).
Data Availability (”DA”) is a hot topic now that EIP-4844 is live! There are a few major players in the space, and all of them take similar approaches but with a few differences. We'll take a look at EigenDA, Celestia, Avail, and Arbitrum AnyTrust. But first, let's start off with a bit of background information.
DA layers ensure that block data is provably published so that applications and rollups can know what the state of the chain is—but once the data is published, DA layers do not guarantee that historical data will be permanently stored and remain retrievable. DAs either deploy a validity proof or a fraud/fault proof (validity proofs are more common). Data availability sampling (”DAS”) by light clients is also a common feature to ensure data can be recovered. However, the term DA typically refers to simple blocks/transaction data, so it differs from large, arbitrary, long-term data availability and storage.
The following section outlines common terms across DA protocols. Skip if familiar.
To clarify, here's a quick recap of what DAs implement:
Validity proofs: ensure that all data and transactions are valid before they are included onchain via zk-SNARKs/STARKs.
Computationally intensive but provides strong security guarantees.
Fraud/fault proofs: allow data to be posted onchain before guaranteed valid—and use a challenge period for tx dispute resolution.
Less computationally intensive but lower security guarantees (i.e., requires the network to actively generate fraud proofs).
KZG commitment scheme: data redundancy via erasure encoding—and correctness thereof without needing a fraud proof.
E.g., full nodes to prove transaction inclusion to light nodes using succinct proof.
Erasure encoding: reduce per-node storage requirements by splitting data up across many nodes while ensuring the original data can be recovered if lost.
This involves decreasing an individual node’s storage requirement by increasing the total size of a piece of data (splitting into blocks & adding additional redundancy/erasure encoded blocks).
Then, distribute the blocks across many nodes. If you need the original data, it should be recoverable by piecing blocks back together from the network—assuming some defined tolerance threshold is held.
Data availability sampling: ensure data availability without requiring nodes to hold the entire dataset; complements erasure encoding to he
lp guarantee data is available.
I.e., randomly sampled pieces of erasure-coded block data to assure the entire block is available in the network for reconstruction—else, slash nodes.
Data availability committee: a trusted set of nodes—or validators in a DA PoS network—that store full copies of data and publish onchain attestations to prove ownership.
The following section outlines common L2s and how they approach DA.
According to Avail, there are a few different approaches that L2s take to DA. Note this is in the sense of block/transaction DA and differs from the “arbitrary” / large DA approach Textile focuses on with Basin and object storage:
Post proofs (validity or fraud) onchain along with state commitments.
All data and computation, except for deposits, withdrawals, and Merkle roots, to be kept offchain.
Adaptation of Optimistic rollups that also take data availability offchain while using fraud proofs for verification.
I.e., differs from traditional rollups in that transaction data is entirely in offchain storage.
E.g., Optimism offers a “plasma mode” where data is uploaded to the DA storage layer via plain HTTP calls
Adaptation of ZK rollups that shift data availability offchain while continuing to use validity proofs.
E.g., Starknet posts a STARK validity proof and also sends a state diff, which represents the changes in the L2 state since the last validity proof was sent (updates/modifications made to the network's state).
No comments yet