Insight: What is a proposal

[norswap]

A proposal consists of:

1. An epoch number (1).
2. Hash of the deposit block starting the epoch. This is necessary to deal with
   L1 chain re-orgs.
3. Some proposed Merkle roots
   • state root after the execution of the epoch
   • logs root for every block in the epoch (or single logs root for the whole
     epoch??)
   • more?
4. Hash of parent proposal (to verify that the timestamp is properly monotonic)

(1) An epoch number is an L1 block number — TBD either the block number of the
L1 block from which the deposit block is generated, or the number of that
block + the sequencing window.

[ben-chain]

Adding some comments here to clarify my mental model, I would break this down a bit differently, so that a proposal consists of:

1. An epoch number.
2. Proposed output of the fraud proof program for that epoch. (ultimately a 32 byte hash -- your sub-points are accurate here, but keeping as a single hash gives maximal separation of concerns in making the dispute game)
3. Hash of parent proposal (to access pre-state -- for example, verifying timestamp monotonicity relative to previous epoch outputs, or to get storage slots for an SLOAD in a new epoch)

Additionally, the propose function where a proposal is submitted should accept an additional argument which commits to any blockhash AFTER the epoch. This is used to prevent deep reorgs from causing an incorrect proposal to be replayed on the "wrong" chain, which could otherwise allow an honest participant to accidentally be slashed. This argument is not otherwise used to check whether a proposal is fraudulent--it just makes sure that proposers only submit what they intend to.

[norswap]

Can you give some more details on that last paragraph?

My current mental model is that after a successful fraud proof, the sequencer will replay all blocks that follow the block for which there was a fraudulent proposal (let's call this "fraudulent block" for short), on top of some "new valid state" (probably the post state that the challenger commits to as being the correct post-state for the fraudulent block).

Basically, after fraud is proven, the challenger's proposal for the fraudulent block replaces the previous fraudulent proposal, and the sequencer replays everything that follows on top of that proposal.

This doesn't seem like it exposes the challenger to any risk -- assuming he did challenge the earliest fraudulent block.

This is used to prevent deep reorgs from causing an incorrect proposal to be replayed on the "wrong" chain

This confuses me, because proposals are commitments and cannot be replayed. Only blocks/tx can!

[ben-chain]

Sorry for the slow response on this!

My current mental model is that after a successful fraud proof, the sequencer will replay all blocks that follow the block for which there was a fraudulent proposal (let's call this "fraudulent block" for short), on top of some "new valid state" (probably the post state that the challenger commits to as being the correct post-state for the fraudulent block).

Naming nit--I would advise against the phrase "fraudulent block" -- the way to think about is that all honest rollup nodes should immediately generate the correct L2 blocks. It will be the role of the challenge agent to make sure that the proposals correctly reflect that single deterministic state of the L2, which is in no way affected by proposals. There is not a "new" valid state -- there is only ever one valid state based on the result of block derivation + execution, and the on-chain proposal + dispute game is there to enforce that only that state is finalized. This gives us "subjective finality" -- the second that L1 blocks are finalized, the resulting L2 state is known by all nodes immediately, even before any proposal about it is made at all. Does that make sense?

[ben-chain]

This confuses me, because proposals are commitments and cannot be replayed. Only blocks/tx can!

The case I mean to describe is: L1 has a deep reorg, and an L1 propose(...) transaction from the old L1 chain is re-included on the new L1 chain. I think this counts as a "replay", but if not, then I'm using the wrong term. Concretely, here is the situation we want to avoid:

1. L1 chain has an L2 tx with Alice->Bob
2. Proposer calls propose on L1 with new state incrementing Bob's balance according to L2 tx in step 1.
3. L1 chain has a deep reorg, now there is a different L2 tx in front of the one above, which sends all of Alice's funds to Charlie
4. The L1 propose tx from step 2. is re-applied to the new L1. Now, this is a faulty proposal, because Bob's balance isn't what should go up on L2 now.

It is also possible to solve for this by adding a large confirmation depth to the off-chain challenger/proposer agent. However, by adding a check on blockhash which is a part of the propose function, we can prevent all edge cases, because it would cause the propose function to revert in step 4.

[norswap]

Oh, I get it now!

[norswap]

ported to https://github.com/ethereum-optimism/optimistic-specs/wiki/State-Proposal