Vitalik: The Ethereum ecosystem needs three technological transformations

Author: Vitalik, founder of Ethereum; Translation: Jinse Finance cryptonaitive

As Ethereum evolves from a young, experimental technology to a mature technology stack capable of delivering an open, global, and permissionless experience to ordinary users, there are three major technological transitions that need to happen simultaneously:

• The first is the transformation of L2 capacity expansion - everyone turns to Rollup technology;
• Second is Wallet Security Transformation - Everyone starts to use smart contract wallets;
• The third is privacy transformation - ensuring privacy-preserving funds transfer functionality is available, and ensuring that all other tools being developed (social recovery, identity verification, reputation, etc.) have privacy-preserving features.

*Ethereum Ecosystem Transformation Triangle. You can only choose all three. *

Without the first item, Ethereum will fail because each transaction costs $3.75 ($82.48 if we go through another bull run), and every mass market product will inevitably drop the on-chain Trade and adopt a centralized solution.

Without the second item, Ethereum would fail as users would be unwilling to store their funds (and non-financial assets) and everyone would turn to centralized exchanges.

Without the third item, Ethereum would fail because for many users, all transactions (and POAP etc) would be publicly visible, the sacrifice of privacy would be too great and everyone would turn to at least some level of hidden data Centralized solution.

For the reasons outlined above, these three transitions are critical. But they are also challenging due to the complexity of the coordination involved. 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 and profoundly, requiring major changes in applications and wallets.

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

In a world of L2 scaling, users will exist on multiple L2 networks. Are you a member of ExampleDAO? ExampleDAO is on Optimism. Then you have an account with Optimism! Do you hold a CDP of a stablecoin system on ZkSync? Then you have an account on ZkSync! Have you ever tried some of the apps located on Kakarot? Then you have an account on Kakarot! Gone are the days when users only had one address.

*My Brave wallet view, I hold Ethereum in four places. Yes, Arbitrum and Arbitrum Nova are different. Don't worry, things will get more complicated over time! *

**Smart contract wallets add more complexity as it makes it more difficult to have the same address on L1 and various L2 networks. **Most users today use externally owned accounts whose addresses are actually hashes of the public keys used to verify signatures - so nothing changes between L1 and L2. However, maintaining an address becomes more difficult when using a smart contract wallet. While a lot of work has been done to try and make addresses a hash of code that is equivalent across different networks, the most important being CREATE2 and the ERC-2470 singleton factory, it is difficult to achieve this perfectly. Some L2 networks (e.g., "ZK-EVM of the fourth type") are not exactly equivalent to EVMs, often using Solidity or intermediate assembly language rather than hash equivalents. Even if hash equivalence could be achieved, the possibility of wallets changing ownership through key changes leads to other less predictable consequences.

**Privacy requires more addresses per user and may even change the types of addresses we handle. **If the stealth address proposal is widely used, users may have one address per transaction instead of just a few addresses per user or one address per L2 network. Other privacy schemes, even existing ones like Tornado Cash, change the way assets are stored in different ways: many users' funds are stored in the same smart contract (and thus on 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 have seen, these three transformations weaken the "one user ≈ one address" mental model in different ways, some of which effects in turn increase the complexity of executing these transformations. Two of the particularly complex issues are:

**1. If you want to pay someone, how will you get the payment information? **

**2. If users store assets in different locations on different chains, how do they perform key changes and social recovery? **

These three transformations and on-chain payments (and identity)

I hold tokens on Scroll, and I want to use them to buy coffee (if the literal "I" refers to Vitalik, the author of this article, then "coffee" of course means "green tea"). You sell coffee on Taiko, but you only accept tokens on Taiko. what to do?

Basically there are two solutions:

1. The receiving wallet (which can be a merchant or an ordinary individual) strives to support each L2 and has some asynchronous fund merging functions.

2. The payee provides their L2 information next to the address, and the sender's wallet automatically routes the funds to the target L2 through some kind of cross-L2 bridging system.

Of course, these solutions can be used in combination: the payee provides the L2 list they are willing to accept, and the sender's wallet determines the payment method, which can be sent directly (with luck), or paid via a bridged path across the L2.

But this is just one example of a key challenge introduced by the three transformations: Simple payment behaviors start to require more information than just a 20-byte address.

Fortunately, moving to smart contract wallets is not a huge burden on the address system, but there are still some technical issues that need to be resolved in other parts of the application stack. Wallets need to be updated to ensure that they are not only sending 21000 gas when sending transactions, but more attention needs to be paid to ensuring that the receiving end of the wallet tracks not only ETH transfers from the EOA, but also ETH transfers from the smart contract code. Applications that rely on immutable ownership of addresses (e.g. NFTs that prohibit smart contracts to enforce royalties) will have to find other ways to achieve their goals. Smart contract wallets will also make some things easier, especially if someone only accepts non-ETH ERC20 tokens, they will be able to use an ERC-4337 paymaster to pay for gas using that token.

On the other hand, the issue of privacy is again a big challenge that we haven't really solved yet. The original Tornado Cash did not introduce these problems because it did not support internal transfers: users could only deposit and withdraw money into the system. However, once internal transfers are possible, users will need to use the privacy system's internal addressing scheme. In practice, the user's "payment message" will need to contain (i) some kind of "spend public key", a secret commitment that the receiver can use to spend, and (ii) the sender can send encrypted messages that only the receiver can decrypt The help recipient discovers the method of payment.

The Stealth address protocol relies on the concept of a meta-address, which works as follows: part of the meta-address is the sender's hoodwinked spending key, and the other part is the sender's encrypted key (although a minimal implementation could set both keys to be the same).

An overview of abstract stealth address schemes based on encryption and ZK-SNARKs

A key lesson here is that **in a privacy-friendly ecosystem, users will have spending public keys and encryption public keys, and users' "payment information" will need to include both keys. **Besides paying, there are other good reasons to expand 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, but in the world of secure smart contract wallets we should probably provide more explicit functionality for this. This also helps make Ethereum-based identities more compatible with non-Ethereum decentralized privacy ecosystems, especially PGP keys.

These three transitions and key recovery

In a world where each user has multiple addresses, the default way to implement key changes and social recovery is to have users run the recovery process on each address individually. This can be done with one click: the wallet can provide a software function to perform the recovery process simultaneously on all addresses of the user. However, even with this simplification of the user experience, there are three problems with multi-address recovery:

1. Gas cost is unrealistic: This is self-evident.

2. Counterfactual addresses: addresses that have not yet issued a smart contract (actually, this will mean accounts from which you have not yet sent funds). As a user, you may have an infinite number of virtual addresses: one or more on each L2, including L2s that do not yet exist, and a whole infinite set of virtual addresses arising from the stealth address scheme.

3. Privacy: If a user intentionally uses multiple addresses to avoid associating them with each other, then they certainly don't want to publicly associate all of them by restoring them at or near the same time!

Solving these problems is difficult. Fortunately, there is a rather elegant solution that works quite well: This architecture separates validation logic from asset holding.

Every user has a keystore contract which exists in one location (could be mainnet or a specific L2). Then, users have addresses on different L2s, and the verification logic for each address is a pointer to the keystore contract. Spending funds from these addresses will require providing a proof of a current (or more realistically, very recent) spend public key for the funds.

This proof can be achieved in several ways:

• ** Read-only access to L1 directly inside L2. ** L2 can be modified to enable it to read L1 state directly. If the keystore contract is on L1, it means that contracts in L2 have "free" access to the keystore.
• **Merkle branches. **Merkle branches can prove L1 state to L2, or L2 state to L1, or a combination of both can prove partial state of one L2 to another L2. The main weakness of Merkle proofs is the high gas cost due to the proof length, which may require a proof length of 5kB, but due to the use of Verkle trees, this will be reduced to <1kB in the future.
• **ZK-SNARKs. **You can reduce data costs by using ZK-SNARKs of Merkle branches instead of using branches themselves. Off-chain aggregation techniques (e.g. on top of EIP-4337) can be built to enable a single ZK-SNARK to verify all cross-chain state proofs in a block.
• **KZG Promise. **Whether it is L2 or the scheme built on it, a sequential addressing system can be introduced, allowing the state proof inside the system to be only 48 bytes. Like ZK-SNARKs, multi-proof schemes can combine all these proofs into a single proof for each block.

If we want to avoid needing a proof for every transaction, we can implement a more lightweight scheme that only requires recovery across L2 proofs. Spending from an account would depend on a spend key with its corresponding public key stored inside the account, but recovery would require a transaction to copy the current spend public key into the keystore. Even if your old keys are not secure, the funds in the virtual address are safe: "activating" the virtual address to turn it into a usable contract will require a cross-L2 proof to replicate the current spend public key. There is a thread on the Safe forums that describes how a similar architecture works.

To add privacy to such a scheme, we only need to encrypt pointers and do all proofs inside ZK-SNARKs:

With further work (e.g. using this work as a starting point), we can also strip ZK -Most of the complexity of SNARKs, building a more simplified KZG-based scheme.

These scenarios can get complicated. The upside is that there are many potential synergies between them. For example, the concept of a "keystore contract" can also be a solution to the "address" mentioned in the previous section: if we want users to have a persistent address that doesn't change every time the user updates the key, we can put the stealth The meta address, encryption key, 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 updated

Using ENS is expensive. Although it is not as expensive as before in June 2023, the transaction fee for registering a domain name is still relatively high, which is comparable to the cost of an ENS domain name. For example, it costs about $27 to register with zuzalu.eth, $11 of which is transaction fees. But if the market turns bullish again, fees will soar. Even if the ETH price does not increase, if the gas fee returns to 200 gwei, the transaction fee for the domain name registration will reach $104. So if we want people to actually use ENS, especially for use cases like decentralized social media, where users are asking for almost free registration (ENS domain fees aren't an issue since these platforms can provide users with subdomains), we need ENS is used on Layer 2.

Fortunately, the ENS team has already stepped up and ENS is being implemented on Layer 2! ERC-3668 (also known as the "CCIP standard") and ENSIP-10 provide a way to automatically verify ENS subdomains on any Layer 2. The CCIP standard requires setting up a smart contract that describes the method for verifying proofs of data on Layer 2, and a domain name (eg, ecc.eth for Optinames) can be placed under the control of such a contract. Once the CCIP contract controls ecc.eth on L1, accessing a certain subdomain.ecc.eth will automatically find and verify a proof storing the Layer 2 state of that specific subdomain (e.g., a Merkle branch).

actually obtaining these proofs involves accessing a list of URLs stored in the contract, although this is in Somehow it might look like centralization, but I'd say it's actually not: it's a 1-to-N trust model (invalid proofs are caught by the validation logic in the CCIP contract callback function, as long as one of the A URL that returns valid proof is fine). The URL list may contain dozens of URLs.

**ENS's CCIP effort is a success story and should be seen as a sign that the radical reforms we need are actually possible. ** But there are still many application-level reforms that need to be done. Here are some examples:

• **Many DApps rely on users to provide off-chain signatures. **For External Accounts (EOA), it's easy. ERC-1271 provides a standardized way to do this for smart contract wallets. However, many DApps still do not support ERC-1271 and they need to be adapted.
• ** DApps that use "is this an EOA?" to differentiate between users and contracts (e.g. to prevent transfers or enforce royalties) will have problems. **In general, I would advise against trying to find a purely technical solution here; determining whether a particular transfer of cryptographic control is a beneficial ownership transfer is a difficult problem that may not be resolved without resorting to some off-chain community-driven mechanisms solve. Most likely, applications will rely less on technical means of blocking transfers and more on techniques like the Harberger tax.
• **Wallet interaction with payouts and encryption keys will need improvement. **Currently, wallets typically use deterministic signatures to generate application-specific keys: signing a standard nonce (e.g. a hash of the application name) with the EOA's private key will generate a deterministic value unless the private key is in possession , otherwise the value cannot be generated and is therefore purely technically safe. However, these techniques are "opaque" to the wallet, preventing wallets from implementing user interface level security checks. In a more mature ecosystem, signing, encryption, and related functions will need to be handled more explicitly by wallets.
• Light clients (such as Helios) will need to authenticate Layer 2 instead of just Layer 1**. **Currently, the light client is focused on checking the validity of the L1 block header information (using the light client synchronization protocol), and verifying the Merkle branch of the L1 state and transactions based on the L1 block header information. In the future, they will also need to verify proofs of the L2 state rooted at the state root stored in L1 (more advanced versions will actually look at the L2 pre-confirmation).

Wallets will need to protect assets and data

Currently, the mission of the wallet is to protect assets. Everything is stored on-chain, all the wallet needs to protect are the private keys currently securing these assets. If you change the key, you can safely post the previous private key publicly on the Internet the next day. However, in a zero-knowledge world, this is no longer the case: wallets don’t just protect authentication credentials, they also hold your data.

We see the first signs of such a world at Zuzalu with Zupass, a ZK-SNARK based identity system. The user has a private key that is used to authenticate into the system, which can be used to generate basic proofs such as "prove that I am a resident of Zuzalu without revealing which resident I am". The Zupass system also started building other applications on top of it, most importantly stamps (Zupass' version of POAP).

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

The key feature of stamps relative to POAP is that they are private: you keep data locally, and only prove a stamp to their ZK (or perform some computation on stamps) if you wish to give that information to someone. But this also comes with an additional risk: if you lose that information, you will lose your stamps.

Of course, the problem of holding data can be reduced to the problem of holding a single encryption key: a third party (even on-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 holding the encryption key is required. But even then, if you lose the encryption key, you lose all your data. And, in turn, if someone sees your encryption key, they will be able to 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 are slim. We can take it a step further by using key sharing to split the key storage among multiple protectors.

Social recovery via MPC is not an adequate solution for wallets, as it means that not only the current protector, but also previous protectors could collude to steal your assets, which is an unacceptably high risk. While a privacy breach is usually less risky than a complete loss of assets, for use cases with high privacy needs, a higher risk of loss can be accepted by not backing up the keys associated with those privacy needs.

To avoid bogging users down in a complex system of multiple recovery paths, wallets that support social recovery may need to manage both aspects of asset recovery and encryption key recovery.

Back to identity

A common theme among these changes is that the concept of an "address" as a representation of identity on the blockchain will need to change fundamentally. ** "Instructions on how to interact with me" will no longer be just an ETH address; express. **

One of these ways is to use ENS as your identity: your ENS record can contain all the information on how to pay and interact with you, if you send someone bob.eth (or bob.ecc.eth etc.), they can Inquire and learn about everything that interacts with you, including in more complex ways across domains and with privacy protection.

However, this ENS-centric approach suffers from two weaknesses:

• **It associates too much content with your name. **Your name does not mean everything about you, it is just one of many attributes about you. It should be possible to change your name without migrating your entire identity profile and updating records in many applications.
• **You cannot have counterfactual names that do not require trust. **A key user experience feature of any blockchain is the ability to send tokens to people who have not yet interacted with the chain. Without such functionality, there is a dilemma: interacting with the chain requires paying transaction fees, and paying transaction fees requires... already owning tokens. ETH addresses, including smart contract addresses with CREATE2, have this functionality. ENS names do not, because if both Bobs decide off-chain that they are bob.ecc.eth, there is no way to choose which Bob gets the name.

One possible solution is to put more content into the keystore contract mentioned earlier in the architecture of this article. A keystore contract can contain various information about you and interactions with you (and with CCIP, some of this information can be off-chain), users will use their keystore contract as their primary identifier. However, the assets they actually receive will be stored in a variety of different places. Keystore contracts are name-agnostic and virtual-name-friendly: you can generate an address that can only be initialized by a keystore contract with certain fixed initial parameters.

Another class of solutions involves abandoning the notion of user-facing addresses entirely, similar to Bitcoin's payment protocol. One idea is to rely more on direct communication channels between the sender and receiver; for example, the sender could send a request link (as an explicit URL or QR code), which the receiver could use to send any request they wish way to accept payment.

Whether it's the sender or receiver who acts first, relying more on wallets to generate up-to-date payment information in real-time reduces friction. However, persistent identifiers are convenient (especially with ENS), whereas in practice relying on direct communication between sender and receiver is a very tricky problem, so a combination of different techniques may be seen.

In all of these designs, it is critical to remain decentralized and understandable to users. We need to ensure that users can easily access an up-to-date view of their current assets and messages targeted to them. These views should rely on open tools rather than proprietary solutions. It will take hard work to keep the greater complexity of payment infrastructure from becoming an opaque "tower of abstraction" that is difficult to understand and adapt to new environments. Despite the challenges, achieving Ethereum's scalability, wallet security, and privacy for ordinary users is paramount. It's not just about technical feasibility, it's about actual accessibility to the average user. We need to meet this challenge.