fhEVM v0.2.0: New Operators, Simpler Syntax and Optimized Performances

October 17, 2023

Levent Demir

This is also a heading
This is a heading
This is also a heading

Since the release of Zama's fhEVM white paper and alpha code a few weeks ago, the Zama team has released many minor versions. The latest to date (v0.2.0) introduces a comprehensive set of operators designed to provide robust functionality and versatility.

Supported types

The following encrypted data types are now supported:

[.c-inline-code]ebool[.c-inline-code]
[.c-inline-code]euint8[.c-inline-code]
[.c-inline-code]euint16[.c-inline-code]
[.c-inline-code]euint32[.c-inline-code]

The equivalent signed types (and 64 bits) are coming soon.

Arithmetic operators

Some operators are overloaded with the usual symbol, below is an example for addition overload:

# the transfer method received amount (euint32) 
balances[to] = balances[to] + amount;
# instead of
# balances[to] = TFHE.add(balances[to], amount);

Addition ([.c-inline-code]add[.c-inline-code])
Subtraction ([.c-inline-code]sub[.c-inline-code])
Multiplication ([.c-inline-code]mul[.c-inline-code])
Division ([.c-inline-code]div[.c-inline-code]) (only with plaintext divisor)
Remain ([.c-inline-code]rem[.c-inline-code]) (only with plaintext divisor)

Bitwise operators

The bitwise operations do not natively accept a mix of ciphertext and plaintext inputs, but the TFHE library adds function overloads to handle those cases.

// a & b
function and(euint8 a, euint8 b) internal view returns (euint8)

// implicit trivial encryption of `b` before calling the operator
function and(euint8 a, uint16 b) internal view returns (euint16)

Bitwise AND ([.c-inline-code]and[.c-inline-code])
Bitwise OR ([.c-inline-code]or[.c-inline-code])
Bitwise XOR ([.c-inline-code]xor[.c-inline-code])

Bit shift operators

The shift right operator can be used to perform division by powers of 2.

Shift Right ([.c-inline-code]shr[.c-inline-code])
Shift Left ([.c-inline-code]shl[.c-inline-code])

Comparison operators

The result of comparison operations is an encrypted boolean (ebool). In the backend, the boolean is represented by an encrypted unsigned integer of bit width 8, but this is abstracted away by the Solidity library.

Equal ([.c-inline-code]eq[.c-inline-code])
Not Equal ([.c-inline-code]ne[.c-inline-code])
Greater Than or Equal ([.c-inline-code]ge[.c-inline-code])
Greater Than ([.c-inline-code]gt[.c-inline-code])
Less Than or Equal ([.c-inline-code]le[.c-inline-code])
Less Than ([.c-inline-code]lt[.c-inline-code])

Additional operators

Minimum ([.c-inline-code]min[.c-inline-code])
Maximum ([.c-inline-code]max[.c-inline-code])
Negation ([.c-inline-code]neg[.c-inline-code])
Logical NOT ([.c-inline-code]not[.c-inline-code])

Now that we reviewed the common operators, let's deep dive into FHE specific ones.

CMUX operator

This operator offers the ability to assign a value among two possibilities based on a condition, while preserving the encrypted state of the data.

This operator takes three inputs. The first input [.c-inline-code]b[.c-inline-code] is of type [.c-inline-code]ebool[.c-inline-code] and the two others of type [.c-inline-code]euintX[.c-inline-code]. If [.c-inline-code]b[.c-inline-code] is an encryption of [.c-inline-code]true[.c-inline-code], the first integer parameter is returned. Otherwise, the second integer parameter is returned.

// if (b == true) return val1 else return val2
function cmux(ebool b, euint8 val1, euint8 val2) internal view returns (euint8) {
  return TFHE.cmux(b, val1, val2);
}

Generating random encrypted integers

Random encrypted integers can be generated fully on-chain.

WARNING: Don't use in production! Integers are currently generated in the plain via a PRNG whose seed and state are public, while the state is on-chain. An FHE-based PRNG is coming soon, where the seed and state will be encrypted.

// Generate a random encrypted unsigned integer `r`.
euint32 r = TFHE.randEuint32();

Decrypt

Decryption currently occurs in the validator, which has full access to the private key (note that a threshold decryption protocol is under development). This function can potentially lead to information leakage, therefore, you should consider using [.c-inline-code]cmux[.c-inline-code] instead for safer operations.

function bid(bytes calldata encryptedBid) internal {
  euint32 bid = TFHE.asEuint32(encryptedBid);
  ebool isAbove = TFHE.le(bid, highestBid);

  // Be sure that the bid is above current highestBid
  require(TFHE.decrypt(isAbove));

  // Replace highest bid
  highestBid = bid;
}

Reencrypt

Remember that all inputs are encrypted under the network public key. To return a user specific data, we need to reencrypt the given data under the user-provided public key.

// returns the decryption of `ciphertext`, encrypted under `publicKey`.
function reencrypt(euint32 ciphertext, bytes32 publicKey) internal view returns (bytes memory reencrypted)

Optimize performance using optReq

Instead of interrupting the transaction flow by decrypting conditions at each occurrence, we accumulate these conditions until the end of the transaction and perform a single decryption with [.c-inline-code]optReq[.c-inline-code]. If all conditions are satisfied, state changes are applied. If not, they are reverted. This approach streamlines the process and enhances efficiency.

Note: this efficiency comes at the price of paying the full transaction gas cost if one of the boolean conditions is false.

Finally, you now have the ability to use our specialized Remix instance, designed specifically to handle input encryption, but you can also take advantage of our dedicated Hardhat template, which includes a single-line command for launching a local fhEVM instance.

Additional links

Star Zama's fhEVM Github repository to endorse our work.
Review Zama's fhEVM documentation.
Get support on our community channels.
Help advance the FHE space with the Zama Bounty Program: Create an on-chain game that keeps private states hidden using Zama's fhEVM programmable privacy (15,000€ in prize).

Read more related posts

No items found.

Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world.If two parties have some sort of dealings, then each has a memory of their interaction. Each party can speak about their own memory of this; how could anyone prevent it? One could pass laws against it, but the freedom of speech, even more than privacy, is fundamental to an open society; we seek not to restrict any speech at all. If many parties speak together in the same forum, each can speak to all the others and aggregate together knowledge about individuals and other parties. The power of electronic communications has enabled such group speech, and it will not go away merely because we might want it to.Since we desire privacy, we must ensure that each party to a transaction have knowledge only of that which is directly necessary for that transaction. Since any information can be spoken of, we must ensure that we reveal as little as possible. In most cases personal identity is not salient. When I purchase a magazine at a store and hand cash to the clerk, there is no need to know who I am. When I ask my electronic mail provider to send and receive messages, my provider need not know to whom I am speaking or what I am saying or what others are saying to me; my provider only need know how to get the message there and how much I owe them in fees. When my identity is revealed by the underlying mechanism of the transaction, I have no privacy. I cannot here selectively reveal myself; I must always reveal myself.Therefore, privacy in an open society requires anonymous transaction systems. Until now, cash has been the primary such system. An anonymous transaction system is not a secret transaction system. An anonymous system empowers individuals to reveal their identity when desired and only when desired; this is the essence of privacy.Privacy in an open society also requires cryptography. If I say something, I want it heard only by those for whom I intend it. If the content of my speech is available to the world, I have no privacy. To encrypt is to indicate the desire for privacy, and to encrypt with weak cryptography is to indicate not too much desire for privacy. Furthermore, to reveal one's identity with assurance when the default is anonymity requires the cryptographic signature.We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence. It is to their advantage to speak of us, and we should expect that they will speak. To try to prevent their speech is to fight against the realities of information. Information does not just want to be free, it longs to be free. Information expands to fill the available storage space. Information is Rumor's younger, stronger cousin; Information is fleeter of foot, has more eyes, knows more, and understands less than Rumor.We must defend our own privacy if we expect to have any. We must come together and create systems which allow anonymous transactions to take place. People have been defending their own privacy for centuries with whispers, darkness, envelopes, closed doors, secret handshakes, and couriers. The technologies of the past did not allow for strong privacy, but electronic technologies do.We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can't get privacy unless we all do, we're going to write it. We publish our code so that our fellow Cypherpunks may practice and play with it. Our code is free for all to use, worldwide. We don't much care if you don't approve of the software we write. We know that software can't be destroyed and that a widely dispersed system can't be shut down.Cypherpunks deplore regulations on cryptography, for encryption is fundamentally a private act. The act of encryption, in fact, removes information from the public realm. Even laws against cryptography reach only so far as a nation's border and the arm of its violence. Cryptography will ineluctably spread over the whole globe, and with it the anonymous transactions systems that it makes possible.For privacy to be widespread it must be part of a social contract. People must come and together deploy these systems for the common good. Privacy only extends so far as the cooperation of one's fellows in society. We the Cypherpunks seek your questions and your concerns and hope we may engage you so that we do not deceive ourselves. We will not, however, be moved out of our course because some may disagree with our goals.The Cypherpunks are actively engaged in making the networks safer for privacy. Let us proceed together apace.Onward. By Eric Hughes. 9 March 1993.