An adapter or task 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.
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 Jobs.
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 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.
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 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 Task Type or the External Initiator: Defines the ways a Job can be triggered to execute.
- The Task list: The
tasksthat specify all of 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 offchain component of an Oracle.
For data feeds, a phase indicates the underlying aggregator implementation has been updated. Phases are relevant only for the EACAggregatorProxys. You can think of a roundId on the proxies as a large number containing data for two numbers (phaseId + roundId). The roundId is pulled from the aggregator's implementation and combined by bit shifting with the latest phaseId of the proxy.
A Run Result is the result of executing a Job Spec.
- 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.
A v2 job task.
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.