Vitalik Buterin: Ethereum's Three Technical Transitions

Original author: Ethereum founder Vitalik Buterin

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

As Ethereum transitions from a young, experimental technology to a mature tech stack capable of truly delivering an open, global, and permissionless experience to ordinary users, the stack will need to go through three major technological transitions roughly simultaneously:

• L2 expansion transition - everyone moves to rollups
• Wallet security transition - everyone moves to smart contract wallets
• Privacy Transition - Make sure that privacy-preserving money transfers are available, and make sure all other widgets in development (social recovery, identity, reputation) are privacy-preserving

Ecosystem transition triangle.

Without the first, Ethereum would fail as each transaction costs $3.75 ($82.48 if we have another bull run) and every product aimed at the mass market will inevitably forget about the chain And adopt a centralized workaround for everything.

Without the second, Ethereum would have failed as users were reluctant to store their funds (and non-financial assets) and everyone turned to centralized exchanges.

Without a third, Ethereum would fail because all transactions (and POAP, etc.) A centralized solution that hides your data to the greatest extent.

These three transitions are critical for the reasons outlined above. But they are also challenging, because addressing them properly requires close coordination. It’s not just the functionality of the protocol that needs to be improved; in some cases, the way we interact with Ethereum needs to change fundamentally, requiring profound changes to applications and wallets.

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

In an L2-extended world, users will exist on many L2s. Are you a member of ExampleDAO that relies on Optimism? Then you have an Optimism account! Do you hold CDP in the stablecoin system on ZkSync? Then you have an account on ZkSync! Have you tried some of the apps on kakarot? Then you have an account on Kakarot! Gone are the days when a user had only one address.

*According to my Brave Wallet view, I have ETH in four places. Yes, Arbitrum and Arbitrum Nova are different. Don't worry, it will get messier over time! *

Smart contract wallets add complexity and make it more difficult to have the same address in L1 and various L2s. Today, most users are using externally owned accounts whose addresses are actually hashes of the public keys used to verify signatures - so nothing changes between L1 and L2. However, with smart contract wallets, it becomes more difficult to reserve an address. While a lot of work has been done to try and make addresses a hash of code that is equivalent across networks, most notably CREATE2 and ERC-2470 singleton factories, it's been hard to make this work flawlessly. Some L2s (such as "Type 4 ZK-EVM") are not exactly equivalent to EVM, usually Solidity or intermediate assemblies are used instead to prevent hash equivalence. Even if you could have hash equivalence, the possibility of wallets changing ownership through key changes has other unintuitive consequences.

Privacy requires more addresses per user and may even change the types of addresses we are dealing with. If the stealth address proposal is widely used, instead of just a few addresses per user, or one address per L2, users might have one address per transaction. Other privacy schemes, even existing ones such as Tornado Cash, change the way assets are stored differently: many users' funds are stored in the same smart contract (and thus at the same address). To send funds to a specific user, the user will need to rely on the privacy scheme's own internal addressing system.

As we've seen, each of these three transitions weakens the "one user ~= one address" mental model in different ways, with some of these effects feeding back into the complexity of implementing the transition. Two special complication points are:

If you wanted to pay someone, how would you get information on how to pay them?

If a user has many assets across chains stored in different places, how do they perform key changes and social recovery?

Three transitions and on-chain payments (and identities)

I have coins on Scroll and I want to pay for coffee (if "I" is literally referring to me as the author of this article, then "coffee" is of course a metonym for "green tea"). You are selling me coffee, but you can only receive coins on Taiko. what to do

Basically there are two solutions:

1. The receiving wallet (which can be a merchant or a regular individual) works very hard to support each L2, with some automation for integrating funds asynchronously.
2. The payee provides their L2 and their address, and the sender's wallet automatically routes the funds to the destination L2 via some inter-L2 bridging system.

Of course, these solutions can be combined: the recipient provides a list of L2s they are willing to accept, and the sender's wallet figures out the payment, which may involve a direct send, or a bridged path across the L2 if they are lucky.

But this is just one example of a key challenge these three transitions present: simple operations like paying someone start requiring more information than just a 20-byte address.

Fortunately, the transition to smart contract wallets will not overburden the addressing system, but there are still some technical issues to be ironed out in other parts of the application stack. Wallets will need to be updated to make sure they don't just send 21000 gas with the transaction, and it's more important to make sure the payment receiving end of the wallet not only tracks the ETH transfer from the EOA, but also tracks the ETH sent by the smart contract code. Applications that rely on the assumption of immutable ownership of addresses (e.g. NFTs that prohibit smart contracts to enforce royalty fees) will have to find other ways to achieve their goals. Smart contract wallets will also make things easier - notably, if someone only receives a non-ETH ERC20 token, they will be able to use that token to pay for gas using ERC-4337 paymasters.

Privacy, on the other hand, again poses a grand challenge that we haven't really tackled yet. The original Tornado Cash didn't introduce any of these problems because it didn't support internal transfers: users could only deposit into the system and withdraw from it. However, once internal transfers are possible, users will need to use the privacy system's internal addressing scheme. In practice, a user's "payment message" needs to contain (i) some kind of "spend key", a promise of a secret that the recipient can use to spend, and (ii) some way for the sender to send the cryptocurrency only Information that the payee can decipher to help the payee discover the payment.

The stealth address protocol relies on the concept of a meta address, which works in this way: 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 minimal implementations can set both keys are the same).

Schematic diagram of an abstract stealth address scheme based on encryption and ZK-SNARKs.

A key lesson here is that in a privacy-friendly ecosystem, users will have both consumption public keys and encryption public keys, and the user's "payment information" must include both keys. Beyond payments, there are good reasons to expand in this direction. For example, if we want encrypted emails based on Ethereum, users will need to publicly provide some kind of encryption key. In the "EOA world" we could reuse account keys for this, but in the world of secure smart contract wallets we should probably provide a more explicit function for this. This also helps make Ethereum-based identities more compatible with non-Ethereum decentralized privacy ecosystems, especially PGP keys.

Three transitions and key recovery

The default way to implement critical changes and social recovery in a world where each user has multiple addresses is to simply have the user run the recovery process on each address separately. This can be done with one click: wallets can contain software that can perform recovery procedures on all of a user's addresses simultaneously. However, even with this simplification of the user experience, there are three problems with simple multi-address recovery:

1. Gas cost is impractical: This one is self-explanatory.
2. Counterfactual addresses: Addresses that the smart contract has not yet issued (actually, this means accounts that you have not yet sent funds from). As a user, you may have an infinite number of counterfactual addresses: one or more addresses on each L2, including L2s that do not yet exist, and another infinite set of counterfactual addresses resulting from the stealth address scheme.
3. Privacy: If a user intentionally has multiple addresses to avoid linking them to each other, they certainly don't want to publicly link them all by restoring them at or around the same time!

Solving these problems is difficult. Fortunately, there is an elegant solution that performs reasonably well: an architecture that separates validation logic from asset holding.

Each user has a keystore contract, which exists in one location (could be the mainnet or a specific L2). Users then have addresses on different L2s, where the validation logic for each address is a pointer to the keystore contract. Spending from these addresses requires proof of entry into the keystore contract showing the current (or, more realistically, most recent) spending public key.

Proof can be achieved in several ways:

• Direct read-only L1 access in L2. L2 can be modified to read the L1 state directly. If the keystore contract is on L1, this means that contracts within L2 have "free" access to the keystore
• Merkel branch. Merkle branches can attest L1 state to L2, or L2 state to L1, or you can combine the two to attest partial state of one L2 to another L2. The main weakness of Merkle proofs is the high gas cost due to the proof length: a proof may require 5 kB, but this will be reduced to < 1 kB in the future thanks to Verkle trees.
• ZK-SNARKs. You can reduce data costs by using ZK-SNARKs of Merkle forks instead of the forks themselves. Off-chain aggregation techniques can be built (eg, on top of EIP-4337) to have a ZK-SNARK verify all cross-chain state proofs in a block.
• KZG Promise. L2, or schemes built on top of them, can introduce a sequential addressing system, allowing state proofs within that system to be only 48 bytes long. Like ZK-SNARKs, multiple proof schemes can combine all these proofs into a single proof for each block.

If we want to avoid making a proof for every transaction, we can implement a lighter scheme that only requires one cross-L2 proof to recover. Spending from an account will depend on a spending key whose corresponding public key is stored in the account, but recovery will require a transaction to copy the current spending public key in the keystore. Funds in counterfactual addresses are safe even if your old keys are not: "activating" a counterfactual address to turn it into a working contract requires a cross L2 proof to duplicate the current spending_pubkey. This thread on the Safe forums describes how a similar architecture works.

To add privacy to such a scheme, we simply encrypt this pointer, and then we do all proofs in ZK-SNARKs:

With more work (eg, using this work as a starting point), we can also remove most of the complexity of ZK-SNARKs and make a simpler KZG-based scheme.

These scenarios can get complicated. On the plus side, there are many potential synergies between them. For example, the concept of "keystore contracts" can also solve the "address" challenge mentioned in the previous section: if we want users to have permanent addresses that don't change every time the user rekeys, we can put the hidden meta Addresses, encryption keys and other information are put into the keystore contract, and the address of the keystore contract is used as the user's "address".

A lot of secondary infrastructure needs to be upgraded

Using ENS is expensive. Today, in June 2023, things are not so bad: transaction fees are high, but still comparable to ENS domain fees. Registering with zuzalu.eth cost me about $27, of which $11 was transaction fees. But if we have another bull market, fees will skyrocket. Even without the ETH price increase, moving gas fees back to 200 gwei would raise the tx fee for domain registrations to $104. So if we want people to actually use ENS, especially for use cases like decentralized social media where users demand almost free registration (and ENS domain fees are not an issue since these platforms provide their users with subdomains), we need ENS at L2 to work.

Fortunately, the ENS team stepped up and ENS on L2 is happening! ERC-3668 (aka "CCIP standard"), together with ENSIP-10, provides a way to make ENS subdomains on any L2 automatically verifiable. The CCIP standard requires the creation of a smart contract that describes a method of verifying proofs of L2 data, and that domains (e.g. Optinames use ecc.eth) can be brought under the control of such a contract. Once the CCIP contract takes control of ecc.eth on L1, accessing some subdomain.ecc.eth will automatically involve finding and verifying the state proof (eg Merkle branch) in L2 where that particular subdomain is actually stored.

Actually getting the proofs involves a list of URLs stored in the contract, which sure feels like centralized, but I think it's not actually: it's a 1-of-N trust model (invalid proofs are caught by verification logic in the CCIP contract callback function, as long as one of the URLs returns a valid proof, that's fine). The list of URLs may contain dozens.

The ENS CCIP effort is a success story, and it should be seen as a sign that the kind of radical reform we need is actually possible. But there are still many application layer reforms that need to be done. A few examples:

• Many dapps rely on users to provide off-chain signatures. With an Externally Owned Account (EOA), it's easy. ERC-1271 provides a standardized way for smart contract wallets to do this. However, many dapps still don't support ERC-1271; they will need to.
• Dapps that use "Is this EOA?" to differentiate users and contracts (eg, prevent transfers or enforce royalty fees) will break. In general, I'd advise against looking for purely technical solutions here; figuring out whether a particular transfer of cryptographic control is a transfer of beneficial ownership is a difficult problem that may not be solved without addressing some off-chain community-driven mechanisms. Most likely, apps will have to rely less on diversion prevention and more on techniques like Harberger taxes.
• Must improve how wallets interact with payouts and encryption keys. Currently, wallets typically use deterministic signatures to generate application-specific keys: signing a standard nonce (such as 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 safe in a purely technical sense. However, these techniques are "opaque" to wallets, preventing wallets from implementing user interface level security checks. In more mature ecosystems, signing, encryption, and related functions will have to be handled more explicitly by wallets.
• Light clients (such as Helios) will have to authenticate L2 and not just L1. Today, light clients focus on checking the validity of L1 headers (using the light client sync protocol), and verifying Merkle forks of L1 state and transactions rooted in L1 headers. Tomorrow, they also need to verify the proof of L2 state, which is rooted in the state root stored in L1 (the more advanced version actually looks at the L2 pre-confirmation).

Wallets will need to protect assets and data

Today, wallets are in the business of protecting assets. Everything is on-chain, and the only thing the wallet needs to protect is the private keys that currently secure these assets. If you change your key, you can safely publish your previous private key on the Internet the next day. However, in the ZK world, this is no longer true: the wallet not only protects the authentication credentials, it also holds your data.

We saw the first signs of such a world with Zupass, the ZK-SNARK based identity system used by Zuzalu. The user has a private key for authenticating to the system, which can be used to make basic proofs such as "prove that I am a resident of Zuzalu without revealing which one". But the Zupass system also started building other applications on top of it, most notably stamp (Zupass' version of POAP).

One of my many Zupass stamps confirming that I am a proud member of Team Cat.

The key feature that stamps offer compared to POAP is that stamps are private: you keep data locally, and if you want someone to have information about you, you just have to prove a stamp (or some computation on a stamp) to someone . But that adds risk: if you lose that information, you lose the stamp.

Of course, the problem of holding data can be reduced to the problem of holding a single encryption key: some third party (or even chain) can hold an encrypted copy of the data. This has the convenient advantage that the action you take doesn't change the encryption key, so no interaction with the system that keeps your encryption key safe is required. But even then, if you lose your encryption key, you lose everything. On the other hand, if someone sees your encryption key, they can see everything encrypted with that key.

Zupass' practical solution is to encourage people to store their keys on multiple devices (such as a laptop and a phone), since the chances of them losing access to all of them at the same time is slim. We can go a step further and use a secret share to store keys, distributed among multiple guardians.

This social recovery via MPC is not an adequate solution for wallets, as it means that not only current guardians but also previous guardians could collude to steal your assets, which is an unacceptably high risk. But the risk of a privacy breach is usually lower than the total asset loss risk, and people with high privacy use cases can always accept a higher risk of loss by not backing up the keys associated with these privacy demanding operations.

To avoid users being overwhelmed by Byzantine systems with multiple recovery paths, wallets that support social recovery may need to manage both asset recovery and encryption key recovery.

Back to identity

One of the things these changes have in common is that the concept of an "address," the cryptographic identifier you use to represent "you" on-chain, has to fundamentally change. "Instructions on how to interact with me" will no longer be just an ETH address; they must be some combination of multiple addresses on multiple L2s, stealth meta addresses, encryption keys, and other data in some form.

One way is to make ENS your identity: your ENS record can just contain all this information, and if you send someone bob.eth (or bob.ecc.eth, or...), they can look up And see everything about how it pays and interacts with you, including more complex cross-domain and privacy-preserving methods.

But this ENS-centric approach has two weaknesses:

• It associates too many things with your domain name. Your domain name is not you, your domain name is one of many attributes of you. It should be possible to change your domain name without moving your entire identity profile and updating a whole bunch of records in many applications.
• You cannot have untrusted counterfactual corn. A key UX feature of any blockchain is the ability to send coins to people who have not yet interacted with the chain. Without such functionality, there is a catch- 22: interacting with the chain requires payment of transaction fees, which requires... already having coins. ETH addresses, including smart contract addresses with CREATE2, have this functionality. ENS names will not, because if two Bobs both decide they are bob.ecc.eth off-chain, there is no way to choose which of them gets the name.

One possible solution is to put more content into the keystore contract mentioned in the architecture earlier in this article. The keystore contract can contain all kinds of information about you and how you interact with it (for CCIP, some of this information may be off-chain), and users will use their keystore contract as their primary identifier. But the actual assets they receive will be stored in a variety of different places. Keystore contracts are name-agnostic, and they are counterfactual friendly: you can generate an address that can be proven to only be initialized by a keystore contract with some fixed initial parameters.

Another type of solution is similar to the Bitcoin payment protocol, completely abandoning the concept of user-oriented addresses. One idea is to rely more on direct communication channels between sender and recipient; for example, the sender could send a claim link (as an explicit URL or QR code) that the recipient could use to follow the their willingness to accept payment.

Regardless of whether the sender or receiver moves first, relying more on wallets to directly generate up-to-date payment information in real-time reduces friction. That said, persistent identifiers are convenient (especially with ENS), whereas the assumption of direct communication between sender and receiver is a very tricky one in practice, so we may end up seeing a combination of different technologies.

In all these designs, making things both discrete and easy for users to understand is the most important. We need to make sure users have easy access to the latest view of what their current assets are and what news is published for them. These perspectives should rely on open tools, not proprietary solutions. Keeping a more complex payment infrastructure from becoming an opaque "tower of abstraction" where developers have a hard time understanding what's going on and adapting it to the new environment will take hard work. Despite the challenges, achieving scalability, wallet security, and privacy for ordinary users is critical to the future of Ethereum. It's not just about technical feasibility, it's about actual accessibility for the average user. We need to rise to this challenge.