Overlooker: an enclave-based oracle for blockchain events

In cross-chain and mulit-chain applications, a fundamental component is an oracle that endorses the events that happened on a remote chain.

Traditionally, oracles use quorum-based schemes to ensure trustworthy outputs. Quorum is a group with a limited number of elected or appointed members. We trust that most of them are honest because:

1. They have proved their honesty in other affairs.

2. They have acted as oracles for a long time and have a good record and reputation.

3. Some economic arrangement rewards their honesty and punishes dishonesty.

However, as long as the quorum's members are human beings, someday a member may do evil because of corruption or violence coerce. Weaknesses of human nature cannot be overcome thoroughly.

Overlooker is a new kind of oracle that uses hardware to minimize the effect of human factors. For a given task, anyone can operate an overlooker instance and act as an oracle. The number is not limited. Operating an overlooker is permissionless. And every overlooker will output exactly the same result.

In this article, we will first introduce the underlying technologies that overlookers are based on. Then we describe the overlooker's implementation details. Finally, we discuss how to integrate overlooker into a cross-chain message-passing application.

## Background

### Enclaves

An enclave is a territory that is entirely surrounded by the territory of one other state or entity. In computer science, the term "enclave" is a trustable execution environment surrounded by untrustable hypervisor, OS, and other applications.

Hardware and firmware ensure that an enclave has the following features:

1. Integrity: a program in the enclave executes precisely 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 and some internal data can be signed by a key kept by hardware to convince the relying parties that it IS the predefined trustable program running.

Currently, the cloud-computing vendors provide three different kinds of enclaves: Intel SGX, AMD SEV-SNP, and AWS Nitro Enclaves. Intel SGX has the longest history and the most mature ecosystem.

### Full-node clients for blockchains

Full-node clients help you to verify the transactions and check the events/states. If you want to cheat someone running a full-node client for a PoS blockchain, you have two choices:

Choice#1: replace this full-node client's binary with a fake one, and

Choice#2: fulfill the following two tasks:

1. Collude with more than 2/3 of the blockchain's validators and make them sign fake blocks.

2. Let his full-node client only connect to the witch nodes controlled by you in the P2P network. These witch nodes will broadcast the fake blocks to his full-node client.

If the full-node client is running inside an enclave, the "integrity" and "attestation" features prevent you from manipulating its binary. So choice#1 is impossible.

If the full-node client is running on the cloud, the cloud vendor's network is very hard to attack. And bribing the validators to corrupt 2/3 of them is almost a "mission impossible".

So a full-node client running in an enclave provided by cloud-computing vendors is highly reliable. It's the best data source for remote chains' events.

### NaaS Providers

A Node-as-a-Service(NaaS) provider runs many full-node clients and its customers pay to access these clients' RPC endpoints.

Although NaaS providers usually use plain compute instances instead of enclave-enabled compute instances, they have a good reputation and practice to protect full-node clients from manipulation.

We can view the NaaS provides as the second-best data source for remote chains' events.

## Implementation

We use [EGVM](https://github.com/smartbch/egvm) (enclave-guarded virtual machine) to implement the overlooker. EGVM is a javascript virtual machine running inside enclaves. Currently, it only supports SGX enclaves.

The key feature of EGVM can be summarized as "code is private key". We all know the catchphrase "code is law", which means the consensus is encoded in the source code and enforced by the community. The catchphrase "code is private key" means an overlooker can use a unique private key that is derived from this overlooker's code.

This private key is bound to the code. It will change if the code changes. This private key is protected inside the overlooker's enclave. The external world cannot access it.

If the enclave hardware and the EGVM software are built correctly and bug-free, you can be sure that whenever you see a signature signed with the code-derived private key, it is signed by the code.

### KeyGrantor

KeyGrantor is a supporting component for EGVM. A KeyGrantor enclave holds a BIP32 extended private key (xprv). which is generated by the CPU's TRNG (true random number generator) or granted from another KeyGrantor enclave.

When you start a KeyGrantor enclave, if an upstream KeyGrantor is specified, it will connect to the upstream one and use an attestation report to prove that both of them have the same program (the measurements are identical). The upstream one checks the proof is correct before sending the xprv key to your KeyGrantor through a TLS channel. If no upstream KeyGrantor is specified, the KeyGrantor started by you will generate a new xprv key using TRNG, which can be granted to other KeyGrant enclaves later.

Using this method, one KeyGrantor can be "cloned" to many identical ones, which hold the same xprv key and has the same functionality. Anyone can get a cloned KeyGrantor, so it's totally permissionless.

### EGVM Script Engine

EGVM Script Engine is the core component of EGVM. It executes javascript code inside an enclave and this code can sign messages using a derived private key, which is granted by a KeyGrantor.

When we talk about "code is private key", the term "code" means the following parts:

1. The program (binary executable) of EGVM Script Engine.

2. The javascript code that EGVM Script Engine executes.

3. A json configuration that the javascript code reads in its initialization phase.

Before the script engine executes the javascript code, it sends the KeyGrantor an attestation report which contains the hash digests of all three parts. The KeyGrantor will derive a secp256k1 private key using the xprv key and these digests and send it to the script engine through a TLS channel.

The KeyGrantor discloses its BIP32 extended public key (xpub) and the script engine discloses the code's secp256k1 public key. Given the code's three parts, anyone can verify the code's secp256k1 public key against the xpub key.

### Witness Mode and Falsification Mode

Overlooker oracles are implemented with javascript and run in EGVM Script Engine. To prevent the damage caused by corrupted data sources and possible bugs in KeyGrantor/EGVM/Overlooker, the implementation must support two modes: witness mode and falsification mode.

In the witness mode, the overlooker endorse "the event is true" if and only if: the majority of data sources must be available and all the available data sources must all agree that the given event did happened on a remote blockchain.

In the falsification mode, the overlooker endorse "the event is false" if and only if: a minority of data sources all agree that the given event did NOT happened on a remote blockchain.

This is an asymmetry design. It is much easier to get a falsification signature than a witness signature. We can stop the application in emergency using a falsification signature even if:

1. the majority of data sources are corrupted and only a minority is honest

2. there is a severe bug in KeyGrantor/EGVM/Overlooker and the attackers can use the derived signature to sign any event.

## Integration

We can only get witness signatures and falsification signatures from overlookers. There is still a gap from a usable application. To integrate overlookers in applications, we need more roles to participate.

Let's take message channels as an example application. A message channel is a smart contract from which other contracts can read events that happened on a remote blockchain. To make it reliable, the following roles are necessary.

Auditors. The auditors review the source code of KeyGrantor and EGVM, as well as the javascript code that implements the overlooker, making sure there is no bug in them.

Configurator. The configurators vote to decide:

1. Which audited implementations of KeyGrantor/EGVM/Overlooker should be used by this message channel

2. What is the content of json configuration. The domain names, TLS certifications and other information of the selected data sources are encoded in the json configuration.

Because "code is private key", the configurators actually endorse the private key used by the overlooker oracle.

Relayer: a relayer runs an overlooker and uses the witness signatures to write events into the message channel. These events will undergo a cooling-down period before they can be read by other contracts.

Challenger: a challenger runs an overlooker and uses the falsification signature to falsify events in their cooling-down period. Once an event is falsified, this message channel is stopped in emergency.

The configurators must analyze why the event is falsified. If the reason is a bug in KeyGrantor/EGVM/Overlooker, they will switch to a patched implementation. If the reason is some corrupted data sources, they will write a new json configuration. When the problem is fixed, they will endorse a new private key for the overlooker and restart this message channel.

Relayers can be anyone, so the message channel has liveness: nobody can stop it from working. Challenger can be anyone, so the message channel has correctness: any stakeholder of the message channel can falsify a fake event.