Étude sur le problème de la liquidité fragmentée à l'ère du Layer 2
Avec le passage d'Ethereum à 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 des intérêts différents 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 de ces blockchains, entraînant de nombreux projets à voir leur prix s'effondrer dès le TGE.
Grâce à l'OP Stack, une plateforme d'échange a lancé sa propre Base Layer 2, une autre plateforme a publié Ink; grâce à la technologie ZK, une plateforme d'échange a lancé XLayer; une entreprise technologique a publié Soneium, une application de communication a lancé Kaia, etc. Aujourd'hui, le financement 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 l'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 permettre l'interopérabilité, il leur est difficile de construire des applications et d'atteindre un consensus sur la même chaîne en raison du grand nombre d'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 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 compensation, le CrossChain natif, 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.
La couche d'application 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 frontale sans nécessairement comprendre le mécanisme de conversion de liquidité sous-jacent.
La couche d'autorisation se situe en dessous de la couche d'application, les utilisateurs se connectent à leur portefeuille à l'application décentralisée (dApp) et demandent un devis pour satisfaire leur intention de transaction. Ici, "intention" fait référence au résultat final de la transaction que l'utilisateur espère, et non au chemin d'exécution spécifique de la transaction.
La gestion des comptes et l'abstraction nécessitent, en raison de l'environnement multichaîne, un système de gestion des comptes et d'abstraction adapté aux différentes chaînes pour maintenir les structures de comptes uniques de chaque chaîne. Une plateforme est un projet représentatif dans ce domaine, ayant construit un système de comptes fiable, sans avoir besoin d'établir un consensus entre les chaînes, mais uniquement par des engagements de confiance entre les systèmes de comptes existants. Cette plateforme réalise la gestion abstraite en générant des portefeuilles de comptes multichaînes pour les utilisateurs, optimisant ainsi considérablement l'expérience utilisateur et réduisant la fragmentation de l'UX. Cependant, la liquidité est principalement intégrée aux chaînes publiques existantes.
Le Solver est responsable de la réception et de la mise en œuvre des intentions de transaction des utilisateurs. Le rôle de Solver est ici en concurrence pour offrir une meilleure expérience utilisateur, y compris des temps de transaction plus rapides et des vitesses d'exécution. Sur cette base, des projets basés sur l'intention ont été construits, proposant diverses solutions pilotées par l'intention. Des dérivés de ce type d'intention, tels que le composant Predicate, peuvent réaliser les intentions des utilisateurs sous des règles spécifiques.
La couche de règlement est la couche intermédiaire utilisée par la couche de résolution pour réaliser l'intention de l'utilisateur. Les composants essentiels des solutions de Liquidité et de dispersion des états comprennent :
Oracles : utilisés pour obtenir des informations sur l'état d'autres chaînes.
Pont inter-chaînes : responsable de la transmission des informations et de la liquidité entre les chaînes.
Confirmation anticipée du plan : réduire le temps de confirmation inter-chaînes.
Disponibilité des données : fournir l'accessibilité des données.
De plus, il est nécessaire de prendre en compte la liquidité entre les chaînes, la finalité, le mécanisme de preuve Layer 2, etc., afin d'assurer le bon fonctionnement de l'ensemble du système multichaîne.
Actuellement, il existe plusieurs solutions sur le marché pour résoudre la liquidité prise les gens pour des idiots. Après avoir examiné un grand nombre de solutions, nous avons constaté qu'il existe principalement plusieurs manières de le faire :
Axé sur RaaS : similaire à des solutions Rollup comme OP Stack, en intégrant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour aider à partager la liquidité et l'é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 destinée à Layer 2 et n'est pas universelle.
Centré sur le compte : construire un portefeuille de compte à l'échelle de 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 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 essentiellement la liquidité et la dispersion des états.
Centrées sur le réseau d'intention hors chaîne : c'est-à-dire le Solver Network, le cœur est que les utilisateurs envoient des intentions au réseau Solver, ce rôle de Solver consiste à concurrencer les offres, fournissant le meilleur temps d'exécution et le prix de transaction. Ces Solvers peuvent être des agents AI, des échanges, des teneurs de marché ou même le protocole d'intégration lui-même. Bien que l'intention puisse théoriquement réaliser des opérations inter-chaînes complexes de n'importe quelle difficulté, sa mise en œuvre nécessite un nombre suffisant de Solvers liquidités 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 méthodes telles que la preuve de fraude sont introduites, 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é en chaîne : 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 d'état en chaîne. Son cœur est de construire une couche de liquidité, sur laquelle des applications sont construites, afin de partager la liquidité de l'ensemble de la chaîne.
Centré sur les applications en chaîne : Ce type d'application construit des applications à haute liquidité en intégrant de grands teneurs de marché ou des applications tierces. Ces projets nécessitent la gestion de processus inter-chaînes complexes, ce qui impose des exigences très élevées aux développeurs, rendant ainsi ces projets très vulnérables aux attaques de hackers.
Résoudre le problème de la Liquidité est une proposition 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 intégrant la Liquidité fragmentée de toute la chaîne, cela aura un potentiel énorme, et nous avons également examiné de nombreuses solutions différentes.
Les différentes solutions d'abstraction ou de liquidité que nous avons énumérées ci-dessus, construites dans différentes directions, correspondent à différents niveaux de ce système, que l'on peut comprendre comme une relation en amont et en aval. Cependant, ces solutions ne sont toujours pas des solutions atomiques, et le problème global de la liquidité en morceaux 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 émergé. Mais en fin de compte, 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.
Un certain projet a construit un service RaaS dans le domaine de la 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 prêts à l'emploi comme le Trading à effet de levier et les Stratégies de rendement. 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é révélé. Ce projet a déjà levé 6 millions de dollars lors de son tour de financement par des semences.
Un réseau a construit trois composants clés, à savoir la couche compatible avec Intent, la Validité et la couche de règlement général.
Les applications externes ou la couche d'intention peuvent publier des intentions à ce réseau, puis la couche de compatibilité des intentions du réseau peut transformer les intentions externes en un format reconnaissable par le Solver de protocole, le format normalisé utilisé étant le langage Validity. Les nœuds de ce réseau 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 de financement lors d'un tour de seed.
Une application décentralisée peut réaliser une découverte de 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 essentiels lors de la liquidation des transactions selon l'intention d'utilisation. Parallèlement, cette application 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. Elle est encore en phase de développement et a annoncé en juillet avoir levé 1,2 million de dollars lors d'un tour de financement Pre-seed.
Un certain projet est basé sur le protocole de consensus Comet BFT. La communication inter-chaînes utilisée 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 déjà effectué quatre tours de financement.
Une certaine fondation est un développeur de marché de puissance de calcul ZK d'Ethereum, de coprocesseurs ZK et de Layer 2, 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 Ethereum, exécuter le traitement des transactions en parallèle par le biais de partitions et générer des ZKP, tandis que la partition principale vérifie les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. La partition principale gère également la distribution des validateurs et des comptes dans les partitions 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. La L2 de cette fondation a intégré la communication inter-partition dans le protocole dès le début.
L'idée de base est de construire une architecture de communication inter-shards intégrée, similaire à l'IBC, à travers une architecture Layer 2 par découpage. Cela 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 la dispersion de la liquidité vise à résoudre est un problème multi-chaînes. Ce qui est construit est un unique Layer 2, ce qui signifie que pour résoudre ce problème, toutes les chaînes doivent devenir un shard de ZK-sharding, ce qui est difficile à réaliser.
Ethereum s'attaque également à ce problème de liquidité inter-chaînes. Actuellement, un Layer 2 et un DEX soutiennent d'abord un certain standard, qui utilise également une méthode inter-chaînes basée sur l'Intent. L'objectif principal est d'établir un standard commun pour les opérations inter-chaînes entre L2 et les sidechains, de normaliser les interfaces de commande et de règlement, et de réaliser une exécution inter-chaînes sans faille. Le cœur de cette approche est qu'un Filler peut également être considéré comme un rôle de Solver dans l'abstraction de chaîne pour le paiement. Cette proposition est construite conjointement par un DEX et un certain projet et est actuellement en cours d'examen par le groupe de travail.
Certains Stack, tout comme les normes mentionnées et zkSharding, sont des solutions internes à Ethereum pour la fragmentation de la liquidité entre les Layer 2, résolvant respectivement les problèmes au niveau de l'architecture, du consensus et de l'application. Certains Stack conçoivent une solution complète multi-Layer 2 pour résoudre une fois pour toutes les problèmes de transmission d'informations et de décentralisation des Séquenceurs. Lorsque vous utilisez cette architecture Stack, des contrats inter-chaînes seront automatiquement déployés, et il y aura un Superviseur pour contester afin d'éviter la transmission de fausses informations inter-chaînes. Actuellement, plusieurs projets connus utilisent cette architecture Stack.
Parmi eux, la chaîne la plus typique est une certaine chaîne. Cette chaîne résout principalement le problème de la fragmentation de la liquidité inter-chaînes grâce à son intégration avec le réseau Superchain. Ce paramètre facilite le mouvement sans couture de la liquidité en offrant les fonctionnalités suivantes:
Pont inter-chaînes basé sur l'intention : ce pont prend en charge un transfert de liquidité rapide et fiable entre les blockchains, permettant aux utilisateurs de définir leurs intentions, ce qui aide le système à choisir automatiquement le meilleur chemin pour le transfert de liquidité. Cette approche abstrait la complexité pour les utilisateurs, rendant les transactions inter-chaînes plus fluides et rapides.
Réseau de validation : Ce réseau d'opérateurs de nœuds décentralisés valide les transactions inter-chaînes, offrant une finalité économique plus rapide. Une finalité plus rapide est essentielle pour assurer un règlement efficace des transactions inter-chaînes, minimisant ainsi le risque de fragmentation de la liquidité dû aux règlements retardés.
Flashblocks et construction de blocs vérifiables : en utilisant Flashblocks, cette chaîne a considérablement réduit le temps de bloc, amélioré l'efficacité des fournisseurs de liquidité et réalisé un marché cross-chain plus synchronisé. Flashblocks aide à garantir que la liquidité est toujours disponible et à réduire les impacts négatifs causés par les retards de confirmation des blocs, ce qui peut entraîner une fragmentation de la liquidité.
Exploration des problèmes de fragmentation de la liquidité et des solutions dans l'ère Layer 2
Étude sur le problème de la liquidité fragmentée à l'ère du Layer 2
Avec le passage d'Ethereum à 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 des intérêts différents 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 de ces blockchains, entraînant de nombreux projets à voir leur prix s'effondrer dès le TGE.
Grâce à l'OP Stack, une plateforme d'échange a lancé sa propre Base Layer 2, une autre plateforme a publié Ink; grâce à la technologie ZK, une plateforme d'échange a lancé XLayer; une entreprise technologique a publié Soneium, une application de communication a lancé Kaia, etc. Aujourd'hui, le financement 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 l'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 permettre l'interopérabilité, il leur est difficile de construire des applications et d'atteindre un consensus sur la même chaîne en raison du grand nombre d'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 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 compensation, le CrossChain natif, 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.
La couche d'application 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 frontale sans nécessairement comprendre le mécanisme de conversion de liquidité sous-jacent.
La couche d'autorisation se situe en dessous de la couche d'application, les utilisateurs se connectent à leur portefeuille à l'application décentralisée (dApp) et demandent un devis pour satisfaire leur intention de transaction. Ici, "intention" fait référence au résultat final de la transaction que l'utilisateur espère, et non au chemin d'exécution spécifique de la transaction.
La gestion des comptes et l'abstraction nécessitent, en raison de l'environnement multichaîne, un système de gestion des comptes et d'abstraction adapté aux différentes chaînes pour maintenir les structures de comptes uniques de chaque chaîne. Une plateforme est un projet représentatif dans ce domaine, ayant construit un système de comptes fiable, sans avoir besoin d'établir un consensus entre les chaînes, mais uniquement par des engagements de confiance entre les systèmes de comptes existants. Cette plateforme réalise la gestion abstraite en générant des portefeuilles de comptes multichaînes pour les utilisateurs, optimisant ainsi considérablement l'expérience utilisateur et réduisant la fragmentation de l'UX. Cependant, la liquidité est principalement intégrée aux chaînes publiques existantes.
Le Solver est responsable de la réception et de la mise en œuvre des intentions de transaction des utilisateurs. Le rôle de Solver est ici en concurrence pour offrir une meilleure expérience utilisateur, y compris des temps de transaction plus rapides et des vitesses d'exécution. Sur cette base, des projets basés sur l'intention ont été construits, proposant diverses solutions pilotées par l'intention. Des dérivés de ce type d'intention, tels que le composant Predicate, peuvent réaliser les intentions des utilisateurs sous des règles spécifiques.
La couche de règlement est la couche intermédiaire utilisée par la couche de résolution pour réaliser l'intention de l'utilisateur. Les composants essentiels des solutions de Liquidité et de dispersion des états comprennent :
De plus, il est nécessaire de prendre en compte la liquidité entre les chaînes, la finalité, le mécanisme de preuve Layer 2, etc., afin d'assurer le bon fonctionnement de l'ensemble du système multichaîne.
Actuellement, il existe plusieurs solutions sur le marché pour résoudre la liquidité prise les gens pour des idiots. Après avoir examiné un grand nombre de solutions, nous avons constaté qu'il existe principalement plusieurs manières de le faire :
Axé sur RaaS : similaire à des solutions Rollup comme OP Stack, en intégrant des ordonnanceurs partagés spécifiques et des ponts inter-chaînes pour aider à partager la liquidité et l'é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 destinée à Layer 2 et n'est pas universelle.
Centré sur le compte : construire un portefeuille de compte à l'échelle de 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 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 essentiellement la liquidité et la dispersion des états.
Centrées sur le réseau d'intention hors chaîne : c'est-à-dire le Solver Network, le cœur est que les utilisateurs envoient des intentions au réseau Solver, ce rôle de Solver consiste à concurrencer les offres, fournissant le meilleur temps d'exécution et le prix de transaction. Ces Solvers peuvent être des agents AI, des échanges, des teneurs de marché ou même le protocole d'intégration lui-même. Bien que l'intention puisse théoriquement réaliser des opérations inter-chaînes complexes de n'importe quelle difficulté, sa mise en œuvre nécessite un nombre suffisant de Solvers liquidités 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 méthodes telles que la preuve de fraude sont introduites, 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é en chaîne : 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 d'état en chaîne. Son cœur est de construire une couche de liquidité, sur laquelle des applications sont construites, afin de partager la liquidité de l'ensemble de la chaîne.
Centré sur les applications en chaîne : Ce type d'application construit des applications à haute liquidité en intégrant de grands teneurs de marché ou des applications tierces. Ces projets nécessitent la gestion de processus inter-chaînes complexes, ce qui impose des exigences très élevées aux développeurs, rendant ainsi ces projets très vulnérables aux attaques de hackers.
Résoudre le problème de la Liquidité est une proposition 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 intégrant la Liquidité fragmentée de toute la chaîne, cela aura un potentiel énorme, et nous avons également examiné de nombreuses solutions différentes.
Les différentes solutions d'abstraction ou de liquidité que nous avons énumérées ci-dessus, construites dans différentes directions, correspondent à différents niveaux de ce système, que l'on peut comprendre comme une relation en amont et en aval. Cependant, ces solutions ne sont toujours pas des solutions atomiques, et le problème global de la liquidité en morceaux 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 émergé. Mais en fin de compte, 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.
Un certain projet a construit un service RaaS dans le domaine de la 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 prêts à l'emploi comme le Trading à effet de levier et les Stratégies de rendement. 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é révélé. Ce projet a déjà levé 6 millions de dollars lors de son tour de financement par des semences.
Un réseau a construit trois composants clés, à savoir la couche compatible avec Intent, la Validité et la couche de règlement général.
Les applications externes ou la couche d'intention peuvent publier des intentions à ce réseau, puis la couche de compatibilité des intentions du réseau peut transformer les intentions externes en un format reconnaissable par le Solver de protocole, le format normalisé utilisé étant le langage Validity. Les nœuds de ce réseau 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 de financement lors d'un tour de seed.
Une application décentralisée peut réaliser une découverte de 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 essentiels lors de la liquidation des transactions selon l'intention d'utilisation. Parallèlement, cette application 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. Elle est encore en phase de développement et a annoncé en juillet avoir levé 1,2 million de dollars lors d'un tour de financement Pre-seed.
Un certain projet est basé sur le protocole de consensus Comet BFT. La communication inter-chaînes utilisée 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 déjà effectué quatre tours de financement.
Une certaine fondation est un développeur de marché de puissance de calcul ZK d'Ethereum, de coprocesseurs ZK et de Layer 2, 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 Ethereum, exécuter le traitement des transactions en parallèle par le biais de partitions et générer des ZKP, tandis que la partition principale vérifie les données, communique avec Ethereum et synchronise l'état du réseau entre tous les validateurs. La partition principale gère également la distribution des validateurs et des comptes dans les partitions 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. La L2 de cette fondation a intégré la communication inter-partition dans le protocole dès le début.
L'idée de base est de construire une architecture de communication inter-shards intégrée, similaire à l'IBC, à travers une architecture Layer 2 par découpage. Cela 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 la dispersion de la liquidité vise à résoudre est un problème multi-chaînes. Ce qui est construit est un unique Layer 2, ce qui signifie que pour résoudre ce problème, toutes les chaînes doivent devenir un shard de ZK-sharding, ce qui est difficile à réaliser.
Ethereum s'attaque également à ce problème de liquidité inter-chaînes. Actuellement, un Layer 2 et un DEX soutiennent d'abord un certain standard, qui utilise également une méthode inter-chaînes basée sur l'Intent. L'objectif principal est d'établir un standard commun pour les opérations inter-chaînes entre L2 et les sidechains, de normaliser les interfaces de commande et de règlement, et de réaliser une exécution inter-chaînes sans faille. Le cœur de cette approche est qu'un Filler peut également être considéré comme un rôle de Solver dans l'abstraction de chaîne pour le paiement. Cette proposition est construite conjointement par un DEX et un certain projet et est actuellement en cours d'examen par le groupe de travail.
Certains Stack, tout comme les normes mentionnées et zkSharding, sont des solutions internes à Ethereum pour la fragmentation de la liquidité entre les Layer 2, résolvant respectivement les problèmes au niveau de l'architecture, du consensus et de l'application. Certains Stack conçoivent une solution complète multi-Layer 2 pour résoudre une fois pour toutes les problèmes de transmission d'informations et de décentralisation des Séquenceurs. Lorsque vous utilisez cette architecture Stack, des contrats inter-chaînes seront automatiquement déployés, et il y aura un Superviseur pour contester afin d'éviter la transmission de fausses informations inter-chaînes. Actuellement, plusieurs projets connus utilisent cette architecture Stack.
Parmi eux, la chaîne la plus typique est une certaine chaîne. Cette chaîne résout principalement le problème de la fragmentation de la liquidité inter-chaînes grâce à son intégration avec le réseau Superchain. Ce paramètre facilite le mouvement sans couture de la liquidité en offrant les fonctionnalités suivantes:
Pont inter-chaînes basé sur l'intention : ce pont prend en charge un transfert de liquidité rapide et fiable entre les blockchains, permettant aux utilisateurs de définir leurs intentions, ce qui aide le système à choisir automatiquement le meilleur chemin pour le transfert de liquidité. Cette approche abstrait la complexité pour les utilisateurs, rendant les transactions inter-chaînes plus fluides et rapides.
Réseau de validation : Ce réseau d'opérateurs de nœuds décentralisés valide les transactions inter-chaînes, offrant une finalité économique plus rapide. Une finalité plus rapide est essentielle pour assurer un règlement efficace des transactions inter-chaînes, minimisant ainsi le risque de fragmentation de la liquidité dû aux règlements retardés.
Flashblocks et construction de blocs vérifiables : en utilisant Flashblocks, cette chaîne a considérablement réduit le temps de bloc, amélioré l'efficacité des fournisseurs de liquidité et réalisé un marché cross-chain plus synchronisé. Flashblocks aide à garantir que la liquidité est toujours disponible et à réduire les impacts négatifs causés par les retards de confirmation des blocs, ce qui peut entraîner une fragmentation de la liquidité.
![Layer2时代下，Liquidité prendre les gens pour des idiots](