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.

Context

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:

Levels

  • :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:

Levels

  • :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:

Levels

  • :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:

Levels

  • :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:

Levels

  • :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.

8 Likes

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.

2 Likes

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:

3 Likes

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.

Edit:
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.

2 Likes

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 L2Beat.com 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.

2 Likes

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.

Very happy to see this effort to give clarity to builders and users about the risks and tradeoffs of different DA options.

My comments:

:yellow_circle: Yellow: Bribery risk is publicly verifiable offchain (e.g., reputational risk) or total slashable funds < total value secured

Since DA withholding is unattributable and can only be slashed via social slashing will there be a distinction made between which staked assets can actually be slashed in case of data withholding (i.e. assets native to the DA protocol)? In my view, non-native assets should not contribute to the total slashable funds.

Separately, I’m not sure it makes sense to bucket reputational risk and cryptoeconomic security together even if the slashable funds are less than the total value secured. In my mind, reputational risk is in its own category as it’s very hard to quantify and compare its value to tangible cryptoeconomic security. I’m not sure if it’s possible to represent more than 4 levels/colors of security here, but maybe reputation risk could be orange.

Maybe in addition to the rosette for this category there can be a ratio of slashable funds to value secured, since having a binary greater than or less than doesn’t quite capture the difference in risk between e.g. $1.1B in value secured by $1B in stake versus the same amount secured by $100 in stake.

: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

I am happy to see this category for fraud detection mechanisms as I think it’s important even for offchain DA security. You could even argue that ease of fraud detection contributes to greater economic security as in order to initiate social slashing for data withholding, the community needs to come to agreement on whether data was withheld or not.

And it will be cool to expand these levels in the future to include new categories like private DAS as you say when those come online.

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

I was going to ask what this means, but I see that @norswap already asked and you answered. I agree that whether DA is native to Ethereum or not is an important distinction for Ethereum users of L2s and rollups.

2 Likes

Hey @nickwh8te , thanks a lot for your feedback and suggestions.

Since DA withholding is unattributable and can only be slashed via social slashing will there be a distinction made between which staked assets can actually be slashed in case of data withholding (i.e. assets native to the DA protocol)? In my view, non-native assets should not contribute to the total slashable funds.

Yes the distiction will be made between slashable and non-slashable assets. Non-native assets that can be socially slashed will also be counted towards the total slashable assets.

Separately, I’m not sure it makes sense to bucket reputational risk and cryptoeconomic security together even if the slashable funds are less than the total value secured. In my mind, reputational risk is in its own category as it’s very hard to quantify and compare its value to tangible cryptoeconomic security. I’m not sure if it’s possible to represent more than 4 levels/colors of security here, but maybe reputation risk could be orange.

Regarding the separation of reputational risk (typical of DACs) and cryptoeconomic security, we are aiming to apply this metric to capture the risks of both economically secure networks and DACs. Currently, our criteria distinguish between the two by allowing only for DA layers with quantifiable onchain security to be marked Green, while simple DACs can only be Yellow or Red. Addressing your point (and your suggestion about the ratio), we are considering adding a minimum threshold of slashable funds to total value secured (e.g., 25-35%) to create a clearer distinction between crytoeconomic security and reputational factors. This would establish a minimum cryptoeconomic requirement for DACs to move from Red to Yellow, for instance preventing scenarios where entities like anon committees could move up in level simply by adding negligible stake.

1 Like

we are considering adding a minimum threshold of slashable funds to total value secured (e.g., 25-35%) to create a clearer distinction between crytoeconomic security and reputational factors

This sounds like a good solution.

Non-native assets that can be socially slashed will also be counted towards the total slashable assets.

How will you distinguish between non-native assets that can be socially slashed and those that cannot?

For example, say a DA protocol “D” makes the claim that they are secured with stake in the form of asset “$A” issued on an unrelated chain “A”. Now say that data withholding happens on D. Since there is no way to objectively prove to chain A that data was withheld, there is no way for chain A to programmatically slash the staked asset $A. The only way to slash $A is for chain A’s social consensus to agree to fork and slash the $A that was staked to the DA protocol. Since A is an unrelated protocol with an unrelated social contract to D, this is highly improbable if not impossible. So the $A staked to D is in practice not slashable and should not be counted towards the total slashable funds.

In practice, the only assets that are slashable for data withholding are those that are aligned with the social contract of the DA layer, which in almost all cases excludes any non-native assets. I think the only exception would be a non-native token explicitly created for staking in the DA protocol that can be socially slashed via an intersubjective mechanism (forking the token contract) like that proposed by EigenLayer.

1 Like

Hey @nickwh8te , thank you for expanding your reasoning here, and I do agree with it. Non-native asset can be considered, but they need to be explicitly bonded to social contract of the DA layer. A staked token created with that sole purpose is the best way to achieve that (as for EIGEN). For other tokens, we will have to assess the mechanism claiming to specifically address the intersubjective faults.

1 Like