The Pros and Cons of Oraclization in Ethereum Smart Contracts
Is It Sensible to Oraclize Ethereum Smart Contracts?
Can you think of anything cooler than the Internet? It gives you the opportunity to find out anything about anything. This isn’t to say that blockchain is going to succeed the Internet but, really, is it? It also stores data; however, there is one issue to discuss — fees.
The fee you pay for smart-contract deployment is called Gas. You can find more information on Ethereum smart contracts here.
For the most part, gas depends upon the size of the smart contract. In Solidity (smart-contract-oriented programming language), storing data is not cheap: 3 gas for storing or updating it). In terms of value, it’s 20,000 gas to store and 50,000 gas to update.
IPFS
The dApps built on top of Ethereum need interaction with storage; otherwise, they won’t function. This is an issue in technology that found its cure in another one — IPFS. Luckily for the nodes, IPFS solves the problem with the gas. Basically, it is a BitTorrent-like file storage system with a certain address. What you do is just add files to the storage for the dApp to interact with.
Let’s have a brief look at the principle of IPFS’s work. Every file and set of blocks you add gets its own unique cryptographic hash. IPFS finds and withdraws repetitions within the network. To find the necessary file behind a unique hash, the node asks the network to find the owner. This makes storing data on Ethereum more accessible.
With the growing use of blockchain, we are going to be facing IPFS technology in different types of oracles.
How Does Oraclization Work?
Very often, smart contracts need to interact with the external web to execute particular functions. Data can be included directly in a smart contract, but instead, we can just use oracle API to reach the data in the internal web whenever needed. This is actually what an oracle of any type does: gives the excess to information from the outside storage.
To use this concept on Ethereum, you’ll need to use oraclize a smart contract to send an API call to Oracle. They use a callback function in your smart contract to send you an input. The principle of work is illustrated in this image:
Wrong Input?
Like any technology that has its issues, there is a trust issue connected to Oracle’s work: not in terms of unsecured connections, but in terms of getting the wrong file or data through a certain oracle.
This is a good argument for using a network of oracles instead of a single one.
Single Oracle vs. Network of Oracles
According to the opinion of the Applicature business analyst Stas Sheliakin:
“Using a single oracle can’t be safer than a network of oracles, as it is a single point of failure. However, there are situations when you cannot avoid using a single oracle. In this case, one well-protected, trusted oracle is better than a network of oracles.”
In any case, if an oracle isn’t protected cryptographically, it can hardly be trusted, as it is difficult to understand whether it is a single oracle or a network.
Oracle Is Not One Size Fits All
The question of oracle usage remains a point of debate among a huge number of developers. In terms of business use cases like travel or retail services, oracles function in the proper way. They provide smart contracts with simple, yet necessary information, and smart contracts fix further actions afterwards.
When it comes to services connected to physical objects like a rental, Oracle has to provide the smart contract with a huge number of informational fees; in particular, dates that Oracle will push onto the blockchain.
To Oraclize or Not to Oraclize: That Is the Question
Oracle is a trusted information feed that is included in a smart contract to allow it to receive information from the direct source holding it. Most frequently, it is a third party that owns the information that Oracle passes. At this point, it gets funny, as blockchain is a decentralized ledger; however, oraclizing the blockchain is a necessary step toward the sensible use of smart contracts. To make it work the way you expect it to, it is essential to use a reliable oracle.
There are different types of smart contracts. Let’s consider those that manage the value of a coin. This type of smart contract is protected from a single point of failure. By inserting an oracle, you basically include it in a smart contract.
“This would be a weak spot, as hacking one oracle is much easier than hacking the blockchain. Thus, in smart contracts written to manage the value of a coin, you’d better not use oracles in order to keep your blockchain secure,” claims Stas Sheliakin.
Smart contracts that have no connection with the value of the coin itself and don’t perform transactions — but, for example, change the coin distribution between the accounts — may provide oracle function. In this case, oraclization of the smart contract causes less risk, as no third party is interested in hacking it. No external party would tend to hack the oracle, though participants in the smart contract, may have the motivation to change some conditions under which the smart contract executes the distribution of tokens. However, if this happens, there is no way the fraudster can escape without being caught.
Stas continues with the most appropriate situation for oracle usage: ”If you need to use Oracle in a smart contract that executes a certain function depending upon conditions that are on the blockchain, the only weak point will be the oracle itself. Here, you are able to protect the bridge (URL) by providing good cryptographic protection. Therefore, oracle use inside of the blockchain is a perfect oracle use case.”
Private Blockchain Oraclization
As you oraclize the public blockchain, there arises the opportunity to oraclize the private one. Unfortunately, you should face the fact that it is easier to create a Proof-of-Authority node, get 51% verification, and attack the public blockchain.
Here, we’ve come to the point where it is time to think about protection from the network.
Stas suggests a way out: “We’ve got two variants: either you keep your blockchain well-protected, or you use Plasma Cash. Plasma Cash is a special smart contract which, unlike oracle, not only gets information from an outside source, but requires validation of previous blocks in the blockchain. Therefore, it gets harder to attack the blockchain.”
Conclusion
Moving down from the perfect oracle use case to the least efficient, the first would be oraclizing the blockchain. This is the oracle that provides a smart contract with information stored on another blockchain, which means that the only weak point is the bridge (URL) between the smart contract and the source of data.
Here, we have to use cryptographic protection in order to avoid being hacked. If you oraclize a functional smart contract, it causes less risk than implementing Oracle in a smart contract that is somehow involved in the value of the coin.
One more use case is oraclizing the side blockchain. When it comes to referring a smart contract on the side blockchain to an external source, you can protect the blockchain by using Plasma Cash.
The most vulnerable use case for Oracle is implementing it in one database. For example, you need to use the exchange rate from Binance. By attacking the source and changing the needed rate, fraudsters could profit.
Therefore, consider limiting oraclization usage in all smart contracts that involve digital addresses, as any hacker can steal coins by typing in his/her own address.
