You mentioned in the ETH Online talk that such enshrining would only be necessary if the winning rollup abuses its position and behaves in unfair way towards the community. I totally understand this motivation (and agree with it), but it’s very important to draw the red line very clearly when such things are mentioned. Because, obviously, a “nationalization” like this would be quite a harsh move. Alone a threat of it could undermine the idea that Ethereum is a nation where property rights are respected. Imagine, for example, that Uniswap decides to introduces fees, and since it’s a protocol with “systemic importance”, community deems UNI as “too extractive” and nationalizes it…
Agree there’s a lot of things to be careful about here, and thank you for bringing this up explicitly. It’s better to discuss such things earlier rather than later, when tens of millions of dollars will have been invested.
I’ll walk back on being “totally fine with enshrining it”; I was too quick to make that statement without thinking through the whole picture and not just the narrow technical considerations.
First of all, to be super clear I would definitely oppose “state-intervention forks” (ie. DAO-style forks) that just grab the state root of a rollup and import it into another system, stripping the token out in the process. A state-intervention fork is the only way to truly cleanly move everyone over from an L2 to an L1 “by default”, so it seems to be off the table by existing norms.
That said, there are other things that in theory could be done. One possibility is the ethereum protocol forking existing code to create a native execution capability, and inviting users to voluntarily move into that system. This would not be a violation of immutability or property rights, but it would be a gross violation of open-source politeness norms. And if the ethereum community commits not to do such a direct fork except in case of some kind of malicious exploitation of monopoly power, that could significantly boost L2 projects’ confidence in building on the ecosystem. I am inclined to also support such a commitment.
The truly tough thing though is dealing with all of the less clear possibilities. At the very least, if ethereum makes a native sharded execution capability, that would compete with all the L2s that have been made until that point, and it would have an unfair advantage. And the concept of doing that versus forking an existing protocol is not a binary, it is a spectrum. For example, if ethereum makes a native L2 execution capability using SNARKs or STARKs, that will doubtlessly use at least some open-source research and software packages that were originally built at least in part with L2s in mind.
There’s a limit to how strong a commitment we can make, because there’s also the possibility that we learn something new in 2-4 years that makes an ethereum-native sharded execution layer a really good idea and crucial to the ongoing success of the project. If we extend from 1 execution shard to 8 execution shards, where the new three execution shards have some different non-EVM language that’s designed to be ZK-provable, but where the goal is not to compete with ZK rollups, is that a problem? I think the best we can promise is to be fair to existing L2 projects and not do things that intuitively feel like pulling the rug out from under them.
A final possibility is some kind of “coin merger” with L2 projects (with their teams and token holders’ consent), but this risks being too controversial because it interferes with the goal of ETH monetary neutrality.
is coming up to you guys at work tomorrow