Native rollups - lev’s edition

I’ve had a pleasant discussion with Justin Drake recently. He kindly explained to me native rollups (I was getting some vibe but didn’t understand a lot of stuff before), and I guess I want to present my own view on the problem.

So, in Justin’s original exposition, native rollups are basically (Type 2) vEVM rollups that have their proving done by the block execution proposer. (I will ignore opEVM option for now).

From outside perspective, they do it using EXECUTE opcode, but it is silently relaced by proof of execution.

Few key features:

  1. DA forced to be Ethereum’s because in case of prover failure next one must be able to make a proof.
  2. Proofs need to be in theory doable on high-end common node hardware, because block execution proposers are highly centralized - so we need an escape mechanism if they decide to stall the chain.
  3. Multiple proofs are made (using different proof systems), and the job is to convince supermajority of validators. Validator clients are configured to believe particular subset of proof systems (most clients are expected to run some sort of k-of-n policy, potentially with differences in their set of proofs). Importantly, proofs are off-chain.
  4. Rollup vEVM is upgradeable with EVM. (???) - more on this later.
  5. Rollups do not have security committees, because instead we have client diversity.

So, quick rundown.

  1. Very good, we need native DA for shared security. More shared security - better for ETH as asset and Ethereum as a security mechanism.
  2. Very good, but as you will see soon, I want more.
  3. I think this is convoluted, tbh. Proofs being off-chain is not directly related to the client diversity - all clients could have the same enshrined policy of believing particular threshold of k-of-n proofs. Not directly opposed, but want to differentiate.
  4. This is wishful thinking. vEVM will always need to be audited to follow EVM. If we live in a world of RISC-V machines simulating exec clients simulating EVM, it is maybe possible, but first of all, this locks us to Type 1 vEVM, and, second this is unlikely to happen in my opinion. (plus there is a whole bag of worms with verifiable compilation pipeline)
  5. This is a good intention, but I think we are not going far enough. In current version, if there is a bug in k-of-n proof systems, it is just a consensus failure. I.e. we are forced to roll back the chain and engage in social consensus. I argue that if we ignore client diversity story (and say all clients use maximal viable set of proof systems), it is just a mainnet enforcing that in case of proof system breaks it will roll back the chain.

My version

Goal: we will instead achieve rollups that do not need to roll-back the chain and inherit it’s security. They are also somewhat more flexible w.r.t. to EVM modifications. k-of-n story is unbundled from client diversity. This is also possible in near-term, and not after the snarkification of mainnet - and can serve as a playground for future mainnet snarkification.

This is also far closer to "execution shard" story because the block execution proposer technically doesn't need to run the nodes for all the rollups. It can, but it is not forced to. Difference with execution shard is that these are still largely independent entities which can have their own bells and whistles as long as they comply to some common interface.

  1. EXECUTE is added and always represents direct (non-SNARK) evaluation.
  2. Rollup can define it’s own proof systems.
  3. If a proof of two different states is obtained, the rollup goes into “inquisitive“ mode (exact policy can be for example for each proof system that we have 2 contradicting answers we kick it, if no proof systems left or the remaining disagree, go into inquisitive mode).
  4. In inquisitive mode, the rollup keeps running by using EXECUTE opcode (i.e. it basically “falls off“ into L1).
  5. This minimal set of assumptions (only having EXECUTE and nothing else) already allows us to avoid security committees.

Technically, there is also a risk of proof system being simultaneously incomplete and unsound - i.e. not being able to make a correct state transition. However, making sure that the system is complete is a tractable problem for formal verification (need to formally validate that it is always possible to make a proof for any correct EVM state transition). Soundness bugs are far subtler and are also far more common.

There is another important distinction - in order to motivate timely proving, we need many more actors making a proof in the “default“ scenario (i.e. if only execution proposer makes a proof by default, we might not be able to challenge it in time). Ideally, this should be done by some sort of proof market (done by nodes monitoring a particular “execution shard”, aka nodes of a particular rollup) - and alternative is tolerating a 1-block mainnet rollback if this happens.

In my opinion, this achieves the same goal with much lesser involvement - we only need EXECUTE opcode, and enshrined verifiers (to distribute proofs offchain).

Separately, I think that enshrined verifiers for popular STARKs and SNARKs is a good idea anyway - this can be implemented as VERIFYk opcode which tells that there was a proof of something, but it was distributed offchain, and only outputs of the proof are present. This is also naturally in line with enshrined universal proof aggregators, i.e. block producer can actually aggregate all the proofs in a single block.

There is no need to worry about the need of picking winners - just pick STARKs and SNARKs for most popular fields, and let the rollup wrap their specific proof system in their favorite target.

Another curious possibility is the idea of non-full EVM equivalence (after all, we want rollups to be playground for new stuff). Techincally, rollup can both ban particular opcodes (i.e. use a subset of EVM), and can also add it’s own opcodes as long as they also have a reference implementation in EVM (for the inquisitive mode).

Some of these ideas transfer also to the SNARK-ed mainnet (with the exception that instead of going inquisitive light clients will just stall until the hardfork).