Author: Robert Mao (CEO and Chief Architect of ArcBlock)
Editor's Note: Chainlink, the Ethereum oracle project, recently rose to become the 9th largest project in the world, and was recently shorted by someone, causing a lot of attention and discussion in the industry. Today, through ArcBlock Technology Community published on February 28th of this year and the last part of chapter 8 "Misunderstandings about Smart Contracts and Virtual Machines" recently published by CITIC Publishing Group, the author shares how to analyze the value and current state of Chainlink and oracles from a technical and product perspective.
Chainlink Technology Discussion#
Chainlink is an old project that I have been following since 2017. In addition to Chainlink, I have also paid attention to Oraclize (now renamed provable.xyz). They are similar, both addressing the Oracle problem on Ethereum.
The oracle machine of external APIs
The design of Ethereum makes the EVM and smart contracts a fully enclosed sandbox. Smart contracts cannot access external APIs, this is also to ensure the determinism of smart contract code execution, because once there is an external API call, different Ethereum nodes may get different results when running at different times (for example, the API itself returns differently, or temporarily encounters an error), thus consensus cannot be reached.
The solution is to create an external (off-chain) program to write some necessary external data to the chain, so that smart contracts can read data from the chain when they need external APIs, solving the determinism problem. This program that puts external data on the chain is called an oracle (informal definition). Similarly, triggering some external actions from the chain can also be done in a similar way.
The above working principle is demonstrated in this Chainlink diagram. Chainlink is similar to Oraclize, both of which have designed a framework, part of which is a smart contract code template on the chain, and the other is a program that provides API calls off-chain, in order to simplify development, applications on the chain only need to call its smart contract.
Decentralized Oracle
Some may doubt, what if the oracles above are manipulated? First of all, generally these oracles access external APIs, which are somewhat centralized in some way, so no matter how the oracles decentralize, you still get centralized data. This is actually very awkward. However, internet applications have been doing this for many years, why is there no problem? This is a very good question. Firstly, because there is no other way, this is the reality, some APIs are now only possible to be centralized; secondly, internet applications themselves are designed in a centralized manner, and adopt a permissioned design, internet applications usually directly access authoritative external APIs in a secure environment, so the problem is not that big. And blockchain needs to use oracles (acting as intermediaries) to access authoritative data, which results in obtaining second-hand data on the chain losing its authority.
Chainlink and Oraclize's main focus is actually how to make this secondary data more authoritative. Chainlink uses a large number of community nodes (similar to miners) to randomly select parts and seek consensus to partially solve the problem. This certainly solves some problems, but the best way is to eliminate intermediaries and directly access authoritative APIs. However, in the design of Ethereum-like architecture, this is not possible, so such a structure must be adopted.
Chainlink
The logic of Chainlink is to attract a large number of participants to run Chainlink nodes, which execute some API calls scheduled from the chain. Chainlink then schedules different nodes to prevent Oracle misconduct. They use the link token as an incentive: application developers pay with link, and node operators receive link.
This design is so similar to ArcBlock's Blocklet! Indeed, that's the case, as we took inspiration from many excellent designs including Chainlink when designing Blocklet.
Does ArcBlock need an oracle similar to Chainlink?
No need. Because our design is not based on Ethereum's virtual machine architecture, Blocklets can fully adopt the same architecture as Internet applications, allowing applications to directly access external APIs without the need for intermediary mechanisms such as oracles.
"Wait a minute, does this mean you're not decentralized enough? You're calling an external central API, bro, how is that decentralized?"
Our design allows you to directly access authoritative APIs, without intermediaries, no intermediaries can do evil, so there is no need for an oracle similar to Chainlink. Just understand the principle introduction above.
Is it fair to say Oracle has no value?
Not so, Oracle is valuable. However, Oracles like Chainlink are just a type of Oracle to access external APIs, which is not necessary in the ArcBlock architecture.
The Oracle of the blockchain is a general term for a mechanism that can reliably and deterministically obtain off-chain data from the chain, which is much broader and more difficult than solving the Oracle accessing external APIs. In fact, there is still no very good and efficient mechanism.
Disclaimer: Of course, the above is my personal opinion, representing my current understanding and judgment of Oracle, and external API types of Oracle, which could be completely wrong. Welcome to discuss and correct.
Blockchain Practice: The Position of Smart Contracts in Applications#
As we get to know more about blockchain and smart contracts, we will find that actually blockchain and smart contracts are just a small part of a complete application. Relying solely on blockchain and smart contracts themselves is far from enough to build a complete user experience application. From this perspective, the position of blockchain and smart contracts in a system is similar to that of databases and stored procedures in the system. They are both at the core of the entire system, but to form a complete user-friendly application, cooperation from other parts is necessary.
In a complete Ethereum Dapp, Ethereum and smart contracts actually only account for a small part. In this example, this is basically a complete web application plus the part that interacts with smart contracts.
The diagram above shows a typical architecture of a blockchain application using Ethereum. In addition to traditional web servers and database servers, smart contracts deployed on the blockchain are crucial. Without this key component, the application may have no difference from a traditional web or mobile application.
In this design, we can see that a small part of the complete application logic is actually completed "on-chain", in other words, in smart contracts, while another part is the traditional application implementation, which is the "off-chain" logic. In fact, almost every blockchain application contains both "on-chain" and "off-chain" parts.
Some logic placed off-chain may be unnecessary, such as logic related to the interface, but there is some logic that cannot be implemented by smart contracts. For example, someone designs a smart contract to make a simple bet with friends "if the Chinese national football team wins, then I will do something", it sounds simple and easy to implement, but the biggest issue is that the blockchain does not have a reliable way to determine if "the Chinese national football team wins" is a fact.
Using Ethereum's smart contracts as an example, it can only access the state on its chain, and it cannot actively access off-chain data. A smart contract cannot simply call an API or access a web service to obtain off-chain data. This design is not a limitation of Ethereum, but intentionally designed this way. The logic of smart contract code emphasizes "determinism", which means that it should return the same result deterministically regardless of how many times it is run or in what environment. Once an external API is introduced, the external API may be non-deterministic, or temporarily inaccessible due to network failure, or the access result may be incorrect, at which point the smart contract cannot obtain deterministic results.
The sandbox mechanism of EVM: A sandbox is a runtime environment that restricts application access to system resources, and in many cases, the sandbox is implemented within a virtual machine (VM). EVM is a relatively closed environment that does not support direct access to the network and file system.
One of the ways to solve this problem is the oracle, which is currently a hot topic in the blockchain industry. The industry hopes to make a breakthrough in achieving consistency between on-chain and off-chain data and between different chains. The word "Oracle" originally comes from ancient Greek religion, meaning "oracle, prophet, prophecy." A blockchain oracle is a platform that can provide "reliable" external information, and the oracle itself can also be considered as a special type of smart contract.
Ideally, oracle machines can provide a trustless or at least nearly trustless way to obtain external data ("real world" or "off-chain"), such as match results, weather information, gold prices, etc. However, achieving this ideal situation is still unsolved. How to implement a decentralized oracle is a very challenging problem. One approach is to have a large group of users in the network collaborate, combining some incentive mechanisms to submit data from the outside world as a blockchain oracle. Another approach is more "centralized," but much easier to implement. Choose a centralized way and trust this data source, using various technological means to prevent single points of failure or reduce the likelihood of temporary errors, such as using a method of randomly selecting participating data providing nodes to prevent malicious or collusive attacks. Many so-called "prediction market" oracles adopt the former approach, but in reality, there have been no large-scale successful cases so far; while more oracles that allow blockchains to access external Web service data sources adopt the latter approach.
An ideal hypothetical oracle design: the user's smart contract sends requests to the on-chain oracle contract, obtains external data through off-chain API interfaces, more precisely, external data is given to the on-chain oracle contract, and then the oracle contract gives the data to the user's smart contract. In the Internet world, calling data APIs like this is very common. However, the interaction between blockchain and external world data cannot be done with such simple operations – one of the most important reasons is the "uncertainty" of external API responses.
On November 6, 2018, the People's Bank of China released a report entitled "What can blockchain do? What can't it do?" In this report, the definition of an oracle is "a mechanism for writing off-chain information into the blockchain, generally referred to as an oracle." Obviously, this is a definition of an oracle based on the design architecture of Ethereum. Oracles are the bridge between blockchain and the real world for data interaction, with a wide range of application scenarios. It can be said that any application that needs to interact with off-chain data requires a mechanism similar to an oracle. Therefore, one of the important technical challenges currently constraining smart contracts from handling any business logic is oracles.
Many of the current products or discussions about oracle in the network are based on Ethereum or similar designed blockchain. So, do the same problems exist for blockchains with different design ideas from Ethereum? Oracles based on Ethereum or similar architectures generally first write off-chain data back to the chain, so that smart contracts can access this on-chain data. Oracles are responsible for ensuring that the on-chain data matches the off-chain data. For blockchains where smart contracts are not executed using virtual machine mechanisms, such as Hyperledger, smart contract execution environments may allow direct access to off-chain data, making implementation simpler. Essentially, no matter what architecture is used, all blockchains will face the same problem - smart contracts require determinism while external data cannot be guaranteed to be deterministic, creating an inherent contradiction.
Although there has not yet been a perfect decentralized oracle, making it difficult and imperfect for smart contracts to handle our daily logic, but we cannot deny that this trend has taken a big step forward from the era when we could only choose to trust centralized services on the Internet. We don't need to overestimate the capabilities of smart contracts today, but we absolutely cannot underestimate the huge progress and application prospects that smart contracts may achieve in the next 10 years.