Author: Vitalik, Ethereum founder; Translator: Blockingcryptonaitive
As Ethereum evolves from a young experimental technology to a mature technology stack that can bring open, global, and permissionless experiences to ordinary users, there are three major technical transformations that need to be carried out simultaneously:
-
The first is the L2 scaling transformation – everyone turns to Rollup technology;
-
The second is the wallet security transformation – everyone starts using smart contract wallets;
-
The third is the privacy transformation – ensuring the provision of privacy-protecting fund transfer functions, and ensuring that all other tools under development (social recovery, identity authentication, reputation, etc.) have privacy-protecting features.
Ethereum ecosystem transformation triangle. You can only choose all three.
Without the first item, Ethereum will fail because the cost of each transaction is $3.75 (if we experience another bull market, the cost will reach $82.48), and every product targeting the mass market will inevitably abandon on-chain transactions and adopt centralized solutions.
Without the second item, Ethereum will fail because users are not willing to store their funds (and non-financial assets), and everyone will turn to centralized exchanges.
Without the third item, Ethereum will fail because for many users, all transactions (such as POAP) are publicly visible, which sacrifices too much privacy, and everyone will turn to centralized solutions that hide data at least to some extent.
For the above reasons, these three transformations are crucial. However, because the coordination work involved is so complex, they are also challenging. It is not just a matter of improving the protocol’s functionality; in some cases, the way we interact with Ethereum needs to undergo fundamental changes, requiring major changes in applications and wallets.
These three transformations will fundamentally reshape the relationship between users and addresses
In the 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 on Optimism! Do you hold a CDP in a stablecoin system on ZkSync? Then you have an account on ZkSync! Have you ever tried some applications on Kakarot? Then you have an account on Kakarot! The days of users having only one address will be gone.
This is my Brave wallet view, I hold Ethereum in four places. Yes, Arbitrum and Arbitrum Nova are different. Don’t worry, it will get more complicated over time!
Smart contract wallets add more complexity, making it harder to have the same address on L1 and various L2 networks. Today, most users use externally owned accounts (EOAs), whose address is actually the hash value of the public key used for signature verification – so there is no change between L1 and L2. However, when using a smart contract wallet, keeping an address becomes more difficult. Although a lot of work has been done to try to make addresses equivalent code hashes that can be used across different networks, the CREATE2 and ERC-2470 singleton factory are the most important, perfecting this is difficult. Some L2 networks (such as the “fourth type ZK-EVM”) are not completely equivalent to EVM and typically use Solidity or intermediate assembly languages instead of hash equivalence. Even if hash equivalence can be achieved, the possibility of wallet ownership changing through key changes can lead to other unpredictable consequences.
Privacy requires that each user have more addresses, and may even change the type of address we handle. If the stealth address proposal is widely used, users may have an address for each transaction, rather than only a few addresses per user or one address per L2 network. Other privacy schemes, including existing schemes such as Tornado Cash, change the way assets are stored in different ways: many users’ funds are stored in the same smart contract (so 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 can see, these three transformations weaken the “one user ≈ one address” mental model in different ways , some of which have the opposite effect of increasing the complexity of implementing these transformations. Two particularly complex issues are:
1. How do you get payment information if you want to pay someone?
2. How do users make key changes and social recovery when they store assets in different locations on different chains?
These three transformations and on-chain payments (and identities)
I hold tokens on Scroll and want to use them to buy coffee (if the literal “I” refers to the author of this article, Vitalik, then “coffee” of course refers to “green tea”). You sell coffee on Taiko, but only accept tokens on Taiko. What to do?
There are basically two solutions:
1. Payment wallets (either merchants or individuals) make an effort to support every L2 and have some asynchronous fund consolidation features.
2. The payee provides their L2 information next to the address, and the sender’s wallet automatically routes the funds to the target L2 via some cross-L2 bridging system.
Of course, these solutions can be combined: the payee provides a list of L2s they are willing to accept, the sender’s wallet determines the payment method, and can either send directly (if lucky) or route payment through a cross-L2 bridging path.
But this is just an example of one key challenge introduced by the transition: simple payment behavior begins to require more information than just a 20-byte address.
Fortunately, transitioning to smart contract wallets is not a heavy burden for the address system, 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 when sending transactions, but also pay more attention to ensuring that the wallet receiving end tracks not only ETH transfers from EOA, but also ETH transfers from smart contract code. Applications that rely on the immutability of address ownership (e.g., NFTs that prohibit smart contracts from executing 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 ERC-4337 Blockingymaster to pay gas fees with that token.
On the other hand, privacy issues once again become a major challenge that we have not yet truly solved. The initial Tornado Cash did not introduce these issues because it did not support internal transfers: users could only deposit and withdraw from the system. However, once internal transfers are possible, users will need to use a privacy system’s internal addressing scheme. In fact, the user’s “payment information” will need to include (i) some kind of “spending public key,” 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 Stealth address protocol relies on the concept of meta-address, which works as follows: part of the meta-address is the sender’s obfuscated spending key, and the other part is the sender’s encryption key (though the simplest implementation can set these two keys to be the same).
A diagram of the abstract stealth address scheme based on encryption and ZK-SNARKs
One key takeaway here is that in a privacy-friendly ecosystem, users will have spending public keys and encryption public keys, and a “payment message” will need to include both keys. 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 sort of encryption key. In the “EOA world”, we can reuse account keys, but in the secure smart-contract wallet world, we may want to 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 achieve key changes and social recovery is to have users run the recovery process separately for each address. This can be streamlined with a click: wallets can provide software functionality that performs the recovery process on all the user’s addresses at once. However, even with such a user experience simplification, multi-address recovery has three problems:
1, Gas cost is unrealistic: This goes without saying.
2, Counterfactual addresses: Addresses for smart contracts that have not yet been released (actually, this would mean you haven’t sent funds from the account that created it). 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 whole set of infinitely many counterfactual addresses generated from a stealth address scheme.
3, Privacy: If users intentionally use multiple addresses to avoid linking them, they certainly don’t want to publicly reveal all of those addresses are linked by recovering them simultaneously or in close proximity!
Solving these problems is difficult. Fortunately, there is a fairly elegant solution that works well: this architecture separates the verification logic and asset holding .
Each user has a keystore contract that exists in one location (it can be the mainnet or a specific L2). The user then has addresses on different L2s, each with verification logic that points to the keystore contract. Spending funds from these addresses will require providing a proof that proves the current (or more realistically, very recent) spending public key for the funds.
The proof can be achieved in several ways:
-
Directly read-only access to L1 inside L2. L2 can be modified to allow direct access to L1. If the keystore contract is on L1, this means that contracts within L2 can access the keystore “for free”.
-
Merkle branches. Merkle branches can prove L1 states to L2, or L2 states to L1, or a part of an L2 to another L2. The main weakness of Merkle proofs is the high gas cost due to proof length, which can require 5kB proof length, but this will be reduced to <1kB in the future due to the use of Verkle trees.
-
ZK-SNARKs. You can reduce data costs by using ZK-SNARKs with Merkle branches instead of using the branches themselves. Chain-down aggregation technology (e.g., on EIP-4337) can be built to verify all cross-chain state proofs in a single ZK-SNARK in each block.
-
KZG commitment. Both L2 and schemes built on top of it can introduce a sequential addressing system, allowing state proofs within the system to be only 48 bytes. Like ZK-SNARKs, multi-proof schemes can merge all these proofs into a single proof for each block.
If we want to avoid having a proof for every transaction, we can implement a lighter solution that only requires cross-L2 proofs for recovery. Spending from an account will depend on a spending key, whose corresponding public key is stored inside the account, but recovery will require a transaction that copies the current spending public key to the keystore. Even if your old key is not secure, funds in a virtual address are safe: activating a virtual address to make it a usable contract will require a cross-L2 proof that copies the current spending public key. A topic on the Safe forum describes how a similar architecture works.
To add privacy to such a scheme, we only need to encrypt the pointers and perform all proofs inside ZK-SNARKs:
Through further work (e.g., starting with this work), we can also strip away most of the complexity of ZK-SNARKs and build a more simplified KZG-based scheme.
These schemes can be complex. The benefit is that there are many potential synergies between them. For example, the concept of a “keystore contract” could also be a solution for the “address” solution mentioned in the previous section: if we want users to have persistent addresses that don’t change every time they update their keys, we can put stealth elements of the address, the encrypted key, and other information into a keystore contract and use the address of the keystore contract as the user’s “address”.
Many Secondary Infrastructures Need Updating
Using ENS is expensive. As of June 2023, although not as expensive as before, the transaction fee for registering a domain name is still relatively high, comparable to the cost of an ENS domain name. For example, registering zuzalu.eth cost approximately $27, of which $11 was the transaction fee. But if the market experiences another bull run, the cost will skyrocket. Even if the ETH price does not rise, if gas fees return to 200 gwei, the transaction fee for domain name registration will reach $104. Therefore, if we want people to really use ENS, especially for use cases like decentralized social media, where users demand almost free registration (ENS domain name fees are not a problem because these platforms can provide subdomains for users), we need to use ENS on Layer 2.
Fortunately, the ENS team has already taken steps, 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 the setting of a smart contract that describes how to verify data proofs on Layer 2, and a domain name (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 a subdomain.ecc.eth will automatically look up and verify a proof (e.g., a Merkle branch) that stores the specific subdomain’s Layer 2 state.
Actually obtaining these proofs involves accessing a list of URLs stored in the contract, although this might look somewhat centralized to some extent, I would say it is not actually: it is a 1-to-N trust model (invalid proofs are caught by the validation logic in the CCIP contract’s callback function, and only one URL needs to return a valid proof). The list of URLs may contain dozens of URLs.
The CCIP effort of ENS is a successful case and should be regarded as a sign that the radical reforms we need are actually feasible. But there are still many application-level reforms that need to be made. Here are some examples:
-
Many DApps rely on users to provide off-chain signatures. For external accounts (EOA), this is easy. ERC-1271 provides a standardized way to perform this operation for smart contract wallets. However, many DApps still do not support ERC-1271 and need to be adapted.
-
Using “is this an EOA?” to differentiate between user and contract DApps (e.g., to prevent transfers or enforce royalties) will be problematic. In general, I recommend not trying to find a purely technical solution here; determining whether a particular cryptographic control transfer is beneficial for ownership transfer is a difficult problem that may not be solvable without the aid of some off-chain community-driven mechanism. Most likely, applications will rely less on technical means of preventing transfers and more on technologies like Harberger taxes.
-
Wallets will need to interact with spending and cryptographic keys in a better way. Currently, wallets typically use deterministic signature generation to produce application-specific keys: signing a standard nonce (e.g., a hash of the application name) with an EOA’s private key will produce a deterministic value that cannot be generated without the private key and is thus secure from a purely technical standpoint. However, these technologies are “opaque” to wallets, preventing them from implementing UI-level security checks. In a more mature ecosystem, signature, encryption, and related functionality will need to be handled more explicitly by wallets.
-
Light clients (e.g., Helios) will need to verify Layer 2, not just Layer 1. Currently, light clients focus on checking the validity of L1 block header information (using a light client synchronization protocol) and verifying the Merkle branches of L1 state and transactions based on L1 block header information. In the future, they will also need to verify proofs of L2 state rooted at the state root stored in L1 (more advanced versions will actually look at L2 pre-commits).
Wallets will need to protect assets and data
Currently, the task of wallets is to protect assets. Everything is stored on-chain, and the wallet only needs to protect the private key that currently protects these assets. If you change the key, you can safely publish the previous private key on the Internet the next day. However, in the zero-knowledge world, this is no longer the case: wallets not only protect authentication credentials, but also store your data.
At Zuzalu, we use the ZuBlockings identity system, which is based on ZK-SNARKs, and we are seeing the initial signs of a world like this. Users have a private key for authentication to the system, which can be used to generate basic proofs, such as “prove that I am a Zuzalu resident without revealing which resident.” The ZuBlockings system is also starting to build other applications on top of it, most notably stamps (the ZuBlockings version of POAP).
One of my many ZuBlockings stamps confirms that I am a member of Team Cat.
The key feature of stamps compared to POAPs is that they are private: you keep the data locally and only prove a stamp (or perform some computation on the stamp) when you want to provide that information to someone else with a ZK proof. But this also comes with an additional risk: if you lose the information, you lose your stamp.
Of course, the problem of holding data can be simplified 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 your actions do not change the encryption key, so you do not need to interact with any system that holds the encryption key. But even so, if you lose the encryption key, you lose all the data. And conversely, if someone sees your encryption key, they can see everything that was encrypted with that key.
ZuBlockings’ practical solution is to encourage people to store their keys on multiple devices (such as laptops and phones), because the chances of losing access to all devices simultaneously are minimal. We can further adopt the use of key sharing to split the key storage among multiple custodians.
Recovery via MPC social recovery is not a sufficient solution for wallets, as it means that not only the current custodians, but also previous custodians could collude to steal your assets, which is an unacceptable high risk. But privacy leaks are typically less risky than complete loss of assets, and for use cases with high privacy requirements, higher loss risk can be accepted by not backing up keys related to those privacy requirements.
To avoid getting users stuck in a complex multi-recovery-path system, wallets that support social recovery might need to manage both asset recovery and encryption key recovery aspects.
Returning to Identity
One common theme among these changes is that the concept of an “address” as a representation of identity on a blockchain will need to undergo fundamental changes. The “instructions for how to interact with me” will no longer be just an ETH address; they will be represented in some form, potentially a combination of multiple addresses on multiple L2s, meta-addresses, cryptographic keys, and other data.
One approach is to use ENS as your identity: your ENS record can contain all the information about how to pay and interact with you, and if you send someone bob.eth (or bob.ecc.eth, etc.), they can query and learn everything about interacting with you, even in more complex cross-domain and privacy-preserving ways.
However, this ENS-centric approach has two weaknesses:
-
It associates too much with your name. Your name doesn’t represent everything about you, it’s just one of your many attributes. You should be able to change your name without having to migrate your entire identity profile and update records in many applications.
-
You can’t have counterfactual names without trust. One key user experience feature of any blockchain is the ability to send tokens to someone who hasn’t yet interacted with the chain. Without this feature, you’re stuck in a catch-22: interacting with the chain requires paying transaction fees, and paying transaction fees requires…already having tokens. ETH addresses, including smart contract addresses with CREATE2, have this feature. ENS names don’t, because if two Bobs decide off-chain that they’re both bob.ecc.eth, there’s no way to choose which Bob gets that name.
One possible solution is to put more content in the keystore contract previously mentioned in this architecture. The keystore contract can contain various information about you and who you interact with (and some of this information can be off-chain using CCIP), and the user will use their keystore contract as their primary identifier. But the assets they actually receive will be stored in various different places. The keystore contract is agnostic to names and is friendly to counterfactual names: you can generate an address that can only be initialized by a keystore contract with specific fixed initial parameters.
Another class of solutions involves completely abandoning the user-facing address concept, 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 can send a request link (as an explicit URL or QR code), and the receiver can use that link to accept payment in any way they choose.
Whether the sender or the receiver takes action first, relying more on the wallet to generate the latest payment information in real time can reduce friction. However, persistent identifiers are very convenient (especially using ENS), and in practice, relying on direct communication between the sender and the receiver 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 and be easy for users to understand. We need to ensure that users can easily access the latest views on their current assets and messages targeted to them. These views should rely on open tools rather than proprietary solutions. Avoiding the greater complexity of payment infrastructure becoming an opaque “tower of abstraction” that is difficult to understand and adapt to new environments requires hard work. Despite the challenges, it is essential to achieve Ethereum’s scalability, wallet security, and ordinary users’ privacy. This is not only about technical feasibility but also about the actual accessibility of ordinary users. We need to meet this challenge.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
