One of the biggest challenges in the current Ethereum ecosystem is privacy. Anything that goes onto a public blockchain is public by default, which means not just assets and transaction activity, but ENS names, POAPs, NFTs, and soulbound tokens, among others. Using a range of Ethereum applications means that a lot of your activity is open for anyone else to view and analyze.

We need to improve this situation. However, so far, the discussion on improving privacy has largely revolved around one specific use case: privacy-preserving transfers of ETH and mainstream ERC20 tokens. This post will describe the mechanics and use cases of a different class of tools that can improve the privacy state of Ethereum in many other contexts, the concept of “stealth addresses”.

## What is Stealth Address System?

Suppose Alice wants to transfer assets to Bob, which may be a certain amount of cryptocurrency (eg 1 ETH, 500 RAI), or it may be an NFT. When Bob receives an asset, he doesn’t want others to know that the asset is for him. It’s impossible to hide the fact that a transfer has taken place, especially if the transfer is an NFT that only has one copy on-chain, but it might be more feasible to hide who the recipient is.

What Alice and Bob would prefer is a payment flow system where Bob sends Alice (or a supported ENS domain name) some kind of “address” encoding that can receive payments, and this information alone is enough for Alice (or anyone else) ) to send him the asset, and it’s almost identical to the current payment workflow.

It is important to note that this level of privacy is completely different from that provided by Tornado Cash. Tornado Cash can hide transfers of mainstream fungible assets like ETH or major ERC-20s (often used to send privately to self), but is very weak at adding privacy to lesser-known ERC20 transfers, and cannot add privacy to NFT transfers at all .

The normal workflow of paying with cryptocurrency as mentioned above adds privacy, i.e. no one can know that the recipient of the asset is Bob, and the workflow is unchanged.

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

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

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

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

Bob adds an ENS record to register (M) as bob.eth’s stealth meta address bob.eth.

Let’s assume Alice knows that Bob’s address is bob.eth. Alice looks up Bob’s stealth meta-address (M) on the ENS.

Alice generates an ephemeral key that only she knows, and she can only use once (generating this specific stealth address).

Alice uses an algorithm that combines her ephemeral key with Bob’s meta address to generate a stealth address. She can now send assets to this address.

Alice also generates her ephemeral public key and publishes it to the ephemeral public key registry (this can be done in the same transaction as the first to send assets to this stealth address).

In order for Bob to discover the stealth address that belongs to him, Bob needs to scan the registry of ephemeral public keys to find the entire list of ephemeral public keys issued by anyone since his last scan.

For each ephemeral public key, Bob tries to combine it with his root spending key to generate a stealth address, and checks to see if there are any assets in that address. If so, Bob computes the spending key for that address and remembers it.

It all relies on two uses of password spoofing. First, we need a pair of algorithms to generate the shared secret: one algorithm using Alice’s ephemeral key and Bob’s meta address, and another algorithm using Bob’s root spending key and Alice’s ephemeral public key. This can be done in a number of ways;Diffie-Hellman key exchangeis one of the fruits of establishing the field of modern cryptography, and it achieves exactly this.

But the shared secret is not enough: if we just generate a private key from the shared secret, then both Alice and Bob can spend from this address. We also add a key blinding mechanism: in a pair algorithm, where Bob can combine the shared secret with his root spend key, and Alice can combine the shared secret with Bob’s meta-address, such that Alice can then generate a stealth address, and Bob can generate a spending key for that stealth address, all without creating a public link between the stealth address and Bob’s meta address (or between one stealth address and another).

## Hide Addresses Using Elliptic Curve Cryptography

Using elliptic curve cryptography to hide the address is initiallyby Peter Todd in 2014Introduced in the context of Bitcoin. The technique works as follows:

Bob generates a key (m), and computes M = G * m, where G is the recognized generation point of the elliptic curve. Stealth meta address is (M).

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

Alice can compute a shared secret S = M * r, and Bob can compute the same shared secret S = m * R.

In general, in Bitcoin and Ethereum (including properly designed ERC-4337 accounts), 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 for this address, Bob can compute p = m + hash(S)

This fulfills all of our requirements above, and is very simple.

there is even aEIPAttempts to define a stealth address standard for Ethereum that both supports this approach and leaves room for users to develop other approaches (e.g. supporting Bob to have separate spending and viewing keys, or using different cryptography to achieve quantum security). Now you might be thinking: Stealth addresses are not that hard, the theory is solid, adoption is just an implementation detail. The problem, however, is that a truly efficient implementation needs to go through some important implementation details.

## Stealth addresses and paying transaction fees

Suppose someone sends you an NFT. If you want to ensure privacy, they will send it to a stealth address that you control. After scanning the ephemeral public key on the chain, your wallet will automatically discover the address. You are now free to prove ownership of NFTs or transfer them to others. But there is a problem, the ETH balance in the account is 0, so the transaction fee cannot be paid.even ifERC-4337Token payers won’t work either, as they only work with 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: just use ZK-SNARKs to transfer funds to pay fees. But this will consume a lot of Gas, and only a single transfer will consume hundreds of thousands of Gas.

Another, smarter approach involves trusting specialized transaction aggregators (searchers in MEV lingo). These aggregators will allow users to pay once to purchase a set of “tickets” that can be used to pay for on-chain transactions.When a user needs to spend an NFT in a stealth address that contains nothing else, they provide one of the tickets to the aggregator, usingEncoding with Chaumian blinding. This is the original protocol used in the centralized privacy-preserving electronic cash schemes proposed in the 1980s and 1990s. Seekers accept the ticket and repeatedly include the transaction in their bundle for free until the transaction is successfully accepted in a block.

## Stealth addresses and separate spending and viewing keys

Suppose instead of just one master “root spend key” that does everything, Bob wants a separate root spend key and view key. The view key can see all of Bob’s stealth addresses, but cannot spend.

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

Bob’s meta address (M) is now of the form (K, V), encoding G * k and G * v, where k is the spending key and v is the viewing key.

The shared secret is now S = V * r = v * R, where r is still Alice’s ephemeral key and R is still Alice’s ephemeral 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 viewing key, and the second step (Alice and Bob’s parallel algorithm generating the stealth address and its private key) uses the root spending key.

This has many 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 view key to scan the chain and see all his POAPs without spending those Powers of POAP.

## Stealth address and easy scan

To more easily scan the entire set of ephemeral public keys, one technique is to add a view tag to each ephemeral public key. One way to do this in the above mechanism is to make the view label a byte of the shared secret (eg, the x coordinate of S modulo 256, or the first byte of hash(S).

This way, Bob only needs to perform one elliptic curve multiplication for each ephemeral public key to compute the shared secret, which is also easier to scan thanks to the view label.

## Stealth addresses and quantum-resistant security

The above scheme relies on elliptic curves, and while it works well, it is unfortunately vulnerable to quantum computers. We will need to switch to quantum resistant algorithms. There are two natural candidates: elliptic curve homology and lattices.

Elliptic Curve Homologyis a very different mathematical construction based on elliptic curves, with linear properties that allow us to use similar cryptographic tricks to what we did above, but neatly avoid constructing cyclic groups that might be vulnerable to discrete logarithm attacks on quantum computers.

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

A 3-isogeny in CSIDH

Lattices are a very different cryptographic structure, relying on simpler mathematics than elliptic-curve isomorphisms, and are capable of doing some very powerful things (e.g.fully homomorphic encryption). Stealth address schemes can be built on Lattice, although designing the best scheme is an open question. However, lattice-based structures tend to have larger key sizes.

Fully homomorphic encryption, lattice applications. FHE can also be used to help the Stealth Address Protocol in a different way: to help Bob outsource the computation of a Stealth Address that checks whether an asset is contained in the entire chain, without revealing his view key.

The third approach is a scheme to construct stealth addresses from generic black-box primitives.The shared key generation part of the scheme maps directly tokey exchange, which is an important part of the public key encryption system. The harder part is the parallel algorithm of having Alice generate only the stealth address (not the spending key) and Bob generating the spending key.

Unfortunately, you cannot build stealth addresses using simpler ingredients than are required to build public-key cryptography. There is a simple proof that it is possible to 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 transaction is sent to either one of Bob’s stealth addresses, or to one of her own stealth addresses, and Bob can see which transactions he has received to read Get news.This is important, in mathematical proofs you can’t just do public key encryption with hashes, you can do it with just hasheszero-knowledge prooftherefore, stealth addresses cannot be done with hashes alone.

This is indeed a method that uses relatively simple ingredients: a zero-knowledge proof, 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 spending key is the corresponding decryption key plus x. To create a stealth address, Alice generates a value c and publishes the encrypted version of c readable by Bob as her ephemeral public key.The address itself is aERC-4337 account, whose code verifies transactions by requiring them to provide a zero-knowledge proof 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 nothing to anyone but Bob, and (k) is a hash that reveals almost nothing about c. The wallet code itself only contains (k), and (c) being private means (k) cannot be traced back to (h).

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

## Stealth addresses and social recovery and multi-L2 wallets

I’ve been interested for a long timesocial recovery wallet, the social recovery wallet has a multi-signature mechanism whose keys can be shared between some combination of institutions, your other devices, and friends. Most keys allow recovery of account access if you lose your primary key.

However, social recovery wallets don’t combine well with stealth addresses: if you have to restore your account (change the private keys that control it), you also have to perform steps to change the account verification logic of your N stealth wallets, which N transactions will be required, at the expense of high fees, convenience, and privacy.

There are similar concerns with social recovery and the interplay of multiple L2 protocols: if you have accounts on Optimism, Arbitrum, StarkNet, Scroll, Polygon, have a dozen parallel instances for scaling reasons, and you have If both have an account, changing keys can be a very complex operation.

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

Perhaps you could use some automated software to transfer 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 among guardians instead of using smart contract recovery. However, this removes the ability to deactivate guardians to help restore power to your account, so there are long-term risks.

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

## in conclusion

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

However, stealth addresses do pose some long-term usability issues, such as difficulties with social recovery. These issues are solvable in the long run, though the stealth address ecosystem does appear to rely heavily on zero-knowledge proofs.

## Be the first to comment