Optimistic rollups (ORs) rely on a censorship resistance assumption of the L1 for security. This is because fraud proofs occur within the chain, not the client itself. It is technically possible for an actor with enough stake securing the L1 to censor blocks that contain fraud proofs. L1s, in order to remain neutral, will hard fork censoring validators out of their validator set in order to remain neutral and allow a rollup fraud proof to make it into the chain.

Dankrad Feist on Warpcast

I don't have an answer. But look at optimistic rollups with a typically 7 day fraud proof window. Current expectation is that in the face of a censorship attack, Ethereum could fix this and fork in that time span to recover. Requiring that an EIP needs "x week community consideration" seems wrong in this light.

This begs the question: what exactly will we, the Ethereum community, fork for?

ORs seem to have made this decision for us, it seems. There are a couple different assumptions.

Fuel v1 is the only OR that has gone this route that I could find. In single round fraud proofs, challengers send a single transaction that invalidates a claim to the rollup's state.

In this case, the answer to our question is simple. If the optimistic rollup has a challenge period of n days, the rollup has Ethereum security if we will hard fork Ethereum within n days to make sure a fraud proof is not censored. Contiguous censorship is relatively straightforward to verify. One can tell that a transaction with a reasonable gas price is not getting included for days and see that all blocks that include the transaction are being forked out of the blockchain.

However, socially agreeing upon the validators that need to be forked out of the chain takes time. This is why rollups have their famous 7 day challenge period.

Contrary to the tweet, it makes absolutely no sense to believe that the Ethereum community can coordinate hard fork out censoring validators within 8 hours (as the tweet suggests).

Optimism, Arbitrum, and the rest all use a different system: interactive fraud proofs. Essentially, claimers and challengers play an interactive game where they both make moves back and forth and, like a chess clock, each of them get to spend a total of m days on all of their moves. When the time on the clock expires, one of them is proven wrong.

So, what's the censorship assumption here? Well, it's much trickier. The assumption is that Ethereum will hard fork before a fraud proof is "chess clock censored" for m days within a 2m day period. It's unclear how this can be detected. What if every time an alarm was raised, the party claiming to be censored's transaction was included in a block? Would we tell the validators that we believe to be censoring to include particular transactions in their blocks and add them to the "fork out" list if they did not include them?

We, the Ethereum community, should ask optimistic rollups to describe exactly under what conditions they are assuming we should fork the chain in order for their safety and come to solution we can agree upon.

One clear result from the above analysis is that an m day "chess clock censorship" assumption is stronger than a m day "contiguous censorship" assumption. So, rollups with single round fraud proofs can have a challenge period half as long as those of interactive fraud proofs.

Taking an example, Optimism seems to be propose their fraud proofs will have a "chess clock censorship" assumption where each entity has 3.5 days, with no push back from the Ethereum community:

One case which they are assuming Ethereum will fork for is if the challenger is censored for 3.5 days straight (their entire response time). However, this is the same assumption being made by rollups with a single round fraud proof with a challenge period of 3.5 days. So a rollup with a single round fraud proof that must be submitted within 3.5 days is making a weaker assumption than Optimism. This means that L2 state can be finalized on L1 in half the time so funds can be bridged back to the L1 in 3.5 days as opposed to 7!

In the fantastic Inside Arbitrum Nitro doc, the Arbitrum team makes the case for interactive fraud proofs:

These are essentially all refuted by ZK fraud proofs based on general zkVMs like Risc0.

Countering the above points:

1. More efficient in the optimistic case: With ZK fraud proofs, the rate of claims can still be low.

2. More efficient in the pessimistic case: With ZK fraud proofs, the fraud proofs will be the cost of a ZK proof and only a single transaction. This is much more efficient than an interactive fraud proof.

3. Higher per-tx gas limit: Again, since you're proving within the zkVM, there are no artificial limits to computation imposed by the EVM

4. More implementation flexibility: With zkVMs that prove riscV or other ISAs directly, there is literally a super low barrier to coding up your own SNARK to verify any STF written in Rust and other languages

One thing I should point out is that, if the rate of claims made (L1 footprint in the optimistic case) is low, it will take ZK proofs take much longer to generate. This is because a single ZK fraud proof needs to prove the execution of all of the transactions between 2 claims in order to prove the latter claim wrong. However, this is not a huge concern for 2 reasons:

1. If a rollup makes a state claim for every 10 seconds worth of execution, and we assume a ZK proof will take 1000x as long as raw execution, this will simply add 2.8 hours to the fraud proof period in order to account for the time it takes to make a ZK fraud proof.

2. Data availability is going to be made very cheap (especially using alternative DA layers), so the rate of claims can be cranked up with minimal additional cost.

Finally, interactive fraud proof rollups are subject to delay attacks which require complexity like BOLD to solve. Instead, I believe that the contained complexity of a zkVM is much more preferable.

Ok, I'm done.

Optimistic rollups (ORs) rely on a censorship resistance assumption of the L1 for security. This is because fraud proofs occur within the chain, not the client itself. It is technically possible for an actor with enough stake securing the L1 to censor blocks that contain fraud proofs. L1s, in order to remain neutral, will hard fork censoring validators out of their validator set in order to remain neutral and allow a rollup fraud proof to make it into the chain.

Dankrad Feist on Warpcast

I don't have an answer. But look at optimistic rollups with a typically 7 day fraud proof window. Current expectation is that in the face of a censorship attack, Ethereum could fix this and fork in that time span to recover. Requiring that an EIP needs "x week community consideration" seems wrong in this light.

This begs the question: what exactly will we, the Ethereum community, fork for?

ORs seem to have made this decision for us, it seems. There are a couple different assumptions.

Fuel v1 is the only OR that has gone this route that I could find. In single round fraud proofs, challengers send a single transaction that invalidates a claim to the rollup's state.

In this case, the answer to our question is simple. If the optimistic rollup has a challenge period of n days, the rollup has Ethereum security if we will hard fork Ethereum within n days to make sure a fraud proof is not censored. Contiguous censorship is relatively straightforward to verify. One can tell that a transaction with a reasonable gas price is not getting included for days and see that all blocks that include the transaction are being forked out of the blockchain.

However, socially agreeing upon the validators that need to be forked out of the chain takes time. This is why rollups have their famous 7 day challenge period.

Contrary to the tweet, it makes absolutely no sense to believe that the Ethereum community can coordinate hard fork out censoring validators within 8 hours (as the tweet suggests).

Optimism, Arbitrum, and the rest all use a different system: interactive fraud proofs. Essentially, claimers and challengers play an interactive game where they both make moves back and forth and, like a chess clock, each of them get to spend a total of m days on all of their moves. When the time on the clock expires, one of them is proven wrong.

So, what's the censorship assumption here? Well, it's much trickier. The assumption is that Ethereum will hard fork before a fraud proof is "chess clock censored" for m days within a 2m day period. It's unclear how this can be detected. What if every time an alarm was raised, the party claiming to be censored's transaction was included in a block? Would we tell the validators that we believe to be censoring to include particular transactions in their blocks and add them to the "fork out" list if they did not include them?

We, the Ethereum community, should ask optimistic rollups to describe exactly under what conditions they are assuming we should fork the chain in order for their safety and come to solution we can agree upon.

One clear result from the above analysis is that an m day "chess clock censorship" assumption is stronger than a m day "contiguous censorship" assumption. So, rollups with single round fraud proofs can have a challenge period half as long as those of interactive fraud proofs.

Taking an example, Optimism seems to be propose their fraud proofs will have a "chess clock censorship" assumption where each entity has 3.5 days, with no push back from the Ethereum community:

One case which they are assuming Ethereum will fork for is if the challenger is censored for 3.5 days straight (their entire response time). However, this is the same assumption being made by rollups with a single round fraud proof with a challenge period of 3.5 days. So a rollup with a single round fraud proof that must be submitted within 3.5 days is making a weaker assumption than Optimism. This means that L2 state can be finalized on L1 in half the time so funds can be bridged back to the L1 in 3.5 days as opposed to 7!

In the fantastic Inside Arbitrum Nitro doc, the Arbitrum team makes the case for interactive fraud proofs:

These are essentially all refuted by ZK fraud proofs based on general zkVMs like Risc0.

Countering the above points:

1. More efficient in the optimistic case: With ZK fraud proofs, the rate of claims can still be low.

2. More efficient in the pessimistic case: With ZK fraud proofs, the fraud proofs will be the cost of a ZK proof and only a single transaction. This is much more efficient than an interactive fraud proof.

3. Higher per-tx gas limit: Again, since you're proving within the zkVM, there are no artificial limits to computation imposed by the EVM

4. More implementation flexibility: With zkVMs that prove riscV or other ISAs directly, there is literally a super low barrier to coding up your own SNARK to verify any STF written in Rust and other languages

One thing I should point out is that, if the rate of claims made (L1 footprint in the optimistic case) is low, it will take ZK proofs take much longer to generate. This is because a single ZK fraud proof needs to prove the execution of all of the transactions between 2 claims in order to prove the latter claim wrong. However, this is not a huge concern for 2 reasons:

1. If a rollup makes a state claim for every 10 seconds worth of execution, and we assume a ZK proof will take 1000x as long as raw execution, this will simply add 2.8 hours to the fraud proof period in order to account for the time it takes to make a ZK fraud proof.

2. Data availability is going to be made very cheap (especially using alternative DA layers), so the rate of claims can be cranked up with minimal additional cost.

Finally, interactive fraud proof rollups are subject to delay attacks which require complexity like BOLD to solve. Instead, I believe that the contained complexity of a zkVM is much more preferable.

Ok, I'm done.