3 Key Architectural Decisions Behind CCIP’s Advanced Security
From its inception, Chainlink has been committed to providing the most secure infrastructure possible, as secure infrastructure is essential to bringing the world’s assets onchain and powering their movement across various trading environments and regions. Already proven as secure infrastructure in Web3, Chainlink has enabled DeFi to successfully scale by consistently providing secure and reliable pricing data to many of the largest and most critical DeFi applications.
This rigorous security-first approach to developing infrastructure has been applied to the cross-chain problem in the form of Chainlink CCIP. CCIP incorporates many individual key security design decisions, but when compared to other cross-chain systems, there are three standout aspects: the level of decentralization, an independent risk management layer, and client diversity.
In this blog, we’ll dive into why these key features are required to power a secure cross-chain ecosystem.
1. Level of Decentralization
Some cross-chain systems operate using a multisig with a few keys, or a few sets of signers, or as central hubs where all transactions flow through a single environment—potentially exposing them to single points of failure and introducing conflicts of interest that could put user funds at serious risk.
In contrast, every CCIP lane has three individual separate oracle networks, which are responsible for confirming three separate aspects of the transaction. The amount of decentralization within CCIP—just based on the number of nodes independently verifying key parts of the transaction—is at a much higher level than the typical cross-chain solution.
2. Risk Management Network
The second key difference between CCIP and other cross-chain solutions is the presence of an independent active risk management layer—the Risk Management Network. It’s a first-of-its-kind innovation that uses software development principles from the aerospace industry, enabling specific policies and configurations to be encoded to address emergent security risks.
If a chain experiences certain types of risks—block reorganization, reliability issues, new adversarial attacks, and more—actions or mitigations of those risks and conditions can be encoded separately from the core protocol into the Risk Management Network.
In such cases, the core CCIP protocol providing security isn’t altered—more security is being added through the Risk Management Network by putting additional conditions on what a transaction needs to meet. With core security maintained, security is bolstered with additional code and configurations in the Risk Management Network. This unlocks a new layer of decentralization and fault redundancy, and the ability to quickly adapt to emerging risks.
3. Client Diversity
The third key aspect powering a high degree of cross-chain security is client diversity. The two core networks, the transactional DONs (Committing DON and Executing DON) and the Risk Management Network, have been written in separate codebases and programming languages (Rust and Go).
The core protocol is written in a completely separate codebase, in a different programming language, and was initially written by a separate team from the one that wrote the Risk Management Network and its codebase. Both of these parts of the CCIP system continue to be separate.
This is a very significant difference compared to other cross-chain solutions because even if a flaw is found in one of those codebases, that flaw does not extend to the other codebase. CCIP is the only cross-chain solution that provides client diversity in this sense, with separate codebases interacting with each other in a secure way, providing an unparalleled level of security among cross-chain solutions.
Building the Internet of Contracts With CCIP
There are many other security features within CCIP that surpass other cross-chain solutions, including rate limiting, anomaly detection, and more. Its successful operation with no value loss, continual reliability, and successful outcomes underscore the value of the time and rigor invested in its development.
When infrastructure is being built to process and interact with the world’s assets, a security-first approach is critical. Chainlink infrastructure and CCIP are designed to meet the scale and complexity of the traditional financial system, which is processing quadrillions per year.
As CCIP is becoming more and more widely adopted across capital markets it’s becoming the standard method for banks and asset managers to transact across chains. If CCIP is able to continue to gain widespread adoption in the public blockchain world and become the secure standard for transactions across chains in capital markets, it could pave the way to a world where all transactions in the public blockchain world and the private bank chain world merge into a single global Internet of Contracts.
The Future of Assets, Powered by CCIP
CCIP is continually becoming even easier for developers to integrate and use in the public blockchain world, supporting more chains, connecting to more dApps, and powering more tokenized real-world assets and stablecoins, all while maintaining a high degree of security and reliability. This ubiquity across the industry, a defining aspect of CCIP’s hyper-scalable design, is critical to how value moves across chains.
If you want to learn more about CCIP’s underlying architecture and code and start building highly secure and reliable cross-chain use cases, check out the CCIP developer documentation.
Disclaimer: This post is for informational purposes only and contains statements about the future. There can be no assurance that actual results will not differ materially from those expressed in these statements, although we believe them to be based on reasonable assumptions. Interactions with blockchain networks create risks, including risks caused by user input errors. All statements are valid only as of the date first posted. These statements may not reflect future developments due to user feedback or later events and we may not update this post in response.