Chainlink ha lanzado la versión 2.0 de su Protocolo de Interoperabilidad entre Cadenas (CCIP), que incorpora Verificadores entre Cadenas, nuevas funciones de token pool y ajustes de finalidad configurables, según las notas de la versión del proyecto. Una descripción general de seguridad complementaria explica la arquitectura más amplia en la que encajan esas funciones. CCIP, que transmite mensajes y tokens entre blockchains que no pueden leer de forma nativa el estado de las demás, amplía el trabajo de un proyecto conocido principalmente por su infraestructura de oráculos en las finanzas descentralizadas.

En conjunto, los cambios permiten a los emisores de tokens exigir verificaciones adicionales antes de aprobar una transferencia entre cadenas y posibilitan que diferentes activos operen bajo distintos ajustes de seguridad y finalidad. La verificación personalizada traslada más responsabilidad al emisor, las rutas más rápidas pueden depender de supuestos diferentes sobre la finalidad, y los usuarios deben evaluar la ruta específica del token en lugar de limitarse a la marca del bridge.

Qué cambió

Piense en una transferencia mediante bridge como una puerta entre dos blockchains. Antes de que la puerta se abra, alguien debe confirmar que el activo fue bloqueado o destruido del otro lado. CCIP 2.0 permite al emisor del token decidir qué verificaciones adicionales deben aprobar esa afirmación. Una stablecoin, un fondo tokenizado y un token criptonativo podrían, por lo tanto, seguir reglas distintas antes de liberar una versión entre cadenas.

Las transferencias entre cadenas dependen de una decisión que debe ser confiable

Una transferencia entre cadenas suele implicar más que mover un token de una dirección a otra. Un activo puede quedar bloqueado en una red, o retirado de la circulación allí, antes de que una versión correspondiente esté disponible en otra cadena. La parte es confirmar que el primer evento realmente ocurrió y que la cadena de destino debe actuar en consecuencia.

Un fallo en ese proceso de decisión puede crear problemas serios: una transferencia válida de un usuario puede retrasarse, o un mensaje no válido podría provocar que se liberen tokens cuando no deberían hacerlo.

CCIP ya proporciona un sistema para transmitir mensajes entre cadenas y verificarlos. La versión 2.0 añade una forma de que los token pools exijan una verificación adicional antes de completar una transferencia. Eso da a los emisores más flexibilidad, pero también hace que la configuración alrededor de una ruta de token sea más importante.

Los emisores pueden añadir sus propias reglas de verificación

CCIP 2.0 introduce los Cross-Chain Verifiers, o CCV: componentes de verificación adicionales que pueden usarse junto con el proceso de seguridad existente de CCIP. En particular, un proyecto no necesita la aprobación de Chainlink antes de desarrollar o usar un verificador adicional. Esa apertura da a los emisores más margen para dar forma a una ruta según sus propios requisitos, al tiempo que les coloca más responsabilidad para evaluar el verificador que elijan.

Un token pool puede especificar qué CCV deben aprobar una transferencia. Un emisor puede querer una prueba adicional de que un activo fue bloqueado en la cadena de origen. Otro podría exigir una condición relacionada con el cumplimiento o una confirmación independiente de un sistema separado. Ese verificador puede publicar evidencias de varias maneras, desde datos firmados y API hasta pruebas criptográficas.

El punto importante para los usuarios es que CCIP no decide qué evidencia debe confiar una ruta de token específica. La diferencia es práctica: una versión entre cadenas de un token puede ya no seguir exactamente el mismo proceso de aprobación que otro activo que usa CCIP, y el modelo de seguridad de la ruta puede depender de las decisiones del propio emisor.

La ejecución más rápida es opcional

La actualización también incluye ajustes de finalidad configurables, entre ellos una función opcional llamada Faster Than Finality. Las blockchains no alcanzan la finalidad todas de la misma manera. Algunas transacciones pueden parecer confirmadas antes de que la red haya llegado al punto en el que reorganizarlas sea muy improbable. Esperar más tiempo puede mejorar la certeza, pero también puede hacer más lenta una transferencia entre cadenas.

CCIP 2.0 da a las partes participantes de una ruta la opción de usar un punto de confirmación más temprano. Las notas de la versión aclaran que este ajuste debe estar soportado por todos los componentes relevantes: emisor, pool, verificador, ejecutor y receptor. Una ruta más rápida puede, por lo tanto, conllevar supuestos operativos distintos a los de una que espera a que la transacción de la cadena de origen alcance su umbral habitual de finalidad. Si esos componentes se configuran de manera inconsistente, las notas de la versión advierten que un mensaje y su contenido de tokens podrían quedar atascados.

Más verificaciones solo ayudan cuando no comparten la misma debilidad

Añadir verificadores no hace que una ruta de bridge sea automáticamente más segura. Los exploits de bridges figuran repetidamente entre las categorías de incidentes más costosas en cripto, y los análisis de fallos importantes frecuentemente se han centrado en cómo se verificaban las transferencias, no en las cadenas mismas. La calidad del arreglo depende de qué verifica cada control y de si los sistemas detrás de esas verificaciones son genuinamente independientes. Por ejemplo, dos verificadores pueden parecer separados mientras dependen de la misma fuente de datos, operador o servicio fuera de la cadena. Si esa dependencia compartida falla, ambas verificaciones pueden llegar a la misma conclusión errónea.

Lo que importa es si cada verificación puede fallar por una razón diferente. Por eso la versión otorga a los emisores flexibilidad en lugar de una garantía universal de seguridad. Una ruta bien diseñada puede añadir controles independientes útiles, mientras que una mal diseñada puede añadir complejidad sin reducir el riesgo central.

CCIP 2.0 proporciona el marco para esas verificaciones. El emisor todavía tiene que decidir cuáles son las reglas, cómo funciona su código y quién puede modificarlas más adelante.

Por qué los controles a nivel del emisor importan más allá de DeFi

Las mismas decisiones de diseño cobran más peso cuando un token representa algo más que una posición ordinaria de DeFi. Un emisor de stablecoin puede necesitar condiciones diferentes a las de un protocolo que transfiere un token de gobernanza criptonativo. Un fondo tokenizado podría requerir restricciones de transferencia, verificaciones de identidad o la aprobación del emisor en ciertas circunstancias. Las instituciones también pueden preferir sistemas que faciliten definir y auditar las reglas en torno a un activo entre cadenas.

Como señaló un análisis previo de Coindoo sobre pruebas de bancos centrales con Chainlink, la infraestructura entre cadenas se está explorando tanto para flujos financieros tokenizados como para transferencias criptonativas.

CCIP 2.0 no demuestra que alguna institución en particular ya haya adoptado un verificador personalizado. Da a un emisor la opción técnica de imponer condiciones adicionales en torno a su propia ruta entre cadenas. Eso podría hacer que el protocolo sea más útil para activos que no pueden basarse en un único conjunto de reglas idéntico. También significa que los usuarios pueden enfrentar restricciones y riesgos distintos según el token que posean.

Qué deben comprobar los usuarios antes de usar una ruta entre cadenas

La actualización hace más juzgar una transferencia solo preguntando si usa un proveedor de bridge conocido. Antes de mover un token entre cadenas, los usuarios pueden querer comprobar:

• Quién controla el token pool: el emisor, un equipo de protocolo o un sistema de gobernanza separado.
• Si la ruta usa verificadores adicionales y en qué evidencia se basan esos verificadores.
• Si la finalidad rápida está activada, ya que una espera más corta puede conllevar supuestos operativos distintos.
• Quién puede cambiar la configuración, incluidos los requisitos de verificación, los derechos de pausa y la autoridad de actualización.
• Si el token de destino tiene los mismos derechos de canje y transferencia que la versión mantenida en la cadena de origen.

Estas preguntas no significan que toda ruta personalizada sea insegura. Ayudan a explicar por qué la palabra "bridged" puede describir sistemas muy diferentes.

Un proveedor de bridge es solo parte de la configuración de seguridad

CCIP 2.0 refleja un cambio más amplio en el diseño entre cadenas. La infraestructura de bridges va dejando de ser la aplicación de un proceso fijo para cada token y pasa a ser más una herramienta que da a los emisores la capacidad de definir cómo viajan sus activos entre redes. Eso puede ser útil cuando diferentes activos conllevan requisitos legales, técnicos u operativos distintos. La contrapartida es que los usuarios necesitan información más clara sobre las reglas asociadas a la ruta que están usando.

La importancia de la actualización se verá en cómo se configuran realmente las rutas —qué emisores añaden verificadores personalizados y cuántos activan la finalidad rápida—, ya que esas decisiones se toman por token y no por Chainlink para el protocolo en su conjunto.

Para los usuarios, el cambio práctico es simple: el proveedor del bridge es solo una parte del panorama de seguridad, y las reglas de aprobación que rigen la ruta específica del token merecen el mismo escrutinio.

Este artículo se proporciona únicamente con fines informativos y no constituye asesoramiento financiero ni de inversión. Las transferencias entre cadenas implican riesgos de contratos inteligentes, operativos y de liquidez.

Publicado originalmente por Coindoo.