Recherche sur le problème de la liquidité dans l'ère du Layer 2
Depuis qu'Ethereum s'est tourné vers des solutions d'extension axées sur Layer 2, avec l'émergence d'outils tels que RaaS, un grand nombre de chaînes publiques ont rapidement évolué. 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 a rendu le développement de l'écosystème difficile à suivre le rythme des chaînes publiques, entraînant de nombreux projets à se déprécier dès leur TGE.
Grâce à OP Stack, une plateforme de trading a lancé sa propre Base Layer 2, une autre plateforme a publié Ink ; grâce à la technologie ZK, une plateforme a lancé XLayer ; Sony a publié Soneium, et LINE a lancé Kaia, etc. 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 certainement une époque de coexistence multichaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour assurer l'interopérabilité, il est difficile 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 soutiennent.
L'écosystème multichaîne actuel pose 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. Il existe actuellement de nombreuses solutions de Liquidité, telles que l'abstraction de chaîne, l'intention, l'exécution de Clearing, le CrossChain natif, ZKSharding, etc., mais leur essence fondamentale reste la même.
Nous utilisons l'architecture Cake, reconnue dans l'industrie, pour présenter de haut en bas les 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 également le niveau le plus abstrait des 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 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 pour 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 le chemin d'exécution spécifique de la transaction.
Gestion des comptes et abstraction de clé (Key Management and Account Abstraction)
En raison de l'existence d'un environnement multichaînes, un système de gestion de comptes et d'abstraction adapté à différentes chaînes est nécessaire pour maintenir la structure de compte unique de chaque chaîne. Par exemple, le système de compte 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 compte de confiance, sans avoir besoin d'établir un consensus inter-chaînes, mais uniquement des engagements de confiance entre les systèmes de compte existants. Near Account réalise la gestion abstraite en générant des portefeuilles de comptes multichaî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 pour offrir une meilleure expérience utilisateur, y compris des temps de transaction plus rapides et des vitesses d'exécution. Sur cette base, des projets basés sur les intentions ont construit diverses solutions pilotées par 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.
Couches de règlement(Settlement Layer)
C'est la couche intermédiaire utilisée pour réaliser l'intention de l'utilisateur. Les composants clés des solutions de Liquidité et d'état décentralisé comprennent :
Oracle (: utilisé pour obtenir des informations d'état sur d'autres chaînes.
Ponts inter-chaînes ) : responsables de la transmission des informations et de la 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 convient de prendre en compte la liquidité inter-chaînes, la finalité ) Finality (, les mécanismes de preuve Layer 2, etc., afin d'assurer le bon fonctionnement efficace de l'ensemble du système multi-chaînes.
![Layer 2时代下，Liquidité prendre les gens pour des idiots问题的研究])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
Actuellement, il existe plusieurs solutions pour résoudre la Liquidité prise les gens pour des idiots sur le marché. 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 Rollup comme OP Stack, assistent à la construction de Rollup sur OP Stack en ajoutant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour partager la liquidité et l'état. Cela vise à résoudre la liquidité et la dispersion d'état à un niveau supérieur. Un aspect plus spécifique est la conception d'ordonnanceurs partagés individuels, cette solution est davantage axée sur Layer 2 et n'est pas universelle.
Centré sur le compte : similaire à NEAR, construire un portefeuille de compte complet sur la chaîne, supportant la signature et l'exécution de transactions à travers plusieurs protocoles de blockchain grâce à une technique appelée "signature de chaîne". Le composant central est le réseau MPC, qui remplace l'utilisateur pour signer les transactions multi-chaî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'intention hors chaîne : c'est-à-dire le réseau Solver dans le diagramme de structure du "gâteau d'introduction". L'essentiel est que les utilisateurs envoient des intentions au réseau Solver, et le rôle de Solver est de faire concurrence sur 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 ou même le protocole intégré lui-même. Bien que les intentions puissent théoriquement permettre des opérations inter-chaînes de complexité arbitraire, leur réalisation nécessite néanmoins un nombre suffisant de Solvers de liquidité 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 réseau Solver augmentera, tout comme le seuil d'entrée pour faire fonctionner un Solver.
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 sont construites, afin de partager la liquidité de toute la chaîne.
Axé sur les applications en chaîne : Ces applications construisent des applications à haute liquidité en intégrant de grands MM ou des applications tierces. Ces projets nécessitent une gestion complexe des processus inter-chaînes, avec des exigences très élevées pour les développeurs, ce qui les rend également très susceptibles aux attaques de hackers.
Résoudre le problème de la liquidité est une question très importante, 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é fragmentée de l'ensemble de la chaîne, cela aura un très grand potentiel.
Dans les deux classifications ci-dessus, nous pouvons voir que, selon la structure du gâteau, la Settlement Layer est la solution au niveau le plus atomique. Au-dessus de ces solutions atomiques telles que les solutions cross-chain, les oracles et les Pre-Confirmation, se construit une couche plus abstraite, qui est la Solver Layer, la Permission Layer et l'Application Layer. Les différentes solutions d'abstraction ou de liquidité que nous avons listé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 au niveau atomique. Le problème de fragmentation de la liquidité a entraîné l'apparition de nombreux problèmes dérivés complexes, c'est pourquoi, 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 liés aux concepts d'abstraction des chaînes, afin de voir comment chacun 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 DeFi, capable de fournir les composants nécessaires à la construction directe des protocoles DeFi, tels que Oracle, Pool Type, IRM, Asset, etc. Il peut également fournir des composants tels que le Leverage Trading et la Yield Strategy, qui sont prêts à être utilisés immédiatement. Cela équivaut à d'autres points de construction d'applications, mais la liquidité finale est placée dans la couche de liquidité d'Infinit. Cependant, pour le moment, le fonctionnement sous-jacent n'a pas encore été divulgué.
(# Réseau Khalani
Khalani a construit trois composants essentiels, à savoir la couche de compatibilité Intent, la Validité et la couche de règlement universelle.
Les applications externes ou la couche d'intention peuvent publier des intentions à Khalani, puis la couche compatible des Intent de Khalani peut convertir les intentions externes dans un format reconnu par le protocole Solver, le format normalisé utilisé est le langage Validity. Les nœuds Khalani sont responsables de soumettre le 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 révélé plus de détails sur le travail.
)# Réglisse
Liquorice est une application décentralisée qui permet la découverte des prix basée sur les enchères et les 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, tout en se connectant facilement aux protocoles DeFi centraux 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 est davantage axée sur la transaction elle-même. Elle est encore en phase de développement.
Xion
Xion est une évolution de la marque Burnt. Auparavant, Burnt se concentrait sur des applications destinées aux consommateurs, mais l'équipe a découvert un problème de grande fragmentation 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.
![Recherche sur le problème de la fragmentation de la liquidité à l'ère Layer 2]###https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###
=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é la solution zkSharding, qui utilise la technologie ZK pour étendre horizontalement le réseau principal d'Ethereum, exécuter un traitement parallèle des transactions en fractionnant et générer des ZKP, tandis que le fragment principal vérifie 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-fragment dans le protocole dès le départ. Les messages inter-fragment sont vérifié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-chaînes intégrée, similaire à l'IBC, par le biais d'une architecture Layer 2 partitionnée, ce qui permettrait de résoudre les problèmes de Liquidité et de dispersion des états. Cependant, l'idée centrale n'est pas raisonnable, car le problème de la dispersion de la liquidité est un problème multi-chaînes, et ce qui est construit est un Layer 2 unique, ce qui signifie que pour résoudre le problème, toutes les chaînes doivent devenir un fragment du 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. Actuellement, plusieurs plateformes soutiennent d'abord 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 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 faille. Le cœur de ce système est un Filler, qui peut également être considéré comme un Solver dans l'abstraction de la chaîne pour le paiement. Cette proposition a été développée conjointement par deux projets, et elle est actuellement examinée par le groupe de travail Cake.
![Recherche sur le problème de la fragmentation de la liquidité à l'ère Layer 2])https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###
OP Stack
OP Stack, ERC-7683 et zkSharding, sont tous des solutions internes d'Ethereum pour la fragmentation de la liquidité entre 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 en une seule fois 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 il existe également un Superviseur pour contester afin d'éviter la transmission de fausses informations inter-chaînes. Actuellement, plusieurs projets bien connus utilisent l'architecture OP Stack.
Parmi eux, le plus typique est Unichain. Unichain se concentre principalement sur
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.
10 J'aime
Récompense
10
5
Partager
Commentaire
0/400
MemeTokenGenius
· Il y a 7h
prendre les gens pour des idiots sans remède
Voir l'originalRépondre0
SocialAnxietyStaker
· Il y a 7h
La sortie de Layer2 s'accélère
Voir l'originalRépondre0
GateUser-9ad11037
· Il y a 7h
Les grands problèmes nécessitent une réponse flexible.
Voir l'originalRépondre0
MysteriousZhang
· Il y a 7h
Clair, professionnel et très profond
Voir l'originalRépondre0
ConsensusBot
· Il y a 7h
Se développer trop rapidement n'est pas une bonne chose.
Analyse des défis et des solutions liés à la liquidité dans l'ère du Layer 2.
Recherche sur le problème de la liquidité dans l'ère du Layer 2
Depuis qu'Ethereum s'est tourné vers des solutions d'extension axées sur Layer 2, avec l'émergence d'outils tels que RaaS, un grand nombre de chaînes publiques ont rapidement évolué. 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 a rendu le développement de l'écosystème difficile à suivre le rythme des chaînes publiques, entraînant de nombreux projets à se déprécier dès leur TGE.
Grâce à OP Stack, une plateforme de trading a lancé sa propre Base Layer 2, une autre plateforme a publié Ink ; grâce à la technologie ZK, une plateforme a lancé XLayer ; Sony a publié Soneium, et LINE a lancé Kaia, etc. 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 certainement une époque de coexistence multichaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour assurer l'interopérabilité, il est difficile 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 soutiennent.
L'écosystème multichaîne actuel pose 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. Il existe actuellement de nombreuses solutions de Liquidité, telles que l'abstraction de chaîne, l'intention, l'exécution de Clearing, le CrossChain natif, ZKSharding, etc., mais leur essence fondamentale reste la même.
Nous utilisons l'architecture Cake, reconnue dans l'industrie, pour présenter de haut en bas les 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 également le niveau le plus abstrait des 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 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 pour 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 le chemin d'exécution spécifique de la transaction.
Gestion des comptes et abstraction de clé (Key Management and Account Abstraction)
En raison de l'existence d'un environnement multichaînes, un système de gestion de comptes et d'abstraction adapté à différentes chaînes est nécessaire pour maintenir la structure de compte unique de chaque chaîne. Par exemple, le système de compte 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 compte de confiance, sans avoir besoin d'établir un consensus inter-chaînes, mais uniquement des engagements de confiance entre les systèmes de compte existants. Near Account réalise la gestion abstraite en générant des portefeuilles de comptes multichaî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 pour offrir une meilleure expérience utilisateur, y compris des temps de transaction plus rapides et des vitesses d'exécution. Sur cette base, des projets basés sur les intentions ont construit diverses solutions pilotées par 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.
Couches de règlement(Settlement Layer)
C'est la couche intermédiaire utilisée pour réaliser l'intention de l'utilisateur. Les composants clés des solutions de Liquidité et d'état décentralisé comprennent :
De plus, il convient de prendre en compte la liquidité inter-chaînes, la finalité ) Finality (, les mécanismes de preuve Layer 2, etc., afin d'assurer le bon fonctionnement efficace de l'ensemble du système multi-chaînes.
![Layer 2时代下，Liquidité prendre les gens pour des idiots问题的研究])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
Actuellement, il existe plusieurs solutions pour résoudre la Liquidité prise les gens pour des idiots sur le marché. 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 Rollup comme OP Stack, assistent à la construction de Rollup sur OP Stack en ajoutant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour partager la liquidité et l'état. Cela vise à résoudre la liquidité et la dispersion d'état à un niveau supérieur. Un aspect plus spécifique est la conception d'ordonnanceurs partagés individuels, cette solution est davantage axée sur Layer 2 et n'est pas universelle.
Centré sur le compte : similaire à NEAR, construire un portefeuille de compte complet sur la chaîne, supportant la signature et l'exécution de transactions à travers plusieurs protocoles de blockchain grâce à une technique appelée "signature de chaîne". Le composant central est le réseau MPC, qui remplace l'utilisateur pour signer les transactions multi-chaî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'intention hors chaîne : c'est-à-dire le réseau Solver dans le diagramme de structure du "gâteau d'introduction". L'essentiel est que les utilisateurs envoient des intentions au réseau Solver, et le rôle de Solver est de faire concurrence sur 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 ou même le protocole intégré lui-même. Bien que les intentions puissent théoriquement permettre des opérations inter-chaînes de complexité arbitraire, leur réalisation nécessite néanmoins un nombre suffisant de Solvers de liquidité 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 réseau Solver augmentera, tout comme le seuil d'entrée pour faire fonctionner un Solver.
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 sont construites, afin de partager la liquidité de toute la chaîne.
Axé sur les applications en chaîne : Ces applications construisent des applications à haute liquidité en intégrant de grands MM ou des applications tierces. Ces projets nécessitent une gestion complexe des processus inter-chaînes, avec des exigences très élevées pour les développeurs, ce qui les rend également très susceptibles aux attaques de hackers.
Résoudre le problème de la liquidité est une question très importante, 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é fragmentée de l'ensemble de la chaîne, cela aura un très grand potentiel.
![Layer 2时代下，Liquidité割裂问题的研究])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp(
Dans les deux classifications ci-dessus, nous pouvons voir que, selon la structure du gâteau, la Settlement Layer est la solution au niveau le plus atomique. Au-dessus de ces solutions atomiques telles que les solutions cross-chain, les oracles et les Pre-Confirmation, se construit une couche plus abstraite, qui est la Solver Layer, la Permission Layer et l'Application Layer. Les différentes solutions d'abstraction ou de liquidité que nous avons listé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 au niveau atomique. Le problème de fragmentation de la liquidité a entraîné l'apparition de nombreux problèmes dérivés complexes, c'est pourquoi, 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 liés aux concepts d'abstraction des chaînes, afin de voir comment chacun 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 DeFi, capable de fournir les composants nécessaires à la construction directe des protocoles DeFi, tels que Oracle, Pool Type, IRM, Asset, etc. Il peut également fournir des composants tels que le Leverage Trading et la Yield Strategy, qui sont prêts à être utilisés immédiatement. Cela équivaut à d'autres points de construction d'applications, mais la liquidité finale est placée dans la couche de liquidité d'Infinit. Cependant, pour le moment, le fonctionnement sous-jacent n'a pas encore été divulgué.
(# Réseau Khalani
Khalani a construit trois composants essentiels, à savoir la couche de compatibilité Intent, la Validité et la couche de règlement universelle.
Les applications externes ou la couche d'intention peuvent publier des intentions à Khalani, puis la couche compatible des Intent de Khalani peut convertir les intentions externes dans un format reconnu par le protocole Solver, le format normalisé utilisé est le langage Validity. Les nœuds Khalani sont responsables de soumettre le 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 révélé plus de détails sur le travail.
)# Réglisse
Liquorice est une application décentralisée qui permet la découverte des prix basée sur les enchères et les 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, tout en se connectant facilement aux protocoles DeFi centraux 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 est davantage axée sur la transaction elle-même. Elle est encore en phase de développement.
Xion
Xion est une évolution de la marque Burnt. Auparavant, Burnt se concentrait sur des applications destinées aux consommateurs, mais l'équipe a découvert un problème de grande fragmentation 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.
![Recherche sur le problème de la fragmentation de la liquidité à l'ère Layer 2]###https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###
=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é la solution zkSharding, qui utilise la technologie ZK pour étendre horizontalement le réseau principal d'Ethereum, exécuter un traitement parallèle des transactions en fractionnant et générer des ZKP, tandis que le fragment principal vérifie 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-fragment dans le protocole dès le départ. Les messages inter-fragment sont vérifié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-chaînes intégrée, similaire à l'IBC, par le biais d'une architecture Layer 2 partitionnée, ce qui permettrait de résoudre les problèmes de Liquidité et de dispersion des états. Cependant, l'idée centrale n'est pas raisonnable, car le problème de la dispersion de la liquidité est un problème multi-chaînes, et ce qui est construit est un Layer 2 unique, ce qui signifie que pour résoudre le problème, toutes les chaînes doivent devenir un fragment du 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. Actuellement, plusieurs plateformes soutiennent d'abord 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 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 faille. Le cœur de ce système est un Filler, qui peut également être considéré comme un Solver dans l'abstraction de la chaîne pour le paiement. Cette proposition a été développée conjointement par deux projets, et elle est actuellement examinée par le groupe de travail Cake.
![Recherche sur le problème de la fragmentation de la liquidité à l'ère Layer 2])https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###
OP Stack
OP Stack, ERC-7683 et zkSharding, sont tous des solutions internes d'Ethereum pour la fragmentation de la liquidité entre 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 en une seule fois 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 il existe également un Superviseur pour contester afin d'éviter la transmission de fausses informations inter-chaînes. Actuellement, plusieurs projets bien connus utilisent l'architecture OP Stack.
Parmi eux, le plus typique est Unichain. Unichain se concentre principalement sur