Étude sur le problème de la Liquidité dans l'ère du Layer 2
Avec le passage d'Ethereum à une solution d'extension axée sur Layer 2, ainsi que l'émergence d'outils comme RaaS, de nombreuses chaînes 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 chaînes publiques rend difficile le développement de l'écosystème, ce qui entraîne de nombreux projets à s'effondrer dès le TGE.
Grâce à OP Stack, une plateforme d'échange a lancé sa propre Base Layer 2, une autre plateforme d'échange a publié Ink ; grâce à la technologie ZK, une autre 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 technique 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 celui de la coexistence des chaînes multiples. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour assurer l'interopérabilité, il est difficile pour elles de construire des applications et d'atteindre un consensus sur la même chaîne en raison du grand nombre d'applications en aval des entités Web2 qui les sous-tendent.
L'écosystème multichaîne actuel pose un nouveau défi : la Liquidité et la dispersion des états. Étant donné que l'existence de multichaînes est inévitable, l'interopérabilité est donc 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 CrossChain natif, du ZKSharding, mais leur essence fondamentale est la même.
Nous utilisons l'architecture Cake, largement 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 le niveau d'interaction directe avec l'utilisateur, et c'est aussi le niveau le plus abstrait dans les solutions de Liquidité, car il masque complètement les détails de la conversion de Liquidité. Au niveau de l'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 à un dApp et en demandant un devis. Ici, "intention" fait référence au résultat final de transaction attendu par l'utilisateur, soit la sortie (, et non le chemin d'exécution spécifique de la transaction.
Gestion de compte et abstraction de clé )Key Management and Account Abstraction(
En raison de l'existence d'un environnement multi-chaînes, il est nécessaire d'avoir un système de gestion de comptes et d'abstraction adapté à différentes chaînes pour maintenir la structure de compte unique 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 construit un système de comptes de confiance sans avoir besoin d'établir un consensus inter-chaînes, mais uniquement des engagements de confiance entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant un portefeuille de comptes multi-chaînes pour les utilisateurs, optimisant 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 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 tels qu'Anoma ont construit diverses solutions axées sur l'intention. 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.
Layer 2 )Settlement Layer (
C'est la couche intermédiaire utilisée pour résoudre les intentions des utilisateurs. Les composants principaux des solutions de Liquidité et de l'état décentralisé incluent :
Oracle ) : utilisé pour obtenir des informations sur l'état d'autres chaînes.
Ponts ( Bridges ) : responsable de la transmission d'informations et de liquidité entre les chaînes.
Confirmation préalable ( : réduire le temps de confirmation inter-chaînes.
Disponibilité des données)DA(: fournir l'accessibilité des données.
De plus, il faut tenir compte de la liquidité inter-chaînes, de la finalité )Finality(, des mécanismes de preuve Layer 2, etc., pour garantir le fonctionnement efficace de l'ensemble du système multi-chaînes.
) solution
Actuellement, sur le marché, il existe plusieurs solutions pour résoudre la Liquidité prise les gens pour des idiots. Après avoir examiné de nombreuses solutions, nous avons constaté qu'il y a 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 détaillé est la conception d'ordonnanceurs partagés individuels, cette solution est davantage axée sur Layer 2, n'ayant pas de caractère universel, comme Astria, Espresso et Flashbots.
Centré sur le compte : similaire à NEAR, construire un portefeuille de compte tout en 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 central est le réseau MPC, qui remplace l'utilisateur pour signer des transactions multi-chaînes. Bien que cette solution puisse grandement résoudre le problème de la fragmentation de l'UX, pour les développeurs, cela implique une mise en œuvre backend complexe et ne résout pas essentiellement la liquidité et la dispersion des états.
Centré sur le réseau d'intentions hors chaîne : c'est-à-dire notre diagramme d'architecture de gâteau "Introduction" dans lequel le Solver Network est au cœur, où les utilisateurs envoient des intentions au réseau Solver, ce rôle de Solver est de faire concurrence sur les offres, en fournissant le meilleur temps d'achèvement et le meilleur prix de transaction. Ces Solvers peuvent être des agents IA, des CEX, des Market Makers, ou même des protocoles intégrés 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 permettre d'exécuter des opérations inter-chaînes d'une complexité quelconque, leur mise en œuvre nécessite néanmoins des Solvers ayant une liquidité suffisante pour aider, et lorsqu'il s'agit de certaines demandes hors chaîne, il existe un risque de fraude de la part des Solvers. Si des moyens tels que des preuves de fraude sont introduits, la difficulté de mise en œuvre du Solver Network augmentera, tout comme le seuil d'entrée pour faire fonctionner un Solver.
Au centre du réseau de liquidité en chaîne : cette direction est spécialement optimisée pour 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 noyau est de construire une couche de liquidité, sur laquelle des applications sont construites, afin de partager la liquidité de l'ensemble de 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 des grands MM ou d'autres applications tierces, comme Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Ces projets nécessitent la gestion de processus inter-chaînes complexes, ce qui impose des exigences très élevées aux développeurs, et ils sont donc également très susceptibles de faire l'objet d'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 d'intégration de liquidité, en particulier en intégrant la liquidité fragmentée de l'ensemble de 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 au niveau le plus atomique. Au-dessus de ces solutions atomiques telles que les solutions inter-chaînes, les oracles et les solutions Pre-Confirmation, se construit un niveau plus abstrait, qui est le Solver Layer, le Permission Layer et l'Application Layer. Les différentes solutions abstraites ou de liquidité que nous avons énumérées ci-dessus, construites dans différentes directions, correspondent à ces différents niveaux, que l'on peut comprendre comme une relation entre l'amont et l'aval. Cependant, ces solutions ne sont toujours pas des solutions atomiques. Le problème de la fragmentation de la liquidité a entraîné l'émergence de nombreux problèmes dérivés complexes, donc en ce qui concerne l'interopérabilité, de nombreuses solutions variées ont vu le jour. Mais en essence, cela dépend toujours de ces composants. Ensuite, nous discuterons de quelques projets typiques de concepts d'abstraction de chaîne pour voir comment chacun d'eux aborde le problème de la fragmentation de la liquidité à partir de son propre point de départ.
INFINIT
INFINIT a construit un service RaaS pour le secteur DeFi, capable de fournir directement les composants nécessaires à la construction des protocoles DeFi, tels que les Oracle, les types de Pool, l'IRM, les actifs, etc. Il peut également offrir des composants tels que le Trading à effet de levier et la Stratégie de rendement, prêts à être utilisés immédiatement. 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é. Actuellement, INFINIT a déjà obtenu un financement de 6 millions de dollars lors d'un tour de seed auprès de plusieurs institutions d'investissement renommées.
(# Khalani Network
Khalani a construit trois composants clés, à savoir la couche compatible avec l'intention, la validité et la couche de règlement général.
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 reconnaissable par le Solver de protocole, 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 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 révélé plus de détails sur le travail. En août, il a obtenu un financement de 2,2 millions de dollars lors d'un tour de financement de semences de la part de certaines institutions d'investissement renommées.
)# 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 sociétés de trading professionnelles des outils de gestion des stocks efficaces et de se connecter facilement à certains protocoles DeFi clés lors du règlement des transactions d'intention d'utilisation. En même temps, 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 actuellement 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 auprès de certaines institutions d'investissement renommées.
Xion
Xion est une mise à niveau de la marque Burnt. Auparavant, Burnt se concentrait sur les applications destinées aux consommateurs. Ensuite, l'équipe a découvert qu'il y avait un problème de fragmentation important dans les interactions sur la chaîne, c'est pourquoi 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 provenant de certaines institutions d'investissement reconnues.
=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 la chaîne principale d'Ethereum, exécuter le traitement parallèle des transactions et générer des ZKP, tandis que la chaîne principale valide les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. La chaîne principale gère également la distribution des validateurs et des comptes dans les chaînes 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 les plus récents. =nil; L2 a intégré la communication inter-chaînes dès le début dans le protocole. Les messages inter-chaînes sont validés par le comité de validation de chaque chaîne en tant que transactions.
Son idée de base est de construire une architecture de communication inter-fragment intégrée, similaire à l'IBC, à travers une architecture Layer 2 fragmentée, ce qui résoudrait les problèmes de Liquidité et de dispersion des états. Cependant, son idée principale n'est pas raisonnable, car le problème que la dispersion de la Liquidité cherche à résoudre est un problème de multi-chaînes. 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 travaille également à résoudre le problème de la liquidité inter-chaînes. Actuellement, certains projets connus 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 des normes universelles pour les opérations inter-chaînes entre L2 et les sidechains, de standardiser les interfaces de commande et de règlement, et de permettre une exécution inter-chaînes sans faille. Le cœur de cela est un Filler, qui peut aussi être considéré comme le rôle de Solver dans l'abstraction de la chaîne pour le paiement. Cette proposition a été construite par plusieurs projets connus 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, résolvant respectivement les problèmes 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 une fois pour toutes les problèmes de transmission d'informations et de décentralisation des Séquenceurs. Lorsque vous utilisez l'architecture OP Stack, des contrats inter-chaînes sont automatiquement déployés, et un Superviseur existe pour contester afin d'éviter la transmission d'informations inter-chaînes fausses. Actuellement, certains projets connus utilisent l'architecture OP Stack.
Parmi eux, le plus typique est Unichain. Unichain vise à résoudre le problème de la fragmentation de la liquidité inter-chaînes principalement grâce à son intégration avec le réseau Superchain. Cette configuration facilite le mouvement de liquidité sans couture en offrant les fonctionnalités suivantes :
Pont inter-chaînes basé sur l'intention : ce
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.
14 J'aime
Récompense
14
4
Reposter
Partager
Commentaire
0/400
GasFeeCry
· Il y a 3h
La piste ne peut plus tenir !
Voir l'originalRépondre0
ContractExplorer
· Il y a 3h
Je veux créer la blockchain la plus explosive ! Qui veut se joindre à moi ?
Voir l'originalRépondre0
MemeEchoer
· Il y a 3h
Encore une vague de rêveurs de blockchain avec le même résultat hahaha
Voir l'originalRépondre0
TokenEconomist
· Il y a 3h
en fait, c'est un classique dilemme du prisonnier dans la distribution de liquidité l2... laisse-moi décomposer les mathématiques rapidement
Explorer le problème de la fragmentation de la liquidité à l'ère du Layer 2 et les solutions dominantes.
Étude sur le problème de la Liquidité dans l'ère du Layer 2
Avec le passage d'Ethereum à une solution d'extension axée sur Layer 2, ainsi que l'émergence d'outils comme RaaS, de nombreuses chaînes 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 chaînes publiques rend difficile le développement de l'écosystème, ce qui entraîne de nombreux projets à s'effondrer dès le TGE.
Grâce à OP Stack, une plateforme d'échange a lancé sa propre Base Layer 2, une autre plateforme d'échange a publié Ink ; grâce à la technologie ZK, une autre 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 technique 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 celui de la coexistence des chaînes multiples. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour assurer l'interopérabilité, il est difficile pour elles de construire des applications et d'atteindre un consensus sur la même chaîne en raison du grand nombre d'applications en aval des entités Web2 qui les sous-tendent.
L'écosystème multichaîne actuel pose un nouveau défi : la Liquidité et la dispersion des états. Étant donné que l'existence de multichaînes est inévitable, l'interopérabilité est donc 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 CrossChain natif, du ZKSharding, mais leur essence fondamentale est la même.
Nous utilisons l'architecture Cake, largement 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 le niveau d'interaction directe avec l'utilisateur, et c'est aussi le niveau le plus abstrait dans les solutions de Liquidité, car il masque complètement les détails de la conversion de Liquidité. Au niveau de l'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 à un dApp et en demandant un devis. Ici, "intention" fait référence au résultat final de transaction attendu par l'utilisateur, soit la sortie (, et non le chemin d'exécution spécifique de la transaction.
Gestion de compte et abstraction de clé )Key Management and Account Abstraction(
En raison de l'existence d'un environnement multi-chaînes, il est nécessaire d'avoir un système de gestion de comptes et d'abstraction adapté à différentes chaînes pour maintenir la structure de compte unique 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 construit un système de comptes de confiance sans avoir besoin d'établir un consensus inter-chaînes, mais uniquement des engagements de confiance entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant un portefeuille de comptes multi-chaînes pour les utilisateurs, optimisant 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 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 tels qu'Anoma ont construit diverses solutions axées sur l'intention. 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.
Layer 2 )Settlement Layer (
C'est la couche intermédiaire utilisée pour résoudre les intentions des utilisateurs. Les composants principaux des solutions de Liquidité et de l'état décentralisé incluent :
De plus, il faut tenir compte de la liquidité inter-chaînes, de la finalité )Finality(, des mécanismes de preuve Layer 2, etc., pour garantir le fonctionnement efficace de l'ensemble du système multi-chaînes.
) solution
Actuellement, sur le marché, il existe plusieurs solutions pour résoudre la Liquidité prise les gens pour des idiots. Après avoir examiné de nombreuses solutions, nous avons constaté qu'il y a 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 détaillé est la conception d'ordonnanceurs partagés individuels, cette solution est davantage axée sur Layer 2, n'ayant pas de caractère universel, comme Astria, Espresso et Flashbots.
Centré sur le compte : similaire à NEAR, construire un portefeuille de compte tout en 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 central est le réseau MPC, qui remplace l'utilisateur pour signer des transactions multi-chaînes. Bien que cette solution puisse grandement résoudre le problème de la fragmentation de l'UX, pour les développeurs, cela implique une mise en œuvre backend complexe et ne résout pas essentiellement la liquidité et la dispersion des états.
Centré sur le réseau d'intentions hors chaîne : c'est-à-dire notre diagramme d'architecture de gâteau "Introduction" dans lequel le Solver Network est au cœur, où les utilisateurs envoient des intentions au réseau Solver, ce rôle de Solver est de faire concurrence sur les offres, en fournissant le meilleur temps d'achèvement et le meilleur prix de transaction. Ces Solvers peuvent être des agents IA, des CEX, des Market Makers, ou même des protocoles intégrés 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 permettre d'exécuter des opérations inter-chaînes d'une complexité quelconque, leur mise en œuvre nécessite néanmoins des Solvers ayant une liquidité suffisante pour aider, et lorsqu'il s'agit de certaines demandes hors chaîne, il existe un risque de fraude de la part des Solvers. Si des moyens tels que des preuves de fraude sont introduits, la difficulté de mise en œuvre du Solver Network augmentera, tout comme le seuil d'entrée pour faire fonctionner un Solver.
Au centre du réseau de liquidité en chaîne : cette direction est spécialement optimisée pour 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 noyau est de construire une couche de liquidité, sur laquelle des applications sont construites, afin de partager la liquidité de l'ensemble de 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 des grands MM ou d'autres applications tierces, comme Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Ces projets nécessitent la gestion de processus inter-chaînes complexes, ce qui impose des exigences très élevées aux développeurs, et ils sont donc également très susceptibles de faire l'objet d'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 d'intégration de liquidité, en particulier en intégrant la liquidité fragmentée de l'ensemble de 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 au niveau le plus atomique. Au-dessus de ces solutions atomiques telles que les solutions inter-chaînes, les oracles et les solutions Pre-Confirmation, se construit un niveau plus abstrait, qui est le Solver Layer, le Permission Layer et l'Application Layer. Les différentes solutions abstraites ou de liquidité que nous avons énumérées ci-dessus, construites dans différentes directions, correspondent à ces différents niveaux, que l'on peut comprendre comme une relation entre l'amont et l'aval. Cependant, ces solutions ne sont toujours pas des solutions atomiques. Le problème de la fragmentation de la liquidité a entraîné l'émergence de nombreux problèmes dérivés complexes, donc en ce qui concerne l'interopérabilité, de nombreuses solutions variées ont vu le jour. Mais en essence, cela dépend toujours de ces composants. Ensuite, nous discuterons de quelques projets typiques de concepts d'abstraction de chaîne pour voir comment chacun d'eux aborde le problème de la fragmentation de la liquidité à partir de son propre point de départ.
INFINIT
INFINIT a construit un service RaaS pour le secteur DeFi, capable de fournir directement les composants nécessaires à la construction des protocoles DeFi, tels que les Oracle, les types de Pool, l'IRM, les actifs, etc. Il peut également offrir des composants tels que le Trading à effet de levier et la Stratégie de rendement, prêts à être utilisés immédiatement. 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é. Actuellement, INFINIT a déjà obtenu un financement de 6 millions de dollars lors d'un tour de seed auprès de plusieurs institutions d'investissement renommées.
(# Khalani Network
Khalani a construit trois composants clés, à savoir la couche compatible avec l'intention, la validité et la couche de règlement général.
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 reconnaissable par le Solver de protocole, 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 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 révélé plus de détails sur le travail. En août, il a obtenu un financement de 2,2 millions de dollars lors d'un tour de financement de semences de la part de certaines institutions d'investissement renommées.
)# 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 sociétés de trading professionnelles des outils de gestion des stocks efficaces et de se connecter facilement à certains protocoles DeFi clés lors du règlement des transactions d'intention d'utilisation. En même temps, 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 actuellement 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 auprès de certaines institutions d'investissement renommées.
Xion
Xion est une mise à niveau de la marque Burnt. Auparavant, Burnt se concentrait sur les applications destinées aux consommateurs. Ensuite, l'équipe a découvert qu'il y avait un problème de fragmentation important dans les interactions sur la chaîne, c'est pourquoi 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 provenant de certaines institutions d'investissement reconnues.
=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 la chaîne principale d'Ethereum, exécuter le traitement parallèle des transactions et générer des ZKP, tandis que la chaîne principale valide les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. La chaîne principale gère également la distribution des validateurs et des comptes dans les chaînes 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 les plus récents. =nil; L2 a intégré la communication inter-chaînes dès le début dans le protocole. Les messages inter-chaînes sont validés par le comité de validation de chaque chaîne en tant que transactions.
Son idée de base est de construire une architecture de communication inter-fragment intégrée, similaire à l'IBC, à travers une architecture Layer 2 fragmentée, ce qui résoudrait les problèmes de Liquidité et de dispersion des états. Cependant, son idée principale n'est pas raisonnable, car le problème que la dispersion de la Liquidité cherche à résoudre est un problème de multi-chaînes. 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 travaille également à résoudre le problème de la liquidité inter-chaînes. Actuellement, certains projets connus 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 des normes universelles pour les opérations inter-chaînes entre L2 et les sidechains, de standardiser les interfaces de commande et de règlement, et de permettre une exécution inter-chaînes sans faille. Le cœur de cela est un Filler, qui peut aussi être considéré comme le rôle de Solver dans l'abstraction de la chaîne pour le paiement. Cette proposition a été construite par plusieurs projets connus 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, résolvant respectivement les problèmes 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 une fois pour toutes les problèmes de transmission d'informations et de décentralisation des Séquenceurs. Lorsque vous utilisez l'architecture OP Stack, des contrats inter-chaînes sont automatiquement déployés, et un Superviseur existe pour contester afin d'éviter la transmission d'informations inter-chaînes fausses. Actuellement, certains projets connus utilisent l'architecture OP Stack.
Parmi eux, le plus typique est Unichain. Unichain vise à résoudre le problème de la fragmentation de la liquidité inter-chaînes principalement grâce à son intégration avec le réseau Superchain. Cette configuration facilite le mouvement de liquidité sans couture en offrant les fonctionnalités suivantes :
Pont inter-chaînes basé sur l'intention : ce