Chainlink a publié CCIP 2.0 le 28 septembre, une version de son protocole inter-chaînes qui permet aux émetteurs de jetons ou à des tiers d'exécuter des vérificateurs inter-chaînes optionnels, ou CCV, et de les exiger avant qu'un transfert puisse être finalisé. Ce changement signifie qu'un vérificateur requis qui tombe en panne peut geler tous les messages qui dépendent de son attestation. Un transfert peut être bloqué avec les jetons de la chaîne source déjà verrouillés ou brûlés et aucune libération ou émission correspondante sur la chaîne de destination.
Où le transfert s'arrête
Dans CCIP 2.0, la séquence de transfert sépare la vérification de l'exécution. L'OnRamp assemble les exigences de vérificateur pour un message. Le pool de jetons verrouille ou brûle ensuite les jetons source. Les services de vérificateur hors chaîne publient des attestations liées à l'ID du message. L'OffRamp vérifie ces attestations requises avant de libérer ou d'émettre sur la chaîne de destination. Chainlink déclare que tous les CCV requis doivent renvoyer des résultats valides avant que l'exécution ne se poursuive. Si un vérificateur requis n'atteste pas, le message de destination peut rester inchangé.
Cet ordre est important car le verrouillage ou la combustion côté source se produit avant que la vérification ne soit terminée. Un transfert bloqué n'est pas une transaction en attente au sens habituel ; c'est un état où le pool source a déplacé les jetons mais la chaîne de destination n'a aucune preuve pour agir. Chainlink attribue aux opérateurs CCV externes la responsabilité de la mise en œuvre, de la maintenance et de la disponibilité, de sorte que la fiabilité d'un vérificateur requis repose sur celui qui l'exécute. Le vérificateur de comité par défaut comprend 16 opérateurs de nœuds indépendants, avec tout CCV supplémentaire à côté de cette base.
Émetteurs et tiers comme dépendances
Si un émetteur exécute un CCV requis pour son propre pool de jetons, le service de cet émetteur devient l'une des parties capables de retarder l'achèvement. Un opérateur tiers créerait une dépendance similaire. Chainlink a averti qu'un vérificateur non réactif peut bloquer tous les messages nécessitant son attestation — pas seulement un transfert. Le matériel de lancement de l'entreprise n'identifie pas d'actif de production nommé ou de voie utilisant un CCV requis géré par l'émetteur, donc le mécanisme en soi n'est pas la preuve qu'un transfert d'un détenteur spécifique a été bloqué.
L'exécution sur la chaîne de destination est sans permission une fois que toutes les preuves requises existent et que tout quorum de vérificateur optionnel est atteint. L'exécuteur par défaut soumet normalement la transaction, mais n'importe qui peut la soumettre via le chemin d'exécution manuel. Payer le gaz de la chaîne de destination ou changer l'exécuteur ne renonce pas à une attestation CCV requise manquante ; l'OffRamp vérifie toujours les preuves avant de libérer ou d'émettre des jetons.
Gestion des échecs et nouvelles tentatives
Lorsqu'une tentative de destination échoue dans le chemin protégé de l'OffRamp, elle peut être marquée FAILURE et réessayée après la correction du problème sous-jacent. L'exécuteur par défaut de Chainlink réessaie les échecs dans une fenêtre configurée actuellement fixée à huit heures. La route d'exécution manuelle publiée ne spécifie pas d'annulation automatique générale, de remboursement ou de retour des jetons de la chaîne source lorsqu'un vérificateur requis n'atteste jamais. Tout recours spécifique à l'émetteur dépendrait des arrangements de cet actif.
Deux hooks offrent une intervention plus précoce. Sur les chaînes EVM, un hook configuré du Chainlink Automated Compliance Engine peut rejeter un transfert sortant avant que le pool source ne verrouille ou ne brûle quoi que ce soit, ce qui annule la transaction source. Un hook postflight de destination configuré séparément peut rejeter la libération ou l'émission après que le transfert côté source a commencé, laissant les jetons non livrés jusqu'à ce que la condition de politique soit remplie. Les deux sont des choix de configuration, pas des paramètres par défaut.
Ce que les constructeurs et les détenteurs peuvent vérifier
La question pratique pour quiconque déplace un jeton via CCIP 2.0 est de savoir quels vérificateurs une voie donnée exige et qui les exploite. Un CCV requis géré par l'émetteur place cet émetteur dans le chemin de chaque transfert pour ce pool. Un CCV tiers ajoute un autre opérateur avec son propre historique de disponibilité. Le vérificateur de comité par défaut à 16 opérateurs est la base, mais des CCV supplémentaires modifient l'ensemble des dépendances.
Chainlink n'a pas nommé d'actif de production ou de voie qui repose sur un CCV requis géré par l'émetteur. Jusqu'à ce qu'un apparaisse, le scénario de blocage est une propriété documentée de la conception plutôt qu'un incident réel. Les constructeurs évaluant la mise à niveau voudront savoir ce qui se passe lorsqu'un vérificateur requis est lent ou silencieux sur leur voie spécifique — et si l'émetteur derrière lui a publié un recours pour les jetons déjà verrouillés sur la chaîne source.
