Étude sur le problème de la fragmentation de la liquidité à l'ère du Layer 2
Après qu'Ethereum se soit tourné vers une solution d'extensibilité basée sur Layer 2, avec la montée en puissance d'outils tels que RaaS, de nombreuses chaînes publiques se sont rapidement développées. Beaucoup d'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 le développement de l'écosystème difficile à suivre, entraînant l'échec de nombreux projets dès le TGE.
Grâce à OP Stack, une plateforme de trading a lancé son propre Layer 2, une autre plateforme a publié Ink ; grâce à la technologie ZK, une plateforme de trading a lancé XLayer ; Sony a publié Soneium, LINE a lancé Kaia, etc. Aujourd'hui, le coût et la technologie nécessaires pour construire une chaîne ont considérablement diminué, et le coût d'exploitation d'une chaîne basée sur OP Stack est d'environ 10 000 dollars par mois.
L'avenir sera sans aucun doute 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 des nombreuses 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 des chaînes multiples est inévitable, l'interopérabilité est un domaine qui doit être exploré et résolu. Actuellement, il existe de nombreuses solutions de Liquidité, telles que l'abstraction de chaîne, l'intention, l'exécution de Clearing, le CrossChain natif, le ZKSharding, mais leur essence fondamentale reste la même.
Nous utilisons l'architecture Cake, qui est 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 la couche d'interaction directe avec l'utilisateur, et c'est la couche la plus abstraite des solutions de liquidité, car elle 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 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 souhaité par l'utilisateur (, c'est-à-dire la sortie ), et non au chemin d'exécution spécifique de la transaction.
Gestion des comptes et abstraction des clés (Key Management and Account Abstraction)
En raison de l'existence d'un environnement multichaînes, un système de gestion de compte et d'abstraction adapté aux différentes chaînes est nécessaire pour maintenir les structures de compte uniques de chaque chaîne. Par exemple, le système de compte centré sur les objets de SUI est complètement différent de l'EVM. One Balance est un projet représentatif dans ce domaine, qui construit un système de comptes fiable sans avoir besoin d'établir un consensus inter-chaînes, mais seulement des engagements de confiance entre les systèmes de comptes existants. Near Account réalise une gestion d'abstraction 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 termes de liquidité, il 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 et des vitesses d'exécution plus rapides. Sur cette base, des projets basés sur l'intention comme Anoma ont construit diverses solutions pilotées par l'intention. 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 ( Couches de règlement )
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é incluent :
Oracles (Oracle ) : utilisé pour obtenir des informations sur l'état d'autres chaînes.
Ponts inter-chaînes ( Bridges ) : responsables de la transmission d'informations et de liquidité entre les chaînes.
Confirmation anticipée (: réduire le temps de confirmation inter-chaînes.
Disponibilité des données ) DA ( : Fournir l'accessibilité des données.
De plus, il faut également prendre en compte la liquidité entre les chaînes, la finalité )Finality(, le mécanisme de preuve Layer 2, etc., pour garantir le bon fonctionnement de l'ensemble du système multichaîne.
![Recherche sur le problème de la liquidité prise les gens pour des idiots à l'ère du Layer 2])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
Solution
Actuellement, il existe plusieurs solutions sur le marché pour résoudre la liquidité prise les gens pour des idiots. Après avoir examiné un grand nombre de solutions, nous avons constaté qu'il existe principalement ces quelques méthodes :
Centré sur RaaS : des solutions Rollup telles que OP Stack, en ajoutant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour aider à partager la liquidité et l'état des Rollups construits sur OP Stack. Cela vise à résoudre la dispersion de la liquidité et de l'état à un niveau supérieur. Un aspect plus spécifique ici est la conception d'ordonnanceurs partagés distincts, cette solution est davantage axée sur Layer 2 et n'est pas universelle, comme Astria, Espresso et Flashbots, etc.
Centré sur le compte : similaire à NEAR, construire un portefeuille de compte sur toute la chaîne, en s'appuyant sur une technologie appelée "signature de chaîne" pour signer et exécuter des transactions à travers divers protocoles de blockchain. Le composant central est le réseau MPC, qui remplace les utilisateurs pour signer des transactions multichaînes. Bien que cette solution puisse grandement résoudre le problème de la fragmentation de l'expérience utilisateur, elle implique un backend complexe pour les développeurs et ne résout pas en essence la liquidité et la dispersion des états.
Centré sur le réseau d'intentions hors chaîne : il s'agit du Solver Network dans notre diagramme d'architecture du gâteau "Introduction", où l'utilisateur envoie des intentions au réseau Solver. Ce rôle de Solver concourt pour des offres, fournissant le meilleur temps d'achèvement et le prix de transaction. Ces Solvers peuvent être des agents IA, des CEX, des Market Makers, ou même des protocoles intégrés comme Liquorice, etc. Les projets dans ce domaine incluent Anoma, Khalani, Enso, aori et Valantis. Bien que les intentions puissent théoriquement réaliser des opérations inter-chaînes d'une complexité arbitraire, il est nécessaire d'avoir suffisamment de Solvers liquides pour aider à leur réalisation. De plus, lorsqu'il s'agit de besoins hors chaîne, il existe un risque de fraude de la part des Solvers. Si des méthodes telles que les preuves de fraude sont introduites, la mise en œuvre du Solver Network deviendra plus difficile, et les barrières à l'entrée pour faire fonctionner un Solver seront également plus élevées.
Centré sur le 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 une couche de liquidité, sur laquelle des applications sont construites pour partager la liquidité de l'ensemble de la chaîne. Quelques projets incluent : Raye Network, INFINIT, Everclear, Elixir, etc.
Centré sur les applications en chaîne : ces applications construisent des applications à haute Liquidité en intégrant de grands MM ou des applications tierces, comme Liquorice, Socket, Radiant Capital, une plateforme d'échange, Hedgemony, etc. Ces projets nécessitent la gestion de processus complexes inter-chaînes, ce qui impose des exigences très élevées aux développeurs, et ils 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 d'intégration de liquidité, en particulier en intégrant la liquidité fragmentée de toute la chaîne, cela aura un potentiel très grand, et nous avons également examiné de nombreuses solutions différentes.
Dans les deux classifications ci-dessus, nous pouvons voir que, selon la structure en couches, le Settlement Layer est la solution la plus atomique. Au-dessus de ces solutions atomiques telles que les solutions inter-chaînes, les oracles et les Pre-Confirmation, se construit une couche plus abstraite, qui est le Solver Layer, le Permission Layer et l'Application Layer. Les différentes solutions d'abstraction ou de liquidité que nous avons énumérées ci-dessus, construites dans différentes directions, correspondent à ces différents niveaux, pouvant être comprises comme des relations en amont et en 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, c'est pourquoi, en ce qui concerne l'interopérabilité, une multitude de solutions a vu le jour. Mais en essence, cela dépend toujours de ces composants. Nous allons maintenant discuter de quelques projets typiques d'abstraction de chaîne pour voir comment chacun d'eux aborde le problème de la fragmentation de la liquidité depuis son propre point de départ.
![Recherche sur le problème de la liquidité prenant les gens pour des idiots à l'ère Layer2])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp(
) INFINIT
INFINIT a construit un service RaaS pour le secteur DeFi, capable de fournir les composants nécessaires à la construction directe de protocoles DeFi, tels que Oracle, Pool Type, IRM, Asset, etc. Il peut également proposer des composants tels que le Trading avec effet de levier et la Stratégie de rendement, qui sont prêts à être utilisés immédiatement. Cela équivaut aux autres applications de construction, mais la liquidité finale est placée dans la couche de liquidité d'Infinit. Cependant, à ce jour, son fonctionnement sous-jacent n'a pas encore été divulgué. Actuellement, INFINIT a déjà levé 6 millions de dollars lors d'un tour de financement de démarrage auprès de Robot Ventures, Electric Capital et Maelstrom Capital.
Réseau Khalani
Khalani a construit trois composants fondamentaux, à savoir la couche de compatibilité des intentions, 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 dans un format que le protocole Solver peut reconnaître, le format normalisé utilisé étant le langage Validity. Le nœud Khalani est responsable 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. En août, il a obtenu 2,2 millions de dollars lors d'un tour de financement de démarrage de la part d'Ethereal Ventures, Nascent, Maelstrom Capital, etc.
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és unilatéraux. La mission principale de Liquorice est de fournir aux sociétés de trading professionnelles des outils efficaces de gestion des stocks, tout en se connectant facilement à certains protocoles DeFi clés tels que certains DEX lors de la liquidation des transactions basées sur l'intention d'utilisation. Parallèlement, Liquorice a créé un marché de prêt pour effectuer des transactions de prêt. Cette application est davantage axée sur le trading lui-même. Elle est encore en phase de développement et a annoncé en juillet avoir levé 1,2 million de dollars lors d'un tour de financement Pre-seed dirigé par GreenField.
Xion
Xion est une évolution de la marque Burnt. Auparavant, Burnt se concentrait sur les applications destinées aux consommateurs, mais l'équipe a découvert un problème de fragmentation considérable 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 tels qu'Animoca, Multicoin, Alliance DAO et Mechanism.
=nil; Fondation
nil est le marché de la puissance de calcul ZK d'Ethereum, un coprocesseur ZK et un développeur de Layer 2, l'équipe possède une solide expertise en technologie ZK. Ils ont proposé une solution zkSharding, qui utilise la technologie ZK pour étendre horizontalement la chaîne principale d'Ethereum, exécuter le traitement parallèle des transactions en fragmentant 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 derniers projets d'exécution parallèle. =nil; L2 a intégré la communication inter-fragment dans le protocole dès le début. Les messages inter-fragments sont validés par le comité de validation de chaque fragment comme des transactions.
Son idée de base est de construire une architecture de communication inter-fragments intégrée similaire à l'IBC à travers une architecture de Layer 2 fragmentée, ce qui permettrait de résoudre les problèmes de liquidité et de dispersion des états. Cependant, son idée centrale n'est pas raisonnable, car le problème de la dispersion de la liquidité est un problème multi-chaînes, alors qu'il construit un Layer 2 unique, ce qui signifie que pour résoudre ce problème, toutes les chaînes doivent devenir un fragment de ZK-sharding, ce qui est difficile à réaliser.
ERC-7683
Ethereum est également en train de s'attaquer à ce problème de liquidité inter-chaînes. Actuellement, certains Layer 2, certains Layer 2 et certains DEX sont les premiers à soutenir publiquement le standard ERC7683, qui utilise également une méthode inter-chaînes basée sur l'Intent. Son objectif principal est d'établir un standard universel pour les opérations inter-chaînes entre L2 et les sidechains, standardisant les interfaces de commande et de règlement, et réalisant une exécution inter-chaînes sans couture. Son élément central est un Filler, qui peut également être considéré comme le rôle de Solver dans l'abstraction de la chaîne pour le paiement. Cette proposition a été construite conjointement par un certain DEX et Across, et elle 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 visant à résoudre la fragmentation de la liquidité entre les Layer 2.
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.
11 J'aime
Récompense
11
5
Partager
Commentaire
0/400
GateUser-1a2ed0b9
· Il y a 6h
La bulle de valorisation a déjà révélé sa vraie nature.
Voir l'originalRépondre0
FOMOmonster
· Il y a 6h
Tout le monde veut manger de la viande.
Voir l'originalRépondre0
SeasonedInvestor
· Il y a 6h
Le phénomène de tomber en dessous du prix d'émission est devenu la norme.
La fragmentation de la liquidité à l'ère du Layer 2 : analyse des défis et des solutions
Étude sur le problème de la fragmentation de la liquidité à l'ère du Layer 2
Après qu'Ethereum se soit tourné vers une solution d'extensibilité basée sur Layer 2, avec la montée en puissance d'outils tels que RaaS, de nombreuses chaînes publiques se sont rapidement développées. Beaucoup d'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 le développement de l'écosystème difficile à suivre, entraînant l'échec de nombreux projets dès le TGE.
Grâce à OP Stack, une plateforme de trading a lancé son propre Layer 2, une autre plateforme a publié Ink ; grâce à la technologie ZK, une plateforme de trading a lancé XLayer ; Sony a publié Soneium, LINE a lancé Kaia, etc. Aujourd'hui, le coût et la technologie nécessaires pour construire une chaîne ont considérablement diminué, et le coût d'exploitation d'une chaîne basée sur OP Stack est d'environ 10 000 dollars par mois.
L'avenir sera sans aucun doute 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 des nombreuses 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 des chaînes multiples est inévitable, l'interopérabilité est un domaine qui doit être exploré et résolu. Actuellement, il existe de nombreuses solutions de Liquidité, telles que l'abstraction de chaîne, l'intention, l'exécution de Clearing, le CrossChain natif, le ZKSharding, mais leur essence fondamentale reste la même.
Nous utilisons l'architecture Cake, qui est 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 la couche d'interaction directe avec l'utilisateur, et c'est la couche la plus abstraite des solutions de liquidité, car elle 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 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 souhaité par l'utilisateur (, c'est-à-dire la sortie ), et non au chemin d'exécution spécifique de la transaction.
Gestion des comptes et abstraction des clés (Key Management and Account Abstraction)
En raison de l'existence d'un environnement multichaînes, un système de gestion de compte et d'abstraction adapté aux différentes chaînes est nécessaire pour maintenir les structures de compte uniques de chaque chaîne. Par exemple, le système de compte centré sur les objets de SUI est complètement différent de l'EVM. One Balance est un projet représentatif dans ce domaine, qui construit un système de comptes fiable sans avoir besoin d'établir un consensus inter-chaînes, mais seulement des engagements de confiance entre les systèmes de comptes existants. Near Account réalise une gestion d'abstraction 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 termes de liquidité, il 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 et des vitesses d'exécution plus rapides. Sur cette base, des projets basés sur l'intention comme Anoma ont construit diverses solutions pilotées par l'intention. 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 ( Couches de règlement )
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é incluent :
De plus, il faut également prendre en compte la liquidité entre les chaînes, la finalité )Finality(, le mécanisme de preuve Layer 2, etc., pour garantir le bon fonctionnement de l'ensemble du système multichaîne.
![Recherche sur le problème de la liquidité prise les gens pour des idiots à l'ère du Layer 2])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
Solution
Actuellement, il existe plusieurs solutions sur le marché pour résoudre la liquidité prise les gens pour des idiots. Après avoir examiné un grand nombre de solutions, nous avons constaté qu'il existe principalement ces quelques méthodes :
Centré sur RaaS : des solutions Rollup telles que OP Stack, en ajoutant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour aider à partager la liquidité et l'état des Rollups construits sur OP Stack. Cela vise à résoudre la dispersion de la liquidité et de l'état à un niveau supérieur. Un aspect plus spécifique ici est la conception d'ordonnanceurs partagés distincts, cette solution est davantage axée sur Layer 2 et n'est pas universelle, comme Astria, Espresso et Flashbots, etc.
Centré sur le compte : similaire à NEAR, construire un portefeuille de compte sur toute la chaîne, en s'appuyant sur une technologie appelée "signature de chaîne" pour signer et exécuter des transactions à travers divers protocoles de blockchain. Le composant central est le réseau MPC, qui remplace les utilisateurs pour signer des transactions multichaînes. Bien que cette solution puisse grandement résoudre le problème de la fragmentation de l'expérience utilisateur, elle implique un backend complexe pour les développeurs et ne résout pas en essence la liquidité et la dispersion des états.
Centré sur le réseau d'intentions hors chaîne : il s'agit du Solver Network dans notre diagramme d'architecture du gâteau "Introduction", où l'utilisateur envoie des intentions au réseau Solver. Ce rôle de Solver concourt pour des offres, fournissant le meilleur temps d'achèvement et le prix de transaction. Ces Solvers peuvent être des agents IA, des CEX, des Market Makers, ou même des protocoles intégrés comme Liquorice, etc. Les projets dans ce domaine incluent Anoma, Khalani, Enso, aori et Valantis. Bien que les intentions puissent théoriquement réaliser des opérations inter-chaînes d'une complexité arbitraire, il est nécessaire d'avoir suffisamment de Solvers liquides pour aider à leur réalisation. De plus, lorsqu'il s'agit de besoins hors chaîne, il existe un risque de fraude de la part des Solvers. Si des méthodes telles que les preuves de fraude sont introduites, la mise en œuvre du Solver Network deviendra plus difficile, et les barrières à l'entrée pour faire fonctionner un Solver seront également plus élevées.
Centré sur le 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 une couche de liquidité, sur laquelle des applications sont construites pour partager la liquidité de l'ensemble de la chaîne. Quelques projets incluent : Raye Network, INFINIT, Everclear, Elixir, etc.
Centré sur les applications en chaîne : ces applications construisent des applications à haute Liquidité en intégrant de grands MM ou des applications tierces, comme Liquorice, Socket, Radiant Capital, une plateforme d'échange, Hedgemony, etc. Ces projets nécessitent la gestion de processus complexes inter-chaînes, ce qui impose des exigences très élevées aux développeurs, et ils 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 d'intégration de liquidité, en particulier en intégrant la liquidité fragmentée de toute la chaîne, cela aura un potentiel très grand, et nous avons également examiné de nombreuses solutions différentes.
Dans les deux classifications ci-dessus, nous pouvons voir que, selon la structure en couches, le Settlement Layer est la solution la plus atomique. Au-dessus de ces solutions atomiques telles que les solutions inter-chaînes, les oracles et les Pre-Confirmation, se construit une couche plus abstraite, qui est le Solver Layer, le Permission Layer et l'Application Layer. Les différentes solutions d'abstraction ou de liquidité que nous avons énumérées ci-dessus, construites dans différentes directions, correspondent à ces différents niveaux, pouvant être comprises comme des relations en amont et en 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, c'est pourquoi, en ce qui concerne l'interopérabilité, une multitude de solutions a vu le jour. Mais en essence, cela dépend toujours de ces composants. Nous allons maintenant discuter de quelques projets typiques d'abstraction de chaîne pour voir comment chacun d'eux aborde le problème de la fragmentation de la liquidité depuis son propre point de départ.
![Recherche sur le problème de la liquidité prenant les gens pour des idiots à l'ère Layer2])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp(
) INFINIT
INFINIT a construit un service RaaS pour le secteur DeFi, capable de fournir les composants nécessaires à la construction directe de protocoles DeFi, tels que Oracle, Pool Type, IRM, Asset, etc. Il peut également proposer des composants tels que le Trading avec effet de levier et la Stratégie de rendement, qui sont prêts à être utilisés immédiatement. Cela équivaut aux autres applications de construction, mais la liquidité finale est placée dans la couche de liquidité d'Infinit. Cependant, à ce jour, son fonctionnement sous-jacent n'a pas encore été divulgué. Actuellement, INFINIT a déjà levé 6 millions de dollars lors d'un tour de financement de démarrage auprès de Robot Ventures, Electric Capital et Maelstrom Capital.
Réseau Khalani
Khalani a construit trois composants fondamentaux, à savoir la couche de compatibilité des intentions, 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 dans un format que le protocole Solver peut reconnaître, le format normalisé utilisé étant le langage Validity. Le nœud Khalani est responsable 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. En août, il a obtenu 2,2 millions de dollars lors d'un tour de financement de démarrage de la part d'Ethereal Ventures, Nascent, Maelstrom Capital, etc.
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és unilatéraux. La mission principale de Liquorice est de fournir aux sociétés de trading professionnelles des outils efficaces de gestion des stocks, tout en se connectant facilement à certains protocoles DeFi clés tels que certains DEX lors de la liquidation des transactions basées sur l'intention d'utilisation. Parallèlement, Liquorice a créé un marché de prêt pour effectuer des transactions de prêt. Cette application est davantage axée sur le trading lui-même. Elle est encore en phase de développement et a annoncé en juillet avoir levé 1,2 million de dollars lors d'un tour de financement Pre-seed dirigé par GreenField.
Xion
Xion est une évolution de la marque Burnt. Auparavant, Burnt se concentrait sur les applications destinées aux consommateurs, mais l'équipe a découvert un problème de fragmentation considérable 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 tels qu'Animoca, Multicoin, Alliance DAO et Mechanism.
=nil; Fondation
nil est le marché de la puissance de calcul ZK d'Ethereum, un coprocesseur ZK et un développeur de Layer 2, l'équipe possède une solide expertise en technologie ZK. Ils ont proposé une solution zkSharding, qui utilise la technologie ZK pour étendre horizontalement la chaîne principale d'Ethereum, exécuter le traitement parallèle des transactions en fragmentant 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 derniers projets d'exécution parallèle. =nil; L2 a intégré la communication inter-fragment dans le protocole dès le début. Les messages inter-fragments sont validés par le comité de validation de chaque fragment comme des transactions.
Son idée de base est de construire une architecture de communication inter-fragments intégrée similaire à l'IBC à travers une architecture de Layer 2 fragmentée, ce qui permettrait de résoudre les problèmes de liquidité et de dispersion des états. Cependant, son idée centrale n'est pas raisonnable, car le problème de la dispersion de la liquidité est un problème multi-chaînes, alors qu'il construit un Layer 2 unique, ce qui signifie que pour résoudre ce problème, toutes les chaînes doivent devenir un fragment de ZK-sharding, ce qui est difficile à réaliser.
ERC-7683
Ethereum est également en train de s'attaquer à ce problème de liquidité inter-chaînes. Actuellement, certains Layer 2, certains Layer 2 et certains DEX sont les premiers à soutenir publiquement le standard ERC7683, qui utilise également une méthode inter-chaînes basée sur l'Intent. Son objectif principal est d'établir un standard universel pour les opérations inter-chaînes entre L2 et les sidechains, standardisant les interfaces de commande et de règlement, et réalisant une exécution inter-chaînes sans couture. Son élément central est un Filler, qui peut également être considéré comme le rôle de Solver dans l'abstraction de la chaîne pour le paiement. Cette proposition a été construite conjointement par un certain DEX et Across, et elle 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 visant à résoudre la fragmentation de la liquidité entre les Layer 2.