Étude sur le problème de la séparation de la liquidité à l'ère du Layer 2
Introduction
Avec le passage d'Ethereum à des solutions d'extension axées sur Layer 2, ainsi que l'essor d'outils comme RaaS, de nombreuses blockchains publiques se développent rapidement. Beaucoup d'entités souhaitent construire leur propre chaîne pour représenter des intérêts différents et poursuivre une valorisation plus élevée. Cependant, l'émergence de nombreuses blockchains publiques rend le développement de l'écosystème difficile à suivre le rythme des blockchains publiques, entraînant de nombreux projets à faire face à une dévaluation lors de leur émission initiale de jetons.
Grâce à la technologie OP Stack, une plateforme d'échange a lancé son propre réseau Layer 2 Base, tandis qu'une autre plateforme a publié Ink ; en utilisant la technologie ZK, une plateforme d'échange a lancé XLayer ; Sony a lancé Soneium, et LINE a lancé Kaia, entre autres. Aujourd'hui, le coût et le seuil technologique pour construire une chaîne ont considérablement diminué, le coût d'exploitation d'une chaîne basée sur OP Stack étant d'environ 10 000 dollars par mois.
L'avenir sera sans aucun doute une époque de coexistence multi-chaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour réaliser l'interopérabilité, en raison des nombreuses applications en aval des entités Web2 qui les soutiennent, il leur sera difficile de construire des applications et d'atteindre un consensus sur la même chaîne.
L'écosystème multichaîne actuel pose un nouveau défi : la liquidité et la dispersion des états. Étant donné que l'existence de chaînes multiples est inévitable, l'interopérabilité est un domaine qui doit être exploré et résolu. Il existe actuellement de nombreuses solutions de liquidité, telles que l'abstraction de chaîne, l'intention, l'exécution de clearing, le cross-chain natif, le ZKSharding, etc., mais leur essence fondamentale est similaire.
Nous utilisons l'architecture Cake, reconnue dans l'industrie, pour présenter de haut en bas la composition des composants clés de l'abstraction inter-chaînes :
Couche d'application (Application Layer)
C'est la couche avec laquelle l'utilisateur interagit directement, et c'est aussi la couche la plus abstraite des solutions de liquidité, car elle masque complètement les détails de la conversion de liquidité. Dans la couche d'application, les utilisateurs interagissent avec l'interface frontale, sans nécessairement comprendre le mécanisme de conversion de liquidité sous-jacent.
Couche d'autorisation (Permission Layer)
Situé en dessous de la couche d'application, l'utilisateur se connecte à un portefeuille sur le dApp et demande un devis pour satisfaire son intention de transaction. Ici, "intention" fait référence au résultat final de transaction attendu par l'utilisateur (c'est-à-dire la sortie), et non au chemin d'exécution spécifique de la transaction.
Gestion des comptes et abstraction des clés (Key Management and Account Abstraction)
En raison de l'existence d'un environnement multichaînes, il est nécessaire d'avoir un système de gestion de compte et d'abstraction adaptable aux différentes chaînes pour maintenir les structures de compte uniques de chaque chaîne. Par exemple, le système de compte centré sur les objets de SUI est complètement différent de celui de l'EVM. One Balance est un projet représentatif dans ce domaine, qui construit un système de compte fiable, sans avoir besoin d'établir un consensus inter-chaînes, mais seulement des engagements fiables entre les systèmes de comptes existants. Near Account permet une gestion abstraite en générant des portefeuilles de comptes multichaînes pour les utilisateurs, ce qui optimise considérablement l'expérience utilisateur et réduit la fragmentation de l'UX. Cependant, en ce qui concerne la liquidité, il intègre principalement les chaînes publiques existantes.
Couche de résolution (Solver Layer)
Cette couche est responsable de la réception et de la mise en œuvre des intentions de transaction des utilisateurs. Le rôle de Solver y est en concurrence pour offrir une meilleure expérience utilisateur, y compris des temps de transaction et des vitesses d'exécution plus rapides. Sur cette base, des projets basés sur l'intention ont construit diverses solutions axées sur les intentions. Des dérivés de ce type d'intention, tels que le composant Predicate, peuvent réaliser les intentions des utilisateurs sous des règles spécifiques.
Couche de règlement (Settlement Layer)
C'est la couche intermédiaire utilisée pour réaliser l'intention de l'utilisateur. Les composants principaux des solutions de liquidité et d'état décentralisé comprennent :
Oracles : utilisés pour obtenir des informations d'état sur d'autres chaînes.
Ponts (Bridges) : responsables du transfert d'informations et de liquidité entre les chaînes.
Pré-confirmation : réduire le temps de confirmation inter-chaînes.
Disponibilité des données (DA) : fournir l'accessibilité des données.
De plus, il faut également prendre en compte la liquidité inter-chaînes, la finalité (Finality), le mécanisme de preuve Layer 2, etc., pour garantir le bon fonctionnement de l'ensemble du système multichaînes.
Solutions
Actuellement, il existe plusieurs solutions sur le marché pour résoudre la liquidité prise les gens pour des idiots. Après avoir examiné de nombreuses solutions, nous avons constaté qu'il existe principalement ces quelques méthodes :
Centré sur RaaS : des solutions de Rollup comme OP Stack, en intégrant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour aider à partager la liquidité et l'état des Rollups construits sur OP Stack. Cela vise à résoudre la décentralisation de la liquidité et de l'état à un niveau supérieur. Un aspect plus détaillé est la conception d'un ordonnanceur partagé distinct, cette solution est davantage axée sur Layer 2 et n'est pas universelle.
Centrées sur le compte : en construisant un portefeuille de compte multi-chaînes, prenant en charge la signature et l'exécution des transactions à travers plusieurs protocoles de blockchain. Le composant clé est le réseau MPC, qui signe les transactions multi-chaînes au nom des utilisateurs. Bien que cette solution puisse grandement résoudre le problème de la fragmentation de l'expérience utilisateur (UX), elle implique une mise en œuvre backend complexe pour les développeurs et ne résout pas fondamentalement la liquidité ni la dispersion des états.
Centré sur le réseau d'intention hors chaîne : l'idée principale est que les utilisateurs envoient des intentions au réseau Solver, et ce rôle de Solver concurrence les offres pour fournir le meilleur temps de réalisation et le meilleur prix de transaction. Ces Solvers peuvent être des agents AI, des CEX, des Market Makers, voire des protocoles intégrés eux-mêmes. Bien que les intentions puissent théoriquement réaliser des opérations inter-chaînes de complexité quelconque, leur mise en œuvre nécessite suffisamment de Solvers de liquidité pour aider, et lorsqu'il s'agit de certaines demandes hors chaîne, il existe une possibilité de fraude par les Solvers.
Centré sur un réseau de liquidité en chaîne : cette direction est spécifiquement optimisée pour les problèmes de liquidité inter-chaînes, mais n'a pas résolu d'autres problèmes de dispersion des états en chaîne. Son cœur est de construire une couche de liquidité, sur laquelle des applications peuvent être construites pour partager la liquidité de l'ensemble de la chaîne.
Axé sur les applications en chaîne : Ce type d'application construit des applications à haute Liquidité en intégrant de grands MM ou d'autres applications tierces. Ce type de projet nécessite de gérer des processus inter-chaînes complexes, ce qui impose des exigences très élevées aux développeurs, et est donc également très susceptible de subir des attaques de hackers.
Résoudre le problème de la liquidité est un sujet très important, dans le monde financier, la liquidité représente souvent tout. Si nous pouvons construire une plateforme intégrant la liquidité, en particulier en réunissant la liquidité fragmentée de l'ensemble de la chaîne, cela aura un potentiel très important, et nous avons également examiné de nombreuses solutions différentes.
Dans les deux catégories ci-dessus, nous pouvons voir que, selon la structure du gâteau, le Settlement Layer est la solution au niveau le plus atomique. Au-dessus de ces solutions atomiques telles que les chaînes croisées, les oracles et les solutions de Pre-Confirmation, se construit un niveau plus abstrait, à savoir le Solver Layer, le Permission Layer et l'Application Layer. Les différentes solutions d'abstraction ou de liquidité que nous avons énumérées ci-dessus, construites dans différentes directions, correspondent à ces différents niveaux et peuvent être comprises comme une relation amont-aval. Cependant, ces solutions ne sont toujours pas des solutions atomiques. Le problème de la fragmentation de la liquidité a engendré de nombreux problèmes dérivés complexes, et c'est pourquoi, en matière d'interopérabilité, une multitude de solutions ont émergé. Mais en essence, cela dépend toujours de ces composants. Nous allons maintenant discuter de quelques projets typiques de concepts d'abstraction de chaînes pour voir comment chacun aborde le problème de la fragmentation de la liquidité depuis son propre point de départ.
INFINIT
INFINIT a construit un service RaaS pour le secteur DeFi, capable de fournir les composants nécessaires à la construction directe de protocoles DeFi, tels que Oracle, Pool Type, IRM, Asset, etc., et peut également offrir des composants activables instantanément comme le Leverage Trading et la Yield Strategy. Cela équivaut à d'autres plateformes de construction d'applications, mais la liquidité finale est placée dans la couche de liquidité d'Infinit. Cependant, à l'heure actuelle, son fonctionnement sous-jacent n'a pas été divulgué. INFINIT a déjà obtenu 6 millions de dollars lors d'un tour de financement par actions.
Réseau Khalani
Khalani a construit trois composants clés, à savoir la couche compatible avec l'intention, la validité et la couche de règlement générale.
Les applications externes ou la couche d'intention peuvent publier des intentions à Khalani, puis la couche de compatibilité des intentions de Khalani peut convertir les intentions externes en un format que le protocole Solver peut reconnaître, le format normalisé utilisé étant le langage Validity. Le nœud Khalani est responsable de la soumission des résultats finaux à la couche de règlement universelle via des ponts inter-chaînes, des technologies de règlement rapide, etc. Ce projet est encore en phase de construction et n'a pas encore divulgué plus de détails sur le travail. Il a obtenu 2,2 millions de dollars lors d'un tour de financement d'amorçage en août.
Liquorice
Liquorice est une application décentralisée qui permet la découverte des prix basée sur des enchères et des pools de liquidité unilatéraux. La mission principale de Liquorice est de fournir aux entreprises de trading professionnelles des outils efficaces de gestion des stocks et de se connecter facilement aux protocoles DeFi principaux lors de la liquidation des transactions. Parallèlement, Liquorice a créé un marché de prêt pour ses transactions de prêt. Cette application se concentre davantage sur le trading lui-même. Elle est encore en phase de développement et a annoncé en juillet avoir levé 1,2 million de dollars lors d'un tour de financement Pre-seed.
Xion
Xion est une mise à niveau de la marque Burnt, qui se concentrait auparavant sur des applications pour consommateurs. Par la suite, l'équipe a découvert un problème de fragmentation énorme dans les interactions sur la chaîne, c'est pourquoi elle a construit Xion pour améliorer ce problème. Xion est basé sur le protocole de consensus Comet BFT. La communication inter-chaînes qu'il utilise est basée sur Cosmos IBC, ce qui la rend plus native et sécurisée que d'autres ponts inter-chaînes. Il a effectué quatre tours de financement.
=nil; Fondation
nil est le marché de puissance de calcul ZK d'Ethereum, un coprocesseur ZK et un développeur de Layer 2, l'équipe ayant une solide expertise en technologie ZK. Ils ont proposé une solution zkSharding, qui utilise la technologie ZK pour étendre horizontalement le réseau principal d'Ethereum, exécuter le traitement parallèle des transactions par le biais de shards et générer des ZKP, tandis que le shard principal valide les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. Le shard principal gère également la distribution des validateurs et des comptes dans les shards d'exécution. Le protocole de consensus utilisé par le comité de validation est également Hotstuff, ce qui est courant dans les projets d'exécution parallèle récents.=nil; L2 a intégré la communication inter-shard dans le protocole dès le départ.
L'idée de base est de construire une architecture de communication inter-chaînes intégrée semblable à IBC à travers une architecture Layer 2 fragmentée, ce qui permettrait de résoudre les problèmes de liquidité et de dispersion des états. Cependant, le concept central n'est pas raisonnable, car le problème que la dispersion de la liquidité cherche à résoudre est celui des multi-chaînes, alors que ce qui est construit est un Layer 2 unique, ce qui signifie que pour résoudre ce problème, toutes les chaînes doivent devenir un fragment de ZK-sharding, ce qui est difficile à réaliser.
ERC-7683
Ethereum est également en train de s'attaquer à ce problème de liquidité inter-chaînes, plusieurs plateformes ayant déjà ouvertement soutenu le standard ERC7683, qui utilise également une méthode inter-chaînes basée sur l'Intent. Son objectif principal est d'établir un standard universel pour les opérations inter-chaînes entre L2 et les sidechains, standardisant les interfaces de commande et de règlement pour permettre une exécution inter-chaînes sans couture. Le cœur de cette initiative est un Filler, qui peut également être considéré comme le rôle de Solver dans l'abstraction de la chaîne. Cette proposition est actuellement examinée par le groupe de travail Cake.
OP Stack
OP Stack, ERC-7683 et zkSharding sont tous des solutions internes d'Ethereum pour la fragmentation de la liquidité entre les Layer 2, respectivement résolvant le problème au niveau de l'architecture, du consensus et de l'application. OP Stack conçoit une solution complète multi Layer 2 pour résoudre simultanément les problèmes de transmission d'informations et de décentralisation du Sequencer. Lorsque vous utilisez l'architecture OP Stack, des contrats inter-chaînes sont automatiquement déployés, avec un Supervisor présent pour contester et éviter la transmission de fausses informations inter-chaînes. Actuellement, plusieurs plateformes d'échange réputées utilisent l'architecture OP Stack.
Parmi eux, le plus typique est
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Analyse des problèmes de fragmentation de la liquidité de l'écosystème Layer 2 et des solutions proposées
Étude sur le problème de la séparation de la liquidité à l'ère du Layer 2
Introduction
Avec le passage d'Ethereum à des solutions d'extension axées sur Layer 2, ainsi que l'essor d'outils comme RaaS, de nombreuses blockchains publiques se développent rapidement. Beaucoup d'entités souhaitent construire leur propre chaîne pour représenter des intérêts différents et poursuivre une valorisation plus élevée. Cependant, l'émergence de nombreuses blockchains publiques rend le développement de l'écosystème difficile à suivre le rythme des blockchains publiques, entraînant de nombreux projets à faire face à une dévaluation lors de leur émission initiale de jetons.
Grâce à la technologie OP Stack, une plateforme d'échange a lancé son propre réseau Layer 2 Base, tandis qu'une autre plateforme a publié Ink ; en utilisant la technologie ZK, une plateforme d'échange a lancé XLayer ; Sony a lancé Soneium, et LINE a lancé Kaia, entre autres. Aujourd'hui, le coût et le seuil technologique pour construire une chaîne ont considérablement diminué, le coût d'exploitation d'une chaîne basée sur OP Stack étant d'environ 10 000 dollars par mois.
L'avenir sera sans aucun doute une époque de coexistence multi-chaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour réaliser l'interopérabilité, en raison des nombreuses applications en aval des entités Web2 qui les soutiennent, il leur sera difficile de construire des applications et d'atteindre un consensus sur la même chaîne.
L'écosystème multichaîne actuel pose un nouveau défi : la liquidité et la dispersion des états. Étant donné que l'existence de chaînes multiples est inévitable, l'interopérabilité est un domaine qui doit être exploré et résolu. Il existe actuellement de nombreuses solutions de liquidité, telles que l'abstraction de chaîne, l'intention, l'exécution de clearing, le cross-chain natif, le ZKSharding, etc., mais leur essence fondamentale est similaire.
Nous utilisons l'architecture Cake, reconnue dans l'industrie, pour présenter de haut en bas la composition des composants clés de l'abstraction inter-chaînes :
Couche d'application (Application Layer)
C'est la couche avec laquelle l'utilisateur interagit directement, et c'est aussi la couche la plus abstraite des solutions de liquidité, car elle masque complètement les détails de la conversion de liquidité. Dans la couche d'application, les utilisateurs interagissent avec l'interface frontale, sans nécessairement comprendre le mécanisme de conversion de liquidité sous-jacent.
Couche d'autorisation (Permission Layer)
Situé en dessous de la couche d'application, l'utilisateur se connecte à un portefeuille sur le dApp et demande un devis pour satisfaire son intention de transaction. Ici, "intention" fait référence au résultat final de transaction attendu par l'utilisateur (c'est-à-dire la sortie), et non au chemin d'exécution spécifique de la transaction.
Gestion des comptes et abstraction des clés (Key Management and Account Abstraction)
En raison de l'existence d'un environnement multichaînes, il est nécessaire d'avoir un système de gestion de compte et d'abstraction adaptable aux différentes chaînes pour maintenir les structures de compte uniques de chaque chaîne. Par exemple, le système de compte centré sur les objets de SUI est complètement différent de celui de l'EVM. One Balance est un projet représentatif dans ce domaine, qui construit un système de compte fiable, sans avoir besoin d'établir un consensus inter-chaînes, mais seulement des engagements fiables entre les systèmes de comptes existants. Near Account permet une gestion abstraite en générant des portefeuilles de comptes multichaînes pour les utilisateurs, ce qui optimise considérablement l'expérience utilisateur et réduit la fragmentation de l'UX. Cependant, en ce qui concerne la liquidité, il intègre principalement les chaînes publiques existantes.
Couche de résolution (Solver Layer)
Cette couche est responsable de la réception et de la mise en œuvre des intentions de transaction des utilisateurs. Le rôle de Solver y est en concurrence pour offrir une meilleure expérience utilisateur, y compris des temps de transaction et des vitesses d'exécution plus rapides. Sur cette base, des projets basés sur l'intention ont construit diverses solutions axées sur les intentions. Des dérivés de ce type d'intention, tels que le composant Predicate, peuvent réaliser les intentions des utilisateurs sous des règles spécifiques.
Couche de règlement (Settlement Layer)
C'est la couche intermédiaire utilisée pour réaliser l'intention de l'utilisateur. Les composants principaux des solutions de liquidité et d'état décentralisé comprennent :
De plus, il faut également prendre en compte la liquidité inter-chaînes, la finalité (Finality), le mécanisme de preuve Layer 2, etc., pour garantir le bon fonctionnement de l'ensemble du système multichaînes.
Solutions
Actuellement, il existe plusieurs solutions sur le marché pour résoudre la liquidité prise les gens pour des idiots. Après avoir examiné de nombreuses solutions, nous avons constaté qu'il existe principalement ces quelques méthodes :
Centré sur RaaS : des solutions de Rollup comme OP Stack, en intégrant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour aider à partager la liquidité et l'état des Rollups construits sur OP Stack. Cela vise à résoudre la décentralisation de la liquidité et de l'état à un niveau supérieur. Un aspect plus détaillé est la conception d'un ordonnanceur partagé distinct, cette solution est davantage axée sur Layer 2 et n'est pas universelle.
Centrées sur le compte : en construisant un portefeuille de compte multi-chaînes, prenant en charge la signature et l'exécution des transactions à travers plusieurs protocoles de blockchain. Le composant clé est le réseau MPC, qui signe les transactions multi-chaînes au nom des utilisateurs. Bien que cette solution puisse grandement résoudre le problème de la fragmentation de l'expérience utilisateur (UX), elle implique une mise en œuvre backend complexe pour les développeurs et ne résout pas fondamentalement la liquidité ni la dispersion des états.
Centré sur le réseau d'intention hors chaîne : l'idée principale est que les utilisateurs envoient des intentions au réseau Solver, et ce rôle de Solver concurrence les offres pour fournir le meilleur temps de réalisation et le meilleur prix de transaction. Ces Solvers peuvent être des agents AI, des CEX, des Market Makers, voire des protocoles intégrés eux-mêmes. Bien que les intentions puissent théoriquement réaliser des opérations inter-chaînes de complexité quelconque, leur mise en œuvre nécessite suffisamment de Solvers de liquidité pour aider, et lorsqu'il s'agit de certaines demandes hors chaîne, il existe une possibilité de fraude par les Solvers.
Centré sur un réseau de liquidité en chaîne : cette direction est spécifiquement optimisée pour les problèmes de liquidité inter-chaînes, mais n'a pas résolu d'autres problèmes de dispersion des états en chaîne. Son cœur est de construire une couche de liquidité, sur laquelle des applications peuvent être construites pour partager la liquidité de l'ensemble de la chaîne.
Axé sur les applications en chaîne : Ce type d'application construit des applications à haute Liquidité en intégrant de grands MM ou d'autres applications tierces. Ce type de projet nécessite de gérer des processus inter-chaînes complexes, ce qui impose des exigences très élevées aux développeurs, et est donc également très susceptible de subir des attaques de hackers.
Résoudre le problème de la liquidité est un sujet très important, dans le monde financier, la liquidité représente souvent tout. Si nous pouvons construire une plateforme intégrant la liquidité, en particulier en réunissant la liquidité fragmentée de l'ensemble de la chaîne, cela aura un potentiel très important, et nous avons également examiné de nombreuses solutions différentes.
Dans les deux catégories ci-dessus, nous pouvons voir que, selon la structure du gâteau, le Settlement Layer est la solution au niveau le plus atomique. Au-dessus de ces solutions atomiques telles que les chaînes croisées, les oracles et les solutions de Pre-Confirmation, se construit un niveau plus abstrait, à savoir le Solver Layer, le Permission Layer et l'Application Layer. Les différentes solutions d'abstraction ou de liquidité que nous avons énumérées ci-dessus, construites dans différentes directions, correspondent à ces différents niveaux et peuvent être comprises comme une relation amont-aval. Cependant, ces solutions ne sont toujours pas des solutions atomiques. Le problème de la fragmentation de la liquidité a engendré de nombreux problèmes dérivés complexes, et c'est pourquoi, en matière d'interopérabilité, une multitude de solutions ont émergé. Mais en essence, cela dépend toujours de ces composants. Nous allons maintenant discuter de quelques projets typiques de concepts d'abstraction de chaînes pour voir comment chacun aborde le problème de la fragmentation de la liquidité depuis son propre point de départ.
INFINIT
INFINIT a construit un service RaaS pour le secteur DeFi, capable de fournir les composants nécessaires à la construction directe de protocoles DeFi, tels que Oracle, Pool Type, IRM, Asset, etc., et peut également offrir des composants activables instantanément comme le Leverage Trading et la Yield Strategy. Cela équivaut à d'autres plateformes de construction d'applications, mais la liquidité finale est placée dans la couche de liquidité d'Infinit. Cependant, à l'heure actuelle, son fonctionnement sous-jacent n'a pas été divulgué. INFINIT a déjà obtenu 6 millions de dollars lors d'un tour de financement par actions.
Réseau Khalani
Khalani a construit trois composants clés, à savoir la couche compatible avec l'intention, la validité et la couche de règlement générale.
Les applications externes ou la couche d'intention peuvent publier des intentions à Khalani, puis la couche de compatibilité des intentions de Khalani peut convertir les intentions externes en un format que le protocole Solver peut reconnaître, le format normalisé utilisé étant le langage Validity. Le nœud Khalani est responsable de la soumission des résultats finaux à la couche de règlement universelle via des ponts inter-chaînes, des technologies de règlement rapide, etc. Ce projet est encore en phase de construction et n'a pas encore divulgué plus de détails sur le travail. Il a obtenu 2,2 millions de dollars lors d'un tour de financement d'amorçage en août.
Liquorice
Liquorice est une application décentralisée qui permet la découverte des prix basée sur des enchères et des pools de liquidité unilatéraux. La mission principale de Liquorice est de fournir aux entreprises de trading professionnelles des outils efficaces de gestion des stocks et de se connecter facilement aux protocoles DeFi principaux lors de la liquidation des transactions. Parallèlement, Liquorice a créé un marché de prêt pour ses transactions de prêt. Cette application se concentre davantage sur le trading lui-même. Elle est encore en phase de développement et a annoncé en juillet avoir levé 1,2 million de dollars lors d'un tour de financement Pre-seed.
Xion
Xion est une mise à niveau de la marque Burnt, qui se concentrait auparavant sur des applications pour consommateurs. Par la suite, l'équipe a découvert un problème de fragmentation énorme dans les interactions sur la chaîne, c'est pourquoi elle a construit Xion pour améliorer ce problème. Xion est basé sur le protocole de consensus Comet BFT. La communication inter-chaînes qu'il utilise est basée sur Cosmos IBC, ce qui la rend plus native et sécurisée que d'autres ponts inter-chaînes. Il a effectué quatre tours de financement.
=nil; Fondation
nil est le marché de puissance de calcul ZK d'Ethereum, un coprocesseur ZK et un développeur de Layer 2, l'équipe ayant une solide expertise en technologie ZK. Ils ont proposé une solution zkSharding, qui utilise la technologie ZK pour étendre horizontalement le réseau principal d'Ethereum, exécuter le traitement parallèle des transactions par le biais de shards et générer des ZKP, tandis que le shard principal valide les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. Le shard principal gère également la distribution des validateurs et des comptes dans les shards d'exécution. Le protocole de consensus utilisé par le comité de validation est également Hotstuff, ce qui est courant dans les projets d'exécution parallèle récents.=nil; L2 a intégré la communication inter-shard dans le protocole dès le départ.
L'idée de base est de construire une architecture de communication inter-chaînes intégrée semblable à IBC à travers une architecture Layer 2 fragmentée, ce qui permettrait de résoudre les problèmes de liquidité et de dispersion des états. Cependant, le concept central n'est pas raisonnable, car le problème que la dispersion de la liquidité cherche à résoudre est celui des multi-chaînes, alors que ce qui est construit est un Layer 2 unique, ce qui signifie que pour résoudre ce problème, toutes les chaînes doivent devenir un fragment de ZK-sharding, ce qui est difficile à réaliser.
ERC-7683
Ethereum est également en train de s'attaquer à ce problème de liquidité inter-chaînes, plusieurs plateformes ayant déjà ouvertement soutenu le standard ERC7683, qui utilise également une méthode inter-chaînes basée sur l'Intent. Son objectif principal est d'établir un standard universel pour les opérations inter-chaînes entre L2 et les sidechains, standardisant les interfaces de commande et de règlement pour permettre une exécution inter-chaînes sans couture. Le cœur de cette initiative est un Filler, qui peut également être considéré comme le rôle de Solver dans l'abstraction de la chaîne. Cette proposition est actuellement examinée par le groupe de travail Cake.
OP Stack
OP Stack, ERC-7683 et zkSharding sont tous des solutions internes d'Ethereum pour la fragmentation de la liquidité entre les Layer 2, respectivement résolvant le problème au niveau de l'architecture, du consensus et de l'application. OP Stack conçoit une solution complète multi Layer 2 pour résoudre simultanément les problèmes de transmission d'informations et de décentralisation du Sequencer. Lorsque vous utilisez l'architecture OP Stack, des contrats inter-chaînes sont automatiquement déployés, avec un Supervisor présent pour contester et éviter la transmission de fausses informations inter-chaînes. Actuellement, plusieurs plateformes d'échange réputées utilisent l'architecture OP Stack.
Parmi eux, le plus typique est