Étude sur le problème de la fragmentation de la liquidité à l'ère du Layer 2

Avec le passage d'Ethereum à des solutions d'extension centrées sur le Layer 2 et l'émergence d'outils tels que RaaS, de nombreuses chaînes publiques se développent rapidement. 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 le rythme des chaînes publiques, entraînant de nombreux projets à connaître une rupture lors de leur TGE.

Grâce à OP Stack, une plateforme de trading a lancé sa propre Base Layer 2, une autre plateforme de trading a publié Ink ; grâce à la technologie ZK, une plateforme de trading 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 été considérablement réduits, le coût d'exploitation d'une chaîne basée sur OP Stack étant d'environ 10 000 dollars par mois.

L'avenir sera sans aucun doute celui d'une coexistence de plusieurs chaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour assurer l'interopérabilité, il est difficile pour les entités Web2 qui les soutiennent de construire des applications et d'atteindre un consensus sur la même chaîne en raison d'un grand nombre d'applications en aval.

L'écosystème multichaîne actuel pose un nouveau défi : la liquidité et la dispersion des états. Étant donné que l'existence de plusieurs chaînes est inévitable, l'interopérabilité est un domaine qui doit être exploré et résolu. Il existe actuellement de nombreuses solutions de liquidité, telles que l'abstraction de chaîne, l'intention, l'exécution de clearing, le cross-chain 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 la couche d'interaction directe des utilisateurs, ainsi que la couche la plus abstraite dans les 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 droits (Permission Layer)

Situé en dessous de la couche d'application, l'utilisateur se connecte à un portefeuille avec le dApp et demande un devis pour satisfaire son intention de transaction. Ici, l'« 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 des comptes et abstraction de clé (Key Management and Account Abstraction)

En raison de l'existence d'un environnement multi-chaînes, il est nécessaire d'avoir un système de gestion de comptes et d'abstraction qui s'adapte à différentes chaînes pour maintenir la structure de compte unique de chaque chaîne. Par exemple, le système de comptes centrés sur les objets de SUI est complètement différent de l'EVM. One Balance est un projet représentatif dans ce domaine, qui a construit un système de comptes de confiance sans nécessiter de consensus inter-chaînes, mais seulement 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, 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.

Couche de résolution (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 compete 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 les intentions ont construit diverses solutions pilotées par les intentions. Des dérivés de ce type d'intentions, tels que le composant Predicate, peuvent réaliser les intentions des utilisateurs selon des règles spécifiques.

Couche de règlement (Settlement Layer)

C'est la couche intermédiaire utilisée pour résoudre le niveau d'intention des utilisateurs. Les composants clés des solutions de Liquidité et de décentralisation des états incluent :

• Oracle : utilisé pour obtenir des informations d'état sur d'autres chaînes.
• Ponts (Bridges) : responsables de la transmission des informations et de la liquidité entre 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 faut également prendre en compte la liquidité entre les chaînes, la finalité, le mécanisme de preuve Layer 2 et d'autres facteurs pour garantir le fonctionnement efficace de l'ensemble du système multichaîne.

Solution

Actuellement, il existe plusieurs solutions sur le marché pour résoudre la liquidité prise les gens pour des idiots. Après avoir examiné de nombreuses solutions, nous avons constaté qu'il y a principalement ces quelques méthodes :

1. Centré sur RaaS : des solutions Rollup comme OP Stack aident à construire des Rollups partagés de liquidité et d'état sur OP Stack en intégrant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes. Cela vise à résoudre la dispersion de la liquidité et de l'état à un niveau supérieur. Un aspect plus détaillé est la conception d'un ordonnanceur partagé distinct, cette solution est plus spécifiquement destinée à Layer 2 et n'est pas universelle.

2. Centré sur le compte : construire un portefeuille de compte sur toute la chaîne, en utilisant une technologie appelée « signature de chaîne » pour prendre en charge la signature et l'exécution de transactions à travers divers protocoles de blockchain. 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'UX, elle implique des implémentations backend complexes pour les développeurs et ne résout pas essentiellement la liquidité et la dispersion des états.

3. Centré sur le réseau d'intentions hors chaîne : le cœur est que les utilisateurs envoient des intentions au réseau Solver, ce rôle de Solver se bat pour des offres, fournissant le meilleur temps d'exécution et le meilleur prix de transaction. Ces Solvers peuvent être des agents IA, des CEX, des market makers ou même des protocoles intégrés eux-mêmes. Bien que les intentions puissent théoriquement permettre des opérations inter-chaînes de complexité arbitraire, il est nécessaire d'avoir des Solvers suffisamment liquides pour aider à leur réalisation. De plus, lorsqu'il s'agit de certaines demandes hors chaîne, il existe un risque de fraude avec les Solvers. Si des moyens comme des preuves de fraude sont introduits, la difficulté de mise en œuvre du réseau Solver augmentera et la barre d'entrée pour faire fonctionner un Solver sera également plus élevée.

4. Centré sur le réseau de liquidité on-chain : cette direction vise spécifiquement à optimiser les problèmes de liquidité inter-chaînes, mais n'a pas résolu les autres problèmes de dispersion des états on-chain. Son noyau est de construire une couche de liquidité, sur laquelle des applications sont construites pour partager la liquidité de l'ensemble de la chaîne.

5. Axé sur les applications sur la chaîne : Ces applications construisent des applications à haute liquidité en intégrant de grands MM ou d'autres applications tierces. Ces projets nécessitent la gestion de processus complexes entre chaînes, ce qui impose des exigences élevées aux développeurs, et sont donc également très susceptibles de subir des attaques de hackers.

Résoudre le problème de la Liquidité est un enjeu très important, dans le monde financier, la Liquidité représente souvent tout. Si nous pouvons construire une plateforme intégrant la Liquidité, en particulier en intégrant la Liquidité fragmentée de toute la chaîne, cela aurait un potentiel énorme, et nous avons également examiné de nombreuses solutions différentes.

Dans les deux classifications ci-dessus, nous pouvons voir qu'en fonction de la structure du gâteau, le Settlement Layer est la solution au niveau le plus atomique. Au-dessus de ces solutions atomiques comme les solutions inter-chaînes, les oracles et les Pre-Confirmation, se construit un niveau plus abstrait, à savoir le Solver Layer, le Permission Layer et l'Application Layer. Les différentes solutions abstraites ou de liquidité que nous avons énumérées ci-dessus, qui sont construites dans différentes directions, correspondent à ces différents niveaux et peuvent être comprises comme une relation 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. Ainsi, en ce qui concerne l'interopérabilité, une multitude de solutions a vu le jour. Mais en essence, cela doit toujours dépendre 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 pour le secteur DeFi, capable de fournir directement les composants nécessaires à la construction des protocoles DeFi, tels que Oracle, Pool Type, IRM, Asset, etc. Il peut également fournir des composants tels que le Trading à 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 le niveau de liquidité d'Infinit. Cependant, son fonctionnement sous-jacent n'a pas encore été divulgué. Actuellement, INFINIT a déjà obtenu 6 millions de dollars de financement de seed de la part de certaines institutions d'investissement.

Khalani Network

Khalani a construit trois composants essentiels, à savoir la couche de compatibilité Intent, Validity et la couche de règlement universelle.

Les applications externes ou la couche d'intention peuvent publier des intentions à Khalani, puis la couche de compatibilité d'Intent de Khalani peut convertir les intentions externes en un format que le protocole Solver peut reconnaître, le format normalisé utilisé étant le langage Validity. Les nœuds Khalani sont responsables de la soumission des résultats finaux à la couche de règlement universelle 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 divulgué 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 seed auprès de certains investisseurs.

Liquorice

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 des outils de gestion des stocks efficaces pour les sociétés de trading professionnelles et de se connecter facilement aux protocoles DeFi de base lors de la liquidation des transactions selon l'intention d'utilisation. Parallèlement, Liquorice a créé un marché de prêt pour effectuer ses transactions de prêt. Cette application est davantage axée sur la transaction elle-même. Elle est actuellement encore 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 mené par un certain fonds d'investissement.

Xion

Xion est une mise à niveau de la marque Burnt, qui, par le passé, se concentrait sur des applications destinées aux consommateurs. L'équipe a ensuite découvert un problème de fragmentation importante dans les interactions sur la chaîne, et a donc construit Xion pour remédier à cela. 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 participé à quatre tours de financement et a obtenu le soutien de plusieurs institutions d'investissement.

=nil; Fondation

nil est le marché de puissance de calcul ZK d'Ethereum, un coprocesseur ZK et un développeur de Layer 2, l'équipe possède une solide expertise en technologie ZK. Ils ont proposé la 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 le fragment 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-fragments dans le protocole depuis le début. Les messages inter-fragments sont vérifiés par le comité de validation de chaque fragment en tant que transactions.

L'idée de base est de construire une architecture de communication inter-fragments intégrée, similaire à IBC, à travers une architecture de Layer 2 fragmentée, ce qui permettrait de résoudre les problèmes de liquidité et de dispersion d'état. Cependant, son idée centrale n'est pas raisonnable, car le problème que la dispersion de liquidité vise à résoudre est celui des multichaînes, alors qu'il construit un Layer 2 unique, ce qui signifie que pour résoudre ce problème, toutes les chaînes devraient devenir un fragment de ZK-sharding, ce qui est difficile à réaliser.

ERC-7683

Ethereum travaille également à résoudre ce problème de liquidité inter-chaînes. Actuellement, certains projets bien connus soutiennent d'abord le standard ERC7683, qui utilise également une méthode inter-chaînes basée sur Intent. Son objectif principal est d'établir un standard universel pour les opérations inter-chaînes entre Layer 2 et les chaînes latérales, standardiser les commandes et les interfaces de règlement, et réaliser une exécution inter-chaînes sans couture. Son élément central est un Filler, qui peut également être considéré comme un rôle de Solver dans l'abstraction de la chaîne pour le paiement. Cette proposition est construite par certains projets bien connus et est actuellement examinée par le groupe de travail Cake.

OP Stack

OP Stack, ERC-7683 et zkSharding sont tous des solutions internes d'Ethereum pour la fragmentation de la liquidité entre Layer2, respectivement résolues au niveau de l'architecture, du consensus et de l'application. OP Stack conçoit une solution complète multi-Layer2 pour résoudre une fois pour toutes les problèmes de transmission d'informations et de décentralisation des Sequencers. Lorsque vous utilisez l'architecture OP Stack, des contrats inter-chaînes sont automatiquement déployés, et un Supervisor est présent pour contester afin d'éviter la transmission de fausses informations inter-chaînes. Actuellement, plusieurs plateformes de trading et projets réputés utilisent l'architecture OP Stack.

Parmi eux, le plus typique est Unichain. Unichain se concentre principalement sur la collaboration avec