Étude sur le problème de la Liquidité dans l'ère du Layer 2

Avec le passage d'Ethereum à une solution d'extension axée sur Layer 2, ainsi que l'émergence d'outils tels que RaaS, de nombreuses blockchains 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 blockchains publiques rend le développement de l'écosystème difficile à suivre le rythme des blockchains publiques, entraînant la chute de nombreux projets dès leur TGE.

Grâce à OP Stack, une plateforme de trading a lancé son propre Base Layer 2, une autre plateforme de trading a publié Ink ; grâce à la technologie ZK, une plateforme a lancé XLayer ; Sony a publié Soneium, LINE a lancé Kaia, etc. Aujourd'hui, le coût et les barrières techniques pour construire une chaîne ont considérablement diminué, 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 d'une coexistence multichaîne. 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, avec de nombreuses applications en aval, 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 multichaîne 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 nettoyage, le CrossChain natif, et le ZKSharding, 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 avec l'utilisateur, 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 frontale sans nécessairement comprendre le mécanisme de conversion de liquidité sous-jacent.

Couche de Permission (Permission Layer)

Situé en dessous de la couche d'application, l'utilisateur se connecte à un portefeuille avec le dApp et demande un devis pour satisfaire son intention de transaction. Ici, « intention » fait référence au résultat final de transaction que l'utilisateur espère (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 des comptes et d'abstraction adapté à différentes chaînes est nécessaire pour maintenir la structure unique des comptes 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 seulement un engagement de confiance entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant des portefeuilles de comptes multichaînes pour les utilisateurs, optimisant 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 de transaction et des vitesses d'exécution plus rapides. Sur cette base, des projets basés sur des intentions ont construit diverses solutions axées sur les intentions. Des dérivés de ce type d'intentions, tels que le composant Predicate, peuvent réaliser les intentions des utilisateurs sous certaines règles.

Couche de règlement (Settlement Layer)

C'est la couche intermédiaire utilisée pour résoudre les intentions des utilisateurs. Les composants principaux des solutions de liquidité et de dispersion des états comprennent :

• Oracle : utilisé pour obtenir des informations sur l'état des autres chaînes.
• Ponts (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 faut également prendre en compte la liquidité inter-chaînes, la finalité et les mécanismes de preuve Layer 2 pour garantir le bon fonctionnement 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 y a principalement ces quelques méthodes :

1. Axé sur RaaS : des solutions Rollup comme OP Stack, en intégrant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour faciliter le partage de liquidité et d'état des Rollups construits sur OP Stack. Cela vise à résoudre la dispersion de la liquidité et de l'état dans une direction de niveau supérieur. Un aspect plus détaillé est la conception d'ordonnanceurs partagés séparés, cette solution est davantage axée sur Layer 2 et n'est pas universelle.

2. Centré sur le compte : Construire un portefeuille de compte sur toute la chaîne, prenant en charge la signature et l'exécution des transactions à travers plusieurs protocoles de blockchain grâce à une technologie appelée « signature de chaîne ». Le composant central est le réseau MPC, remplaçant l'utilisateur pour signer les transactions multichaînes. Bien que cette solution puisse grandement résoudre le problème de fragmentation de l'UX, elle implique une mise en œuvre backend complexe pour les développeurs et ne résout pas en essence la liquidité et la dispersion des états.

3. Centré sur le réseau d'intentions hors chaîne : c'est-à-dire le Solver Network dans notre diagramme d'architecture de « Introduction » au gâteau, le cœur est que les utilisateurs envoient des intentions au réseau Solver, ce rôle de Solver pour rivaliser avec des offres, fournissant le meilleur temps d'achèvement et le meilleur prix de transaction, ces Solvers peuvent être des agents AI, CEX, Market Maker ou même le protocole intégré lui-même. Bien que les intentions puissent théoriquement réaliser des opérations inter-chaînes de complexité arbitraire, leur mise en œuvre nécessite suffisamment de Solvers de liquidité pour aider, et lorsqu'il s'agit de certaines exigences hors chaîne, il existe un risque de fraude de la part des Solvers. Si des moyens tels que la preuve de fraude sont introduits, la difficulté de mise en œuvre du Solver Network augmentera, tout comme le seuil d'entrée pour faire fonctionner un Solver.

4. 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 peuvent être construites pour 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 de grands MM, ou des applications tierces, etc. Ces projets doivent gérer des processus inter-chaînes complexes, 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 intégrant la Liquidité, en particulier en rassemblant la Liquidité fragmentée de toute la chaîne, cela aura un potentiel énorme, 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 de niveau le plus atomique. Au-dessus de ces solutions atomiques telles que les solutions inter-chaînes, les oracles et les solutions de Pre-Confirmation, se construit une couche plus abstraite, à savoir 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 et peuvent être comprises comme une relation amont-aval. Cependant, ces solutions ne sont toujours pas des solutions atomiques. L'ensemble du problème de fragmentation de la liquidité a entraîné l'émergence de nombreux problèmes dérivés complexes. Par conséquent, en ce qui concerne l'interopérabilité, une multitude de solutions ont émergé. Mais essentiellement, cela dépend toujours 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é depuis son propre point de départ.

INFINIT a construit un service RaaS pour le DeFi, capable de fournir directement les composants nécessaires à la construction de protocoles DeFi, tels que les Oracles, les Types de Pool, l'IRM, les Actifs, etc. Il peut également fournir des composants tels que le Trading avec Effet de Levier et les Stratégies de Rendement, qui sont immédiatement utilisables. Cela équivaut à d'autres applications de construction, mais la liquidité finale est placée dans la couche de liquidité d'Infinit. Cependant, pour le moment, son fonctionnement sous-jacent n'a pas encore été divulgué.

Khalani a construit trois composants clés, à 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 à Khalani, puis la couche de compatibilité Intent de Khalani peut transformer les intentions externes en un format que le Solver de protocole peut reconnaître, le format normalisé utilisé est le langage Validity. Les nœuds Khalani sont responsables 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.

Liquorice est une application décentralisée permettant la découverte des prix basée sur des enchères et des pools de liquidité unidirectionnels. La mission principale de Liquorice 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 selon l'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 le trading lui-même.

Xion 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 le rend plus natif et sécurisé que d'autres ponts inter-chaînes.

=nil; La Fondation a proposé une solution zkSharding, qui utilise la technologie ZK pour étendre horizontalement la blockchain principale d'Ethereum, exécuter le traitement parallèle des fragments et générer des ZKP, tandis que le fragment principal valide 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, qui est courant dans les projets d'exécution parallèle récents. =nil; L2 a intégré dès le départ la communication inter-fragments dans le protocole.

Ethereum travaille également à résoudre le problème de la liquidité inter-chaînes. Actuellement, certaines plateformes d'échange majeures soutiennent d'abord le standard ERC7683, qui utilise également une méthode inter-chaîne 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, de standardiser les interfaces de commande et de règlement, et d'atteindre une exécution inter-chaînes sans faille. Le cœur de ce concept est qu'un Filler peut également être considéré comme le rôle de Solver dans l'abstraction de la chaîne pour le paiement.

OP Stack conçoit une solution complète multi Layer 2 pour résoudre en une seule fois les problèmes de transmission d'informations et de décentralisation des Séquenceurs. Lors de l'utilisation de 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.

Résoudre le problème de la liquidité inter-chaînes est un domaine très complexe avec de nombreuses solutions. Les solutions Layer 2 se divisent en celles qui utilisent des messages inter-chaînes intégrés à Ethereum, en particulier ERC-7683, ainsi que Layer 2 comme OP qui construit OP Stack pour partager le Sequencer. En dehors du contexte Layer 2, tous les Layer 1 font également face à des problèmes de liquidité, d'état et de fragmentation de l'expérience utilisateur. Il existe des solutions spécifiquement centrées sur les applications pour la liquidité, ainsi que des solutions hors chaîne comme Solver Network, et même des solutions centrées sur le compte comme NEAR, mais cela nécessite également de s'appuyer sur des rôles hors chaîne comme Solver.

La liquidité inter-chaînes, l'état et la fragmentation de l'expérience utilisateur sont des problèmes de l'ensemble de l'industrie de la blockchain. Si l'on pense de manière globale, il est nécessaire d'adopter une approche plus abstraite, semblable à l'abstraction de chaîne, ce qui équivaut à être véritablement.