Data availability (DA) refers to the assurance that all data referenced in a block is actually available to network participants. A block is a fundamental data structure that contains several key pieces of information such as transaction data, state, etc. Without full data availability, nodes can't fully validate the state of the network, which can lead to security issues and potential attacks.
Data Availability Committees
Data Availability Committees (DACs) focus on data management and availability, particularly for scaling solutions. These do not apply to Arweave but L2s instead, where scalability issues do exist.
For instance, optimistic chains use DACs for managing off-chain data storage. It is important to note that Arweave as DA is not a validium, as a validium is a scaling solution that enforces integrity of transactions using validity proofs like ZK-rollups (for Ethereum).
How Arweave approaches DA
Wildfire
Wildfire is Arweave's implementation of their Adaptive Interacting Incentive Agents (AIIA) game that optimizes data availability through a peer ranking system.
Nodes rank peers based on two key factors:
- Generosity in sharing new transactions/blocks
- Responsiveness to information requests
How does this maintain high data availability? Nodes keep a list of peers and score them based on their data-sharing speed. High-scoring peers receive messages first (in parallel), while low-scoring peers receive them second (one after another). The list gets cleaned up regularly by removing poor performers, but new peers get a grace period to prove themselves.
Succinct Proofs of Random Access
Succinct Proofs of Random Access (SPoRA), is a mechanism within Arweave to make sure data gets stored and retrieved efficiently on the network.Instead of just focusing on computing power, SPoRA rewards miners who can access and retrieve data the fastest. The faster and more efficiently miners can store and fetch data, the more they earn.
This approach uses less energy than their previous system and encourages miners to actually maintain good data storage systems rather than just pooling their computing resources together.
Blockshadows
Blockshadows contain transaction IDs instead of full transactions, allowing nodes to reconstruct blocks if they already have the transactions in their mempool.
When a block is formally proposed, parts of its transaction data are already distributed across the network. This results in transactions to be included in blocks almost as quickly as they can be spread throughout the network.
Here we effectively split data availability into two phases:
- Pre-block distribution of transactions
- Block proposal using references (IDs) to already-distributed data
