Introduction

L'avenir est aux chaînes multiples. La recherche de l'évolutivité a conduit Ethereum vers les roll-ups. L'évolution vers des blockchains modulaires a relancé l'attention sur les chaînes d'applications. Et à l'horizon, nous entendons des murmures sur les roll-ups spécifiques aux applications, les L3 et les chaînes souveraines.

Mais cela s'est fait au prix d'une fragmentation. La première vague de passerelles de base a donc été lancée pour répondre au besoin de passerelle, mais elles sont souvent limitées en termes de fonctionnalités et dépendent de signataires de confiance pour la sécurité.

À quoi ressemblera la finalité d'un réseau interconnecté3 ? Nous pensons que tous les ponts évolueront vers des protocoles de messagerie inter-chaînes ou de "passage de messages arbitraires" (AMP) afin de débloquer de nouveaux cas d'utilisation, en permettant aux applications de passer des messages arbitraires de la chaîne source à la chaîne de destination. Nous assisterons également à l'émergence d'un "paysage de mécanismes de confiance", dans lequel les constructeurs devront faire des compromis en matière de facilité d'utilisation, de complexité et de sécurité.

Toute solution AMP a besoin de deux fonctionnalités essentielles :

• Vérification : La capacité de vérifier la validité du message de la chaîne source sur la chaîne de destination.
• Caractère vivant (Liveness) : La capacité de relayer l'information de la source à la destination

Il n'est pas possible de réaliser une vérification sans confiance à 100 % et les utilisateurs doivent faire confiance au code, à la théorie des jeux, aux humains (ou aux entités) ou à une combinaison de ces éléments, selon que la vérification est effectuée sur la chaîne ou en dehors de la chaîne.

Nous divisons le paysage global de l'interopérabilité en fonction du mécanisme de confiance et de l'architecture d'intégration.

Mécanisme de confiance :

1. Code de confiance/math : Pour ces solutions, il existe une preuve sur la chaîne qui peut être vérifiée par n'importe qui. Ces solutions s'appuient généralement sur un client léger pour valider le consensus d'une chaîne source sur une chaîne de destination ou pour vérifier la validité d'une transition d'état pour une chaîne source sur une chaîne de destination. La vérification par l'intermédiaire de clients légers peut être rendue beaucoup plus efficace grâce aux preuves de connaissance zéro, qui permettent de comprimer les calculs arbitrairement longs hors ligne et de fournir une vérification simple sur la chaîne pour prouver les calculs.
2. Théorie des jeux de confiance : Il existe une hypothèse de confiance supplémentaire lorsque l'utilisateur/l'application doit faire confiance à un tiers ou à un réseau de tiers pour l'authenticité des transactions. Ces mécanismes peuvent être rendus plus sûrs grâce à des réseaux sans autorisation associés à la théorie des jeux, comme les incitations économiques et la sécurité optimiste.
3. Faire confiance aux humains : Ces solutions reposent sur l'honnêteté de la majorité des validateurs ou sur l'indépendance des entités relayant des informations différentes. Ils nécessitent la confiance dans des tiers en plus de la confiance dans le consensus des deux chaînes qui interagissent. La seule chose en jeu ici est la réputation des entités participantes. Si un nombre suffisant d'entités participantes s'accordent sur la validité d'une transaction, celle-ci est considérée comme valide.

Il est important de noter que toutes les solutions nécessitent, dans une certaine mesure, de faire confiance au code et aux humains. Toute solution dont le code est défectueux peut être exploitée par des pirates informatiques et toute solution comporte un élément humain dans la mise en place, les mises à jour ou la maintenance de la base de code.

Architecture d'intégration :

1. Modèle point à point : Un canal de communication dédié doit être établi entre chaque source et chaque destination.
2. Modèle en étoile : Un canal de communication doit être établi avec un hub central qui permet la connectivité avec toutes les autres blockchains connectées à ce hub.

Le modèle point à point est relativement difficile à mettre à l'échelle car un canal de communication par paire est nécessaire pour chaque blockchain connectée. Le développement de ces canaux peut s'avérer difficile pour les blockchains ayant des consensus et des cadres différents. Toutefois, les passerelles par paire offrent une plus grande souplesse pour personnaliser les configurations, si nécessaire. Une approche hybride est également possible, par exemple en utilisant un protocole de communication inter-blockchain (IBC) avec un routage multi-sauts via un hub, ce qui supprime la nécessité d'une communication directe par paire, mais réintroduit une plus grande complexité en matière de sécurité, de latence et de considérations de coût.

Code de confiance/mathématique

Comment les clients légers valident-ils le consensus d'une chaîne source sur une chaîne de destination ?

Un client/nœud léger est un logiciel qui se connecte à des nœuds complets pour interagir avec la blockchain. Les clients légers de la chaîne de destination stockent normalement l'historique des en-têtes de blocs (de manière séquentielle) de la chaîne source, ce qui est suffisant pour vérifier les transactions. Les agents hors chaîne, tels que les relais, surveillent les événements sur la chaîne source, génèrent des preuves d'inclusion cryptographiques et les transmettent, avec les en-têtes de bloc, au client léger sur la chaîne de destination. Les clients légers sont en mesure de vérifier la transaction car ils stockent les en-têtes de bloc de manière séquentielle et chaque en-tête de bloc contient le hachage de la racine Merkle qui peut être utilisé pour prouver l'état. Les principales caractéristiques de ce mécanisme sont les suivantes

1. La sécurité :

• Outre la confiance dans le code, une autre hypothèse de confiance est introduite lors de l'initialisation du client léger. Lorsque quelqu'un crée un nouveau client léger, celui-ci est initialisé avec un en-tête provenant d'une hauteur spécifique de la chaîne de contrepartie. L'en-tête fourni peut être incorrect et le client léger peut être trompé par la suite avec d'autres faux en-têtes. Aucune hypothèse de confiance n'est introduite une fois que le client léger a été initialisé. Cependant, il s'agit d'une hypothèse de confiance faible car n'importe qui peut vérifier l'initialisation.
• Le relayeur est soumis à une hypothèse de permanence puisqu'il est tenu de transmettre l'information.

1. Mise en œuvre : dépend de la disponibilité de la prise en charge des primitives cryptographiques nécessaires à la vérification

• Si le même type de chaîne est connecté (même cadre d'application et algorithme de consensus), l'implémentation du client léger des deux côtés sera la même. Exemple : IBC pour toutes les chaînes basées sur le SDK Cosmos.
• Si deux types de chaînes différents (différents cadres d'application ou types de consensus) sont connectés, l'implémentation du client léger sera différente. Exemple : Composable finance travaille pour permettre aux chaînes Cosmos SDK d'être connectées via IBC à Substrate (cadre d'application de l'écosystème Polkadot). Cela nécessite un client léger Tendermint sur la chaîne du substrat et un client léger dit "beefy" ajouté à la chaîne du SDK Cosmos.

1. Défis :

• L'intensité des ressources : Il est coûteux de faire fonctionner des clients légers par paire sur toutes les chaînes, car les écritures sur les blockchains sont coûteuses et ne peuvent pas être exécutées sur des chaînes avec des ensembles de validateurs dynamiques comme Ethereum.
• Extensibilité : Une mise en œuvre légère du client est nécessaire pour chaque combinaison de chaînes. Étant donné que la mise en œuvre varie en fonction de l'architecture de la chaîne, il est difficile de faire évoluer et de connecter différents écosystèmes.
• Exploitation du code : Les erreurs dans le code peuvent entraîner des vulnérabilités. L'exploit de la chaîne BNB en octobre 2022 a mis au jour une faille de sécurité critique affectant toutes les chaînes compatibles IBC.

Comment les preuves ZK vérifient-elles la validité d'une transition d'état de la chaîne source sur la chaîne de destination ?

L'exécution de clients légers par paire sur toutes les chaînes est d'un coût prohibitif et n'est pas pratique pour toutes les blockchains. Les clients légers dans des implémentations comme IBC sont également tenus de garder une trace de l'ensemble de validateurs de la chaîne source, ce qui n'est pas pratique pour les chaînes avec des ensembles de validateurs dynamiques, comme Ethereum. Les épreuves ZK offrent une solution pour réduire le temps de vérification et de production de gaz. Au lieu d'exécuter l'ensemble du calcul sur la chaîne, seule la vérification de la preuve de calcul est effectuée sur la chaîne et le calcul proprement dit est effectué en dehors de la chaîne. La vérification d'une preuve de calcul peut être effectuée en moins de temps et avec moins de gaz que la ré-exécution du calcul original. Les principales caractéristiques de ce mécanisme sont les suivantes

1. Sécurité : les zk-SNARKs dépendent des courbes elliptiques pour leur sécurité et les zk-STARKs dépendent des fonctions de hachage. Les zk-SNARKs peuvent ou non nécessiter une installation de confiance. La configuration de confiance n'est nécessaire qu'au départ, c'est-à-dire lors de la création initiale des clés utilisées pour créer les preuves nécessaires à la vérification de ces preuves. Si les secrets de l'événement d'installation ne sont pas détruits, ils pourraient être utilisés pour falsifier des transactions par de fausses vérifications. Aucune hypothèse de confiance n'est introduite une fois que la configuration de confiance est effectuée.
2. Mise en œuvre : Il existe aujourd'hui différents systèmes de preuve ZK tels que SNARK, STARK, VPD, SNARG, et actuellement SNARK est le plus largement adopté. Les preuves récursives ZK sont un autre développement récent qui permet de répartir le travail total de preuve entre plusieurs ordinateurs au lieu d'un seul. Pour générer des preuves de validité, les primitives de base suivantes doivent être mises en œuvre :

• la vérification du système de signature utilisé par les validateurs
• inclusion de la preuve des clés publiques du validateur dans l'engagement de l'ensemble de validateurs (qui est stocké sur la chaîne)
• le suivi de l'ensemble des validateurs qui peuvent changer fréquemment

1. Défis :

• La mise en œuvre de différents systèmes de signature dans un zkSNARK nécessite la mise en œuvre d'opérations arithmétiques hors champ et d'opérations complexes sur la courbe elliptique. Cela n'est pas facile à réaliser et pourrait nécessiter des mises en œuvre différentes pour chaque chaîne, en fonction de leur cadre et de leur consensus.
• Si le temps et l'effort de preuve sont extrêmement élevés, seules des équipes spécialisées disposant d'un matériel spécialisé seront en mesure de le faire, ce qui conduira à la centralisation. Un temps de génération de preuve plus élevé peut également entraîner une latence.
• L'augmentation du temps et des efforts de vérification se traduira par une augmentation des coûts de la chaîne.

1. Exemples : Polymer ZK-IBC de Polymer Labs, Succinct Labs. Polymer travaille sur l'IBC multi-sauts afin d'augmenter la connectivité tout en réduisant le nombre de connexions par paire nécessaires.

Théorie des jeux de confiance

Les protocoles d'interopérabilité qui s'appuient sur la théorie des jeux peuvent être divisés en deux catégories en fonction de la manière dont ils incitent les entités participantes à adopter un comportement honnête :

1. Sécurité économique : Plusieurs participants externes (comme les validateurs) parviennent à un consensus sur l'état actualisé de la chaîne source. Il s'agit d'une configuration similaire à une configuration multi-sig, mais pour devenir un validateur, les participants doivent miser un certain nombre de jetons, qui peuvent être réduits en cas de détection d'une activité malveillante. Dans les systèmes sans autorisation, n'importe qui peut accumuler des enjeux et devenir un validateur. Il existe également des récompenses en bloc, qui servent d'incitations économiques, lorsque les validateurs participants respectent le protocole. Les participants sont donc économiquement incités à être honnêtes. Toutefois, si le montant qui peut être volé est beaucoup plus élevé que le montant mis en jeu, les participants peuvent tenter de s'entendre pour voler des fonds. Exemples : Axelar, Celer IM
2. Sécurité optimiste : Les solutions de sécurité optimistes reposent sur l'hypothèse de la confiance minoritaire, qui suppose que seule une minorité de participants à la blockchain sont vivants, honnêtes et respectent les règles du protocole. La solution pourrait exiger qu'un seul participant honnête détienne une garantie. L'exemple le plus courant est celui d'une solution optimale où tout le monde peut soumettre une preuve de fraude. Il existe également une motivation économique, mais il est pratiquement possible, même pour un observateur honnête, de ne pas voir une transaction frauduleuse. Les roll-ups optimistes tirent également parti de cette approche. Exemples : Nomad, ChainLink CCIP

• Dans le cas de Nomad, les observateurs peuvent prouver la fraude. Toutefois, les observateurs de Nomad sont inscrits sur la liste blanche au moment de la rédaction du présent document.
• Le CCIP de ChainLink s'appuiera sur un réseau anti-fraude qui consistera en des réseaux oracles décentralisés ayant pour seul but de surveiller les activités malveillantes. La mise en œuvre du réseau anti-fraude de la CCIP n'est pas encore connue.

Les principales caractéristiques de ces mécanismes sont les suivantes

1. Sécurité : Pour les deux mécanismes, il est essentiel que les validateurs et les observateurs participent sans autorisation pour que les mécanismes de la théorie des jeux soient efficaces. Dans le cadre du mécanisme de sécurité économique, les fonds peuvent être plus exposés si le montant mis en jeu est inférieur au montant qui peut être volé. Dans le cadre du mécanisme de sécurité optimiste, les hypothèses de confiance minoritaire pour les solutions optimistes peuvent être exploitées si personne ne soumet la preuve de fraude ou si les observateurs autorisés sont compromis/supprimés, alors que les mécanismes de sécurité économiques n'ont pas la même dépendance à l'égard de la rapidité pour la sécurité.
2. Mise en œuvre :

• Chaîne intermédiaire avec ses propres validateurs : Un groupe de validateurs externes surveille la chaîne source, parvient à un consensus sur la validité de la transaction chaque fois qu'un appel est détecté, et fournit une attestation sur la chaîne de destination si le consensus est atteint. Les validateurs sont généralement tenus de mettre en jeu un certain nombre de jetons qui peuvent être réduits si une activité malveillante est détectée. Exemples : Axelar Network, Celer IM
• Via des agents hors chaîne : Les agents hors chaîne peuvent être utilisés pour mettre en œuvre une solution optimiste de type roll-up où, pendant une fenêtre de temps prédéfinie, les agents hors chaîne seront autorisés à soumettre des preuves de fraude et à annuler la transaction. Exemple : Nomad s'appuie sur des agents indépendants hors chaîne pour relayer l'en-tête et la preuve cryptographique. ChainLink CCIP s'appuiera sur son réseau oracle existant pour contrôler et attester les transactions inter-chaînes.

1. Défis :

• Les hypothèses de confiance peuvent être exploitées pour voler des fonds si la majorité des validateurs sont de connivence, ce qui nécessite des contre-mesures telles que le vote quadratique et les preuves de fraude.
• Finalité : Les solutions optimistes d'AMP basées sur la sécurité introduisent une complexité dans la finalité et la vivacité parce que les utilisateurs et les applications doivent attendre la fenêtre de fraude.

1. Avantages :

• Optimisation des ressources : Cette approche n'est généralement pas gourmande en ressources car la vérification n'a généralement pas lieu sur la chaîne.
• Extensibilité : Cette approche est plus extensible car le mécanisme de consensus reste le même pour tous les types de chaînes et peut être facilement étendu à des blockchains hétérogènes.

Faire confiance aux humains

1. Hypothèse de l'honnêteté de la majorité : Ces solutions reposent sur une mise en œuvre multi-sig dans laquelle plusieurs entités vérifient et signent les transactions. Une fois le seuil minimum atteint, la transaction est considérée comme valide. On part ici du principe que la majorité des entités sont honnêtes et que si une majorité d'entre elles signent une transaction particulière, celle-ci est valide. La seule chose en jeu ici est la réputation des entités participantes. Exemples : Multichain (Anycall V6), Wormhole. Des exploits dus à des bogues de contrats intelligents sont toujours possibles, comme l'a montré le piratage de Wormhole au début de 2022.
2. Indépendance : Ces solutions divisent l'ensemble du processus de transmission des messages en deux parties et s'appuient sur des entités indépendantes différentes pour gérer les deux processus. On suppose ici que les deux entités sont indépendantes l'une de l'autre et ne sont pas de connivence. Exemple : LayerZero. Les en-têtes de blocs sont diffusés à la demande par des oracles décentralisés et les preuves de transaction sont envoyées par l'intermédiaire de relais. Si la preuve correspond aux en-têtes, la transaction est considérée comme valide. Alors que l'appariement des preuves repose sur le code/math, les participants doivent faire confiance aux entités pour qu'elles restent indépendantes. Les applications reposant sur LayerZero ont la possibilité de choisir leur Oracle et leur relais (ou d'héberger leur propre Oracle/relayer), ce qui limite le risque de collusion entre l'Oracle et le relais. Les utilisateurs finaux doivent être convaincus que LayerZero, un tiers ou l'application elle-même exécute l'oracle et le relais de manière indépendante et sans intentions malveillantes.

Dans les deux approches, la réputation des entités tierces participantes décourage les comportements malveillants. Il s'agit généralement d'entités respectées au sein de la communauté des validateurs et des oracles, qui risquent de nuire à leur réputation et d'avoir un impact négatif sur leurs autres activités commerciales si elles agissent de manière malveillante.

Au-delà des hypothèses de confiance et de l'avenir de l'interopérabilité

Tout en examinant la sécurité et la facilité d'utilisation d'une solution AMP, nous devons également prendre en compte les détails au-delà des mécanismes de base. Comme il s'agit d'éléments mobiles qui peuvent changer au fil du temps, nous ne les avons pas inclus dans la comparaison globale.

• Intégrité du code : Un certain nombre de piratages récents ont exploité des bogues dans le code, ce qui nécessite des audits fiables, des primes aux bogues bien planifiées et de multiples implémentations de clients. Si tous les validateurs (en sécurité économique/optimiste/réputationnelle) exécutent le même client (logiciel de vérification), cela accroît la dépendance à l'égard d'une base de code unique et réduit la diversité des clients. Ethereum, par exemple, s'appuie sur de multiples clients d'exécution comme geth, nethermind, erigon, besu, akula. Des implémentations multiples dans une variété de langues sont susceptibles d'accroître la diversité sans qu'aucun client ne domine le réseau, éliminant ainsi un point de défaillance unique potentiel. Le fait d'avoir plusieurs clients pourrait également contribuer à la vivacité si une minorité de validateurs/signataires/clients légers tombent en panne en raison d'exploits/bugs dans une implémentation particulière.
• Mise en place et évolutivité : Les utilisateurs et les développeurs doivent savoir si les validateurs/observateurs peuvent rejoindre le réseau sans autorisation, sinon la confiance est cachée par la sélection des entités autorisées. Les mises à jour des contrats intelligents peuvent également introduire des bogues qui peuvent conduire à des exploits ou même potentiellement modifier les hypothèses de confiance. Différentes solutions peuvent être mises en œuvre pour atténuer ces risques. Par exemple, dans l'instanciation actuelle, les passerelles Axelar peuvent être mises à niveau sous réserve de l'approbation d'un comité hors ligne (seuil de 4/8) ; toutefois, dans un avenir proche, Axelar prévoit de demander à tous les validateurs d'approuver collectivement toute mise à niveau des passerelles. Les contrats de base de Wormhole sont évolutifs et gérés par le système de gouvernance de la chaîne de Wormhole. LayerZero s'appuie sur des contrats intelligents immuables et des bibliothèques immuables pour éviter toute mise à jour, cependant, il peut pousser une nouvelle bibliothèque, et les dapps avec des paramètres par défaut obtiendront la version mise à jour, et les dapps avec leur version réglée manuellement devront la régler sur la nouvelle.
• MEV : Les différentes blockchains ne sont pas synchronisées par une horloge commune et ont des délais de finalisation différents. Par conséquent, l'ordre et le moment de l'exécution sur la chaîne de destination peuvent varier d'une chaîne à l'autre. Il est difficile de définir clairement le MEV dans un monde de chaînes croisées. Il introduit un compromis entre la rapidité et l'ordre d'exécution. Un canal ordonné garantit la livraison ordonnée des messages, mais le canal se fermera si l'un des messages n'aboutit pas. Une autre application pourrait préférer un scénario dans lequel la commande n'est pas nécessaire mais où la livraison d'autres messages n'est pas affectée.

Tendances et perspectives d'avenir :

• Sécurité personnalisable et additive : Pour mieux répondre aux différents cas d'utilisation, les solutions AMP sont incitées à offrir plus de flexibilité aux développeurs. Axelar a présenté une approche permettant d'améliorer le passage des messages et la vérification, sans modifier la logique de la couche d'application. HyperLane V2 a introduit des modules qui permettent aux développeurs de choisir parmi plusieurs options telles que la sécurité économique, la sécurité optimiste, la sécurité dynamique et la sécurité hybride. CelerIM offre une sécurité optimiste supplémentaire ainsi qu'une sécurité économique. De nombreuses solutions attendent un nombre minimum prédéfini de confirmations de blocs sur la chaîne source avant de transmettre le message. LayerZero permet aux développeurs de mettre à jour ces paramètres. Nous nous attendons à ce que certaines solutions AMP continuent à offrir plus de flexibilité, mais ces choix de conception méritent d'être discutés. Les applications doivent-elles être en mesure de configurer leur sécurité, dans quelle mesure, et que se passe-t-il si les applications adoptent une architecture de conception médiocre ? La sensibilisation des utilisateurs aux concepts de base de la sécurité pourrait devenir de plus en plus importante. En fin de compte, nous prévoyons l'agrégation et l'abstraction des solutions AMP, peut-être sous une forme de combinaison ou de sécurité "additive".
• Croissance et maturation des mécanismes de "code de confiance/math" : Dans une fin de partie idéale, tous les messages inter-chaînes seront réduits au minimum grâce à l'utilisation de preuves de connaissance zéro (ZK) pour vérifier les messages et les états. Nous assistons déjà à cette évolution avec l'émergence de projets tels que Polymer Labs et Succinct Labs. Multichain a également publié récemment un livre blanc sur le zkRouter afin de permettre l'interopérabilité par le biais de preuves ZK. Avec la machine virtuelle Axelar récemment annoncée, les développeurs peuvent utiliser l'amplificateur Interchain pour établir sans permission de nouvelles connexions au réseau Axelar. Par exemple, une fois que des clients légers robustes & ZK proofs pour l'état d'Ethereum sont développés, un développeur peut facilement les intégrer dans le réseau Axelar pour remplacer ou améliorer une connexion existante. Dans sa documentation, LayerZero évoque la possibilité d'ajouter à l'avenir de nouvelles bibliothèques de messagerie de preuve optimisées. Des projets plus récents comme Lagrange explorent l'agrégation de preuves multiples à partir de chaînes sources multiples et Herodotus rend les preuves de stockage réalisables grâce aux preuves ZK. Toutefois, cette transition prendra du temps, car il est difficile de faire évoluer cette approche parmi les blockchains qui reposent sur des mécanismes et des cadres de consensus différents. Le ZK est une technologie relativement nouvelle et complexe qui est difficile à contrôler et, actuellement, la vérification et la production de preuves ne sont pas optimales en termes de coûts. Nous pensons qu'à long terme, pour soutenir des applications inter-chaînes hautement évolutives sur la blockchain, de nombreuses solutions AMP sont susceptibles de compléter les humains et les entités de confiance avec des logiciels vérifiables parce que :
• La possibilité d'exploitation du code peut être minimisée par des audits et des primes aux bogues. Avec le temps, il sera plus facile de faire confiance à ces systèmes, car leur histoire servira de preuve de leur sécurité.
• Le coût de production des preuves ZK diminuera. Avec plus de R&D dans les ZKP, les ZK récursifs, l'agrégation de preuves et le matériel spécialisé, nous nous attendons à ce que le temps et le coût de la génération et de la vérification des preuves soient considérablement réduits, ce qui en fait une approche plus rentable.
• Les blockchains deviendront plus conviviales. À l'avenir, les zkEVM pourront fournir une preuve de validité succincte de l'exécution, et des solutions légères basées sur le client pourront facilement vérifier à la fois l'exécution et le consensus d'une chaîne source sur la chaîne de destination. La finalité d'Ethereum prévoit également de tout "zk-SNARK", y compris le consensus.
• Preuve d'humanité/de réputation/d'identité : La sécurité des systèmes complexes tels que les solutions AMP ne peut être encapsulée dans un cadre unique et justifie plusieurs couches de solutions. Par exemple, outre les incitations économiques, Axelar a mis en place un système de vote quadratique pour empêcher la concentration du pouvoir de vote au sein d'un sous-ensemble de nœuds et promouvoir la décentralisation. D'autres preuves d'humanité, de réputation et d'identité peuvent également compléter les mécanismes d'installation et d'autorisation.

Dans l'esprit d'ouverture du Web3, nous verrons probablement un avenir pluriel où de multiples approches coexisteront. En fait, les applications peuvent choisir d'utiliser plusieurs solutions d'interopérabilité, soit de manière redondante, soit en permettant aux utilisateurs de les combiner en leur indiquant les compromis à faire. Les solutions point à point peuvent être privilégiées entre les itinéraires à "fort trafic", tandis que les modèles en étoile peuvent dominer la longue queue des chaînes. En fin de compte, c'est à nous, la démonstration collective des utilisateurs, des constructeurs et des contributeurs, qu'il revient de façonner la topographie du web interconnecté3.

Nous tenons à remercier Bo Du et Peter Kim de Polymer Labs, Galen Moore d'Axelar Network, Uma Roy de Succinct Labs, Max Glassman et Ryan Zarick de LayerZero pour leur relecture et leurs précieux commentaires.

Liste de références :

• Axelar : https://docs.axelar.dev/
• CelerIM : https://im-docs.celer.network/developer/celer-im-overview
• ChainLink CCIP : https://blog.chain.link/introducing-the-cross-chain-interoperability-protocol-ccip/
• debridge : https://docs.debridge.finance/
• CIB : https://tutorials.cosmos.network/academy/3-ibc/
• LayerZero : https://layerzero.gitbook.io/docs/
• Multichaîne : https://docs.multichain.org/getting-started/introduction
• Nomade : https://docs.nomad.xyz/nomad-101/introduction
• Laboratoires de polymères : https://polymerlabs.medium.com/
• Succinct Labs : https://blog.succinct.xyz/
• Trou de ver : https://docs.wormhole.com/wormhole/

Liste de lectures complémentaires :

• Naviguer dans les ponts de messagerie arbitraires : Un cadre de comparaison : https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• L2Bridge Risk Framework : https://gov.l2beat.com/t/l2bridge-risk-framework/31
• Horace au pont : https://maven11.substack.com/p/horatius-at-the-bridge

Clause de non-responsabilité：

1. Cet article est repris de[medium]. Tous les droits d'auteur appartiennent à l'auteur original[LongHash Ventures]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.