Étude sur le problème de la liquidité prise les gens pour des idiots à 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 comme 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 difficile le développement de l'écosystème pour suivre le rythme de ces blockchains, ce qui entraîne l'échec de nombreux projets dès leur TGE.
Grâce à OP Stack, une plateforme de trading a lancé sa propre Base Layer 2, une autre plateforme a publié Ink ; grâce à la technologie ZK, une plateforme de trading a lancé XLayer ; Sony a lancé Soneium, LINE a lancé Kaia, etc. Aujourd'hui, le coût et les barrières technologiques 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 une époque de coexistence multichaî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, avec leurs 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 de multichaînes est inévitable, l'interopérabilité est un domaine qui doit être exploré et résolu. Actuellement, il existe de nombreuses solutions de Liquidité, comme l'abstraction de chaîne, l'intention, l'exécution de clearing, le Native CrossChain, ZKSharding, etc., mais leur essence fondamentale reste 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 la couche la plus abstraite des solutions de liquidité, car elle masque complètement les détails de la conversion de liquidité. À 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 à dApp et demande un devis pour satisfaire son intention de transaction. Ici, l'« 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 multi-chaînes, il est nécessaire d'avoir un système de gestion de comptes et d'abstraction adapté à différentes chaînes pour maintenir la structure de compte unique 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 nécessiter de consensus inter-chaînes, mais simplement des engagements fiables entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant un portefeuille 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 s'intègre principalement aux chaînes publiques existantes.
Couche de résolution (Solver Layer)
Cette couche est responsable de la réception et de la mise en œuvre des intentions de transaction des utilisateurs, le rôle de Solver y 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, divers solutions axées sur les intentions ont été construites. Des dérivés de ce type d'intentions, tels que le composant Predicate, peuvent réaliser les intentions des utilisateurs sous des règles spécifiques.
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 des solutions de Liquidité et d'état décentralisé incluent :
Oracle : utilisé pour obtenir des informations sur l'état d'autres chaînes.
Ponts inter-chaînes (Bridges) : responsables de la transmission des informations et de la 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é entre les chaînes, la finalité et les mécanismes de preuve Layer 2, afin de 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 existe principalement ces quelques méthodes :
Centré sur RaaS : des solutions de Rollup comme OP Stack, en ajoutant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour aider à construire une liquidité et un état partagés pour les Rollups construits sur OP Stack. Cela vise à résoudre la dispersion de la liquidité et de l'état à un niveau supérieur. Il y a un aspect plus segmenté qui est le design d'ordonnanceurs partagés distincts, cette solution est davantage axée sur Layer 2 et n'est pas universelle.
Centré sur le compte : construire un portefeuille de compte sur toute 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 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'expérience utilisateur, elle 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 le réseau d'intention hors chaîne : le cœur est que les utilisateurs envoient des intentions au réseau Solver, ce rôle de Solver va concurrencer les offres, fournissant le meilleur temps d'exécution et le meilleur prix de transaction. Ces Solvers peuvent être des agents AI, des CEX, des Market Makers, 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 lorsqu'il s'agit de certaines demandes hors chaîne, il existe un risque de fraude de la part des Solvers. Si des moyens tels que les preuves de fraude sont introduits, la difficulté de mise en œuvre du réseau Solver sera encore plus élevée, et le seuil d'entrée pour faire fonctionner les Solvers sera également plus élevé.
Centré sur le réseau de liquidité on-chain : cette direction est spécialement dédiée à l'optimisation des problèmes de liquidité inter-chaînes, mais n'a pas résolu les problèmes de décentralisation des états on-chain d'autres chaînes. 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.
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. Ces projets nécessitent la gestion de processus inter-chaînes complexes, 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 les problèmes de liquidité est un enjeu très important, car dans le monde financier, la liquidité représente souvent tout. Si l'on peut construire une plateforme intégrant la liquidité, en particulier en rassemblant la liquidité fragmentée de l'ensemble de la chaîne, cela pourrait avoir un très grand potentiel, 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 la plus atomique. Au-dessus de ces solutions atomiques telles que les solutions inter-chaînes, les oracles et les pré-confirmations, 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 listées ci-dessus, 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, et c'est pourquoi, en matière d'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înes pour voir comment chacun d'eux aborde le problème de la fragmentation de la Liquidité depuis son propre point de départ.
Un certain projet a construit un service RaaS dans le domaine de la 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 fournir des composants tels que le Leverage Trading et la Yield Strategy, immédiatement opérationnels. Cela équivaut à un autre point de construction d'application, mais la liquidité finale est placée dans la couche de liquidité de ce projet. Cependant, il n'a pas encore révélé le fonctionnement sous-jacent.
Un autre projet a construit trois composants clés, à savoir la couche de compatibilité des Intent, la Validity et la couche de règlement universel. Les applications externes ou la couche d'intention peuvent publier des intentions à ce projet, puis sa couche de compatibilité des Intent peut transformer 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 soumettre le résultat final à la couche de règlement universel 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.
Il existe également 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. Sa mission principale est de fournir aux sociétés de trading professionnelles des outils de gestion des stocks efficaces et de se connecter facilement aux protocoles DeFi de base lors du règlement des transactions basées sur 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 encore plus sur le trading lui-même. Elle est actuellement encore en phase de développement.
Un certain projet 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.
Un autre projet est le marché de puissance de calcul ZK d'Ethereum, le coprocesseur ZK et les développeurs de Layer 2, l'équipe ayant 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 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, qui est courant dans les projets d'exécution parallèle récents. Ce projet L2 a intégré la communication inter-shard dans le protocole dès le début. Les messages inter-shard sont validés par le comité de validation de chaque shard en tant que transactions.
Son idée fondamentale est de construire une architecture de communication inter-fragment similaire à l'IBC, intégrée à une architecture Layer 2 par le biais de la fragmentation, ce qui permettrait de résoudre les problèmes de Liquidité et de décentralisation des états. Cependant, son idée centrale n'est pas raisonnable, car le problème de la décentralisation 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.
Ethereum est également en train de s'attaquer à ce problème de liquidité inter-chaînes. Actuellement, certains projets soutiennent d'abord 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 commun pour les opérations inter-chaînes entre L2 et les chaînes latérales, de normaliser les interfaces de commande et de règlement, et de réaliser une exécution inter-chaînes transparente. Le cœur de cette approche repose principalement sur un Filler, qui peut également être considéré comme le rôle de Solver dans l'abstraction de chaîne pour le paiement. Cette proposition est actuellement examinée par le groupe de travail Cake.
OP Stack, ERC-7683 et zkSharding sont tous des solutions internes d'Ethereum pour résoudre la fragmentation de la liquidité entre les Layer 2, traitant respectivement les niveaux d'architecture, de consensus et d'application. 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. Lorsque vous utilisez l'architecture OP Stack, des contrats inter-chaînes sont automatiquement déployés, et un superviseur existe pour contester afin d'éviter la transmission d'informations inter-chaînes fausses. Actuellement, certaines plateformes de trading majeures utilisent l'architecture OP Stack.
Parmi eux, le plus typique est Unichain. Unichain fonctionne principalement en se connectant au réseau Superchain.
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.
9 J'aime
Récompense
9
5
Partager
Commentaire
0/400
GasFeeCrier
· Il y a 15h
Il y a peu de projets dans la chaîne.
Voir l'originalRépondre0
ApyWhisperer
· 07-29 09:15
Développez tôt des scénarios cross-chain.
Voir l'originalRépondre0
ETHReserveBank
· 07-29 09:09
tomber en dessous du prix d'émission doit être attribué à l'émission excessive
L'ère de Layer 2 : exploration des problèmes de liquidité et des solutions
Étude sur le problème de la liquidité prise les gens pour des idiots à 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 comme 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 difficile le développement de l'écosystème pour suivre le rythme de ces blockchains, ce qui entraîne l'échec de nombreux projets dès leur TGE.
Grâce à OP Stack, une plateforme de trading a lancé sa propre Base Layer 2, une autre plateforme a publié Ink ; grâce à la technologie ZK, une plateforme de trading a lancé XLayer ; Sony a lancé Soneium, LINE a lancé Kaia, etc. Aujourd'hui, le coût et les barrières technologiques 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 une époque de coexistence multichaî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, avec leurs 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 de multichaînes est inévitable, l'interopérabilité est un domaine qui doit être exploré et résolu. Actuellement, il existe de nombreuses solutions de Liquidité, comme l'abstraction de chaîne, l'intention, l'exécution de clearing, le Native CrossChain, ZKSharding, etc., mais leur essence fondamentale reste 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 la couche la plus abstraite des solutions de liquidité, car elle masque complètement les détails de la conversion de liquidité. À 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 à dApp et demande un devis pour satisfaire son intention de transaction. Ici, l'« 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 multi-chaînes, il est nécessaire d'avoir un système de gestion de comptes et d'abstraction adapté à différentes chaînes pour maintenir la structure de compte unique 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 nécessiter de consensus inter-chaînes, mais simplement des engagements fiables entre les systèmes de comptes existants. Near Account réalise une gestion abstraite en générant un portefeuille 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 s'intègre principalement aux chaînes publiques existantes.
Couche de résolution (Solver Layer)
Cette couche est responsable de la réception et de la mise en œuvre des intentions de transaction des utilisateurs, le rôle de Solver y 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, divers solutions axées sur les intentions ont été construites. Des dérivés de ce type d'intentions, tels que le composant Predicate, peuvent réaliser les intentions des utilisateurs sous des règles spécifiques.
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 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é et les mécanismes de preuve Layer 2, afin de 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 existe principalement ces quelques méthodes :
Centré sur RaaS : des solutions de Rollup comme OP Stack, en ajoutant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour aider à construire une liquidité et un état partagés pour les Rollups construits sur OP Stack. Cela vise à résoudre la dispersion de la liquidité et de l'état à un niveau supérieur. Il y a un aspect plus segmenté qui est le design d'ordonnanceurs partagés distincts, cette solution est davantage axée sur Layer 2 et n'est pas universelle.
Centré sur le compte : construire un portefeuille de compte sur toute 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 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'expérience utilisateur, elle 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 le réseau d'intention hors chaîne : le cœur est que les utilisateurs envoient des intentions au réseau Solver, ce rôle de Solver va concurrencer les offres, fournissant le meilleur temps d'exécution et le meilleur prix de transaction. Ces Solvers peuvent être des agents AI, des CEX, des Market Makers, 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 lorsqu'il s'agit de certaines demandes hors chaîne, il existe un risque de fraude de la part des Solvers. Si des moyens tels que les preuves de fraude sont introduits, la difficulté de mise en œuvre du réseau Solver sera encore plus élevée, et le seuil d'entrée pour faire fonctionner les Solvers sera également plus élevé.
Centré sur le réseau de liquidité on-chain : cette direction est spécialement dédiée à l'optimisation des problèmes de liquidité inter-chaînes, mais n'a pas résolu les problèmes de décentralisation des états on-chain d'autres chaînes. 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.
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. Ces projets nécessitent la gestion de processus inter-chaînes complexes, 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 les problèmes de liquidité est un enjeu très important, car dans le monde financier, la liquidité représente souvent tout. Si l'on peut construire une plateforme intégrant la liquidité, en particulier en rassemblant la liquidité fragmentée de l'ensemble de la chaîne, cela pourrait avoir un très grand potentiel, 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 la plus atomique. Au-dessus de ces solutions atomiques telles que les solutions inter-chaînes, les oracles et les pré-confirmations, 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 listées ci-dessus, 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, et c'est pourquoi, en matière d'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înes pour voir comment chacun d'eux aborde le problème de la fragmentation de la Liquidité depuis son propre point de départ.
Un certain projet a construit un service RaaS dans le domaine de la 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 fournir des composants tels que le Leverage Trading et la Yield Strategy, immédiatement opérationnels. Cela équivaut à un autre point de construction d'application, mais la liquidité finale est placée dans la couche de liquidité de ce projet. Cependant, il n'a pas encore révélé le fonctionnement sous-jacent.
Un autre projet a construit trois composants clés, à savoir la couche de compatibilité des Intent, la Validity et la couche de règlement universel. Les applications externes ou la couche d'intention peuvent publier des intentions à ce projet, puis sa couche de compatibilité des Intent peut transformer 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 soumettre le résultat final à la couche de règlement universel 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.
Il existe également 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. Sa mission principale est de fournir aux sociétés de trading professionnelles des outils de gestion des stocks efficaces et de se connecter facilement aux protocoles DeFi de base lors du règlement des transactions basées sur 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 encore plus sur le trading lui-même. Elle est actuellement encore en phase de développement.
Un certain projet 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.
Un autre projet est le marché de puissance de calcul ZK d'Ethereum, le coprocesseur ZK et les développeurs de Layer 2, l'équipe ayant 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 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, qui est courant dans les projets d'exécution parallèle récents. Ce projet L2 a intégré la communication inter-shard dans le protocole dès le début. Les messages inter-shard sont validés par le comité de validation de chaque shard en tant que transactions.
Son idée fondamentale est de construire une architecture de communication inter-fragment similaire à l'IBC, intégrée à une architecture Layer 2 par le biais de la fragmentation, ce qui permettrait de résoudre les problèmes de Liquidité et de décentralisation des états. Cependant, son idée centrale n'est pas raisonnable, car le problème de la décentralisation 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.
Ethereum est également en train de s'attaquer à ce problème de liquidité inter-chaînes. Actuellement, certains projets soutiennent d'abord 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 commun pour les opérations inter-chaînes entre L2 et les chaînes latérales, de normaliser les interfaces de commande et de règlement, et de réaliser une exécution inter-chaînes transparente. Le cœur de cette approche repose principalement sur un Filler, qui peut également être considéré comme le rôle de Solver dans l'abstraction de chaîne pour le paiement. Cette proposition est actuellement examinée par le groupe de travail Cake.
OP Stack, ERC-7683 et zkSharding sont tous des solutions internes d'Ethereum pour résoudre la fragmentation de la liquidité entre les Layer 2, traitant respectivement les niveaux d'architecture, de consensus et d'application. 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. Lorsque vous utilisez l'architecture OP Stack, des contrats inter-chaînes sont automatiquement déployés, et un superviseur existe pour contester afin d'éviter la transmission d'informations inter-chaînes fausses. Actuellement, certaines plateformes de trading majeures utilisent l'architecture OP Stack.
Parmi eux, le plus typique est Unichain. Unichain fonctionne principalement en se connectant au réseau Superchain.