Source: Vitalik, Ethereum founder; Compiled by: Jinse Finance
I've been following the various reactions to my comments about L2 about a day and a half ago.
I think one point is very important: "Building another EVM chain and then adding an optimistic bridge to Ethereum with a one-week delay" is, for infrastructure, equivalent to repeatedly forking Compound for governance—we've been doing it for too long, too much, because we've become too comfortable, resulting in stifling our imagination and leading us into a dead end.
If you build an EVM chain without an optimistic bridge to Ethereum (i.e., another Alt L1), that's even worse. We don't need any more copy-and-paste EVM chains, much less any more L1. Ethereum L1 is scaling, which will bring a lot of EVM block space—not infinite (especially since AI applications require both more block space and lower latency, which even a significantly scaled L1 cannot fully satisfy), but still a lot. Please build something that truly brings something new. I've given a few examples: privacy-focused, application-specific high-efficiency, ultra-low latency, but my list is certainly far from complete. I think the second point is also important: regarding "connections to Ethereum," the vibes must match the substance. Personally, I really like a lot of things that can be called "app chains." For example, I think the optimal architecture for prediction markets is probably something like this: the market is issued and settled on L1, user accounts are on L1, but transactions happen on some rollup or other L2-like system that reads L1 to verify signatures and the market. I like architectures that prioritize deep connectivity with L1 rather than post-hoc fixes ("We're basically a standalone chain, but oh yeah, we have a bridge, and then, okay, we send one or two developers to make it stage 1, and the L2beat people will give us a green checkmark, and Vitalik will like us"). Another extreme is the "application chain," such as persuading a government registry, social media platform, or gaming project to put their database's Merkle root along with STARK proofs (proving that each update is authorized, signed, and executed according to a pre-committed algorithm) on-chain. This is also perfectly reasonable—and in my opinion, it's the most suitable form for so-called "institutional L2." It's clearly not Ethereum, not trust-neutral, not trustless—operators can say at any time, "We're switching to another version now, with different rules." But it enables verifiable algorithmic transparency, a feature many of us hope to see in government, social media algorithms, or elsewhere, and could potentially make previously impossible economic activities possible. I think: If you're the former (deeply connected), then calling yourself an Ethereum application is reasonable and great—it's technically inseparable from Ethereum and maximizes interoperability and composability with other Ethereum applications. If you are the latter, then you are not Ethereum, but you are: (i) bringing more algorithmic transparency and trust minimization to humanity, so you are pursuing a similar vision; (ii) depending on the specific implementation, it is likely to be synergistic with Ethereum. So you should state these facts directly! In summary: Do something that truly brings new value. The atmosphere should match the substance—the degree of connection to Ethereum that you emphasize in your public image should reflect the actual degree of connection your product has with Ethereum in reality.
Alex
Kikyo
Hui Xin
Brian