Les protocoles d’interopérabilité basés sur la théorie des jeux peuvent-ils résoudre l’énigme de la confiance ?

Auteur : STANFORD BLOCKCHAIN ​​​​CLUB Compilé par : Cointime : QDD.
introduction
L’avenir est multi-chaînes. La recherche de l’évolutivité conduit Ethereum vers des solutions évolutives. Le passage aux blockchains modulaires a renouvelé l’intérêt pour les chaînes d’applications. À l’horizon, nous entendons des rumeurs concernant des solutions glissantes spécifiques aux applications, des solutions de couche 3 et des chaînes souveraines. Mais tout cela se fait au prix de la fragmentation, les ponts actuels ayant souvent des fonctionnalités limitées et s'appuyant sur des signataires de confiance pour assurer la sécurité.
À quoi ressemblera la forme finale d’interconnexion dans Internet 3.0 ? Nous pensons que les ponts finiront par évoluer vers des protocoles de messagerie inter-chaînes ou de transmission de messages arbitraires (AMP) pour débloquer de nouveaux cas d'utilisation, permettant aux applications de transmettre des messages arbitraires entre les chaînes source et cible. Nous assisterons également à l’émergence d’un « paysage de confiance » dans lequel les constructeurs font divers compromis en matière de facilité d’utilisation, de complexité et de sécurité.
Chaque solution AMP nécessite deux fonctionnalités clés :
1. Vérification : Vérifiez la validité du message de la chaîne source sur la chaîne cible.
2. Survivabilité : capacité à transférer des informations de la chaîne source à la chaîne cible.
Malheureusement, une vérification à 100 % sans confiance n’est pas réaliste et les utilisateurs doivent faire confiance au code, à la théorie des jeux, aux humains (ou aux entités), ou à une combinaison de ceux-ci, selon que la vérification est effectuée sur la chaîne ou hors chaîne.
Dans cet article, nous diviserons le paysage global de l’interopérabilité verticalement et horizontalement en fonction des mécanismes de confiance et des architectures d’intégration utilisés.
Mécanisme de confiance :
1. Faites confiance au code et aux mathématiques : pour ces solutions, il existe des preuves en chaîne qui peuvent être vérifiées par n’importe qui. Ces solutions s’appuient généralement sur des clients légers pour vérifier le consensus de la chaîne source sur la chaîne cible ou pour vérifier la validité de la transition d’état de la chaîne source sur la chaîne cible. Les preuves à connaissance nulle peuvent rendre la vérification légère du client plus efficace, en compressant les calculs hors ligne arbitrairement longs et en fournissant une vérification simple sur la chaîne pour prouver le calcul.
2. Théorie du jeu de confiance : lorsqu'un utilisateur/une application doit faire confiance à un tiers ou à un groupe de tiers pour garantir l'authenticité d'une transaction, des hypothèses de confiance supplémentaires sont nécessaires. Ces mécanismes peuvent être rendus plus sûrs en combinant des incitations économiques et la théorie des jeux, comme la sécurité optimiste via des réseaux sans permission.
3. Confiance dans l’humain : Ces solutions s’appuient sur l’honnêteté de la majorité des validateurs ou sur l’indépendance des entités qui transmettent différentes informations. En plus de faire confiance au consensus des deux chaînes en interaction, la confiance dans un tiers est également requise. Seule la réputation des entités participantes est ici en jeu. Si suffisamment d’entités participantes jugent une transaction valide, elle est alors 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 de code défectueuse peut être exploitée par des pirates informatiques, et chaque solution comporte un certain élément humain dans la configuration, la mise à niveau ou la maintenance de la base de code.
Architecture intégrée :
1. Modèle peer-to-peer : un canal de communication dédié doit être établi entre chaque chaîne source et chaque chaîne cible.
2. Modèle de hub central : un canal de communication doit être établi avec un hub central qui connecte toutes les autres blockchains connectées au hub.
Le modèle peer-to-peer est relativement difficile à mettre à l’échelle car chaque blockchain connectée nécessite un canal de communication par paires. Développer ces canaux peut être un défi pour les blockchains avec des consensus et des cadres différents. Toutefois, si vous le souhaitez, une approche hybride peut être adoptée, comme l'utilisation du protocole de communication inter-blockchain (IBC) pour le routage multi-sauts via un hub central, ce qui élimine le besoin d'une communication point à point directe mais introduit plus de complexité en termes de sécurité, de latence et de coût.
Faites confiance au code et aux mathématiques
Afin de s'appuyer uniquement sur le code/les mathématiques pour les hypothèses de confiance, un client léger peut être utilisé pour vérifier le consensus de la chaîne source sur la chaîne cible. Un client/nœud léger est un logiciel qui se connecte à un nœud complet pour interagir avec la blockchain. Les clients légers sur la chaîne cible stockent généralement les en-têtes de bloc de la chaîne source (dans l'ordre), ce qui est suffisant pour vérifier les transactions. De même, les agents hors chaîne (tels que les relais) sur la chaîne source surveillent les événements, génèrent des preuves d’inclusion cryptographiques et les transmettent avec les en-têtes de bloc aux clients légers sur la chaîne cible. Étant donné que les clients légers stockent les en-têtes de bloc dans l’ordre, ils sont en mesure de vérifier les transactions car chaque en-tête de bloc contient un hachage racine Merkle qui prouve l’état. Voici un aperçu des principales caractéristiques de cette approche :
Sécurité
Les hypothèses de confiance sont introduites lors du processus d’initialisation du client léger. Lorsqu'un nouveau client léger est créé, il est initialisé avec un en-tête de bloc à une hauteur spécifique. Cependant, les en-têtes de bloc fournis peuvent être erronés et il est possible de tromper les clients légers en falsifiant les en-têtes de bloc. Une fois le client léger initialisé, aucune autre hypothèse de confiance n’est introduite. Il convient toutefois de noter que ce processus d’initialisation repose sur une hypothèse de confiance plus faible puisque n’importe qui peut le vérifier. De plus, la continuité du répéteur est également une hypothèse de confiance puisqu'il est responsable de la transmission de l'information.
accomplir
La mise en œuvre de clients légers dépend de la disponibilité des primitives cryptographiques requises pour l’authentification. Si les chaînes connectées sont du même type, c'est-à-dire qu'elles partagent le même cadre d'application et le même algorithme de consensus, alors les implémentations de clients légers des deux côtés seront les mêmes. Par exemple, toutes les chaînes basées sur le SDK Cosmos utilisent le protocole Inter-Blockchain Communication (IBC). En revanche, si vous connectez deux types de chaînes différents, tels que des frameworks d’application ou des types de consensus différents, l’implémentation du client léger sera différente. Un exemple est Composable Finance, qui travaille à connecter la chaîne Cosmos SDK au substrat de l’écosystème Polkadot via IBC. Cela nécessite l'ajout d'un client léger Tendermint sur la chaîne Substrate et d'un client léger « puissant » sur la chaîne Cosmos SDK. Récemment, ils ont établi la première connexion entre Polkadot et Kusama via IBC.
défi
L’intensité des ressources constitue un défi majeur. L’exécution de paires de clients légers sur toutes les chaînes peut être coûteuse, car les écritures sur la blockchain sont coûteuses. De plus, il n’est pas possible d’exécuter des clients légers sur des chaînes avec des ensembles de validateurs dynamiques, comme Ethereum.
L’évolutivité est un autre défi. Les implémentations de clients légers varient en fonction de l’architecture de la chaîne, ce qui rend difficile la mise à l’échelle et la connexion de différents écosystèmes.
L’exploitation du code est un risque potentiel car les erreurs dans le code peuvent entraîner des vulnérabilités. Un exemple est la vulnérabilité de la chaîne BNB en octobre 2022, qui a révélé une vulnérabilité de sécurité critique affectant toutes les chaînes compatibles IBC[1].
Pour faire face au coût et à la praticité de l’exécution de paires de clients légers sur toutes les chaînes, des alternatives telles que les preuves à connaissance nulle (ZK) offrent un moyen d’éliminer le besoin de confiance dans un tiers.
La preuve à connaissance nulle comme solution à la confiance des tiers
Les preuves ZK peuvent être utilisées pour vérifier la validité des transitions d’état sur la chaîne source sur la chaîne cible. Au lieu d'effectuer l'intégralité du calcul sur la chaîne, il est préférable d'effectuer uniquement la vérification du calcul sur la chaîne, tandis que le processus de calcul réel est effectué hors chaîne. Cette approche peut être plus rapide et plus économe en énergie que la réexécution des calculs d’origine. Quelques exemples incluent Polymer ZK-IBC de Polymer Labs et Telepathy de Succinct Labs. Polymer développe un IBC avec prise en charge du multi-saut pour améliorer la connectivité et réduire le nombre de connexions par paires requises.
Les principaux aspects du mécanisme comprennent :
Sécurité
La sécurité des zk-SNARK repose sur des courbes elliptiques, tandis que les zk-STARK reposent sur des fonctions de hachage. Les zk-SNARK peuvent nécessiter un processus de configuration fiable où les clés initiales sont créées pour les preuves utilisées dans la vérification. Il est essentiel que la clé secrète qui détruit l’événement de configuration soit gardée secrète pour empêcher que des transactions soient effectuées via une vérification falsifiée. Une fois la configuration de confiance terminée, aucune autre hypothèse de confiance n’est introduite. De plus, les nouveaux frameworks ZK tels que Halo et Halo2 éliminent complètement le besoin d’une configuration de confiance.
accomplir
Il existe différents schémas de preuve ZK tels que SNARK, STARK, VPD et SNARG, SNARK étant le plus largement adopté actuellement. Différents frameworks de preuve SNARK, tels que Groth16, Plonk, Marlin, Halo et Halo2, présentent des compromis en termes de taille de preuve, de temps de preuve, de temps de vérification, d'exigences de mémoire et de nécessité d'une configuration fiable. Des preuves ZK récursives ont également émergé, permettant de répartir la charge de travail de preuve sur plusieurs ordinateurs au lieu d'un seul. Pour générer une preuve de validité, les primitives de base suivantes doivent être implémentées : vérifier le schéma de signature utilisé par le validateur, y compris la preuve de la clé publique du validateur dans l'engagement de l'ensemble de validateurs stocké sur la chaîne, et suivre l'ensemble de validateurs, qui peut changer fréquemment.
défi
La mise en œuvre de divers schémas de signature dans zkSNARK nécessite la mise en œuvre d’opérations arithmétiques hors domaine et de courbes elliptiques complexes, ce qui n’est pas trivial et peut nécessiter des implémentations différentes pour chaque chaîne en fonction du cadre et du consensus de la chaîne. L’audit des circuits ZK est une tâche difficile et sujette aux erreurs. Les développeurs doivent se familiariser avec les langages spécifiques au domaine comme Circom, Cairo et Noir, ou simplement implémenter les circuits eux-mêmes, ce qui peut être difficile et ralentir l'adoption. Cela peut conduire à une centralisation si le temps et la charge de travail s'avèrent très élevés, ce que seule une équipe dédiée avec du matériel spécialisé pourrait être en mesure de gérer. Des délais de génération de preuves plus longs peuvent également entraîner des retards. Des techniques comme le calcul incrémental vérifiable (IVC) peuvent améliorer les temps de preuve, mais nombre d’entre elles sont encore en phase de recherche, en attente de mise en œuvre. Des délais de vérification et des charges de travail plus longs augmenteront les coûts sur la chaîne.
La théorie du jeu de la confiance
Les protocoles d’interopérabilité basés sur la théorie des jeux peuvent être largement divisés en deux catégories en fonction de la manière dont ils encouragent un comportement honnête parmi les entités participantes :
Le premier est la sécurité économique, où plusieurs acteurs externes (tels que les validateurs) collaborent pour parvenir à un consensus sur l’état mis à jour de la chaîne source. Pour devenir validateur, les participants doivent miser un certain nombre de jetons, qui peuvent être réduits en cas d'activité malveillante. Dans un environnement sans autorisation, n’importe qui peut accumuler une participation et devenir validateur. De plus, des incitations financières sont fournies aux validateurs pour qu'ils suivent le protocole sous la forme de récompenses globales, garantissant des incitations financières pour un comportement honnête. Toutefois, si le montant potentiellement volable dépasse le montant mis en jeu, les participants peuvent s’entendre pour voler des fonds. Axelar et Celer IM sont des exemples de protocoles utilisant des mécanismes de sécurité économique.
La deuxième catégorie est celle de la sécurité optimiste, où la solution repose sur l’hypothèse que seule une minorité des participants à la blockchain sont honnêtes et suivent les règles du protocole. Dans cette approche, un seul participant honnête peut servir de garantie. Par exemple, une solution optimale permettrait à n’importe qui de soumettre des preuves de fraude. Bien qu’il existe une incitation financière, les observateurs honnêtes peuvent passer à côté de transactions frauduleuses. Optimistic Roll-up adopte également ce mécanisme. Nomad et ChainLink CCIP sont des exemples de protocoles qui utilisent une sécurité optimiste. Dans le cas de Nomad, les observateurs ont pu prouver une fraude malgré leur statut de liste blanche au moment de la rédaction du présent rapport. ChainLink CCIP prévoit d'utiliser un réseau anti-fraude composé d'un réseau oracle décentralisé pour surveiller les activités malveillantes, bien que la mise en œuvre du réseau anti-fraude de CCIP reste encore à déterminer.
Sécurité
En termes de sécurité, les deux mécanismes s'appuient sur la participation sans autorisation des validateurs et des observateurs pour garantir la validité de la théorie des jeux. Dans un mécanisme de sécurité économique, si le montant mis en jeu est inférieur au montant potentiellement volable, les fonds sont plus vulnérables aux attaques. En revanche, dans les mécanismes de sécurité optimistes, l’hypothèse de confiance minoritaire peut être exploitable si personne ne soumet de preuves de fraude ou si l’observateur d’autorité est compromis ou supprimé. En revanche, les mécanismes de sécurité économique dépendent moins de la vivacité pour maintenir la sécurité.
Mise en œuvre
En termes de mise en œuvre, une approche implique une chaîne intermédiaire avec ses propres validateurs. Dans cette configuration, un groupe de validateurs externes surveille la chaîne source et parvient à un consensus sur la validité des transactions lorsqu'un appel est détecté. Une fois le consensus atteint, ils fournissent des preuves sur la chaîne cible. Les validateurs sont généralement tenus de miser une certaine quantité de jetons et peuvent être réduits si une activité malveillante est détectée. Les exemples de protocoles utilisant cette implémentation incluent Axelar Network et Celer IM.
Une autre méthode de mise en œuvre consiste à utiliser un proxy hors chaîne. Les proxys hors chaîne sont utilisés pour mettre en œuvre des solutions similaires aux roll-ups optimistes. Dans une fenêtre de temps prédéfinie, ces proxys hors chaîne sont autorisés à soumettre des preuves de fraude et à annuler des transactions si nécessaire. Par exemple, Nomad s'appuie sur des proxys hors chaîne indépendants pour relayer les en-têtes et les preuves cryptographiques. D’autre part, ChainLink CCIP prévoit d’exploiter son réseau oracle existant pour surveiller et prouver les transactions inter-chaînes.
Avantages et défis
L’un des principaux avantages des AMP basés sur la théorie des jeux est l’optimisation des ressources, car le processus de vérification ne se produit généralement pas sur la chaîne, ce qui réduit les besoins en ressources. De plus, ces mécanismes sont évolutifs puisque le mécanisme de consensus reste le même pour différents types de chaînes et peut être facilement étendu aux blockchains hétérogènes.
Ces mécanismes sont également confrontés à certains défis. Si une majorité de validateurs s’entendent, l’hypothèse de confiance peut être exploitée pour voler des fonds, ce qui nécessite l’utilisation de contre-mesures telles que le vote quadratique et les preuves de fraude. De plus, les solutions basées sur la sécurité optimiste introduisent une complexité en termes de finalité et de vivacité, car les utilisateurs et les applications doivent attendre une fenêtre de fraude pour garantir la validité des transactions.
La confiance dans les humains
Les solutions qui nécessitent la confiance dans une entité humaine peuvent également être largement divisées en deux catégories :
1. Sécurité de la réputation : ces solutions reposent sur des implémentations multi-signatures où plusieurs entités vérifient et signent les transactions. Une fois le seuil minimum atteint, la transaction est considérée comme valide. L’hypothèse ici est que la majorité des entités sont honnêtes, et si la majorité de ces entités signent une transaction particulière, alors celle-ci est valide. Quelques exemples incluent Multichain (Anycall V6) et Wormhole. Les vulnérabilités des contrats intelligents peuvent toujours être exploitées, comme l’a démontré le piratage de Wormhole début 2022.
2. Indépendance : ces solutions divisent l’ensemble du processus de messagerie en deux parties et s’appuient sur différentes entités indépendantes pour gérer les deux processus. L’hypothèse ici est que les deux entités sont indépendantes l’une de l’autre et ne s’entendront pas. LayerZero en est un exemple. Les en-têtes de bloc peuvent être transmis à la demande par des oracles décentralisés, et les preuves de transaction sont envoyées via des relais. Si la preuve correspond à l'en-tête du bloc, la transaction est considérée comme valide. Bien que la preuve d’une correspondance repose sur le code et les mathématiques, les participants doivent avoir confiance dans le fait que ces entités restent indépendantes. Les applications construites sur LayerZero peuvent choisir leurs oracles et relais (ou héberger leurs propres oracles/relais), limitant ainsi le risque de collusion entre oracles/relais individuels. Les utilisateurs finaux doivent avoir confiance que LayerZero, des tiers ou l’application elle-même exploitent l’oracle et le relais de manière indépendante et sans intention malveillante.
Dans les deux approches, la réputation des entités tierces participantes réduit l’incitation à agir de manière malveillante. Il s’agit souvent d’entités très respectées au sein des communautés de validateurs et d’oracles et elles sont confrontées à des conséquences sur leur réputation et à des impacts négatifs sur leurs autres activités commerciales si elles se comportent de manière malveillante.
Au-delà de l'hypothèse de confiance : considérations supplémentaires pour les solutions AMP
Lorsque nous considérons la sécurité et la convivialité d’une solution AMP, nous devons également prendre en compte des détails au-delà des mécanismes de base. Comme il s’agit de pièces mobiles qui peuvent changer au fil du temps, nous ne les avons pas incluses dans la comparaison globale.
Intégrité du code
Les piratages récents ont exploité des erreurs de codage, soulignant la nécessité d'un audit fiable, de primes aux bugs et d'implémentations client diversifiées. Si tous les validateurs (en matière de sécurité économique/optimiste/réputationnelle) exécutent le même client (logiciel utilisé pour la validation), cela augmentera la dépendance à une seule base de code et réduira la diversité des clients. Par exemple, Ethereum s'appuie sur plusieurs clients d'exécution tels que geth, nethermind, erigon, besu, akula. Des implémentations multiples dans plusieurs langues pourraient augmenter la diversité sans qu'aucun client ne domine le réseau, éliminant ainsi les points de défaillance uniques potentiels. Avoir plusieurs clients peut également aider à améliorer la vivacité, si quelques validateurs/signataires/clients légers tombent en panne en raison d'un bug/d'une attaque dans une implémentation particulière, d'autres clients sont toujours disponibles.
Installation et évolutivité
Les utilisateurs et les développeurs doivent comprendre si les validateurs/observateurs peuvent rejoindre le réseau sans autorisation, sinon la confiance sera masquée par les entités autorisées choisies. Les mises à niveau des contrats intelligents peuvent également introduire des bugs susceptibles de conduire à des attaques ou même de 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, la passerelle Axelar peut être mise à niveau en fonction de l’approbation du comité hors ligne (seuil 4/8), cependant, Axelar prévoit dans un avenir proche d’exiger que tous les validateurs approuvent collectivement toute mise à niveau de la passerelle. Les contrats de base de Wormhole sont évolutifs et gérés via le système de gouvernance en chaîne de Wormhole. LayerZero s'appuie sur des contrats intelligents immuables et des bibliothèques immuables pour éviter toute mise à niveau, mais de nouvelles bibliothèques peuvent être déployées et les dApps utilisant les paramètres par défaut obtiendront la version mise à jour, et les dApps qui définissent manuellement la version devront la définir sur la nouvelle version.
Valeur maximale extractible (VME)
Différentes blockchains sont synchronisées via une horloge commune et ont des temps de finalité différents. Par conséquent, l’ordre d’exécution et le timing sur la chaîne cible peuvent varier d’une chaîne à l’autre. Dans le monde inter-chaînes, une définition claire de MEV est un défi. Il introduit un compromis entre la vivacité et l’ordre d’exécution. Un canal ordonné assurera la livraison ordonnée des messages, mais si un message expire, le canal sera fermé. Une autre application pourrait préférer éliminer le besoin de commande, mais sans impacter la livraison d'autres messages.
Finalité de la chaîne source
Idéalement, une solution AMP doit attendre qu’une chaîne source atteigne son stade final avant de transférer les informations d’état de la chaîne source vers une ou plusieurs chaînes cibles. Cela garantira que les blocs de la chaîne source sont pratiquement impossibles à inverser ou à modifier. Cependant, pour offrir la meilleure expérience utilisateur, de nombreuses solutions proposent une messagerie instantanée et font des hypothèses de confiance sur la finalité. Dans ce cas, si la chaîne source revient en arrière après la livraison du message et le pontage des fonds, une double dépense de fonds peut se produire. Les solutions AMP peuvent gérer ce risque de diverses manières, par exemple en utilisant différentes hypothèses de finalité pour différentes chaînes, en évaluant la vitesse et la sécurité en fonction du niveau de décentralisation de la chaîne. Les ponts exploitant la solution AMP peuvent définir des limites sur le nombre d'actifs qui peuvent être pontés avant que la chaîne source n'atteigne son stade final.
Tendances et perspectives d'avenir
Personnalisable et sécurité renforcée
Pour mieux répondre aux différents cas d’utilisation, les solutions AMP sont encouragées à offrir davantage de flexibilité de développement. Axelar introduit une méthode permettant d'évoluer la messagerie et l'authentification sans modifier la logique de la couche applicative. HyperLane V2 introduit des modules qui permettent aux développeurs de choisir parmi plusieurs options, notamment la sécurité économique, la sécurité optimiste, la sécurité dynamique et la sécurité hybride. En plus de la sécurité économique, CelerIM offre également une sécurité optimiste supplémentaire. De nombreuses solutions attendent un nombre minimum prédéfini de confirmations de blocs sur la chaîne source avant de transmettre un message. LayerZero permet aux développeurs de mettre à jour ces paramètres. Nous nous attendons à ce que certaines solutions AMP continuent d’offrir davantage de flexibilité, mais ces choix de conception nécessitent une certaine discussion. L'application peut-elle configurer sa sécurité, dans quelle mesure et que se passe-t-il si l'application est conçue avec une conception sous-optimale ? La sensibilisation des utilisateurs aux concepts de base de la sécurité peut devenir de plus en plus importante. À terme, nous prévoyons l’agrégation et l’abstraction des solutions AMP, peut-être sous une forme de sécurité combinée ou « ajoutée ».
La maturité du mécanisme de « confiance dans le code et les mathématiques »
Dans l’objectif final idéal, tous les messages inter-chaînes minimiseront la confiance grâce à l’utilisation de preuves à connaissance nulle. Nous voyons déjà ce changement émerger avec des projets comme Polymer Labs et Succinct Labs. Multichain a également publié un livre blanc appelé zkRouter, qui permet l'interopérabilité via les preuves ZK. Avec la machine virtuelle Axelar récemment annoncée, les développeurs peuvent exploiter l'amplificateur interchaîne pour établir sans autorisation de nouvelles connexions au réseau Axelar. Par exemple, une fois que des clients légers robustes et des preuves ZK de l’état d’Ethereum sont développés, les développeurs peuvent facilement les intégrer au réseau Axelar pour remplacer ou améliorer les connexions existantes. Celer Network a annoncé une plate-forme de preuve de données inter-chaînes ZK appelée Brevis, permettant aux dApps et aux contrats intelligents d'accéder, de calculer et d'utiliser des données arbitraires sur plusieurs blockchains. Celer utilise des circuits clients légers ZK pour implémenter un actif visible par l'utilisateur zkBridge pour relier les réseaux de test Ethereum Goerli et BNB Chain. LayerZero parle dans sa documentation de la possibilité d'ajouter de nouvelles bibliothèques de messages de preuve optimisées à l'avenir. De nouveaux projets comme Lagrange explorent la possibilité d'agréger plusieurs preuves provenant de plusieurs chaînes sources, tandis qu'Hérodote rend possible la preuve de stockage via des preuves ZK. Toutefois, cette transition prendra du temps car cette approche est difficile à mettre en œuvre sur des blockchains qui reposent sur des mécanismes et des cadres de consensus différents.
Le ZK est une technologie relativement nouvelle et complexe, difficile à auditer, et les coûts actuels de vérification et de génération de preuves sont sous-optimaux. Nous pensons qu'à long terme, afin de prendre en charge des applications inter-chaînes hautement évolutives sur les blockchains, de nombreuses solutions AMP combineront probablement des entités humaines de confiance avec des logiciels vérifiables pour les raisons suivantes :
1. Grâce à l’audit et aux primes aux bugs, la possibilité d’exploitation du code peut être minimisée. Au fil du temps, leur historique servant de preuve de sécurité, il deviendra plus facile de faire confiance à ces systèmes.
2. Le coût de génération des preuves ZK sera réduit. Avec davantage de R&D sur les ZKP, les ZK récursifs, l'agrégation de preuves, les schémas de pliage et le matériel spécialisé, nous prévoyons que le temps et le coût de la génération et de la vérification des preuves diminueront considérablement, ce qui en fera une approche plus rentable.
3. La blockchain sera plus compatible avec ZK. À l’avenir, le zkEVM sera en mesure de fournir des preuves succinctes de la validité de l’exécution, et les solutions client légères pourront facilement vérifier l’exécution et le consensus de la chaîne source. Dans la phase finale d’Ethereum, il est prévu de « tout convertir en zk-SNARK », y compris le consensus.
L'humain, la réputation et l'identité
La sécurité d’un système complexe comme la solution AMP ne peut pas être encapsulée par un seul framework et nécessite une solution multicouche. Par exemple, en plus des incitations économiques, Axelar met également en œuvre un mécanisme de vote quadratique pour empêcher la concentration du pouvoir de vote dans un sous-ensemble de nœuds et promouvoir la décentralisation. D’autres preuves humaines, de réputation et d’identité peuvent également compléter les mécanismes de paramétrage et d’autorisations.
en conclusion
En s’appuyant sur l’esprit ouvert du Web3, nous pourrions voir un avenir où plusieurs approches coexister. En pratique, les applications peuvent choisir d’utiliser plusieurs solutions d’interopérabilité, soit de manière redondante, soit pour permettre aux utilisateurs de les combiner avec des compromis. Les solutions point à point peuvent être prioritaires entre les itinéraires « à fort trafic », tandis que les modèles en étoile peuvent dominer dans la longue queue de la chaîne. En fin de compte, c’est à nous, en tant que communauté d’utilisateurs, de créateurs et de contributeurs, de façonner le paysage d’un Web3 interconnecté.
Références
https://forum.cosmos.network/t/ibc-security-advisory-dragonberry/7702 
https://polymerlabs.medium.com/the-multi-hop-ibc-upgrade-will-take-ibc-to-ethereum-and-beyond-b4bee43523e 
https://cointelegraph.com/news/wormhole-hack-illustrates-danger-of-defi-cross-chain-bridges 
https://axelar.network/blog/future-proof-interop-path-adaptability-for-cross-chain-dapps 
https://ethresear.ch/t/hashi-a-principled-approach-to-bridges/14725 
https://twitter.com/MultichainOrg/status/1613830754458533888?s=20&t=MoDGESqOdcjMQDMFQqzTyQ
https://axelar.network/blog/axelar-virtual-machine-future-of-interoperability 
https://twitter.com/CelerNetwork/status/1638330932603109379?s=20
https://axelar.network/blog/axelar-implements-quadratic-voting-with-maeve-upgrade  