Understanding the L1 Race: zkEVMs and other Common L1 Features
By: Evan Shapiro, CEO of Mina Foundation
Programmable L1 competition heated up in the last market cycle. Given the similarities over the dimensions of technical competition, it does seem like this is all driving somewhere, towards some particular L1 architecture.
Most recently, there has been a lot of talk about zkEVMs. One might look at this as just talk of Ethereum L2s exploring EVM and see this as the case — but then there are folks talking about Ethereum itself eventually using zkEVM directly. If you look at the Eth2 roadmap, you’ll see this there (ZK everything, as a to-do).
ZK isn’t the full picture, there are other things too — here’s my attempt to collect and share my viewpoint on it. I think this should have value for people trying to think about L1s generally, as well as for Mina, as we plan next steps. Note this is just a personal view of mine that I’ve sketched out as a chart relating to zkEVM and the broader L1 landscape this morning, and so while I think generally correct almost certainly has some small places for improvement.
The big table:
*Note that many of these boxes are likely up to interpretation and further discussion; I welcome any input and feedback on talking through these. There are of course also subtleties in how different teams are approaching these that are not captured by the categories mentioned. The community row in particular might be controversial, given my particular definition on the left of what I am thinking the goal should be.
It’s not all inclusive, but I believe these features represent commonalities in an ideal L1 architecture that many protocols are working towards. zkEVMs are one of them. All of these, done correctly, I believe should lead to a secure, scalable, private, (and user-owned) web.
As Mina and crypto broadly continue to push L1s, I’m particularly excited about how these different communities work together and evolve, and to continue driving Mina towards the optimal design.
