Vitalik's latest thoughts: Ethereum has fallen into path dependence; it's time to start anew from first principles.

This article represents the most thought-provoking internal reflection within the Ethereum community: If today were the first time, what would you build?

Compiled by Deep Tide TechFlow

Deep Tide Editorial: On March 6, Vitalik published a lengthy article directly pointing out the long-standing “path dependence” mindset in the Ethereum community: always making incremental improvements based on the existing ecosystem rather than reimagining the application layer from first principles. He calls on Ethereum developers to “take off their suits and ties” and approach DeFi, decentralized social, identity verification, and the intersection of AI and privacy with a bolder, more open mindset.

The full text is as follows:

I believe that we in the Ethereum world should maintain a bolder, more open mindset on many issues—especially regarding the application layer and how we perceive our position in the world.

Core attributes are non-negotiable: censorship resistance, open source, privacy, security (CROPS). We should not distort “openness” into a state where people have no clarity on what security properties the Layer 1 will retain after a year. We should not ask ourselves questions like “Do we really need lightweight clients to verify chain correctness trustlessly?” But especially at the application layer and at the interface between Ethereum and the outside world, we should be more willing to fundamentally rethink concepts and step out of our comfort zones.

This includes technical directions, such as: “What if AI development essentially means that browser plugins and mobile wallets will disappear within a year—what then?”

A year ago, an example was a shift in mindset—viewing privacy as equally important as other security attributes. This implies a completely different Ethereum application stack, since so far, the entire tech stack has not been built around privacy. So, let’s build a radically different Ethereum application stack!

An example from this year is the increasing work on network-layer privacy, both inside and outside the Ethereum Foundation.

This also includes application-layer questions, such as: “What if the rest of DeFi is basically a general futures market built on high-quality decentralized oracles, allowing users to self-organize on top of it?” and “What if the ideal decentralized oracle simply verifies M-of-N SNARK proofs of data from several mainstream news sites, using small LLMs over zk-TLS data?”

(By the way, this is interconnected with AI topics: one consequence of AI is that it shifts “applications” from discrete UI-based behaviors to a continuous space. Therefore, the pattern of “building fewer applications and relying on user self-organization” will inevitably expand as a paradigm.)

Another example from this year is rethinking the role of L2 from scratch—what kind of L2 truly maximizes synergy and gains with Ethereum.

This also involves cultural aspects. This is a key reason why I, @AyaMiyagotchi, and others are deeply connected to the “milady thing.” Yes, it’s a silly meme. Yes, I find some of the political views of milady supporters awkward, sometimes even outright sycophantic (though there are others who oppose this). But the core underlying message—the “information behind the information”—is: take off your suit and tie. If you’re wearing a suit and tie, be willing to pick up the nearest glass of wine and splash it on your tie, leaving you no choice but to tear it off and regain your full bodily flexibility and freedom. Next time you’re invited to a formal dinner full of wealthy people, really imagine doing that. Write down the preconception of “being a decent person,” crumple it up, and burn it. This psychological cleansing will lead to an intellectual awakening—unlocking greater creativity and expanding the boundaries of possibility.

For too long, our algorithm in Ethereum has been: we have this existing ecosystem, what’s the next step to make it a little better? Now, our algorithm should be: we have this excellent Layer 1 that will become even more excellent, and a set of increasingly rich tools—both built within our ecosystem and from outside—so, with everything we have today, what is the most valuable thing to do?

If you were to write the chapter on applications in the Ethereum white paper of 2014, starting from first principles and thinking about what truly matters in DeFi, decentralized social, identity verification, etc., what would you write? At least take this step: zero out all concerns about path dependence, pretend that the Ethereum chain’s usage today is zero, and be the first to propose or build an application—see what emerges. Even if you are the one building the current applications, do this.

This is how Ethereum becomes powerful again.

Popular comments:

@dcposch:

Zero out path dependence on “wallets” and similar—100% agree. Usage is roughly zero anyway, and many deeply ingrained product decisions are completely wrong.

Zero out path dependence on off-chain finance—100% oppose.

The truly liberating value signals for 100 million users will inevitably involve seamless integration with fiat channels and issuer assets, which is unquestionable. It doesn’t have to stop there, nor be locked into these things. It can be open source, substantively better in privacy, accessibility, and censorship resistance. But it must respect this particular path dependence—otherwise, we’re just stuck on a geek island, entertaining ourselves.

@vitalikburterin:

Yes, I completely agree. Mainstream user payment apps/wallets/agent-type products integrated with traditional finance, allowing users to deposit and withdraw, are entirely reasonable.

What I hope we shed is mainly the historical path dependence of the Ethereum application/wallet ecosystem itself.

For example: if you’re just making a payment app, explore completely not exposing 0x addresses (maybe only using one-time addresses for deposits, and allowing withdrawals to others’ addresses). All payments are done within Railgun or Aztec.