Content pfp
Content
@
0 reply
0 recast
0 reaction

Vitalik Buterin pfp
Vitalik Buterin
@vitalik.eth
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)
35 replies
680 recasts
2846 reactions

Vitalik Buterin pfp
Vitalik Buterin
@vitalik.eth
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.
1 reply
3 recasts
45 reactions

Vitalik Buterin pfp
Vitalik Buterin
@vitalik.eth
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.
1 reply
1 recast
29 reactions

Vitalik Buterin pfp
Vitalik Buterin
@vitalik.eth
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
1 reply
1 recast
14 reactions

Vitalik Buterin pfp
Vitalik Buterin
@vitalik.eth
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.
1 reply
2 recasts
13 reactions