Le risque de collusion peut-il être éliminé et la sécurité du pont inter-chaînes améliorée sans sacrifier les performances, l'évolutivité et la polyvalence du pont inter-chaînes ?
Écrit par : MiddleX
Avec le développement du modèle multi-chaînes, le pont inter-chaînes est devenu une infrastructure importante dans le domaine du Web 3. Quelle que soit l'évolution du modèle de chaîne publique, le cross-chain est toujours une demande rigide constante. Pour les parties de projet Dapp, elles doivent étendre leur champ d'activité à autant de chaînes que possible, d'une Dapp à chaîne unique à une Dapp à chaîne complète ; pour les parties de projet de chaîne publique, tout le monde a la motivation de relier Bitcoin et Ethereum Square, pour importer des actifs et du trafic pour leur propre écologie ; pour les utilisateurs cryptés, ils espèrent également permettre à leurs actifs cryptés de voyager sur différentes chaînes de manière décentralisée, au lieu de s'appuyer sur des échanges centralisés.
Cependant, le pont inter-chaînes, en tant que "véhicule de transport de fonds" entre les chaînes, a été "volé" à plusieurs reprises. Au cours des deux dernières années, presque sans exception, les grands projets de ponts inter-chaînes ont été patronnés par des pirates. Parmi tous les types d'incidents de sécurité liés au cryptage, l'incident du pont inter-chaînes est arrivé en tête de liste avec une perte de près de 2 milliards de dollars. Pour résoudre le problème de sécurité du pont à chaînes croisées, il est imminent d'ajouter une armure à ce "porte-monnaie" "à toit ouvert".
Comment casser le jeu ?
D'une manière générale, il existe deux types d'incidents de sécurité dans les ponts inter-chaînes : l'un est causé par des failles dans le code du contrat, telles que l'absence de vérification de l'adresse du contrat de jeton, ce qui fait que les événements de dépôt de monnaie contrefaite forgés par les attaquants ne sont pas filtrés, et un autre l'exemple est le manque de contrôle d'accès, ce qui conduit à La liste des ensembles de validateurs a été falsifiée ; l'autre est la collusion des nœuds de validation pour voler la clé privée, puis voler les fonds verrouillés par le pont inter-chaînes, ou menthe pièces contrefaites pour voler LP.
La principale raison de la première est que la base de code du pont inter-chaînes n'est pas encore mature, et ces problèmes diminueront progressivement avec l'accumulation de l'expérience de l'industrie. La raison principale de ce dernier est les défauts inhérents à la conception des ponts à chaînes croisées.
Le pont inter-chaînes résout essentiellement le problème de savoir comment une chaîne connaît les événements sur une autre chaîne. Ce problème est divisé en deux aspects, l'un est la transmission et l'autre est la vérification. Dans le pont inter-chaînes, n'importe qui peut transmettre des événements inter-chaînes, la clé est de savoir comment la chaîne cible vérifie que l'événement s'est réellement produit sur la chaîne source. **
Selon différents mécanismes de vérification, les ponts inter-chaînes sont divisés en trois types : nativement vérifiés, localement vérifiés et vérifiés en externe.
Vérification native signifie que tous les vérificateurs de la chaîne cible effectuent une vérification consensuelle sur les événements de la chaîne source, ce qui est généralement réalisé en déployant le client léger de la chaîne source sur la chaîne cible. Ce client léger enregistre et met à jour en permanence l'en-tête de bloc de la chaîne source, puis effectue une vérification SPV des événements de la chaîne source.
La vérification locale fait référence à la vérification directe de la transaction par la contrepartie, également appelée vérification point à point. Un paradigme typique est un échange atomique basé sur des timelocks hachés. Les intérêts économiques des parties à la transaction étant antagonistes, il n'y a aucune possibilité de collusion.
* La vérification externe fait référence à l'introduction d'un groupe de témoins externes chargés de vérifier les messages inter-chaînes. L'ensemble de témoins externes exécute une signature consensuelle sur les événements inter-chaînes. Une fois que la chaîne cible a vérifié la signature, il juge l'événement crédible.
Le coût de la vérification native est élevé, ce qui se reflète principalement dans deux points. Premièrement, le coût de la vérification en chaîne est élevé. Exécuter un client léger sur la chaîne et effectuer une vérification SPV sur les événements consommera beaucoup de gaz. Deuxièmement, le coût de développement de la compatibilité avec de nouvelles chaînes est élevé, pour être compatible avec une nouvelle chaîne, il est nécessaire de développer au moins une paire de clients légers. Avec l'essor des récits ZK, il existe actuellement des solutions sur le marché pour améliorer la vérification native grâce à la technologie ZK, ce qui peut réduire efficacement les coûts ci-dessus.Cependant, quelle que soit son optimisation, au moins une preuve ZK doit être vérifiée sur la chaîne, et le coût est d'environ 500 000 Gwei, la vérification n'a besoin que de vérifier une signature (21 000 Gwei) ce qui est tout à fait différent. Par conséquent, la vérification native ne peut pas obtenir un avantage dans la concurrence des prix des ponts inter-chaînes et ne peut pas réaliser la véritable "chaîne complète".
L'authentification locale était autrefois adoptée par des projets bien connus tels que Celer et Connext, mais ces projets, sans exception, ont changé de ton et n'utilisent plus l'authentification locale. La raison en est que l'expérience de transaction de la vérification locale est extrêmement médiocre.Aussi optimisée soit-elle, elle nécessite toujours que l'utilisateur opère au moins deux fois (initier la transaction, déverrouiller le verrou de hachage en direct). De plus, la vérification locale ne s'applique qu'à la chaîne croisée des actifs et ne peut être étendue à aucune chaîne croisée des messages.
Le coût de mise en œuvre de la vérification externe est faible, la surcharge inter-chaînes est faible, elle peut être facilement adaptée à plusieurs chaînes et prend en charge le chaînage inter-chaînes de messages arbitraires. Actuellement, c'est la solution adoptée par la plupart des chaînes inter-chaînes. projets de ponts. Cependant, les ponts inter-chaînes externes introduisent des risques de collusion potentiels en raison de l'introduction de nouvelles hypothèses de confiance. La plupart des ponts inter-chaînes de vérification externe utilisent la technologie MPC (informatique multipartite sécurisée) pour fragmenter la clé privée, de sorte que chaque nœud de vérification externe puisse maîtriser un fragment. Par rapport à la technologie MutiSig (multi-signature) ordinaire, la technologie MPC est plus universelle (il n'y a aucune exigence pour le schéma de signature adopté par la chaîne), le coût de vérification est inférieur (une seule signature doit être vérifiée sur la chaîne), et il est pratique de transférer l'autorité de signature (il suffit d'actualiser le fragment, pas besoin de changer l'adresse) et d'autres avantages, mais cela ne change pas l'essence de la centralisation de la vérification externe et ne peut empêcher la collusion.
Alors, quel type de solution inter-chaînes peut être utilisé pour éliminer le risque de collusion et améliorer la sécurité du pont inter-chaînes sans sacrifier les performances, l'évolutivité et la polyvalence du pont inter-chaînes ?
BOOL Schéma de réseau
BOOL Network est un produit de pont inter-chaînes lancé par LayerBase Labs. LayerBase Labs effectue des recherches dans le domaine inter-chaînes depuis près de 4 ans, au cours desquels il a lancé des produits minimum viables, mais en raison de l'imperfection de ces produits, ils n'ont pas été largement utilisés. Récemment, LayerBase Labs a lancé un pont inter-chaîne basé sur Dynamic Hidden Committee (DHC) : BOOL Network.Cette solution est considérée comme suffisamment parfaite, elle est donc prête à être dévoilée au public.
La solution inter-chaînes de BOOL Network intègre la technologie ZK et la technologie TEE sur la base de la technologie MPC, et transforme l'ensemble de vérificateurs externes en un ** comité caché dynamique inconnu et inconscient **, atteignant un degré élevé d'attributs anti-collusion, réalisant ainsi un haut degré de sécurité.
Prenons un exemple pour illustrer ce qu'est un "club dynamique de membres cachés".
Supposons que vous soyez un général, commandant 1000 soldats et chargé de garder 50 greniers, comment organiserez-vous vos soldats ?
En supposant que tous les greniers ont la même importance, le meilleur arrangement serait de diviser les 1 000 soldats en 50 escouades de 20 hommes chacune pour garder un grenier.
Mais la division des troupes apporte un danger caché. Si plus de la moitié des soldats d'une certaine équipe conspirent, le grenier correspondant peut tomber. C'est-à-dire que si 11 soldats d'une équipe conspirent, ils peuvent vous trahir et voler le grenier. .
C'est quelque chose que vous ne pouvez pas tolérer.Afin d'empêcher ce genre de complot et d'assurer la sécurité du grenier, vous pouvez prendre les mesures suivantes :
Dynamique : Tous les soldats sont regroupés et les escouades sont re-divisées chaque jour, de sorte que le grenier gardé par chaque soldat et ses coéquipiers ne sera pas fixe ;
Caché : bandez les yeux des soldats pour qu'ils ne sachent pas quel grenier ils gardent ou qui sont leurs coéquipiers.
De cette façon, les soldats rebelles ne sauront pas avec qui conspirer. Même s'il y a des traîtres convenus à l'avance, ils ne peuvent pas contrôler et ne peuvent pas savoir si les traîtres sont dans la même équipe.
En supposant que pour assurer une forte probabilité de succès dans le complot, le traître doit conspirer avec la majorité de toute votre équipe de 1 000 personnes. C'est sans aucun doute aussi difficile que d'escalader le ciel. Grâce à des méthodes "dynamiques" et "cachées", vous faites en sorte que la fiabilité de chaque escouade atteigne le niveau de toute l'équipe.
C'est exactement le schéma adopté par BOOL Network.
TEE - Bandez les yeux de chaque soldat
BOOL Le réseau nécessite que les nœuds du réseau utilisent des dispositifs TEE pour participer à la vérification des événements inter-chaînes. Le réseau BOOL est complètement ouvert et accessible, et tout sujet disposant d'un dispositif TEE peut devenir un nœud de vérification en engageant $BOOL.
Le nom complet de TEE est Trusted Execution Environment (Trusted ute Environment). Il s'agit d'un environnement informatique s'exécutant sur un appareil donné qui est isolé du système d'exploitation principal, comme une enclave. Cette isolation est renforcée par le matériel. Le processus d'exécution des programmes dans TEE est caché et ne peut être perçu ou interféré par le monde extérieur. Cela rend impossible pour les pirates d'attaquer.
TEE peut exécuter des applications à haute sécurité, telles que l'authentification biométrique, la gestion sécurisée des paiements, etc. Dans notre vie quotidienne, TEE n'est pas étranger, et la vérification des empreintes digitales sur les téléphones mobiles est exécutée en TEE. Cela peut garantir que d'autres applications de téléphonie mobile ne peuvent pas obtenir d'informations sur les empreintes digitales lors de l'utilisation du résultat de la vérification des empreintes digitales.
Pendant le processus de vérification des événements inter-chaînes, les nœuds de vérification externes doivent effectuer des signatures de consensus. À ce stade, la clé privée doit être exposée au réseau, ce qui est très facile à devenir la cible d'attaques de pirates. L'attaque du pont officiel d'Axie Infinity Ronin Bridge en mars 2022 et l'attaque du pont officiel de la chaîne publique Harmony Horizen Bridge en juin 2022 ont été causées par l'obtention de la clé privée du nœud de pont par des pirates. L'utilisation de TEE pour stocker des fragments de clé privée et exécuter des signatures de consensus améliorera considérablement la sécurité et empêchera les pirates d'obtenir des clés privées. Sur cette base, BOOL Network exige que toutes les communications entre les nœuds TEE soient également entièrement cryptées, afin que les pirates ne puissent intercepter aucune information du contenu de la communication entre les nœuds.
Ring VRF - Laisser les soldats tourner au hasard
BOOL Network est conçu comme un outil pour créer un pont inter-chaînes, qui prend en charge tout tiers pour créer un pont inter-chaînes dessus. Lorsqu'un tiers crée un pont inter-chaînes sur le réseau BOOL, il doit créer un DHC (Dynamic Hidden Membership Club) en premier. En supposant que le tiers souhaite que le pont inter-chaînes qu'il crée prenne en charge 10 chaînes, il doit créer 10 DHC, chaque chaîne correspondant à un DHC et tous les messages inter-chaînes envoyés au chaîne sont vérifiées par le DHC.
Chaque fois qu'un tiers crée un pont inter-chaînes via le réseau BOOL, plusieurs DHC seront générés. Comme le nombre de ponts inter-chaînes créés sur le réseau BOOL continue d'augmenter, il peut y avoir des milliers de DHC. Un tiers peut définir le seuil de signature de DHC, et les seuils de signature communs sont 5 sur 9, 13 sur 19 et 15 sur 21.
Il convient de noter que les membres de chaque DHC ne sont pas fixes, mais tournent constamment, et chaque époque sera mélangée une fois. Basé sur la technologie ZK, BOOL Network a développé le protocole Ring VRF, qui peut affecter des membres à chaque DHC de manière complètement aléatoire. Ring VRF générera une preuve ZK pour les membres DHC. Cette preuve ZK représente l'identité temporaire des membres. Les membres DHC utilisent des identités temporaires pour s'identifier et communiquer entre eux, afin de coopérer pour effectuer un certain travail (comme la signature de seuil MPC). Cela garantit l'anonymat des membres du DHC, tant à l'extérieur qu'entre eux.
Dans la même époque, les nœuds TEE de différents DHC peuvent se chevaucher, ou certains nœuds TEE peuvent être inactifs sans entrer dans un DHC. Ces situations sont autorisées, mais RIng VRF donnera à chaque nœud TEE des chances exactement égales.
En bref, **En masquant dynamiquement le mécanisme des membres du comité, BOOL Network a construit une boîte noire incassable. Si un nœud TEE est en état de fonctionnement, personne (y compris l'opérateur du nœud lui-même, les autres nœuds et les attaquants externes) n'a aucun moyen de connaître l'état de fonctionnement du nœud. Dans quel DHC se trouve le nœud ? Sur le même DHC que quels autres nœuds ? Quelles communications consensuelles ont eu lieu ? Quels messages sont signés ? Il n'y a aucun moyen de connaître la vérité. C'est "l'inconnaissable" et "l'inconnaissance" mentionnés ci-dessus. Sous une telle prémisse, tant que le réseau BOOL lui-même est sûr, chaque membre caché dynamique est sûr. Pour assurer une forte probabilité de succès de l'attaque, l'attaquant doit maîtriser la majorité des nœuds du réseau BOOL. Cependant, étant donné que les programmes exécutés dans le TEE ne peuvent pas être altérés, les attaquants peuvent uniquement arrêter le réseau et ne peuvent pas voler les actifs du réseau.
Comment évaluer une solution inter-chaînes
Bien que la sécurité soit le problème le plus urgent à résoudre pour les ponts inter-chaînes, la sécurité n'est pas le seul critère d'évaluation des ponts inter-chaînes. Si pour résoudre un problème, un nouveau problème est créé, cela ne résout pas vraiment le problème.
LayerBase Labs étudie depuis longtemps diverses solutions d'extension basées sur des clients légers, y compris la solution ZK Client. Le principe de base du client ZK est d'étendre le client léger grâce à la technologie ZK, de mettre la vérification de l'en-tête de bloc et la vérification SPV de l'événement de la chaîne source hors de la chaîne, de générer un certificat ZK et de le soumettre à la chaîne, et seulement besoin pour vérifier le certificat ZK sur la chaîne Cela équivaut à vérifier les en-têtes de bloc et les événements de la chaîne source. Bien que ce schéma soit suffisamment sûr, la consommation de gaz sur la chaîne est toujours élevée. Deuxièmement, le circuit ZK sous la chaîne et le client léger sur la chaîne sont relativement bonnes en termes de mise en œuvre technique Complexité, ce qui peut conduire à une plus grande vulnérabilité au niveau du code, affectant ainsi la sécurité du pont inter-chaînes. De plus, afin d'éviter que chaque chaîne n'ait à déployer des clients légers de toutes les autres chaînes, cette solution doit souvent introduire une chaîne de relais (voir la figure ci-dessous), et l'existence de la chaîne de relais rendra le cross-chain qui peut être complété en une seule étape Le processus de livraison des messages a dû être divisé en deux étapes, ce qui a entraîné une augmentation de la latence (délai) de la livraison des messages inter-chaînes.
De nombreuses personnes dans l'industrie préconisent la technologie ZK Client et affirment même que ZK Client est la solution ultime pour les ponts inter-chaînes. Ce que nous voulons dire, c'est que la technologie n'est pas pour le spectacle, et encore moins pour la mode, mais pour résoudre de vrais problèmes.ZK Client crée beaucoup plus de problèmes qu'il n'en résout.
Nous avons également étudié la solution dite Ultra Light Client de LayerZero. LayerZero met le client léger dans l'oracle hors chaîne pour résoudre le problème de surcoût de gaz sur la chaîne, mais vous remettez la responsabilité de la vérification au vérificateur de la cible. chaîne Étant donné l'oracle hors chaîne, il ne s'agit plus d'une vérification native, mais d'une vérification externe, et il existe une hypothèse de sécurité pour l'oracle hors chaîne. Quant au postulat de sécurité revendiqué par LayerZero Labs : "Relayer et oracle machine sont indépendants l'un de l'autre", il n'existe pas dans la réalité, et l'expérience d'attaque de L2BEAT Labs a confirmé ce point.
Nous avons également remarqué le schéma de vérification optimiste adopté par Nomad et Celer. En ajoutant un rôle de challenger sur la base d'une vérification externe, la sécurité de m-de-n peut être améliorée avec succès à 1-de-n. Bien que ce schéma soit bien conçu, le coût est un retard d'environ 30 minutes, ce qui limitera le champ d'application du régime.
Nous avons également trouvé la conception cool d'Avalanche Bridge, qui utilise des nœuds TEE comme vérificateurs externes pour vérifier les événements inter-chaînes, et réalise une expérience inter-chaînes efficace et bon marché grâce à une conception de contrat minimaliste. Mais nous avons également vu que bien qu'Avalanche Bridge puisse conserver en toute sécurité la clé privée pour empêcher les attaquants externes, il ne peut pas empêcher l'attaque par collusion entre les nœuds TEE internes.
En fin de compte, nous avons proposé le système de comité caché dynamique actuel de BOOL Network. Du point de vue de la sécurité, il peut empêcher les attaques de pirates externes et empêcher la collusion interne. En termes de performances et d'expérience, l'expérience inter-chaînes de BOOL Network n'est pas dans le Make any sacrifices sur la base d'une vérification externe et maintenir le même niveau que le pont de vérification externe.
Pour évaluer un pont inter-chaînes, nous pensons que sur la base du triangle impossible, il doit être étendu à six aspects pour une évaluation complète, à savoir le coût (Cost), la rapidité (Speed), la sécurité (Security), la convivialité (Liveness), la généralité , et Scarabilité**.
Coût : Le coût de la chaîne croisée réside principalement dans le coût du gaz sur la chaîne. Le coût d'une vérification des messages inter-chaînes du réseau BOOL n'est en fait qu'une vérification de signature unique, qui est au même niveau que la passerelle de vérification externe ;
Vitesse : Ici, nous n'évaluons que la latence du pont inter-chaîne lui-même, sans tenir compte de la finalité de la chaîne elle-même. À ce stade, puisqu'il n'y a pas de calculs redondants en chaîne et hors chaîne, et aucune conception de chaîne de relais (la chaîne de relais conduira à une vérification de second ordre redondante), la vitesse inter-chaîne du réseau BOOL peut également atteindre le niveau limite ;
Sécurité : nous avons expliqué en détail que BOOL Network peut empêcher les attaques externes et la collusion interne. *
Disponibilité : en termes simples, ne plantez pas. BOOL Nework permettra à chaque DHC d'être équipé d'un ou plusieurs DHC de secours lors de sa création, afin d'éviter les problèmes de disponibilité causés lorsque plus de la moitié des nœuds TEE d'un DHC donné sont hors ligne.
Généralités : il est non seulement nécessaire de prendre en charge la chaîne croisée des actifs, mais également de prendre en charge la chaîne croisée des messages arbitraires, ce qui est également satisfait par BOOL Network.
* Évolutivité : peut-il rapidement prendre en charge de nouvelles chaînes ? BOOL Network n'a besoin que de déployer un ensemble de contrats simples pour prendre en charge une nouvelle chaîne (1 personne-mois d'heures de développement peut être complétée), et maintenant nous avons terminé le support de toutes les blockchains grand public. De plus, BOOL Network n'est pas limité par l'exhaustivité Turing de la chaîne et peut prendre en charge des chaînes complètes non Turing telles que BTC sans ajouter de nouvelles hypothèses de confiance.
On peut dire que le réseau BOOL est le guerrier hexagonal du pont à chaînes croisées.
Il convient de mentionner que les articles sur les solutions techniques de BOOL Network ont été inclus dans IEEE TIFS, la meilleure revue dans le domaine de la cryptographie (Lien : cela représente la reconnaissance des solutions techniques de BOOL Network par la communauté de la cryptographie.
Orientation future
BOOL Network fournit actuellement une plate-forme sécurisée de construction de ponts inter-chaînes, et tout tiers peut créer une application de chaîne complète basée sur Bool Network. BOOL Network deviendra le support sous-jacent le plus solide pour toute l'application de la chaîne.
D'un autre point de vue, BOOL Network construit essentiellement une machine de signature décentralisée, qui peut être utilisée non seulement pour vérifier les messages sur la chaîne, mais également pour vérifier les messages hors de la chaîne, ce qui signifie que BOOL Network deviendra un A sûr et fiable oracle à chaîne complète. En outre, le réseau TEE décentralisé construit par BOOL Network fournira également des services informatiques de confidentialité à l'avenir.
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.
Comprendre Bool Network en trois minutes : des guerriers hexagonaux dans des ponts à chaînes croisées
Écrit par : MiddleX
Avec le développement du modèle multi-chaînes, le pont inter-chaînes est devenu une infrastructure importante dans le domaine du Web 3. Quelle que soit l'évolution du modèle de chaîne publique, le cross-chain est toujours une demande rigide constante. Pour les parties de projet Dapp, elles doivent étendre leur champ d'activité à autant de chaînes que possible, d'une Dapp à chaîne unique à une Dapp à chaîne complète ; pour les parties de projet de chaîne publique, tout le monde a la motivation de relier Bitcoin et Ethereum Square, pour importer des actifs et du trafic pour leur propre écologie ; pour les utilisateurs cryptés, ils espèrent également permettre à leurs actifs cryptés de voyager sur différentes chaînes de manière décentralisée, au lieu de s'appuyer sur des échanges centralisés.
Cependant, le pont inter-chaînes, en tant que "véhicule de transport de fonds" entre les chaînes, a été "volé" à plusieurs reprises. Au cours des deux dernières années, presque sans exception, les grands projets de ponts inter-chaînes ont été patronnés par des pirates. Parmi tous les types d'incidents de sécurité liés au cryptage, l'incident du pont inter-chaînes est arrivé en tête de liste avec une perte de près de 2 milliards de dollars. Pour résoudre le problème de sécurité du pont à chaînes croisées, il est imminent d'ajouter une armure à ce "porte-monnaie" "à toit ouvert".
Comment casser le jeu ?
D'une manière générale, il existe deux types d'incidents de sécurité dans les ponts inter-chaînes : l'un est causé par des failles dans le code du contrat, telles que l'absence de vérification de l'adresse du contrat de jeton, ce qui fait que les événements de dépôt de monnaie contrefaite forgés par les attaquants ne sont pas filtrés, et un autre l'exemple est le manque de contrôle d'accès, ce qui conduit à La liste des ensembles de validateurs a été falsifiée ; l'autre est la collusion des nœuds de validation pour voler la clé privée, puis voler les fonds verrouillés par le pont inter-chaînes, ou menthe pièces contrefaites pour voler LP.
La principale raison de la première est que la base de code du pont inter-chaînes n'est pas encore mature, et ces problèmes diminueront progressivement avec l'accumulation de l'expérience de l'industrie. La raison principale de ce dernier est les défauts inhérents à la conception des ponts à chaînes croisées.
Le pont inter-chaînes résout essentiellement le problème de savoir comment une chaîne connaît les événements sur une autre chaîne. Ce problème est divisé en deux aspects, l'un est la transmission et l'autre est la vérification. Dans le pont inter-chaînes, n'importe qui peut transmettre des événements inter-chaînes, la clé est de savoir comment la chaîne cible vérifie que l'événement s'est réellement produit sur la chaîne source. **
Selon différents mécanismes de vérification, les ponts inter-chaînes sont divisés en trois types : nativement vérifiés, localement vérifiés et vérifiés en externe.
Le coût de la vérification native est élevé, ce qui se reflète principalement dans deux points. Premièrement, le coût de la vérification en chaîne est élevé. Exécuter un client léger sur la chaîne et effectuer une vérification SPV sur les événements consommera beaucoup de gaz. Deuxièmement, le coût de développement de la compatibilité avec de nouvelles chaînes est élevé, pour être compatible avec une nouvelle chaîne, il est nécessaire de développer au moins une paire de clients légers. Avec l'essor des récits ZK, il existe actuellement des solutions sur le marché pour améliorer la vérification native grâce à la technologie ZK, ce qui peut réduire efficacement les coûts ci-dessus.Cependant, quelle que soit son optimisation, au moins une preuve ZK doit être vérifiée sur la chaîne, et le coût est d'environ 500 000 Gwei, la vérification n'a besoin que de vérifier une signature (21 000 Gwei) ce qui est tout à fait différent. Par conséquent, la vérification native ne peut pas obtenir un avantage dans la concurrence des prix des ponts inter-chaînes et ne peut pas réaliser la véritable "chaîne complète".
L'authentification locale était autrefois adoptée par des projets bien connus tels que Celer et Connext, mais ces projets, sans exception, ont changé de ton et n'utilisent plus l'authentification locale. La raison en est que l'expérience de transaction de la vérification locale est extrêmement médiocre.Aussi optimisée soit-elle, elle nécessite toujours que l'utilisateur opère au moins deux fois (initier la transaction, déverrouiller le verrou de hachage en direct). De plus, la vérification locale ne s'applique qu'à la chaîne croisée des actifs et ne peut être étendue à aucune chaîne croisée des messages.
Le coût de mise en œuvre de la vérification externe est faible, la surcharge inter-chaînes est faible, elle peut être facilement adaptée à plusieurs chaînes et prend en charge le chaînage inter-chaînes de messages arbitraires. Actuellement, c'est la solution adoptée par la plupart des chaînes inter-chaînes. projets de ponts. Cependant, les ponts inter-chaînes externes introduisent des risques de collusion potentiels en raison de l'introduction de nouvelles hypothèses de confiance. La plupart des ponts inter-chaînes de vérification externe utilisent la technologie MPC (informatique multipartite sécurisée) pour fragmenter la clé privée, de sorte que chaque nœud de vérification externe puisse maîtriser un fragment. Par rapport à la technologie MutiSig (multi-signature) ordinaire, la technologie MPC est plus universelle (il n'y a aucune exigence pour le schéma de signature adopté par la chaîne), le coût de vérification est inférieur (une seule signature doit être vérifiée sur la chaîne), et il est pratique de transférer l'autorité de signature (il suffit d'actualiser le fragment, pas besoin de changer l'adresse) et d'autres avantages, mais cela ne change pas l'essence de la centralisation de la vérification externe et ne peut empêcher la collusion.
Alors, quel type de solution inter-chaînes peut être utilisé pour éliminer le risque de collusion et améliorer la sécurité du pont inter-chaînes sans sacrifier les performances, l'évolutivité et la polyvalence du pont inter-chaînes ?
BOOL Schéma de réseau
BOOL Network est un produit de pont inter-chaînes lancé par LayerBase Labs. LayerBase Labs effectue des recherches dans le domaine inter-chaînes depuis près de 4 ans, au cours desquels il a lancé des produits minimum viables, mais en raison de l'imperfection de ces produits, ils n'ont pas été largement utilisés. Récemment, LayerBase Labs a lancé un pont inter-chaîne basé sur Dynamic Hidden Committee (DHC) : BOOL Network.Cette solution est considérée comme suffisamment parfaite, elle est donc prête à être dévoilée au public.
La solution inter-chaînes de BOOL Network intègre la technologie ZK et la technologie TEE sur la base de la technologie MPC, et transforme l'ensemble de vérificateurs externes en un ** comité caché dynamique inconnu et inconscient **, atteignant un degré élevé d'attributs anti-collusion, réalisant ainsi un haut degré de sécurité.
Prenons un exemple pour illustrer ce qu'est un "club dynamique de membres cachés".
Supposons que vous soyez un général, commandant 1000 soldats et chargé de garder 50 greniers, comment organiserez-vous vos soldats ?
En supposant que tous les greniers ont la même importance, le meilleur arrangement serait de diviser les 1 000 soldats en 50 escouades de 20 hommes chacune pour garder un grenier.
Mais la division des troupes apporte un danger caché. Si plus de la moitié des soldats d'une certaine équipe conspirent, le grenier correspondant peut tomber. C'est-à-dire que si 11 soldats d'une équipe conspirent, ils peuvent vous trahir et voler le grenier. .
C'est quelque chose que vous ne pouvez pas tolérer.Afin d'empêcher ce genre de complot et d'assurer la sécurité du grenier, vous pouvez prendre les mesures suivantes :
De cette façon, les soldats rebelles ne sauront pas avec qui conspirer. Même s'il y a des traîtres convenus à l'avance, ils ne peuvent pas contrôler et ne peuvent pas savoir si les traîtres sont dans la même équipe.
En supposant que pour assurer une forte probabilité de succès dans le complot, le traître doit conspirer avec la majorité de toute votre équipe de 1 000 personnes. C'est sans aucun doute aussi difficile que d'escalader le ciel. Grâce à des méthodes "dynamiques" et "cachées", vous faites en sorte que la fiabilité de chaque escouade atteigne le niveau de toute l'équipe.
C'est exactement le schéma adopté par BOOL Network.
TEE - Bandez les yeux de chaque soldat
BOOL Le réseau nécessite que les nœuds du réseau utilisent des dispositifs TEE pour participer à la vérification des événements inter-chaînes. Le réseau BOOL est complètement ouvert et accessible, et tout sujet disposant d'un dispositif TEE peut devenir un nœud de vérification en engageant $BOOL.
Le nom complet de TEE est Trusted Execution Environment (Trusted ute Environment). Il s'agit d'un environnement informatique s'exécutant sur un appareil donné qui est isolé du système d'exploitation principal, comme une enclave. Cette isolation est renforcée par le matériel. Le processus d'exécution des programmes dans TEE est caché et ne peut être perçu ou interféré par le monde extérieur. Cela rend impossible pour les pirates d'attaquer.
TEE peut exécuter des applications à haute sécurité, telles que l'authentification biométrique, la gestion sécurisée des paiements, etc. Dans notre vie quotidienne, TEE n'est pas étranger, et la vérification des empreintes digitales sur les téléphones mobiles est exécutée en TEE. Cela peut garantir que d'autres applications de téléphonie mobile ne peuvent pas obtenir d'informations sur les empreintes digitales lors de l'utilisation du résultat de la vérification des empreintes digitales.
Pendant le processus de vérification des événements inter-chaînes, les nœuds de vérification externes doivent effectuer des signatures de consensus. À ce stade, la clé privée doit être exposée au réseau, ce qui est très facile à devenir la cible d'attaques de pirates. L'attaque du pont officiel d'Axie Infinity Ronin Bridge en mars 2022 et l'attaque du pont officiel de la chaîne publique Harmony Horizen Bridge en juin 2022 ont été causées par l'obtention de la clé privée du nœud de pont par des pirates. L'utilisation de TEE pour stocker des fragments de clé privée et exécuter des signatures de consensus améliorera considérablement la sécurité et empêchera les pirates d'obtenir des clés privées. Sur cette base, BOOL Network exige que toutes les communications entre les nœuds TEE soient également entièrement cryptées, afin que les pirates ne puissent intercepter aucune information du contenu de la communication entre les nœuds.
Ring VRF - Laisser les soldats tourner au hasard
BOOL Network est conçu comme un outil pour créer un pont inter-chaînes, qui prend en charge tout tiers pour créer un pont inter-chaînes dessus. Lorsqu'un tiers crée un pont inter-chaînes sur le réseau BOOL, il doit créer un DHC (Dynamic Hidden Membership Club) en premier. En supposant que le tiers souhaite que le pont inter-chaînes qu'il crée prenne en charge 10 chaînes, il doit créer 10 DHC, chaque chaîne correspondant à un DHC et tous les messages inter-chaînes envoyés au chaîne sont vérifiées par le DHC.
Chaque fois qu'un tiers crée un pont inter-chaînes via le réseau BOOL, plusieurs DHC seront générés. Comme le nombre de ponts inter-chaînes créés sur le réseau BOOL continue d'augmenter, il peut y avoir des milliers de DHC. Un tiers peut définir le seuil de signature de DHC, et les seuils de signature communs sont 5 sur 9, 13 sur 19 et 15 sur 21.
Il convient de noter que les membres de chaque DHC ne sont pas fixes, mais tournent constamment, et chaque époque sera mélangée une fois. Basé sur la technologie ZK, BOOL Network a développé le protocole Ring VRF, qui peut affecter des membres à chaque DHC de manière complètement aléatoire. Ring VRF générera une preuve ZK pour les membres DHC. Cette preuve ZK représente l'identité temporaire des membres. Les membres DHC utilisent des identités temporaires pour s'identifier et communiquer entre eux, afin de coopérer pour effectuer un certain travail (comme la signature de seuil MPC). Cela garantit l'anonymat des membres du DHC, tant à l'extérieur qu'entre eux.
Dans la même époque, les nœuds TEE de différents DHC peuvent se chevaucher, ou certains nœuds TEE peuvent être inactifs sans entrer dans un DHC. Ces situations sont autorisées, mais RIng VRF donnera à chaque nœud TEE des chances exactement égales.
En bref, **En masquant dynamiquement le mécanisme des membres du comité, BOOL Network a construit une boîte noire incassable. Si un nœud TEE est en état de fonctionnement, personne (y compris l'opérateur du nœud lui-même, les autres nœuds et les attaquants externes) n'a aucun moyen de connaître l'état de fonctionnement du nœud. Dans quel DHC se trouve le nœud ? Sur le même DHC que quels autres nœuds ? Quelles communications consensuelles ont eu lieu ? Quels messages sont signés ? Il n'y a aucun moyen de connaître la vérité. C'est "l'inconnaissable" et "l'inconnaissance" mentionnés ci-dessus. Sous une telle prémisse, tant que le réseau BOOL lui-même est sûr, chaque membre caché dynamique est sûr. Pour assurer une forte probabilité de succès de l'attaque, l'attaquant doit maîtriser la majorité des nœuds du réseau BOOL. Cependant, étant donné que les programmes exécutés dans le TEE ne peuvent pas être altérés, les attaquants peuvent uniquement arrêter le réseau et ne peuvent pas voler les actifs du réseau.
Comment évaluer une solution inter-chaînes
Bien que la sécurité soit le problème le plus urgent à résoudre pour les ponts inter-chaînes, la sécurité n'est pas le seul critère d'évaluation des ponts inter-chaînes. Si pour résoudre un problème, un nouveau problème est créé, cela ne résout pas vraiment le problème.
LayerBase Labs étudie depuis longtemps diverses solutions d'extension basées sur des clients légers, y compris la solution ZK Client. Le principe de base du client ZK est d'étendre le client léger grâce à la technologie ZK, de mettre la vérification de l'en-tête de bloc et la vérification SPV de l'événement de la chaîne source hors de la chaîne, de générer un certificat ZK et de le soumettre à la chaîne, et seulement besoin pour vérifier le certificat ZK sur la chaîne Cela équivaut à vérifier les en-têtes de bloc et les événements de la chaîne source. Bien que ce schéma soit suffisamment sûr, la consommation de gaz sur la chaîne est toujours élevée. Deuxièmement, le circuit ZK sous la chaîne et le client léger sur la chaîne sont relativement bonnes en termes de mise en œuvre technique Complexité, ce qui peut conduire à une plus grande vulnérabilité au niveau du code, affectant ainsi la sécurité du pont inter-chaînes. De plus, afin d'éviter que chaque chaîne n'ait à déployer des clients légers de toutes les autres chaînes, cette solution doit souvent introduire une chaîne de relais (voir la figure ci-dessous), et l'existence de la chaîne de relais rendra le cross-chain qui peut être complété en une seule étape Le processus de livraison des messages a dû être divisé en deux étapes, ce qui a entraîné une augmentation de la latence (délai) de la livraison des messages inter-chaînes.
De nombreuses personnes dans l'industrie préconisent la technologie ZK Client et affirment même que ZK Client est la solution ultime pour les ponts inter-chaînes. Ce que nous voulons dire, c'est que la technologie n'est pas pour le spectacle, et encore moins pour la mode, mais pour résoudre de vrais problèmes.ZK Client crée beaucoup plus de problèmes qu'il n'en résout.
Nous avons également étudié la solution dite Ultra Light Client de LayerZero. LayerZero met le client léger dans l'oracle hors chaîne pour résoudre le problème de surcoût de gaz sur la chaîne, mais vous remettez la responsabilité de la vérification au vérificateur de la cible. chaîne Étant donné l'oracle hors chaîne, il ne s'agit plus d'une vérification native, mais d'une vérification externe, et il existe une hypothèse de sécurité pour l'oracle hors chaîne. Quant au postulat de sécurité revendiqué par LayerZero Labs : "Relayer et oracle machine sont indépendants l'un de l'autre", il n'existe pas dans la réalité, et l'expérience d'attaque de L2BEAT Labs a confirmé ce point.
Nous avons également remarqué le schéma de vérification optimiste adopté par Nomad et Celer. En ajoutant un rôle de challenger sur la base d'une vérification externe, la sécurité de m-de-n peut être améliorée avec succès à 1-de-n. Bien que ce schéma soit bien conçu, le coût est un retard d'environ 30 minutes, ce qui limitera le champ d'application du régime.
Nous avons également trouvé la conception cool d'Avalanche Bridge, qui utilise des nœuds TEE comme vérificateurs externes pour vérifier les événements inter-chaînes, et réalise une expérience inter-chaînes efficace et bon marché grâce à une conception de contrat minimaliste. Mais nous avons également vu que bien qu'Avalanche Bridge puisse conserver en toute sécurité la clé privée pour empêcher les attaquants externes, il ne peut pas empêcher l'attaque par collusion entre les nœuds TEE internes.
En fin de compte, nous avons proposé le système de comité caché dynamique actuel de BOOL Network. Du point de vue de la sécurité, il peut empêcher les attaques de pirates externes et empêcher la collusion interne. En termes de performances et d'expérience, l'expérience inter-chaînes de BOOL Network n'est pas dans le Make any sacrifices sur la base d'une vérification externe et maintenir le même niveau que le pont de vérification externe.
Pour évaluer un pont inter-chaînes, nous pensons que sur la base du triangle impossible, il doit être étendu à six aspects pour une évaluation complète, à savoir le coût (Cost), la rapidité (Speed), la sécurité (Security), la convivialité (Liveness), la généralité , et Scarabilité**.
On peut dire que le réseau BOOL est le guerrier hexagonal du pont à chaînes croisées.
Il convient de mentionner que les articles sur les solutions techniques de BOOL Network ont été inclus dans IEEE TIFS, la meilleure revue dans le domaine de la cryptographie (Lien : cela représente la reconnaissance des solutions techniques de BOOL Network par la communauté de la cryptographie.
Orientation future
BOOL Network fournit actuellement une plate-forme sécurisée de construction de ponts inter-chaînes, et tout tiers peut créer une application de chaîne complète basée sur Bool Network. BOOL Network deviendra le support sous-jacent le plus solide pour toute l'application de la chaîne.
D'un autre point de vue, BOOL Network construit essentiellement une machine de signature décentralisée, qui peut être utilisée non seulement pour vérifier les messages sur la chaîne, mais également pour vérifier les messages hors de la chaîne, ce qui signifie que BOOL Network deviendra un A sûr et fiable oracle à chaîne complète. En outre, le réseau TEE décentralisé construit par BOOL Network fournira également des services informatiques de confidentialité à l'avenir.