An Adapter is a piece of software responsible for executing a specific piece of functionality. A Chainlink node comes with a number of Adapters built in, commonly known as Core Adapters, but can also be extended via Bridges to connect with user defined External Adapters. Core Adapters offered by the Chainlink Node by default:
The result produced from an oracle service, after all safety checks and aggregations have been performed.
Bridge is the connection between a Chainlink node and an External Adapter. The External Adapter runs as a separate service, and a Bridge facilitates communication between the node and one of these adapters.
If you would like to add a new External Adapter to your node, you create a new Bridge either in the GUI or the CLI. Within the Chainlink node, a bridge must have a unique name, but can share the same URL with other bridges. You can also set a different number of default confirmations for each bridge, and an additional payment amount. Once the bridge is added to the node, its name can then be used as a task type in Job Specifications.
Recipient of an Answer provided by an Oracle. The Consumer is commonly a contract, and is also commonly the same entity that requested the Answer, but does not have to be. We have a helper function,
addExternalRequest, that gives consuming contracts the ability to safely check answers it receives without requesting them itself.
External adapters are what make Chainlink easily extensible, providing simple integration of custom computations and specialized APIs.
A Chainlink node communicates with external adapters by sending a POST request with a JSON data payload. More information can be found on the external adapter developers page.
A function selector specifies the function to be called in Ethereum. It is the first four bytes of the call data for a function call in an Ethereum transaction. Solidity contracts have a built-in helper method to access the function selector by using
myFunction is a non-overloaded function in the contract.
Triggers the execution of a Job Spec.
Available initiators are:
Currently only the
execagreement can be used with payment to the node operator. These initiators will use the node configured MINIMUM_CONTRACT_PAYMENT, plus any additional payment if there is a bridge in the given JobID or SAID configured with a payment specified, to determine whether or not enough payment was sent along with the request.
Short-hand for a Job Spec.
The ID associated to a given Job Spec. This will be unique per-node, even with the same contents within the spec itself.
The Job Run is the artifact documenting the outcome of executing a Job Spec. The Job Run is made up of one set of Request Parameters, a TaskRun for each Task Spec in the Job Spec, and a Run Result representing the ultimate outcome of the Job Run.
The Job Specification is the specification of a piece of work to be completed by an Oracle Node. The Job Spec is made up of two main parts:
- The Initiator list,
initiators, lists out all of the ways a Job Spec can be triggered to execute.
- The Task list,
tasks, which specifies all of the the computation steps to perform when executing a Job Spec. The Task list is sometimes referred to as the Job Pipeline because all of the Tasks' operations are performed in order, with the result being fed into the next task.
The off-chain component of an Oracle.
When a Job Run is requested, the full definition of all Task Specs may be filled in. The Requester can specify the rest of the Job Spec definition when requesting a Job Run by passing a JSON payload with the request. The JSON will be merged with each Task Spec before executing each Task Run.
- In Progress
- Pending Confrimations
- Pending Bridge
- Pending Sleep
The ID associated with a given Service Agreement.
The Service agreement consists of a Job Spec and a set of encumbrance parameters that is shared among a creator and multiple Chainlink nodes. Information on service agreements can be found on our Wiki.
Another short-hand for a Job Spec.
Short-hand for a Task Spec.
The Task Spec is the definition for an individual task to be performed within the job specification by a specific adapter. The Task Spec always includes a
type field which specifies which adapter will execute it. Optionally, a Task Spec can specify additional
params which will be passed on to its adapter, and
confirmations which specify how many confirmations a Task Run needs before executing.
Updated about a year ago