Étude sur le problème de la division de la liquidité à l'ère du Layer 2
Avec le passage d'Ethereum à des solutions d'extension axées sur le Layer 2 et l'émergence d'outils comme RaaS, de nombreuses blockchains publiques se développent rapidement. De nombreuses entités souhaitent construire leur propre chaîne pour représenter différents intérêts et rechercher 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, ce qui entraîne de nombreux projets à voir leur prix chuter dès la TGE.
Grâce à OP Stack, une plateforme de trading a lancé son propre Base Layer 2, tandis qu'une autre plateforme a publié Ink ; grâce à la technologie ZK, une plateforme de trading a lancé XLayer ; Sony a publié Soneium, et LINE a lancé Kaia, entre autres. Aujourd'hui, les coûts et les barrières technologiques pour construire une chaîne ont considérablement diminué, et le coût d'exploitation d'une chaîne basée sur OP Stack est d'environ 10 000 dollars par mois.
L'avenir sera sans aucun doute une ère de coexistence multi-chaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour atteindre l'interopérabilité, il est difficile pour les entités Web2 qui les soutiennent, ayant de nombreuses applications en aval, de construire des applications et d'atteindre un consensus sur la même chaîne.
L'écosystème multichaînes actuel apporte un nouveau défi : la liquidité et la dispersion des états. Étant donné que l'existence de plusieurs chaînes est inévitable, l'interopérabilité est un domaine qui doit être exploré et résolu. Actuellement, il existe de nombreuses solutions de liquidité, comme nous avons tous entendu parler de l'abstraction de chaîne, de l'intention, de l'exécution de clearing, du cross-chain natif, du ZKSharding, mais leur essence fondamentale est la même.
Nous utilisons l'architecture Cake, reconnue dans l'industrie, pour présenter de haut en bas la composition des composants principaux de l'abstraction inter-chaînes :
Couche d'application(Application Layer)
C'est la couche d'interaction directe avec l'utilisateur, 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 forcément comprendre le mécanisme de conversion de Liquidité sous-jacent.
couche de permission (Permission Layer)
Situé sous la couche d'application, l'utilisateur satisfait son intention de transaction en connectant son portefeuille à une dApp et en demandant un devis. 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 de couche (Gestion des clés et abstraction de compte)
En raison de l'existence d'un environnement multi-chaînes, il est nécessaire d'avoir un système de gestion des comptes et d'abstraction adapté aux différentes chaînes pour maintenir la structure unique des comptes de chaque chaîne. Par exemple, le système de comptes centré sur les objets de SUI est complètement différent de l'EVM. One Balance est un projet représentatif dans ce domaine, qui a construit un système de comptes fiable, sans avoir besoin d'établir un consensus inter-chaînes, mais simplement en s'appuyant sur des engagements de confiance entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant des portefeuilles de comptes multi-chaînes pour les utilisateurs, optimisant ainsi considérablement l'expérience utilisateur et réduisant la fragmentation de l'UX. Cependant, en ce qui concerne la liquidité, elle intègre principalement les chaînes publiques existantes.
Résoudre la couche (Solver Layer)
Cette couche est responsable de la réception et de la réalisation des intentions de transaction des utilisateurs. Le rôle de Solver y concourt afin d'offrir une meilleure expérience utilisateur, notamment des temps de transaction plus rapides et une exécution plus rapide. Sur cette base, des projets basés sur les intentions, tels qu'Anoma, ont construit diverses solutions axées sur les intentions. Des dérivés de ce type d'intention, comme le composant Predicate, peuvent réaliser les intentions des utilisateurs sous des règles spécifiques.
Couches de règlement ( Settlement Layer )
C'est la couche intermédiaire utilisée pour réaliser l'intention des utilisateurs. Les composants clés des solutions de liquidité et d'état décentralisé comprennent :
Oracle (: utilisé pour obtenir des informations sur l'état d'autres chaînes.
Ponts inter-chaînes ) : responsables de la transmission des informations et de la liquidité entre les chaînes.
Confirmation anticipée (: 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, et d'autres facteurs afin d'assurer le fonctionnement efficace de l'ensemble du système multichaîne.
![Recherche sur le problème de la Liquidité dans l'ère Layer 2])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
) solution
Actuellement, il existe plusieurs solutions sur le marché pour résoudre la Liquidité et prendre les gens pour des idiots. Après avoir examiné un grand nombre de solutions, nous avons constaté qu'il existe principalement ces quelques méthodes :
Centré sur RaaS : des solutions de Rollup comme OP Stack, en ajoutant 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 dispersion de la liquidité et de l'état à un niveau supérieur. Un aspect plus spécifique est la conception d'ordonnanceurs partagés individuels, cette solution est plus axée sur Layer 2, n'ayant pas de caractère universel, comme Astria, Espresso et Flashbots.
Centré sur le compte : similaire à NEAR, créer un portefeuille de compte sur toute la chaîne, prenant en charge la signature et l'exécution des transactions à travers plusieurs protocoles de blockchain grâce à une technologie appelée « signature de chaîne ». Le composant clé est le réseau MPC, qui remplace l'utilisateur pour signer les transactions multichaînes. Bien que cette solution puisse grandement résoudre le problème de la fragmentation de l'UX, elle implique une mise en œuvre backend complexe pour les développeurs et ne résout pas fondamentalement la Liquidité et la dispersion des états.
Centré sur le réseau d'intentions hors chaîne : c'est-à-dire le réseau Solver dans notre diagramme d'architecture de gâteau « Introduction », l'essentiel est que l'utilisateur envoie des intentions au réseau Solver, le rôle de Solver est de faire concurrence sur les offres, en fournissant le meilleur temps de réalisation et le meilleur prix de transaction. Ces Solvers peuvent être des agents IA, des CEX, des Market Makers ou même des protocoles d'intégration eux-mêmes comme Liquorice, etc. Les projets dans ce domaine incluent Anoma, Khalani, Enso, aori et Valantis. Bien que les intentions puissent théoriquement réaliser des opérations inter-chaînes de complexité arbitraire, leur mise en œuvre nécessite cependant un nombre suffisant de Solvers de Liquidité pour aider, et lorsqu'il y a des demandes hors chaîne, il existe un risque de fraude chez les Solvers. Si des méthodes comme la preuve de fraude sont introduites, la difficulté de mise en œuvre du réseau Solver sera plus élevée et le seuil de fonctionnement des Solvers sera également plus élevé.
Centré sur le réseau de liquidité en chaîne : cette direction vise à optimiser spécifiquement les problèmes de liquidité inter-chaînes, mais n'a pas résolu les autres problèmes de dispersion des états en chaîne. Son cœur est de construire une couche de liquidité, sur laquelle des applications sont développées, afin de partager la liquidité de toute la chaîne. Certains projets incluent : Raye Network, INFINIT, Everclear, Elixir, etc.
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, comme Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Ces projets nécessitent la gestion de processus complexes entre chaînes, ce qui impose des exigences élevées aux développeurs, et sont donc également très susceptibles de subir des attaques de hackers.
Résoudre le problème de la liquidité est un enjeu très important, dans le monde financier, la liquidité représente souvent tout. Si nous pouvons construire une plateforme d'intégration de la liquidité, en particulier en intégrant la liquidité dispersée sur toute la chaîne, cela aura un très grand potentiel, et nous avons également examiné de nombreuses solutions différentes.
Dans les deux classifications ci-dessus, nous pouvons voir que, selon la structure du gâteau, le Settlement Layer est la solution la plus atomique, et au-dessus de ces solutions atomiques telles que les solutions inter-chaînes, les oracles, et les solutions de Pre-Confirmation, se trouve une couche plus abstraite, qui est le Solver Layer, le Permission Layer et l'Application Layer. Les différentes solutions abstraites ou de Liquidité que nous avons listées ci-dessus, construites dans différentes directions, peuvent être comprises comme une relation entre l'amont et l'aval. Cependant, ces solutions ne sont toujours pas des solutions atomiques, et le problème global de la fragmentation de la Liquidité a entraîné l'émergence de nombreux problèmes dérivés complexes. Par conséquent, en ce qui concerne l'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 d'eux 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 des protocoles DeFi, tels que les Oracle, le Type de Pool, l'IRM, les Actifs, etc., et peut également fournir des composants prêts à l'emploi comme le Trading avec effet de levier et des Stratégies de Rendement. Cela équivaut à d'autres applications de construction, 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 encore été divulgué. INFINIT a déjà levé 6 millions de dollars lors d'un tour de financement de démarrage, avec des investisseurs tels que Robot Ventures, Electric Capital et Maelstrom Capital.
(# Khalani Network
Khalani a construit trois composants principaux, à savoir la couche de compatibilité Intent, Validity et la couche de règlement universelle.
Les applications externes ou la couche d'intention peuvent publier des intentions à Khalani, puis la couche de compatibilité des intentions de Khalani peut transformer les intentions externes en un format que le Solver de protocole peut reconnaître, le format normalisé utilisé étant le langage Validity. Le nœud Khalani est responsable de la soumission du résultat final à la couche de règlement général 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 dévoilé plus de détails sur le travail. En août, il a obtenu 2,2 millions de dollars lors d'un tour de financement de semences de la part d'Ethereal Ventures, Nascent, Maelstrom Capital, etc.
![Recherche sur le problème de la liquidité fragmentée à l'ère Layer 2])https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###
Liquorice
Liquorice est une application décentralisée qui permet la découverte de 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 de gestion des stocks efficaces, tout en se connectant facilement aux protocoles DeFi essentiels 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 obtenu un financement de pré-amorçage de 1,2 million de dollars dirigé par GreenField.
(# Xion
Xion est une mise à niveau de la marque Burnt. Auparavant, Burnt se concentrait sur les applications destinées aux consommateurs, mais l'équipe a découvert qu'il existait un problème de fragmentation important dans les interactions sur la chaîne. Par conséquent, Xion a été construit 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, avec des investisseurs tels qu'Animoca, Multicoin, Alliance DAO, Mechanism, etc.
)# =nil; Fondation
nil est le marché de la puissance de calcul ZK d'Ethereum, un coprocesseur ZK et un développeur de Layer 2, l'équipe possède une solide expertise en technologie ZK. Ils ont proposé une solution de zkSharding, qui utilise la technologie ZK pour étendre horizontalement la chaîne principale d'Ethereum, exécuter le traitement parallèle des transactions par fragments et générer des ZKP, tandis que le fragment principal valide les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. Le fragment principal gère également la distribution des validateurs et des comptes dans les fragments 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-fragments dans le protocole dès le début. Les messages inter-fragments sont validés par le comité de validation de chaque fragment en tant que transactions.
L'idée de base est de construire une architecture de communication inter-fragment intégrée similaire à l'IBC grâce à une architecture Layer 2 fragmentée, ce qui permettrait de résoudre les problèmes de liquidité et de dispersion des états. Cependant, son idée centrale n'est pas raisonnable, car le problème de la dispersion de la liquidité est un problème 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.
![Recherche sur le problème de la liquidité prise les gens pour des idiots à l'époque de Layer 2]###https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###
ERC-7683
Ethereum s'attaque également à ce problème de liquidité inter-chaînes. Actuellement, Arbitrum, OP et un certain DEX soutiennent d'abord le standard ERC7683, qui utilise également une méthode inter-chaînes basée sur l'Intent. L'objectif principal est d'établir un standard universel pour les opérations inter-chaînes entre L2 et les chaînes latérales, de normaliser les interfaces de commande et de règlement, et de réaliser une exécution inter-chaînes sans couture. Le cœur de ce processus est un Filler, qui peut également être considéré comme le rôle de Solver dans l'abstraction de la chaîne pour le paiement. Cette proposition a été co-construite par un certain DEX et Across, et 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. Ils résolvent le problème à différents niveaux : architecture, consensus et application. OP Stack propose une solution complète multi-Layer 2 pour résoudre à la fois la transmission d'informations et le Sequ.
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.
9 J'aime
Récompense
9
2
Reposter
Partager
Commentaire
0/400
MetaNomad
· Il y a 3h
cross-chain vrai rouleau Personne ne peut s'enfuir
Voir l'originalRépondre0
NestedFox
· Il y a 3h
Un homme d'honneur ne peut pas passer un jour sans se battre.
Exploration des solutions de Liquidité cross-chain à l'ère du Layer 2
Étude sur le problème de la division de la liquidité à l'ère du Layer 2
Avec le passage d'Ethereum à des solutions d'extension axées sur le Layer 2 et l'émergence d'outils comme RaaS, de nombreuses blockchains publiques se développent rapidement. De nombreuses entités souhaitent construire leur propre chaîne pour représenter différents intérêts et rechercher 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, ce qui entraîne de nombreux projets à voir leur prix chuter dès la TGE.
Grâce à OP Stack, une plateforme de trading a lancé son propre Base Layer 2, tandis qu'une autre plateforme a publié Ink ; grâce à la technologie ZK, une plateforme de trading a lancé XLayer ; Sony a publié Soneium, et LINE a lancé Kaia, entre autres. Aujourd'hui, les coûts et les barrières technologiques pour construire une chaîne ont considérablement diminué, et le coût d'exploitation d'une chaîne basée sur OP Stack est d'environ 10 000 dollars par mois.
L'avenir sera sans aucun doute une ère de coexistence multi-chaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour atteindre l'interopérabilité, il est difficile pour les entités Web2 qui les soutiennent, ayant de nombreuses applications en aval, de construire des applications et d'atteindre un consensus sur la même chaîne.
L'écosystème multichaînes actuel apporte un nouveau défi : la liquidité et la dispersion des états. Étant donné que l'existence de plusieurs chaînes est inévitable, l'interopérabilité est un domaine qui doit être exploré et résolu. Actuellement, il existe de nombreuses solutions de liquidité, comme nous avons tous entendu parler de l'abstraction de chaîne, de l'intention, de l'exécution de clearing, du cross-chain natif, du ZKSharding, mais leur essence fondamentale est la même.
Nous utilisons l'architecture Cake, reconnue dans l'industrie, pour présenter de haut en bas la composition des composants principaux de l'abstraction inter-chaînes :
Couche d'application(Application Layer)
C'est la couche d'interaction directe avec l'utilisateur, 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 forcément comprendre le mécanisme de conversion de Liquidité sous-jacent.
couche de permission (Permission Layer)
Situé sous la couche d'application, l'utilisateur satisfait son intention de transaction en connectant son portefeuille à une dApp et en demandant un devis. 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 de couche (Gestion des clés et abstraction de compte)
En raison de l'existence d'un environnement multi-chaînes, il est nécessaire d'avoir un système de gestion des comptes et d'abstraction adapté aux différentes chaînes pour maintenir la structure unique des comptes de chaque chaîne. Par exemple, le système de comptes centré sur les objets de SUI est complètement différent de l'EVM. One Balance est un projet représentatif dans ce domaine, qui a construit un système de comptes fiable, sans avoir besoin d'établir un consensus inter-chaînes, mais simplement en s'appuyant sur des engagements de confiance entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant des portefeuilles de comptes multi-chaînes pour les utilisateurs, optimisant ainsi considérablement l'expérience utilisateur et réduisant la fragmentation de l'UX. Cependant, en ce qui concerne la liquidité, elle intègre principalement les chaînes publiques existantes.
Résoudre la couche (Solver Layer)
Cette couche est responsable de la réception et de la réalisation des intentions de transaction des utilisateurs. Le rôle de Solver y concourt afin d'offrir une meilleure expérience utilisateur, notamment des temps de transaction plus rapides et une exécution plus rapide. Sur cette base, des projets basés sur les intentions, tels qu'Anoma, ont construit diverses solutions axées sur les intentions. Des dérivés de ce type d'intention, comme le composant Predicate, peuvent réaliser les intentions des utilisateurs sous des règles spécifiques.
Couches de règlement ( Settlement Layer )
C'est la couche intermédiaire utilisée pour réaliser l'intention des utilisateurs. Les composants clés 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, et d'autres facteurs afin d'assurer le fonctionnement efficace de l'ensemble du système multichaîne.
![Recherche sur le problème de la Liquidité dans l'ère Layer 2])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
) solution
Actuellement, il existe plusieurs solutions sur le marché pour résoudre la Liquidité et prendre les gens pour des idiots. Après avoir examiné un grand nombre de solutions, nous avons constaté qu'il existe principalement ces quelques méthodes :
Centré sur RaaS : des solutions de Rollup comme OP Stack, en ajoutant 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 dispersion de la liquidité et de l'état à un niveau supérieur. Un aspect plus spécifique est la conception d'ordonnanceurs partagés individuels, cette solution est plus axée sur Layer 2, n'ayant pas de caractère universel, comme Astria, Espresso et Flashbots.
Centré sur le compte : similaire à NEAR, créer un portefeuille de compte sur toute la chaîne, prenant en charge la signature et l'exécution des transactions à travers plusieurs protocoles de blockchain grâce à une technologie appelée « signature de chaîne ». Le composant clé est le réseau MPC, qui remplace l'utilisateur pour signer les transactions multichaînes. Bien que cette solution puisse grandement résoudre le problème de la fragmentation de l'UX, elle implique une mise en œuvre backend complexe pour les développeurs et ne résout pas fondamentalement la Liquidité et la dispersion des états.
Centré sur le réseau d'intentions hors chaîne : c'est-à-dire le réseau Solver dans notre diagramme d'architecture de gâteau « Introduction », l'essentiel est que l'utilisateur envoie des intentions au réseau Solver, le rôle de Solver est de faire concurrence sur les offres, en fournissant le meilleur temps de réalisation et le meilleur prix de transaction. Ces Solvers peuvent être des agents IA, des CEX, des Market Makers ou même des protocoles d'intégration eux-mêmes comme Liquorice, etc. Les projets dans ce domaine incluent Anoma, Khalani, Enso, aori et Valantis. Bien que les intentions puissent théoriquement réaliser des opérations inter-chaînes de complexité arbitraire, leur mise en œuvre nécessite cependant un nombre suffisant de Solvers de Liquidité pour aider, et lorsqu'il y a des demandes hors chaîne, il existe un risque de fraude chez les Solvers. Si des méthodes comme la preuve de fraude sont introduites, la difficulté de mise en œuvre du réseau Solver sera plus élevée et le seuil de fonctionnement des Solvers sera également plus élevé.
Centré sur le réseau de liquidité en chaîne : cette direction vise à optimiser spécifiquement les problèmes de liquidité inter-chaînes, mais n'a pas résolu les autres problèmes de dispersion des états en chaîne. Son cœur est de construire une couche de liquidité, sur laquelle des applications sont développées, afin de partager la liquidité de toute la chaîne. Certains projets incluent : Raye Network, INFINIT, Everclear, Elixir, etc.
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, comme Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Ces projets nécessitent la gestion de processus complexes entre chaînes, ce qui impose des exigences élevées aux développeurs, et sont donc également très susceptibles de subir des attaques de hackers.
Résoudre le problème de la liquidité est un enjeu très important, dans le monde financier, la liquidité représente souvent tout. Si nous pouvons construire une plateforme d'intégration de la liquidité, en particulier en intégrant la liquidité dispersée sur toute la chaîne, cela aura un très grand potentiel, et nous avons également examiné de nombreuses solutions différentes.
Dans les deux classifications ci-dessus, nous pouvons voir que, selon la structure du gâteau, le Settlement Layer est la solution la plus atomique, et au-dessus de ces solutions atomiques telles que les solutions inter-chaînes, les oracles, et les solutions de Pre-Confirmation, se trouve une couche plus abstraite, qui est le Solver Layer, le Permission Layer et l'Application Layer. Les différentes solutions abstraites ou de Liquidité que nous avons listées ci-dessus, construites dans différentes directions, peuvent être comprises comme une relation entre l'amont et l'aval. Cependant, ces solutions ne sont toujours pas des solutions atomiques, et le problème global de la fragmentation de la Liquidité a entraîné l'émergence de nombreux problèmes dérivés complexes. Par conséquent, en ce qui concerne l'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 d'eux 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 des protocoles DeFi, tels que les Oracle, le Type de Pool, l'IRM, les Actifs, etc., et peut également fournir des composants prêts à l'emploi comme le Trading avec effet de levier et des Stratégies de Rendement. Cela équivaut à d'autres applications de construction, 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 encore été divulgué. INFINIT a déjà levé 6 millions de dollars lors d'un tour de financement de démarrage, avec des investisseurs tels que Robot Ventures, Electric Capital et Maelstrom Capital.
(# Khalani Network
Khalani a construit trois composants principaux, à savoir la couche de compatibilité Intent, Validity et la couche de règlement universelle.
Les applications externes ou la couche d'intention peuvent publier des intentions à Khalani, puis la couche de compatibilité des intentions de Khalani peut transformer les intentions externes en un format que le Solver de protocole peut reconnaître, le format normalisé utilisé étant le langage Validity. Le nœud Khalani est responsable de la soumission du résultat final à la couche de règlement général 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 dévoilé plus de détails sur le travail. En août, il a obtenu 2,2 millions de dollars lors d'un tour de financement de semences de la part d'Ethereal Ventures, Nascent, Maelstrom Capital, etc.
![Recherche sur le problème de la liquidité fragmentée à l'ère Layer 2])https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###
Liquorice
Liquorice est une application décentralisée qui permet la découverte de 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 de gestion des stocks efficaces, tout en se connectant facilement aux protocoles DeFi essentiels 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 obtenu un financement de pré-amorçage de 1,2 million de dollars dirigé par GreenField.
(# Xion
Xion est une mise à niveau de la marque Burnt. Auparavant, Burnt se concentrait sur les applications destinées aux consommateurs, mais l'équipe a découvert qu'il existait un problème de fragmentation important dans les interactions sur la chaîne. Par conséquent, Xion a été construit 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, avec des investisseurs tels qu'Animoca, Multicoin, Alliance DAO, Mechanism, etc.
)# =nil; Fondation
nil est le marché de la puissance de calcul ZK d'Ethereum, un coprocesseur ZK et un développeur de Layer 2, l'équipe possède une solide expertise en technologie ZK. Ils ont proposé une solution de zkSharding, qui utilise la technologie ZK pour étendre horizontalement la chaîne principale d'Ethereum, exécuter le traitement parallèle des transactions par fragments et générer des ZKP, tandis que le fragment principal valide les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. Le fragment principal gère également la distribution des validateurs et des comptes dans les fragments 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-fragments dans le protocole dès le début. Les messages inter-fragments sont validés par le comité de validation de chaque fragment en tant que transactions.
L'idée de base est de construire une architecture de communication inter-fragment intégrée similaire à l'IBC grâce à une architecture Layer 2 fragmentée, ce qui permettrait de résoudre les problèmes de liquidité et de dispersion des états. Cependant, son idée centrale n'est pas raisonnable, car le problème de la dispersion de la liquidité est un problème 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.
![Recherche sur le problème de la liquidité prise les gens pour des idiots à l'époque de Layer 2]###https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###
ERC-7683
Ethereum s'attaque également à ce problème de liquidité inter-chaînes. Actuellement, Arbitrum, OP et un certain DEX soutiennent d'abord le standard ERC7683, qui utilise également une méthode inter-chaînes basée sur l'Intent. L'objectif principal est d'établir un standard universel pour les opérations inter-chaînes entre L2 et les chaînes latérales, de normaliser les interfaces de commande et de règlement, et de réaliser une exécution inter-chaînes sans couture. Le cœur de ce processus est un Filler, qui peut également être considéré comme le rôle de Solver dans l'abstraction de la chaîne pour le paiement. Cette proposition a été co-construite par un certain DEX et Across, et 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. Ils résolvent le problème à différents niveaux : architecture, consensus et application. OP Stack propose une solution complète multi-Layer 2 pour résoudre à la fois la transmission d'informations et le Sequ.