Aperçu par couches de la technologie de pont cross-chain : quelles possibilités restent à explorer ?
TechFlow SélectionTechFlow Sélection
Aperçu par couches de la technologie de pont cross-chain : quelles possibilités restent à explorer ?
La technologie de pont inter-chaînes semble être une technologie constamment controversée, mais qui est régulièrement évoquée.
Dédié à des analyses Web3 approfondiesRédaction : Jeffrey Hu, HashKey Capital
La technologie de pont inter-chaînes (cross-chain) semble toujours être un sujet controversé, tout en étant régulièrement évoqué. Chaque fois qu’un pont inter-chaînes est piraté, les débats sur cette technologie reprennent de plus belle. D’un autre côté, avec la maturité croissante de technologies comme IBC ou LayerZero, la communauté semble limiter ses attentes concernant l’avenir du cross-chain.
Est-ce donc là le point final pour le cross-chain ? Eh bien,
This is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.
Le domaine du cross-chain a connu plusieurs avancées notables au cours des derniers mois de 2022. Profitant d'invitations récentes à donner des présentations sur ce thème, j'ai souhaité consigner ici mes observations et réflexions concernant les évolutions technologiques dans ce secteur.
I. Aperçu par couches de la technologie cross-chain
1. Comprendre le cross-chain via une approche par couches
Avant d’aborder ces progrès, il est utile de rappeler précisément quel est le problème traité par le cross-chain : quand nous parlons de cross-chain, quelle en est l’essence fondamentale ?
Pour reprendre une expression récemment populaire, comment appliquer le « principe de la première vérité » (first principles thinking) au cross-chain ?
Si la caractéristique centrale — et distinctive — des blockchains est la désintermédiation, c’est-à-dire la capacité à vérifier l’information sans avoir à faire confiance (« Don’t trust, verify »), alors le cross-chain consiste essentiellement à valider une information provenant d’une chaîne donnée sur une autre chaîne. L’information transmise inclut, de façon générale, les transactions ainsi que les preuves de leur validité (généralement des preuves Merkle).
À partir de ces informations vérifiables sur la chaîne, les blockchains peuvent construire des applications basiques telles que le transfert d’actifs. De même, à partir d’informations cross-chain vérifiées, certaines applications inter-chaînes peuvent être développées, comme le transfert de jetons via la méthode classique « lock & mint » (verrouillage sur la chaîne source, puis émission sur la chaîne cible).
Par conséquent, selon le type de problème abordé par une technologie ou un projet cross-chain, il est possible de les classer selon deux axes principaux : la couche communication et la couche application.
2. Classification des technologies cross-chain
Couche communication
Commençons par la couche communication. Comment permettre à une information sur une chaîne d’être vérifiée par une autre chaîne ? En fonction de qui effectue la vérification, on distingue principalement trois approches : la validation externe, la validation locale et la validation native.
-
Validation externe : l’information cross-chain est validée par des tiers appelés « témoins » (aussi nommés notaires, passerelles, etc.). Cette méthode permet une connexion rapide entre chaînes hétérogènes, car elle ne nécessite que la capacité des témoins à lire/écrire sur chaque chaîne. Toutefois, la validité de l’information (par exemple, si une transaction a bien été confirmée sur la chaîne source) dépend entièrement de ces témoins. La sécurité globale du système repose donc sur l’hypothèse d’honnêteté des témoins.
-
Validation locale : sans recourir à des témoins externes, les utilisateurs peuvent eux-mêmes observer les transactions sur la chaîne et garantir l’échange mutuel via des mécanismes techniques comme HTLC. Cette approche évite de faire confiance à un tiers et permet un transfert rapide entre chaînes hétérogènes. Son inconvénient principal est la difficulté à implémenter des applications complexes, telles que le transfert d’informations générales ou l’appel de contrats intelligents.
-
Validation native : la blockchain valide elle-même l’authenticité des informations cross-chain. Cela se fait généralement en intégrant un client léger (light client) d’une autre blockchain. Ainsi, elle peut suivre, récupérer et vérifier les données d’une autre chaîne, puis agir en conséquence (transfert inter-chaînes, libération de jetons, etc.). Étant donné la diversité des modèles de chaînes hétérogènes, l’existence d’un standard facilitant la conception et l’implémentation (comme le protocole IBC) est cruciale. Cette approche offre la meilleure sécurité, car elle n’introduit aucune hypothèse de confiance supplémentaire, mais implique un effort de développement important (intégration de clients légers, mise en œuvre éventuelle d’une pile complète de protocoles cross-chain, etc.).
Couche application
La seule existence d'une couche communication inférieure n'est pas suffisante : il faut aussi développer des applications orientées utilisateur. À partir des informations cross-chain validées en amont, toutes sortes d'applications inter-chaînes peuvent théoriquement être conçues, tant qu'elles n'exigent pas une forte cohérence transactionnelle. Les cas les plus courants restent toutefois les transferts de jetons et autres opérations basiques.
La question centrale devient donc : comment transmettre la liquidité inter-chaînes ? Pour y répondre, on peut s’inspirer des modèles de marché : contrepartie centrale, OTC/P2P, échange automatisé (swap).
-
Contrepartie centrale : souvent adoptée par les « ponts officiels », cette méthode repose sur une adresse désignée officiellement pour gérer les entrées/sorties. Il s’agit du modèle « lock & mint » mentionné précédemment. Par exemple, lorsque l’utilisateur initie un transfert cross-chain, son jeton est verrouillé sur une adresse de la chaîne source, tandis qu’un nouveau jeton est frappé sur la chaîne cible.
-
OTC/P2P : outre la contrepartie officielle, celle-ci peut aussi être assurée par des tierces parties comme des market makers ou d’autres utilisateurs. Par exemple, un utilisateur propose de la liquidité pour un transfert inter-chaînes, et un market maker accepte cette offre en libérant la liquidité correspondante sur la chaîne cible.
-
Échange automatisé (Swap) : au-delà des échanges entre utilisateurs, la contrepartie peut être un protocole d’échange automatisé. Par exemple, un utilisateur échange un actif sur un AMM de la chaîne source, puis le protocole effectue l’opération inverse sur la chaîne cible.
-
Agrégation de liquidité : à l’instar des protocoles comme 1inch qui agrègent la liquidité sur une même chaîne, certains protocoles combinent différentes solutions de liquidité cross-chain afin d’offrir aux utilisateurs le meilleur taux, la liquidité optimale ou le coût le plus bas pour leurs transferts inter-chaînes.
II. Quelles nouvelles possibilités pour le cross-chain ?
1. Des infrastructures plus légères
Bien que le protocole IBC soit considéré comme la norme dorée du cross-chain, sa mise en œuvre sur des chaînes hétérogènes peut rencontrer des obstacles pratiques. Par exemple, la vérification des en-têtes de bloc Tendermint sur Ethereum peut dépasser la limite de gaz disponible en raison du calcul des signatures Ed25519.
Du relais à l’oracle
Le bon fonctionnement du protocole IBC dépend du rôle des relais (relayers). Ce qui peut sembler « contre-intuitif », c’est que ces relais peuvent être centralisés sans pour autant devoir être « de confiance » (trusted). En effet, les informations qu’ils transmettent peuvent être vérifiées indépendamment par la chaîne cible. Un relais malveillant ne peut donc pas falsifier les messages pour voler les fonds des utilisateurs, comme cela pourrait arriver dans les systèmes à validation externe. Le relais joue ainsi un rôle similaire à celui de la couche physique dans les protocoles Internet : connecter différents réseaux et transporter les données.
Même si la sécurité (security) d’IBC ne dépend pas des relais, le protocole nécessite néanmoins qu’au moins un relais fonctionnel soit actif pour garantir sa vivacité (liveness).
Or, la tâche principale du relais consiste à surveiller la chaîne source et à soumettre les informations sur la chaîne cible — autrement dit, réaliser le transfert d’information. Ce processus peut donc être réalisé via des oracles. Autrement dit, les oracles évoluent d’un rôle « hors-chaîne vers sur-chaîne » à un rôle « sur-chaîne vers sur-chaîne ».
C’est probablement l’une des raisons pour lesquelles de nombreux projets d’oracles, comme Chainlink CCIP[1] ou SupraOracle, s’orientent désormais vers le cross-chain.
De l’oracle au TEE
Quelles informations exactement peuvent être transmises par un oracle ? LayerZero constitue un excellent exemple. Il délègue aux oracles la vérification de l’état de consensus, telle que définie dans IBC. Ainsi, plutôt que de continuellement mettre à jour et vérifier les en-têtes de bloc en fonction des changements de validateurs, il suffit d’interroger et de valider les informations nécessaires via un oracle au moment opportun.
LayerZero délègue une partie du travail du client léger à des oracles [2]
Cette approche réduit considérablement les coûts de vérification sur la chaîne. Le relais, quant à lui, n’a plus qu’à transmettre la transaction inter-chaînes et sa preuve. LayerZero peut ainsi rapidement connecter plusieurs chaînes EVM. Toutefois, l’introduction d’un oracle tiers ajoute une hypothèse de sécurité supplémentaire (il faut faire confiance à l’oracle pour qu’il n’agisse pas de concert avec un attaquant), ce qui diminue légèrement la sécurité globale du système. D'autres solutions envisageables incluent l'utilisation des « oracles natifs » de Substrate, via les off-chain workers [3].
Pour réduire la dépendance vis-à-vis des oracles, une autre piste consiste à améliorer la synchronisation des en-têtes de bloc via d'autres technologies. Par exemple, LCP Network utilise un environnement d’exécution fiable (TEE) pour valider les transactions inter-chaînes [4].
De la preuve Merkle à la preuve ZK
Outre la transmission de l’information, la manière dont l’information elle-même — et sa preuve — est construite fait également l’objet de recherches récentes utilisant la technologie des preuves à divulgation nulle (zero-knowledge proofs). En reprenant la définition du cross-chain donnée en introduction, l’un des éléments clés à transmettre est la preuve de validité d’une transaction. Dans les implémentations actuelles, on utilise généralement des preuves Merkle.
Une autre grande catégorie de preuves de validité est constituée par les preuves ZK, associées à la technologie très en vogue des zero-knowledge proofs. Grâce aux progrès récents dans ce domaine, les ponts inter-chaînes basés sur ZK (ZK Bridges) passent progressivement de la théorie [5] à la faisabilité pratique.
En générant une preuve ZK, il devient possible de résoudre des problèmes coûteux comme la vérification de signatures Ed25519 sur Ethereum. Par exemple, Electron Labs implémente des preuves ZK-SNARKs pour vérifier la légitimité des signatures sur des chaînes basées sur Tendermint [6], évitant ainsi des calculs très coûteux dans les contrats intelligents.
Conception d’IBC sur Ethereum utilisant des preuves ZK [6]
Parmi les autres équipes et projets actuellement en développement de ponts ZK figurent Succinct Labs, zkbridge [7], Polymer [8] et Mina [9].
Quelques conceptions actuelles de ponts basés sur ZK [7]
2. Meilleur support pour les développeurs (transfert d’informations générales, appels de contrats intelligents)
Ces protocoles fondamentaux de cross-chain permettent un meilleur support pour le transfert d’informations générales, y compris les appels de contrats intelligents. De nombreux projets s’appuient dès lors sur ces bases pour proposer des SDK et d’autres outils facilitant le développement d’applications multi-chaînes ou omni-chaînes (omni-chain).
On retrouve notamment IBC Interchain Account [10], Multichain anycall, Celer IM, etc. Il est également possible de développer des middlewares plus conviviaux (comme Spanning Labs), qui permettent de créer des applications déployées sur plusieurs chaînes et capables de règlements inter-chaînes. Ces outils externalisent aux couches inférieures ou aux middlewares des tâches auparavant gérées au niveau applicatif, comme le transfert de jetons.
3. Innovation au niveau de la liquidité applicative
Grâce aux protocoles cross-chain de base et aux middlewares, de nouvelles innovations sont possibles au niveau de la liquidité applicative. Par exemple, le concept récent de slAMM [11] (AMM à liquidité partagée) utilise une chaîne Hub pour coordonner la liquidité sur plusieurs « chaînes satellites ». Sur cette base, des fonctions de gestion comme le déplacement ou le règlement de liquidité entre chaînes peuvent être réalisées via des protocoles cross-chain.
Comparaison entre dAMM et slAMM [11]
4. Retour d’influence sur la couche protocole
Le cross-chain est généralement perçu comme un soutien à la couche protocole des blockchains. Toutefois, avec son évolution, il pourrait à son tour influencer la conception future des protocoles blockchain eux-mêmes.
Amélioration du consensus
Premier impact notable : celui sur le consensus des blockchains.
Avec l’émergence du modèle « application chain + cross-chain », de nombreuses chaînes dédiées à une application spécifique peuvent ne pas être suffisamment sécurisées à leur lancement. Elles doivent alors recourir à des mécanismes de validation inter-chaînes, où un grand réseau garantit la sécurité d’un petit réseau. C’est le cas par exemple de la sécurité inter-chaînes (interchain security) dans Cosmos ou de l’architecture Polkadot (chaîne-relais + parachains).
Au-delà de cette validation unidirectionnelle (petites chaînes autour d’une chaîne principale), une autre possibilité récemment proposée est la « sécurité maillée » (Mesh Security) [12], où les réseaux se valident mutuellement. Cette idée en est encore à ses débuts, et ses modalités concrètes restent à observer.
Exemple de sécurité maillée [12]
Impact sur le MEV
Un autre impact significatif concerne la conception du MEV (Maximum Extractable Value). L’industrie du MEV sur une seule chaîne est déjà très développée. Selon une étude de Chorus One [13], plus de 1 milliard de dollars de MEV avaient été extraits sur Ethereum au total d’ici octobre 2022.
Les conceptions de protocoles cross-chain commencent à intégrer des réflexions sur le MEV, ce qui pourrait transformer le paysage actuel. Par exemple, le livre blanc de Cosmos 2.0 [14] ou encore Zenith [15] proposent une marchandisation de l’espace-bloc inter-chaînes. Cela pourrait se concrétiser via un « planificateur inter-chaînes » (Interchain Allocator) permettant :
Aux chaînes consommatrices (via sécurité partagée) d’offrir de l’espace-bloc
Aux utilisateurs d’acheter cet espace pour garantir des opportunités d’arbitrage ou de règlement cross-chain
Conclusion
Bien que l’attention principale de l’innovation dans l’écosystème blockchain soit actuellement focalisée sur Ethereum (ZK, AA, MEV, etc.), les avancées récentes dans les protocoles cross-chain — notamment en matière de légèreté des protocoles de base, de support accru aux développeurs, d’innovations dans la liquidité applicative et d’influence rétroactive sur les couches protocole —, en particulier dans le domaine des ponts ZK, offrent de nombreuses perspectives prometteuses. Toutefois, en raison de la rapidité des évolutions technologiques et du grand nombre de projets, cette brève synthèse ne prétend pas à l’exhaustivité et peut contenir des erreurs ou omissions. Toute discussion est la bienvenue !
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
