The execution layer in fhEVM can perform computations on ciphertexts. At some point, it becomes necessary to reveal the actual values of these ciphertexts. However, the private key is managed by the KMS (Key Management System). The question arises: how can we perform asynchronous decryption requests (which make the values public) and re-encryptions (for personal information) when the execution layer and the KMS are decoupled? This is where inclusion proofs come into play.

How to Compute an Inclusion Proof

Verification of the Proof in KMS BC ISC

Notes on Root Hash Verification

This section will be elaborated upon in the future to explain the validation of root hash integrity.

Everything in fhEVM is encrypted, at some point one could need to decrypt somes values. Let's give as illustration a blind auction application. After reaching the end of the auction, one need to discover (only) the winner, here is where a asynchronous decrypt could appear.

How it's working

The Gateway acts as an oracle service: it will listen to decryption request events and return the decrypted value through a callback function. The responsabilities of the Gateway are:

• Listening decryption request from fhEVM that contains a handle h that corresponds to a ciphertext C

• Computing a storage proof P to attest h (i.e. C) is decryptable

• Retrieve C from fhEVM using h as key

• Send a decyption request to TKMS which in turn is running an internal blockchain aka KMS BC

• Wait and listen for decyptionResponse (containing the plaitext and a few signatures from KMS to attest the integrity of the palintext) event from KMS BC

• Return decyptionResponse through the callback function

High level overview of the decryption flow

We allow explicit decryption requests for any encrypted type. The values are decrypted with the network private key.

1. The dApp retrieves the ciphertext from the view function (e.g., balanceOf).

2. The dApp generates a keypair for the user and requests the user to sign the public key.

3. The dApp calls the gateway, providing the ciphertext, public key, user address, contract address, and the user's signature.

4. The dApp decrypts the received value with the private key.