One important difference between shards and rollups that I did not get into is *upgradeability*: shards would upgrade their EVM automatically, rollups need their own governance. But could we change that? (thread)

I made one proposal a few months ago: https://notes.ethereum.org/@vbuterin/enshrined_zk_evm

Basically, do it in a highly flexible way by putting the proof system outside of consensus and letting individual clients prove in their own way. But the more I think about it, the more that seems overly complex and brittle.

Rollups that wish to be "EVM-compatible" could point to the ZK-EVM v-keys provided by the precompile. Rollups that wish to do their own thing could stay with their own v-keys.

Potentially, rollups could even be "almost compatible": the v-keys could provide a standard interface for extending the EVM with other features

If we go "full scifi", you could make it work with arbitrary proof systems: you could provide a formal proof (eg. in coq or lean) that a new proof system is valid, and that the ZK-EVM v-key you provide for the new system corresponds to the same EVM as the existing v-keys. But that's far away.

Another benefit of this approach of focusing on specific proof systems and v-keys, is that it supports not just rollups, but also validiums and other off-chain systems, where data is potentially unavailable and so re-proving under a different system is not always possible.

It's easier if you agree on one, or N, proof systems. Then, in each hard fork, we would have to also agree on the verification key of the ZK-EVM (rough analogy: "hash of the ZK-EVM interpreter") for each proof system. We then expose those keys through a precompile.