Skip to main content
Version: Mainnet

Data Availability

Data availability (DA) networks are utilized by RollApp sequencers to publish BLOBs of transaction data and ISRs. When transaction data is submitted to DA networks and settled to Dymension, the sequencer commits to a state transition that is provable by external full nodes.

Data​

Unlike data storage where nodes are incentivized to store data in archive nodes, data availability networks are designed to facilitate the verification of high-throughput networks with low hardware requirements (i.e. light nodes). Data may be periodically pruned by DA network full nodes as such it is the responsibility of archival nodes to retain the transaction data.

While each DA network has different security, cost, and ecosystem features it is vital for a RollApp sequencer to choose a highly available and secure DA network that enables seemless verification of published data.

In order to do so, DA networks needs to provide with two features, inclusion and non-inclusion proofs. Inclusion proofs are necessary to prove that the data commited by a sequencer is the same data used to generate fraud-proofs by full-nodes, when the sequencer adds invalid transactions. Non-inclusion proofs are necessary to prove that the sequencer commmitted to unexisting data in the DA.

Inclusion​

Inclusion proofs are used to prove that a blob has been included and is avaliable in a specific block height and in a specific span (DA initial share position and length (or end position) for the submitted blobs in a Namespaced Merkle Tree (NMT). Any node is able to validate the avaialbility of the blob data, by validating the proofs against the specific block header.

Inclusion proofs require the following:

  • Blob data.
  • Block height.
  • Span (index and length).
  • NMT proof (proof that the blob data is part of a specific row of the matrix).
  • Merkle proof for each NMT row where the blob data is to the available DataRoot that is included in the block header.

Non-inclusion​

Data unavailability means that the sequencer claims the data is in a share that is out of the range of a blob data matrix. In that case it is necessary to submit a merkle proof of any row to the data root to Dymension for verification. Non-inclusion proof transactions include:

The sequencer commits to a DA height and span for the shares corresponding to a specific block data. To prove the rollup block data is unavailable it is necessary to check that the span is out of bounds. To this end, when a full node submits a non-availability proof, Dymension checks the Merkle proof of the row/column submitted with the data root it holds for the specific DA height, and calculates the size of the DA matrix using the total value of the Merkle proof. Then, it can use that information to check if the provided share span, is out of the square size bounds.

In case the span is out of the square size, it means the data is not available and the sequencer could be slashed. Full-nodes can detect data is not available in the DA and send non-inclusion proof to be validated by Dymension

Non-inclusion proofs include the following:

  • Block height: Block height that is not available in DA.
  • DA height: DA block height that is supposed to hold the blob.
  • Row proof: Used to proof that the span specified by DA is not correct.