Partnered With:

Adding privacy to smart contracts isn't easy

Read this article in 30 Minutes

Why is it not easy to add privacy features to Ethereum contracts?

Original title: "Dry goods | It is not easy to add privacy to smart contracts"

Original source: Ethereum enthusiasts

< /p>

For users, the privacy protection of ordinary transactions (Translator's Note: The text is sometimes referred to as private transactions for short) is basically a solved problem (although research is still Some challenges remain). If we want to transfer cryptocurrencies without revealing the account balance or transfer amount, we have acceptable options like Zcash or Monero. However, privacy protection is still an unsolved problem for decentralized applications or smart contracts.

What makes smart contracts and ordinary transactions different in terms of input/output (I/O) privacy protection different?

In this article, we will decipher the challenges of extending privacy protection from ordinary transactions to smart contracts. To this end, we will examine common cryptographic tools applied to privacy coins and explore why these tools are less suitable for more complex privacy applications. Finally, we briefly describe some recently proposed smart contract privacy protection schemes.

Definition of Privacy Protection

What exactly does "privacy protection" mean?

We will define privacy protection in terms of functions. For example, we can think of transactions as functions that take as input an account balance and a transfer amount. It then outputs the updated balance.

- Figure 1: The transaction process is represented by a function. -

(To achieve privacy protection) we can consider the input and output of the hidden function. In terms of transactions, this allows us to hide account balances and transfer amounts. Would you be willing to disclose your account balance and transfer history? Probably not. Therefore, we at least support I/O privacy protection for functions (and subsequently smart contracts).

- Figure 2: I/O of the hidden function. -

We can also consider hiding the caller information of the function. Sometimes function inputs leave clues about the identity of the function caller. In practice, hiding the input and output of a function is often combined with hiding the identity of the function's caller.

- Figure 3: Hiding the function caller. -

Finally, we can consider hiding the function itself. This is less common in the world of cryptocurrencies, where it is often combined with input/output of hidden functions.

- Figure 4: Hiding the function itself. -

When you see the word "privacy protection" in this article, please take it as an umbrella term referring to At least something that supports I/O privacy protection .

Okay, but where do we use privacy protection?

We can consider the privacy protection of ordinary transactions to be solved (at least in terms of feasibility, and scalability is another story), so let's move directly to privacy protection for smart contracts.

However, let’s take a detour and review Ethereum...

Ethereum supports user-defined contracts, which are executed in the form of code (that is, "smart contracts"). These contracts are written in Ethereum's own Turing-complete language and pay some (preset) fee for each operation performed. Therefore, a transaction fee is attached to each transaction to incentivize miners to package transactions.

App privacy protection

Smart contracts allow us to build a wealth of applications on the blockchain - from decentralized exchanges (DEX) where users can trade various cryptocurrencies and their derivatives, to allowing stakeholders to vote on proposals Decentralized Autonomous Organization (DAO).

I don't think it's necessary to go into a long story about why a DAO needs privacy; in real life, voting is usually done privately Yes, so it's also very reasonable to want to hide our virtual votes.

On the other hand, the privacy protection of decentralized exchanges needs to be explained. Front-running is a problem for both centralized and decentralized exchanges. In the blockchain world, front-running traders keep a close eye on the submitted orders and jump the queue by paying higher transaction fees (bribing miners). This allows Eve, a front-runner trader, to buy the security that Bob wants to buy before Bob, and then sell it to Bob at a higher price. Closed auctions are a possible solution to this problem. For interested readers, more information about front running on decentralized exchanges can be found here.

However, Ethereum smart contracts do not provide any form of privacy protection out of the box. All information is publicly viewable - the input/output of the contract, the functions of the contract, participating users, etc. Adding privacy protection to Ethereum smart contracts is not an easy task, because Ethereum was not designed to support privacy protection from the beginning. Although private transactions (via 1, 2) can be realized on Ethereum, more complex privacy protection operations are often too expensive, even exceeding the fee limit (ie gas limit) of a single block of Ethereum, so that it cannot be realized.

Can't we design a new cryptocurrency that supports privacy protection for any function from the start ? After all, that's what Zcash and Monero do.

It is unclear how to support arbitrary functions in cryptocurrencies (e.g. voting and exchanges require function) I/O privacy protection. To understand these challenges, we need to examine how cryptocurrencies support private transactions.

The road to privacy protection

Let's first examine cryptographic tools for general transaction I/O privacy protection. We will focus on cryptocurrencies with an account model rather than a UTXO model. Account models are especially useful in scenarios where smart contracts are supported, but account models are not necessary for private computation (as we will see later).

Tool 1: Homomorphic addition

Large Most privacy-preserving schemes for cryptocurrencies rely on encryption or commitment schemes with additive homomorphisms . For simplicity, we'll focus on encryption schemes, but the same principles apply to commitment schemes.

Under the additive homomorphic encryption scheme, we have the following equation: Enc(a) + Enc(b) = Enc(a + b).

Therefore, the additive homomorphic encryption scheme allows anyone to verify the validity of the transaction like this: Enc(balance) + Enc(transfer amount) = Enc(balance + transfer amount) (the sum of the encrypted value of the balance and the encrypted value of the transfer amount is exactly equal to the encrypted value of the sum of the two).

- Figure 5: Alice does not disclose the account balance or transfer amount Next Transfer. -

Alice has her own public key—pk_a. She encrypts the account balance bal_a with her public key (so that only she knows the account balance). We denote her encrypted balance by β_a, β_a = Enc(pk_a, bal_a). Alice's public key pk_a and encrypted balance β_a are public on the Internet, and anyone can view it.

The same is true for Bob; he also has his own public key pk_b, the account balance bal_b that only he knows, and The balance β_b encrypted by his public key, β_b = Enc(pk_b, bal_b).

If Alice wants to transfer money to Bob without revealing the transfer amount (amnt) or her own account balance , she only needs to publish the transfer amount encrypted with her own public key, and the transfer amount encrypted with Bob's public key. We denote these values by c_a = Enc(pk_a, amnt) and c_b = Enc(pk_b, amnt) respectively.

Anyone can now calculate the updated balance. Alice's updated account balance is β_a - c_a, and Bob's updated account balance is β_b + c_b.

Wait a minute! If all these values are encrypted, how do we know if there is enough money in Alice's account to pay for the transfer of amnt amount? How do we know whether the encrypted amounts of c_a and c_b are the same?

This is where we will use our next tool - zero-knowledge proof.

Tool 2: Zero Knowledge Proof (ZKP)

In order to ensure that Alice did not cheat in the above transaction, she needs to attach a proof to the transaction. This proof needs to show that she has enough funds in her account to complete the transaction, that she did not transfer a negative amount to Bob (whether by accident or maliciously), and that c_a and c_b indeed encrypted the same amount.

Of course, Alice does not want to disclose her real account balance and transfer amount; therefore, she attaches a zero-knowledge Proving π convinces all other users that the necessary conditions have been met without revealing any additional information (such as her account balance or transfer amount).

Now putting all the tools together...

- Figure 6: Now attach the necessary ZKP to private transactions -

Alice encrypts the transfer amount with her and Bob's public keys respectively, and obtains c_a and c_b. She provides a ZKP, π, proving that she did not cheat in the transaction. Miners will verify that all necessary conditions are met and that the ZKP is valid. They then update Alice's and Bob's encrypted balances respectively using homomorphic addition: β_a = β_a - c_a, β_b = β_b + c_b. Note that while users provide encrypted inputs and a ZKP, miners are responsible for performing computations and updating encrypted balances. In a blockchain, we assume that most miners are honest, so we know they will update Alice's and Bob's balances correctly.

Note: This is a greatly simplified explanation (e.g. leaving out the randomness needed for cryptographic security)

The challenge of extending the privacy protection technology of ordinary transactions to smart contracts

So we have just seen that we can perform transactions with hidden inputs and outputs. So can we use the technology used in privacy transactions to support application I/O privacy protection? In other words:

Are private computing and private transactions different? If yes, why?

Question 1

It should be noted that private transactions need to meet the set conditions to be correct (ie, the sender must have sufficient funds, the transfer amount must be a positive number, etc.). How can we figure out what conditions an arbitrary contract needs to satisfy? These conditions are obviously application specific. In voting, we might want to prove that our hidden votes were cast within the correct range, and for auctions, we might want to prove that we have enough funds in our account for closed bids.

Potential Solution to Problem 1

This problem is not that serious; it just requires more work from the user. Developers of decentralized applications must specify what conditions their particular application needs to meet and communicate these conditions to users. In order to be able to prove a wide variety of conditions, we may want to support some general ZKP in the scheme. The so-called universal ZKP is able to prove arbitrary statements (unlike those currently used in Zcash, which are non-universal).

Question 2

In normal transactions, we only operate on values that belong to the same user (i.e. are encrypted with the same key). For example, in Figure 6, the miner adds the balance encrypted with Alice's public key to the transfer amount encrypted with Alice's public key. What if we want to perform private computations on input values belonging to different users? This is not such a far-fetched requirement, such as when we consider privacy protection for voting.

Potential Solution to Problem 2

It is unclear how to support computation of input from different users without revealing the plaintext of the input to each other. There are some advanced cryptographic elements (such as secure multi-party computation and multi-key based fully homomorphic encryption FHE) that allow users to perform computations on inputs encrypted with different keys. However, these solutions are very costly and have many disadvantages. In the context of cryptocurrencies, no one currently seems to have a good solution to this problem (besides sharing the plaintext with other users participating in the computation and then encrypting it under the same key).

Question 3

Ordinary transactions only need to Stateful addition, because we only need to add the encrypted transfer amount to the encrypted balance. What if we want to do more complex calculations, possibly involving multiplication?

Potential Solution to Problem 3

Homomorphic multiplication allows us to multiply encrypted inputs such that Enc(a) * Enc(b) = Enc(a * b) . With homomorphic addition and multiplication, we can represent arbitrary polynomial functions. So, we naturally thought of this question:

Can we support homomorphic multiplication?

An encryption scheme that can support both homomorphic addition and multiplication is fully homomorphic encryption ( FHE). With FHE, we can still follow the model depicted in Figure 6. That is, the user specifies a cryptographic input, a function to run, and a ZKP proving that the cryptographic input satisfies the necessary conditions. Miners are able to verify ZKP. They operate directly on user-supplied ciphertext using homomorphic addition and multiplication.

Unfortunately, the FHE scheme uses lattice-based encryption, which is (currently) incompatible with cipher The ultra-efficient ZKPs used in academic currencies are not compatible. We've written about FHE and its problems in the past. Currently, no one has proposed a FHE-based solution due to some shortcomings of FHE.

So we are now left with only two ways to solve problem 3.

Accept the status quo that we can only support homomorphic addition and follow the private transaction model.

- Figure 7: Follow the privacy transaction model-

Here, the user provides encrypted input and a ZKP proving that their input satisfies some specified conditions for a particular application. Miners verify the proof, using homomorphic addition to operate on the input. Note that functions applied to the input can only be expressed additively. Therefore, as long as the function only needs to use homomorphic addition, we can ask the miner to execute any function that satisfies this condition on our encrypted input. This is the approach taken by Zether .

Require users to calculate offline. This way we don't need to support homomorphic multiplication for encryption/commitments.

- Figure 8: Outsourcing work to users-

< p>

Here, we ask user Alice to put almost all calculations on plaintext offline. She will publish the encrypted input and encrypted output of the computation. Because the calculation is done offline (so we don't know if Alice is honest), she also needs to provide a ZKP to prove that the calculation process is correct. Note that this step is unnecessary for private transactions, since miners will perform computations, and we assume that most miners are honest. As far as the application is concerned, she may also need another ZKP, proving that the conditions specified by the application have been met. All a miner needs to do is verify that the ZKP is valid and then agree to the state change proposed by Alice. This is the approach taken by Zexe and Zkay .

I will not discuss here which method (Fig. 7 vs. Fig. 8) is superior; just to illustrate them are different

Privacy protection of smart contracts

We have already talked about some problems in the privacy protection of supporting arbitrary functions in the blockchain. Now let's take a look at the construction of some existing schemes.

If what has been said before is not clear enough, let me reiterate that there is still a long way to go in this field to solve the problem Way to go. The papers designing these constructs (i.e. Zether, Zkay, Zexe) were all published in the past two years.

Zether is a private transaction solution built on Ethereum. It can be extended to support I/O privacy protection for limited smart contracts—that is, those contracts that can be represented by homomorphic addition. This allows us to perform simple closed auctions (assuming bidders will buy all units at once) and private voting (assuming voting options are either 0 or 1). Unfortunately, due to the limitation of gas, it is currently only possible to hide user balances and transfer amounts in transactions on Ethereum. Unlike the next two constructions, Zether uses a "transparent" ZKP (i.e. the ZKP does not require a trusted startup setup).

Zkay also extends the design of Ethereum to support the privacy protection of smart contracts. They rely on ZKP to ensure the correctness of privacy calculations, so that most of the work can be left to users to complete offline. Therefore, this design choice enables them to support more types of functions than Zether.

Zexe is an attempt to extend the Zcash design to support arbitrary scripts. Unlike the former two, Zexe can also support the privacy protection of the function itself.

* Zkay and Zexe (as mentioned earlier) use a ZKP scheme with a trusted setup . However, these ZKP schemes can of course be replaced by schemes that do not require a trusted setup.

** In a blockchain scenario, I/O privacy protection seems to make more sense than function privacy protection, because users will likely want to audit the contract before deciding whether to participate in the contract.

Note that there are other constructs for smart contract privacy protection (i.e. Ekiden, Hawk, Arbitrum), but these all require some kind of semi-trusted manager or trusted hardware.

Most privacy-preserving schemes for smart contracts require additional security assumptions—whether trusted setup, quasi-trusted The manager is also trusted hardware. However, ZKPs are a rapidly developing field, and more efficient and transparent constructions will likely be created.

Expect

The exploration of privacy protection in smart contracts raises a lot of interesting theories when it comes to expressiveness, trust and efficiency and practical challenges. Now, it's hard to say which, if any, of the approaches represented in Figure 7 or Figure 8 is likely to win out in privacy calculations for blockchains. In addition, it is also interesting to see whether the progress of fully homomorphic encryption can be transformed into the blockchain to solve problem 3 in the future.