API function specifications
The functions exposed by the TFHE
Solidity library come in various shapes and sizes in order to facilitate developer experience. For example, most binary operators (e.g., add
) can take as input any combination of the supported data types.
In the fhEVM
, FHE operations are only defined on same-type operands. Implicit upcasting will be done automatically, if necessary.
Most binary operators are also defined with a mix of ciphertext and plaintext operands, under the condition that the size of the plaintext operand is at most the size of the encrypted operand. For example, add(uint8 a, euint8 b)
is defined but add(uint32 a, euint16 b)
is not. Note that these ciphertext-plaintext operations may take less time to compute than ciphertext-ciphertext operations.
asEuint
asEuint
The asEuint
functions serve three purposes:
verify ciphertext bytes and return a valid handle to the calling smart contract;
cast a
euintX
typed ciphertext to aeuintY
typed ciphertext, whereX != Y
;trivially encrypt a plaintext value.
The first case is used to process encrypted inputs, e.g. user-provided ciphertexts. Those are generally included in a transaction payload.
The second case is self-explanatory. When X > Y
, the most significant bits are dropped. When X < Y
, the ciphertext is padded to the left with trivial encryptions of 0
.
The third case is used to "encrypt" a public value so that it can be used as a ciphertext. Note that what we call a trivial encryption is not secure in any sense. When trivially encrypting a plaintext value, this value is still visible in the ciphertext bytes. More information about trivial encryption can be found here.
Examples
asEbool
asEbool
The asEbool
functions behave similarly to the asEuint
functions, but for encrypted boolean values.
Arithmetic operations (add
, sub
, mul
, div
, rem
)
add
, sub
, mul
, div
, rem
)Performs the operation homomorphically.
Note that division/remainder only support plaintext divisors.
Examples
Bitwise operations (AND
, OR
, XOR
)
AND
, OR
, XOR
)Unlike other binary operations, bitwise operations do not natively accept a mix of ciphertext and plaintext inputs. To ease developer experience, the TFHE
library adds function overloads for these operations. Such overloads implicitely do a trivial encryption before actually calling the operation function, as shown in the examples below.
Examples
Bit shift operations (<<
, >>
)
<<
, >>
)Shifts the bits of the base two representation of a
by b
positions.
Examples
Rotate operations
Rotates the bits of the base two representation of a
by b
positions.
Examples
Comparison operation (eq
, ne
, ge
, gt
, le
, lt
)
eq
, ne
, ge
, gt
, le
, lt
)Note that in the case of ciphertext-plaintext operations, since our backend only accepts plaintext right operands, calling the operation with a plaintext left operand will actually invert the operand order and call the opposite comparison.
The result of comparison operations is an encrypted boolean (ebool
). In the backend, the boolean is represented by an encrypted unsinged integer of bit width 8, but this is abstracted away by the Solidity library.
Examples
Multiplexer operator (select
)
select
)This operator takes three inputs. The first input b
is of type ebool
and the two others of type euintX
. If b
is an encryption of true
, the first integer parameter is returned. Otherwise, the second integer parameter is returned.
Example
min
, max
min
, max
Returns the minimum (resp. maximum) of the two given values.
Examples
Unary operators (neg
, not
)
neg
, not
)There are two unary operators: neg
(-
) and not
(!
). Note that since we work with unsigned integers, the result of negation is interpreted as the modular opposite. The not
operator returns the value obtained after flipping all the bits of the operand.
NOTE: More information about the behavior of these operators can be found at the TFHE-rs docs.
Generating random encrypted integers
Random encrypted integers can be generated fully on-chain.
That can only be done during transactions and not on an eth_call
RPC method, because PRNG state needs to be mutated on-chain during generation.
Example
ACL (allow
, allowTransient
, isAllowed
, isSenderAllowed
)
allow
, allowTransient
, isAllowed
, isSenderAllowed
)Allow an address to use a ciphertext, which includes computation, decryption, and reencryption. The allow
function will permanently store the allowance in a dedicated contract, while allowTransient
will temporarily store it in transient storage.
Example
ACL verification
To verify whether an address is allowed, isAllowed
will return true if the specified address has permission. isSenderAllowed
is similar but uses msg.sender
as the address.
NOTE: These functions will return true if the ciphertext is authorized, regardless of whether the allowance is on the ACL contract or in transient storage.
Example
Last updated