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:
So, quick rundown.
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.
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).