La multi-chaîne est la future tendance de développement, et la recherche de l'évolutivité a conduit Ethereum à la construction de la technologie Rollup. Dans le passage aux blockchains modulaires, l'attention a de nouveau été portée sur Lisk. Et dans un avenir pas trop lointain, nous entendrons des rumeurs sur des rollups, des L3 et des chaînes souveraines spécifiques à une application. Mais tout cela se fera au prix de la fragmentation, et les ponts inter-chaînes actuels ont souvent des fonctionnalités limitées et reposent sur des signataires de confiance pour la sécurité.
Alors, à quoi ressemblera finalement le Web3 connecté ? Nous pensons que les ponts inter-chaînes évolueront éventuellement vers des protocoles de messagerie inter-chaînes ou de « messagerie arbitraire » (AMP) pour débloquer de nouveaux scénarios d'application, permettant aux applications de transmettre des messages arbitraires entre la chaîne source et la chaîne cible. Nous assisterons également à l'émergence d'un "paysage de mécanismes de confiance", où les constructeurs feront divers compromis entre convivialité, complexité et sécurité.
Chaque solution AMP doit implémenter deux fonctions clés :
Vérification : Possibilité de vérifier la validité des messages de la chaîne source sur la chaîne cible
Liveness : la capacité à transmettre des informations de la chaîne source à la chaîne cible
Malheureusement, une vérification sans confiance à 100 % n'est pas réaliste, les utilisateurs doivent choisir de faire confiance au code, à la théorie des jeux, aux humains (ou entités) ou à une combinaison de ceux-ci, selon que la vérification est en chaîne ou hors chaîne.
Dans cet article, nous divisons verticalement le domaine global de l'interopérabilité en mécanismes basés sur la confiance et en architectures basées sur l'intégration.
Mécanisme de confiance :
Faites confiance au code et aux mathématiques : pour ces solutions, il existe une preuve en chaîne que tout le monde peut vérifier. 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 vérifier la validité de la transition d'état de la chaîne source sur la chaîne cible. La vérification via des clients légers peut améliorer l'efficacité grâce à des preuves à connaissance nulle, en compressant des calculs arbitrairement longs à effectuer hors ligne, tout en fournissant une simple vérification en chaîne pour prouver les résultats des calculs.
Trust Game Theory : lorsqu'un utilisateur/une application doit faire confiance à un tiers ou à un réseau tiers pour garantir l'authenticité d'une transaction, des hypothèses de confiance supplémentaires sont impliquées. La sécurité de ces mécanismes peut être améliorée en utilisant des réseaux sans autorisation et la théorie des jeux tels que les incitations économiques et la sécurité optimiste.
Confiance en l'humain : Ces solutions reposent sur l'honnêteté ou l'indépendance d'une majorité de validateurs, qui communiquent différentes informations. En plus de faire confiance au consensus des deux chaînes interactives, vous devez également faire confiance à un tiers. Dans ce cas, le seul risque est la réputation des entités participantes. Une transaction est considérée comme valide si suffisamment d'entités participantes conviennent qu'elle est valide.
Il convient de noter que toutes les solutions nécessitent une certaine confiance dans le code et les humains dans une certaine mesure. Toute solution avec un code bogué peut être exploitée par des pirates, et chaque solution comporte un élément humain dans la configuration, les mises à niveau ou la maintenance de la base de code.
Architecture intégrée :
Modèle point à point : Un canal de communication dédié doit être établi entre chaque chaîne source et chaîne cible.
Modèle de hub central : Un canal de communication avec le hub central doit être établi pour réaliser l'interconnexion avec 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 couplé. Le développement de ces canaux peut être difficile pour les blockchains avec des consensus et des cadres différents. Cependant, les ponts jumelés offrent plus de flexibilité pour personnaliser la configuration si vous le souhaitez. Des approches hybrides sont également possibles, telles que le routage multi-sauts via des relais utilisant le protocole Inter-Blockchain Communication (IBC), qui supprime le besoin d'une communication directe d'égal à égal, mais introduit plus de complexités en termes de sécurité, de latence et de coût.
Code de confiance et mathématiques
Afin de ne s'appuyer que sur le code/les mathématiques pour les hypothèses de confiance, des clients légers peuvent être utilisés pour vérifier le consensus de la chaîne source sur la chaîne cible. Les clients/nœuds légers sont des logiciels qui se connectent à des nœuds complets pour interagir avec la blockchain. Les clients légers sur la chaîne cible stockent généralement un historique (dans l'ordre) des en-têtes de bloc de la chaîne source, ce qui est suffisant pour vérifier les transactions. Un proxy hors chaîne (tel qu'un relais) surveille les événements sur la chaîne source, génère des preuves cryptographiques d'inclusion et les transmet avec des 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 de manière séquentielle, chacun contenant un hachage racine Merkle pouvant être utilisé pour prouver l'état, ils sont en mesure de vérifier les transactions. Voici un aperçu des principales caractéristiques de cette approche :
sécurité
Des hypothèses de confiance sont introduites lors de l'initialisation des clients légers. Lors de la création d'un nouveau client léger, il sera initialisé à un en-tête de bloc à partir d'une hauteur spécifique sur l'autre chaîne. Cependant, il est possible que les en-têtes de bloc fournis soient incorrects, ce qui permet de tromper les clients légers avec des en-têtes de bloc falsifiés. Une fois qu'un client léger est initialisé, aucune autre hypothèse de confiance n'est introduite. Cependant, il convient de noter que ce processus d'initialisation repose sur une hypothèse de confiance faible, car il peut être vérifié par n'importe qui. De plus, il existe une hypothèse de vivacité pour la transmission continue d'informations par le relais.
mettre en œuvre
L'implémentation des clients légers dépend de la disponibilité des primitives cryptographiques nécessaires à l'authentification. Si le même type de chaînes est connecté, c'est-à-dire qu'elles partagent le même cadre d'application et le même algorithme de consensus, les implémentations du client léger aux deux extrémités seront les mêmes. Par exemple, toutes les chaînes basées sur Cosmos SDK utilisent le protocole Inter-Blockchain Communication (IBC). D'autre part, les implémentations telles que les clients légers dépendent de la prise en charge des primitives cryptographiques nécessaires à l'authentification. Si le même type de chaînes sont connectées, c'est-à-dire qu'elles partagent le même cadre d'application et le même algorithme de consensus, les implémentations du client léger des deux côtés seront les mêmes. Par exemple, le protocole Inter-Blockchain Communication (IBC) est utilisé pour toutes les chaînes basées sur le SDK Cosmos. D'autre part, si deux types de chaînes différents sont connectés, tels que des cadres 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 sur la connexion de la chaîne Cosmos SDK au cadre d'application Substrate de l'écosystème Polkadot via IBC. Cela nécessite un client léger Tendermint sur la chaîne Substrate et un client léger "costaud" 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 est un défi important. Exécuter des paires de clients légers sur toutes les chaînes peut être coûteux car les écritures sur la blockchain sont coûteuses. De plus, l'intensité des ressources avec des vérificateurs dynamiques est un défi important. Il peut être coûteux d'exécuter des clients légers jumelés sur toutes les chaînes, car les écritures sur la blockchain sont coûteuses. De plus, pour les chaînes avec des ensembles de validateurs dynamiques (comme Ethereum), il n'est pas possible d'exécuter des clients légers.
L'évolutivité est un autre défi. La mise en œuvre des clients légers varie selon l'architecture de la chaîne, ce qui rend difficile la mise à l'échelle et la connexion de différents écosystèmes.
Les vulnérabilités du code sont un risque potentiel car les bogues dans le code peuvent entraîner des vulnérabilités. Par exemple, la violation de la chaîne BNB d'octobre 2022 a révélé une faille de sécurité critique affectant toutes les chaînes compatibles IBC.
Pour répondre au coût et à l'aspect pratique de l'exécution de clients légers par paires sur toutes les chaînes, des solutions alternatives telles que les preuves à connaissance nulle (ZK) peuvent être utilisées pour supprimer le besoin de confiance de tiers.
Les preuves à connaissance nulle comme solution pour la confiance des tiers
Les preuves à connaissance nulle peuvent être utilisées pour vérifier la validité des transitions d'état de la chaîne source sur la chaîne cible. Par rapport à l'exécution de l'intégralité du calcul en chaîne, les preuves ZK n'effectuent que la partie vérification du calcul en chaîne, tandis que le calcul réel se produit hors chaîne. Cette approche permet une vérification plus rapide et plus efficace que la réexécution du calcul d'origine. Certains exemples incluent Polymer Labs ; Polymer ZK-IBC ; et Succinct Labs ; Telepathy. Polymer développe des IBC multi-sauts pour améliorer la connectivité et réduire le nombre de connexions appariées nécessaires.
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 une configuration de confiance, y compris la création de clés initiales utilisées pour générer des preuves utilisées dans la vérification. La clé est de détruire le secret de l'événement de configuration pour empêcher les transactions d'être authentifiées par falsification. Une fois la configuration de confiance terminée, aucune autre hypothèse de confiance n'est introduite. De plus, les nouveaux frameworks ZK (comme Halo et Halo;2;) suppriment complètement le besoin d'une configuration de confiance.
mettre en œuvre
Il existe une variété de schémas de preuve ZK, tels que SNARK, STARK, VPD et SNARG, et SNARK est actuellement le plus largement utilisé. Différents frameworks de preuve SNARK, tels que Groth;16, Plonk, Marlin, Halo et Halo;2;, offrent des compromis en termes de taille de preuve, de temps de preuve, de temps de vérification, d'exigences de mémoire et d'exigences de configuration de confiance. Des preuves ZK récursives ont également émergé, permettant à la charge de travail de preuve d'être répartie sur plusieurs ordinateurs plutôt que sur un seul. Afin de générer des preuves de validité, les primitives de base suivantes doivent être implémentées : vérification du schéma de signature utilisé par un validateur, stockage des preuves de la clé publique du validateur dans l'engagement d'ensemble de validateur stocké en chaîne, et suivi de l'ensemble de validateur, qui peut changer fréquemment.
défi
L'implémentation de divers schémas de signature dans zkSNARK nécessite l'implémentation d'opérations arithmétiques hors domaine et de courbes elliptiques complexes, ce qui n'est pas trivial et peut nécessiter différentes implémentations en fonction du cadre et du consensus des différentes chaînes. 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 à un domaine tels que Circom, Cairo et Noir, ou implémenter des circuits directement, ce qui peut être difficile et ralentir l'adoption. Si le temps et les efforts s'avèrent très importants, ils ne peuvent être gérés que par des équipes dédiées et du matériel dédié, ce qui peut conduire à une centralisation. Des temps de génération de preuve plus longs entraînent également des retards. Des techniques telles que le calcul incrémental vérifiable (IVC) peuvent optimiser les temps de preuve, mais nombre d'entre elles sont encore en phase de recherche, en attente de mise en œuvre. Des temps de vérification et des charges de travail plus longs augmenteront les coûts en chaîne.
Théorie des jeux de confiance
Les protocoles d'interopérabilité basés sur la théorie des jeux peuvent être globalement divisés en deux catégories, selon la manière dont ils incitent à un comportement honnête des entités participantes :
La première catégorie est un mécanisme de sécurité économique dans lequel plusieurs acteurs externes (tels que des validateurs) coopèrent pour parvenir à un consensus afin de déterminer l'état mis à jour de la chaîne source. Pour devenir validateur, les participants doivent miser un certain nombre de jetons, qui peut être réduit en cas d'activité malveillante. Dans une configuration sans autorisation, n'importe qui peut accumuler des mises et devenir un validateur. En outre, des incitations économiques telles que des récompenses globales sont fournies aux validateurs qui suivent le protocole pour garantir des incitations économiques pour un comportement honnête. Cependant, si le montant potentiellement volé dépasse le montant misé, les participants peuvent s'entendre pour voler des fonds. Des exemples de protocoles qui utilisent des mécanismes de sécurité économiques incluent Axelar et Celer IM.
La deuxième catégorie est celle des mécanismes de sécurité optimistes, où la solution repose sur l'hypothèse que seul un petit nombre de participants à la blockchain sont honnêtes et obéissent aux règles du protocole. Dans cette approche, un participant honnête agit comme une garantie. Par exemple, une solution optimale permet à quiconque de soumettre des preuves de fraude. Bien qu'il existe une incitation financière, un observateur honnête peut manquer une transaction frauduleuse. Les cumuls optimistes utilisent également ce mécanisme. Nomad et ChainLink CCIP sont des exemples de protocoles qui utilisent des mécanismes de sécurité optimistes. Dans le cas de Nomad, les observateurs ont pu prouver la fraude, bien qu'ils soient sur liste blanche au moment de la rédaction. ChainLink CCIP prévoit d'utiliser un réseau anti-fraude composé d'un réseau distribué d'oracles pour détecter les activités malveillantes, bien que la mise en œuvre du réseau anti-fraude de CCIP soit inconnue.
sécurité
En termes de sécurité, les deux mécanismes reposent sur la participation sans autorisation des vérificateurs et des observateurs pour garantir la validité de la théorie des jeux. Dans un mécanisme de sécurité économique, les fonds sont plus vulnérables si le montant misé est inférieur au montant qui pourrait être volé. D'autre part, dans les mécanismes de sécurité optimistes, l'hypothèse de confiance minoritaire peut être exploitée si personne ne soumet de preuve de fraude, ou si les observateurs d'autorisation sont compromis ou supprimés. En revanche, les mécanismes de sécurité économique dépendent moins de la vivacité pour maintenir la sécurité.
mettre 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é d'une transaction lorsqu'une invocation est détectée. Une fois le consensus atteint, ils fournissent des preuves sur la chaîne cible. Les validateurs sont généralement tenus de miser un certain nombre de jetons, qui peut être réduit si une activité malveillante est détectée. Des exemples de protocoles qui utilisent cette méthode de mise en œuvre incluent Axelar Network et Celer IM.
Une autre méthode de mise en œuvre implique l'utilisation de proxys hors chaîne. Des proxys hors chaîne sont utilisés pour mettre en œuvre des solutions optimistes de type Rollups. Dans une fenêtre de temps prédéfinie, ces mandataires hors chaîne peuvent 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 de tirer parti de son réseau existant d'oracles pour surveiller et attester les transactions inter-chaînes.
Forces et défis
Un avantage clé des solutions AMP basées sur la théorie des jeux est l'optimisation des ressources, car le processus de vérification est généralement hors chaîne, ce qui réduit les besoins en ressources. De plus, ces mécanismes sont évolutifs car le mécanisme de consensus reste le même pour différents types de chaînes et peut être facilement étendu à des blockchains hétérogènes.
Plusieurs défis sont également associés à ces mécanismes. Si une majorité de validateurs s'entendent, les hypothèses de confiance peuvent être exploitées pour voler des fonds, nécessitant des contre-mesures telles que le vote quadratique et les preuves de fraude. De plus, les solutions basées sur la sécurité optimiste introduisent des complexités en termes de finalité et de vivacité, car les utilisateurs et les applications doivent attendre des fenêtres frauduleuses pour garantir la validité des transactions.
Faites confiance aux humains
Les solutions nécessitant la confiance dans les entités humaines peuvent également être divisées en deux grandes catégories :
Sécurité de 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 plupart des entités sont honnêtes, et si la majorité de ces entités signent une transaction particulière, alors cette transaction est valide. La seule chose en danger ici est la réputation des entités impliquées. Quelques exemples incluent; Multichain (Anycall V;6;) et Wormhole. Des vulnérabilités peuvent toujours exister en raison de vulnérabilités de contrats intelligents, comme l'a démontré le piratage de Wormhole au début de 2022.
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 ces deux entités sont indépendantes l'une de l'autre et ne peuvent pas s'entendre. LayerZero en est un exemple. Les en-têtes de bloc sont transmis à la demande via des oracles distribués et les preuves de transaction sont envoyées via des relais. Si la preuve correspond à l'en-tête, la transaction est considérée comme valide. Bien que la preuve d'une correspondance repose sur le code/les mathématiques, les participants doivent être sûrs que ces entités restent indépendantes et n'ont aucune intention malveillante. Les applications construites sur ;LayerZero; peuvent choisir leurs oracles et relais (ou héberger leurs propres oracles/relais), limitant ainsi les risques pour les oracles/relais individuels. Les utilisateurs finaux doivent être sûrs que LayerZero, des tiers ou l'application elle-même exécutent des oracles et des relais indépendamment, sans intention malveillante.
Dans les deux approches, la réputation des entités tierces participantes dissuade les comportements malveillants. Ce sont généralement des entités très respectées dans la communauté des validateurs et des oracles, et s'ils se comportent de manière malveillante, ils risquent de nuire à leur réputation et d'avoir un impact négatif sur d'autres activités commerciales.
Considérations supplémentaires pour les solutions AMP
Lors de l'examen de la sécurité et de 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 composants qui peuvent évoluer dans le temps, nous ne les avons pas inclus dans la comparaison globale.
intégrité du code
Des hacks récents ont exploité des erreurs de code, soulignant la nécessité d'un audit robuste, de primes de bogues et de diverses implémentations de clients. Si tous les vérificateurs (en sécurité économique/optimiste/réputationnelle) exécutent le même client (logiciel de vérification), cela augmente la dépendance à une seule base de code et réduit la diversité des clients. Par exemple, Ethereum s'appuie sur plusieurs clients d'exécution tels que geth, netermind, erigon, besu, akula. Plusieurs implémentations dans différentes langues peuvent augmenter la diversité, aucun client ne dominant le réseau, éliminant ainsi un point de défaillance unique potentiel. Avoir plusieurs clients peut également aider à maintenir la vivacité au cas où un petit nombre de validateurs/signataires/clients légers échoueraient en raison d'un bogue/d'une attaque dans une implémentation particulière.
Configuration et évolutivité
Les utilisateurs et les développeurs doivent savoir si les validateurs/observateurs peuvent rejoindre le réseau sans autorisation, sinon la confiance sera masquée par les entités qui choisissent l'autorisation. Les mises à niveau des contrats intelligents peuvent également introduire des vulnérabilités pouvant conduire à des attaques et éventuellement même modifier les hypothèses de confiance. Différentes solutions peuvent être mises en place pour atténuer ces risques. Par exemple, dans l'instanciation actuelle, la passerelle Axelar peut être mise à niveau mais nécessite l'approbation du comité hors ligne (seuil 4/8), cependant, dans un avenir proche, Axelar prévoit d'exiger que tous les validateurs approuvent collectivement toute mise à niveau de la passerelle. Les principaux contrats 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 poussées, les dapps qui définissent les paramètres par défaut obtiendront des versions plus récentes, les dapps qui définissent manuellement la version doivent la définir sur la nouvelle version.
Valeur Maximale Extractible (MEV)
Différentes blockchains ne sont pas synchronisées par une horloge commune et ont des temps de finalité différents. Par conséquent, l'ordre d'exécution et la synchronisation sur la chaîne cible peuvent varier d'une chaîne à l'autre. Dans un monde inter-chaînes, le MEV est difficile à définir clairement. Il introduit un compromis entre la vivacité et l'ordre d'exécution. Un canal ordonné assurera la livraison dans l'ordre des messages, mais si un message expire, le canal sera fermé. Une autre application peut préférer qu'il n'y ait pas de classement, mais la remise d'autres messages n'est pas affectée.
certitude de la chaîne source
Idéalement, les solutions AMP devraient attendre que la chaîne source atteigne la finalité avant de transmettre les informations d'état de la chaîne source à une ou plusieurs chaînes cibles. Cela garantira que les blocs de la chaîne source peuvent difficilement être inversés ou modifiés. Cependant, de nombreuses solutions fournissent une messagerie instantanée et font des hypothèses de confiance sur la finalité afin de fournir la meilleure expérience utilisateur. Dans ce cas, si la chaîne source subit une annulation d'état après la livraison du message et le passage de l'actif de pont, cela peut conduire à des situations telles que la double dépense des fonds de pont. Les solutions AMP peuvent gérer ce risque de plusieurs manières, par exemple en définissant différentes hypothèses de finalité pour différentes chaînes en fonction de la décentralisation de la chaîne, ou en faisant des compromis entre vitesse et sécurité. Les ponts utilisant des solutions AMP peuvent fixer des limites sur la quantité d'actifs pontés avant que la chaîne source n'atteigne la finalité.
Tendances et perspectives d'avenir Sécurité personnalisable et attachable
Pour mieux servir divers cas d'utilisation, les solutions AMP sont incitées à offrir plus de flexibilité aux développeurs. Axelar introduit une méthode permettant l'évolutivité de la messagerie et de la validation sans modifier la logique de la couche application. HyperLane V2 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 en plus de la sécurité économique. De nombreuses solutions attendent un nombre minimum prédéfini de confirmations de bloc sur la chaîne source avant de délivrer un message. LayerZero permet aux développeurs de mettre à jour ces paramètres. Nous nous attendons à ce que certaines solutions AMP continuent d'offrir plus de flexibilité, mais ces choix de conception nécessitent quelques discussions. Les applications doivent-elles pouvoir configurer leur sécurité, dans quelle mesure et que se passe-t-il si les applications sont architecturées avec une conception sous-optimale ? La sensibilisation des utilisateurs aux concepts fondamentaux de la sécurité est susceptible de devenir de plus en plus importante. En fin de compte, nous prévoyons l'agrégation et l'abstraction des solutions AMP, éventuellement sous la forme d'une certaine forme de composition ou de sécurité "complémentaire".
La maturité du mécanisme « Trust Code and Math »
Dans une phase finale idéale, tous les messages inter-chaînes seront minimisés en termes de confiance grâce à l'utilisation de preuves à connaissance nulle (ZK). Nous avons vu des projets similaires comme Polymer Labs et Succinct Labs émerger. Multichain a également publié un livre blanc zkRouter sur l'interopérabilité via les preuves ZK. Avec la machine virtuelle Axelar récemment annoncée, les développeurs peuvent tirer parti de l'amplificateur Interchain pour établir de nouvelles connexions au réseau Axelar sans autorisation. Par exemple, une fois que des clients légers puissants et des preuves ZK sont développés pour l'état d'Ethereum, les développeurs peuvent facilement les intégrer dans le réseau Axelar pour remplacer ou améliorer les connexions existantes. Celer Network a annoncé Brevis, une plate-forme de preuve de données inter-chaînes ZK qui permet aux dApps et aux contrats intelligents d'accéder, de calculer et d'utiliser des données arbitraires sur plusieurs chaînes de blocs. Celer a implémenté un actif orienté utilisateur zkBridge en utilisant le circuit client léger ZK pour la chaîne croisée entre le testnet Ethereum Goerli et le testnet BNB Chain. LayerZero discute dans sa documentation de la possibilité d'ajouter de nouvelles bibliothèques de messages de preuve optimisés à l'avenir. Des projets plus récents comme Lagrange explorent l'agrégation de plusieurs preuves à partir de plusieurs chaînes de sources, tandis qu'Hérodote permet de stocker des preuves avec des preuves ZK. Cependant, cette transition prendra du temps, car cette approche est difficile à mettre à l'échelle sur des chaînes de blocs qui reposent sur différents mécanismes et cadres de consensus.
ZK est une technologie relativement nouvelle et complexe qui est difficile à auditer, et les coûts actuels de vérification et de génération de preuves ne sont pas optimaux. Nous pensons qu'à long terme, pour prendre en charge des applications inter-chaînes hautement évolutives sur des chaînes de blocs, de nombreuses solutions AMP combineront probablement des logiciels vérifiables avec des humains et des entités de confiance car :
Grâce à l'audit et aux primes de bogue, la possibilité d'exploitation du code peut être minimisée. Au fil du temps, il deviendra plus facile de faire confiance à ces systèmes car leur historique devient la preuve de leur sécurité.
Le coût de génération des épreuves ZK sera réduit. Avec plus de recherche et de développement sur les ZKP, les ZKP récursifs, l'agrégation de preuves, les schémas de pliage et le matériel spécialisé, nous nous attendons à ce que le coût en temps de génération et de vérification des preuves diminue considérablement, ce qui en fait une approche plus rentable.
La blockchain deviendra plus favorable à ZK. À l'avenir, zkEVM sera en mesure de fournir des preuves concises de la validité de l'exécution, et les solutions basées sur des clients légers pourront facilement vérifier l'exécution et le consensus de la chaîne source. Dans la phase finale d'Ethereum, il est également prévu de "zk-SNARK tout", y compris le mécanisme de consensus.
Références humaines, réputation et identité
La sécurité d'un système complexe comme une solution AMP ne peut pas être encapsulée par un seul cadre et nécessite une solution multicouche. Par exemple, en plus des incitations économiques, Axelar met en place un mécanisme de vote quadratique pour empêcher la concentration du pouvoir de vote entre un sous-ensemble de nœuds et favoriser la décentralisation. D'autres preuves humaines, réputations et identités peuvent également compléter les mécanismes de configuration et d'autorisation.
en conclusion
Dans l'esprit ouvert du Web3, nous pouvons voir un avenir pluraliste où de multiples approches coexistent. En fait, une application peut choisir d'utiliser plusieurs solutions d'interopérabilité, soit de manière redondante, soit pour que l'utilisateur choisisse une combinaison basée sur des compromis. Entre les itinéraires à « fort trafic », les solutions point à point peuvent être privilégiées, tandis que les modèles en étoile peuvent dominer la longue queue de la chaîne. En fin de compte, nous, en tant que communauté d'utilisateurs, de constructeurs et de contributeurs, façonnerons la forme de base de l'Internet Web3.
Lien d'origine
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Comment une interprétation approfondie des protocoles de messagerie arbitraires résout-elle le problème de confiance d'interopérabilité ?
Auteur original : Shi Khai Wei, Raghav Agarwal
Compilation originale : Kxp, BlockBeats
Introduction
La multi-chaîne est la future tendance de développement, et la recherche de l'évolutivité a conduit Ethereum à la construction de la technologie Rollup. Dans le passage aux blockchains modulaires, l'attention a de nouveau été portée sur Lisk. Et dans un avenir pas trop lointain, nous entendrons des rumeurs sur des rollups, des L3 et des chaînes souveraines spécifiques à une application. Mais tout cela se fera au prix de la fragmentation, et les ponts inter-chaînes actuels ont souvent des fonctionnalités limitées et reposent sur des signataires de confiance pour la sécurité.
Alors, à quoi ressemblera finalement le Web3 connecté ? Nous pensons que les ponts inter-chaînes évolueront éventuellement vers des protocoles de messagerie inter-chaînes ou de « messagerie arbitraire » (AMP) pour débloquer de nouveaux scénarios d'application, permettant aux applications de transmettre des messages arbitraires entre la chaîne source et la chaîne cible. Nous assisterons également à l'émergence d'un "paysage de mécanismes de confiance", où les constructeurs feront divers compromis entre convivialité, complexité et sécurité.
Chaque solution AMP doit implémenter deux fonctions clés :
Malheureusement, une vérification sans confiance à 100 % n'est pas réaliste, les utilisateurs doivent choisir de faire confiance au code, à la théorie des jeux, aux humains (ou entités) ou à une combinaison de ceux-ci, selon que la vérification est en chaîne ou hors chaîne.
Dans cet article, nous divisons verticalement le domaine global de l'interopérabilité en mécanismes basés sur la confiance et en architectures basées sur l'intégration.
Mécanisme de confiance :
Faites confiance au code et aux mathématiques : pour ces solutions, il existe une preuve en chaîne que tout le monde peut vérifier. 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 vérifier la validité de la transition d'état de la chaîne source sur la chaîne cible. La vérification via des clients légers peut améliorer l'efficacité grâce à des preuves à connaissance nulle, en compressant des calculs arbitrairement longs à effectuer hors ligne, tout en fournissant une simple vérification en chaîne pour prouver les résultats des calculs.
Trust Game Theory : lorsqu'un utilisateur/une application doit faire confiance à un tiers ou à un réseau tiers pour garantir l'authenticité d'une transaction, des hypothèses de confiance supplémentaires sont impliquées. La sécurité de ces mécanismes peut être améliorée en utilisant des réseaux sans autorisation et la théorie des jeux tels que les incitations économiques et la sécurité optimiste.
Confiance en l'humain : Ces solutions reposent sur l'honnêteté ou l'indépendance d'une majorité de validateurs, qui communiquent différentes informations. En plus de faire confiance au consensus des deux chaînes interactives, vous devez également faire confiance à un tiers. Dans ce cas, le seul risque est la réputation des entités participantes. Une transaction est considérée comme valide si suffisamment d'entités participantes conviennent qu'elle est valide.
Il convient de noter que toutes les solutions nécessitent une certaine confiance dans le code et les humains dans une certaine mesure. Toute solution avec un code bogué peut être exploitée par des pirates, et chaque solution comporte un élément humain dans la configuration, les mises à niveau ou la maintenance de la base de code.
Architecture intégrée :
Modèle point à point : Un canal de communication dédié doit être établi entre chaque chaîne source et chaîne cible.
Modèle de hub central : Un canal de communication avec le hub central doit être établi pour réaliser l'interconnexion avec 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 couplé. Le développement de ces canaux peut être difficile pour les blockchains avec des consensus et des cadres différents. Cependant, les ponts jumelés offrent plus de flexibilité pour personnaliser la configuration si vous le souhaitez. Des approches hybrides sont également possibles, telles que le routage multi-sauts via des relais utilisant le protocole Inter-Blockchain Communication (IBC), qui supprime le besoin d'une communication directe d'égal à égal, mais introduit plus de complexités en termes de sécurité, de latence et de coût.
Code de confiance et mathématiques
Afin de ne s'appuyer que sur le code/les mathématiques pour les hypothèses de confiance, des clients légers peuvent être utilisés pour vérifier le consensus de la chaîne source sur la chaîne cible. Les clients/nœuds légers sont des logiciels qui se connectent à des nœuds complets pour interagir avec la blockchain. Les clients légers sur la chaîne cible stockent généralement un historique (dans l'ordre) des en-têtes de bloc de la chaîne source, ce qui est suffisant pour vérifier les transactions. Un proxy hors chaîne (tel qu'un relais) surveille les événements sur la chaîne source, génère des preuves cryptographiques d'inclusion et les transmet avec des 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 de manière séquentielle, chacun contenant un hachage racine Merkle pouvant être utilisé pour prouver l'état, ils sont en mesure de vérifier les transactions. Voici un aperçu des principales caractéristiques de cette approche :
sécurité
Des hypothèses de confiance sont introduites lors de l'initialisation des clients légers. Lors de la création d'un nouveau client léger, il sera initialisé à un en-tête de bloc à partir d'une hauteur spécifique sur l'autre chaîne. Cependant, il est possible que les en-têtes de bloc fournis soient incorrects, ce qui permet de tromper les clients légers avec des en-têtes de bloc falsifiés. Une fois qu'un client léger est initialisé, aucune autre hypothèse de confiance n'est introduite. Cependant, il convient de noter que ce processus d'initialisation repose sur une hypothèse de confiance faible, car il peut être vérifié par n'importe qui. De plus, il existe une hypothèse de vivacité pour la transmission continue d'informations par le relais.
mettre en œuvre
L'implémentation des clients légers dépend de la disponibilité des primitives cryptographiques nécessaires à l'authentification. Si le même type de chaînes est connecté, c'est-à-dire qu'elles partagent le même cadre d'application et le même algorithme de consensus, les implémentations du client léger aux deux extrémités seront les mêmes. Par exemple, toutes les chaînes basées sur Cosmos SDK utilisent le protocole Inter-Blockchain Communication (IBC). D'autre part, les implémentations telles que les clients légers dépendent de la prise en charge des primitives cryptographiques nécessaires à l'authentification. Si le même type de chaînes sont connectées, c'est-à-dire qu'elles partagent le même cadre d'application et le même algorithme de consensus, les implémentations du client léger des deux côtés seront les mêmes. Par exemple, le protocole Inter-Blockchain Communication (IBC) est utilisé pour toutes les chaînes basées sur le SDK Cosmos. D'autre part, si deux types de chaînes différents sont connectés, tels que des cadres 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 sur la connexion de la chaîne Cosmos SDK au cadre d'application Substrate de l'écosystème Polkadot via IBC. Cela nécessite un client léger Tendermint sur la chaîne Substrate et un client léger "costaud" 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 est un défi important. Exécuter des paires de clients légers sur toutes les chaînes peut être coûteux car les écritures sur la blockchain sont coûteuses. De plus, l'intensité des ressources avec des vérificateurs dynamiques est un défi important. Il peut être coûteux d'exécuter des clients légers jumelés sur toutes les chaînes, car les écritures sur la blockchain sont coûteuses. De plus, pour les chaînes avec des ensembles de validateurs dynamiques (comme Ethereum), il n'est pas possible d'exécuter des clients légers.
L'évolutivité est un autre défi. La mise en œuvre des clients légers varie selon l'architecture de la chaîne, ce qui rend difficile la mise à l'échelle et la connexion de différents écosystèmes.
Les vulnérabilités du code sont un risque potentiel car les bogues dans le code peuvent entraîner des vulnérabilités. Par exemple, la violation de la chaîne BNB d'octobre 2022 a révélé une faille de sécurité critique affectant toutes les chaînes compatibles IBC.
Pour répondre au coût et à l'aspect pratique de l'exécution de clients légers par paires sur toutes les chaînes, des solutions alternatives telles que les preuves à connaissance nulle (ZK) peuvent être utilisées pour supprimer le besoin de confiance de tiers.
Les preuves à connaissance nulle comme solution pour la confiance des tiers
Les preuves à connaissance nulle peuvent être utilisées pour vérifier la validité des transitions d'état de la chaîne source sur la chaîne cible. Par rapport à l'exécution de l'intégralité du calcul en chaîne, les preuves ZK n'effectuent que la partie vérification du calcul en chaîne, tandis que le calcul réel se produit hors chaîne. Cette approche permet une vérification plus rapide et plus efficace que la réexécution du calcul d'origine. Certains exemples incluent Polymer Labs ; Polymer ZK-IBC ; et Succinct Labs ; Telepathy. Polymer développe des IBC multi-sauts pour améliorer la connectivité et réduire le nombre de connexions appariées nécessaires.
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 une configuration de confiance, y compris la création de clés initiales utilisées pour générer des preuves utilisées dans la vérification. La clé est de détruire le secret de l'événement de configuration pour empêcher les transactions d'être authentifiées par falsification. Une fois la configuration de confiance terminée, aucune autre hypothèse de confiance n'est introduite. De plus, les nouveaux frameworks ZK (comme Halo et Halo;2;) suppriment complètement le besoin d'une configuration de confiance.
mettre en œuvre
Il existe une variété de schémas de preuve ZK, tels que SNARK, STARK, VPD et SNARG, et SNARK est actuellement le plus largement utilisé. Différents frameworks de preuve SNARK, tels que Groth;16, Plonk, Marlin, Halo et Halo;2;, offrent des compromis en termes de taille de preuve, de temps de preuve, de temps de vérification, d'exigences de mémoire et d'exigences de configuration de confiance. Des preuves ZK récursives ont également émergé, permettant à la charge de travail de preuve d'être répartie sur plusieurs ordinateurs plutôt que sur un seul. Afin de générer des preuves de validité, les primitives de base suivantes doivent être implémentées : vérification du schéma de signature utilisé par un validateur, stockage des preuves de la clé publique du validateur dans l'engagement d'ensemble de validateur stocké en chaîne, et suivi de l'ensemble de validateur, qui peut changer fréquemment.
défi
L'implémentation de divers schémas de signature dans zkSNARK nécessite l'implémentation d'opérations arithmétiques hors domaine et de courbes elliptiques complexes, ce qui n'est pas trivial et peut nécessiter différentes implémentations en fonction du cadre et du consensus des différentes chaînes. 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 à un domaine tels que Circom, Cairo et Noir, ou implémenter des circuits directement, ce qui peut être difficile et ralentir l'adoption. Si le temps et les efforts s'avèrent très importants, ils ne peuvent être gérés que par des équipes dédiées et du matériel dédié, ce qui peut conduire à une centralisation. Des temps de génération de preuve plus longs entraînent également des retards. Des techniques telles que le calcul incrémental vérifiable (IVC) peuvent optimiser les temps de preuve, mais nombre d'entre elles sont encore en phase de recherche, en attente de mise en œuvre. Des temps de vérification et des charges de travail plus longs augmenteront les coûts en chaîne.
Théorie des jeux de confiance
Les protocoles d'interopérabilité basés sur la théorie des jeux peuvent être globalement divisés en deux catégories, selon la manière dont ils incitent à un comportement honnête des entités participantes :
La première catégorie est un mécanisme de sécurité économique dans lequel plusieurs acteurs externes (tels que des validateurs) coopèrent pour parvenir à un consensus afin de déterminer l'état mis à jour de la chaîne source. Pour devenir validateur, les participants doivent miser un certain nombre de jetons, qui peut être réduit en cas d'activité malveillante. Dans une configuration sans autorisation, n'importe qui peut accumuler des mises et devenir un validateur. En outre, des incitations économiques telles que des récompenses globales sont fournies aux validateurs qui suivent le protocole pour garantir des incitations économiques pour un comportement honnête. Cependant, si le montant potentiellement volé dépasse le montant misé, les participants peuvent s'entendre pour voler des fonds. Des exemples de protocoles qui utilisent des mécanismes de sécurité économiques incluent Axelar et Celer IM.
La deuxième catégorie est celle des mécanismes de sécurité optimistes, où la solution repose sur l'hypothèse que seul un petit nombre de participants à la blockchain sont honnêtes et obéissent aux règles du protocole. Dans cette approche, un participant honnête agit comme une garantie. Par exemple, une solution optimale permet à quiconque de soumettre des preuves de fraude. Bien qu'il existe une incitation financière, un observateur honnête peut manquer une transaction frauduleuse. Les cumuls optimistes utilisent également ce mécanisme. Nomad et ChainLink CCIP sont des exemples de protocoles qui utilisent des mécanismes de sécurité optimistes. Dans le cas de Nomad, les observateurs ont pu prouver la fraude, bien qu'ils soient sur liste blanche au moment de la rédaction. ChainLink CCIP prévoit d'utiliser un réseau anti-fraude composé d'un réseau distribué d'oracles pour détecter les activités malveillantes, bien que la mise en œuvre du réseau anti-fraude de CCIP soit inconnue.
sécurité
En termes de sécurité, les deux mécanismes reposent sur la participation sans autorisation des vérificateurs et des observateurs pour garantir la validité de la théorie des jeux. Dans un mécanisme de sécurité économique, les fonds sont plus vulnérables si le montant misé est inférieur au montant qui pourrait être volé. D'autre part, dans les mécanismes de sécurité optimistes, l'hypothèse de confiance minoritaire peut être exploitée si personne ne soumet de preuve de fraude, ou si les observateurs d'autorisation sont compromis ou supprimés. En revanche, les mécanismes de sécurité économique dépendent moins de la vivacité pour maintenir la sécurité.
mettre 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é d'une transaction lorsqu'une invocation est détectée. Une fois le consensus atteint, ils fournissent des preuves sur la chaîne cible. Les validateurs sont généralement tenus de miser un certain nombre de jetons, qui peut être réduit si une activité malveillante est détectée. Des exemples de protocoles qui utilisent cette méthode de mise en œuvre incluent Axelar Network et Celer IM.
Une autre méthode de mise en œuvre implique l'utilisation de proxys hors chaîne. Des proxys hors chaîne sont utilisés pour mettre en œuvre des solutions optimistes de type Rollups. Dans une fenêtre de temps prédéfinie, ces mandataires hors chaîne peuvent 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 de tirer parti de son réseau existant d'oracles pour surveiller et attester les transactions inter-chaînes.
Forces et défis
Un avantage clé des solutions AMP basées sur la théorie des jeux est l'optimisation des ressources, car le processus de vérification est généralement hors chaîne, ce qui réduit les besoins en ressources. De plus, ces mécanismes sont évolutifs car le mécanisme de consensus reste le même pour différents types de chaînes et peut être facilement étendu à des blockchains hétérogènes.
Plusieurs défis sont également associés à ces mécanismes. Si une majorité de validateurs s'entendent, les hypothèses de confiance peuvent être exploitées pour voler des fonds, nécessitant des contre-mesures telles que le vote quadratique et les preuves de fraude. De plus, les solutions basées sur la sécurité optimiste introduisent des complexités en termes de finalité et de vivacité, car les utilisateurs et les applications doivent attendre des fenêtres frauduleuses pour garantir la validité des transactions.
Faites confiance aux humains
Les solutions nécessitant la confiance dans les entités humaines peuvent également être divisées en deux grandes catégories :
Sécurité de 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 plupart des entités sont honnêtes, et si la majorité de ces entités signent une transaction particulière, alors cette transaction est valide. La seule chose en danger ici est la réputation des entités impliquées. Quelques exemples incluent; Multichain (Anycall V;6;) et Wormhole. Des vulnérabilités peuvent toujours exister en raison de vulnérabilités de contrats intelligents, comme l'a démontré le piratage de Wormhole au début de 2022.
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 ces deux entités sont indépendantes l'une de l'autre et ne peuvent pas s'entendre. LayerZero en est un exemple. Les en-têtes de bloc sont transmis à la demande via des oracles distribués et les preuves de transaction sont envoyées via des relais. Si la preuve correspond à l'en-tête, la transaction est considérée comme valide. Bien que la preuve d'une correspondance repose sur le code/les mathématiques, les participants doivent être sûrs que ces entités restent indépendantes et n'ont aucune intention malveillante. Les applications construites sur ;LayerZero; peuvent choisir leurs oracles et relais (ou héberger leurs propres oracles/relais), limitant ainsi les risques pour les oracles/relais individuels. Les utilisateurs finaux doivent être sûrs que LayerZero, des tiers ou l'application elle-même exécutent des oracles et des relais indépendamment, sans intention malveillante.
Dans les deux approches, la réputation des entités tierces participantes dissuade les comportements malveillants. Ce sont généralement des entités très respectées dans la communauté des validateurs et des oracles, et s'ils se comportent de manière malveillante, ils risquent de nuire à leur réputation et d'avoir un impact négatif sur d'autres activités commerciales.
Considérations supplémentaires pour les solutions AMP
Lors de l'examen de la sécurité et de 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 composants qui peuvent évoluer dans le temps, nous ne les avons pas inclus dans la comparaison globale.
intégrité du code
Des hacks récents ont exploité des erreurs de code, soulignant la nécessité d'un audit robuste, de primes de bogues et de diverses implémentations de clients. Si tous les vérificateurs (en sécurité économique/optimiste/réputationnelle) exécutent le même client (logiciel de vérification), cela augmente la dépendance à une seule base de code et réduit la diversité des clients. Par exemple, Ethereum s'appuie sur plusieurs clients d'exécution tels que geth, netermind, erigon, besu, akula. Plusieurs implémentations dans différentes langues peuvent augmenter la diversité, aucun client ne dominant le réseau, éliminant ainsi un point de défaillance unique potentiel. Avoir plusieurs clients peut également aider à maintenir la vivacité au cas où un petit nombre de validateurs/signataires/clients légers échoueraient en raison d'un bogue/d'une attaque dans une implémentation particulière.
Configuration et évolutivité
Les utilisateurs et les développeurs doivent savoir si les validateurs/observateurs peuvent rejoindre le réseau sans autorisation, sinon la confiance sera masquée par les entités qui choisissent l'autorisation. Les mises à niveau des contrats intelligents peuvent également introduire des vulnérabilités pouvant conduire à des attaques et éventuellement même modifier les hypothèses de confiance. Différentes solutions peuvent être mises en place pour atténuer ces risques. Par exemple, dans l'instanciation actuelle, la passerelle Axelar peut être mise à niveau mais nécessite l'approbation du comité hors ligne (seuil 4/8), cependant, dans un avenir proche, Axelar prévoit d'exiger que tous les validateurs approuvent collectivement toute mise à niveau de la passerelle. Les principaux contrats 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 poussées, les dapps qui définissent les paramètres par défaut obtiendront des versions plus récentes, les dapps qui définissent manuellement la version doivent la définir sur la nouvelle version.
Valeur Maximale Extractible (MEV)
Différentes blockchains ne sont pas synchronisées par une horloge commune et ont des temps de finalité différents. Par conséquent, l'ordre d'exécution et la synchronisation sur la chaîne cible peuvent varier d'une chaîne à l'autre. Dans un monde inter-chaînes, le MEV est difficile à définir clairement. Il introduit un compromis entre la vivacité et l'ordre d'exécution. Un canal ordonné assurera la livraison dans l'ordre des messages, mais si un message expire, le canal sera fermé. Une autre application peut préférer qu'il n'y ait pas de classement, mais la remise d'autres messages n'est pas affectée.
certitude de la chaîne source
Idéalement, les solutions AMP devraient attendre que la chaîne source atteigne la finalité avant de transmettre les informations d'état de la chaîne source à une ou plusieurs chaînes cibles. Cela garantira que les blocs de la chaîne source peuvent difficilement être inversés ou modifiés. Cependant, de nombreuses solutions fournissent une messagerie instantanée et font des hypothèses de confiance sur la finalité afin de fournir la meilleure expérience utilisateur. Dans ce cas, si la chaîne source subit une annulation d'état après la livraison du message et le passage de l'actif de pont, cela peut conduire à des situations telles que la double dépense des fonds de pont. Les solutions AMP peuvent gérer ce risque de plusieurs manières, par exemple en définissant différentes hypothèses de finalité pour différentes chaînes en fonction de la décentralisation de la chaîne, ou en faisant des compromis entre vitesse et sécurité. Les ponts utilisant des solutions AMP peuvent fixer des limites sur la quantité d'actifs pontés avant que la chaîne source n'atteigne la finalité.
Tendances et perspectives d'avenir Sécurité personnalisable et attachable
Pour mieux servir divers cas d'utilisation, les solutions AMP sont incitées à offrir plus de flexibilité aux développeurs. Axelar introduit une méthode permettant l'évolutivité de la messagerie et de la validation sans modifier la logique de la couche application. HyperLane V2 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 en plus de la sécurité économique. De nombreuses solutions attendent un nombre minimum prédéfini de confirmations de bloc sur la chaîne source avant de délivrer un message. LayerZero permet aux développeurs de mettre à jour ces paramètres. Nous nous attendons à ce que certaines solutions AMP continuent d'offrir plus de flexibilité, mais ces choix de conception nécessitent quelques discussions. Les applications doivent-elles pouvoir configurer leur sécurité, dans quelle mesure et que se passe-t-il si les applications sont architecturées avec une conception sous-optimale ? La sensibilisation des utilisateurs aux concepts fondamentaux de la sécurité est susceptible de devenir de plus en plus importante. En fin de compte, nous prévoyons l'agrégation et l'abstraction des solutions AMP, éventuellement sous la forme d'une certaine forme de composition ou de sécurité "complémentaire".
La maturité du mécanisme « Trust Code and Math »
Dans une phase finale idéale, tous les messages inter-chaînes seront minimisés en termes de confiance grâce à l'utilisation de preuves à connaissance nulle (ZK). Nous avons vu des projets similaires comme Polymer Labs et Succinct Labs émerger. Multichain a également publié un livre blanc zkRouter sur l'interopérabilité via les preuves ZK. Avec la machine virtuelle Axelar récemment annoncée, les développeurs peuvent tirer parti de l'amplificateur Interchain pour établir de nouvelles connexions au réseau Axelar sans autorisation. Par exemple, une fois que des clients légers puissants et des preuves ZK sont développés pour l'état d'Ethereum, les développeurs peuvent facilement les intégrer dans le réseau Axelar pour remplacer ou améliorer les connexions existantes. Celer Network a annoncé Brevis, une plate-forme de preuve de données inter-chaînes ZK qui permet aux dApps et aux contrats intelligents d'accéder, de calculer et d'utiliser des données arbitraires sur plusieurs chaînes de blocs. Celer a implémenté un actif orienté utilisateur zkBridge en utilisant le circuit client léger ZK pour la chaîne croisée entre le testnet Ethereum Goerli et le testnet BNB Chain. LayerZero discute dans sa documentation de la possibilité d'ajouter de nouvelles bibliothèques de messages de preuve optimisés à l'avenir. Des projets plus récents comme Lagrange explorent l'agrégation de plusieurs preuves à partir de plusieurs chaînes de sources, tandis qu'Hérodote permet de stocker des preuves avec des preuves ZK. Cependant, cette transition prendra du temps, car cette approche est difficile à mettre à l'échelle sur des chaînes de blocs qui reposent sur différents mécanismes et cadres de consensus.
ZK est une technologie relativement nouvelle et complexe qui est difficile à auditer, et les coûts actuels de vérification et de génération de preuves ne sont pas optimaux. Nous pensons qu'à long terme, pour prendre en charge des applications inter-chaînes hautement évolutives sur des chaînes de blocs, de nombreuses solutions AMP combineront probablement des logiciels vérifiables avec des humains et des entités de confiance car :
Grâce à l'audit et aux primes de bogue, la possibilité d'exploitation du code peut être minimisée. Au fil du temps, il deviendra plus facile de faire confiance à ces systèmes car leur historique devient la preuve de leur sécurité.
Le coût de génération des épreuves ZK sera réduit. Avec plus de recherche et de développement sur les ZKP, les ZKP récursifs, l'agrégation de preuves, les schémas de pliage et le matériel spécialisé, nous nous attendons à ce que le coût en temps de génération et de vérification des preuves diminue considérablement, ce qui en fait une approche plus rentable.
La blockchain deviendra plus favorable à ZK. À l'avenir, zkEVM sera en mesure de fournir des preuves concises de la validité de l'exécution, et les solutions basées sur des clients légers pourront facilement vérifier l'exécution et le consensus de la chaîne source. Dans la phase finale d'Ethereum, il est également prévu de "zk-SNARK tout", y compris le mécanisme de consensus.
Références humaines, réputation et identité
La sécurité d'un système complexe comme une solution AMP ne peut pas être encapsulée par un seul cadre et nécessite une solution multicouche. Par exemple, en plus des incitations économiques, Axelar met en place un mécanisme de vote quadratique pour empêcher la concentration du pouvoir de vote entre un sous-ensemble de nœuds et favoriser la décentralisation. D'autres preuves humaines, réputations et identités peuvent également compléter les mécanismes de configuration et d'autorisation.
en conclusion
Dans l'esprit ouvert du Web3, nous pouvons voir un avenir pluraliste où de multiples approches coexistent. En fait, une application peut choisir d'utiliser plusieurs solutions d'interopérabilité, soit de manière redondante, soit pour que l'utilisateur choisisse une combinaison basée sur des compromis. Entre les itinéraires à « fort trafic », les solutions point à point peuvent être privilégiées, tandis que les modèles en étoile peuvent dominer la longue queue de la chaîne. En fin de compte, nous, en tant que communauté d'utilisateurs, de constructeurs et de contributeurs, façonnerons la forme de base de l'Internet Web3.
Lien d'origine