Vitalik discusses three necessary changes for Ethereum to increase its popularity: L2 scalability, wallet security, and privacy.

In a recent article titled "The Three Transitions" by Ethereum founder Vitalik Buterin, he discussed the three transitions that Ethereum needs to undergo in order to achieve greater mainstream adoption. These transitions are related to L2 scalability, wallet security, and privacy.

This translation and summary are provided for reference. For any uncertainties, please refer to the original article.

The Three Transitions:https://t.co/rtewRnm2wK

— vitalik.eth (@VitalikButerin) June 9, 2023

Three Technological Shifts Needed for Ethereum to Become More Mainstream

At the beginning of the article, Vitalik clearly states that as Ethereum transitions from a young experimental technology to a mature technical stack that can provide an open, global, and permissionless experience for ordinary users, three major technological shifts need to happen simultaneously:

1. L2 Scaling Shift: Everyone migrates to rollups
2. Wallet Security Shift: Everyone switches to using smart contract wallets
3. Privacy Shift: Ensuring that privacy-protecting funds are transferable, and other developing tools such as social recovery, identity, reputation are also privacy-protecting.

If L2 scaling cannot be achieved, Ethereum will fail due to high transaction costs; if wallet security cannot be improved, users will not be willing to store funds on the chain; if privacy cannot be increased, exposing all transactions to anyone will be too high a sacrifice in terms of privacy for many users.

Vitalik believes that if any of the above shifts cannot be achieved, users will resort to seeking centralized solutions.

Three Shifts Will Drastically Change the Relationship Between Users and Addresses

In the ecosystem of L2 scaling, users' assets exist on many different L2s.

Using his own Brave wallet as an example, Vitalik's ETH exists in four different places, including the Ethereum mainnet, Arbitrum, Arbitrum Nova, and Optimism. Vitalik believes that this situation will only become more complex, especially when using smart contract wallets.

The reason why things get more complex after using smart contract wallets is that it becomes more difficult to use the same addresses across L1 and various L2s.

Currently, most users use externally owned accounts, where the address is actually the hash of the public key used for signature verification, so there is no change between L1 and L2. However, when using smart contract wallets, it is not easy to design addresses as code with equivalent hashes across different blockchain networks.

Furthermore, increasing privacy will further increase complexity. If address hiding schemes are widely adopted, each user's transaction may generate an address, rather than each user having only a few addresses or one address per L2.

As Vitalik raises these questions, these shifts are changing the psychological assumption of "one user, one address," with some effects increasing the complexity of the shifts. Two of the more complex issues that Vitalik believes are:

1. How do you obtain payment information when you want to pay someone?
2. If users store many assets in different places on different chains, how do they change keys and recover socially?

Three Shifts and On-Chain Payments and Identity

Vitalik raises a payment-related question: when a user has assets on Scroll and wants to use them for payment, but the seller only accepts assets from another L2, what should be done?

There are basically two solutions:

1. The recipient's wallet strives to support more L2s and has some cross-chain fund integration functions.
2. The recipient provides their own address, and the sender transfers assets to the target L2 through a cross-chain bridge.

This is just one of the challenges faced in the three shifts. Even solving the simplest payment problem requires more tool integration, not just relying on one address.

However, Vitalik believes that the shift to smart contract wallets is not a huge burden on the address system, but there are technical issues that need to be addressed in the app, such as ensuring that the wallet recipient not only tracks transfers from external wallets but also adjusts the amount of Gas sent in transactions.

On the other hand, privacy issues have not yet been truly resolved. Once internal transfers can be made, users will need to use internal address schemes of privacy systems. In operation, a user's "payment message" will consist of the following two parts:

1. A "Spend key" Spend key
2. The sender can send encrypted messages that only the recipient can decrypt to help the recipient discover the payment

The Stealth Address Protocol is based on the concept of meta-addresses. The operation is such that part of the meta-address is a masked version of the sender's spend key, and the other part is the sender's encrypted key.

Vitalik states that in a privacy-focused ecosystem, users will have a spend key and an encryption key, and a user's "payment message" must contain these two keys.

Three Shifts and Key Recovery

When users have multiple addresses, the default method for key changes and social recovery is to have users go through the recovery process on each address separately. This can be done with one click: as long as the wallet software can execute the recovery process on all of the user's addresses simultaneously.

However, even with this UX simplification, Vitalik believes that simple multi-address recovery still faces three problems:

1. Unrealistic cost of Gas fees: This is self-explanatory.
2. Counterfactual addresses for virtual addresses: Addresses that have not yet issued smart contracts mean that no funds have been sent from that account. As a user, you may have an infinite number of virtual addresses: including one or more addresses on each L2, and additionally, stealth address schemes will also generate more addresses.
3. Privacy: If users intentionally have multiple addresses and want to avoid them being related to each other, users definitely do not want to publicly link their addresses together with a single recovery.

To address these issues, Vitalik proposes a solution: a framework that separates verification logic from asset holding.

Each user has a keystore contract for storing keys, which can exist on the mainnet or specific L2s. When users have addresses on different L2s, the verification logic for each address points to the keystore contract.

However, to avoid generating a proof for each transaction, a simpler solution can be chosen, where only a cross-L2 proof is needed during recovery.

Spending from an account will depend on a spend key, and the corresponding public key will be stored in that account. But recovery requires a transaction to copy the current spend public key to the keystore contract.

Even if old keys are at risk, funds in virtual addresses are safe: activating a virtual address to turn it into a runnable contract requires a cross-L2 proof to copy the current spend public key.

Wallets Need to Protect Assets and Data

Today, the business of wallets is to protect assets. Everything exists on the blockchain, and the only thing wallets need to protect is the private keys that currently protect these assets. If a user changes a private key, they can safely make the previous private key public on the network the next day.

However, in the world of ZK, this no longer holds true: wallets not only protect authentication credentials but also safeguard user data.

Vitalik uses an identity system based on ZK-SNARK Zupass as an example. Users have a private key for system access and basic proof, which is also used for POAP in the Stamps Zupass version.

Compared to POAP, an important feature of Stamps is privacy. User data is kept locally, and a ZK proof is only made when someone wants information about the user, ensuring privacy. However, this also brings risks: if users lose this information, they will lose their Stamps.

Vitalik states that Zupass's solution encourages people to store their keys on multiple devices (e.g., laptops and phones) since the chances of losing all devices simultaneously are very low.

Returning to the Identity Issue

Finally, Vitalik discusses the commonality of these shifts. In the future, the concept of an "address" on the blockchain representing users will undergo fundamental changes. "How to interact with users" will no longer be just an ETH address but, in some form, will combine multiple addresses on multiple L2s, hidden meta addresses, encrypted private keys, and other data.

One approach is to use ENS as your identity. ENS can contain all this information. If you send bob.eth to someone, they can search and understand how to pay and interact with Bob, including more complex cross-domain and privacy-preserving methods.

However, using ENS has two drawbacks: it binds too much to ENS and cannot have trustless virtual domain names, as this would prevent sending assets to users who have not interacted yet.

To this, Vitalik proposes two possible solutions:

1. Store more information in the keystore contract mentioned earlier, which users can use as the primary form of identification. However, the assets the user actually receives will be stored in various places.
2. Completely abandon user-facing addresses and use payment protocols similar to Bitcoin, relying more on direct communication between sender and receiver. For example, the sender can send a withdrawal link (URL or QR Code), and the receiver can use this link to accept payment in their preferred way.

In all designs, Vitalik believes that maintaining decentralization and making users understand are crucial to avoid the payment infrastructure becoming an opaque "tower of abstraction" as complexity increases. "Despite the challenges, achieving scalability, wallet security, and general user privacy are crucial for Ethereum's future. This is not just a question of technical feasibility but actually a question of usability for the general user. We need to rise to this challenge," Vitalik said.