Partnered With:

V God New text: Incognito address incomplete guide

Read this article in 28 Minutes

Currently stealth addresses can be implemented quickly and significantly improve Ethereum user privacy, but the stealth address ecosystem does seem to rely heavily on zero-knowledge proof.

Original title: An incomplete guide to stealth addresses

原文作者：Vitalik Buterin

原文编译：Karen，Foresight News

One of the biggest challenges in the Ethereum ecosystem right now is privacy. By default, anything that goes into the public blockchain is public, which means not only assets and trading activity, but also ENS domain names, Poaps, NFT and soul-bound tokens, among others. Using a range of Ethereum apps means that a lot of your activity is open to anyone else to see and analyze.

We need to improve this situation. However, to date, the discussion about improving privacy has focused on one particular use case: ETH and the privacy transfer of mainstream ERC20 tokens. This article will describe the mechanisms and use cases for a different class of tools that can improve Ethereum's privacy status in many other situations, known as "invisible-address." stealth addresses) concept.

What is the stealth address system?

Suppose Alice wants to transfer an asset to Bob, which could be a certain amount of cryptocurrency (e.g. 1 ETH, 500 RAI), or an NFT. When Bob receives an asset, he does not want others to know that he is the recipient of the asset. It is not possible to hide the fact that the transfer has occurred, especially if the transfer is to an NFT with only one copy on the chain, but it may be more feasible to hide who the recipient is.

What Alice and Bob would prefer is a payment process system in which Bob sends Alice (or ENS domain name support) some sort of "address" code to receive the payment, and this information alone is enough for Alice (or anyone else) to send him the asset, And it's almost exactly the same as the current payment workflow.

It is important to note that this privacy is nothing like that provided by Tornado Cash. Tornado Cash can hide transfers from mainstream alternative assets such as ETH or the main ERC-20 (often used privately to send to oneself), but is very weak at adding privacy to little-known ERC20 transfers, and cannot add privacy to NFT transfers at all.

The normal workflow for making payments with cryptocurrency, as mentioned above, adds privacy, i.e., no one knows that the asset recipient is Bob, and the workflow is unchanged.

Stealth addresses are addresses that can be generated by either Alice or Bob, but can only be controlled by Bob. Bob generates a spending key, keeps it secret, and then uses it to generate a stealth meta-address. He passes this meta address to Alice (or registers it with ENS). Alice can perform calculations on this meta address to generate an invisible address belonging to Bob. Alice can then send any assets she wants to to this address, and Bob will have complete control over those assets. During the transfer, Alice posts some additional encrypted data (a temporary public key) on the chain to help Bob discover that the address belongs to him.

Another way to look at it is: stealth addresses provide the same privacy attributes as Bob, generating a new address for each transaction, but without any interaction from Bob.

The complete workflow of the stealth address scheme is as follows:

1.Bob generates his root expenditure key (m) and stealth meta address (M).

2.Bob adds an ENS record to register (M) as the stealth address bob.eth.

3. We assume that Alice knows bob's address as bob.eth. Alice looks for Bob's incognito meta address (M) on ENS.

4.Alice generates a temporary key that only she knows and that she can use only once (generating this particular stealth address).

5.Alice uses an algorithm that combines her temporary key with Bob's meta address to produce a stealth address. She can now send assets to this address.

6.Alice also generates her temporary public key and publishes it to the temporary public key registry (this can be done in the same transaction as the first one that sent the asset to this invisible address).

7. In order for Bob to discover the stealth address that belongs to him, Bob needs to scan the temporary public key registry for the entire list of temporary public keys published by anyone since his last scan.

8. For each temporary public key, Bob tries to combine it with his root expenditure key to generate a stealth address, and checks to see if there are any assets at that address. If so, Bob calculates the expenditure key for that address and remembers it.

It all depends on two uses of password spoofing. First, we need a pair of algorithms to generate a shared secret: one algorithm uses Alice's temporary key and Bob's meta address, and the other algorithm uses Bob's root spending key and Alice's temporary public key. This can be done in a variety of ways;Diffie-Hellman key exchangeIs one of the achievements of establishing the modern field of cryptography, and it does exactly that.

But just sharing the secret is not enough: if we just generate a private key from the shared secret, then both Alice and Bob can consume from that address. We also added a key blinding mechanism: In a pair of algorithms, where Bob can combine the shared key with his root cost key, and Alice can combine the shared key with Bob's meta address, Alice can generate the stealth address, and Bob can generate the expenditure key for the stealth address. All of this does not require creating a public link between the incognito address and Bob's meta-address (or between one incognito address and another).

Use elliptic curve cryptography to hide addresses

Using elliptic curve cryptography to hide addresses is originallyBy Peter Todd in 2014It was introduced in the context of bitcoin. Here's how the technology works:

· Bob generates a key (m) and calculates M = G * m, where G is the accepted generation point of an elliptic curve. The incognito meta address is (M).

· Alice generates a temporary key (r) and publishes the temporary public key R = G * r.

· Alice can calculate a shared key S = m * R, and Bob can also calculate the same shared key S = m * R.

· Generally speaking, in Bitcoin and Ethereum (including a properly designed ERC-4337 account), an address is a hash containing the public key used to verify transactions from that address. So if you compute the public key, you can compute the address. To compute the public key, Alice or Bob can compute P = M + G * hash(S)

· To compute the private key of this address, Bob can compute p = m + hash(S)

This meets all of our requirements above, and it's very simple.

There was even oneEIPAttempts to define a stealthiness address standard for Ethereum that both supports this approach and gives users room to develop other approaches (for example, enabling Bob to have separate payout and view keys, or using different cryptography to achieve anti-quantum security). Now you may think: stealth address is not very difficult, the theoretical knowledge has been solid, use is only an implementation detail. The problem, however, is that a truly effective implementation still needs to go through some important implementation details.

Stealth address and payment of transaction fees

Suppose someone sends you an NFT. If you want to ensure privacy, they will send it to an incognito address you control. After scanning the temporary public key on the chain, your wallet will automatically find the address. You are now free to prove ownership of the NFT or transfer it to someone else. However, there is a problem that the ETH balance in this account is 0, so the transaction fee cannot be paid. Even if it isERC-4337Token payers won't work either, as they only apply to fungible ERC20 tokens. And you can't send ETH to it from your main wallet, because then you create a publicly visible link, which means no privacy.

There is an easy way around this: simply use ZK-SNARKs to transfer funds to cover the fee. But that consumes a lot of Gas, hundreds of thousands of extra Gas in a single transfer.

Another, smarter approach involves trusting specialized trade aggregators (searchers in MEV terminology). These aggregators will allow users to pay once for a set of "tickets" that can be used to pay for on-chain transactions. When a user needs to spend NFT in a stealth address that doesn't contain anything else, they provide one of the tickets to the aggregator, usingChaumian blind method for coding. This was the original protocol used in the centralized privacy protection e-cash schemes proposed in the 1980s and 1990s. Searchers accept tickets and repeatedly include the transaction in their bundle for free until the transaction is successfully accepted in a block.

Stealth addresses and separate payouts and view keys

Suppose instead of having a single primary "root expenditure key" that can do everything, Bob wants a separate root expenditure key and view key. This view key can see all of Bob's incognito addresses, but it can't spend money.

In the world of elliptic curves, this can be solved using a very simple cryptographic trick:

· Bob's meta address (M) is now of the form (K, v), encoded G * k and G * v, where k is the expenditure key and v is the view key.

· The shared key is now S = V * r = v * R, where r is still Alice's temporary key and R is still Alice's temporary public key.

· The public key of the stealth address is P = K + G * hash(S), and the private key is p = k + hash(S).

The first step (generating the shared secret) uses the view key, and the second step (Alice and Bob's parallel algorithm generating the stealth address and its private key) uses the root expenditure key.

There are a lot of use cases. For example, if Bob wants to receive POaps, then Bob can give his POAP wallet (or even a less secure Web interface) the viewing key to scan the chain and view all of his POaps without giving the interface the power to spend those POaps.

Stealthy address and easy scan

To make it easier to scan the entire set of temporary public keys, one technique is to add a view label to each temporary public key. One way to do this in the mechanism above is to make the view label a byte of the shared key (for example, S The x coordinate of modulo 256, or the first byte of hash(S).

This way, Bob only needs to perform elliptic curve multiplication once for each temporary public key to calculate the shared key, and because of the view tag, it is easier to scan.

Stealth address and anti-quantum security

The above scheme relies on elliptic curves, but while this works well, it is unfortunately vulnerable to quantum computer attacks. We're going to need to switch to a quantum-resistant algorithm. There are two natural candidates: elliptic curve cognates and lattices.

Elliptic curve homologyIs a very different mathematical construction based on elliptic curves, with linear properties, that allows us to use cryptographic tricks similar to those done above, but neatly avoids constructing cyclic groups that might be vulnerable to discrete logarithm attacks from quantum computers.

The main weakness of homologous cryptography is its highly complex underlying mathematics and the risk of hiding possible attacks under this complexity. Some same-origin (cryptographics-based) protocols were attacked last year,But other protocols remain secure. The main advantages of homology are the relatively small key size and the ability to directly port multiple elliptic curve-based methods.

A 3-isogeny in CSIDH

lattices are a very different cryptographic structure that relies on simpler mathematics than elliptic curve isomorphism, and is capable of doing some very powerful things (e.gComplete homomorphic encryption). Stealth address schemes can be built on grids, although the best scheme to design is an open question. However, lattice-based structures tend to have larger key sizes.

Full homomorphic encryption, lattice applications. FHE can also be used to aid the stealth address protocol in a different way: help Bob outsource the calculation of the stealth address of the asset to check whether the entire chain contains it, without revealing his view key.

The third method is to construct stealth address from common black box primitives. The shared key generation part of the scheme maps directly toKey exchange, which is an important part of public key encryption system. The harder part is the parallel algorithm that gets Alice to generate only the stealth address (not the expenditure key) and Bob to generate the expenditure key.

Unfortunately, you can't build stealth addresses with much simpler ingredients than you need to build public key cryptosystems. A simple proof is that you can build a public key encryption system with a stealth address scheme. If Alice wants to encrypt a message to Bob, she can send N transactions, each to either one of Bob's incognito addresses or to one of her own incognito addresses, and Bob can see which transactions he received to read the message. This is very important, in mathematical proof you can't do public key encryption with just hashing, you can do it with just hashingZero-knowledge proofTherefore, stealth address can not only be hashed to complete.

This is indeed an approach using relatively simple ingredients: zero-knowledge proofs, which can consist of hashing and (key-hiding) public-key encryption. Bob's meta-address is a public encryption key plus a hash h = hash(x), and his expenditure key is the corresponding decryption key plus x. To create a stealth address, Alice generates a value c and publishes Bob's readable encryption of c as her temporary public key. The address itself is aAccount ERC-4337, whose code verifies the transaction by requiring it to provide proof of zero knowledge, proving ownership of the values x and c such that k = hash(hash(x), c) (where k is part of the account code). Knowing x and c, Bob can reconstruct the address and code himself.

The encryption of (c) tells no information to anyone other than Bob, and (k) is a hash that reveals little about c Anything. The wallet code itself contains only (k), and (c) private means that (k) cannot be traced back to (h).

However, this requires a STARK. Ultimately, I think the post-quantum Ethereum world is likely to involve using many STARK applications, so I advocate itAs described hereThe aggregation protocol combines all of these StarKs into one recursive STARK to save space.

Incognito address and social recovery as well as multi-L2 wallet

I've been interested for a long timeSocial Recovery walletThe social recovery wallet has a multi-signature mechanism, and its key can be shared among the organization, your other devices, and some combination of friends. Most keys allow account access to be restored if you lose your primary key.

However, Social recovery wallets don't combine well with incognito addresses: If you had to restore your account (change the private key that controls it), you would also have to perform some steps to change the account verification logic of your N incognito wallets, which would require N transactions at the expense of high fees, convenience, and privacy costs.

Similar concerns exist about social recovery and the interaction of multiple L2 protocols: If you have accounts in Optimism, Arbitrum, StarkNet, Scroll, Polygon, a dozen parallel instances for scaling reasons, and you have an account on each instance, then changing the key can be a very complicated operation.

Changing the keys of multiple accounts in multiple chains is a huge effort.

Perhaps you could use some automated software to move assets to new stealth addresses at random intervals over a two-week time span to reduce the effectiveness of time-based associations. But it's far from perfect. Another approach is to secretly share the root key between guardians instead of using smart contract recovery. However, this eliminates the ability to deactivate the guardian's power to help restore your account, so there is a long-term risk.

A more complex approach involves zero-knowledge proof. This allows many accounts, even across many L2 protocols, to be controlled somewhere (on the underlying chain or on some L2) by a single k value, where changing that value is enough to change the ownership of all accounts, all without compromising the links between your multiple accounts.

conclusion

The current basic stealth address can be implemented quickly and can significantly improve user privacy on Ethereum. I think wallets should start moving to a more native multi-address model for other privacy-related reasons (for example, creating a new address for every app you interact with might be an option).

However, stealth addresses do pose some long-term usability problems, such as difficulties with social recovery. These problems can be solved in the long run, but the stealth address ecosystem does seem to rely heavily on zero-knowledge proof.