# On Verifiable TEE and Slashable Threshold Networks

### Multi-player FHE Application

Most of the FHE-based applications aims to achieve Private Shared State. This is an encrypted state on which everyone can perform homomorphic operations. An example of such application is Private Auction. Each user can encrypt their bid $E(bid_1) = ct_1$, $E(bid_2) = ct_2$. The Auction Manager (or, even, a smart contract) can perform the homomorphic operation to evaluate which one is the highest $max(ct_1, ct_2) = ct_?$. The highest bid $ct_?$ is now the Private Shared State. Each new bidder will then "add" their encrypted bid to the Private Shared State. FHE allows to evaluate which bid is the highest without having to decrpyt each individual bids first. Note that the homomorphic operation can be performed by anyone as it doesn't require access to any secret in order to be performed correctly.

The necessary condition to perform homorphic operations between two ciphertexts is that the ciphertexts must be encrypted under the same public key. Similarly, the secret key associated to the public key is needed to decrypt the ciphertext. In the described application, this would be the highest (encrypted) bid after the auction is over.

You might now be thinking on how to design such application. If each user would encrypt their bid with their own public key, the homomorphic operation wouldn't be possible. The only way to achieve this is to encrypt each bid under the same public key. Picking the public key of the Auction Manager would suffice to achieve the goal of the application. The problem here is that the Auction Manager would be able to decrypt each bid while the aution is still open. In this scenario, you have to trust the Auction Manager to not decrypt the partial states and use this information to influence the auction. I'd argue that you could create a Private Auction application with the same trust assumption with less complex technologies than FHE.

The de-facto standard solution ([ZAMA](https://github.com/zama-ai/fhevm/blob/main/fhevm-whitepaper.pdf)) is to rely on a network of nodes where each of them stores a secret key share. The associated public key is used to perform encryption operations by users. In order to perform decryption, the nodes has to come together and contribute to the decryption prodcess. This is usually performed in a threshold setting in which $t$ out of $n$ nodes are required to perform such decryption.

### Problem

In the latest solution, users would need to trust that $t$ members of the network would not join their forces and decrypt state maliciously. In the Private Auction application, for example, they could still come together and decrypt the Private State before the Auction is over. The worse thing about this design is that you cannot even rely on staking incentives. Staking-based designs rely on the possibility to slash actors in the case they behave not accordingly to the rules of a protocol. In Threshold Decryption Networks, there's no way to spot a malicious set of network nodes as this malicious act doesn't leave any cryptographically verifiable trace that can be used to slash them.

### Proposed Solution

The propose solution is to enforce the nodes to use TEE as enclave to protect their secret key share. By design, the TEE doesn't allow the node to access the secrey key share by any matter.

When required by the protcol, each node will join the threshold network and perform individual decryption using the secret key share protected inside their TEE. Up to now, the only difference is that the key is enforced to live inside a TEE.

TEE are able to provide Remote Attestations, this is a cryptographic proof that allows to prove to a remote party (typically a remote server) data related to the TEE.

My idea to use these Remote Attestation to monitor the behaviour of a node within the network. In this setting, each would be able to produce a Remote Attestation every time the perform a decryption operation. In that case, if the malicious node performs a decryption share when this is not required by the protocol, the TEE would produce a Remote Attestation of the crime. This Remote Attestation can be used to slash the stake of the node.

### Flaw in the Proposed Solution

In this scenario, nothing prevents a malicious node from calling the decryption API of the TEE to generate a decryption share and not report the Remote Attestation.

### An Idea to Solve That

A solution for that might be to allow chaining of these Remote Attestations for example by attacching an incremental nonce to them. In this way, the malicious node that doesn't report the crime would can be detected as the next (valid) Remote Attestation report will have a missing nonce.