Transaction flow
The following diagram is a high level description of the flow of encrypted data from the end user to the contract, through a privacy preserving computation, and back to the user. The actual concepts and steps are discussed below.
Network key: The network maintains a secret sharing of a symmetric key that "belongs" to the network. This means that every secret state exists in the form of a ciphertext encrypted under that key. The network key is generated in a distributed fashion once when the network is deployed, such that no single node can see the key in full, rather, each node has a 'share' of that key.
Client key: Apart of the usual and beloved signing keys that is generated and kept secretly by users, in the gcEVM each user is also assigned a symmetric encryption key (this is an AES key). Being a symmetric key means that it is being used for both encryption and decryption. The key is generated by the network in a distributed fashion (so no single network operator can see it) and is securely delivered only to the user. To initiate that, a user has to send an onboard transaction that will conclude with a symmetric key being assigned to that specific user (EOA) and only that user knows that key in full. Users that do not submit secret inputs or are not expected to receive secret output can simply use the network just like any other EVM-compatible chain, without being bothered with the onboarding transaction.
Submitting a transaction with secret data: Once the user obtained its symmetric key, it is imperative that same key is being secret shared by the gcEVM nodes (the MPC nodes). To send a secret argument to a contract, the user encrypts that argument using its own symmetric key. When that transaction arrives in the gcEVM (i.e., it resides inside a sequenced block) it will first get transformed into a garbledtext - a form of ciphertext suitable to be securely processed inside a garbled circuit.
Processing secret data: Just like new inputs coming from users, any value that takes part in a computation that has to be kept private is first being transformed into a garbledtext. This applies to state data too; namely, ciphertexts that "belong" to the contract (and are therefore encrypted under the network key). Once all needed information is in the garbledtext form, the garbled circuits come into play and perform the actual computation. From the developer's perspective there is almost no difference between a contract written to a normal EVM and a contract written to the gcEVM, see supported Data Types and Secure Operations.
Outputs: Once computation over secret data is complete, the developer can choose on whether to reveal outputs to everyone, to a specific user, or to keep them secret and store them back at the contract. Revealing an output to everyone can be done by calling the Decrypt function, whereas encrypting to the user or to the contract involves calling the OffboardToUser and Offboard, respectively. OffboardToUser transform the respective garbledtext into an encryption under the user's key and Offboard transform that garbledtext into an encryption under the network key (again, without any MPC node actually knowing that key in full).
Last updated