Vitalik: Ethereum's Necessary Transformation - L2 Scaling, Wallet Security, and Privacy.

Original Title: "The Three Transactions"

Original Author: Vitalik Buterin

Translated by: MarsBit

When Ethereum transitions from a young experimental technology to a mature technology stack that can truly bring open, global, and permissionless experiences to ordinary users, this stack needs to undergo three major technological transformations, roughly simultaneously:

L2 Extension Transformation - Everyone is migrating to rollups.

Wallet Security Transformation - Everyone is migrating to smart contract wallets.

Privacy Transformation - Ensure privacy-protected fund transfers and ensure that all other tools under development (social recovery, identity, reputation) can protect privacy.

This is the triangular relationship of ecosystem transformation. You can only choose 3 out of 3.

Without the first one, Ethereum will fail, because every transaction costs $3.75 (if we have another bull market, the price will be $82.48), and every product targeting the mass market will eventually forget the chain and adopt a centralized solution for everything.

Without a second one, Ethereum will fail, because users are unwilling to store their funds (and non-financial assets), and everyone will move to centralized exchanges.

Without a third party, Ethereum will fail, because all transactions (and POAPs, etc.) are publicly visible to anyone, which is too much of a sacrifice for privacy for many users, and everyone will move to at least some centralized solutions with hidden data.

For the aforementioned reasons, these three transitions are crucial. However, due to the need for strong coordination to address these issues, they are also challenging. Not only do we need to improve the functionality of the protocols, but in some cases, we also need to make significant fundamental changes to the way we interact with Ethereum, requiring in-depth changes to applications and wallets.

These three transformations will completely change the relationship between users and addresses

In the L2 expansion world, users will exist in many L2s. Are you a member of ExampleDAO, located on Optimism? Then you have an account on Optimism! Do you hold a CDP in the stablecoin system on ZkSync? Then you have an account on ZkSync! Have you ever tried some apps that happen to be on Kakarot? Then you have an account on Kakarot! The days when users only have one address are gone forever.

I have ETH in four places according to my Brave Wallet view. Yes, Arbitrum and Arbitrum Nova are different. Don't worry, this will become more complex over time!

The complexity of smart contract wallets has increased, making it more difficult to have the same address on L1 and various L2s. Currently, most users are using externally owned accounts, whose addresses are actually the hash of the public key used for signature verification - so there is no change between L1 and L2. However, for smart contract wallets, maintaining one address becomes more difficult. Despite a lot of work being done to try to make addresses the hash of equivalent code between networks, especially with CREATE 2 and ERC-2470 singleton factories, it is very difficult to achieve this perfectly. Some L2s (such as "type 4 ZK-EVMs") are not exactly equivalent to EVM and often use Solidity or intermediate assembly instead, preventing hash equivalence. Even if you can have hash equivalence, there are other non-intuitive consequences that arise from the possibility of changing ownership through key changes in wallets.

Privacy requires each user to have more addresses, and may even change the type of addresses we process. If the proposal for privacy addresses is widely used, each user will no longer have only a few addresses, or one address on each L2, but may have one address in each transaction. Other privacy solutions, even existing solutions such as Tornado Cash, will change the way assets are stored in different ways: many users' funds are stored in the same smart contract (and therefore in the same address). To send funds to a specific user, the user needs to rely on the privacy solution's internal address system.

As we can see, these three transformations have weakened the mental model of "one user ~= one address" in different ways, and some of these effects have fed back into the complexity of implementing the transformations. Two particular complexities are:

1. If you want to make a payment to someone, how do you obtain the information to make the payment to them?

2. If a user has stored a lot of assets in different places on different chains, how do they change their keys and recover socially?

Three Transformations Related to On-Chain Payments (and Identity)

I have coins on Scroll and I want to pay for coffee (if "I" literally means the author of this article, then "coffee" is of course a metaphor for "green tea"). You are selling me coffee, but you only accept coins on Taiko. What should I do?

There are basically two solutions:

1. Receive wallets (which may be merchants or just ordinary individuals) work hard to support each L2 and have some automatic functions for asynchronous integration of funds.

2. The recipient provides their L2 and their 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 combined: the recipient provides a list of L2s they are willing to accept, the sender's wallet calculates the payment, which may involve direct sending (if they are lucky) or bridging across L2 paths.

However, this is just an example of one of the key challenges introduced by the three transformations: simple actions like paying someone now require more than just a 20-byte address.

The transformation of smart contract wallets is fortunate that the burden on the address system is not significant, 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 that they not only send 21000 gas in transactions, but more importantly, ensure that the payment receiver of the wallet tracks ETH transfers from EOAs as well as those sent by smart contract code. Applications that rely on the assumption of unchanged ownership of addresses (such as NFTs that prohibit smart contracts from enforcing royalties) will have to find other ways to achieve their goals. Smart contract wallets will also make some things easier - in particular, if someone only receives non-ETH ERC 20 tokens, they will be able to use ERC-4337 payers to pay gas fees with that token.

On the other hand, privacy has once again raised a major challenge that we have not yet truly solved. The original Tornado Cash did not introduce these issues because it did not support internal transfers: users could only deposit and withdraw from the system. Once internal transfers are possible, users need to use the internal address scheme of the privacy system. In practice, the user's "payment information" needs to include (i) some kind of "spending public key", which is a secret commitment 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 master address, which works as follows: part of the master address is a blinded version of the sender's spending key, while the other part is the sender's encryption key (although the smallest implementation can set these two keys to be the same).

The key lesson here is that in a privacy-focused ecosystem, users will have both spending public keys and encryption public keys, and their "payment information" will need to include both types of keys. In addition to payments, there are other good reasons to expand in this direction. For example, if we want to have encrypted email based on Ethereum, users will need to publicly provide some form of encryption key. In the "EOA world," we can reuse account keys to achieve this goal, but in a secure smart contract wallet world, we may need more explicit functionality to achieve this goal. This will also help make Ethereum-based identities more compatible with non-Ethereum decentralized privacy ecosystems, with the most prominent example being PGP keys.

Three Transformations and Key Recovery

In a world where a user may have multiple addresses, the default way to implement key changes and social recovery is to have the user perform a recovery program on each address separately. This can be done with a single click: the wallet can include software to execute the recovery program on all of the user's addresses simultaneously. However, even with such a simplified user experience, naive multi-address recovery still has three problems.

The impracticality of gas costs: This goes without saying.

Counterfactual address: The address of the smart contract has not yet been published (in fact, this means that you have not sent funds from the account). As a user, you may have an infinite number of counterfactual addresses: one or more on each L2, including non-existent L2s, and a completely different set of infinite counterfactual addresses originating from the confidential address scheme.

Privacy: If a user intentionally has many addresses to avoid linking them together, they certainly do not want all of their addresses to be publicly linked by recovering them at the same or similar times!

It is difficult to solve these problems. Fortunately, there is a rather elegant solution that performs quite well: an architecture that separates validation logic from asset holding.

Each user has a key vault contract that exists in a location (which may be the mainnet or a specific L2). Then, the user has addresses on different L2s, where the validation logic for each address points to a pointer to the key vault contract. Spending from these addresses will require a proof of entry into the key vault contract, displaying the current (or more realistically, the most recent) spending public key.

Proof can be achieved in several ways:

1. Directly read the read-only L1 access permission in L2. L2 can be modified to provide a method for them to directly read the L1 state. If the key store contract is on L1, this will mean that contracts within L2 can "freely" access the key store.

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

3. ZK-SNARKs. You can reduce data costs by using ZK-SNARKs with Merkel branches instead of the branches themselves. Off-chain aggregation techniques can be built (e.g. based on EIP-4337) to allow a single ZK-SNARK to verify all cross-chain state proofs in a block.

4. KZG commitment. An order addressing system can be introduced in L2 or schemes built on it, allowing state proofs within the 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 proving every transaction, we can implement a lighter solution that only requires a cross-L2 proof when restoring. Spending from an account will depend on a spending key, whose corresponding public key is stored in the account, but restoration will require a transaction that copies the current spending public key in the key store. 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 spending public key. This thread on the Safe forum describes how a similar architecture might work.

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

Through more work (for example, starting with this job), we can also strip away much of the complexity of ZK-SNARKs and create a simpler KZG-based solution.

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

Many secondary infrastructure needs to be updated

Using ENS is expensive. Today, in June 2023, the situation is not too bad: transaction fees are high but can still be compared to ENS domain name 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 increase in ETH price, gas fees returning to 200 gwei will raise the transaction fee for domain name registration to $104. Therefore, if we want people to truly use ENS, especially in decentralized social media applications where users demand almost free registration (ENS domain name fees are not a problem because these platforms provide subdomains for their users), we need ENS to operate on L2.

Luckily, the ENS team has already taken action and ENS is actually happening on L2! ERC-3668 (also known as the "CCIP standard"), along 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 the method of verifying L2 data proofs, and the 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. Merkle branch) of the L2 state that actually stores that particular subdomain.

实际获取证明涉及访问存储在合约中的一系列 URL，这 admittedly 感觉像是中心化，尽管我会辩称它实际上并不是：它是一个 1-of-N 信任模型（无效的证明会被 CCIP 合约的回调函数中的验证逻辑捕获，只要有一个 URL 返回有效的证明，就没有问题）。这个 URL 列表可能包含数十个 URL。

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

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

Dapps that use "Is this an EOA?" to distinguish between users and contracts (for example, 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 mechanisms. Most likely, applications will have to rely less on preventing transfers and more on technologies like Harberger taxes.

Improvements are needed for how wallets interact with spending and cryptographic keys. Currently, wallets typically use deterministic signatures to generate application-specific keys: the private key of an EOA is used to sign a standard random number (such as the hash of the application name), generating a deterministic value that cannot be generated without the private key, so it is technically secure. However, these techniques are "opaque" to wallets, preventing them from implementing user interface-level security checks. In a more mature ecosystem, signatures, encryption, and related functions need to be handled more explicitly by wallets.

Light clients (such as Helios) will have to verify L2, not just L1. Today, light clients focus on checking the validity of the L1 header (using the light client synchronization protocol), as well as verifying the Merkle branches of L1 state and transactions originating from the L1 header. Tomorrow, they will also need to verify the proof of L2 state originating from the storage root in L1 (this more advanced version will actually look at the pre-commitment of L2).

Wallets need to protect assets and data  

Nowadays, the business of wallets is to protect assets. Everything exists on the chain, and the only thing that wallets need to protect is the private key that currently protects these 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 the same: wallets are not only protecting authentication credentials, but also your data.

We saw the first sign of such a world at Zupass, which is a ZK-SNARK-based identity system used in Zuzalu. Users have a private key that they use to authenticate with the system, which can be used for basic proofs such as "prove that I am a resident of Zuzalu without revealing which one." However, other applications are also being built on top of the Zupass system, the most famous of which is the POAPs version of stamps.

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

The key feature that stamps offer over POAPs is that stamps are 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 your information. But this comes with added risk: if you lose that information, you lose your stamp.

Of course, the issue of holding data can be reduced to the issue of holding an encryption key: third parties (even chains) can hold encrypted copies of the data. This has the convenient advantage that your actions do not change the encryption key, so there is no need to interact with a system that keeps 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.

Zupass's practical solution is to encourage people to store their keys on multiple devices (such as laptops and phones), as the chances of losing all devices at the same time are small. We can go further and use secret sharing to store the keys, dividing them among multiple guardians.

This kind of social recovery through MPC is not a sufficient solution for wallets, because it means that not only the current guardians, but also the previous guardians may collude to steal your assets, which is an unacceptable high risk. However, leaking privacy is often less risky than losing assets completely. If someone has a highly privacy-sensitive use case, they can accept higher loss risks by not backing up the associated keys that need to be protected.

In order to avoid overwhelming users with a complex multi-recovery path system, a wallet that supports social recovery may need to manage both asset recovery and encryption key recovery simultaneously.

Return to identity issues

The common theme of these changes is that the concept of "address", which represents "you" with an encrypted identifier used on the chain, must undergo a thorough change. "Instructions on how to interact with me" is no longer just an ETH address; they must be in some form, a combination of multiple addresses on multiple L2s, hidden meta-addresses, encrypted keys, and other data.

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

However, this ENS-centric approach has two weaknesses:

It binds too many things with your name. Your name is not you, it is just one of your many attributes. You should be able to change your name without having to move your entire identity profile and update a bunch of records in many applications.

You cannot have a non-trusted counterfactual name. 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, which require...already having coins. ETH addresses, including smart contract addresses with CREATE 2, have this feature. ENS names do not, because if two Bobs both decide off-chain that 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 key vault contract mentioned in the front-end architecture of this article. The key vault contract can contain various information about you and how you interact with it (some of which can be off-chain through CCIP), and users can use their key vault contract as the primary identifier. However, the actual assets they receive will be stored in various different places. Key vault contracts are not bound to names, they are retroactively friendly: you can generate an address that can only be initialized by a key vault contract with certain fixed initial parameters.

Another category of solutions is related to the concept of abandoning the address-oriented approach to users, which is similar to the spirit of the Bitcoin payment protocol. One idea is to rely more on direct communication channels between senders and recipients; for example, senders can send a request link (as an explicit URL or QR code), and recipients can use the link to accept payment in the way they prefer.

Whether it's the sender or the recipient, taking action first and relying more on the wallet to generate the latest payment information in real time can reduce friction. That being said, persistent identifiers are convenient (especially when used with ENS), and in practice, the assumption of direct communication between sender and recipient is a very tricky problem, so we may see a combination of different technologies.

In all of these designs, it is crucial to maintain decentralization while being easily understandable to users. We need to ensure that users can easily access the latest views of their current assets and the information that is relevant to them. These views should rely on open tools rather than proprietary solutions. Avoiding the more complex payment infrastructure becoming an opaque "tower of abstraction" that developers find difficult to understand and adapt to new environments will require hard work. Despite the challenges, achieving Ethereum's scalability, wallet security, and privacy for ordinary users is crucial. This is not just about technical feasibility, but about actual accessibility for ordinary 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.

Original Link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia