The commonly used definition of an oracle in regards to blockchain technology is to retrieve data from the internet and feed it to a smart contract.

Chainlink provides the functionality to do that in a decentralized manner, but it also adds some extra power, by making use of external adapters to produce outputs. The outputs can be passed on to other external adapters within the Chainlink node and can even give Chainlink the capability to utilize private resources and blockchains residing in a company’s network. Throughout this article, I’m going to refer to this fictional company as such, without a specific name.

A simplified workflow for this diagram is:

A) Chainlink nodes are selected for the contract, referred to as a job

B) The nodes return a result to a smart contract

Through the rest of this article, I’ll be mainly focusing on the processes, represented by the arrows, but I’ll include entities in the workflow where explanation is needed.

If we change the perspective of the workflows described above to that of the node itself, we can see that the process is a little more involved, but the concept remains the same.

To explain what each process is doing:

A) Chainlink nodes are selected for the assignment

B) The nodes use their own credentials stored in external adapters

C) Data is returned to the node

D) The result is provided to a smart contract on the blockchain

Thinking about the data retrieval process in this way gives us a closer perspective from that of the node itself. If you watch my node architecture video, you’ll see that pieces of the node can be separated from the Chainlink core software. In particular for this example, we’re talking about external adapters.

Process B in the diagram above had to make use of an external adapter in order to manage the credentials necessary for that data source. Nodes will need an external adapter for each resource that requires the node operator’s credentials in order to retrieve data. The only limit to the number of adapters per node is based on hardware capabilities of handling a large number of requests at once.

Going further into the external adapter’s capabilities, we’ll introduce the concept of runs. Runs are a way to send the results of an adapter to another external adapter for further processing, called run results. This can continue as many times as necessary since external adapters are, by design, service-oriented and separated from the ChainLink core software.

The basic workflow for sending run result data to another external adapter is:

A) The node uses its stored credentials in an external adapter to connect to a data provider

B) The data is retrieved from the source, and a run result is created

C) Another external adapter picks up the resulting data and processes it, this can actually repeat several times (chaining adapters)

D) The result of that processing is returned to the node software

E) The end result is returned to the smart contract on the blockchain

Finally, the diagram that brings in everything we’ve learned about adapters and runs and provides a real-use case for internal processes.

Workflow for this type of assignment is:

A) A user creates a smart contract

B) When choosing nodes, they ensure that their nodes are included during manual selection

C) The selected nodes pick up the assignment

D) The nodes use stored credentials to connect to external resources

E) The retrieved data is returned to the node

F) Resulting data is passed on to another external adapter, which has its own stored credentials

G) Using the data returned in process E, any number of internal processes can occur, including logging to private blockchains, off-chain payment transactions, etc.

H) Any result from the snapshot is returned to the node

I) Final result is returned to a smart contract on the public blockchain

In this diagram, there are a few things that are different from previous examples. Smart contract creators can specify which nodes to use for an assignment by white listing nodes by their ID.

Let’s also look specifically at the entity labeled G. Getting data here is possible because another external adapter running on our fictional company’s nodes was able to pass the “run result” data to their internal API. Keep in mind that since external adapters are separate from the Chainlink node, it’s practically endless for what they can do. As long as they return acceptable data to the smart contract creator and it conforms to the adapter schema, then it can make use of the Chainlink network.

In this scenario, the node’s API call (process F) is going to trigger internal actions to take place within a closed network with credentials supplied by the external adapter. All the logic (both business and programming) for what to do with that API call remains in the control of the company. This also means that the speed of the smart contract’s blockchain is not a limiting factor for any internal process. Once that call has been made, we would simply return the answer along with any data provided by the entity G to the smart contract residing on the blockchain.

There are probably some initial concerns of security with this scenario, so let’s discuss that now. First, one might question if any node could come along and call this API which would modify a company’s private blockchain. The answer is no, since credentials would be stored in the external adapter, that information is not publicly available. There’s also no requirement for the external adapter to be open-source. Anyone can develop their own external adapters and keep them to themselves, and for a secure API like in this scenario, that is a valid cause.

Then there’s also a concern about making sure that the nodes ran by the company are selected for the assignment. This can be done by manually matching nodes while setting up the Chainlink smart contract and specifying the nodes’ ID.

Hopefully this helps you understand some of the added functionality of external adapters while using Chainlink as an oracle service. Feel free to leave a comment below if you have any questions, contact me on the Chainlink Slack (we have a #Node_Information channel), or on the Chainlink Gitter lobby.