Decryption
The decryption operation is asynchronous. To use it, your contract must extend the GatewayCaller
contract. This will import automatically the Gateway
solidity library as well. See the following example:
Note that a GatewayContract
contract is already predeployed on the fhEVM testnet, and a default relayer account is added through the specification of the environment variable PRIVATE_KEY_GATEWAY_RELAYER
in the .env
file. Relayers are the only accounts authorized to fulfil the decryption requests. However GatewayContract
would still check the KMS signature during the fulfilment, so we trust the relayer only to forward the request on time, a rogue relayer could not cheat by sending fake decryption results.
The interface of the Gateway.requestDecryption
function from previous snippet is the following:
The first argument, ct
, should be an array of ciphertexts handles which could be of different types, i.e uint256
values coming from unwrapping handles of type either ebool
, euint4
, euint8
, euint16
, euint32
, euint64
or eaddress
. ct
is the list of ciphertexts that are requested to be decrypted. Calling requestDecryption
will emit an EventDecryption
on the GatewayContract
contract which will be detected by a relayer. Then, the relayer will send the corresponding ciphertexts to the KMS for decryption before fulfilling the request.
callbackSelector
is the function selector of the callback function which will be called by the GatewayContract
contract once the relayer fulfils the decryption request. Notice that the callback function should always follow this convention, if passSignaturesToCaller
is set to false
:
Or, alternatively, if passSignaturesToCaller
is set to true
:
Notice that XXX
should be the decrypted type, which is a native Solidity type corresponding to the original ciphertext type, following this table of conventions:
ebool
bool
euint4
uint8
euint8
uint8
euint16
uint16
euint32
uint32
euint64
uint64
eaddress
address
Here callbackName
is a custom name given by the developer to the callback function, requestID
will be the request id of the decryption (could be commented if not needed in the logic, but must be present) and x_0
, x_1
, ... x_N-1
are the results of the decryption of the ct
array values, i.e their number should be the size of the ct
array.
msgValue
is the value in native tokens to be sent to the calling contract during fulfilment, i.e when the callback will be called with the results of decryption.
maxTimestamp
is the maximum timestamp after which the callback will not be able to receive the results of decryption, i.e the fulfilment transaction will fail in this case. This can be used for time-sensitive applications, where we prefer to reject decryption results on too old, out-of-date, values.
passSignaturesToCaller
determines whether the callback needs to transmit signatures from the KMS or not. This is useful if the dApp developer wants to remove trust from the Gateway service and prefers to check the KMS signatures directly from within his dApp smart contract. A concrete example of how to verify the KMS signatures inside a dApp is available here in the requestBoolTrustless
function.
WARNING: Notice that the callback should be protected by the
onlyGateway
modifier to ensure security, as only theGatewayContract
contract should be able to call it.
Finally, if you need to pass additional arguments to be used inside the callback, you could use any of the following utility functions during the request, which would store additional values in the storage of your smart contract:
With their corresponding getter functions to be used inside the callback:
For example, see this snippet where we add two uint256
s during the request call, to make them available later during the callback:
When the decryption request is fufilled by the relayer, the GatewayContract
contract, when calling the callback function, will also emit the following event:
The first argument is the requestID
of the corresponding decryption request, success
is a boolean assessing if the call to the callback succeeded, and result
is the bytes array corresponding the to return data from the callback.
In your hardhat tests, if you sent some transactions which are requesting one or several decryptions and you wish to await the fulfilment of those decryptions, you should import the two helper methods asyncDecrypt
and awaitAllDecryptionResults
from the asyncDecrypt.ts
utility file. This would work both when testing on an fhEVM node or in mocked mode. Here is a simple hardhat test for the previous TestAsyncDecrypt
contract (more examples can be seen here):
You should setup the gateway handler by calling asyncDecrypt
at the top of the before
block. Notice that when testing on the fhEVM, a decryption is fulfilled usually 2 blocks after the request, while in mocked mode the fulfilment will always happen as soon as you call the awaitAllDecryptionResults
helper function. A good way to standardize hardhat tests is hence to always callawaitAllDecryptionResults
which will ensure that all pending decryptions are fulfilled in both modes.
Last updated