Chainlink lanzó CCIP 2.0 el 28 de septiembre, una versión de su protocolo entre cadenas que permite a los emisores de tokens o a terceros ejecutar verificadores entre cadenas opcionales, o CCV, y exigirlos antes de que se complete una transferencia. El cambio significa que un verificador requerido que se desconecta puede congelar todos los mensajes que dependen de su atestación. Una transferencia puede atascarse con los tokens de la cadena de origen ya bloqueados o quemados y sin la liberación o acuñación correspondiente en la cadena de destino.
Dónde se detiene la transferencia
En CCIP 2.0, la secuencia de transferencia separa la verificación de la ejecución. El OnRamp ensambla los requisitos del verificador para un mensaje. Luego, el pool de tokens bloquea o quema los tokens de origen. Los servicios de verificación fuera de cadena publican atestaciones vinculadas al ID del mensaje. El OffRamp verifica esas atestaciones requeridas antes de liberar o acuñar en la cadena de destino. Chainlink afirma que todos los CCV requeridos deben devolver resultados válidos antes de que la ejecución continúe. Si un verificador requerido no atestigua, el mensaje de destino puede permanecer intacto.
Ese orden es importante porque el bloqueo o quema en el lado de origen ocurre antes de que se complete la verificación. Una transferencia atascada no es una transacción pendiente en el sentido habitual; es un estado en el que el pool de origen ha movido los tokens pero la cadena de destino no tiene prueba para actuar. Chainlink asigna a los operadores de CCV externos la responsabilidad de la implementación, el mantenimiento y el tiempo de actividad, por lo que la confiabilidad de un verificador requerido recae en quien lo ejecuta. El verificador de comité predeterminado comprende 16 operadores de nodos independientes, con cualquier CCV adicional situado junto a esa base.
Emisores y terceros como dependencias
Si un emisor ejecuta un CCV requerido para su propio pool de tokens, el servicio de ese emisor se convierte en una de las partes capaces de retrasar la finalización. Un operador externo crearía una dependencia similar. Chainlink ha advertido que un verificador que no responde puede atascar todos los mensajes que requieren su atestación, no solo una transferencia. El material de lanzamiento de la compañía no identifica un activo de producción nombrado ni un carril que utilice un CCV requerido ejecutado por el emisor, por lo que el mecanismo por sí solo no es evidencia de que la transferencia de un titular específico haya sido bloqueada.
La ejecución en la cadena de destino no requiere permiso una vez que existe cada prueba requerida y se cumple cualquier quórum de verificador opcional. El ejecutor predeterminado normalmente envía la transacción, pero cualquiera puede enviarla a través de la ruta de ejecución manual. Pagar el gas de la cadena de destino o cambiar el ejecutor no exime de una atestación CCV requerida faltante; el OffRamp aún verifica las pruebas antes de liberar o acuñar tokens.
Manejo de fallos y reintentos
Cuando un intento de destino falla dentro de la ruta protegida del OffRamp, se puede marcar como FAILURE y reintentar después de que se solucione el problema subyacente. El ejecutor predeterminado de Chainlink reintenta fallos dentro de una ventana configurada actualmente establecida en ocho horas. La ruta de ejecución manual publicada no especifica una cancelación automática general, reembolso o devolución de tokens de la cadena de origen cuando un verificador requerido nunca atestigua. Cualquier remedio específico del emisor dependería de los acuerdos de ese activo.
Dos hooks ofrecen intervención anticipada. En cadenas EVM, un hook configurado del Motor de Cumplimiento Automatizado de Chainlink puede rechazar una transferencia saliente antes de que el pool de origen bloquee o queme algo, lo que revierte la transacción de origen. Un hook posterior al vuelo de destino configurado por separado puede rechazar la liberación o acuñación después de que haya comenzado la transferencia del lado de origen, dejando los tokens sin entregar hasta que se cumpla la condición de la política. Ambos son opciones de configuración, no valores predeterminados.
Qué pueden verificar los desarrolladores y los tenedores
La pregunta práctica para cualquiera que mueva un token a través de CCIP 2.0 es qué verificadores requiere un carril dado y quién los opera. Un CCV requerido ejecutado por el emisor pone a ese emisor en la ruta de cada transferencia para ese pool. Un CCV de terceros añade otro operador con su propio historial de actividad. El verificador de comité predeterminado de 16 operadores es la base, pero los CCV adicionales cambian el conjunto de dependencias.
Chainlink no ha nombrado un activo de producción ni un carril que dependa de un CCV requerido ejecutado por el emisor. Hasta que aparezca uno, el escenario de bloqueo es una propiedad documentada del diseño en lugar de un incidente en vivo. Los desarrolladores que evalúan la actualización querrán saber qué sucede cuando un verificador requerido es lento o silencioso en su carril específico, y si el emisor detrás de él ha publicado un remedio para los tokens ya bloqueados en la cadena de origen.
