Chainlink CCIP 2.0 peut bloquer les transferts soumis aux contrôles obligatoires des émetteurs

Chainlink CCIP 2.0 permet à un émetteur de jetons d’exiger un vérificateur supplémentaire avant le transfert des jetons d’une blockchain à une autre. La fonctionnalité a été annoncée le 28 septembre. Elle ajoute des vérificateurs inter-chaînes (Cross-Chain Verifiers) facultatifs au vérificateur de comité (Committee Verifier) par défaut de CCIP. Un émetteur ou un tiers peut exploiter un vérificateur et faire de son approbation une condition du transfert. Le pool source peut verrouiller ou brûler les jetons avant que le vérificateur obligatoire ne fournisse son attestation. La chaîne de destination ne peut ni débloquer ni créer les jetons sans l’attestation requise. Les documents de lancement de Chainlink ne mentionnent aucun actif et itinéraire de production utilisant un vérificateur obligatoire exploité par un émetteur. La fonctionnalité ne permet donc pas d’établir qu’un émetteur a bloqué le transfert d’un détenteur. L’OnRamp de CCIP rassemble les exigences relatives aux vérificateurs pour un transfert. L’OnRamp enregistre le message à l’intention des services de vérification hors chaîne après que le pool source a verrouillé ou brûlé les jetons. Ces services surveillent l’événement sur la chaîne source et appliquent leurs règles de finalité et de vérification. Ils publient des attestations liées à l’identifiant du message. L’OffRamp de CCIP vérifie les attestations obligatoires avant que le pool de destination ne débloque ou ne crée les jetons. Ces vérifications s’appuient sur les paramètres de la voie et du pool de jetons. Un contrat de réception peut également imposer des exigences en matière de vérificateurs. Les préférences de l’expéditeur peuvent s’ajouter à l’ensemble des vérificateurs côté source. Un transfert de jetons seul ne comporte aucun rappel du contrat de réception avec des préférences de vérificateurs à vérifier. Chainlink indique que tous les vérificateurs inter-chaînes (CCV) obligatoires doivent renvoyer des résultats valides avant que l’exécution puisse se poursuivre. Son modèle de confiance avertit qu’un vérificateur qui ne répond pas peut bloquer chaque message nécessitant son attestation. Un émetteur qui exploite un vérificateur et le rend obligatoire pour son pool de jetons peut retarder l’exécution. Un opérateur tiers peut créer une dépendance similaire qu’il contrôle. Chainlink indique que son vérificateur de comité par défaut se compose de 16 opérateurs de nœuds indépendants. Les CCV supplémentaires fonctionnent en complément de cette configuration de base. Chainlink attribue aux opérateurs externes de CCV la responsabilité de la mise en œuvre, de la maintenance et du temps de disponibilité. L’exécution sur la chaîne de destination est sans permission dès lors que toutes les preuves requises existent et que tout quorum facultatif de vérificateurs est atteint. L’exécuteur par défaut de Chainlink soumet normalement la transaction. N’importe qui peut la soumettre par la procédure d’exécution manuelle. Changer d’exécuteur ou payer les frais de gaz de la chaîne de destination ne dispense pas de fournir une attestation obligatoire manquante. L’OffRamp vérifie toujours les preuves avant de débloquer ou de créer les jetons. Un message de destination peut rester à l’état UNTOUCHED si l’attestation obligatoire n’a pas été rassemblée. UNTOUCHED signifie qu’aucune exécution n’a été enregistrée. Une tentative soumise sur la chaîne de destination qui échoue dans le parcours protégé de l’OffRamp peut être marquée FAILURE. Chainlink indique qu’une tentative échouée peut être relancée une fois le problème sous-jacent résolu. Son exécuteur par défaut relance les échecs dans une fenêtre configurée actuellement fixée à huit heures. Cette limite s’applique au service automatisé. Le guide d’exécution manuelle explique comment vérifier l’état des vérificateurs et de l’exécution. Il décrit notamment les cas où l’indexeur n’a pas recueilli le résultat d’un vérificateur externe. La procédure d’exécution manuelle publiée par Chainlink ne précise pas de mécanisme général d’annulation, de remboursement ou de restitution automatique des jetons sur la chaîne source si un vérificateur obligatoire ne fournit jamais son attestation. Tout recours propre à un émetteur dépend des dispositions prévues pour l’actif. Sur les chaînes EVM, un module de conformité Chainlink (Automated Compliance Engine, ACE) configuré peut rejeter un transfert sortant avant que le pool source ne verrouille ou ne brûle les jetons. Cet échec préalable fait échouer et annule la transaction source. Un module de vérification a posteriori distinct, configuré sur la chaîne de destination, peut rejeter le déblocage ou la création des jetons après le début du transfert côté source. Les jetons restent alors non livrés jusqu’à ce que la condition de la politique soit remplie et que l’exécution soit relancée. Le guide d’intégration ACE de Chainlink décrit ces paramètres comme des configurations distinctes et facultatives. Le répertoire mainnet de Chainlink répertorie les réseaux et les jetons pris en charge. Une inscription ne montre pas si un itinéraire de production exige un vérificateur exploité par un émetteur ou si un contrôle ACE a été activé sur la chaîne de destination. Une annonce d’un partenaire ou une migration antérieure d’actif ne permet pas d’établir ces paramètres. La publication propose également des transferts plus rapides que la finalité complète de la chaîne source. La finalité complète de la chaîne source reste l’option par défaut. Le guide FTF de Chainlink indique que l’option accélérée peut exposer un transfert à une double exécution sur la chaîne de destination après une réorganisation suffisamment profonde. D’autres CCV obligatoires peuvent appliquer leurs propres règles en matière de réorganisation. L’option de transfert accéléré ne supprime pas l’obligation de fournir les attestations requises.