Inter-Enclave Synchronization
Last updated
Last updated
To create a decentralized fault-tolerant network of TEE enclaves, they should asynchronously communicate and replicate their confidential state. Whenever an enclave receives, stores, and seals a secret share, it will send a confirmation transaction to the blockchain. When the blockchain receives 5 different confirmations for the same NFT-ID from a cluster, the blockchain will generate an ‘NFT-synced’ event in the current block. Since all enclaves in the network are listening to the blockchain events, as soon as they notice the ‘NFT-synced’ event, they send a request to the original cluster and corresponding slot number for the new secret share (s).
Expirable tokens, confidential signatures, and TLS standards secure the Communication channel of enclaves. However, the enclaves have to prove their genuineness in each secret exchange. That means they should prove that: they are running in verifiable updated (CPU microcodes) hardware, they are running under a secured mechanism of TEE in terms of memory, processing, and storage and finally they are running an updated official code of open-source Ternoa enclave.
These are only possible through a hardware-generated quote in TEE and then verifying it with Intel as the manufacturer. To make the process bulletproof, we inject a signature of some confidential data into the quote before being signed by the hardware key. These injected data will provide critical identity information to the other party that helps establish the trust. Above all at the final stage, the data will be encrypted another time with a temporary public key which is generated securely inside the enclave.
When a new enclave gets registered on the network, it starts discovering the existing clusters and especially the corresponding slots in each cluster to its slot number.
Then it chooses a proper enclave to fetch all of its current stored secret-shares. If the process fails, it goes to another cluster until all the secret shares of available NFT IDs are stored on the new enclave.
Then enclave will be ready to receive new data or synchronize its data to other enclaves.
Enclave should persistently keep track of its latest synchronization state, to be able to recover after downtimes, either because of network connection problems or hardware maintenance, etc.
Down-time may happen to enclaves, either because of planned maintenance or network issues. Back to the online state, enclaves get the current block number from the blockchain, then start crawling the chain looking for minted secret-nft or capsules. The result of the crawling is a list of NFT-IDs whose secret shares should be fetched using the synchronization process we’ve described above.