The proposal “locks in” certain assumptions e.g. exact trie format, gas schedule, transaction types, the derivation function, etc. This limits flexibility of rollup developers and very likely reduces efficiency. This is made in the name, at least partly, of removing governance (or giving it to L1). This makes sense.
What are the degrees of freedom that are left to customization for a native rollup? As Justin mentions, those are at least: Bridging and Withdrawals, Sequencing and Custom Gas Token.
In the OP, it looks like the governance is referred to something that is both undesirable and necessary, and the EXECUTE opcode can alleviate need in them. However, why don’t apply the same logic to bridging and withdrawals? If Ethereum took over that as well, then the user won’t need to consult with L2beat before interacting with a rollup. They can just interact with a rollup because they know it is as secure as the L1.
And indeed, this would be something like upgrade of the execution shards. Execution shards circa 2019 did not have the benefit of the domain knowledge we have today. For example, I believe it’s still possible to allow for custom sequencing unlike the original version of execution shards.
Another direction emerges when we consider: what if we relax the structure of the EXECUTE opcode and instead of executing an EVM environment with all those things like storage, transactions and etc, the EXECUTE will execute a program that just takes some input and produces some output.
In this case we lose the EVM equivalence, regain flexibilitiy while maintaining the other benefits of this approach.
Specifically,
-
The rollup developers will not have to reimplement the fraud proof game or SNARK. This complexity will be on the ethereum side.
-
The rollup developer will only have to implement the specific logic of their exact EVM behavior (or reuse one from the shelf). This will allow for customization of STF and of derivation rules. This should lift the concerns that @edfelten expressed. Now, it looks to me that in this world, we should really embrace RISC-V. That would allow us to reuse the common toolchains such as Rust and products like reth to simplify implementation of EVM.
-
This would avoid backing in the exact format of the trie. The program passed in the
EXECUTEwill pick it’s own trace format.
You got the idea.
I am also pretty sure that patching up the problems brought up by @thegaram33, @ihagopian and @edfelten will greatly complicate the proposal.
All in all, I want to express that this proposal picks a suboptimal point in the design space and would be better off if it either moved into direction:
- of encompassing more stuff and bringing it closer to the ideas of execution shards,
- or of encompassing less stuff and basically allowing for more innovation on rollups,