Understanding Rollups

General
1

Hi all, I’ve been trying to grok rollup architecture under the hood and struggling to answer a few questions. I know there’s a lot of contentious debate on twitter lately as to what specifically defines a rollup, so forgive me if I am misstating certain properties, and please correct me where my intuition goes wrong

I want to focus on “classic” smart contract rollups that settle to Ethereum, a la Arbitrum and Optimism

From a high level this Arbitrum contract on L1 seems to perform 4 major functions:

  1. Warehouses L2 TXs
  2. Archives L2 state roots
  3. Operates a bidirectional bridge that allows ETH L1 native assets to move in/out of the L2 environment
  4. Serves as the arbitration agent for fraud disputes

The major question I have is around the last component.

to clarify :

-The L1 “warehouses” these TXs, but has no comprehension as to what these transactions mean.
-The L2 doesn’t warehouse them (ie the L2 isnt the DA layer), but is able to look at the TXs on the L1 and derive meaning from the content embedded, execute them against the L2 state, and compute a new L2 state root

During a fraud dispute however, and from what I understand (correct me if I am wrong) the L2 falls back on the L1 smart contract to re-execute the state transition functions (or in event of a interactive fraud dispute, a micro segment of the STFs). This implies that somewhere along the road, the L1 becomes “conscious” of the L2 TXs it is storing as calldata, and is able to re-execute those transactions to determine the correct L2 state.

My question is- where and how does this L1 “consciousness” occur in the protocol?

2 Likes
2

I found a link explaining fraud proofs:

https://medium.com/offchainlabs/interactive-fraud-proofs-arbitrums-secret-sauce-debc3b019418

This does not really belong here though. You are talking about Arbitrum, Optimism, these are separate protocols. You should follow up with them.

3

A few months back I tried to answer this very same question. It turns out that fault proofs are not yet live for neither Optimism or Arbitrum.

Optimism fault proofs are called Cannon (or Cannon Cannon Cannon). More on GitHub - ethereum-optimism/cannon: On chain interactive fault prover for Ethereum.

Arbitrum fault proofs are called Bold. They said is almost ready and will have a governance proposal to enable them soon. More on GitHub - OffchainLabs/bold: Efficient, all-vs-all dispute protocol for Optimistic Rollups.

From the design I’ve seen what they are aiming to do is the following:

  1. Have these transactions on L1 (in the warehouse contract as you called it)
  2. Let a challenger single out the earliest transaction that its state root is processed incorrectly
  3. Then the challenger submits a challenge transaction with the earliest first OP code (the first CPU) instruction that is computed incorrectly
  4. Optimism compiled Ethereum (geth) to MIPS (a miminal CPU architecture) and will deploy a smart contract that executes MIPS code on chain
  5. So when there’s a faulty state root update the cost to verify the fault proof is just on OP code
  6. That MIPS execution smart contract will need access to the state of L2 (as you pointed out)
  7. The data that are required from the L2 are provided by challenger (using a technique called pre-image oracle, more on cannon/docs at master · ethereum-optimism/cannon · GitHub)

Hope this helps