Data Availability Risk Framework - call for feedback

The L2BEAT research team would like to introduce a risk framework designed to evaluate the security profile of data availability (DA) solutions. This framework extends our previous efforts in assessing the security of different L2 architectures and aims to provide a risk classification system specific to DA providers. At this stage, we invite broad community feedback to refine and enhance our framework.


Data Availability (DA) layers need to guarantee that users have access to L2 transaction data. In ZK rollups, users need to be able to access transaction data or state diffs to recreate and advance the state (e.g., for withdrawals). Additionally, in Optimistic rollups users need the data to be able to challenge a dishonest state root proposer.

To ensure that data was made available, L2 state validating bridges on the settlement layer require proof that, at some point in time, the data was publicly available on the DA layer. Should L2s publish data directly to Ethereum in the form of blobs or calldata, this requirement is inherently satisfied since all data is posted onchain, and validating bridges can access its commitment. On the other hand, if L2 chooses an external DA provider, only data commitment is posted to Ethereum (while full data is posted to that DA provider). In this case, Ethereum must be “convinced” that full data was indeed made available. This is done via a so-called DA bridge, which simply attests that some data of a given commitment was made available to the external system (so this DA bridge works as an Oracle to Ethereum).

From Ethereum’s point of view, the security assumptions of external DA providers are not only dependent on the intrinsic characteristics of the DA solution itself, but also on how well its security properties are mapped to the data attestation posted to the DA bridge on Ethereum.

The following section aims to categorize the security guarantees that DA solutions need to provide for L2s to inherit the security properties of the settlement layer.

1 - Economic Security

Economic security measures the level of trust we can place in the majority consensus, seen as the amount of funds a committee would need to burn to successfully deceive the DA bridge. It is scored as:


  • :green_circle: Green: Bribery risk is quantifiable onchain and total slashable funds > total value secured
    • Committee members hold slashable assets on a public network
  • :yellow_circle: Yellow: Bribery risk is publicly verifiable offchain (e.g., reputational risk) or total slashable funds < total value secured
    • Committee members bribery risk is publicly verifiable, but not slashable
  • :red_circle: Red: Bribery risk is not publicly verifiable or quantifiable (e.g., anon committee)

2 - Fraud Detection Mechanism

The fraud detection mechanism category measures how effectively users can protect themselves against a malicious majority of committee members, such as validators.

The issue with data availability attestations is that should data be unavailable, we cannot easily say - as an independent observer - if the missing transaction was never published by the block producer or it was published but for some reason we did not receive it. As outlined in the fisherman dilemma, a data withholding attack is not an attributable fault and no slashing mechanism can be achieved at smart contract level. Thus, there needs to be a mechanism for slashing on the DA layer to prevent a nothing-at-stake problem. In some projects, this mechanism is data availability sampling (DAS). Light clients failing to perform DAS would stop processing new block headers, forcing a halt and resolving to social consensus to slash malicious validators.

This data availability verification cannot be performed by Ethereum, which due to the passive nature of smart contracts, cannot actively sample data from external sources. Hence the risk analysis for Optimiums and Validiums needs to focus on the point of view of an offchain observer, like a lightnode, and assess its ability to detect fraud on the DA layer. It is scored as:


  • :green_circle: Green: Data withholding attacks and invalid data can be detected on the DA layer
    • DAS with block reconstruction, has erasure coding fraud proof
  • :yellow_circle: Yellow: DAS without block reconstruction, has erasure coding fraud proof
  • :red_circle: Red: No fraud detection mechanism

In the future, these levels could be expanded to include additional levels specific to DAS security, such as anonymous sampling to protect against selective share disclosure attacks. For more details, see this post on different DAS security levels.

Note that while current Proto-Danksharding (EIP-4844) does not have fraud protection mechanism against dishonest majority, future Danksharding plans to have a DAS mechanism in place allowing for efficient light clients.

3 - Attestation Security

Attestation security evaluates the robustness of the DA bridge’s ability to verify data commitments without introducing additional trust assumptions. It assesses whether the DA bridge can securely confirm that the data availability attestations are backed by the DA layer’s economic security, ensuring that the signatures from the DA layer are accurately verified and tracked on-chain. It is scored as:


  • :green_circle: Green:
    • Verifies attestations are backed by DA layer-defined economic security, committee signatures are verified and the set of signers is tracked onchain. In the case of zk-proof data commitments, the correctness and threshold of the validator signatures should be verified as part of the proof. Signature equivocation is not allowed.
    • Commitment frequency should respect DA finality and committee membership unbonding period
  • :yellow_circle: Yellow:
    • Possible signature equivocation, different set of signers (typically much smaller) than DA layer itself
  • :red_circle: Red: No bridge or no requirement satisfied

4 - Exit Window

The exit window criterion examines the upgradeability of the DA bridge, specifically focusing on the mechanisms in place for withdrawals and the time allowed for users to exit in case of an upgrade. This category considers the presence of timelocks or other security measures that ensure users have adequate time to withdraw their funds before any changes to the bridge contract are implemented. It is scored as:


  • :green_circle: Green: Immutable bridge, or upgrade timelock allowing enough time for users to exit
  • :yellow_circle: Yellow: Security council can upgrade the bridge, or an EOA with timelock
  • :red_circle: Red: Smart contract (e.g., multisig) without timelock, or an EOA can upgrade the bridge

5 - Accessibility

Accessibility measures the ease with which data can be accessed directly from the Ethereum network. This category distinguishes between DA solutions that are integrated into the Ethereum protocol (enshrined) and those that are not. It is scored as:


  • :green_circle: Green: Enshrined in the Ethereum protocol
  • :red_circle: Red: Not enshrined

It is important to note that this risk category applies only to Ethereum L2s and not Sovereign Rollups using DA Layers independently.

This risk framework is intended to guide L2 users in understanding the different DA providers risk profiles, as well as developers and researchers in enhancing the security of L2 scaling solutions. We invite the community to share their feedback to finalize this risk framework, ensuring it accurately assesses the risks of data availability solutions.


I am a developer and definitely struggle with fees that would go to DA. I am not sure where the level of fees would go in this framework.


Helpful framework and quality consistent considerations. I’m still learning about how DA functions but this was very informative and I appreciate the cognitive effort that went into its construction. Thanks for providing accessible and valuable thoughts to the wider community. :pray:


Hey Pavel, in this framework DA fees will mainly influence economic security. For instance, fluctuations in fees can affect the total value secured by the DA provider. Fee-sensitive L2s may switch providers, making it more or less likely for committee members to consider an attack. Additionally, fees impact economic security through the opportunity cost of missed income during or after an attack. Committee members risk their assets/reputation, but they also forfeit potential income if optimiums or validiums stop paying for blob space once an attack is detected.
We do recognize that fees are important for developers and users experience, DA fees will be a metric we plan to track and include as part of the DABEAT dashboard :+1:

1 Like

I’m not following the difference between green and yellow, if they both require a timelock?

Hey @musalbas , thanks for the comment, I’ll edit the Green level to be more explicit. The difference lies in who can initiate the upgrade. For the Green level, either no one (the bridge is immutable), or a security council subject to timelock can initiate the upgrade. For the Yellow, an EOA can initiate an upgrade subject to timelock, or a security council but without a timelock. For the Red, an upgrade can be mandated without a security council and without a timelock.

To specify the exit window parameters applied to the timelocks, we define the ‘exit window’ parameters similarly to the Stages framework, without considering the delay to withdraw specific to individual rollups. In particular:

Green: upgrade delay is above 30 days, except in the case of an on-chain provable bug
Yellow: upgrade delay is above 7 days, or 0 days through a security council (as defined in Stages)
Red: upgrade delay below 7 days, no security council

Although user exit cannot be guaranteed (as it also depends on individual L2 design), the goal is to give users enough time to be aware of an upgrade and try and exit the system if they choose to do so.


hey, gud read!

can you elaborate on that? as if we apply to this to Ethereum, there is like 120B at stake vs 500B of total value secured :thinking: - what do you think about total amount/volume transacted in an event horizon < amount slashable

data withholding attacks are not attributable - that said, isn’t not storing data a provable form of malicious behavior that can be slashed (at the protocol level) through proof of custody? do you think that should be taken into consideration when designing this framework?

can you elaborate on what do you mean here i.e “DA solutions that are integrated into the Ethereum protocol” - isn’t Ethereum DA the only data publication layer that is enshrined at the protocol level?

1 Like

Hey @sam-ng , thanks for the feedback.

I believe you are also counting native assets on Ethereum, while total value secured applies to Ethereum as a data availability provider to L2s. Currently reports around $41 billion value locked for Ethereum rollups, so this parameter is satisfied. The problem with using total transacted over value secured is that the former does not necessarily map to the funds at risk. In the event of a data withholding attack, it’s the value locked on the L2 that is a risk a being frozen/stolen, regardless of the activity of the chain.

Proof of custody can be a solution against the so-called lazy validator problem, slashing validators for not storing data. It helps to guarantee data is stored, but that does not mean that validators will make the data available - for that guarantee you need data availability sampling. As explained in this post, there are some ways in which proof of custody can still be beneficial, but they wouldn’t apply here as this category aims at capturing the risk of a data withholding attack. We are also still waiting for live implementations of proof of custody for DA, we will evaluate the practical implications for specific projects once they become available.

Yes that’s correct. Ethereum through calldata and blobs (proto-danksharding) is the only enshrined for now, and in the future through full Danksharding. This category aims at capturing the fact that an enshrined data layer has stronger availability guarantees than an external DA. Data availability on Ethereum is guaranteed by the fact that if there were a block with unavailable data, the full nodes would not accept it and the chain will fork it out. Instead, external DA providers need to rely on DA attestations by the validator set, thus being subject to an additional trust assumption.


I think the color for “not enshrined” should be yellow, as red is usually reserved for things that are quite unsafe, and that might not be the case here. Even better would be a different color altogether.

Other than that, this is pretty much on the money for me.

1 Like

How easy or practical will it be to switch providers? Would there be an overlap period? If yes, are the L2s designed to have an overlap and 2 service providers configured? Does the OP Stack code base allow for that?

1 Like

How easy or practical will it be to switch providers? Would there be an overlap period? If yes, are the L2s designed to have an overlap and 2 service providers configured? Does the OP Stack code base allow for that?

Hey @dsukh , the sequencer posting the txs batch would have to be modified to post data to the external DA. Also L2 nodes state derivation logic would need to be modified to be made aware that the data is posted to a different DA provider. Lastly the state validating bridge on Ethereum might need to be updated to verify data inclusion on a different DA bridge. An overlap period it’s probably not worth it due to the added costs and complexity. Usually L2s using external DA have a fallback DA provider configured, should posting the blob to the primary DA fail (see this example for a fork of op-node handling external DA with fallback to Ethereum).

thank you @norswap for your feedback and suggestion. We agree and will assign “Not Enshrined” as yellow in the scoring system.