The Oracle Problem: A Response to the BIS Bulletin

The Bank for International Settlements (BIS) recently published the bulletin ‘The oracle problem and the future of DeFi’. Leonardo Gambacorta and his team provide great exposure and insight to the realm of blockchain oracles. This article provides an alternative perspective, given solutions exist to mitigate against some of the issues raised.

Blockchain oracles act as a bridge between smart contracts and web2 systems, transferring data from web2 into web3. This allows smart contracts to execute based on information that is not natively on the blockchain.

This solves the oracle problem, whereby smart contracts and dApps are isolated from off-chain data.

The primary concerns raised by BIS were trusting a blockchain oracle, and compromising efficiency by increasing decentralisation in order to enhance trust.

In this article Applied Blockchain takes the opportunity to provide a response to these points and propose an alternative solution with Silent Data [Oracle].

Trusting a blockchain oracle

“[Centralised oracles rely on a single data source] however, this reliance on a single source leaves room for manipulation when the data source is not trustworthy.”

The bulletin explores an example of a smart contract that allocates funds based on the temperature in a specific city on a particular date. Given blockchains are isolated from the outside world, the 2 developers use an oracle to provide the smart contract with the temperature reading.

BIS highlights this as a potential point of manipulation, hypothesising how an invested party, “developer 1, could bribe oracle 1 to report a temperature below 10 °C to receive a payment from developer 2” (p3).

Silent Data [Oracle] is a centralised solution that addresses trust concerns by leveraging confidential computing. It cannot manipulate results from the data source as developers and untrusted code do not have access to the oracle key. The Silent Data [Oracle] key lies inside the hardware secure enclave which makes the request to the data source and processes the results. The source code executed in the hardware secure enclave cannot be manipulated by the developer either, as this is attested by the enclave manufacturer and anchored to the smart contract. Thus, trust is placed in confidential computing hardware as opposed to a blockchain oracle operator.

Hardware secure enclaves

Using secret keys embedded in the hardware, Intel SGX creates encrypted regions of memory with enclave-only access meaning not even the super user of the machine can access the running program. The oracle request and response processing are pre-configured and immutable. In the secure environment, the secrets are decrypted and used to perform the API requests and the results are signed with the oracle key. As such, neither the operator nor user can access or manipulate the oracle request or access user credentials.

This eliminates risk around a single data source as the hardware secure enclave uses the oracle key to sign results before sending them to the blockchain, and the oracle code cannot be changed. As such, even if an attacker gained access to the Silent Data servers (or a bribe attempted), the results posted on-chain cannot be modified by the oracle.

See ‘What is the Blockchain Oracle problem?’ for greater detail.

Blockchain Efficiency

“The challenges of resolving [the Oracle Problem lay in] the trade-off between trust and efficiency in decentralised platforms. When this trade-off is understood, the future of DeFi in its purest sense looks bleak.”

The bulletin states the challenge in resolving the oracle problem lies in “the tradeoff between trust and efficiency in decentralised platforms” p2.

Decentralised blockchain oracles reflect the mutual consensus nature inherent to blockchain, but come at the cost of efficiency. More time is taken returning results of user requests as oracle nodes must reach consensus before posting.

Meanwhile, traditional centralised oracles maintain efficiency, but compromise security. Users must trust a single oracle operator to report unmodified results for their exact request.

The bulletin outlines the choice between an unreliable result or a loss in efficiency, but a third method exists.

A third alternative

Decentralised oracles intend to improve reliability of results, but leveraging hardware is another way to achieve this without losing the efficiency of a centralised service.

Silent Data [Oracle] allows users to benefit from the efficiency of a centralised oracle, while bolstering security. As detailed above, trust is placed in hardware and manufacturer attestation as opposed to oracle operators in a decentralised oracle network.

Silent Data [Oracle] processes data and signs attestations in an enclave meaning results cannot be modified by an operator

Conclusion

The BIS report whilst detailed presents a straightforward tradeoff between trust/security and efficiency. However by leveraging secure hardware and manufacturer attestation (e.g. Intel SGX), solutions like Silent Data [Oracle] enable both security and efficiency without requiring additional trust.

‍