Étude des problèmes de fragmentation de la liquidité à l'ère des Layer2
Avec le passage d'Ethereum vers des solutions d'extension centrées sur Layer 2, ainsi que l'émergence d'outils tels que RaaS, de nombreuses blockchains publiques se développent rapidement. Beaucoup d'entités souhaitent construire leur propre chaîne pour représenter différents intérêts et chercher une valorisation plus élevée. Cependant, l'émergence de nombreuses blockchains publiques rend difficile le développement de l'écosystème, ce qui entraîne l'échec de nombreux projets dès le TGE.
Grâce à OP Stack, une plateforme de trading a lancé sa propre Base Layer 2, une autre plateforme a publié Ink ; avec la technologie ZK, une plateforme a lancé XLayer ; Sony a publié Soneium, et LINE a lancé Kaia, entre autres. 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 sans aucun doute une époque de coexistence multichaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour assurer l'interopérabilité, il leur est difficile de construire des applications sur la même chaîne et d'atteindre un consensus 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 répartition 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. Il existe actuellement de nombreuses solutions de Liquidité, comme celles dont nous avons tous entendu parler : l'abstraction de chaîne, l'intention, l'exécution de clearing, le CrossChain natif, le ZKSharding, mais leur essence fondamentale est la même.
Nous utilisons une architecture Cake reconnue dans l'industrie pour introduire 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 aussi 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 de permission (Permission Layer)
Situé sous la couche d'application, l'utilisateur satisfait son intention de transaction en connectant son portefeuille à dApp et en demandant un devis. Ici, "intention" fait référence au résultat final de transaction attendu par l'utilisateur (c'est-à-dire la sortie), plutôt qu'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'environnements multi-chaînes, un système de gestion de comptes et d'abstraction adapté à différentes chaînes est nécessaire pour maintenir la structure de comptes unique de chaque chaîne. Par exemple, le système de comptes centré sur les objets de SUI est complètement différent de l'EVM. One Balance est un projet représentatif dans ce domaine, qui construit un système de comptes de confiance sans avoir besoin d'établir un consensus inter-chaînes, mais uniquement des engagements de confiance entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant des portefeuilles de comptes multi-chaînes pour les utilisateurs, optimisant ainsi considérablement l'expérience utilisateur et réduisant la fragmentation de l'UX. Cependant, en ce qui concerne la liquidité, il intègre principalement les chaînes publiques existantes.
Couche de résolution (Solver Layer)
Ce niveau est responsable de la réception et de la réalisation des intentions de transaction des utilisateurs. Le rôle de Solver y est en concurrence pour offrir une meilleure expérience utilisateur, y compris des temps et des vitesses d'exécution des transactions plus rapides. Sur cette base, des projets basés sur l'intention tels qu'Anoma ont construit diverses solutions axées sur l'intention. Des produits dérivés de ce type d'intention, 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éaliser l'intention de l'utilisateur. Les composants clés 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) : responsables de la transmission d'informations et de liquidité entre les chaînes.
Confirmation préalable (Pre-Confirmation) : 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 Layer 2, etc., afin d'assurer le bon fonctionnement de l'ensemble du système multichaîne.
Solution
Actuellement, il existe plusieurs solutions pour résoudre la séparation de la liquidité sur le marché. Après avoir examiné un grand nombre de solutions, nous avons constaté qu'il y a principalement plusieurs façons :
Centré sur RaaS : des solutions de Rollup comme OP Stack, en intégrant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour aider à construire des Rollup sur OP Stack et partager la liquidité et l'état. Cela vise à résoudre la liquidité et la dispersion des états à un niveau supérieur. Il y a une conception plus segmentée des ordonnanceurs partagés, cette solution est davantage destinée à Layer2, n'ayant pas de caractère universel, comme Astria, Espresso, etc.
Axé sur le compte : similaire à NEAR, construire un portefeuille de compte complet sur la chaîne, soutenu par une technologie appelée "signature de chaîne" pour signer et exécuter des transactions à travers plusieurs protocoles de blockchain. Le composant central est le réseau MPC, qui remplace les utilisateurs pour signer les transactions multi-chaînes. Ce système, bien qu'il puisse grandement résoudre le problème de la fragmentation de l'expérience utilisateur, implique une mise en œuvre backend complexe pour les développeurs, et ne résout pas essentiellement la liquidité et la dispersion des états.
Centré sur un réseau d'intention hors chaîne : c'est-à-dire le Solver Network dans notre diagramme d'architecture de gâteau "Introduction". Le cœur de ce réseau est l'envoi d'intentions par les utilisateurs au réseau Solver, où le rôle de Solver consiste à faire concurrence sur les offres pour fournir le meilleur temps d'exécution et le meilleur prix de transaction. Ces Solvers peuvent être des agents AI, 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 l'intention puisse théoriquement permettre d'effectuer des opérations inter-chaînes de complexité arbitraire, sa mise en œuvre nécessite suffisamment de Solvers avec liquidité pour assister, et lorsque des demandes hors chaîne se présentent, il y a un risque de fraude de la part des Solvers. Si l'on introduit des moyens de preuve de fraude, la difficulté de mise en œuvre du Solver Network augmentera, et le seuil d'entrée pour faire fonctionner un Solver sera également plus élevé.
Centré sur un réseau de liquidité on-chain : 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 on-chain. Son cœur est de construire une couche de liquidité, sur laquelle des applications sont construites pour partager la liquidité de toute la chaîne. Certains projets incluent : Raye Network, INFINIT, Everclear, Elixir, etc.
Axé sur les applications en chaîne : Ce type d'application construit des applications à haute liquidité en intégrant de grands MM ou d'autres applications tierces, telles que Liquorice, Socket, Radiant Capital, un DEX, Hedgemony, etc. Ces projets doivent gérer des processus complexes inter-chaînes, ce qui impose des exigences très élevées aux développeurs, et par conséquent, ils sont également très susceptibles de subir des attaques de hackers.
Résoudre le problème de Liquidité est une question très importante, le monde financier représente souvent que la Liquidité signifie tout. Si nous pouvons construire une plateforme intégrée de Liquidité, en particulier en intégrant la Liquidité fragmentée de l'ensemble de la chaîne, cela aura un potentiel très important, 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 la 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, à savoir la couche de solveur, 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, correspondent à ces différents niveaux, que l'on peut comprendre comme une relation de chaîne d'approvisionnement. Cependant, ces solutions ne sont toujours pas des solutions atomiques. Le problème de la fragmentation de la liquidité entraîne l'émergence de nombreux problèmes dérivés complexes. Par conséquent, face à l'interopérabilité, une multitude de solutions a vu le jour. Mais en substance, cela dépend toujours de ces composants. Nous allons maintenant discuter de quelques projets typiques liés aux concepts d'abstraction de chaîne pour voir comment chacun d'entre eux aborde le problème de la fragmentation de la liquidité à partir de son propre point de départ.
INFINIT
INFINIT a construit un service RaaS pour le 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 Trading avec effet de levier et la Stratégie de rendement, prêts à être utilisés. 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é. INFINIT a déjà levé 6 millions de dollars lors d'un tour de financement d'amorçage avec Robot Ventures, Electric Capital et Maelstrom Capital.
Khalani Network
Khalani a construit trois composants principaux : la couche de compatibilité d'intention, la validité et la couche de règlement universelle.
Les applications externes ou les couches d'intentions peuvent publier des intentions à Khalani, puis la couche de compatibilité des Intent de Khalani peut convertir les intentions externes en un format reconnu par le Solver de protocole, le format normalisé utilisé étant le langage Validity. Le nœud Khalani est responsable de la soumission des résultats finaux à la couche de règlement général via des ponts inter-chaînes, des technologies de règlement rapide, etc. Ce projet est encore en phase de construction et n'a pas encore révélé plus de détails sur le travail. En août, il a obtenu un financement de 2,2 millions de dollars lors d'un tour de financement de semences de la part d'Ethereal Ventures, Nascent, Maelstrom Capital, etc.
Réglisse
Liquorice est une application décentralisée qui permet la découverte des prix basée sur des enchères et des pools de liquidité unilatéraux. La mission principale de Liquorice est de fournir aux entreprises de trading professionnelles des outils efficaces de gestion des stocks et de se connecter facilement aux protocoles DeFi de base lors de la liquidation des transactions avec intention d'utilisation. Parallèlement, Liquorice a créé un marché de prêt pour ses transactions de prêt. Cette application se concentre davantage sur la transaction elle-même. Actuellement encore en phase de développement, elle a annoncé en juillet avoir obtenu un financement de pré-amorçage de 1,2 million de dollars dirigé par GreenField.
Xion
Xion est une évolution de la marque Burnt, qui se concentrait auparavant sur les applications destinées aux consommateurs. Par la suite, l'équipe a constaté qu'il existait un problème de fragmentation des 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 comme Animoca, Multicoin, Alliance DAO et Mechanism.
=nil; Fondation
nil est le marché de puissance de calcul ZK d'Ethereum, un co-processeur ZK et un développeur de Layer2, l'équipe possède une solide expertise en technologie ZK. Elle a proposé la solution zkSharding, qui utilise la technologie ZK pour étendre horizontalement le réseau principal 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 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-fragments sont validés par le comité de validation de chaque fragment en tant que transactions.
L'idée de base est de construire une architecture de communication inter-chaînes intégrée, similaire à l'IBC, à travers une architecture Layer2 fragmenté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 que résout la dispersion de Liquidité est un problème multi-chaînes, alors que ce qui est construit est un Layer2 unique, ce qui signifie que pour résoudre cela, toutes les chaînes doivent devenir un fragment de ZK-sharding, ce qui est difficile à réaliser.
ERC-7683
Ethereum s'attaque également à ce problème de liquidité inter-chaînes. Actuellement, certains des principaux Layer 2 et DEX prennent d'abord en charge le standard ERC7683, qui utilise également une méthode inter-chaînes basée sur l'intention. Son objectif principal est d'établir un standard commun pour les opérations inter-chaines entre L2 et les sidechains, de standardiser les interfaces de commande et de règlement, et de permettre une exécution inter-chaînes transparente. Son principal noyau est qu'un Filler peut également.
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.
16 J'aime
Récompense
16
6
Reposter
Partager
Commentaire
0/400
GasFeeCryer
· Il y a 3h
Donner de l'argent sans faire de cross-chain.
Voir l'originalRépondre0
GasBandit
· Il y a 11h
Encore en train de rouler L2.
Voir l'originalRépondre0
DecentralizedElder
· Il y a 11h
Encore un prendre les gens pour des idiots ?
Voir l'originalRépondre0
PriceOracleFairy
· Il y a 11h
je secoue la tête en regardant ces l2s se fragmenter comme les promesses de mon ex... la théorie des jeux de liquidité est brutalement difficile en ce moment
Voir l'originalRépondre0
MEVSandwich
· Il y a 11h
prendre les gens pour des idiots encore et encore, même le Portefeuille ne suffit presque plus.
Voir l'originalRépondre0
NestedFox
· Il y a 11h
prendre les gens pour des idiots ? Avec un pont, ce n'est pas pareil ?
Exploration des problèmes de liquidité et des solutions dans l'ère Layer2
Étude des problèmes de fragmentation de la liquidité à l'ère des Layer2
Avec le passage d'Ethereum vers des solutions d'extension centrées sur Layer 2, ainsi que l'émergence d'outils tels que RaaS, de nombreuses blockchains publiques se développent rapidement. Beaucoup d'entités souhaitent construire leur propre chaîne pour représenter différents intérêts et chercher une valorisation plus élevée. Cependant, l'émergence de nombreuses blockchains publiques rend difficile le développement de l'écosystème, ce qui entraîne l'échec de nombreux projets dès le TGE.
Grâce à OP Stack, une plateforme de trading a lancé sa propre Base Layer 2, une autre plateforme a publié Ink ; avec la technologie ZK, une plateforme a lancé XLayer ; Sony a publié Soneium, et LINE a lancé Kaia, entre autres. 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 sans aucun doute une époque de coexistence multichaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour assurer l'interopérabilité, il leur est difficile de construire des applications sur la même chaîne et d'atteindre un consensus 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 répartition 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. Il existe actuellement de nombreuses solutions de Liquidité, comme celles dont nous avons tous entendu parler : l'abstraction de chaîne, l'intention, l'exécution de clearing, le CrossChain natif, le ZKSharding, mais leur essence fondamentale est la même.
Nous utilisons une architecture Cake reconnue dans l'industrie pour introduire 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 aussi 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 de permission (Permission Layer)
Situé sous la couche d'application, l'utilisateur satisfait son intention de transaction en connectant son portefeuille à dApp et en demandant un devis. Ici, "intention" fait référence au résultat final de transaction attendu par l'utilisateur (c'est-à-dire la sortie), plutôt qu'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'environnements multi-chaînes, un système de gestion de comptes et d'abstraction adapté à différentes chaînes est nécessaire pour maintenir la structure de comptes unique de chaque chaîne. Par exemple, le système de comptes centré sur les objets de SUI est complètement différent de l'EVM. One Balance est un projet représentatif dans ce domaine, qui construit un système de comptes de confiance sans avoir besoin d'établir un consensus inter-chaînes, mais uniquement des engagements de confiance entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant des portefeuilles de comptes multi-chaînes pour les utilisateurs, optimisant ainsi considérablement l'expérience utilisateur et réduisant la fragmentation de l'UX. Cependant, en ce qui concerne la liquidité, il intègre principalement les chaînes publiques existantes.
Couche de résolution (Solver Layer)
Ce niveau est responsable de la réception et de la réalisation des intentions de transaction des utilisateurs. Le rôle de Solver y est en concurrence pour offrir une meilleure expérience utilisateur, y compris des temps et des vitesses d'exécution des transactions plus rapides. Sur cette base, des projets basés sur l'intention tels qu'Anoma ont construit diverses solutions axées sur l'intention. Des produits dérivés de ce type d'intention, 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éaliser l'intention de l'utilisateur. Les composants clés 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 Layer 2, etc., afin d'assurer le bon fonctionnement de l'ensemble du système multichaîne.
Solution
Actuellement, il existe plusieurs solutions pour résoudre la séparation de la liquidité sur le marché. Après avoir examiné un grand nombre de solutions, nous avons constaté qu'il y a principalement plusieurs façons :
Centré sur RaaS : des solutions de Rollup comme OP Stack, en intégrant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour aider à construire des Rollup sur OP Stack et partager la liquidité et l'état. Cela vise à résoudre la liquidité et la dispersion des états à un niveau supérieur. Il y a une conception plus segmentée des ordonnanceurs partagés, cette solution est davantage destinée à Layer2, n'ayant pas de caractère universel, comme Astria, Espresso, etc.
Axé sur le compte : similaire à NEAR, construire un portefeuille de compte complet sur la chaîne, soutenu par une technologie appelée "signature de chaîne" pour signer et exécuter des transactions à travers plusieurs protocoles de blockchain. Le composant central est le réseau MPC, qui remplace les utilisateurs pour signer les transactions multi-chaînes. Ce système, bien qu'il puisse grandement résoudre le problème de la fragmentation de l'expérience utilisateur, implique une mise en œuvre backend complexe pour les développeurs, et ne résout pas essentiellement la liquidité et la dispersion des états.
Centré sur un réseau d'intention hors chaîne : c'est-à-dire le Solver Network dans notre diagramme d'architecture de gâteau "Introduction". Le cœur de ce réseau est l'envoi d'intentions par les utilisateurs au réseau Solver, où le rôle de Solver consiste à faire concurrence sur les offres pour fournir le meilleur temps d'exécution et le meilleur prix de transaction. Ces Solvers peuvent être des agents AI, 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 l'intention puisse théoriquement permettre d'effectuer des opérations inter-chaînes de complexité arbitraire, sa mise en œuvre nécessite suffisamment de Solvers avec liquidité pour assister, et lorsque des demandes hors chaîne se présentent, il y a un risque de fraude de la part des Solvers. Si l'on introduit des moyens de preuve de fraude, la difficulté de mise en œuvre du Solver Network augmentera, et le seuil d'entrée pour faire fonctionner un Solver sera également plus élevé.
Centré sur un réseau de liquidité on-chain : 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 on-chain. Son cœur est de construire une couche de liquidité, sur laquelle des applications sont construites pour partager la liquidité de toute la chaîne. Certains projets incluent : Raye Network, INFINIT, Everclear, Elixir, etc.
Axé sur les applications en chaîne : Ce type d'application construit des applications à haute liquidité en intégrant de grands MM ou d'autres applications tierces, telles que Liquorice, Socket, Radiant Capital, un DEX, Hedgemony, etc. Ces projets doivent gérer des processus complexes inter-chaînes, ce qui impose des exigences très élevées aux développeurs, et par conséquent, ils sont également très susceptibles de subir des attaques de hackers.
Résoudre le problème de Liquidité est une question très importante, le monde financier représente souvent que la Liquidité signifie tout. Si nous pouvons construire une plateforme intégrée de Liquidité, en particulier en intégrant la Liquidité fragmentée de l'ensemble de la chaîne, cela aura un potentiel très important, 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 la 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, à savoir la couche de solveur, 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, correspondent à ces différents niveaux, que l'on peut comprendre comme une relation de chaîne d'approvisionnement. Cependant, ces solutions ne sont toujours pas des solutions atomiques. Le problème de la fragmentation de la liquidité entraîne l'émergence de nombreux problèmes dérivés complexes. Par conséquent, face à l'interopérabilité, une multitude de solutions a vu le jour. Mais en substance, cela dépend toujours de ces composants. Nous allons maintenant discuter de quelques projets typiques liés aux concepts d'abstraction de chaîne pour voir comment chacun d'entre eux aborde le problème de la fragmentation de la liquidité à partir de son propre point de départ.
INFINIT
INFINIT a construit un service RaaS pour le 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 Trading avec effet de levier et la Stratégie de rendement, prêts à être utilisés. 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é. INFINIT a déjà levé 6 millions de dollars lors d'un tour de financement d'amorçage avec Robot Ventures, Electric Capital et Maelstrom Capital.
Khalani Network
Khalani a construit trois composants principaux : la couche de compatibilité d'intention, la validité et la couche de règlement universelle.
Les applications externes ou les couches d'intentions peuvent publier des intentions à Khalani, puis la couche de compatibilité des Intent de Khalani peut convertir les intentions externes en un format reconnu par le Solver de protocole, le format normalisé utilisé étant le langage Validity. Le nœud Khalani est responsable de la soumission des résultats finaux à la couche de règlement général via des ponts inter-chaînes, des technologies de règlement rapide, etc. Ce projet est encore en phase de construction et n'a pas encore révélé plus de détails sur le travail. En août, il a obtenu un financement de 2,2 millions de dollars lors d'un tour de financement de semences de la part d'Ethereal Ventures, Nascent, Maelstrom Capital, etc.
Réglisse
Liquorice est une application décentralisée qui permet la découverte des prix basée sur des enchères et des pools de liquidité unilatéraux. La mission principale de Liquorice est de fournir aux entreprises de trading professionnelles des outils efficaces de gestion des stocks et de se connecter facilement aux protocoles DeFi de base lors de la liquidation des transactions avec intention d'utilisation. Parallèlement, Liquorice a créé un marché de prêt pour ses transactions de prêt. Cette application se concentre davantage sur la transaction elle-même. Actuellement encore en phase de développement, elle a annoncé en juillet avoir obtenu un financement de pré-amorçage de 1,2 million de dollars dirigé par GreenField.
Xion
Xion est une évolution de la marque Burnt, qui se concentrait auparavant sur les applications destinées aux consommateurs. Par la suite, l'équipe a constaté qu'il existait un problème de fragmentation des 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 comme Animoca, Multicoin, Alliance DAO et Mechanism.
=nil; Fondation
nil est le marché de puissance de calcul ZK d'Ethereum, un co-processeur ZK et un développeur de Layer2, l'équipe possède une solide expertise en technologie ZK. Elle a proposé la solution zkSharding, qui utilise la technologie ZK pour étendre horizontalement le réseau principal 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 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-fragments sont validés par le comité de validation de chaque fragment en tant que transactions.
L'idée de base est de construire une architecture de communication inter-chaînes intégrée, similaire à l'IBC, à travers une architecture Layer2 fragmenté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 que résout la dispersion de Liquidité est un problème multi-chaînes, alors que ce qui est construit est un Layer2 unique, ce qui signifie que pour résoudre cela, toutes les chaînes doivent devenir un fragment de ZK-sharding, ce qui est difficile à réaliser.
ERC-7683
Ethereum s'attaque également à ce problème de liquidité inter-chaînes. Actuellement, certains des principaux Layer 2 et DEX prennent d'abord en charge le standard ERC7683, qui utilise également une méthode inter-chaînes basée sur l'intention. Son objectif principal est d'établir un standard commun pour les opérations inter-chaines entre L2 et les sidechains, de standardiser les interfaces de commande et de règlement, et de permettre une exécution inter-chaînes transparente. Son principal noyau est qu'un Filler peut également.