Chainlink a publié la version 2.0 de son Cross-Chain Interoperability Protocol (CCIP), introduisant des Cross-Chain Verifiers, de nouvelles fonctions de token pool et des paramètres de finalité configurables, selon les notes de version du projet. Une présentation de la sécurité associée explique l'architecture plus large dans laquelle ces fonctionnalités s'inscrivent. CCIP, qui transmet des messages et des jetons entre des blockchains ne pouvant pas lire nativement l'état des autres, prolonge le travail d'un projet connu avant tout pour son infrastructure d'oracles dans la finance décentralisée.

Prises ensemble, ces modifications permettent aux émetteurs de jetons d'exiger des vérifications supplémentaires avant l'approbation d'un transfert inter-chaînes et permettent à différents actifs de fonctionner avec des paramètres de sécurité et de finalité différents. La vérification personnalisée transfère davantage de responsabilité à l'émetteur, les routes plus rapides peuvent reposer sur des hypothèses différentes concernant la finalité, et les utilisateurs doivent évaluer la route de jeton spécifique plutôt que la seule marque du pont.

Ce qui a changé

Imaginez un transfert par pont comme une porte entre deux blockchains. Avant que la porte ne s'ouvre, quelqu'un doit confirmer que l'actif a été verrouillé ou détruit de l'autre côté. CCIP 2.0 permet à l'émetteur du jeton de décider quelles vérifications supplémentaires doivent approuver cette affirmation. Un stablecoin, un fonds tokenisé et un jeton crypto-native pourraient donc chacun suivre des règles différentes avant la publication d'une version inter-chaînes.

Les transferts inter-chaînes reposent sur une décision qui doit être fiable

Un transfert inter-chaînes implique généralement plus que le déplacement d'un jeton d'une adresse à une autre. Un actif peut être verrouillé dans un réseau, ou retiré de la circulation à cet endroit, avant qu'une version correspondante ne devienne disponible sur une autre chaîne. La partie difficile consiste à confirmer que le premier événement s'est réellement produit et que la chaîne de destination doit agir en conséquence.

Un échec dans ce processus de décision peut créer de sérieux problèmes : un transfert utilisateur valide peut être retardé, ou un message invalide pourrait entraîner la libération de jetons qui n'auraient pas dû l'être.

CCIP fournit déjà un système de transmission et de vérification des messages inter-chaînes. La version 2.0 ajoute un moyen pour les token pools d'exiger une vérification supplémentaire avant de finaliser un transfert. Cela donne aux émetteurs plus de flexibilité, mais rend également la configuration d'une route de jeton plus importante.

Les émetteurs peuvent ajouter leurs propres règles de vérification

CCIP 2.0 introduit les Cross-Chain Verifiers, ou CCV — des composants de vérification supplémentaires pouvant être utilisés aux côtés du processus de sécurité existant de CCIP. Fait notable, un projet n'a pas besoin de l'approbation de Chainlink pour développer ou utiliser un vérificateur supplémentaire. Cette ouverture donne aux émetteurs plus de latitude pour façonner une route selon leurs propres exigences, tout en plaçant sur eux plus de responsabilité quant à l'évaluation du vérificateur qu'ils choisissent.

Un token pool peut spécifier quels CCV doivent approuver un transfert. Un émetteur peut vouloir une preuve supplémentaire qu'un actif a été verrouillé sur la chaîne d'origine. Un autre pourrait exiger une condition liée à la conformité ou une confirmation indépendante d'un système distinct. Un tel vérificateur peut publier des preuves de plusieurs manières, des données signées et API aux preuves cryptographiques.

Le point important pour les utilisateurs est que CCIP ne décide pas des preuves auxquelles une route de jeton spécifique doit faire confiance. La différence est concrète : une version inter-chaînes d'un jeton peut ne plus suivre exactement le même processus d'approbation qu'un autre actif utilisant CCIP, et le modèle de sécurité de la route peut dépendre des choix propres à l'émetteur.

Une exécution plus rapide est optionnelle

La mise à jour comprend également des paramètres de finalité configurables, dont une fonctionnalité optionnelle appelée Faster Than Finality. Les blockchains n'atteignent pas toutes la finalité de la même manière. Certaines transactions peuvent sembler confirmées avant que le réseau n'ait atteint le point où leur réorganisation devient hautement improbable. Attendre plus longtemps peut améliorer la certitude, mais peut aussi rendre un transfert inter-chaînes plus lent.

CCIP 2.0 donne aux parties participantes d'une route la possibilité d'utiliser un point de confirmation plus précoce. Les notes de version précisent que ce paramètre doit être pris en charge par l'ensemble des composants concernés : expéditeur, pool, vérificateur, exécuteur et récepteur. Une route plus rapide peut donc comporter des hypothèses opérationnelles différentes de celle qui attend que la transaction de la chaîne source atteigne son seuil de finalité habituel. Si ces composants sont configurés de manière incohérente, les notes de version avertissent qu'un message et son contenu en jetons pourraient rester bloqués.

Des vérifications supplémentaires n'aident que si elles ne partagent pas la même faiblesse

Ajouter des vérificateurs ne rend pas automatiquement une route de pont plus sûre. Les piratages de ponts ont régulièrement figuré parmi les catégories d'incidents les plus coûteuses en crypto, et les analyses des échecs majeurs ont fréquemment porté sur la manière dont les transferts étaient vérifiés plutôt que sur les chaînes elles-mêmes. La qualité de l'arrangement dépend de ce que chaque vérification contrôle et de l'indépendance réelle des systèmes derrière ces vérifications. Par exemple, deux vérificateurs peuvent sembler distincts tout en s'appuyant sur la même source de données, le même opérateur ou le même service hors chaîne. Si cette dépendance commune échoue, les deux vérifications peuvent aboutir à la même conclusion erronée.

Ce qui compte, c'est de savoir si chaque vérification peut échouer pour une raison différente. C'est pourquoi cette version accorde aux émetteurs de la flexibilité plutôt qu'une garantie universelle de sécurité. Une route soigneusement conçue peut ajouter des contrôles indépendants utiles, tandis qu'une route mal conçue peut ajouter de la complexité sans réduire le risque fondamental.

CCIP 2.0 fournit le cadre de ces vérifications. L'émetteur doit toujours décider quelles sont les règles, comment leur code fonctionne et qui peut les modifier ultérieurement.

Pourquoi les contrôles au niveau de l'émetteur comptent au-delà de la DeFi

Les mêmes choix de conception prennent plus d'importance lorsqu'un jeton représente quelque chose au-delà d'une simple position DeFi. Un émetteur de stablecoin peut nécessiter des conditions différentes de celles d'un protocole transférant un jeton de gouvernance crypto-native. Un fonds tokenisé pourrait exiger des restrictions de transfert, des vérifications d'identité ou l'approbation de l'émetteur dans certaines circonstances. Les institutions peuvent également préférer des systèmes rendant les règles entourant un actif inter-chaînes plus faciles à définir et à auditer.

Comme l'a noté une analyse précédente de Coindoo sur des tests de banques centrales impliquant Chainlink, l'infrastructure inter-chaînes est explorée pour les flux financiers tokenisés aussi bien que pour les transferts crypto-natifs.

CCIP 2.0 ne démontre pas qu'une institution particulière a déjà adopté un vérificateur personnalisé. Il offre à un émetteur l'option technique de placer des conditions supplémentaires autour de sa propre route inter-chaînes. Cela pourrait rendre le protocole plus utile pour les actifs ne pouvant pas s'appuyer sur un ensemble de règles unique et identique. Cela signifie également que les utilisateurs peuvent faire face à des restrictions et des risques différents selon le jeton qu'ils détiennent.

Ce que les utilisateurs devraient vérifier avant d'utiliser une route inter-chaînes

Cette mise à jour rend plus difficile le jugement d'un transfert en se demandant simplement s'il utilise un fournisseur de pont connu. Avant de déplacer un jeton entre des chaînes, les utilisateurs peuvent souhaiter vérifier :

• Qui contrôle le token pool : l'émetteur, une équipe de protocole ou un système de gouvernance distinct.
• Si la route utilise des vérificateurs supplémentaires, et sur quelles preuves ces vérificateurs s'appuient.
• Si la finalité accélérée est activée, car une attente plus courte peut s'accompagner d'hypothèses opérationnelles différentes.
• Qui peut modifier la configuration, y compris les exigences de vérification, les droits de pause et l'autorité de mise à niveau.
• Si le jeton de destination offre les mêmes droits de rachat et de transfert que la version détenue sur la chaîne d'origine.

Ces questions ne signifient pas que chaque route personnalisée est dangereuse. Elles aident à expliquer pourquoi le mot « bridged » peut désigner des systèmes très différents.

Un fournisseur de pont n'est qu'une partie du dispositif de sécurité

CCIP 2.0 reflète une évolution plus large de la conception inter-chaînes. L'infrastructure de ponts devient moins une question d'application d'un processus fixe à chaque jeton que celle de fournir aux émetteurs des outils pour défin comment leurs actifs circulent entre les réseaux. Cela peut être utile lorsque différents actifs ont des exigences juridiques, techniques ou opérationnelles différentes. Le compromis est que les utilisateurs ont besoin d'informations plus claires sur les règles attachées à la route qu'ils utilisent.

La portée de cette mise à niveau se révélera dans la manière dont les routes sont réellement configurées — quels émetteurs ajoutent des vérificateurs personnalisés, et combien activent une finalité plus rapide — car ces choix se font par jeton plutôt que par Chainlink pour le protocole dans son ensemble.

Pour les utilisateurs, le changement concret est simple : le fournisseur de pont n'est qu'une partie du tableau de sécurité, et les règles d'approbation régissant la route de jeton spécifique méritent le même examen attentif.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d'investissement. Les transferts inter-chaînes comportent des risques liés aux contrats intelligents, aux opérations et à la liquidité.

Publié à l'origine par Coindoo.