Offchain Architecture - Overview

CCIP's offchain architecture includes the following:

• Decentralized Oracle Networks (DONs): Running offchain consensus using the Offchain Reporting Protocol (OCR).
• Interaction Components: Managing communication between the CCIP DONs and the RMN.

Components

CCIP Decentralized Oracle Networks

With the CCIP v1.6 architecture, there is a single DON called the Role DON that includes all participating nodes. Two OCR plugins run on these nodes:

1. Commit OCR Plugin

   • Coordinates observations from multiple source chains.
   • Requests blessings from the RMN (when applicable) and posts a Commit Report on the destination chain.

2. Executing OCR Plugin

   • Monitors pending executions on the destination chain.
   • Verifies events on the source chain and executes messages accordingly.

Note: For simplicity, we sometimes refer to the nodes running the Commit OCR Plugin as the Committing DON and those running the Executing OCR Plugin as the Executing DON. However, these are not separate oracle networks; they are subsets of the same Role DON, distinguished solely by their assigned roles.

Role DON: Diagram and Explanation

Let's take an example from the diagram above to understand the key components. The diagram shows a Commit OCR instance configured for a destination chain (Chain C). Key details include:

• Commit Role DON

  • Represents all participating nodes.
  • Within the Role DON, a specific group of nodes—sometimes called a "sub-committee"—may be assigned chain-specific roles.

• Chain-Specific Roles (as illustrated)

  • Green Rectangle: Nodes observe Chain A (i.e., they read from Chain A).
  • Orange Rectangle: Nodes observe Chain B.
  • Blue Rectangle: Nodes write commit reports to Chain C.
  • Overlap: Note that groups may overlap. For example, the four nodes in the bottom-left corner of the Role DON might not connect to Chain A or Chain C, demonstrating flexibility in node participation.
  • Interaction with RMN: The Commit OCR interacts with RMN nodes to receive RMN blessings. These blessings act as independent attestations of the validity of source chain observations and are used to form a consolidated set of merkle roots.

• Configuration and Role Validation:

  • Node roles are configured on the Home Chain (i.e., Ethereum) through specific contracts.
  • The node software reads from the CCIP Home and RMN Home contracts to verify that each node is authorized for its role—whether for making observations or providing RMN blessings.

High Level Flow

Below are the high-level steps for the Commit OCR process and the Executing OCR process.

Commit OCR Process

• Observation Phase

  • Each subcommittee reading from a source chain reaches consensus on the range of messages to build a merkle root.
  • A minimum threshold of valid observations is required for consensus.

• Report Building Phase

  • For source chains where RMN blessing is enabled, the leader of the OCR round queries the RMN nodes for the defined message ranges.
  • RMN nodes return independently constructed merkle roots for these ranges.
  • After validating the returned merkle roots, the leader sends the consolidated set of merkle roots to the RMN for signatures (a single signature may cover multiple merkle roots).

• Query Phase

  • The leader shares the Commit Report (which may include RMN signatures) with the rest of the nodes in the Role DON for validation.
  • Invalid observations are dropped and the remaining valid ones must meet the threshold to achieve consensus among the nodes.

• Reporting Phase

  • A subcommittee of nodes writing to the destination chain submits the final Commit Report onchain.
  • The report may include merkle roots from multiple sources—some of which have RMN signatures.
  • Additionally, the Commit plugin posts price reports for fee tokens, so the Commit Report can contain a combination of merkle roots and price reports.

Executing OCR Process

• Pending Execution Check

  • The subcommittee connected to the destination chain checks for pending executions that have been committed via a Commit Report.

• Validation and Optimization:

  • The DON coordinates to validate the corresponding source chain events for these pending executions.
  • Once validated, the Executing DON optimizes the set of messages to be batched for execution. This optimization considers factors such as the gas limit and specific nuances of the destination chain.

• Execution:

  • The message (or batch of messages) is executed on the destination chain.