Cloud Enclaves and their Applications in Blockchains

By Wang Kui (

Top cloud computing vendors have recently been actively marketing confidential computing services, i.e., enclaves. Enclaves provide the features of integrity, isolation, data sealing, and attestation, through which relying parties only need to trust the CPU hardware and the code running inside enclaves. The cloud computing vendors and the administrators of enclave instances cannot tamper or peek at the execution inside enclaves.

Blockchains enforce “code is law” by consensus algorithms, while enclaves enforce “code is law” by CPU hardware. The similarity between them hints to us that it’s possible to improve blockchain applications’ security, privacy, and efficiency with enclaves

In this article, we’ll introduce the mainstream enclave solutions of the top cloud computing vendors and discuss several applications which may benefit from enclaves.

Enclave Solutions

  1. A secure cryptoprocessor measures the firmware and hardware of the device. If they are trustable, start the firmware.
  2. The firmware measures the OS. If it is trustable, start it.
  3. The OS measures application programs and starts only the trustable ones.

In the cloud computing era, the vendors still need to make the hardware-software stack secure and trustable. But their customers want more: even if the vendors are evil or their cloud infrastructures are vulnerable, the computing instances and containers are still trustable.

So today’s confidential computing solutions start from some middle point in the hardware-software stack, instead of the bottom. The major server CPU manufacturers, i.e., Intel and AMD, take different choices:

  1. AMD’s SEV technology enables enclaves on top of hypervisors, which contain OS kernel and application programs.
  2. Intel’s SGX technology enables enclaves on top of OSes, which contain only (a part of) one program and one process (with multi-threading).

Currently, Microsoft and Google provide enclaves based on AMD CPUs, while Microsoft and Alibaba provide enclaves based on Intel CPUs. Despite the implementation details, their products all support the following features:

  1. Integrity: a program in the enclave executes exactly as its source code specifies, no party can tamper with it, even the hypervisor and/or OS under it. A hacker or evil administrator with privilege cannot change how the code runs.
  2. Isolation: the program(s) executing context (registers status and DRAM status) cannot be viewed or changed by any other party, even the hypervisor and/or OS under it.
  3. Data sealing: the data written to persistent storage from the programs in an enclave are encrypted and can only be decrypted in the enclave later.
  4. Attestation: after hardware-assistant measurement of the program running in an enclave, the hash digest of the measurement is signed by a key kept by hardware to convince the relying parties that it IS the predefined trustable program running.

When an enclave is providing services on the cloud, the relying parties can trust it even if the cloud computing vendor and its customer who rents and operates the enclave are both dishonest. The human factor threatening the service’s security is reduced dramatically.

Manipulation-proof Random Number Generator

Many applications directly use block hashes as a random source. Block hashes are cheap to use because there is always a hash for every block and no more computation is needed. But block hashes are prone to be manipulated. The block proposer can try different transaction sets and pick a block hash that is most beneficial to it. On PoW chains, this trial process may delay the proposer from successfully mining a block, so there is some potential penalty. On a PoS chain, it is almost riskless for the proposer to try different block hashes.

VRF (verifiable random function) is a special kind of hash function. Using a private key, VRF computes the hash result and proof from the input pre-image. With the corresponding public key and the proof, the hash result can be verified against the pre-image. If an honest party is holding VRF’s private key, then the VRF results of block hashes can be used as fair random numbers, because the validators have no way to know the VRF results before proposing a new block.

An enclave can act as such an honest party: it does exactly as the source code specifies, and never reveal anything it should keep as a secret, including the VRF private key. When a DApp needs the random number corresponding to a block, it queries the enclave for the VRF result and the proof and then verifies them on-chain against the VRF public key and the block hash, i.e., the VRF input. If the check passes, the DApp will have confidence that this random number is not manipulated.

Improve privacy of CoinJoin

CoinJoin’s idea is quite simple: a UTXO-based transaction has multiple inputs and multiple outputs; by combining inputs and outputs from what would otherwise be separate transactions, into one jumbo transaction, the correspondence of the original transaction’s inputs and outputs are obfuscated. Just make your UTXO set undergoes several levels of such jumbo transactions, and an external viewer cannot match the resulting UTXO set owned by you to the original UTXO set.

CoinJoin uses a client-server model. The servers coordinate which users are shuffling and know which user owns which inputs/outputs. This is a risk for privacy because servers may leak their knowledge. How to alleviate this risk? Dash coin uses multiple masternodes for coordinating and CashShuffle has decentralized servers. If you scatter the many levels of jumbo transactions among these servers (masternodes), then your UTXOs cannot be fully tracked as long as a few of these servers are honest. The more levels and servers you use, the harder your coins are to track.

The isolation feature of enclaves makes sure no information leaks out from the servers. If the client confirms the server runs inside an enclave through attestation, it would have the confidence no third party can steal the information sent to the server. Thus, fewer servers and levels are necessary and the total solution can be more efficient.

Blackbox Execution of Pure Functions

Let’s generalize such a scenario to any pure function. A pure function has no side-effect and its outputs depend only on its inputs. We have:

  1. A predefined specification of the pure function without ambiguity
  2. Some public input arguments for this pure function, which can be revealed to anyone
  3. Some private input arguments for this pure function, which cannot be known by anyone else except their owner

We want a reliable blackbox, which is trustworthy to compute the correct outputs from the given public and private input arguments. At the same time, the provider of private arguments does not need to worry about information leakage.

Several cryptographic technologies can implement a blockbox with relatively simple functions and we usually refer to them as “zero-knowledge-proof”. Such technologies need a lot of expensive cryptographic computations and the function’s logic cannot be too complex, or else the proof circuit would be extremely large. Furthermore, if the pure function has an unbounded loop inside, zero-knowledge-proof technologies would be infeasible because the proof circuit cannot be constructed. Another shortcoming of zero-knowledge-proof technologies is the hardness to use. If the engineer does not have enough cryptography knowledge, it is hard to get things working and prone to leave vulnerabilities.

Enclaves can also implement such blockboxes. Isolation ensures enclaves never leak private input arguments, while attestations ensure enclaves compute just as the source code specifies.

Compared to zero-knowledge-proof technologies, enclaves are weaker in the trust model: we only need to trust math to use zero-knowledge-proof but must trust CPU vendors to use enclaves. However, enclaves are much easier to use: the pure function’s source code can be used directly in enclaves. There are no circuit constructions and unbounded loops are permitted.

Off-chain enclaves can easily interact with on-chain smart-contract. An enclave can be denoted by a public key stored on-chain. With the private key, it signs the pure function’ public input arguments and the outputs. On-chain logic verifies the signature with the public key and accepts the outputs.

Reliable Witnesses for Chain-Crossing

We do require that every smartBCH full-node client must have a corresponding BCH full-node client for querying transactions on BCH main chain. But it is impossible to require a BCH full-node client to watch a smartBCH node when running. It is also impossible for other chain-crossing scenarios, such as Ethereum to BSC, Ethereum to Solana, etc.

So it is unavoidable for cross-chain bridges to rely on some witnesses providing state information about another chain. The problem of witness collusion threatens all the cross-chain bridges. For some bridges, the witness set is the same set of validators and the state information is the Merkle root of the whole state tree, which leads to a little safer design but still cannot avoid collusion.

A witness runs a full-node client of Chain A and publishes its state to Chain B with its signature. If it turns evil, it may publish any information to Chain B, despite the actual state of Chain A. Even if the witness is a trustworthy organization, the machine administrator can still be bribed and the private key for generating signatures onto Chain B may get stolen.

As an enhancement, the witness can run its daemon process inside an enclave. The attestation process prevents corrupted administrators and isolation protects the private key.

When we implement SHA-Gate, the cross-chain bridge which transfers BCH between the main chain and smartBCH sidechain, enclaves will be taken into consideration since the blueprint.




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store

Maximize throughput of EVM & Web3 on a sidechain of Bitcoin Cash