Taking a closer look at data availability policies in (Ethereum) rollups

Data availability is a critical consideration for blockchain scaling designs; rollups are the preferred scaling solution for Ethereum today because availability of data required to reconstruct the L2 state is guaranteed by the L1 network. But data availability—especially in the context of rollups—has many subtle, easy-to-miss details that are nevertheless important for security.

With “L2 summer” finally happening, and modular data availability layers moving from theory to production, educating the community on the implications of rollups’ approach to data availability for security and decentralization has become more important than ever. It is especially important for users to know how differences in where transaction data is stored determines if a rollup is “secured by Ethereum” or not.

As a contribution to this effort, I put together an article that covers the topic of data availability from first principles, discussing the (in)famous “data availability problem” in Layer 1 (L1) and Layer 2 (L2) blockchains—before exploring the different approaches rollup blockchains adopt to guarantee data availability, including publishing transaction data on Ethereum and using external data availability services.

Some other topics covered include:

  1. The relationship between economic security of a data availability layer and the security guarantees it provides to rollups using it.

  2. Drawbacks and challenges around using alternative data availability layers, rather than Ethereum, to store rollup data.

  3. Differences in approaches to storing transaction data on Ethereum (spoiler: not every “Ethereum rollup” stores state data on Ethereum the same way).

All feedback and comments are welcome. I’d also like to know what others in the community think of the movement towards alternate data availability layers, and how that impacts the future of Ethereum’s rollup-centric roadmap.

PS: Also adding some recent tweets from the L2Beat team for context on emerging issues around rollups on Ethereum integrating with modular data availability layers:

1 Like

Great article!

Curious to get your opinion on the limits of data availability—i.e., if our data availability implementation was perfect and L1 smart contracts knew everything about the L2 state at all times, would there be important things we still couldn’t do?

It seems to me that a very important thing we couldn’t do is figure out who owns what assets in the case of a full L2 shutdown.

E.g., if Arbitrum shut down and there was $6B in L1 bridges that Arbitrum controlled and Arbitrum needed to fairly distribute that $6B in (say) a week before it went out of business, what would it do?

With full knowledge of L2 state it could send all EOAs their L2 balances on the L1. But what about L2 smart contract balances? This would be billions of dollars and there is not enough information in L2 state to assign unambiguous ownership to this massive sum.

Consider a loan: suppose Alice borrows 100eth from Bob giving her bridged CryptoPunk as collateral. Alice either has to pay Bob 100eth and get the Punk back or not pay Bob back and forfeit the Punk. With six months left on the loan, the L2 shuts down. Alice doesn’t have the money to repay the loan now. What happens to the Punk?

Here’s a live example, though it’s more contrived:


What happens to the ether in this contract if Base shuts down before someone wins the contest? Or rather how does Coinbase distribute the corresponding L1 ether without changing the terms of the contest?

Does the L2 owner need to adjust the terms on all contracts in a way they find “fair”? Or else how do they determine how to distribute the bridge funds.

Given Arbitrum’s major outage of only a few weeks ago, I think it’s clear that we can say “when, not if” about a large L2 shutting down. Perhaps forced inclusion could be used to run an L2 indefinitely, but I haven’t seen that idea suggested.

Is the space’s focus on data availability missing what users will actually want in the case of a disastrous shutdown? I.e., their money back?

1 Like

Hi @middlemarch. I admit this is an interesting problem that I haven’t thought about previously. Still, I can give my two gwei: The most feasible solution I can think of is that exiting funds “fairly” will require some coordination at the social layer (as opposed to what would happen if we were purely exiting funds from the rollup’s L1 bridge).

Is it correct to assume the GuessTheMagicNumber contract is a Ponz-like contract where anyone can pay a small fee per transaction–which accrues to the contract balance–and then, if they successfully guess the “magic number”, they can withdraw all the funds in the contract (i.e., funds contributed by users who failed to guess the number currently)?

If that’s the case, a developer might say something like “send a proof you sent X ETH to the contract” and match those proofs against the transaction data posted by the sequencer to L1. It’s a convoluted solution–and assumes the developer has administrative controls–but, at least, the availability of the rollup’s transaction history on L1 should make it easier to distribute those funds in a “verifiably fair” way. Of course, this means Coinbase has to change the terms of the contest like you suggest (I assume, in a normal scenario, only the caller that guesses the number gets the full payout).

The question of what happens to Alice’s punk would likely involve a similar off-chain agreement (e.g., bridge the Punk back to L1 and keep it an escrow contract until Alice pays back 100 ETH). But maybe you have a more technical solution to the problem that can be implemented at the base layer of the rollup? I’d be interested in hearing about it.