DeFi Security Lecture 10 —Mixer
Why we need Mixer?
The main reason is that mixing coins help us solve the problems of anonymity and privacy and currency interchangeability. There will be many transactions involved in Defi, and how to trade securely is a question worth thinking about.
A real scenario is, for example, if you are a “rich person on the chain”, as long as your transaction is sent out, the chain can quickly monitor the changes of your address, and the robot on the chain will immediately know all the addresses that have been used, and total assets. For another example, online shopping with an on-chain account, because all consumption history will be seen by the entire network. This lack of “privacy” on the chain obviously also hinders the landing of the blockchain, which prevents the chain from interacting with the real world on a large scale. The so-called “asset on-chain” has become empty talk. Every move is recorded and analyzed by others. Before the blockchain, everyone is equal, isn’t it very insecure?
The principle can be explained in one sentence: mix your own assets with those of many other people, and then transfer them to a new address, thereby erasing the direct connection with the original address. The purpose of shuffling is to sever the connection between the sender and the recipient of a cryptocurrency transaction, improve the privacy and anonymity of cryptocurrency, and make it harder for third parties to track what the cryptocurrency is used for and who it belongs to. A widely used method is to change the transaction process without changing the transaction result, so that the attacker cannot directly obtain the complete information of the transaction, this method is called “mixing”.
Blockchains are not completely anonymous by design, and are pseudo-anonymous at best. The “address” in the blockchain is a pseudonym used by users to hide their real identity, which can be obtained using a public key and an encryption algorithm (such as ECC). In the encryption algorithm, the public key is used to generate the input address and output address of the transaction, and the private key information is kept by the user and used to generate the signature necessary to prove the ownership of the funds when paying Bitcoin. Any person or organization can easily create a Hash account and participate in the verification. Although such an account does not correspond one-to-one with individuals, due to the openness of transactions, anyone can track your transactions on the public ledger. For example, human flesh analysis, if it is matched with more advanced tools, and it is possible to use this information to find out your true identity, there will be more in-depth skin-picking articles.
Since every transaction made by the user will be permanently recorded in the blockchain, once a historical transaction is real-named (for example, the Bitcoin exchange is hacked, resulting in the disclosure of user account information), all relevant transaction records will be recorded. The identity information of the traders will be leaked. In addition, as blockchain transactions are gradually applied to the field of daily payments, attackers can use off-chain information to speculate on the identity of accounts in the blockchain. For example, compare the user’s shopping records with the payment records of the Bitcoin account to analyze the identity information of the account. However, the global ledger that records transaction data in the blockchain is public in the network, and any attacker can obtain all transaction information, which puts the privacy of the trader at risk of leakage.
A lot of useful information can be mined along the transaction chain. No matter how many addresses you have, as long as those addresses are related to each other, they can theoretically be discovered through analysis. So there is almost no privacy on the chain. An ordinary payment and an address exposure may make all your actions on the chain have nowhere to hide.
For privacy stealing methods based on data analysis, some privacy protection mechanisms have emerged. The main idea is to hide part of the information in the public data without affecting the normal operation of the blockchain system, increasing the difficulty of data analysis. Among them, currency mixing is a widely used privacy protection method. The core idea of the currency mixing mechanism is to hide the transaction process of the two parties in the blockchain transaction, so that the attacker cannot accurately analyze the relationship between different addresses, so as to disperse the transaction relationship of the trader in the addresses that are not related to each other, and increase the analysis. The difficulty of being a trader.
Mixed currency solution
Centralized currency mixing scheme:
The essence of the centralized currency mixing scheme is to simply transfer a single fund to multiple addresses for multiple times, which is simple to implement and easy to operate. The currency mixing process does not require other technical support. It has extremely high applicability in the currency system. However, the existing centralized currency mixing schemes generally suffer from delay problems. Most improvement schemes prevent theft and information leakage by increasing the cost of third-party violations, and cannot fundamentally eliminate the occurrence of violations. Mixing schemes using cryptographic techniques such as blind signatures will increase the computational cost, and third-party Performing the mixing process will inevitably bring additional service overhead.
Decentralized currency mixing solution:
Ruffing T et al. proposed a completely decentralized currency mixing protocol — CoinShuffle, which adds a mechanism for shuffling the output address on the basis of CoinJoin, so that the currency mixing participants cannot obtain the association relationship of transaction addresses other than themselves. However, this scheme requires all participants to be online at the same time when performing the mixing process, which is vulnerable to denial of service attacks. Bissias G et al. proposed a decentralized currency mixing protocol, Xim, which anonymously searches for mixing participants based on blockchain advertisements. As the number of users participating in the mixing increases, the cost of an attacker’s attack will increase linearly. Thereby effectively avoiding denial of service attacks. In CoinParty, a trusted third party is simulated by secure multi-party computing. Even in the case of malicious operation or failure of some nodes involved in the mixing of coins, the mixing process is still valid. Monero (so that users who participate in mixing coins do not need to communicate with other participating nodes, and can participate in mixing coins by themselves, which provides effective solutions for the common denial of service attacks in the decentralized currency mixing mechanism and the leakage of information by users of mixed coins). defensive measures.
Basic concepts
zero-knowledge proof
In order to create a random connection between the withdrawer and the mixed cryptocurrency, zero-knowledge proofs need to be used to solve the problem of proving cryptocurrency ownership without revealing the relevant information. So what is a zero-knowledge proof, and why can a zero-knowledge proof prove that you know a secret without revealing sensitive information?
Zero-Knowledge Proof was proposed by S. Goldwasser, S. Micali and C. Rackoff in the early 1980s. It was born before the blockchain, but it is known by everyone because of the blockchain. It refers to the ability of the prover to convince the verifier that an assertion is correct without providing any useful information to the verifier.
Zero-knowledge proofs can be divided into two types: interactive and non-interactive.
interactive
The foundation of zero-knowledge proof protocols is interactive. It requires the verifier to continuously ask a series of questions about the “knowledge” the prover possesses. By answering a series of questions, the prover convinces the verifier that the prover does know this “knowledge”. However, this simple method does not convince people that both the prover and the verifier are real, and the two can collude in advance so that the prover can pass the verification without knowing the answer.
non-interactive
Non-interactive zero-knowledge proofs do not require an interactive process, avoiding the possibility of collusion, but may require additional machines and programs to determine the order of experiments.
In layman’s terms, it is to prove what you want to prove, and at the same time the information disclosed to the verifier is “zero”.
For example, when a user registers with the system, the system does not save the plaintext of the user’s password, but saves the hash value of the password; when the user logs in to the system, he only needs to enter the password at the time of registration, and the system will generate a hash value based on the user’s input password. The hash value is compared with the hash value stored in the system database. If they are consistent, the system considers that the current logged-in user knows the password of the account.
This way, users don’t need to tell the website their password to prove their identity. This is actually a zero-knowledge proof.
A detailed analysis of the implementation of a decentralized smart contract mixing technology
Tornado.cash helps you take back your privacy by sending Ether to any address in a way that hides the sending address. Implemented through zero-knowledge proofs. You can use this app to deposit ETH into a non-custodial smart contract and then easily generate credentials to prove that you made the deposit without revealing the original address. Then, when withdrawing money, the app sends this proof to the service provider, which submits it to the smart contract, which then sends the ETH to the desired recipient and pays the service provider a small fee.
When making a deposit, the official will return the credentials, so that you can withdraw by providing the corresponding credentials when withdrawing.
The deposit is deposited, and after a period of time, you can withdraw the deposit through the note, and you can use a new address when withdrawing, so that the transaction cannot be traced back.
Although ETH transactions are not anonymous, because there is always a traceable connection for peer-to-peer transmission, tornado.cash provides a way that anyone can forward the same deposit to it and provide the deposit certificate, and then provide it when the depositor provides it. Try to remove this connection by transferring tokens to the depositor when depositing the certificate.
How to realize anonymous token transfer in blockchain transparent transmission environment
Merkle Tree is used in the specific implementation of tornado.cash. Each time the user makes a deposit, the user will call insert to insert nodes into the Merkle Tree (deposit certificate).
Finally, a certificate of deposit is given after adding the Merkle Tree leaf node.
When the depositor is withdrawing money, he can withdraw it by providing the credentials, but some people here can’t help but ask, as if the zero-knowledge proof is not reflected?
In fact, when depositing coins, the data that is actually provided is:
When withdrawing, the data provided by the withdrawer is decrypted through note to become the following parameters
_proof: proof of deposit
_root: Indicates which Merkle Tree root is at
_nullifierHash: Indicates whether to invalidate, if set to true, the deposit has been used
_recipient : The address of the token recipient when withdrawing
The incoming data is filled in according to the decryption of the note returned after the deposit, which is equivalent to the _proof, _root, and _nullifierHash returned after the deposit during the transaction process to prove your deposit, which is zero Demonstration of knowledge proof.
At the code level, how to prove this deposit through _proof, _root, _nullifierHash?
Here we will pay attention to the withdraw function:
Three parts of data are used when withdrawing, _root indicates the corresponding Merkle Tree, and _nullifierHash also indicates whether the deposit is used.
A separate validator contract is used in the final deposit verification phase, deployed at this address.
https://etherscan.io/address/0xce172ce1f20ec0b3728c9965470eaf994a03557a#code
The key function verifyProof is a specific implementation of zero-knowledge verification. After loading Proof, input(uint256(_root), uint256(_nullifierHash), uint256(_recipient), uint256(_relayer), _fee, _refund) are loaded into vk_x in turn And hand it over to Pairing.pairing for verification. The specific code is implemented as follows:
After passing the verification (confirmed that the deposit has been deposited and the deposit has not been withdrawn), the withdrawal flag is set to true and the _processWithdraw function is used to withdraw assets.
The specific algorithm is described as follows
To get the coin (k, r) at position i in the tree, the user does the following:
The smart contract verifies the authenticity and uniqueness of the _nullifierHash hash. In the case of successful verification, it sends (N−f) to the specified address and adds h to the hash list with true.
Sum up
Tornado improves transaction privacy by breaking the on-chain ties between addresses using a smart contract that accepts ETH deposits that can then be withdrawn by different addresses. Users are required to provide the hash of the secret when depositing, and then provide a zkSnark proof when withdrawing, showing knowledge of the secret without revealing the secret or the previous deposit itself. This decouples withdrawals from deposits.
And is this enough anonymity? Obviously not.
In the process of deposit and withdrawal, proxy and other means should still be used to hide their own network layer data and other information. ISPs can record the timestamps of data packets sent to the relay layer and associate them with the withdrawal transaction timestamps.
The problem of the deposit and withdrawal time interval, if the deposit and withdrawal time interval is short, it may lead to the time correlation of the deposit and withdrawal transactions, resulting in the reduction of anonymity. Therefore, the official recommendation is to perform the withdrawal operation after a period of time after the deposit.
In addition, in other currency mixing services, only one recall contract call may be designed. Here, if the contract needs to be called directly and does not involve the parameter transfer of the receiving address to withdraw from a new address, it must be executed from a newly generated address. The withdrawal function withdraws the transaction, then the user needs to have some ETH in it to pay for gas. But the source of this ETH (usually an exchange) would undermine Tornado’s privacy. So the preferred alternative is to use the repeater network again.
The original active payment of gas needs to rely on the purchase of ETH on a centralized exchange after KYC, and the alternative aims to reduce this on-chain user experience friction by shifting the user’s burden to the repeater, the cost of which is determined by the wallet Provider on-chain/off-chain and/or user off-chain compensation.
Zero-knowledge proof can hide and off-chain the original transparent data (_commitment) (the inaccessibility of note), but the privacy and security in the process of off-chain and on-chain are not protected by tornado.cash, and you still need to make some protection by yourself .
After going off the chain, restore the proof data through the note (_proof, [uint256(_root), uint256(_nullifierHash), uint256(_recipient), uint256(_relayer), _fee, _refund])), the credential note is to restore your R(_Root) , h(_nullifierHash), A(_recipient), f(fee), P(_proof), must not be lost or forgotten.
Finally, the proof of the deposit is made and transferred to a new address, thus breaking the effect of the transparent data connection in the transfer.
Beaver Finance team up experienced security experts on building our system and would continuously share our findings on DeFi security topics.
Stay Alert, Stay Safe!
