People often ask me whether smart contracts are going to have real impact someday. In my experience, making technology predictions is a mug’s game. Happily, in this case, there’s no need: Smart contracts have already had a big impact.

Smart contracts have transformed technology venture funding through billions of dollars of ERC20 token sales, which have outstripped early-stage internet startup investment. They’ve even managed to get people to pay more for digital cats than the most expensive fur-and-blood exemplar (a handsome animal, unlike a CryptoKitty).

For all the money and fur they’ve made fly, though, these smart contract successes are, technically speaking, pretty pedestrian. Token contracts are little more than account books or blockchains within blockchains. CryptoKitties are just (non-fungible) tokens.

When I first started doing research on smart contracts in their remote antiquity (in 2015), it seemed clear that, to do anything interesting, smart contracts would need connections to the real world. Those connections, called oracles, were severely underdeveloped in blockchain systems. That’s why my group, led by Fan Zhang, embarked on the creation of the Town Crier (TC) oracle.

It’s a rare and gratifying thing to see academic research taken up by industry. Thanks to help from Intel, though, TC was, in 2017, the first public-facing production application to use Intel’s new SGX technology (discussed below). Such is the fast-moving blockchain world that there’s increased hunger for good oracles, and now Town Crier has become part of Chainlink. The TC team is thrilled to see this happen.

I’d like to offer some thoughts about how TC might now enrich Chainlink. Specifically, I’d like to highlight some of the ways in which TC complements the capabilities that Chainlink has as a decentralized system and the ways in which it extends them – enabling oracles to do things you might not think they could.

Let me begin, though, with an answer to the question:

What is Town Crier?

In a word, TC is an oracle backed by a trusted execution environment (TEE).

An oracle, in its most basic form, is a service that receives a query q from a smart contract SC and returns an answer A. The query Q can relate to most anything, e.g., “What was the USD price of Ether at 3 p.m. today?” (for a financial smart contract), “Did Alice rent drone #2871?” (for a drone-rental smart contract), “Did Seraphim Airways Flight #123 land on time?” (for a flight insurance contract), “Did Trump get his wall?” (for a betting contract). Usually, the service obtains its answer A from one or more trusted websites.

A TEE is a hardware-based capability that allows programs like Town Crier to run in a protected environment. This environment, called an enclave, provides both integrity and confidentiality.  Integrity means that it’s infeasible for an attacker to tamper with the code in an enclave. It ensures users that TC is acting as an honest oracle. Confidentiality means it’s also infeasible for an attacker to inspect the contents of an enclave. TC leverages TEE confidentiality to handle sensitive data safely—anything from passwords, to private keys controlling cryptocurrency, to personally identifying information. (I give some provisos in the notes to this blog explaining how the security of TEEs is far from perfect.)

In short, you can think of an enclave as a black box, a hardened, opaque environment in which to run programs securely. You can think of TC as an oracle that runs in such a black box.

Oracle Integrity

As a decentralized oracle system, Chainlink can provide smart contracts with responses from multiple nodes or sources. For example, a smart contract may receive answers from three different Chainlink nodes to the question, “What was the USD price of Ether at 3 p.m. today?” If most of these nodes are honest, then it’s easy to ensure that A is correct: Simply take the majority value from the answers the nodes provide. As long as two of the three responses are right (and consistent), a correct value of A will result. Even if one oracle misbehaves and provides an incorrect answer, A will still be correct.

TC, on the other hand, can ensure correct answers with only one node. More precisely, it provides an end-to-end guarantee: Provided that the node runs TC in a TEE, an adversary cannot tamper with an answer while it is relayed by the oracle from the website to the smart contract.

Some users may be skeptical of TEEs’ security – for reasons I explain in an appendix to this blog. Happily, decentralization and TEEs aren’t an either/or choice. It’s possible to use both in a simple, complementary, belt-and-suspenders way. Running TC on the nodes in a decentralized system helps ensure that these nodes behave honestly. For the oracle to send corrupted answers to smart contracts, a majority of node operators would need to be corrupted or malicious AND the TEEs on their nodes would need to fail. Put another way, a decentralized system that uses TEEs—even flawed ones—is strictly stronger than a system that doesn’t.

Oracle Confidentiality

TC’s other main feature is its ability to enforce confidentiality. This ability in particular suggests extensions to the features that decentralized oracles can safely offer.

Let’s take an example from the Town Crier paper meant to illustrate how a richly featured oracle can spawn new markets. Alice wants to sell a Steam game to Bob for 1 ETH. To do this fairly, i.e., to ensure she gets her money and Bob his game, the two can use a smart contract. Obviously, the smart contract can act as an intermediary in transferring the 1 ETH from Alice to Bob. But without explicit Steam support (an API), which Steam doesn’t provide, how can the contract determine whether Alice transferred the game to Bob?

The answer is that Alice can give her password to the TC oracle, which can log into her account and verify that she sent the game to Bob.

Thanks to its use of a TEE, TC can in principle safely handle passwords, including Alice’s.[1] In contrast, there’s no way to entrust a password safely to an ordinary node in a decentralized oracle. Even techniques like zero-knowledge proofs and secure multiparty computation don’t help. Whatever cryptography is used, at the end of the day, some node needs to send Alice’s password to Steam. Only by using a TEE can this node adequately protect the password.

The Steam example is just one of many in which TC can accomplish things that decentralized oracles alone cannot with reasonable security assurances. Here are a couple of others:

Confidential queries: The query to an oracle service is often sensitive and should be hidden, not just on-chain, but from the oracle service itself.

A good example use case, given in the Town Crier paper, is a flight insurance contract.

Suppose Alice has purchased an insurance policy with Flight Insurance Contract. The contract then needs to know which flight she’s taking, and subsequently whether her flight was delayed in order to determine whether she should be paid.

Alice could send her flight information directly to the contract, but then her travel plans would be on-chain and visible to the whole world. She could alternatively conceal her flight information (airline, number, and date) on-chain by encrypting it under the public key of the oracle service. But this information needs to be decrypted somewhere. In a decentralized oracle system, it would be decrypted by the oracle nodes, and thus exposed to their operators.

In contrast, TC can conceal Alice’s flight information within its TEE, hiding it both on-chain and from the operator of TC. The idea is shown in this conceptual figure:

Private computation: Consider a loan smart contract that needs to determine whether Alice is creditworthy according to some special formula F that’s proprietary to the contract creator. (For example, F might combine her bank account balance, the quality of her network of friends in social media, and her credit scores at the major bureaus.) There are potentially three critical types of confidentiality to be enforced in this example: (1) The credentials (e.g., passwords) Alice uses to log into websites with her data; (2) The credit-related data itself; and (3) The formula F, which the creator of the contract may wish to keep secret.

Ideally, at the end of the day, the oracle node operators and the contract should see only one bit of information: Whether or not Alice is creditworthy according to F. TC makes such strong confidentiality for sophisticated data-processing possible for this use case and many others.

The Future Role of Town Crier in Chainlink

While evocative, the term “oracle” imposes unfortunate constraints on the imagination. It suggests a service that simply responds to questions. An oracle can and will be much more: A general, bidirectional, compute-enabled connector between on-chain and off-chain systems. This view is essentially Chainlink’s vision for expanding oracles’ capability.

Using oracles in this expansive sense, smart contracts could, for instance, monitor and control internet-of-things devices. They could use AIS GPS to track shipments of food, monitor and analyze temperature-sensor data to ensure cold-chain integrity, and unlock containers when payment and other conditions are met. To be viable in existing industries, they will need to interface with legacy systems – a goal encompassed under the “Sound Migration” IC3 Grand Challenge. And, in many cases, they will need to do intensive, private computations that are only viable off-chain.[2] All of these things fit nicely into an extended oracle architecture.

If I had to make a prediction, it would be that TC, with its TEE-backed capabilities, will play an important role in making this panoply of possibilities a reality in Chainlink.

Disclosure: I co-developed TC in my role as a faculty member at Cornell Tech, where I am also a Co-Director of the Initiative for CryptoCurrencies and Contracts (IC3). More recently, I became a technical advisor to Chainlink, a role distinct from my academic activities. All the opinions expressed in this blog post are my own.

[1] TEEs can also be used in such a way that Alice herself logs into her account using her own TEE, which then produces a tamper-proof attestation to the fact she’s transferred the game.
[2] For examples of how to implement whole smart contracts themselves in TEEs, making them private and performant, see Private Data Objects and Ekiden.

Appendix

Aren’t TEEs broken?

Today, Intel Software Guard eXtensions (SGX) is the only broadly available TEE that has the integrity and confidentiality properties I’ve described and also supports another key feature called attestation—remote proof that a particular program is running in an enclave. SGX is built into Skylake and later Intel CPUs.

SGX is meant to work in a strong adversarial model. It provides hardware protections for code and data against even the operating system of the machine on which a program is running. It also protects against physical tampering, and thus against the host’s operator and/or physical possessor. But SGX comes with important provisos.

Intel has warned, and researchers have shown from the outset, that SGX is vulnerable to side-channel attacks. The SGX architecture inherently leaks some information about application execution (such as page faults, which the OS itself can induce). More recent attacks, most notably Foreshadow, have badly broken SGX security—both its integrity and confidentiality.

So is SGX useless? Given the architectural challenges that attacks on SGX have surfaced, are good TEEs unrealizable?

There are no absolutes in security. It’s no good asking whether a system is secure, only whether it’s secure against a particular class of adversary or adversaries. Critical vulnerabilities are an inescapable fact in all computing infrastructure. Moreover, attacks and defenses evolve. New TEE architectures are already on the horizon.

So, important questions to ask are: What is the TEE protecting? Who’s operating it? And on what time horizon is it being deployed? A TEE hosted by a trustworthy service provider and used to secure assets in the low millions, I’d probably feel confident in. A multi-million-dollar smart contract whose security relies on no TEE anywhere in the world being broken is clearly a bad idea.

There are also models in which it’s possible to limit TEE exposure by relying, for instance, mainly on its integrity, rather than its (more vulnerable) confidentiality properties.

TC and TEEs more generally may be viewed as an alternative or complement to decentralization. I believe and have bet much of my recent research on the hypothesis that TEEs will prove to be not just valuable, but vital for practical blockchain infrastructure.