Introduction

Depuis la création de l'industrie de la blockchain, d'innombrables L1/L2 ont vu le jour et presque toutes les chaînes publiques ont développé leur propre écosystème DeFi. Certaines personnes n'interagissent que sur des chaînes publiques spécifiques, tandis que d'autres espèrent trouver des opportunités de profit, telles que le commerce et l'exploitation minière, sur différentes chaînes. Parmi ceux-ci, le transfert de fonds entre chaînes est devenu une nécessité indispensable.

Outre les utilisateurs ordinaires, de nombreuses parties au projet ont également besoin de transférer des fonds entre différentes chaînes, de guider les liquidités sur différentes chaînes et de parvenir à "une monnaie pour de multiples usages".

Cependant, les différentes blockchains sont des systèmes de consensus isolés, et il n'existe aucun moyen pour les fonds de passer directement d'une chaîne à l'autre. L'essence des fonds inter-chaînes est que le pont inter-chaînes agit comme une contrepartie publique, recevant les fonds des utilisateurs de la chaîne source et envoyant de l'argent aux utilisateurs de la chaîne cible. (émettre des actifs mappés ou libérer des fonds pour les utilisateurs à partir du pool de liquidités réservé par la chaîne cible).

Quelle est la meilleure façon de réaliser des fonds inter-chaînes ? Au début, les gens faisaient encore confiance aux échanges centralisés. Il fut un temps où l'on disait : "Les bourses centralisées sont les meilleurs ponts entre les chaînes" : "Les échanges centralisés sont les meilleurs ponts entre les chaînes. Cependant, l'opération "échange-retrait d'enjeu" est très lourde, et les gens espèrent avoir une chaîne pure. De cette manière, les fonds peuvent être transférés plus directement.

En outre, par rapport aux échanges centralisés, les ponts inter-chaînes peuvent effectuer des échanges de messages plus généraux, qui ne se limitent pas aux transferts de fonds. Par exemple, si vous utilisez une dApp de prêt cross-chain pour fournir un enjeu de la chaîne A et prêter des actifs sur la chaîne B, vous devez utiliser la messagerie cross-chain.

Si vous examinez l'origine historique de la chaîne croisée, vous constaterez qu'elle remonte aux premiers stades du développement de la technologie blockchain. À l'époque, l'émergence de différentes chaînes publiques a fait prendre conscience que le problème de l'interopérabilité entre les chaînes devait être résolu, faute de quoi de nombreux îlots d'information/de fonds apparaîtraient. Au fil du temps, les gens ont proposé différents types de méthodes de chaîne croisée, formant progressivement le modèle général de chaîne croisée d'aujourd'hui.

Nous expliquons ci-dessous quelques développements de la technologie de la chaîne croisée.

1. La méthodologie

Trouvez des contreparties, réfléchissez-y vous-même, quelle est la méthode la plus intuitive pour traverser la chaîne ? Supposons que vous ayez 100 USDT sur la chaîne A et que vous souhaitiez les transférer sur la chaîne B. Il se trouve qu'une personne possède 100 USDT sur la chaîne B et qu'elle souhaite transférer des USDT sur la chaîne A. Vous avez tous les deux vu que cela convenait parfaitement et vous vous êtes immédiatement entendus. Mais lorsque vous avez transféré des USDT à l'adresse de l'autre partie sur la chaîne A, il l'a regretté et n'a pas transféré ses USDT sur la chaîne B à votre adresse. Ce modèle d'échange P2P n'est donc pas très fiable. Premièrement, l'autre partie peut rompre le contrat et vous faire subir des pertes sans aucune garantie ; deuxièmement, cette contrepartie n'est pas facile à trouver et vous devrez peut-être attendre longtemps avant d'en trouver une qui corresponde au montant que vous souhaitez transférer, mais la direction du transfert n'est pas la même.

2. Services de notaire

2.1 Notaire individuel

Nous avons donc pensé que, puisque l'autre partie pouvait rompre le contrat, je pouvais trouver un tiers de confiance pour effectuer les transactions. Je lui donne d'abord l'argent sur la chaîne source, puis il promet de me transférer l'argent sur la chaîne cible. Par exemple, cette personne possède des actifs à la fois sur la chaîne A et sur la chaîne B et elle garantit que tant qu'elle recevra 100 USDT de ma part sur la chaîne A, elle me transférera 100 USDT de la chaîne B.

C'est bien mieux que le premier échange d'actifs P2P entre chaînes, car il existe une contrepartie publique de confiance, qui a entre les mains une chose magique appelée "liquidité", et vous pouvez effectuer des transactions avec elle à tout moment.

En d'autres termes, votre transaction avec lui devient une transaction "point à pool" plutôt qu'une transaction "point à point". Mais vous ne vous sentez toujours pas à l'aise. Si vous échangez 100 USDT avec lui, c'est parfait. Et si vous voulez échanger 1 million d'USDT avec lui ? Même s'il avait une réputation relativement bonne, il a quand même pris l'argent et s'est enfui.

Après tout, ce notaire introduit une sorte de centralisation, ce qui n'est toujours pas la méthode "Trustless cross-chain" que nous souhaitons.

2.2 Notaires multiples (MultiSig)

Et si ce notaire n'est pas une personne, mais un groupe de personnes ? Nous pouvons établir un compte cogéré, et plusieurs signataires gèrent conjointement le compte. Ils doivent signer un message. Ce n'est que lorsque le nombre de signatures atteint un certain seuil (généralement 2/3) que les fonds sont transférés.

Dans ce cas, si un petit nombre d'entre eux (pas plus d'un tiers) ont une mauvaise idée et veulent collecter de l'argent auprès de moi sur la chaîne source, mais ne veulent pas m'envoyer d'argent sur la chaîne cible, ou sont hors ligne, cela n'a pas d'importance. Un autre notaire honnête signerait quand même et transfèrerait l'argent qui m'est dû.

Cette solution est plus fiable, affaiblit le risque de centralisation et est plus sûre. Par exemple, s'il y a 20 notaires réputés au total, la probabilité qu'ils agissent mal en même temps reste très faible. (Cela n'inclut pas les situations comme Multichain où 20 nœuds sont gérés par une seule personne, ou les situations comme Axie cross-chain bridge où des pirates ont volé 2/3 des clés de signature du notaire).

2.3 Notaires publics multiples (MPC)

Cependant, la méthode de gestion des comptes à signatures multiples présente également de nombreux inconvénients.

Les multi-signatures rendent les règles de signature plus facilement accessibles. S'il s'agit d'un système de signature 5/7, le code du contrat intelligent du portefeuille multi-signature indiquera le nombre de signataires, et les pirates pourront rechercher ces signataires de manière ciblée et attendre des occasions de voler la clé privée.

La multi-signature nécessite une adaptation aux différentes chaînes publiques. Par exemple, certaines chaînes publiques ne prennent pas en charge les contrats intelligents, de sorte que vous devez utiliser les primitives cryptographiques spécialisées de la chaîne pour mettre en œuvre des comptes à signatures multiples. Si ce n'est pas le cas, votre portefeuille multi-signatures ne pourra pas fonctionner.

Le signataire de signatures multiples ne peut pas être modifié une fois que le signataire a été choisi. Par exemple, si vous souhaitez passer du schéma de signature 5/7 au schéma 6/8, ou si vous souhaitez changer de signataire, vous devez redéployer le contrat multisignature et transférer les fonds vers le nouveau contrat multisignature.

La première solution de chaîne croisée pour les dérivés du BTC, le tBTC, utilisait la méthode de la multi-signature, qui a été éliminée parce qu'elle était boiteuse et difficile à utiliser. La plupart des ponts à chaîne croisée actuels adoptent la méthode MPC la plus avancée.

Le nom complet de Multi-Party Computation est Multi-Party-Computation (Multi-Party Secure Computation), qui est une technologie de partage de clés privées. Un compte multi-signature gère un compte avec plusieurs clés privées, tandis qu'un compte MPC gère un compte avec une clé privée. La clé privée est divisée en plusieurs fragments. Les signataires multiples détiennent chacun un fragment de clé privée. Lorsque le nombre de signataires est de Une signature complète ne peut être synthétisée que lorsque le seuil est atteint, et la clé privée complète ne sera pas exposée au cours du processus de signature. Lorsqu'une signature est requise, par exemple, 5/7 fragments de clé privée sont utilisés pour signer chacun d'eux, et plusieurs sous-signatures sont fusionnées pour former une signature légale finale. Ainsi, ce que vous voyez sur la chaîne est une signature unique et ordinaire. Vous ne pouvez pas savoir si elle provient du compte MPC, et encore moins qui en est le signataire, ni le nombre de fragments de clé privée et les règles de signature spécifiques. Il peut s'adapter à la plupart des chaînes publiques mieux que les portefeuilles multi-signatures. Le MPC est une technologie de signature et n'a rien à voir avec la chaîne. Un compte MPC est un compte ordinaire. Qu'une chaîne publique prenne ou non en charge les contrats intelligents, un compte cogéré peut être créé grâce à la technologie MPC. Il peut prendre en charge des ajustements plus souples des règles de signature, tels que la modification du nombre de fragments de clé privée et des seuils de signature à tout moment, et vous pouvez également changer de signataire à tout moment. Il vous suffit de partager à nouveau la clé privée.

3. Autres mesures de sécurité

3.1 Séparation du chaud et du froid

Après que le dépôt du notaire a reçu mes 100 USDT sur la chaîne A, il a transféré 100 USDT à mon adresse sur la chaîne B. Quel devrait être le processus de déclenchement de ce comportement ?

Supposons que chaque membre du notariat dispose d'une machine qui surveille les transactions sur la chaîne A. Lorsqu'ils ont découvert que j'avais transféré 100 USDT sur le compte de dépôt de la passerelle entre les chaînes, cette transaction indiquait que j'espérais être nommé sur la chaîne B. Recevez ces USDT à l'adresse de l'utilisateur 2.

À ce moment-là, les notaires ont signé conjointement et transféré à l'utilisateur 100 USDT sur le compte pont de la chaîne croisée de la chaîne B. Ce processus doit être codé et exécuté automatiquement, sinon le notaire devrait être en ligne en temps réel et intervenir immédiatement après avoir reçu la demande, ce qui est trop irréaliste.

Ce programme automatisé comprendra plusieurs parties

1. Programme de contrôle : Responsable du contrôle des transactions sur la chaîne d'approvisionnement. Pour filtrer les transactions non pertinentes ou non valides, cette étape peut effectuer une vérification de base du format ;

2. Procédure de vérification : Il s'agit du client du nœud léger (qui peut également être un nœud complet) de la blockchain prise en charge, chargé de vérifier qu'une transaction sur la chaîne source qui interagit avec le contrat passerelle inter-chaînes est intégrée dans un bloc et placée sur la chaîne. ;

3. Procédure de signature : Responsable de la signature et de l'initiation des transactions de transfert vers les utilisateurs de la chaîne cible.

Mais l'automatisation pose également un problème : le programme automatisé peut être attaqué et manipulé par des pirates informatiques. Par conséquent, pour contrôler les risques, les ponts de la chaîne transversale prendront des mesures pour séparer le chaud et le froid. Le programme automatisé contrôle le raccourci clavier et le montant du transfert est limité. Pour les transferts importants, le notaire doit utiliser la clé froide pour signer manuellement. Les règles de séparation à chaud et à froid peuvent être mises en œuvre dans le compte MPC.

3.2 Isolation des risques

S'il y a un bogue, ne voulez-vous pas le régler en une seule fois ? Il est donc nécessaire d'isoler la réserve de capitaux et d'utiliser plusieurs comptes de dépôt pour gérer les fonds de liquidité. Par exemple, selon l'isolement entre les différentes chaînes publiques, A et B, B et C, et C et D sont tous des pools de capitaux indépendants.

3.3 TEE

Les programmes de contrôle et de signature automatisés exécutés par le notaire peuvent être exécutés sur des dispositifs TEE, ce qui peut accroître considérablement la difficulté des attaques de pirates informatiques. TEE signifie Trusted Execute Environment (environnement d'exécution de confiance), c'est-à-dire un environnement informatique exécuté sur un dispositif donné qui est isolé du système d'exploitation principal, comme une enclave.

Cette isolation est renforcée par le matériel avec une sécurité extrêmement élevée, de sorte que les TEE peuvent exécuter des applications avec des exigences de sécurité élevées, telles que la gestion des clés de chiffrement, l'authentification biométrique, le traitement sécurisé des paiements, etc.

3.4 La PoA va à gauche, la PoS va à droite

Pour rendre les passerelles inter-chaînes plus sûres, il y a deux directions dans la sélection des notaires :

La première consiste à choisir, dans la mesure du possible, de grandes entreprises et des institutions bien connues jouissant d'une bonne réputation. Pour ces institutions, le coût du mal est extrêmement élevé et elles risquent de perdre des années de bonne volonté. En outre, essayez de les diversifier le plus possible sur le plan géographique (en évitant de les concentrer dans la même juridiction).

Par exemple, le projet de pont transversal Wormhole a choisi ce modèle. Ses 19 nœuds sont soutenus par de grandes institutions réputées, dotées de fonds importants. Il s'agit de la méthode PoA.

Une autre solution consiste à admettre les notaires sans autorisation, mais à leur imposer un piquetage. S'ils se comportent mal, leur mise sera réduite. C'est ainsi que fonctionne le PoS. C'est ce qu'utilise ZetaChain.

Il est difficile de tirer directement une conclusion arbitraire sur la question de savoir laquelle des deux méthodes est la meilleure et laquelle est la pire. Cela dépend de la manière dont les parties au projet de pont inter-chaînes se débrouillent dans leurs directions respectives.

Qu'il s'agisse de PoA ou de PoS, vous pouvez transformer le pont inter-chaînes directement en une chaîne publique. Chaque nœud exécute le même programme, et toutes les demandes et tous les processus de traitement entre chaînes sont enregistrés sur cette chaîne. La chaîne elle-même peut également accueillir des applications, devenant ainsi un centre écologique.

3.5 Observateur

Un autre moyen de renforcer la sécurité consiste à définir un rôle d'observateur. Ce rôle consiste à surveiller le comportement de la chaîne croisée et, si des problèmes sont découverts, à signaler les transactions en cours de chaîne et les transactions interrompues. Étant donné que les observateurs ont besoin d'un délai pour réagir, l'heure d'arrivée des transferts entre chaînes peut être retardée. Par conséquent, les observateurs n'interviendront que si les utilisateurs acceptent des retards de transfert pour des transactions de grande valeur ou des opérations sensibles entre chaînes.

Autres solutions inter-chaînesSerrure de hachageRetour à la première méthode mentionnée dans cet article : P2P à la recherche de contreparties pour l'échange d'actifs entre chaînes. Si nous craignons que la contrepartie ne rembourse pas le prêt, nous pouvons mettre en place un mécanisme. Lorsque quelqu'un revient sur sa parole, l'autre partie peut récupérer l'argent et le restituer intact. Il s'agit du verrouillage par hachage, qui utilise astucieusement des verrous de hachage et des verrous temporels. Il oblige le destinataire des fonds à confirmer le paiement avant la date limite et à générer une preuve de réception sur la chaîne source. Avec cette preuve de réception, le payeur pourra obtenir les actifs équivalents du destinataire dans la chaîne cible. Dans le cas contraire, les deux parties s'engagent à rembourser les fonds par la voie initiale.

Toutefois, cette méthode ne permet que d'échanger des fonds et ne peut pas effectuer de transfert général d'informations entre les chaînes. Même du point de vue du transfert de fonds entre chaînes, l'expérience de l'utilisateur est très mauvaise : si la fluctuation des prix des devises est défavorable à la contrepartie (fournisseur de liquidités), elle peut rationnellement choisir de ne pas effectuer la transaction ; pour effectuer un échange entre chaînes, l'utilisateur et la contrepartie doivent tous deux signer deux fois. Par conséquent, en tant que solution inter-chaîne, les verrous de temps de hachage ont été éliminés. Les premiers ponts inter-chaînes (tels que cBridge et Connext) qui utilisaient cette solution ont changé de voie. Client léger sur la chaîneCette méthode consiste à déployer directement le contrat de client léger de la chaîne source sur la chaîne cible. Si vous déployez un contrat sur une chaîne, tous les nœuds de la chaîne exécuteront le code du contrat que vous avez déployé.

Par conséquent, la solution du client léger sur la chaîne permet à la chaîne cible de vérifier directement les transactions de la chaîne source. Cette méthode est extrêmement sûre, mais c'est aussi la plus coûteuse. Le caractère onéreux se reflète dans les aspects suivants : Le contrat de client léger de la chaîne cible doit recevoir et vérifier le nouvel en-tête de bloc de la chaîne source en temps réel. Ce processus consomme beaucoup de gaz. Même si ZK est utilisé pour obtenir une preuve concise, la consommation de gaz pour vérifier une preuve ZK ne sera pas inférieure à 400 000 gaz (EVM par exemple), dans le schéma MPC, tout ce qui doit être vérifié sur la chaîne est une signature, et la consommation de gaz n'est que d'un peu plus de 20 000, soit une différence de 20 fois ! Utiliseriez-vous un pont plus sûr mais 20 fois plus cher ?

La quantité de travail nécessaire à l'élaboration de contrats avec des clients légers est énorme. Pour rendre le pont inter-chaînes compatible avec des chaînes plus hétérogènes, vous devez mettre en œuvre les contrats clients légers d'autres chaînes dans des environnements de développement complètement différents, ce qui représente un défi de taille pour les développeurs. Cela conduit à une plus grande probabilité de bogues dans la rédaction des contrats, c'est-à-dire que la sécurité d'un pont de client léger n'est qu'au niveau théorique, mais en termes de pratique d'ingénierie, il est très peu sûr. Pour réduire la quantité de travail de développement, une solution réalisable consiste à introduire une chaîne de relais et à laisser toutes les chaînes établir des contrats de client léger avec cette chaîne de relais. Cela peut en effet réduire la charge de travail de C(n,2) à n, mais pas trop petit. Le transfert direct de la chaîne source à la chaîne cible est devenu un transfert de second ordre de la chaîne source → chaîne relais → chaîne cible, ce qui entraîne une consommation de gaz et une perte de temps supplémentaires.

Par conséquent, la solution technique du client léger ne peut actuellement pas être utilisée pour construire un pont inter-chaînes plus universel.

Fin du jeu

Tout d'abord, les différentes chaînes publiques ont des approches différentes et disposent de ressources différentes pour les soutenir. Tant qu'ils ne s'avoueront pas vaincus, l'écosystème existera. Même si le développement n'est pas très bon à court terme, il peut un jour être amélioré et reprendre vie. L'intérêt d'une telle infrastructure sous-jacente est de voir qui peut persister plus longtemps et qui peut s'adapter rapidement au marché.

Bitcoin et Ethereum ne peuvent pas résoudre tous les scénarios d'application, ou dans un certain segment, il y a toujours des gens qui n'aiment pas la première place, alors ils créent une nouvelle roue, donc l'avenir sera multi-chaîne. À l'avenir, la couche inférieure ne sera plus une chaîne, et l'avenir doit donc être multi-écologique. Le transfert de fonds et de messages entre plusieurs écosystèmes nécessite une technologie inter-chaîne/inter-écologique !

Qu'est-ce qui préoccupe le plus les utilisateurs lorsqu'il s'agit de la chaîne croisée ? Rien de plus que les points suivants :

Rapidité : Combien de temps faut-il pour qu'une opération inter-chaînes soit achevée ?

Frais : Quel est le montant à payer pour une opération inter-chaînes ?

Sécurité : Le pont inter-chaînes est-il sûr et les fonds seront-ils perdus ?

Liquidité : Y a-t-il suffisamment de liquidités pour soutenir ma transaction et un impact acceptable sur les prix ?

Étendue de la connexion : Combien de chaînes soutenez-vous ? Prenez-vous en charge les chaînes que je dois utiliser dans le cadre d'opérations inter-chaînes ?

Expérience : Le fonctionnement de la chaîne croisée est-il pratique, notamment en ce qui concerne la prise en charge du paiement au gaz, l'exactitude de l'estimation des coûts, la prise en charge de l'interrogation de l'état d'avancement et de la visualisation du navigateur, la fréquence des pannes, la manière de gérer les pannes, etc.

Examinons tout d'abord les caractéristiques de certains projets sous trois angles relativement clairs : la sécurité, le coût et l'étendue de la connexion.

Cliquez sur le lien pour consulter le tableau clair (le tableau est constamment mis à jour) :

https://docs.google.com/spreadsheets/d/1LKlbd5KJUnQIx3ZBTgyMADhxHtWVwBH9qDRm765tPMw/

Pour expliquer pleinement le pont interchaînes, de nombreux détails dimensionnels doivent être examinés, notamment toutes les dimensions et l'analyse des données dans le tableau ci-dessus. Quels sont donc les facteurs dont vous tenez compte lorsque vous traversez des chaînes ? Quels sont les ponts inter-chaînes que vous utilisez le plus souvent ? Selon vous, quels sont les aspects sur lesquels les ponts inter-chaînes devraient se concentrer pour être optimisés ? Si vous avez des idées, n'hésitez pas à les communiquer à l'auteur.

Clause de non-responsabilité：

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