We have long been interested in the topic of anonymity in cryptocurrencies and try to follow the development of technologies in this area. In our articles, we have already analyzed in detail the principles of work in Monero, and also held technologies in this field. However, all anonymous cryptocurrencies today are built on the data model proposed by Bitcoin - Unspent Transaction Output (hereinafter referred to as UTXO). For account-based blockchains like Ethereum, existing anonymity and privacy solutions (for example, or ) tried to replicate the UTXO model in smart contracts.
In February 2019, a team of researchers from Stanford University and Visa Research released "Zether: Towards Privacy in the World of Smart Contracts". The authors for the first time proposed an approach to ensuring anonymity in account-based blockchains and presented two options for a smart contract: for confidential (hiding balances and transfer amounts) and anonymous (hiding the recipient and sender) transactions. We find the proposed technology interesting and would like to share its design, as well as talk about why the problem of anonymity in account-based blockchains is considered very difficult and whether the authors managed to solve it to the fullest.
About the structure of these data models
In the UTXO model, a transaction consists of "inputs" and "outputs". The direct analogue of “outputs” is banknotes in your wallet: each “output” has some denomination. When you pay someone (form a transaction), you spend one or more "outputs", while they become "inputs" of the transaction, and the blockchain marks them as spent. In this case, the recipient of your payment (or yourself, if you need change) receives the newly generated "outputs". Schematically, this can be represented as follows:
Account-based blockchains are set up much like your bank account. They operate only on the amount in your account and the amount of the transfer. When you transfer some amount from your account, you do not burn any "outputs", the network does not need to remember which coins are spent and which are not. In the simplest case, checking a transaction comes down to checking the sender's signature and the amount on his balance:
Technology Analysis
Next, we will talk about how Zether hides the amount of transactions, the recipient and the sender. In the course of describing the principles of its operation, we will note the differences in the confidential and anonymous version. Since it is much easier to provide privacy in account-based blockchains, some of the restrictions imposed by anonymization will not be relevant for the confidential version of the technology.
Hiding balances and transfer amounts
Zether uses an encryption scheme to encrypt balances and transfer amounts . It works as follows. When Alice wants to send Bob b coins by address (its public key) Y, she picks a random number r and encrypts the amount:
where C - encrypted amount, D - an auxiliary value needed to decipher this amount, G - a fixed point on an elliptic curve, when multiplying the secret key by which the public key is obtained.
When Bob receives these values, he simply adds them to his balance encrypted in the same way, which is convenient for this scheme.
Similarly, Alice subtracts the same values from her balance, only as Y uses its public key.
Hiding the addressee and sender
Mixing "outputs" in UTXO appeared at the dawn of cryptocurrencies and helps to hide the sender. To do this, the sender himself, when making a transfer, collects random “outputs” in the blockchain and mixes them with his own. Then he signs the “outputs” with a ring signature, a cryptographic mechanism that allows you to convince the verifier that the sender’s coins are among the involved “outputs”. The coins themselves, of course, are not spent.
However, to hide the recipient, we will not be able to generate fake "outputs". Therefore, in UTXO, each “output” has its own unique address, and it is cryptographically associated with the address of the recipient of these coins. At the moment, there is no way to reveal the relationship between the unique "exit" address and the address of the recipient, without knowing his secret keys.
In the account-based model, we cannot use one-time addresses (otherwise it will already be an “exits” model). Therefore, the recipient and sender have to be mixed among other accounts in the blockchain. At the same time, encrypted 0 coins are deducted from the mixed accounts (or 0 is added if the recipient is mixed), without actually changing their real balance.
Since both the sender and the recipient always have a permanent address, here it becomes necessary to use the same groups for mixing when transferring to the same addresses. It's easier to see this with an example.
Let's say Alice decides to make a donation to Bob's charitable foundation, but prefers that this transfer remain anonymous to the outside observer. Then, in order to disguise herself in the sender field, she also enters the accounts of Adam and Adele. And to hide Bob, in the recipient field, additionally, the accounts of Ben and Bill. When making the next installment, Alice decided to write Alex and Amanda next to her, and Bruce and Benjen next to Bob. In this case, when analyzing the blockchain in these two transactions, there is only one intersecting pair of participants - Alice and Bob, which deanonymizes these transactions.
Transaction races
As we already mentioned, in order to hide his balance in account-based systems, the user encrypts his balance and the amount of the transfer. At the same time, he must prove that the balance on his account remains non-negative. The problem is that when forming a transaction, the user builds a proof regarding his current account status. But what happens if Bob sends a transaction to Alice, and it is accepted before the one sent by Alice? Then Alice's transaction will be considered invalid, because the balance proof was built before Bob's transaction was accepted.
The first solution that comes in such a situation is to freeze the account until the transaction takes place. But this approach is not suitable, because in addition to the complexity of solving such a problem in a distributed system, in an anonymous scheme it will not be clear whose account to block.
To solve this problem, the technology separates incoming and outgoing transactions: spending funds has an immediate effect on the balance sheet, while receipts have a delayed effect. To do this, the concept of "epoch" is introduced - a group of blocks of a fixed size. The current "epoch" is determined by dividing the block height by the group size. When processing a transaction, the network updates the sender's balance immediately, and adds the recipient's funds to the accumulator. The accumulated funds are available to the payee only when a new "epoch" begins.
As a result, the user can send transactions regardless of how often he receives funds (as far as his balance allows, of course). The epoch size is determined based on how fast blocks propagate across the network and how fast a transaction gets into a block.
This solution works well in the case of confidential transfers, but with anonymous transactions, as we will see later, it creates serious problems.
Protection against replay attacks
In account-based blockchains, each transaction is signed with the sender's private key, which convinces the verifier that the transaction has not been modified and was created by the owner of this key. But what if an attacker who was listening on the transmission channel intercepts this message and sends exactly the same second one? The verifier will verify the signature of the transaction and be convinced of its authorship, and the network will write off the same amount from the sender's balance again.
This attack is called a replay attack. In the UTXO model, such attacks are not relevant, because the attacker will try to use the spent outputs, which in itself is not valid and is rejected by the network.
To prevent this from happening, a field with random data is embedded in the transaction, which is called a nonce or simply “salt”. When resending a transaction with a "salt", the verifier looks to see if this nonce has been used before and, if not, considers this transaction valid. In order not to store the entire history of user nonces in the blockchain, it is usually taken equal to zero in the very first transaction, and then increased by one. The network only needs to check that the nonce of the new transaction differs from the previous one by one.
In an anonymous transfer scheme, the problem of validating transaction nonces arises. We cannot bind the nonce explicitly to the sender's address, because, obviously, this deanonymizes the transfer. We also cannot add one to the nonces of all participating accounts, as this may conflict with other transfers in progress.
The authors of Zether propose to generate a nonce cryptographically, depending on the “epoch”. For example:
Here x is the sender's secret key, and Gepoch — an additional generator for the epoch, obtained by hashing a string of the form 'Zether + '. Now the problem seems to be solved - we do not disclose the nonce of the sender and do not interfere with the nonces of uninvolved participants. But this approach imposes a serious limitation: one account can send no more than one transaction per “epoch”. This problem, unfortunately, remains unresolved, and at the moment makes the anonymous version of Zether, in our opinion, hardly usable.
Complexity of Zero Knowledge Proofs
In UTXO, the sender must prove to the network that he does not spend a negative amount, otherwise it becomes possible to generate new coins out of thin air (why this is possible, we wrote in one of the previous ). And also to sign the “entrances” with a ring signature to prove that among the coins being kneaded there are funds belonging to him.
In the anonymous version of the account-based blockchain, the proof expressions are much more complicated. The sender proves that:
- The amount sent is positive;
- The balance remains non-negative;
- The sender correctly encrypted the transfer amounts (including zero ones);
- The balance on the balance changes only for the sender and recipient;
- The sender owns the secret key to his account and he is really present in the list of senders (among those involved);
- The nonce used in the transaction is correct.
For such a complex proof, the authors use a mixture (one of the authors, by the way, took part in its creation) and , which is called Sigma-bullets. The formal proof of such a statement is a rather difficult task, and it greatly limits the number of people willing to implement the technology.
The result?
In our opinion, the part of Zether that brings privacy to account-based blockchains can be used right now. But at the moment, the anonymous version of the technology imposes serious restrictions on its use, and its complexity on implementation. However, it should not be discounted that the authors released it only a few months ago, and perhaps someone else will find a solution to the problems that exist today. After all, that is how science is done.
Source: habr.com