Design considerations: centralized and decentralized oracles

This is the second blog post in a series that explains some of what happens under the hood when we want to rely on information that is outside a blockchain.

In the case of oracles, the classification of centralized versus decentralized is somewhat of a misnomer. In this blog post, I argue that there is rather an evolutionary step from centralization to decentralization. We evaluated current blockchain oracle projects to this conclusion.

Centralized oracles
For any oracle to function efficiently, there must be an off-chain entity or node (software, hardware or a combination of both) that facilitates information transfer in and out of the blockchain. Also, ideally this node is secured such that the hardware and software it uses is tamper proof to a reasonable certainty. In its purest form a centralized oracle does exactly that: it functions in a secure manner and through providing data from an external source to the smart contract. A great example of a centralized oracle provider is Provable.

Basically, the oracle has a set of secure software and hardware that requests the data from an API or measures it through hardware sensors. Simultaneously the oracle runs a blockchain node and once it has received the information it needed it broadcasts it as a transaction…