Gwyneth smart contracts design

[Brechtpd]

Describe the feature

Core rollup smart contracts, without any fancy features for now.

Overview:

• Switch from current approach that uses smart contract storage to store the chain state to the approach that derives the state directly from L1 by running over an arbitrary number of L1 blocks
• The main rollup contract now only used for putting data onchain, not storing any chain state
• Proving is done in a separate contract, automatically supports proof aggregation

Onchain costs (completely independent of blocks now):

• Proposing (arbitrary number of blocks per L1 tx): 21k gas fixed tx cost + calldata/blob cost (+ some verification/events for now)
• Proving (arbitrary number of blocks regardless how or when they were proposed): 25k gas total (without zk) == ~20k for verification of 3 proofs (stateless, should be roughly 6k per TEE proof) + 5k for updating a single storage slot

BasedOperator/TaikoL1 changes

• proposeBlock should not store or modify any state, we don't track anything onchain. We pretty much only put data onchain. All the data we need is in the function inputs, but let's put the required data for the node also in events for now
• Remove proveBlock/verifyBlocks and related functionality. We do not prove or verify blocks anymore here.
• Remove prover bond/prover assignment, contract doesn't have to care about prover now (hopefully remains that way)
• Let's keep _isProposerPermitted for now, but in theory can also be removed.
• Maybe merge BasedOperator and TaikoL1 because they will be so small and simple

ChainProver contract

• New contract!
• This is now the main contract that will prove things, a completely independent contract from any other contracts (for now)
• Similar to the current proveBlock in that this contract will have to verify multiple proofs by calling the verifier contracts
• Everything is proven sequentially. Always.
• The contract needs to store a single value: keccak(l1_blockhash, root).
  • l1_blockhash is the L1 block up until we have proven everything.
  • root is an opaque hash for some data that the prover will need internally that may also need to be exposed onchain)
• The input into a proof: keccak(keccak(current_l1_blockhash, current_root), keccak(new_l1_blockhash, new_root))
  • keccak(current_l1_blockhash, current_root) is the value stored in the contract
  • new_l1_blockhash needs to be validated, needs to be one of the blockhashes available in the EVM through blockhash(new_l1_block_number) so we know it's a valid one.
• No forks or anything like that, so no need to keep a chain of data, if the proofs are valid the new state is simply accepted, and keccak(new_l1_blockhash, new_root) is stored in the smart contract, overwriting the old value.

Additional context

No response

[adaki2004]

All the data we need is in the function inputs, but let's put the required data for the node also in events for now.

There are currently some 3rd party partners (e.g.: ENS) which require cross-state-roots on-chain for example. Or also some data which accounting for the chain height, etc.

The contract needs to store a single value: keccak(l1_blockhash, root). l1_blockhash is the L1 block up until we have proven everything. root is an opaque hash for some data that the prover will need internally that may also need to be exposed onchain)

Where is data related to L2 stored/validated or the link between a block under proving and a block proposed (already)? Like, why l1_blockhash is needed but l2 does not appear in your description above, something does not really add up in my head 😄. or the current_root and new_root refers to L2 world state root ?

[github-actions[bot]]

This issue is stale because it has been open for 21 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale.