ChainLink White Paper — Section 2 — Architectural Overview
The Architectural Overview gives the detailed view for how ChainLink fits between the blockchain and the internet. It also provides the technical outlook for how the network will operate. ChainLink is going to be developed on Ethereum initially, with support for other blockchains and cross-chains at a later date. There is also a focus keeping the system separated so that any piece may be easily upgraded. The architectural overview is comprised of only two (but both very important) sub-sections: On-Chain Architecture and Off-Chain Architecture.
On-Chain Architecture is the initial implementation for the ChainLink network. In this method, the majority of the work is done within smart contracts and the retrieving of the data is done within the node. The user-created smart contract is what supplies the query supplied by the smart contract creator for the nodes to individually carry out.
The ChainLink smart contract’s on-chain components are comprised of a reputation contract, and order-matching contract, and an aggregating contract. The reputation contract is what keeps track of the metrics discussed in Section 5. The order-matching contract takes the parameters set by the smart contract creator and accepts bids from individual nodes according to the SLA. Finally, the aggregating contract is what collects each node’s answer and provides a final result to the user’s query (as well as provide metrics to the reputation contract). On-chain aggregation is broken into three steps: oracle selection, data reporting, and result aggregation.
In oracle selection, the smart contract creator (or end-user) specifies the criteria needed by the smart contract, like what information they would like to gather and the number of and reputation of the nodes to be used in the assignment (assignment is another word used for the work required of the nodes). A listing service will be provided to make the oracle selection process easier on the smart contract creator. This will allow the smart contract creator to submit the assignment through the listing service (off-chain), but the final SLA will be met on-chain. Additionally, it may be possible to automatically determine which nodes would be best suited for the assignment with an order-matching contract. This would be possible with the use of rules configured on each node to determine whether they would automatically bid on the assignment or not. If an assignment matches the node’s own criteria, it will bid by paying the configured penalty amount (an amount that would be lost if the node returns unacceptable data). Nodes which were not accepted by the assignment will immediately be able to withdraw their penalty payment bid, and those that were selected will start the assignment.
In data reporting, the nodes simply carry out the assignment as defined by the SLA. This means the node would connect to their API endpoints, process the data through their adapters, digitally sign their responses, and return their answers on-chain.
In result aggregation, nodes reveal their results to the aggregating contract, which calculates an answer for the contract creator’s query. The aggregation contract uses each oracle’s response to report to the reputation contract its validity and timeliness. An additional property of the aggregation contract is that it is entirely configurable by the smart contract creator. In order to deal with varying answers, the smart contract creator my wish to configure the aggregation contract to ignore outlying answers before calculating an average, for example.
The off-chain architecture is made up of the nodes which make up the ChainLink network. Each node must individually connect to other off-chain resources via API calls in order to gather responses for assignments. External adapters may be employed in order to extend the available connections for 3rd party API endpoints.
The ChainLink core software is what translates off-chain data (data which was gathered via an API endpoint) into a way that can be read on-chain. It also handles the details of an assignment, including carrying out an assignment’s sub-tasks as they are configured and scheduled by the smart contract creator.
External adapters are needed for connecting to 3rd party API endpoints. They can be written in any language as long as they conform to the schema defined by ChainLink. External adapters may also chain off one another, accepting the response of one adapter in order to produce another result.
That’s all for this section of the ChainLink white paper. Also see this page which summarizes the ChainLink Smart Contract Process. Let me know what you think and feel free to leave any feedback.
