Vitalik: To achieve large-scale adoption, Ethereum must undergo three transitions: L2, wallets, and privacy.

Vitalik believes that for Ethereum to be widely adopted, it needs to undergo three transitions: L2, wallets, and privacy.

Original text: “The Three Transitions” by Vitalik Buterin

Translated by MarsBit, MK

As Ethereum transitions from a young experimental technology to a mature technology stack that truly brings open, global, and permissionless experiences to everyday users, the stack needs to undergo three major technical transitions, roughly happening concurrently:

1. L2 scaling transition – everyone moves to rollups
2. Wallet security transition – everyone moves to smart contract wallets
3. Privacy transition – ensuring privacy-preserving fund transfers and ensuring all other tools under development (social recovery, identity, reputation) preserve privacy

• Web3 without AI has no soul. How ZKML Reshapes the Relationship Between AI and Blockchain
• Blockchain’s Ambition: Anti-Keynesianism, Public Life, and Transhumanism
• Evening Must-read | How Blockchain and Ethereum are Changing the World

These are the three corners of an ecosystem transformation triangle. You can only pick three out of three.

Without the first one, Ethereum fails, as every transaction costs $3.75 (or $82.48 if we have another bull market) and every consumer-facing product will eventually forget the chain and take centralized solutions for everything.

Without the second one, Ethereum fails, as users are unwilling to store their funds (and non-financial assets) and everyone moves to centralized exchanges.

Without the third one, Ethereum fails, as all transactions (and POAPs, etc.) are public for anyone to see, which is too high a sacrifice of privacy for many users, and everyone moves to at least somewhat centralized solutions with hidden data.

For these reasons, these three transitions are critical. But they are also challenging, as solving these problems requires strong coordination. It requires not only improving the functionality of the protocols, but also sometimes fairly fundamental changes to how we interact with Ethereum, requiring deep changes to applications and wallets.

These three transitions will fundamentally change the relationship between users and addresses

In the L2 scaling world, users will exist on many L2s. Are you a member of ExampleDAO on Optimism? Then you have an account on Optimism! Do you hold a CDP in ZkSync’s stablecoin system? Then you have an account on ZkSync! Have you tried some app that happens to be on Kakarot? Then you have an account on Kakarot! The days of users having only one address are gone.

According to my Brave Wallet view, I have ETH in four places. Yes, Arbitrum and Arbitrum Nova are different. Don’t worry, this will get more complicated over time!

The complexity of smart contract wallets makes it more difficult to have the same address across L1 and various L2s. Nowadays, most users are using externally owned accounts, whose address is actually the hash of the public key used for signature verification – so there’s no change between L1 and L2. However, for smart contract wallets, keeping one address becomes more difficult. Despite a lot of work being done to try to make addresses hash-equivalent code across networks, particularly CREATE2 and ERC-2470 Singleton Factory, it is very difficult to perfectly achieve this. Some L2s (such as “type 4 ZK-EVMs”) are not fully equivalent to the EVM and typically use Solidity or intermediate assembly instead, preventing hash equivalence. Even if you can have hash equivalence, there are other non-intuitive consequences from wallet ownership changing through key changes.

Privacy demands that each user has more addresses, and may even change the kind of addresses we deal with. If privacy address proposals become widely used, each user would no longer have just a few addresses, or one address on each L2, but could have one address per transaction. Other privacy schemes, or even existing schemes like Tornado Cash, change how assets are stored in different ways: many users’ funds are stored in the same smart contract (and therefore at the same address). To send funds to a specific user, the user has to rely on the privacy scheme’s own internal address system.

As we’ve seen, these three transitions weaken the “one user ~= one address” mental model in different ways, and some of the effects feed back into the complexity of executing the transitions. Two particular complexities are:

1. If you want to pay someone, how do you get the information to pay them?

2. If a user stores a lot of assets in different places on different chains, how do they do key changes and social recovery?

Three Transitions and On-Chain Payments (and Identity)

I have coins on Scroll and I want to pay for coffee (if “I” literally means me, the author of this article, then “coffee” is of course a stand-in for “green tea”). You’re selling me coffee but only prepared to accept coins on Taiko. What do I do?

There are basically two solutions:

1. The receiver wallet (which could be a merchant or just a regular person) makes an effort to support every L2 and has some automatic functionality for asynchronously consolidating funds.

2. The receiver provides their L2 and address, and the sender’s wallet automatically routes the funds to the target L2 via some kind of cross-L2 bridging system.

Of course, these solutions can be combined: the receiver provides a list of L2s they are willing to accept, the sender’s wallet calculates the payment, which may involve direct sending (if they’re lucky) or a cross-L2 bridging path.

But this is just one example of the key challenges introduced by three transitions: simple behaviors like paying someone start to require more than just a 20-byte address.

The transition to smart contract wallets is lucky in that it doesn’t burden the address system too much, but there are still some technical issues that need to be addressed in other parts of the application stack. Wallets need to be updated to ensure they’re not just sending 21000 gas in a transaction, but more importantly, to ensure that the wallet’s payment receiver tracks ETH transfers from EOAs as well as ETH sent by smart contract code. Applications that rely on the assumption of address ownership remaining constant (e.g., NFTs that prohibit smart contracts from imposing royalties) will have to find other ways to achieve their goals. Smart contract wallets will also make some things easier—specifically, if someone only accepts non-ETH ERC20 tokens, they will be able to use ERC-4337 payers to pay gas fees with that token.

On the other hand, privacy raises major challenges that we haven’t really solved yet. The original Tornado Cash didn’t introduce these issues, because it didn’t support internal transfers: users could only deposit into the system and withdraw. Once you can do internal transfers, users need to use an internal address scheme for the privacy system. In practice, the user’s “payment information” needs to include (i) some kind of “spending public key,” a blinded version of the recipient’s address that the recipient can use to spend, and (ii) a way for the sender to send encrypted information that only the recipient can decrypt, to help the recipient discover the payment.

The privacy address protocol relies on the concept of a meta-address, which works as follows: part of the meta-address is a blinded version of the sender’s spending key, and the other part is the sender’s encryption key (although the smallest implementation could set these two keys to be the same).

The key lesson here is that in a privacy-focused ecosystem, users will have spending keys and encryption keys, and a user’s “payment information” will need to include both. There are other good reasons to extend in this direction beyond payments as well. For example, if we want Ethereum-based encrypted email, users will need to publicly provide some form of encryption key. In an “EOA world” we can reuse account keys to achieve this, but in a secure smart contract wallet world, we may want more explicit functionality to achieve this. This would also help make Ethereum-based identities more compatible with non-Ethereum decentralized privacy ecosystems, the most prominent example being PGP keys.

Three Transitions and Key Recovery

In a world where a user may have multiple addresses, the default way of achieving key changes and social recovery is to have users go through a recovery process for each individual address. This can be done with one click: the wallet can include software that executes the recovery process on all of a user’s addresses simultaneously. However, even with this user experience simplification, naive multi-address recovery has three issues:

1. Unrealistic gas costs: This goes without saying.
2. Counterfactual addresses: Addresses that have not yet had their smart contract published (in effect, this means that you have not yet sent funds from that account). As a user, you may have an infinite number of counterfactual addresses: one or more on each L2, including L2s that don’t yet exist, and a completely different infinite set of counterfactual addresses that arise from stealth address schemes.
3. Privacy: If users deliberately have many addresses to avoid linking them together, they certainly don’t want to publicly link all of their addresses by recovering them at the same time or close to the same time!

Solving these problems is difficult. Fortunately, there is a fairly elegant solution that performs quite well: an architecture that separates verification logic from asset holding.

Each user has a keyring contract, which exists in one location (perhaps on the mainnet or on a specific L2). The user then has addresses on different L2s, each of which has verification logic that points to the keyring contract. Spending from these addresses will require a proof that enters the keyring contract, showing the current (or more practically, most recent) spending public key.

Proofs can be achieved in several ways:

1. Directly read-only L1 access permissions in L2. L2 can be modified to give them a way to directly read the L1 state. If the key library contract is on L1, this would mean contracts within L2 can “freely” access the key library.

2. Merkel branching. Merkel branching can prove the L1 state to L2, or the L2 state to L1, or you can combine the two to prove part of an L2 state is given to another L2. The main weakness of Merkel proof is the high gas cost due to proof length: a proof can require 5kB, although this will be reduced to less than 1kB in the future due to Verkle trees.

3. ZK-SNARKs. You can reduce the data cost by using ZK-SNARK with Merkle branch instead of the branch itself. Chain-offline aggregation technology (such as based on EIP-4337) can be built to allow a single ZK-SNARK to verify all cross-chain state proofs in a block.

4. KZG commitment. L2 or schemes built on it can introduce a sequential addressing system that allows state proofs within this system to be only 48 bytes long. Like ZK-SNARKs, a multi-proof scheme can merge all these proofs into a single proof for each block.

If we want to avoid doing a proof for every transaction, we can implement a lighter-weight scheme that only requires a cross-L2 proof upon recovery. Spending from an account will depend on an expenditure key, whose corresponding public key is stored in that account, but recovery will require a transaction that copies the current expenditure public key stored in the key library. Funds in a counterfactual address are safe even if your old key is compromised: “activating” a counterfactual address to turn it into a working contract will require a cross-L2 proof that copies the current expenditure public key. This thread on the Safe forum describes how a similar architecture might work.

To add privacy to such a scheme, we just need to encrypt the pointers and then do all the proofs in ZK-SNARKs:

With more work (e.g. building on this work), we can also peel away much of the complexity of ZK-SNARKs and make a simpler KZG-based scheme.

These schemes may become complex. However, there are many potential synergies between these schemes. For example, the concept of a “keyring contract” could also be a solution to the “address” challenge mentioned in the previous section: if we want users to have persistent addresses that don’t change when they update their keys, we can put the secret meta-address, encryption key, and other information into a keyring contract and use the address of the keyring contract as the user’s “address.”

Many Layer 2 Infrastructures Need Updating

Using ENS is expensive. Today, in June 2023, the situation is not too bad: while transaction fees are high, they are still comparable to ENS domain fees. Registering zuzalu.eth cost me about $27, of which $11 was transaction fees. But if we have another bull market, fees will skyrocket. Even without an ETH price increase, gas returning to 200 gwei will raise the transaction fee for domain registration to $104. Therefore, if we want people to actually use ENS, especially in use cases like decentralized social media where users demand nearly free registration (ENS domain fees are not a problem because these platforms provide subdomains to their users), we need ENS to run on L2.

Fortunately, the ENS team has already started taking action, and ENS on L2 is actually happening! ERC-3668 (also known as the “CCIP standard”), together with ENSIP-10, provides a way to automatically verify ENS subdomains on any L2. The CCIP standard requires setting up a smart contract that describes how to validate L2 data proofs, and a domain (e.g., Optinames uses ecc.eth) can be placed under the control of such a contract. Once the CCIP contract controls ecc.eth on L1, accessing some subdomain.ecc.eth will automatically involve looking up and verifying the proof (e.g., a Merkle branch) of L2 state that actually stores that particular subdomain.

Actually obtaining the proof involves accessing a series of URLs stored in the contract, which admittedly feels centralized, although I would argue that it actually isn’t: it’s a 1-of-N trust model (invalid proofs are caught by the validation logic in the CCIP contract’s callback function, and as long as one URL returns a valid proof, there’s no problem). This list of URLs could contain dozens of URLs.

The work of ENS CCIP is a successful example and should be seen as a sign that the kind of radical reform we need is possible. However, more reforms at the application layer are needed. Some examples include:

Many dapps rely on users to provide off-chain signatures. For externally owned accounts (EOAs), this is straightforward. ERC-1271 provides a standardized way for smart contract wallets to do this. However, many dapps still do not support ERC-1271; they need to.

Dapps that use “is this an EOA?” to differentiate between users and contracts (e.g., to prevent transfers or execute royalties) will break. Generally, I recommend not trying to find a purely technical solution; figuring out whether a specific cryptographic control transfer is a beneficial equity transfer is a difficult problem that may not be solvable without some off-chain community-driven mechanism. Most likely, the application will have to rely less on blocking transfers and more on technologies like Harberger taxes.

How wallets interact with spending and cryptographic keys will need to be improved. Currently, wallets typically use deterministic signatures to generate application-specific keys: signing a standard random number (e.g., a hash of the application name) with the EOA’s private key generates a deterministic value that cannot be generated without the private key, so it is technically secure. However, these technologies are “opaque” to wallets, preventing them from implementing user-interface-level security checks. In a more mature ecosystem, signing, encryption, and related functions need to be handled more explicitly by wallets.

Light clients (e.g., Helios) will have to verify L2, not just L1. Today, light clients focus on checking the validity of L1 headers (using the light client synchronization protocol) and verifying the Merkle branches of L1 states and transactions sourced from L1 headers. Tomorrow, they will also need to verify proofs of L2 state sourced from the state root stored in L1 (this more advanced version will actually look at L2 precommits).

Wallets need to protect assets and data

Today, the wallet’s business is to protect assets. Everything exists on-chain, and the only thing the wallet needs to protect is the private key that currently protects those assets. If you change the key, you can safely publish your previous private key on the internet the next day. However, in a world of zero-knowledge proofs, the situation is no longer like this: the wallet is not only protecting authentication credentials, but also your data.

We saw the first signs of a world like this at ZuBlockingss, the ZK-SNARK based identity system used in Zuzalu. Users have a private key they use to authenticate with the system, which can be used for basic proofs like “prove I’m a resident of Zuzalu, but don’t reveal which one.” But the ZuBlockingss system is also starting to have other applications built on top of it, the most famous of which is stamps (the POAPs version of ZuBlockingss).

One of my many ZuBlockingss stamps, proving that I’m a proud member of Team Cat.

Stamps offer a key feature that POAPs don’t: they’re private. You hold the data locally, and only prove the stamp (or some computation on the stamp) to them when you want them to have that information. But this adds risk: if you lose that data, you lose your stamp.

Of course, the issue of holding data can be reduced to holding an encryption key: third parties (or even the chain) can hold encrypted copies of the data. This has a convenient advantage that your actions don’t change the encryption key, so you don’t need to interact with a system keeping your encryption key secure. But even so, if you lose your encryption key, you lose everything. Conversely, if someone sees your encryption key, they can see everything encrypted by that key.

ZuBlockingss’ actual solution is to encourage people to store their keys on multiple devices (e.g. laptop and phone), since the chance of losing all devices at once is small. We can go further and use secret sharing to store the key, splitting the key among multiple guardians.

This social recovery through MPC isn’t a sufficient solution for wallets, since it means not only the current guardians but also previous guardians could collude to steal your assets, which is an unacceptable high risk. However, leaking privacy is often a smaller risk than losing assets entirely, and if someone has a high privacy protection use case, they may accept a higher loss risk by not backing up the associated keys for privacy-protecting actions.

To avoid overwhelming users with a complex multi-recovery-path system, wallets that support social recovery may need to manage both asset recovery and encryption key recovery simultaneously.

Back to Identity

A common theme among these changes is that the concept of the “address” representing “you” through an encrypted identifier used on-chain must undergo a radical transformation. “How to interact with me” is no longer just an ETH address; they must be included in some form of combination of multiple addresses on multiple L2s, a hidden meta-address, encryption keys, and other data.

One way to achieve this is to make ENS your identity: your ENS record can contain all this information, and if you send bob.eth (or bob.ecc.eth, or…), they can look up and learn everything about how to pay and interact with you, including in more complex cross-domain and privacy-preserving ways.

However, this ENS-centric approach has two weaknesses:

• It binds too many things to your name. Your name is not you, your name is just one of your many attributes. You should be able to change your name without having to move your entire identity configuration profile and update a bunch of records in many apps.
• You cannot have untrusted pseudonyms. One key UX feature of any blockchain is the ability to send coins to someone who has not yet interacted with the chain. Without this feature, there is a chicken-and-egg problem: interacting with the chain requires paying transaction fees, and paying fees requires…already having coins. ETH addresses, including smart contract addresses with CREATE2, have this feature. ENS names do not, because if two Bobs both off-chain decide they are bob.ecc.eth, there is no way to choose which one gets that name.

One possible solution is to put more things into the keyring contract mentioned earlier in this article’s architecture. Keyring contracts can contain various information about you and how to interact with you (some of which can be off-chain via CCIP), and users can use their keyring contract as their primary identifier. But the actual assets they receive will be stored in various different places. Keyring contracts are not bound to names, they are pseudonym-friendly: you can generate an address initialized with a keyring contract that can only be owned by someone with certain fixed initial parameters.

Another category of solutions is related to giving up the user-facing concept of addresses, similar to the spirit of the Bitcoin payment protocol. One idea is to rely more on direct communication channels between sender and receiver; for example, the sender can send a claim link (as an explicit URL or QR code), and the receiver can accept the payment however they wish using that link.

Whether initiated by the sender or receiver, relying more on wallets to directly and instantly generate the latest payment information can reduce friction. That said, persistent identifiers are convenient (especially with ENS), and in practice, the assumption of direct communication between sender and receiver is a very thorny issue, so we may see a combination of different technologies.

In all of these designs, maintaining decentralization while remaining easily understandable to users is critical. We need to ensure that users can easily access the latest view of their current assets, as well as information published to them. These views should rely on open tools, rather than proprietary solutions. Avoiding more complex payment infrastructure becoming an opaque “abstraction tower” that is difficult for developers to understand what is happening and adapt to new environments will require concerted effort. Despite the challenges, achieving Ethereum scalability, wallet security, and privacy for regular users is crucial. This is not only about technical feasibility, but actual accessibility for regular users. We need to rise to this challenge.

Special thanks to Dan Finlay, Karl Floersch, David Hoffman, and the Scroll and SoulWallet teams for their feedback, review, and suggestions.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!