We’ve long been interested in the topic of crypto anonymity and tried to follow technologies developing in this area. In our articles we already analyzed the principles of Monero confidential transactions, and also did a comparative review of the current technologies in this field. However, all anonymous cryptocurrencies of today are built on the data model proposed by Bitcoin — Unspent Transaction Output (“UTXO”). For account-based blockchains like Ethereum, existing solutions for anonymity and confidentiality (e.g., Mobius or Aztec) were an attempt to copy the UTXO model in smart contracts.
In February 2019, a group of researchers from Stanford University and Visa Research released the preprint named “Zether: Towards Privacy in a Smart Contract World”.
For the first time, the developers proposed an approach to ensure anonymity in account-based models and presented two smart contract options: for confidential (concealing balance and transfer amount) and anonymous (concealing recipient and sender) transactions. The proposed technology seems quite promising so we would like to talk about its design and share some thoughts on the anonymity problem in account-based blockchains — why it is viewed as such a complex issue and whether the developers did a good job solving it.
About configuration of these data models
In the UTXO model, a transaction includes “inputs” and “outputs”. The closest analogy to “outputs” are the bills in your wallet: each “output” has some kind of face value. When you pay someone (initiate a transaction), you spend one or several “outputs”, so they convert into transaction “inputs”, and blockchain marks them as spent. In this case, the recipient of your payment (or yourself, if you need a change) receives the newly generated “outputs”. Simplified flow chart of the process looks like this:
Account-based blockchains are roughly like your bank account. They operate only with the amount on your account and the amount of transfer. When you transfer some amount from your account, you don’t consume any “outputs”, and the networks don’t need to memorize which coins are spent and which are not. At its simplest, transaction verification is reduced to checking the sender’s signature and his balance amount:
Technology in detail
Next, we discuss how Zether hides sender, recipient and transaction amount. As we describe how it works, we will also underline the differences between confidential and anonymous versions. Since it is much easier to ensure confidentiality in account-based blockchains, some restrictions imposed by anonymization stop being relevant for the confidential version.
Hiding balances and transfer amounts
To encrypt balances and transfer amounts, Zether uses the ElGamal encryption algorithm. Let’s see how it works. When Alice wants to send Bob b coins to Y address (his public key), she picks a random number r and encrypts the amount:
where C is an encrypted amount, D is an auxiliary value needed to decrypt this amount, G is a fixed point on the elliptic curve: multiplying it by the private key we get the public key.
When Bob receives these values, he just adds them to his identically encrypted balance — that’s what makes the algorithm user-friendly.
In a similar way, Alice deducts the same values from her balance but uses her public key as Y.
Hiding the recipient & sender details
Mixing “outputs” in UTXO started in the early days of cryptocurrencies as a means of the sender concealment: during transfer, the sender himself picks random “outputs” in blockchain and mixes them with his own ones. Then he signs “outputs” using ring signature — a cryptographic mechanism to convince the verifier that the sender’s coins are among the mixed “outputs”. Mixed coins are, of course, not spent.
However, to conceal the recipient, it is impossible to generate fake “outputs”. Therefore, in UTXO, each “output” belongs to the unique address, which is cryptographically connected to the address of these coins’ recipient. At the moment there is no way to identify the connection between the unique address of an “output” and the recipient’s address if his private keys are unknown.
In the account-based model, we cannot use one-time addresses (because those are an attribute of the “output” model). Therefore, the recipient and the sender have to be mixed among the other blockchain accounts. At the same time, mixed accounts are charged 0 encrypted coins (or 0 is added in case of mixing the recipient), so their real balance does not actually change.
Since both the sender and the recipient are attached to a permanent address, it is necessary to use the same groups for mixing when directing payments to the same addresses. An example will be a better illustration here:
Suppose Alice decides to make a contribution to Bob’s charitable foundation, but she prefers this payment to appear anonymous to a third party. Then, to hide herself in the sender field, she adds Adam’s and Adele’s accounts. She also adds Ben’s and Bill’s accounts in the recipient field to hide Bob. For the next contribution, Alice enters Alex and Amanda next to herself, and Bruce and Benjen next to Bob. In this case, when blockchain is analyzed, these two transactions will only have one matching pair deanonymizing them — Alice and Bob.
Transaction Races
As we already mentioned, in order to hide the balance in account-based systems, the user encrypts his balance and the amount of transfer. However, he must prove somehow that the remaining balance on his account is non-negative. The problem is that by starting a transaction, the user provides proof regarding his current account state. And what if Bob sends a transaction to Alice, and it will be accepted earlier than the one sent by Alice? Then Alice’s transaction will be regarded as invalid since the proof of the balance was built before accepting Bob’s transaction.
The first obvious solution, in this case, is to freeze the account before the transaction. But this approach is no good since in addition to the general complexity of solving this problem in a distributed system, the anonymous procedure makes it unclear whose account should be blocked.
To solve this problem, technology separates incoming and outgoing transactions: expenditure immediately impacts the balance, unlike receipt that provides delayed effect. Therefore, the “epoch” concept meaning a group of fixed-size blocks is introduced. The current “epoch” is determined by dividing the block height by the group size. Processing the transaction, the network immediately updates the sender’s balance and places the recipient’s funds into storage. Accumulated funds become available to the recipient of payment only when a new “epoch” is generated.
As a result, the user can send transactions regardless of how often he receives funds (as far as his balance allows it, of course). The epoch size is determined based on how quickly the blocks are distributed through the network and how quickly the transaction enters the block.
This solution works well for confidential transfers, but in anonymous transactions, it poses major problems, as we will see further on.
Replay protection
In account-based blockchains, each transaction is signed by the sender’s private key, convincing the verifier that the transaction has not been changed and was created by this key’s owner. But what if an attacker who monitored the transmission channel captures this message and sends the exact same next one? Upon the transaction signature check, the verifier will be convinced it comes from a genuine author, and the network will write off the same amount from the sender’s balance again.
This kind of attack is called a replay attack. In UTXO model, such attacks are irrelevant, since the attacker will try to use the spent outputs, which is originally invalid and rejected by the network.
To prevent this from happening, a field filled with random data called nonce (or “salt”) is embedded into the transaction. When the “salted” transaction is resent, the verifier checks whether the nonce has been used before and, if not, validates the transaction. To avoid storing the entire history of users’ nonces on the blockchain, it is usually taken equal to zero in the very first transaction and then incremented by one. The network just needs to make sure that the nonce of a new transaction differs from the previous by one.
In the anonymous payment scheme, there is a problem of validating transaction nonces. We cannot directly connect nonce to the sender’s address, since, obviously, this will deanonymize the transfer. We also cannot add one to the nonces of all accounts involved, since this may conflict with other transfers being processed.
Zether developers propose the cryptographic generation of nonces, depending on the “epoch”. For example:
Here, x is the sender’s private key, and G epoch is an additional generator for the epoch, obtained by hashing a string like ‘Zether + <epoch number>’. Now, the problem seems solved — we do not reveal the sender’s nonce and do not tamper with nonces of uninvolved participants. But this approach imposes severe restriction: only one transaction can be sent from one account per “epoch”. This problem, unfortunately, remains unresolved, and, in our opinion, currently makes an anonymous version of Zether hardly suitable for use.
Zero-knowledge proof complexity
In UTXO, the sender must prove to the network that he does not spend a negative amount, otherwise there’s a risk of generating new coins out of thin air (see our previous article to understand why this is even possible). Also, “inputs” have to be signed with a ring signature to prove sender’s funds are really somewhere among the mixed coins.
In the anonymous version of the account-based blockchain, statements to prove are much more complicated. The sender proves that:
1. The amount sent is positive;
2. The balance remains non-negative;
3. The sender encrypted the transfer amounts (including zero amounts) correctly;
4. Only the sender’s and the recipient’s balances change;
5. The sender owns the private key to his account and is really present in the list of senders (among those mixed);
6. The nonce used in the transaction is correct.
For such a complex proof, the developers mix Bulletproof (one of the developers, by the way, took part in its creation) and Sigma protocol, the result is called 𝝨-bullets (Sigma-bullets). Formal proof of this statement is a serious challenge, and it dramatically limits the number of specialists interested in implementing the technology.
What is the bottom line?
From our point of view, the part of Zether which brings confidentiality to account-based blockchains may well be put into use right now. But at the moment anonymous version of the technology limits its use, just as the complexity hinders its implementation. However, don’t forget that the developers released it just a few months ago, and perhaps someone else will be able to find a solution. After all, this is how science is done.
