This section of the Chainlink whitepaper dives into further detail on some of the properties of the ideal oracle solution proposed in Section 3. There are three main sub-sections: oracle confidentiality, infrastructure changes, and off-chain computation.

In regards to oracle confidentiality, trusted hardware is introduced as a better solution to protect against faulty nodes. The Town Crier oracle is comprised of a network of nodes running trusted hardware, and operating on Ethereum’s blockchain. Trusted hardware via Intel’s Software Guard eXtensions (SGX) improves upon previous secure computing methods in that its program execution can be cryptographically verified. Trusted hardware allows software to be executed within a protected environment referred to as an enclave. Within the enclave, the data and code cannot be viewed or modified by any party, including the node operator. Data can even consist of usernames and passwords, and API keys can be provided an a query to the nodes without the possibility of eavesdropping even on a compromised machine.

Allowing for inputs and queries to remain confidential is difficult when dealing with third-party oracles because in order for a query to tell an oracle provider how and where to obtain data, traditionally, that query would need to be revealed to the oracle. Then the oracle would also be able to see the response, which is undesirable for confidentiality.

The benefit of trusted hardware running SGX is that queries can be given to an oracle, that query can be decrypted, its data retrieved and processed, and encrypted to be returned to the smart contract, all within the enclave. An example of trusted hardware being utilized with confidential data is how flight information can be relayed using Town Crier (TC) smart contracts. Confidential flight information can be given to an oracle running a SGX enclave and return a simple yes or no answer back to the user to be written on the blockchain. Another example is trading games on Steam. TC can allow usernames and passwords to be given within a query, verify game ownership, and transfer that ownership within a smart contract.

The simplified abstraction for SGX is as follows:

Assume: The program operating within the enclave has methods Initialize and Resume

Initialize:
 - Untrusted code Initializes the enclave

 - The attestation of the code within the enclave and its output is generated

 - The attestation is signed to verify that the code was running with the output produced within the enclave

 - The result along with the signed attestation is returned

Resume:
 - Untrusted code calls the Resume method with a session identifier and input parameters

 - An output is produced from the code within the enclave (called with the Resume method)

 - The output is returned

The authenticity of an oracle running SGX is defined by its signature. The input parameters which were given as part of the query are combined with the attestation along with the time of the execution and are signed with the oracle’s private key. These parameters cannot be reproduced in such a way that would allow the returning of modified data to be accepted within the system.

Infrastructure changes on a large scale would need to be implemented in order for data to securely be returned to nodes in a verifiable manner without trusted hardware, but can also be used to further enhance the security and confidentiality provided by trusted hardware. For example, HTTPS does not allow for the digital signature of data, but an extension of TLS, TLS-N, could be used to improve oracle security by allowing servers to sign sessions with clients. TLS-N looks promising, but it does have some limitations. Data sources would need to individually enable the extension in order for oracles to take advantage of it. It provides no capability to aggregate data off-chain. It would increase the transaction cost within smart contracts. Providing credentials would be a one-time use, instead of continued use within a smart contract.

Further changes to off-chain computation are also proposed in this section. Oracles may need to connect to API endpoints multiple times using the supplied credentials. In order to do this, the ability to securely manage those credentials within an enclave would need to be developed. Currently, off-chain data processing is limited to a regex-based language. The goal for the future is to have most, if not all, off-chain computation be accomplished within oracles. These oracles would then feed the results of the computation back to the smart contract. This would reduce the cost for smart contracts, and by making use of trusted hardware, would improve confidentiality.

The key takeaway from this section should be learning about how SGX improves the oracle’s security within the Chainlink Network. I tried to take away the math associated with Figure 5 so that it would make sense for anyone to read it. However, the concept of running a program within an enclave can still be difficult to understand.