A protocol designed to transfer data and value across blockchains in a trust-minimized manner. This is done using a combination of checks on the source chain(s), destination chains, and off-chain security. This document outlines key security considerations and details the messaging protocol at the data and event processing levels. As this repository is for the off-chain portion of CCIP, we'll focus on off-chain components and the on-chain integration points.
The user interface is not described here. It is largely unchanged compared to the earlier architecture and the public docoumentation provides a comprehensive guide to using CCIP.
The libOCR framework provides security to the system with a Distributed Oracle Network (DON) utilizing a byzantine fault tolerant protocol. Security is enhanced by the Reporting Plugin when the plugins ensure observation thresholds on data used by the system. See the Consensus and Sub-consensus page for more information about how the CCIP plugins use and extend the typical OCR framework.
The protocol is implemented in two phases, each with a corresponding libOCR plugin: commit and execute.
In the commit phase, user created messages are collected from every source chain, a merkle root is generated for messages from each source, and the roots are put into a Commit Report. The report is sent to the on-chain code for final processing where a commit report log is written to the blockchain.
An independant Risk Management Network (RMN) serves as an additional security layer to validate merkle roots. RMN can be thought of as a validation network with veto power. In the previous version of CCIP RMN was an independent component which provided a blessing or curse after the commit report was written to the network. With this architecture the plugin queries the RMN network directly so that the RMN signatures can be included in the initial report.
The report includes additional gas and token price data required by the billing algorithm. Strictly speaking, it is not part of the protocol and could be implemented separately. For convenience it is included in the commit plugin.
More detail about the implementation can be found in the README.
In the execute phase, the plugin searches for commit reports with pending executions. All messages for these commit reports are gathered, and a special merkle proof is computed for all messages ready for execution. These proofs are put into the Execute Plugin Report.
Due to the Role DON architecture, this process has to be done across several rounds of consensus:
- Destination readers look for commit reports.
- Based on the commit reports, source readers fetch the messages.
- Based on the messages, the destination reader determines execution order.
The commit report is sent to the on-chain code for final processing. This step includes token transfers, data handling and user contract interaction.