Data availability (DA)
For risks associated with DA, check out https://l2beat.com/data-availability/summary, as of 28-11-2024, none (!) of the DA layers has a bridge to Ethereum for posting proofs.
"Data availability is the guarantee that the block proposers are required to publish the data for each block, which nodes participating in Ethereum's consensus store locally. This is what powers trustlessness: rather than having to trust that block producers are honest, all nodes on the Ethereum network execute the transactions to verify that the new information is valid. Data availability is one of the ways in which a L2 differs from a sidechain."
- From the EF docs (28-7-2023)
"Data availability refers to the confidence a user can have that the data required to verify a block is really available to all network participants. For full nodes on Ethereum layer 1 this is relatively simple; the full node downloads a copy of all the data in each block - the data has to be available for the downloading to be possible. A block with missing data would be discarded rather than being added to the blockchain. This is "on chain data availability" and it is a feature of monolithic blockchains. Full nodes cannot be tricked into accepting invalid transactions because they download and execute every transaction for themselves. However, for modular blockchains, layer 2 rollups and light clients, the data availability landscape is more complex, requiring some more sophisticated verification procedures. The data availability problem is the need to prove to the whole network that the summarized form of some transaction data that is being added to the blockchain really represents a set of valid transactions, but doing so without requiring all nodes to download all data. The full transaction data is necessary for independently verifying blocks, but requiring all nodes to download all transaction data is a barrier to scaling. Solutions to the data availability problem aim to provide sufficient assurances that the full transaction data was made available for verification to network participants that do not download and store the data for themselves.
Light nodes and Layer 2 rollups are important examples of network participants that require strong data availability assurances but cannot download and process transaction data for themselves. Avoiding downloading transaction data is what makes light nodes light and enables rollups to be effective scaling solutions.
Data availability is also a critical concern for future "stateless" Ethereum clients that do not need to download and store state data in order to verify blocks. The stateless clients still need to be certain that the data is available somewhere and that it has been processed correctly."
