Trusted Execution Environments
An ongoing problem that all smart contract-based blockchains face is the infamous Walled Garden problem: the scope of smart contracts is confined to the blockchain that they’re part of, making it impossible for a smart contract to interact with any entity outside of its blockchain.
While this problem will be somehow alleviated with the introduction of blockchain-level oracles running on consensus nodes in NEO3, enabling the acquisition of external data from the NEO blockchain, complete external interaction capabilities will remain in the realm of impossibility, as evidenced by the fact that a smart contract won’t be able to operate on any private information, hold a private key or actively trigger operations outside of the chain.
Given these heavy constraints on the operation of smart contracts, how can blockchain solutions that need these capabilities circumvent the problem? One solution is oracles, trusted servers that hold private data, keys or credentials and listen for events from smart contracts, launching actions when these are fired, therefore enabling smart contracts to offload some of their responsibilities to them. Of course, this solution requires trusting such servers, thus losing the trust-less properties obtained from building a project on a public blockchain.
A better solution, pioneered by research from Cornell University, revolves around running the oracles inside Trusted Execution Environments (TEEs), which are hardware systems embedded into CPUs that allow running programs inside them in a totally isolated way, making it impossible for other parts of the CPU or computer to alter their state or tamper with the code running inside, as everything is protected by hardware-level isolation.
However, for the oracle use-case, the most important feature of TEEs is that, upon instantiation of new code inside a TEE, it’s possible to create an attestation: a hash of the state of the TEE (including all the memory and code inside it) signed with the TEE’s private key. This attestation can then be used to prove to other nodes that the server is running a specific code and has been in a specific state, therefore it’ll always follow that code (if you provide it a secret and it’s code doesn’t have any instructions that send it, you can be sure that it won’t leak the secret).
What’s more, due to the fact that all Intel SGX-compatible CPUs (which implement TEEs) have a unique private key from Intel inside them, it’s possible for the created attestation to be signed with it so that it can be proved to any entity that the code is actually being run inside a TEE, ensuring that the server is in a known state and that it cannot be tampered with, making it possible to know how it will act at all times.
Moreover, if trusting Intel about the private keys is not viable (Intel could be hacked), this assumption can be removed and we’d still find ourselves with a system that requires less trust than standard servers, as once a program starts running in a TEE it can’t be tampered with, therefore we only need to trust the entity that hosts the oracle at the time when the oracle is created, instead of having to trust it continuously. It can be argued that trust on Intel cannot be removed totally thought, as we place some trust on Intel in an implicit way when we assume Intel hasn’t built any hardware backdoor into these systems, but such trust requirements can be eliminated by using several TEE providers in tandem, such as AMD, ARM…
Finally, it’s important to note that none of these systems allow for the complete and absolute removal of trust in the person or organisation who is running the server, as such entity can still turn off the TEE, or, if it has enough resources, launch a TEMPEST attack on it to exfiltrate private data. These risks can be somehow mitigated, but never eliminated entirely, by distributing the responsibilities among a group of servers hosted by different entities and using threshold cryptography to keep any secrets also distributed.
To dive more into the technical details of how TEEs could be used in oracles we suggest reading the academic paper Town Crier: An Authenticated Data Feed for Smart Contracts.
