Étude sur le problème de la liquidité fragmentée à l'ère Layer2
Avec le passage d'Ethereum à des solutions d'extension centrées sur Layer 2 et l'émergence d'outils tels que 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 pour suivre le rythme des chaînes publiques, ce qui entraîne de nombreux projets à échouer dès leur TGE.
Grâce à OP Stack, une plateforme d'échange a lancé sa propre Base Layer 2, une autre plateforme a publié Ink ; grâce à la technologie ZK, une plateforme d'échange a lancé XLayer ; Sony a publié Soneium, 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 ère de coexistence multi-chaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour réaliser l'interopérabilité, il leur est difficile de construire des applications et d'atteindre un consensus sur la même chaîne en raison des nombreuses applications en aval des entités Web2 qui les soutiennent.
L'écosystème multichaînes 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, le ZKSharding, etc., 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 de 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é. Dans la couche d'application, les utilisateurs interagissent avec l'interface frontale, sans nécessairement comprendre le mécanisme de conversion de liquidité sous-jacent.
Couche de Permission(Permission Layer)
Situé en dessous de la couche d'application, les utilisateurs se connectent à leur portefeuille pour accéder au dApp et demander une cotation afin de satisfaire leur intention de transaction. Ici, "intention" fait référence au résultat final de transaction attendu par l'utilisateur (, c'est-à-dire la sortie ), et non au chemin d'exécution spécifique de la transaction.
Gestion de compte et abstraction de clé (Gestion de compte et abstraction de clé)
En raison de l'existence d'un environnement multichaînes, un système de gestion des comptes et d'abstraction adapté à différentes chaînes est nécessaire pour maintenir les structures de comptes uniques 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, il construit un système de comptes fiable, sans avoir besoin d'établir un consensus inter-chaînes, mais seulement des engagements fiables entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant des portefeuilles de comptes multichaînes pour les utilisateurs, ce qui optimise considérablement l'expérience utilisateur et réduit la fragmentation de l'UX. Cependant, en ce qui concerne la liquidité, il intègre principalement les chaînes publiques existantes.
Couche Solver (
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 compete 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 comme Anoma ont construit diverses solutions dirigées par les intentions. Des dérivés de telles intentions, comme le composant Predicate, peuvent réaliser les intentions des utilisateurs sous certaines règles.
Couche de règlement )Settlement Layer(
C'est la couche intermédiaire utilisée pour résoudre les intentions des utilisateurs. Les composants essentiels de la solution de liquidité et de l'état décentralisé comprennent :
Oracle ) : utilisé pour obtenir des informations sur l'état d'autres chaînes.
Ponts inter-chaînes ( Bridges ) : responsable de la transmission des informations et de la Liquidité inter-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 est nécessaire de prendre en compte la liquidité inter-chaînes, la finalité )Finality(, les mécanismes de preuve de la couche 2, etc., afin d'assurer le fonctionnement efficace de l'ensemble du système multi-chaînes.
) solution
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 y a principalement ces quelques façons :
Centré sur RaaS : des solutions de Rollup comme OP Stack, qui aident à construire des Rollups sur OP Stack en ajoutant des ordonneurs partagés spécifiques et des ponts inter-chaînes pour partager la liquidité et l'état. Cela vise à résoudre la dispersion de la liquidité et de l'état dans une direction de niveau supérieur. Un aspect plus spécifique est la conception d'ordonneurs partagés séparés, cette solution est plus axée sur Layer2 et n'a pas de caractère universel, comme Astria, Espresso et Flashbots.
Centré sur le compte : similaire à NEAR, construire un portefeuille de compte sur l'ensemble de la chaîne, en signant et en exécutant 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 fragmentation de l'expérience utilisateur, 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.
Avec un réseau d'intention hors chaîne comme centre : c'est-à-dire notre diagramme de structure de gâteau "Introduction" où le Solver Network est au cœur, l'idée est que l'utilisateur envoie des intentions au réseau Solver, ce rôle de Solver est de faire concurrence sur les offres, 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, voire des protocoles intégrés comme Liquorice, etc. Les projets dans ce domaine incluent Anoma, Khalani, Enso, aori et Valantis. Bien que l'intention puisse théoriquement réaliser des opérations inter-chaînes de complexité arbitraire, sa réalisation nécessite suffisamment 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 comme la preuve de fraude sont introduits, la difficulté de mise en œuvre du Solver Network augmentera, et le seuil d'entrée pour exécuter un Solver sera également plus élevé.
Centré sur un 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 d'autres problèmes de dispersion des états en chaîne. Son cœur est de construire un niveau de liquidité, sur lequel des applications sont construites, 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 des applications tierces, telles que Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Ces projets nécessitent la gestion de processus complexes entre chaînes, ce qui exige un niveau élevé de compétences des développeurs, et sont donc également très susceptibles de subir des 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 intégrant la Liquidité, en particulier en rassemblant la Liquidité fragmentée de l'ensemble de la chaîne, cela aurait 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, la couche de règlement 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 de pré-confirmation, se construit une couche plus abstraite, qui est la couche de résolution, la couche de permission et la couche d'application. Les différentes solutions abstraites ou de liquidité que nous avons énuméré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. Le problème de la fragmentation de la liquidité a engendré de nombreux problèmes dérivés complexes. Par conséquent, en ce qui concerne l'interopérabilité, une multitude de solutions a émergé. Cependant, cela dépend essentiellement de ces composants. Nous allons maintenant discuter 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 dans le domaine de la DeFi, capable de fournir directement les composants nécessaires à la construction de protocoles DeFi, tels que Oracle, Pool Type, IRM, Asset, etc. Il peut également offrir des composants tels que Leverage Trading et Yield Strategy, qui sont 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, pour l'instant, son fonctionnement sous-jacent n'a pas été divulgué. Actuellement, INFINIT a déjà obtenu un financement de 6 millions de dollars lors d'un tour de financement d'amorçage de Robot Ventures, Electric Capital et Maelstrom Capital.
Khalani Network
Khalani a construit trois composants principaux : une couche de compatibilité des intentions, la Validité et une couche de règlement universelle.
Les applications externes ou la couche d'intention peuvent publier des intentions à Khalani, puis la couche compatible avec les intentions de Khalani peut convertir les intentions externes en un format que le Solver du protocole peut reconnaître, le format normalisé utilisé étant le langage de Validité. Les nœuds Khalani sont responsables 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 toujours en phase de construction et n'a pas encore dévoilé 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 d'Ethereal Ventures, Nascent, Maelstrom Capital, etc.
Réglisse
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 sociétés de trading professionnelles des outils de gestion des stocks efficaces, tout en se connectant facilement aux protocoles DeFi fondamentaux lors de la liquidation des transactions d'intention d'utilisation. Dans le même temps, Liquorice a créé un marché de prêt pour effectuer des transactions de prêt. Cette application se concentre davantage sur la transaction elle-même. Elle est actuellement en phase de développement et a annoncé en juillet avoir obtenu un financement de 1,2 million de dollars lors d'un tour de pré-amorçage dirigé par GreenField.
Xion
Xion est une évolution de la marque Burnt, qui se concentrait auparavant sur les applications destinées aux consommateurs. Par la suite, l'équipe a découvert qu'il existait un problème de fragmentation considérable dans les interactions sur la chaîne, c'est pourquoi Xion a été construit pour améliorer cette situation. 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 et Mechanism.
(# =nil; Fondation
nil est le marché de la puissance de calcul ZK d'Ethereum, le co-processeur ZK et le développeur de Layer2, l'équipe ayant 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 le partage de traitements de transactions en parallèle et générer des ZKP, tandis que le principal partage vérifie les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. Le principal partage gère également la distribution des validateurs et des comptes dans le partage d'exécution. Le protocole de consensus utilisé par le comité de validation est également Hotstuff, ce qui est courant dans les derniers projets d'exécution parallèle. =nil; L2 a intégré la communication inter-partage dans le protocole dès le début. Les messages inter-partage sont vérifiés par le comité de validation de chaque partage en tant que transactions.
L'idée de base est de construire une architecture de communication inter-shard intégrée, similaire à l'IBC, à travers une architecture Layer2 fragmentée, afin de résoudre les problèmes de Liquidité et de dispersion des états. Cependant, le concept central n'est pas raisonnable, car le problème de la dispersion de la Liquidité est un problème multi-chaînes, et ce qui est construit est un Layer2 unique, ce qui signifie que pour résoudre cela, toutes les chaînes doivent devenir un shard de ZK-sharding, ce qui est difficile à réaliser.
![Recherche sur le problème de la rupture de liquidité à l'ère de Layer2])https://img-cdn.gateio.im/webp-social/moments-69852e6a1bbab8f4fc50f48006eb6fef.webp###
ERC-7683
Ethereum s'attaque également à ce problème de liquidité inter-chaînes. Actuellement, certains DEX, OP, etc., 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, standardisant les interfaces de commande et de règlement, et permettant une exécution sans couture des échanges inter-chaînes. Le cœur de ce projet est qu'un Filler, qui peut également être considéré comme le rôle de Solver dans l'abstraction de la chaîne, se charge du paiement. Cette proposition a été co-construite par un DEX et Across.
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
2
Partager
Commentaire
0/400
PumpBeforeRug
· Il y a 5h
Est-ce que la liaison peut être faite ? J'ai l'impression que c'est condamné comme une blockchain.
La fragmentation de la liquidité à l'ère Layer2 : défis et solutions à explorer
Étude sur le problème de la liquidité fragmentée à l'ère Layer2
Avec le passage d'Ethereum à des solutions d'extension centrées sur Layer 2 et l'émergence d'outils tels que 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 pour suivre le rythme des chaînes publiques, ce qui entraîne de nombreux projets à échouer dès leur TGE.
Grâce à OP Stack, une plateforme d'échange a lancé sa propre Base Layer 2, une autre plateforme a publié Ink ; grâce à la technologie ZK, une plateforme d'échange a lancé XLayer ; Sony a publié Soneium, 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 ère de coexistence multi-chaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour réaliser l'interopérabilité, il leur est difficile de construire des applications et d'atteindre un consensus sur la même chaîne en raison des nombreuses applications en aval des entités Web2 qui les soutiennent.
L'écosystème multichaînes 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, le ZKSharding, etc., 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 de 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é. Dans la couche d'application, les utilisateurs interagissent avec l'interface frontale, sans nécessairement comprendre le mécanisme de conversion de liquidité sous-jacent.
Couche de Permission(Permission Layer)
Situé en dessous de la couche d'application, les utilisateurs se connectent à leur portefeuille pour accéder au dApp et demander une cotation afin de satisfaire leur intention de transaction. Ici, "intention" fait référence au résultat final de transaction attendu par l'utilisateur (, c'est-à-dire la sortie ), et non au chemin d'exécution spécifique de la transaction.
Gestion de compte et abstraction de clé (Gestion de compte et abstraction de clé)
En raison de l'existence d'un environnement multichaînes, un système de gestion des comptes et d'abstraction adapté à différentes chaînes est nécessaire pour maintenir les structures de comptes uniques 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, il construit un système de comptes fiable, sans avoir besoin d'établir un consensus inter-chaînes, mais seulement des engagements fiables entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant des portefeuilles de comptes multichaînes pour les utilisateurs, ce qui optimise considérablement l'expérience utilisateur et réduit la fragmentation de l'UX. Cependant, en ce qui concerne la liquidité, il intègre principalement les chaînes publiques existantes.
Couche Solver (
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 compete 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 comme Anoma ont construit diverses solutions dirigées par les intentions. Des dérivés de telles intentions, comme le composant Predicate, peuvent réaliser les intentions des utilisateurs sous certaines règles.
Couche de règlement )Settlement Layer(
C'est la couche intermédiaire utilisée pour résoudre les intentions des utilisateurs. Les composants essentiels de la solution de liquidité et de l'état décentralisé comprennent :
De plus, il est nécessaire de prendre en compte la liquidité inter-chaînes, la finalité )Finality(, les mécanismes de preuve de la couche 2, etc., afin d'assurer le fonctionnement efficace de l'ensemble du système multi-chaînes.
) solution
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 y a principalement ces quelques façons :
Centré sur RaaS : des solutions de Rollup comme OP Stack, qui aident à construire des Rollups sur OP Stack en ajoutant des ordonneurs partagés spécifiques et des ponts inter-chaînes pour partager la liquidité et l'état. Cela vise à résoudre la dispersion de la liquidité et de l'état dans une direction de niveau supérieur. Un aspect plus spécifique est la conception d'ordonneurs partagés séparés, cette solution est plus axée sur Layer2 et n'a pas de caractère universel, comme Astria, Espresso et Flashbots.
Centré sur le compte : similaire à NEAR, construire un portefeuille de compte sur l'ensemble de la chaîne, en signant et en exécutant 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 fragmentation de l'expérience utilisateur, 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.
Avec un réseau d'intention hors chaîne comme centre : c'est-à-dire notre diagramme de structure de gâteau "Introduction" où le Solver Network est au cœur, l'idée est que l'utilisateur envoie des intentions au réseau Solver, ce rôle de Solver est de faire concurrence sur les offres, 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, voire des protocoles intégrés comme Liquorice, etc. Les projets dans ce domaine incluent Anoma, Khalani, Enso, aori et Valantis. Bien que l'intention puisse théoriquement réaliser des opérations inter-chaînes de complexité arbitraire, sa réalisation nécessite suffisamment 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 comme la preuve de fraude sont introduits, la difficulté de mise en œuvre du Solver Network augmentera, et le seuil d'entrée pour exécuter un Solver sera également plus élevé.
Centré sur un 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 d'autres problèmes de dispersion des états en chaîne. Son cœur est de construire un niveau de liquidité, sur lequel des applications sont construites, 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 des applications tierces, telles que Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Ces projets nécessitent la gestion de processus complexes entre chaînes, ce qui exige un niveau élevé de compétences des développeurs, et sont donc également très susceptibles de subir des 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 intégrant la Liquidité, en particulier en rassemblant la Liquidité fragmentée de l'ensemble de la chaîne, cela aurait 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, la couche de règlement 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 de pré-confirmation, se construit une couche plus abstraite, qui est la couche de résolution, la couche de permission et la couche d'application. Les différentes solutions abstraites ou de liquidité que nous avons énuméré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. Le problème de la fragmentation de la liquidité a engendré de nombreux problèmes dérivés complexes. Par conséquent, en ce qui concerne l'interopérabilité, une multitude de solutions a émergé. Cependant, cela dépend essentiellement de ces composants. Nous allons maintenant discuter 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 dans le domaine de la DeFi, capable de fournir directement les composants nécessaires à la construction de protocoles DeFi, tels que Oracle, Pool Type, IRM, Asset, etc. Il peut également offrir des composants tels que Leverage Trading et Yield Strategy, qui sont 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, pour l'instant, son fonctionnement sous-jacent n'a pas été divulgué. Actuellement, INFINIT a déjà obtenu un financement de 6 millions de dollars lors d'un tour de financement d'amorçage de Robot Ventures, Electric Capital et Maelstrom Capital.
Khalani Network
Khalani a construit trois composants principaux : une couche de compatibilité des intentions, la Validité et une couche de règlement universelle.
Les applications externes ou la couche d'intention peuvent publier des intentions à Khalani, puis la couche compatible avec les intentions de Khalani peut convertir les intentions externes en un format que le Solver du protocole peut reconnaître, le format normalisé utilisé étant le langage de Validité. Les nœuds Khalani sont responsables 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 toujours en phase de construction et n'a pas encore dévoilé 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 d'Ethereal Ventures, Nascent, Maelstrom Capital, etc.
Réglisse
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 sociétés de trading professionnelles des outils de gestion des stocks efficaces, tout en se connectant facilement aux protocoles DeFi fondamentaux lors de la liquidation des transactions d'intention d'utilisation. Dans le même temps, Liquorice a créé un marché de prêt pour effectuer des transactions de prêt. Cette application se concentre davantage sur la transaction elle-même. Elle est actuellement en phase de développement et a annoncé en juillet avoir obtenu un financement de 1,2 million de dollars lors d'un tour de pré-amorçage dirigé par GreenField.
Xion
Xion est une évolution de la marque Burnt, qui se concentrait auparavant sur les applications destinées aux consommateurs. Par la suite, l'équipe a découvert qu'il existait un problème de fragmentation considérable dans les interactions sur la chaîne, c'est pourquoi Xion a été construit pour améliorer cette situation. 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 et Mechanism.
(# =nil; Fondation
nil est le marché de la puissance de calcul ZK d'Ethereum, le co-processeur ZK et le développeur de Layer2, l'équipe ayant 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 le partage de traitements de transactions en parallèle et générer des ZKP, tandis que le principal partage vérifie les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. Le principal partage gère également la distribution des validateurs et des comptes dans le partage d'exécution. Le protocole de consensus utilisé par le comité de validation est également Hotstuff, ce qui est courant dans les derniers projets d'exécution parallèle. =nil; L2 a intégré la communication inter-partage dans le protocole dès le début. Les messages inter-partage sont vérifiés par le comité de validation de chaque partage en tant que transactions.
L'idée de base est de construire une architecture de communication inter-shard intégrée, similaire à l'IBC, à travers une architecture Layer2 fragmentée, afin de résoudre les problèmes de Liquidité et de dispersion des états. Cependant, le concept central n'est pas raisonnable, car le problème de la dispersion de la Liquidité est un problème multi-chaînes, et ce qui est construit est un Layer2 unique, ce qui signifie que pour résoudre cela, toutes les chaînes doivent devenir un shard de ZK-sharding, ce qui est difficile à réaliser.
![Recherche sur le problème de la rupture de liquidité à l'ère de Layer2])https://img-cdn.gateio.im/webp-social/moments-69852e6a1bbab8f4fc50f48006eb6fef.webp###
ERC-7683
Ethereum s'attaque également à ce problème de liquidité inter-chaînes. Actuellement, certains DEX, OP, etc., 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, standardisant les interfaces de commande et de règlement, et permettant une exécution sans couture des échanges inter-chaînes. Le cœur de ce projet est qu'un Filler, qui peut également être considéré comme le rôle de Solver dans l'abstraction de la chaîne, se charge du paiement. Cette proposition a été co-construite par un DEX et Across.