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

Après qu'Ethereum a adopté une solution d'extension centrée sur le Layer 2, et avec 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 le développement de l'écosystème difficile à suivre le rythme des chaînes publiques, ce qui entraîne des difficultés pour de nombreux projets dès le début.

Grâce à OP Stack, une plateforme d'échange a lancé sa propre Layer 2, tandis qu'une autre plateforme a publié un nouveau projet de blockchain ; grâce à la technologie ZK, une plateforme d'échange a lancé un nouveau niveau. Certaines grandes entreprises technologiques ont également lancé leurs propres projets de blockchain. Aujourd'hui, le coût et le niveau technique 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 s'élève à environ 10 000 dollars par mois.

L'avenir sera sans aucun doute une époque de coexistence de plusieurs chaînes. Bien que ces chaînes Layer 2 puissent choisir la compatibilité EVM pour réaliser l'interopérabilité, en raison des nombreuses applications en aval des entreprises technologiques traditionnelles qui les soutiennent, il leur est difficile de construire des applications et d'atteindre un consensus sur la même chaîne.

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 qu'il faut explorer et résoudre. Il existe actuellement de nombreuses solutions de liquidité, telles que l'abstraction de chaîne, les intentions, 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: C'est la couche avec laquelle les utilisateurs interagissent directement, et c'est aussi la couche la plus abstraite des solutions de Liquidité, car elle masque complètement les détails de la conversion de Liquidité. Dans la couche d'application, les utilisateurs interagissent avec l'interface utilisateur sans nécessairement comprendre le mécanisme de conversion de Liquidité sous-jacent.

Niveau d'autorisation : situé en dessous du niveau d'application, les utilisateurs se connectent à leur portefeuille à dApp et demandent des devis pour satisfaire leur intention de transaction. Ici, "intention" fait référence au résultat final de transaction attendu par l'utilisateur, et non à la voie d'exécution spécifique de la transaction.

Gestion des comptes et couches d'abstraction : En raison de l'existence d'environnements multi-chaînes, un système de gestion des comptes et d'abstraction adapté aux différentes chaînes est nécessaire pour maintenir la structure de compte unique de chaque chaîne. Certains projets ont construit un système de comptes de confiance, sans avoir besoin d'établir un consensus entre les chaînes, mais uniquement des engagements de confiance entre les systèmes de comptes existants. D'autres projets réalisent une gestion abstraite en générant des portefeuilles 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 ce qui concerne la liquidité, l'intégration s'est principalement concentrée sur les blockchains publiques existantes.

Résoudre la couche : 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 concurrence pour offrir une meilleure expérience utilisateur, notamment des temps de transaction et des vitesses d'exécution plus rapides. Sur cette base, divers solutions pilotées par l'intention ont été construites sur des projets basés sur l'intention. Des dérivés de ce type d'intention, tels que le composant Predicate, peuvent réaliser l'intention de l'utilisateur sous des règles spécifiques.

Couche de règlement : il s'agit de la couche intermédiaire utilisée par la couche de résolution pour réaliser l'intention de l'utilisateur. Les composants clés des solutions de liquidité et de dispersion d'état comprennent : des oracles, des ponts inter-chaînes, des solutions de confirmation anticipée et la disponibilité des données. De plus, il est nécessaire de prendre en compte la liquidité inter-chaînes, la finalité, le mécanisme de preuve Layer 2, etc., afin d'assurer le fonctionnement efficace de l'ensemble du système multi-chaînes.

Actuellement, il existe plusieurs solutions pour résoudre la liquidité prise les gens pour des idiots sur le marché. Après avoir examiné de nombreuses solutions, nous avons constaté qu'il existe principalement les façons suivantes :

1. Centré sur RaaS : similaire à certaines solutions Rollup, il aide à partager la liquidité et l'état des Rollups construits dessus en ajoutant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes. Cela espère résoudre la liquidité et la dispersion de l'état à un niveau plus élevé. Un aspect plus détaillé est le design d'un ordonnanceur partagé séparé, cette solution est davantage destinée au Layer 2 et n'est pas universelle.

2. Axé sur le compte : construire un portefeuille de compte sur toute la chaîne, permettant la signature et l'exécution de 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 la fragmentation de l'UX, elle implique une mise en œuvre backend complexe pour les développeurs et ne résout pas fondamentalement la liquidité et la dispersion des états.

3. Centré sur le réseau d'intention hors chaîne : c'est-à-dire notre "introduction" diagramme de l'architecture du gâteau dans le Solver Network, le cœur étant que les utilisateurs envoient des intentions au réseau Solver, ce rôle de Solver va faire concurrence pour les offres, fournissant le meilleur temps d'exécution et le prix de transaction. Ces Solvers peuvent être des Agents IA, des bourses, des teneurs de marché, voire le protocole intégré lui-même. Bien que l'intention puisse théoriquement réaliser des opérations inter-chaînes de complexité arbitraire, sa mise en œuvre nécessite suffisamment de Solvers de liquidité pour aider, et lorsque certaines demandes hors chaîne se présentent, il existe un risque de fraude avec les Solvers. Si des moyens tels que la preuve de fraude sont introduits, la mise en œuvre du réseau Solver deviendra plus difficile et le seuil d'entrée pour faire fonctionner un Solver sera également plus élevé.

4. Centré sur un réseau de liquidité en chaîne : cette direction vise à optimiser spécifiquement 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 développées, afin de partager la liquidité de l'ensemble de la chaîne.

5. Axé sur les applications en chaîne : Ce type d'application construit des applications à haute liquidité en intégrant des teneurs de marché importants ou des applications tierces. Ces projets nécessitent la gestion de processus inter-chaînes complexes, ce qui impose des exigences élevées aux développeurs, et ils sont donc également très susceptibles de présenter des vulnérabilités de sécurité.

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 réunissant 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, le Settlement Layer est la solution au niveau le plus atomique, et au-dessus de ces solutions atomiques comme les solutions cross-chain, les oracles et les Pre-Confirmation, se construit un niveau plus abstrait, 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, 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'apparition de nombreux problèmes dérivés complexes, c'est pourquoi, en ce qui concerne l'interopérabilité, une multitude de solutions ont émergé. Mais en essence, cela doit encore 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 résout le problème de la Liquidité en partant de son propre point de vue.

Un certain projet a construit un service RaaS dans le domaine de la DeFi, capable de fournir les composants nécessaires à la construction directe des protocoles DeFi, tels que les Oracles, les Types de Pools, l'IRM, les Actifs, etc. Il peut également fournir des composants tels que le Trading à Effet de Levier et les Stratégies de Rendement, prêts à l'emploi. Cela équivaut à d'autres applications de construction, mais la liquidité finale est placée dans la couche de liquidité de ce projet. Cependant, pour l'instant, son fonctionnement sous-jacent n'a pas été divulgué.

Un autre projet a construit trois composants principaux, à savoir la couche de compatibilité Intent, Validity et la couche de règlement général. Les applications externes ou la couche d'intention peuvent publier des intentions à ce projet, puis sa couche de compatibilité Intent peut convertir les intentions externes en un format que le Solver du protocole peut reconnaître, le format normalisé utilisé étant le langage Validity. Les nœuds de ce projet sont responsables 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 divulgué plus de détails sur le travail.

Il y a aussi un projet qui est une application décentralisée, permettant la découverte des prix basée sur des enchères et des pools de liquidité unilatéraux. Sa mission principale est de fournir aux entreprises de trading professionnelles des outils de gestion des stocks efficaces, et de se connecter facilement aux protocoles DeFi principaux lors de la liquidation des transactions en fonction de l'intention d'utilisation. Parallèlement, le projet a créé un marché de prêt pour effectuer des transactions de prêt. Cette application se concentre davantage sur le trading lui-même.

Un certain projet est issu d'une mise à niveau d'une autre marque, qui se concentrait auparavant sur des applications destinées aux consommateurs. Par la suite, l'équipe a constaté qu'il y avait un problème de fragmentation considérable dans les interactions sur la chaîne, c'est pourquoi un nouveau projet a été créé pour améliorer cette situation. Celui-ci est construit 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.

Une certaine fondation est un développeur du marché de la puissance de calcul ZK d'Ethereum, des coprocesseurs ZK et de Layer 2, l'équipe possède de solides compétences techniques en ZK. Elle a proposé une solution zkSharding, qui utilise la technologie ZK pour étendre horizontalement la chaîne principale d'Ethereum, exécuter le traitement des transactions en parallèle par le biais de sharding et générer des ZKP, tandis que le shard principal vérifie les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. Le shard principal gère également la distribution des validateurs et des comptes dans le shard 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 les plus récents. Cette solution intègre la communication inter-sharding dans le protocole dès le départ. Les messages inter-sharding sont vérifiés par le comité de validation de chaque shard en tant que transactions.

Son idée de base est de construire une architecture de communication inter-shard intégrée, similaire à IBC, à travers une architecture Layer 2 par le biais de sharding, 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 que ce qui est construit est un unique Layer 2, ce qui signifie que pour le résoudre, toutes les chaînes doivent devenir un shard de ZK-sharding, ce qui est difficile à réaliser.

Ethereum est également en train de s'attaquer à ce problème de liquidité inter-chaînes. Actuellement, plusieurs projets principaux soutiennent publiquement un certain standard ERC, utilisant également une méthode inter-chaînes basée sur l'intention. 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, permettant une exécution inter-chaînes transparente. Le cœur de cette initiative 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 est construite conjointement par deux projets principaux et est actuellement examinée par le groupe de travail.

Certaines piles technologiques, les normes ERC susmentionnées et zkSharding, sont toutes des solutions internes d'Ethereum pour la fragmentation de la liquidité entre Layer 2, résolvant respectivement les problèmes au niveau de l'architecture, du consensus et des applications. Cette pile technologique conçoit une solution complète multi Layer 2 pour résoudre d'un seul coup les problèmes de transmission d'informations et de décentralisation du Sequencer. Lorsque vous utilisez cette architecture de pile technologique, des contrats inter-chaînes sont automatiquement déployés, et un Supervisor existe pour contester et éviter la transmission de fausses informations inter-chaînes. Actuellement, plusieurs projets connus utilisent cette architecture de pile technologique.

Résoudre les problèmes de liquidité inter-chaînes est un domaine très complexe avec de nombreuses solutions. Par exemple, les solutions Layer 2 sont divisées en solutions intégrées de messages inter-chaînes d'Ethereum, en particulier celles qui utilisent les normes ERC mentionnées ci-dessus, ainsi que des séquenceurs partagés construits sur certaines piles technologiques. En dehors du contexte Layer 2, tous les Layer 1 aussi.