CCIP Concepts

Before you explore how Chainlink CCIP works in the architecture guide, it is best to understand the core concepts.

Prerequisites

Prior to learning about Chainlink CCIP, you should understand these fundamental blockchain concepts.

Accounts: you should understand the differences between Externally-owned accounts (EOA) and Contract accounts.
Smart Contracts.
Decentralized Applications (dApps).
ERC-20 Token Standard.
Merkle Trees.

Cross-Chain dApps

Cross-Chain Decentralized Applications (Cross-Chain dApps) are decentralized applications designed to interact with multiple blockchain networks using cross-chain interoperability protocols. Each application leverages the unique strengths of its underlying blockchain network, providing a unified and seamless user experience. Cross-Chain dApps enable transactions, communication, and data sharing between blockchains, increasing functionality and cooperation between multiple blockchain ecosystems.

Interoperability

Interoperability is the ability to exchange information between different systems or networks, even if they are incompatible. Shared concepts on different networks ensure that each party understands and trusts the exchanged information. It also considers the concept of finality to establish trust in the exchanged information by validating its accuracy and integrity.

CCIP uses interoperability to help web3 developers overcome blockchain restraints, enable specialization of web3 applications, and allow dApps to leverage the liquidity and benefits of multiple blockchain ecosystems.

To learn more, read about blockchain interoperability and cross-chain smart contracts.

Finality

Finality refers to the state of irreversibility and permanent record of a transaction on the blockchain. If the parameters for finality are properly set, the likelihood of irreversibility is extremely low. For CCIP, source chain finality is the main factor that determines the end-to-end elapsed time for CCIP to send a message from one chain to another.

Finality varies across different networks. Some networks offer instant finality and others require multiple confirmations. These time differences are set to ensure the security of CCIP and its users. Finality is crucial for token transfers because funds are locked and not reorganized once they are released onto the destination chain. In this scenario, finality ensures that funds on the destination chain are available only after they have been successfully committed on the source chain.

Lane

A Chainlink CCIP lane is a distinct pathway between a source and a destination blockchain. Lanes are unidirectional. For instance, Ethereum Sepolia => Polygon Mumbai and Polygon Mumbai => Ethereum Sepolia are two different lanes.

Decentralized Oracle Network (DON)

Chainlink Decentralized Oracle Networks, or DONs, run Chainlink OCR2. The protocol runs in rounds during which an observed data value might be agreed upon. The output of this process results in a report which is attested to by a quorum of participants. The report is then transmitted on-chain by one of the participants. No single participant is responsible for transmitting on every round, and all of them will attempt to do so in a round-robin fashion until a transmission has taken place. In the context of CCIP, a lane contains two OCR DON committees that monitor transactions between a source and destination blockchain: the Committing DON and Executing DON. Read the Architecture page to learn more.

Active Risk Management (ARM) network

The Active Risk Management (ARM) network is built using off-chain and on-chain components:

Off-chain: Several ARM nodes continually monitor all supported chains against abnormal activities
On-chain: One ARM contract per supported CCIP chain

Off-chain (ARM node)

The ARM network is a secondary validation service parallel to the primary CCIP system. It doesn't run the same codebase as the DON to mitigate against security vulnerabilities that might affect the DON's codebase. The ARM network has two main modes of operation:

Blessing: Each ARM node monitors all Merkle roots of messages committed on each destination chain. The Committing DON commits these Merkle roots. (More information on Merkle roots can be found on the architecture page). The ARM node independently reconstructs the Merkle tree by fetching all messages on the source chain. Then, it checks for a match between the Merkle root committed by the Committing DON and the root of the reconstructed Merkle tree. If both Merkle roots match, the ARM node blesses the root to the ARM contract on the destination chain. The ARM contract tracks the votes. When a quorum is met, the ARM contract dubs the Merkle root blessed.
Cursing: If an ARM node detects an anomaly, the ARM node will curse the CCIP system. After a quorum of votes has been met, the ARM contract dubs the CCIP system cursed. CCIP will automatically pause on that chain and wait until the contract owner assesses the situation before potentially lifting the curse. There are two cases where ARM nodes pause CCIP:
- Finality violation: A deep reorganization which violates the safety parameters set by the ARM configuration occurs on a CCIP chain.
- Execution safety violation: A message is executed on the destination chain without any matching transaction being on the source chain. Double executions fall into this category since the executing DON can only execute a message once.

On-chain (ARM contract)

There is one ARM contract for each supported destination chain. The ARM contract maintains a group of nodes authorized to participate in the ARM blessing/cursing. Each ARM node has five components: an address for voting to curse, an address for voting to bless, an address for withdrawing a vote to curse, a curse weight, and a blessing weight. The contract also maintains two thresholds to determine the quorum for blessing and cursing. There are two different voting logics depending on the mode:

Blessing voting procedure: every time an ARM node blesses a Merkle root, the ARM contract adds the blessing weight for that node. If the sum exceeds the blessing threshold, the ARM contract considers the contract blessed.
Cursing voting procedure: an ARM node that sends a vote to curse assigns the vote a random 32-byte ID. The node may have multiple active votes to curse at any time. However, if there is at least one active cursing vote, the ARM contract considers the node to have voted to curse. The ARM contract adds the cursing weight for that node. If the sum of the weights of votes to curse exceeds the curse threshold, the ARM contract considers the contract cursed.

If the ARM contract is cursed, then the owner of the original contract must resolve any underlying issues the original contract might have. If the owner is satisfied that these issues have been resolved, they can revoke the cursing on behalf of ARM nodes.