Chainlink Node Model
In the diagram above, we see 4 distinct entities:
- External Data
- External Adapter(s)
- Chainlink Node
- Blockchain Node
These entities represent the major external components of Chainlink’s architecture. Below, we will dive into the details of each one and discuss their relationship, represented by the arrows, with one another. It’s important to note that while these entities are separated in the diagram, external adapters, the Chainlink node, and the blockchain node may all exist on the same resource.
External data may represent an API, whether open or private, another blockchain, network, or any repository of data that would need to be read or written to.
External Adapters allow for additional functionality outside of what is supported within the core Chainlink Adapters. External adapters may be written in any language and can operate as a separate service that accepts and responds with JSON formatted data.
The red arrow above the External Adapter(s) entity represents connectivity between the adapter and external data. This may be necessary when the external data provider requires authentication in order to establish connectivity. Credentials for that provider can be stored in the adapter, rather than the Chainlink node itself, giving the node operator complete control over how to securely store their credentials. The Chainlink node will pass an “id” to the external adapter, which is the JobRunID that the external adapter should include in its response back.
The Chainlink node handles jobs, tasks, scheduling, and signing transactions for the blockchain. The Chainlink node runs through a specified set of sequential processes and includes a number of core adapters which give it support to read and process data, and write to the blockchain. The Chainlink node also contains the keystores used to sign transactions. This prevents needing to keep the sensitive keystore files unlocked on the blockchain node.
The green arrow represents connectivity to external data which does not require any sort of authentication. The Chainlink node can read open APIs, process their response, and write to the blockchain without any external adapters.
The blue arrow represents the Chainlink node’s connectivity to its external adapter(s). The node operator must provision and add each external adapter they are willing to support as a bridge, and the adapter may be on a separate system than that which the Chainlink node resides on.
The blockchain node monitors the blockchain and allows the Chainlink node to look for specific events to occur to initiate a job. It also allows the node to broadcast its signed transactions, which return data to consuming contracts. In the case of the blockchain node going offline, the Chainlink node will continuously attempt to reconnect, and monitor the missed blocks when connectivity is restored.
The black arrow represents connectivity between the Chainlink and the blockchain node. The Chainlink node will subscribe to the blockchain node in order to read events occurring on the blockchain, and send signed transactions to it in order to publish responses.
Chainlink Requester Model
When you create a Chainlink request, your Requester Contract sends an
on-chain transaction to an Oracle Contract, indicated by the red arrow
below. That transaction transfers LINK, along with the data representing
your request, using
transferAndCall. The Oracle Contract tracks LINK balances from requesters and emits an event when it receives LINK via
which notifies the off-chain Chainlink network that a request has been
initiated, indicated by the black arrow below. Chainlink nodes monitor
the blockchain for these events and will begin process
With the request received, Chainlink performs the work of the request and returns the answer to the oracle contract, indicated by the blue arrow. The Oracle Contract updates the LINK balance to pay the node operator and returns the result to the Consumer Contract, indicated by the green arrow.