Chainlink is not a singular monolithic network but rather a collection of more than 1,000 decentralized oracle networks, each configured to meet the specific requirements of its distinct set of users.
While oracle networks share many common characteristics with blockchains—namely decentralization and cryptoeconomic incentives—there are key differences in their operation. Blockchains operate in a highly deterministic and predictable environment, focused on validating transactions using cryptography (private keys and hash functions), as well as historical state (previously validated transactions stored on the ledger). Oracle networks, on the other hand, operate in highly non-deterministic and unpredictable environments where consensus is generated about external events in the real world.
Oracle networks are not static but rather require regular updates and adjustments to maintain a high level of security and reliability. The ability for adjustments to be made in response to unpredictable externalities is how Chainlink has securely scaled to over 1,000 independent oracle networks and can continue scaling to help secure onchain markets that potentially involve trillions of dollars worth of tokenized assets.
In order to meet user demand and continuously improve performance, Chainlink services are updated from time to time to introduce new features and functionalities. Additionally, due to the dynamic nature of offchain environments, swift updates may also be required in response to various externalities. Examples may include, but are not limited to, token migrations, protocol rebrands, extreme market events, and upstream issues with data or node operations.
In alignment with software development best practices, updates can encompass offchain and/or onchain processes as Chainlink services are composed of both onchain smart contract logic and offchain infrastructure such as the Chainlink node client and data provider end-points.
Offchain updates commonly take place at the node operator level, where each individual operator manages their own Chainlink node configuration. Updates can include upgrading to a new Chainlink node software version to improve performance or changing API endpoints in a job specification if a data provider becomes unreliable. Offchain updates can also take place at the data provider level, such as responding to a token migration event or other externalities.
Onchain updates take place at the smart contract level, where a multi-signature safe (multisig) is used to modify onchain parameters relating to a Chainlink service. This can include replacing faulty nodes on a specific oracle network, introducing new features such as Offchain Reporting, or resolving a smart contract logic error. The multisig-coordinated upgradability of Chainlink services involves time-tested processes that balance collusion-resistance with the flexibility required to implement improvements and adjust parameters.
Specifically, the use of a multisig to modify the onchain parameters of Chainlink services allows for a safe, secure, and rapid response to black swan events and other potential incidents on the order of minutes, minimizing service interruption for users. Alternative methods to incident response that don’t utilize a multisig can introduce severe risk to users. For instance, oracle services with immutable onchain logic require a full contract redeployment if any onchain parameter requires modification. This can delay incident response times, introduce significant coordination friction, and necessitate additional actions from users who may not respond in a timely enough manner.
Signers on Chainlink Gnosis Safe multisigs are selected from multiple high-quality Chainlink node operators with a proven, multi-year track record of securing billions in value within the Chainlink Network, as well as from Chainlink Labs. Signers are also spread across multiple different geographic locations globally and may be rotated on a periodic basis to help mitigate potential risks, such as geographic concentration, as they arise.
In alignment with industry practices, the identities of signers in Chainlink Gnosis Safe multisigs are not publicly disclosed. Disclosing the exact identities could put those individual signers at risk, such as exposing them to potential spear phishing attacks and other forms of targeted exploitation or social engineering. This balance between transparency and operational security reflects the security-conscious approach taken to every aspect of the Chainlink Network.
As the Chainlink ecosystem continues to evolve, so too has the approach taken to the upgradability of different oracle networks. For example, all onchain security-critical configuration changes and upgrades to the Cross-Chain Interoperability Protocol (CCIP) must pass through a Role-based Access Control Timelock (RBACTimelock) smart contract. Any proposal must either (1) be proposed by a dedicated ManyChainMultiSig contract and then be subjected to a review period, during which the node operators securing CCIP are able to veto the proposal; or (2) be proposed by a dedicated ManyChainMultiSig contract and be explicitly approved by a quorum of the node operators securing CCIP, providing an alternative path during time-sensitive circ*mstances.
Any onchain update that passes the timelock without a veto becomes executable by anyone, which can be done by running a timelock-worker to process executable upgrades. Additionally, CCIP uses a novel ManyChainMultiSig contract structure, which supports the signing of multiple transactions that target multiple chains with a single set of signatures. This provides a scalable solution to managing various CCIP configurations across a growing number of supported blockchains.
With Chainlink Staking v0.2, all onchain security-critical configuration changes and upgrades must pass through a timelock smart contract, which features a time delay of up to a few weeks, with critical configuration changes taking the longest (longer than the unbonding period for withdrawing staked LINK). This allows the community to review and choose to opt out of such changes before they are implemented onchain.
Moreover, Chainlink is a generalized and modular protocol that enables oracle networks to be customized to meet the exact requirements of users. This includes the ability of users to set up and launch their own Chainlink oracle networks with custom configurations and upgradability processes.
Security is the number one priority for the Chainlink ecosystem, a north-star objective we do not compromise on. As new technologies arise and the Chainlink platform expands, we will continue to evaluate and implement the best and most secure processes for managing the upgradability of Chainlink services. Information on the upgradability of Chainlink Data Feeds can be found in the Chainlink Documentation.
