Are blockchain oracles heralding a new era of smart contracts?

With the dominance of Airbnb, Booking.com and other accommodation-sharing platforms, we live in an age where you often need to be your own travel agent and concierge when it comes to finding, booking and getting into your place in the sun.

But one part of the process often leaves much to be desired. More often than not you’ll find yourself punching a four-digit code the host has sent you into a lockbox to retrieve a key with which to let yourself in. Such an old-school link in an otherwise digital chain hardly makes for a seamless experience.

One alternative is smart lock – a minicomputer which can fully automate the check-in process with the help of the guest’s smartphone. But even if the transaction itself took place on the blockchain – a distributed ledger reputed for its immutability and security – these provide swathes of new attack surfaces that can serve as both digital and literal backdoors for hackers to access a property.

Smartphones can be stolen or hacked, while smart locks are IoT devices that have much weaker inbuilt security controls than IT systems.

Some second-generation blockchains can already enable smart contracts, which, once their secure integration with external data sources is solved , can revolutionise the way we collaborate or trade with each other.

Smart contracts are computer programmes that can self-execute on the blockchain when specific conditions are met. Data proving the fulfilment of these pre-set conditions can be fetched into the blockchain from online sources such as weather apps, flight delay data and price feeds – or payment data as in the example above.

But the execution of the contract can also be conditioned upon information coming from the physical world via movement and temperature sensors or RFID tags. The question is how these external data sources will get fed into the blockchain.

The most obvious route is via an API – a software intermediary that allows two applications to talk to each other. Using only APIs as data sources, however, would mean that each node of the blockchain would have to contact the API individually, and – as data changes in real time – they would get different results.

This would throw a spanner in the works of the blockchain’s consensus-making mechanism, based on all nodes receiving identical data to approve a new block.

Third- and first-party oracles

Enter oracles – middleware that can mediate between blockchains and off-chain data sources (APIs) and post external data on the blockchain, thus enabling smart contracts to execute.

But centralised oracles not subject to the blockchain’s underlying security mechanism can provide backdoors to decentralised ecosystems. Therefore, a blockchain can be only as secure and trustworthy as the off-chain data it relies on for a trigger.

So far there are two different approaches to addressing the oracle problem. The first involves fetching the data on-chain after it has been verified either by third parties or by reputable and trustworthy API providers themselves.

Although it can be a good way of guaranteeing data authenticity and accuracy and increase the accessibility of real-time data on the blockchain, this approach is still somewhat foreign to the original concept of a distributed public ledger designed to bypass any central authority.

The other way of tackling the oracle problem is to leave data off-chain while creating a decentralised oracle network (DON). In this scenario, blockchain oracles retrieve data from external sources independently and bring it on-chain following a data validation and consensus procedure to make sure the data triggering the contract is reliable.

In the second scenario, blockchain oracles are more than just data feeds. They also serve as autonomous auditors of the information they fetch onto the blockchain.

However, being a decentralised system, oracle networks, just like blockchains, need to ensure that nodes aren’t hoarded by one individual or a group of hackers until, thanks to owning the majority of them, they are able to compromise data to serve their own needs. For example, they can feed false data into the blockchain that will trigger smart contracts they can cash in on by playing the system.

There are several hurdles that blockchains – both public and private – and smart contracts need to clear before they can be implemented for use cases beyond crypto and prediction markets – such as their legal enforceability and energy consumption. Finding ways of getting accurate and timely data to them without compromising blockchain security, however, needs to come first.