Deep Dive to Decentralized Oracle Networks
For the first article of the series:
In the first article, I used the following expression.
If Blockchain networks represent Galaxies, Chainlink represents the entire Universe with its own Galaxies.
I would like to start this article by deepening this concept.
Galaxies, which represent Blockchains, exert gravity on each other due to the masses of the planets in them, and the Planet/Galaxy movements we observe today emerge with space-time distortions.
Sometimes these large masses (LUNA) collapse into each other and form black holes.
Even sometimes, Galaxies (Solana), which emerge with the claim of “Composability”, try to harbour the entire Galaxy population within a single planet.
But these Galaxies have no connection with each other. They cannot exchange population (data) with each other.
The ever-growing universe becomes unexplorable for our disconnected Galaxies. These galaxies need to communicate with each other.
At this point, a large Oracle network is established that provides communication between all these Galaxies and makes these Galaxies more habitable.
Thanks to this Oracle, our Galaxies will be able to be aware of each other, and when necessary, they will make up for their deficiencies.
Section 1: Security Models and Objectives
🕸️ First of all, in order to make this Oracle (Chainlink) more functional, we should divide it into structures called Decentralised Oracle Networks, DONs. There should be a separate job description for each DON. While one of them generates a Random Number (VRF), another one would ensure pricing data for fruits and vegetables are available in all Galaxies (Data Feeds).
In this way, our Oracle will have a “Modular” structure. For each DON, we should define its own consensus model and security assumptions. In this way, we can create new DONs according to our needs.
The term Decentralised Oracle Network is used to cover the oracle network system with all its functions, both protected by the oracle nodes and defined as the API structure.
The term Ledger (𝓛) is used for the data structure maintained by the DON and the systems it provides.
Decentralised Oracle Network is not a blockchain, it is a structure created to support blockchains. A DON is expected to use a BFT-type consensus, but the choice is left to the developers.
A Ledger (𝓛) is a set of ledgers/states in which the data/transactions are ordered in a sequential order. It has similar features to blockchains. A 𝓛 has the following features:
Append Only; Once a data is added, it cannot be changed,
Public; Publicly available,
Available; Only nodes can add data, but anyone can withdraw data.
Instead of an independent DON structure, the nodes of a PoS network can also be designed to operate as DON nodes.
However, DONs are expected to maintain a committee-based consensus protocol. But this is only an expectation, DON developers can program as they wish.
Bolstering Trust Model
An important feature of Chainlink is the ability for users to select nodes based on decentralised records of their performance history.
With the Staking Mechanism, which I will discuss later, and the Implicit-Incentive Framework mentioned in the previous post, users have a strong influence on measuring and improving the security of DONs.
In the same framework, DONs themselves will be able to enforce various security requirements on participating nodes.
Section 2: What Can a Decentralized Oracle Network Do?
In this chapter, we will discuss the design of DONs in a simple but powerful way.
Applications on the DON are divided into 2 categories as “executables” and “adapters”.
An “executable” is a pre-programmed program that produces deterministic outputs as a result of its operation, similar to smart contracts. Executables contain “initiators” that the programme will call when a predefined event occurs.
“Adapters” are the keys to the off-chain world and are called when the “initiator” or the core logic in the“executables” is triggered. Although their behaviour depends on external resources, “initiators” and “adapters” can behave non-deterministically.
We describe the DON developer interface and the functioning of “executables” and “adapters” in terms of the three resources used to characterise computing systems;
- Networking
- Computing
- Storage
2.1) Networking
Adapters are interfaces that allow executables running on the DON to send and receive data from non-DON systems. They can work bilaterally. They can also use cryptographic functions such as Secure Multy-Party Computation. Let’s take a look at some example designs:
Blockchains -> An adapter defines how an adapter can read block, transaction, state data from a blockchain or how it can send transactions, data to a blockchain. It can also be used for mempool operations.
Web Servers -> Adapters provide APIs for how data can be retrieved/sent from web services.
External Storage -> An adapter can be designed to write data to or pull data from a server outside the DON.
Other DONs -> Adapters can provide data flow between DONs.
During the initial design of the DON, it is expected that there will be adapters called “building block adapters” that connect to external resources. It is also expected that DON-specific adapters will be allowed to be published later by DON nodes.
The main goal is to make the adapters (and therefore the servers from which data can be retrieved) more widespread over time. The biggest expectation at this point is that users will be able to install adapters.
Some Adapters should be built to ensure the continuity and availability of external resources controlled by a DON. For example, cloud storage is a service that requires maintenance.
A DON can also perform decentralised management of private keys on behalf of users or executables.
2.2) Computation
Executable structure is a piece of code in a DON. There are two inputs;
exec = (logic, init)
Logic is the set of entry points of a deterministic programme.
Init represents specific triggers (initiators).
All the input data that the code fragment in the executable will receive must be contained in the Ledger (𝓛).
2.2.1 => Initiators
Initiators cause “job executions” based on events/messages that occur on Chainlink nodes. This is the same for a DON, with the difference that an initiator can trigger specific executables.
An initiator can be triggered by time or an external factor.
Initiators are an important addition that distinguishes an executable from a smart contract. Executables can run autonomously because they can run as a result of triggering initiators, while initiators can be triggered based on time.
There are 2 main features that distinguish executables from smart contracts:
Confidentiality -> Executables can perform a secret computation. The outputs of these confidential computations are not necessarily shared with blockchains or external sources.
Supporting Role -> Executables support smart contracts. For this reason, they have some limitations. For example, since Executables comply with the security assumptions in the DON, smart contracts can firewall against the DON with “guard rails”.
3.3) Storage
As a Committee-Based system, DONs can store the same amount of data permanently much cheaper than a permissionless blockchain. They can also reference external storage solutions such as Filecoin and link these systems with blockchains.
These solutions are attractive for the State Bloat problem.
DONs store data on nodes or an external source according to their intended use. They store the data secret-shared with Secure Multiparty Computation or Fully Homomorphic Encryption or using Trusted Execution Enviroment (TEE, I will explain this structure shortly).
DONs are expected to be a memory management application for blockchains and smart contracts.
3.4) Transaction Execution Framework (TEF)
The Transaciton Execution Framework is designed for the efficient communication of a smart contract between Blockchain and DON.
TEF can support Fair Sequencing Service (FSS) and Layer 2 networks. It is one of the main foci of FSS.
For the use of TEF, the target smart contract is transformed into a Hybrid Smart Contract. This transformation creates a Hybrid Smart Contract consisting of 2 parts:
The so-called “anchor contract”, which is located on the blockchain,
On DON, this is an executable that triggers the smart contract.
Our anchor contract manages the assets, provides state changes on the blockchain, and runs guard rails against DON failures.
Our executable queues transactions using FSS and adds oracle data to these transactions.
3.5) Mempool Services
With the support of TEF and FSS, Mempool Services (MS) will be added to DON as an application-layer update. With MS, Hybrid Smart Contract transactions falling into Mempool will be collected. The collected transactions will be forwarded to the relevant executables of the DON. The transactions organised here will be sent back to the target smart contract and will be used to create new transactions.
3.6) Chainlink’s Current Stars
3.6.1 => Off-Chain Reporting (OCR)
OCR collects Oracle reports and forwards them to the target smart contract. It works partially like BFT Consensus.
In a BFT consensus, if the faulty/fraudulent nodes are less than 1/3 of all nodes, liveness and correctness are ensured. But as I said, OCR is not completely a BFT consensus.
Nodes do not keep a global state on OCR. Also, the Leader Node can behave unstable without jeopardising the security of the system.
OCR uses a message type called “medianised aggregation of values”, which averages the incoming data and converts it into a common message. We call this message “attested reports”.
The assumption is this: The average value is a value between the data of 2 honest nodes. This is where OCR gets its security.
The leader can have some influence on the average value in a certified report as long as it is subject to an accuracy condition.
OCR has some functionalities that BFT does not have:
All-or-nothing off-chain report broadcast (Fairness principle): OCR is based on sending the attested report to all nodes at the same time or not sending it at all. This way, honest nodes remain in the majority and the report is sent to the destination blockchain without errors.
Reliable Transmission (Liveness principle): The report (even if it is incorrect) is sent to the target smart contract at a certain time.
Contract Based Trust Minimisation (Correctness Enforcement Principle): If a new report is significantly different/incorrect from the previous ones, the report is not accepted by the target smart contract. This is an example of “Guard Rails”.
3.6.2 => DECO and Town Crier
DECO and Town Crier are 2 important technologies used and developed in Chainlink networks.
Most web services use TLS to allow users to access the service securely.
(HTTPS → HTTP using TLS)
Most TLS-enabled servers have one notable limitation. The data is not digitally signed. A user or “Prover” cannot present data from a server to a “Verifier”, such as oracle, smart contract, etc. that can guarantee the authenticity of the data.
If there is digital signing, there is a confidentiality problem in the system. The “Prover” may want to hide some sensitive information, but he cannot do that because the main feature of digital signatures is that the message/text cannot be changed.
Thanks to DECO and Town Crier, the Prover can send the data received from web services to the “Verifier” by adhering to the principles of integrity and confidentiality.
The important feature of both systems is that they do not require any changes to the target web server. They can work with a TLS-enabled server.
The 2 systems are similar, but there are differences in security assumptions and practices.
DECO
Cryptographic protocols are used for Integrity and Confidentiality.
When communicating with a web server using DECO, Prover also engages an interactive protocol with Verifier.
Within the current round, Prover can prove a piece of data “D” to Verifier. It can also send parts of “D” or “D” with ZK-Proof.
In a typical use of DECO, a node/user forwards the “D” data received from the web server in a private session to all nodes in a DON. The entire DON can verify “D”.
Even if only a single DON node has access to the source of “D”, the entire DON can verify “D”.
Town Crier
Town Crier, like Intel SGX, is based on the use of a Trusted Execuiton Enviroment (TEE). The execution takes place in a closed box, unavailable and in secret.
Even the person running TEE cannot see inside this box and cannot tamper with it.
Town Crier can do everything that DECO does. While there is only one Verifier in DECO, thanks to Town Crier, public proof sharing can be done to everyone. In addition, secret data can be taken and used without decrypting.
The negative feature of Town Crier is that it relies on Trusted Execution Enviroment.
We are putting an end to our adventure here for now. Please read this article carefully and try to understand it. Difficult days are behind us. From here on, we will examine the design details of existing applications and services such as FSS.
If you like the article, you can support by sharing it.
Alperen Tunçkıran / Chainlink Community Advocate
Twitter : @blockofchain