El protocolo CCIP de Chainlink presenta varias características innovadoras:

1. Transferencias de tokens programables: permiten la personalización de las condiciones de transferencia, lo que permite interacciones financieras más complejas en la cadena de bloques.

2. Transferencias de tokens simplificadas: esta función reduce la complejidad de las transferencias de tokens, lo que hace que las transacciones sean más ágiles y fáciles de usar.

3. Red activa de gestión de riesgos (ARM Network): este sistema de gestión de riesgos está diseñado para mejorar la seguridad y estabilidad de las transacciones.

4. Límites de velocidad (Rate Limits): pueden controlar la velocidad y la cantidad de transferencias de tokens, proporcionando una protección contra actividades maliciosas.

5. Ejecución inteligente: esta característica optimiza la eficiencia de las transacciones, garantizando operaciones blockchain más fluidas y rápidas.

6. Actualizabilidad con bloqueo de tiempo (Time-Locked Upgradability): proporciona una opción para programar actualizaciones o cambios en el sistema, garantizando la adaptabilidad del protocolo en línea con los avances tecnológicos.

La tecnología blockchain nos permite abordar casos de uso con herramientas innovadoras, pero también presenta ciertas limitaciones. Siempre digo que critico mucho la blockchain porque tiene varias limitaciones, pero estas limitaciones fomentan la innovación y el desarrollo de nuevas soluciones.

Cada uno de los proyectos actuales está construyendo su propio ecosistema. Hay muchos allá afuera, y cada día surge uno nuevo, como Ethereum, BNB, Avalanche, Optimism, entre otros. Esto es positivo, pero cada una de estas blockchains representa una isla; están aisladas entre sí y, de manera nativa, no existe un protocolo que permita la comunicación entre diferentes cadenas.

Para entender mejor este desafío, es esencial comprender el concepto de interoperabilidad.

¿Qué es la Interoperabilidad?

La interoperabilidad se refiere a la capacidad de diferentes sistemas y redes para intercambiar información por más de que sean incompatibles el uno con el otro. En el contexto de blockchain, la interoperabilidad permite que diferentes blockchains interactúen y compartan datos de manera segura y eficiente. En este contexto, Chainlink ha introducido Chainlink Cross-Chain Interoperability Protocol (CCIP), un protocolo que promete revolucionar la manera en que las blockchains se comunican entre sí. En este artículo, exploraremos qué es Chainlink CCIP, sus ventajas, y cómo se diferencia de los bridges tradicionales, así cómo la diferencia entre cross-chain y multi-chain.

Hacks de Bridges: Un Problema Crítico

Los bridges (puentes) tradicionales han sido una solución común para la interoperabilidad entre blockchains, pero son centralizados y han demostrado ser vulnerables a ataques. Estos hacks han resultado en la pérdida de millones de dólares en activos digitales. Algunos ejemplos notables incluyen:

• Hack de Poly Network: En 2021, Poly Network, un protocolo de interoperabilidad cross-chain sufrió un ataque que resultó en la pérdida de más de $600 millones de dólares. Cabe señalar que también hubo otro el 2023.

• Ronin Bridge Hack: En 2022, el bridge de Ronin, utilizado por el juego Axie Infinity, fue hackeado, resultando en una pérdida de alrededor de $620 millones.

Estos han dejando en evidencia la necesidad de soluciones más seguras y robustas para la interoperabilidad blockchain.

La Solución: Chainlink CCIP

Chainlink CCIP es un protocolo diseñado para facilitar la interoperabilidad entre diferentes cadenas de bloques. Este protocolo permite la transferencia segura y confiable de datos y activos entre diversas redes blockchain, proporcionando una infraestructura robusta para aplicaciones cross-chain. CCIP utiliza -entre otros componentes- la red de oráculos de Chainlink para ofrecer una comunicación fiable y segura entre las distintas cadenas, reduciendo el riesgo de errores y vulnerabilidades.

Diferencia entre Cross-Chain y Multi-Chain

Para entender completamente el impacto de Chainlink CCIP, es crucial diferencia entre los conceptos de cross-chain y multi-chain:

• Cross-Chain: Se refiere a la capacidad de una blockchain para interactuar y transferir activos o datos directamente con otra blockchain. Esto requiere protocolos y tecnologías específicas para asegurar que las transacciones sean seguras y válidas en ambas cadenas.

• Multi-chain: Implica que una aplicación o proyecto se despliegue en múltiples blockchains, operando de manera independiente en cada una de ellas. Aunque puede haber interoperabilidad entre las versiones de la aplicación en diferentes cadenas, no es un requisito inherente.

Chainlink CCIP se centra en proporcionar una verdadera funcionalidad cross-chain, permitiendo la comunicación y transferencia entre diferentes blockchains de manera segura y eficiente.

Diferencias entre Chainlink CCIP y un Bridge

Nota: Se menciona en reiteradas ocaciones la red de oráculos descentralizada de Chainlink (Decentralized Oracle Network = DON) como si fuera el único componente. Pero en la siguiente sección mencionaremos otros componentes que conforman CCIP. Ya que cuenta con componentes off-chain y on-chain que permiten el funcionamiento integral del protocolo.

1. Seguridad:

   • Bridges: A menudo han sido el objetivo de hacks debido a vulnerabilidades en su diseño y ejecución.

   • Chainlink CCIP: Utiliza la infraestructura de oráculos descentralizados de Chainlink, proporcionando una capa adicional de seguridad y fiabilidad. Los oráculos aseguran que los datos transferidos entre cadenas sean precisos y verificados.

2. Confiabilidad:

   • Bridges: La confiabilidad puede variar dependendiendo de la implementación específica del bridge.

   • Chainlink CCIP: La red de oráculos de Chainlink es conocida por su alta confiabilidad y ha sido y está siendo utilizado por grandes protocolos dentro del ecosistema como AAVE, Synthetix, etc.

3. Descentralización

   • Bridges: Muchos bridges operan de manera más centralizada, lo que puede introducir riesgos adicionales.

   • Chainlink CCIP: Aprovecha la naturaleza descentralizada de la red de oráculos de Chainlink, reduciendo los puntos únicos de falla.

4. Flexibilidad

   • Bridges: Generalmente diseñados para conectar un número limitado de blockchains.

   • Chainlink CCIP: Diseñado para ser altamente flexible y extensible, permitiendo la interoperabilidad entre una amplia variedad de blockchains.

"Uno de los objetivos del protocolo es que CCIP sea para las blockchains como TCP/IP es para el internet".

¿Qué te permite Chainlink CCIP?

Estas son las principales funciones que puedes realizar al día de hoy con Chainlink CCIP.

• Transferencia de Tokens: Puedes enviar tokens desde una cadena a otra, ya sea a un contrato o una EOA. Solo puedes transferir tokens soportados por el protocolo, que hoy en día varían dependendiendo de la blockchain pero comúnmente son: token nativo, wrapped token y USDC. Por ejemplo en Ethereum podrías transferir: ETH, wETH o USDC.

• Mensajes Arbitrarios: Puedes enviar información arbitraria de una blockchain a otra. Solo puedes ser enviada a otro contrato inteligente ya que necesita estar configurado como CCIP Receiver (ya entenderás esto más adelante).

• Tokens y Datos: De igual manera puedes realizar ambas acciones al mismo tiempo: transferir tokens y enviar un mensaje arbitrario.

Conceptos Necesarios

Debemos entender algunos conceptos y la terminología, de otra manera nos volvemos locos. En un principio todo esto puede sonar confuso, pero a medida que vas estudiando y aplicando los conocimientos en ejercicios prácticos, lograrás un entendimiento mayor con facilidad. Y si, grabaré algunos videos para que aprendas como implementar CCIP en distintos casos de uso como NFTs Cross-Chain, no olvides subscribirte a mi canal para no perdértelo.

Finality

También conocida como Finalidad, es la garantía de que las transacciones pasadas incluidas en la cadena son extremadamente difíciles o imposibles de revertir. Si los parámetros de finalidad se establecen correctamente, la probabilidad de reversibilidad es extremadamente baja. Para CCIP, la finalidad de la cadena de origen es el factor principal que determina el tiempo transcurrido de extremo a extremo para que CCIP envíe un mensaje de una cadena a otra.

La finalidad varía en las distintas redes. Algunas redes ofrecen finalidad instantánea y otras requieren múltiples confirmaciones. Estas diferencias de tiempo se establecen para garantizar la seguridad de CCIP y sus usuarios. La finalidad es crucial para las transferencias de tokens porque los fondos se bloquean y no se reorganizan una vez que se liberan en la cadena de destino, En este escenario, la finalidad garantiza que los fondos en la cadena de destino estén disponibles solo después de que se hayan comprometido con éxito en la cadena de origen.

Lane

O Carill, en CCIP es una ruta distinta entre una blockchain de origen y una de destino. Los carriles son unidireccionales. Por ejemplo:

• Ethereum Mainnet ==> Polygon Mainnet

• Polygon Mainnet ==> Ethereum

Son dos caminos diferentes, por más de que estemos hablando de las mismas cadenas, existe solo un camino de ida.

Terminología de Chainlink CCIP

Para comprender como utilizar CCIP necesitas familiarizarte con la terminología, más adelante haremos ejemplos prácticos en los que necesitaremos configurar algunos parámetros propios de cada cadena.

Componentes de Chainlink CCIP: Nos ponemos más técnicos

Detallaremos los componentes y la arquitectura que componen este protocolo de comunicación.

Recuerda siempre que quieras, puedes obtener información desde la documentación oficial:

• Chainlink CCIP

• Descripción General Conceptual

• Arquitectura

• Mejores prácticas

Active Risk Management Network (ARM)

La red activa "Risk Management Network" (ARM) o "Red de Manejo de Riesgos" en español, -aunque solo la traduzco para mejor entendimiento pero recomiendo encarecidamente utilizar los términos en inglés- opera como una entidad autónoma que monitorea y verifica persistentemente el comportamiento de la red CCIP principal, otorgando una capa adicional de seguridad.

Está autenticando de manera independiente las transacciones entre cadenas, buscando anomalías.

Piensa en la red ARM como un centinela, diseñado y entrenado específicamente para comprobar de manera constante el buen funcionamiento de las transacciones.

Reitero, es una red separada y autónoma que funciona aparte de la red principal CCIP, esto un elemento principal para brindarle mayor seguridad al protocolo.

La ARM se compone de elementos dentro y fuera de la cadena, lo que conocemos como on-chain y off-chain.

• Offchain: varios nodos de Gestión de Riesgos están supervisando continuamente todas las cadenas compatibles contra actividades anómalas.

• Onchain: Un contrato de Gestión de Riesgos por cadena CCIP compatible.

Nodo de Risk Management (Gestión de Riesgos) Offchain

La Risk Management Network es un servicio de validación secundario paralelo al sistema primario de CCIP. No ejecuta la misma base de código que las DON para mitigar las vulnerabilidades de seguridad que pudieran afectar a la base de código de la DON. La ARM tiene dos modos principales de funcionamiento, el primero es:

• Blessing (Bendecir): Cada nodo de Gestión de Riesgos monitorea todas las Merkle root de los mensajes confirmados en cada cadena de destino. La Commiting DON compromete estas Merkle root*(raíces de merkle). El nodo de Gestión de Riesgos reconstruye de forma independiente el Merkle tree (árbol de merkle) recuperando los mensajes de la cadena de origen. Luego, busca una coincidencia entre la Merkle root(raíz de merkle)* confirmada por la Committing DON y la raíz del Merkle tree (árbol de merkle) reconstruido. Si ambas Merkle root*(raíces de merkle)* coinciden, el nodo de Gestión de Riesgos bendice*(blesses)* la root del contrato de Gestión de Riesgos en la cadena de destino. El contrato de Gestión de Riesgos realiza un seguimiento de los votos. Cuando se alcanza el quórum, el contrato de Gestión de Riesgos considera blessed (bendita) la Merkle root (raíz de merkle).

En otras palabras Blessing es ...

Cada nodo ARM revisa toda la información resumida que está representada en los árboles de Merkle (Merkle tree). Esta información contiene los mensajes que están siendo transferidos desde una blockchain a otra, de origen a destino. Esta información resumida está registrada por la DON, la cuál supervisa el proceso.

Para asegurarse que todo esté correcto, el nodo ARM hace su propia revisión. Toma todos los mensajes desde la blockchain de origen y crea su propio resumen de la información (reconstruye los árboles de Merkle). Luego compara su propio resumen con el elaborado por la DON.

Si ambos resúmenes coinciden, el nodo ARM le dice "genial, todos está correcto" (dicho de otra manera bendice esa raíz) al contrato ARM en la blockchain de destino. Esta bendición es como decir que la transacción parece legítima.

El segundo modo de funcionamiento para la ARM es:

• Cursing (Maldecir): Si un nodo de Gestión de Riesgos detecta una anomalía, el nodo de Gestión de Riesgos maldecirá*(will curse)* el sistema CCIP. Una vez alcanzado el quórum de votos, el contrato de Gestión de Riesgos califica el sistema CCIP como cursed (maldito). CCIP se detendrá automáticamente en esa cadena y esperará hasta que el propietario del contrato evalúe la situación antes de potencialmente levantar la maldición*(lifting the curse)*.

En otras palabras Cursing es ...

Si un nodo ARM encuentra algo inusual durante su verificación, genera una alarma. Esto es lo que mencionamos como "maldecir" el sistema CCIP.

Esta maldición podemos verla como una señal de advertencia de que algo puede no estar bien con las transacciones que se procesan. Cuando suficientes nodos ARM han dado la alarma (lo que sería alcanzar el quórum), el contrato ARM confirma que existe un problema potencial y etiqueta el sistema CCIP como cursed (maldito).

Una vez que esto sucede, CCIP detiene automáticamente el procesamiento de transacciones en la cadena de bloques afectada. Esta pausa permite verificar el sistema y abordar cualquier problema potencial. El sistema permanecerá en pausa hasta que el propietario del contrato investigue y decida si es seguro reanudar las transacciones, lo que se conoce como levantar la maldición*(lifting the curse).*

Hay dos casos para los que los nodos de Risk Management pausen CCIP.

• Finality violation*(violación de finalidad)*: Se produce una reorganización profunda que viola los parámetros de seguridad establecidos por la configuración de Gestión de riesgos en una cadena CCIP.

• Execution safe violation*(violación de seguridad de ejecución)*: Un mensaje se ejecuta en la cadena de destino sin que haya ninguna transacción que coincida en la cadena de origen. Las ejecuciones dobles entran en esta categoría ya que la Executing DON solo puede ejecutar un mensaje a la vez.

On-chain ARM Contract

Hay un contrato de Gestión de Riesgos para cada cadena de destino admitida. El contrato de Gestión de Riesgos mantiene un grupo de nodos autorizados a participar en la bendición/bendición (blessing/cursing).

Cada nodo de Gestión de Riesgos tiene cinco componentes:

• Un address para votar a maldecir

• Un address para votar a bendecir

• Un address para retirar un voto de maldición

• Un peso maldito (curse weight)

• Un peso de bendición (blessing weight)

El contrato también mantiene dos umbrales para determinar el quórum para bendecir y maldecir. Existen dos lógicas de votación diferentes según el modo:

• Blessing voting procedure (Procedimiento de votación de bendición): Cada vez que un nodo de Gestión de Riesgos bendice una raíz de Merkle, el contrato de Gestión de Riesgos agrega el peso de bendición para ese nodo. Si la suma de los pesos de los votos a bendecir excede el umbral de bendición, el contrato de Gestión de Riesgos considera el contrato bendecido.

• Cursing voting procedure (Procedimiento de votación de maldición): Un nodo de gestión de riesgos que envía un voto para maldecir le asigna al voto un ID aleatorio de 32 bytes. El nodo puede tener múltiples votos activos para maldecir en cualquier momento. Sin embargo, si hay al menos un voto de maldición activo, el contrato de Gestión de Riesgos considera que el nodo ha votado a favor de la maldición. El contrato de Gestión de riesgos añade el peso de maldición para ese nodo. si la suma de los votos a maldecir excede el umbral de maldición, el contrato de gestión de riesgos considera el contrato maldito.

Si el contrato de Gestión de Riesgos está maldito, entonces el propietario del contrato original debe resolver cualquier problema subyacente que pueda tener el contrato original. Si el propietario está satisfecho de que estos problemas se han resuelto, puede revocar la maldición en nombre los nodos de Gestión de Riesgos.

Arquitectura de CCIP

La siguiente figura describe los diferentes componentes involucrados en una transacción cross-chain:

• Las dApps cross-chain son específicas del usuario. Un contrato inteligentes o una EOA (cuenta de propiedad externa) interactúa con el CCIP router para enviar datos arbitrarios o transferir tokens cross-chain.

• Los contratos en azul oscuro son la interfaz CCIP (router). Para usar CCIP, los usuarios solo necesitan comprender cómo interactuar con el router; no necesitan comprender todas la arquitectura CCIP. Nota: La interfaz CCIP es estática y permanece constante a lo largo del tiempo para brindar confiabilidad y estabilidad a los usuarios.

• Los contratos en azul claro son internos al protocolo CCIP y están sujetos a cambios.

Componentes Onchain

Router

El router es el contrato principal con el que interactúan los usuarios de CCIP. Este contrato es responsable de iniciar interacciones cross-chain. Existe un contrato router por cada cadena de bloques. Al transferir tokens, los usuarios deben aprobar los tokens para el contrato router. El contrato router envía la instrucción al OnRamp específico del destino.

Commit Store

La Committing DON interactúa con el contrato Commit Store en la cadena de bloques de destino para almacenar la Merkle root de los mensajes finalizados en la blockchain de origen. Esta Merkle root debe ser aprobada por la ARM antes de que la Executing DON pueda ejecutarlos en la blockchain de destino. El CommitStore garantiza que el mensaje sea aprobado por la ARM y que solo exista un CommitStore por lane (carril)

OnRamp

Existe un contrato OnRamp por carril. Este contrato realiza las siguientes tareas:

• Verifica la validez específica de la blockchain de destino, como la validación de la sintaxis de la dirección de la cuenta.

• Verifica el límite de tamaño del mensaje y los límites de gas.

• Realiza un seguimiento de los números de secuencia para preservar la secuencia de mensajes para el receptor.

• Gestiona la facturación.

• Interactúa con el TokenPool si el mensaje incluye una transferencia de token.

• Emite un evento monitoreado por la DON que realiza la confirmación.

OffRamp

Existe un contrato OffRamp por carril. Este contrato realiza las siguientes tareas:

• Garantiza la autenticidad del mensaje verificando la prueba proporcionada por la Executing DON contra una Merkle root confirmada y autorizada.

• Se asegura que las transacciones se ejecuten solo una vez.

• Después de la validación, el contrato OffRamp transmite cualquier mensaje recibido al contrato Router. Si la transacción CCIP incluye transferencia de tokens, el contrato OffRamp llama al TokenPool para transferir los activos corrector al receptor.

Token pools

Cada token tiene su propio pool de tokens, una capa de abstracción sobre tokens ERC-20 diseñada para facilitar las operaciones relacionadas con tokens para OnRamping y OffRamping. Los pools de tokens proporcionan una limitación de velocidad, una característica de seguridad que permite a los emisores de tokens establecer una velocidad máxima a la que se puede transferir su token por lane (carril). Los pools de tokens están configurados para bloquear (lock) o quemar (burn) tokens en la blockchain de origen y desbloquear (unlock) o acuñar (mint) tokens en la blockchain de destino. Esta configuración da como resultado cuatro mecanismos principales:

• Burn and Mint: los tokens se queman en la blockchain de origen y se mintea la cantidad equivalente de tokens en la blockchain de destino.

• Lock and Mint: los tokens se bloquean en la blockchain de emisión y los "wrapped tokens" totalmente garantizados se mintean en la cadena de bloques de destino. Estos "wrapped tokens" se pueden transferir entre cadenas que NO emiten mediante el mecanismo de "burn and mint".

• Burn and Unlock: los tokens se queman en la blockchain de origen y se libera una cantidad equivalente de tokens en la blockchain de destino. Este mecanismo es el inverso del mecanismo de "lock and mint". Se aplica cuando envías tokens a su blockchain de origen emisor.

• Lock and Unlock: los tokens se bloquean en la blockchain de origen y se libera una cantidad equivalente de tokens en la blockchain de destino.

Quizás lo anterior podría ser un poco confuso, lo principal a entender es que el mecanismo de manejo de tokens varía en función de las características de cada uno de ellos. A continuación veremos algunos ejemplos para ilustrar esto:

• El token LINK se mintea en una única blockchain (mainnet de Ethereum) y tiene un total supply fijo. Esto quiere decir, que CCIP no puede mintear más LINK de forma nativa en otra blockchain. Para LINK, la token pool está configurada para bloquear*(lock) los tokens en Ethereum mainnet (**blockchain emisora*) y mintearlos en la blockchain de destino. Por el contrario, al transferir tokens desde una blockchain no-emisora(cualquier que no sea Ethereum mainnet en el caso de LINK) a Ethereum mainnet, la token pool de LINK está configurada para quemar los tokens en la blockchain de origen (no emisora en este flujo de LINK) y desbloquearlos en Ethereum mainnet (emisora). Por ejemplo, transferir 10 LINK de Ethereum mainnet a Base mainnet implica que la token pool de LINK bloquee 10 LINK en Ethereum mainnet y mintee 10 LINK en Base mainnet. A la inversa, transferir 10 LINK de Base mainnet a Ethereum mainnet implica que la token pool de LINK queme 10 LINK en Base mainnet y desbloquee 10 LINK en Ethereum** mainnet.

• Los activos nativos "wrappeados" -la traducción es envueltos pero no me gusta- (Por ejemplo,WETHo cualquier**Wrapped Token) utilizan un mecanismo de bloqueo y desbloqueo (lock/unlock). Por ejemplo, al transferir 10 WETH de Ethereum mainnet a Optimism mainnet, la token pool WETH bloqueará 10 WETH en Ethereum mainnet y desbloqueará 10 WETH en Optimism mainnet. A la inversa, al transferir de Optimism mainnet a Ethereum mainnet, la token pool de WETH bloqueará 10 WETH en Optimism mainnet y desbloqueará 10 WETH en Ethereum mainnet.

• Las stable coins (por ejemplo, USDC) pueden mintearse de forma nativa nativa en varias blockchains. Sus respectivas token pool emplean un mecanismo de "Burn and Mint" (quema/acuñación), quemando el token en la blockchain de origen y minteándolo después de forma nativa en la blockchain de destino.

• Los tokens con una Proof of Reserve (PoR) con una alimentación PoR en una blockchain específica presentan un desafío para el mecanismo "Burn and Mint" cuando se aplica a través de otras blockchains debido a conflictos con la alimentación PoR. Para este tipo de tokens, se prefiere el enfoque "Lock and Mint".

Componentes Offchain

Committing DON

La Committing DON tiene varias tareas, cada una de las cuales supervisa las transacciones entre blockchains de origen y destino:

• Cada job monitorea los eventos de un contrato OnRamp determinado en la blockchain de origen.

• El job espera la finalidad, que depende de la blockchain de origen.

• El job agrupa las transacciones y crea una Merkle root. Esta raíz de Merkle es firmada por un quórum de nodos de oráculos que forman parte de la Committing DON.

• Por último, la tarea escribe la Merkle root en el contrato CommitStore de la blockchain de destino.

Executing DON

Al igual que la Committing DON, la Executing DON tiene varios jobs, cada uno de los cuales ejecuta transacciones cross-chain entre una blockchain de origen y una de destino:

• Cada job monitorea los eventos de un contrato OnRamp determinado en la blockchain de origen.

• El job comprueba si la transacción forma parte de la Merkle root retransmitida en el contrato CommitStore.

• El job espera a que la ARM bendiga (blesses) el mensaje.

• Por último, el job crea una Merkle proof (prueba de merkle) válida, que el contrato OffRamp verifica comparándola con la raíz de Merkle (Merkle root) del contrato CommitStore. Una vez superadas estas comproibaciones, la tarea llama al contrato OffRamp para completar las transacciones CCIP en la blockchain de destino.

¿Los beneficios de estos componentes OffChain?

Separar el Committing y Execution permite a la Red de Gestión de Riesgos disponer de tiempo suficiente para comprobar el Committing de los mensajes antes de ejecutarlos. El retraso entre el compromiso (Commitment) y la ejecución (Execution) también permite realizar comprobaciones adicionales, como la profundidad de reorganización anormal, la simulación potencial y el recorte (slashing).

Guardar un Commitment (compromiso) es compacto y tiene un coste fijo de gas, mientras que la ejecución de las llamadas de retorno del usuario puede consumir mucho gas. Separar el Commitment (compromiso) y le ejecución (Execution) permite la ejecución por parte de los usuarios finales en varios casos, como el de ejecuciones fallidas, que podemos volver a ejecutarlas a través del explorador de transacciones CCIP.

Palabras Finales

Es bastante información la que podemos ver, pero es para aquellos que desean ir un poco más allá y comprender todo lo que está involucrado no solo en CCIP, si no también al momento de plantearse alguna solución cross-chain. Me parece que es necesario que tengan estos conceptos en mente. Si en tu trabajo se están planteando este escenario ahora tiene argumentos respecto a que plantearse y qué no, en qué escenarios visualizarse, etc.

Cualquier duda puedes contactarme, estudia estos conocimientos que ya viene un video donde utilizaremos Chainlink CCIP.