ChainLink White Paper — Section 3— Oracle Security
As the title states, Section 3 of the ChainLink white paper gives an overview of the ChainLink oracle security. The section creates a scenario depicting the perfect oracle solution, then adds layers of complexity and explains why it is difficult to achieve such an environment.
Security is important to have on each individual oracle (node) so that the data is reliably delivered to smart contracts without being tampered with. We trust the blockchain because it is immutable and verifiable, therefore, oracles should also be proportionately secure themselves.
An example of the perfect oracle security is then given. In a perfect world, we would have an impeccable data source, and a trusted third party running an oracle. The oracle would accept requests from smart contracts, obtain the requested data from the data source (over a secure channel), and return that data to the smart contract (digitally signed). In this scenario, we rely on the integrity of both the trusted third party (which is running the oracle) and the data source providing the data.
Then a layer of complexity is added to the above scenario: confidentiality. When the smart contract creator creates a query, that would have been sent over plain-text to the oracle, which is undesirable. We add the requirement of encrypting the query sent to the oracle, so that it is not visible to the outside world. However, this adds a new problem: now the oracle can see the query once it has been decrypted. We are now relying again on the integrity of the trusted third party running the oracle.
Another layer of complexity is added in the form of availability. Not only must the oracle remain online, but it also must appropriately respond to all requests. Meaning, it won’t choose to ignore or deny requests that its owner doesn’t agree with. This is similar to the underlying blockchain, in that nodes that operate on the blockchain layer do not censor certain transactions, they simply accept, validate, write, and maintain them accordingly.
Finally, the ideal oracle represented in the “perfect world” scenario above is difficult to achieve because there are multiple factors that could compromise the integrity of the data given back to the smart contract. In the real-world, the data source itself could be compromised or report incorrect data. This sort of issue can be alleviated by using multiple data sources for a given assignment. Also, the notion of a trusted third party running an oracle is unrealistic simply because there could be bugs in the software running the oracle, or its system could be hacked or compromised itself. This would prevent the oracle from performing as its intended.
The purpose of this section was to describe the ideal definition of an oracle for the ChainLink network. Though no such perfect oracle exists, the goal is to come as close as possible to the oracle in the “perfect world” scenario. This is one of the less-techy sections, but is critical for understanding the reasons why decentralization and trusted hardware is necessary for the secure and reliable delivery of data to the blockchain.
See the ChainLink white paper here.
