TL ; Dr

• Aujourd’hui, l’expérience utilisateur cryptographique par défaut permet aux utilisateurs de toujours savoir avec quel réseau ils interagissent. Cependant, les utilisateurs d’Internet n’ont pas besoin de savoir avec quel fournisseur de cloud ils interagissent. Apporter cette approche aux blockchains est ce que nous appelons l’abstraction de la chaîne.
• Cet article présente le framework CAKE, c’est-à-dire les éléments clés d’abstraction de la chaîne. Il est composé de quatre couches : Applications, Autorisations, Résolution et Règlement, qui facilitent collectivement les opérations cross-chain transparentes pour les utilisateurs.
• La réalisation de l’abstraction de chaîne nécessite l’utilisation d’un ensemble complexe de technologies pour fournir une exécution fiable, rentable, sécurisée, rapide et privée.
• Nous définissons l’espace de compromis cross-chain dans l’abstraction de la chaîne comme un trilema et proposons six conceptions, qui offrent chacune des avantages uniques.
• Dans l’ordre de réussir le saut vers un avenir d’abstraction de chaîne, il est impératif que nous, en tant qu’industrie, définissions et adoptions une norme commune pour la messagerie entre les couches du CAKE. Un bon standard est la cerise sur le gâteau. 🎂

Introduction

En 2020, le réseau Ethereum est passé à une feuille de route centrée sur le rollup pour la mise à l’échelle. Quatre ans après cette décision, plus de 50 rollups (L2) sont déjà en production. Bien que rollups fournir une mise à l’échelle horizontale indispensable pour l’espace de bloc EVM, il a totalement ruiné l’expérience utilisateur.

Les utilisateurs ne doivent ni se soucier ni savoir avec quel cumul ils interagissent. Les utilisateurs de crypto sachant avec quel cumul (Optimism ou Base) ils interagissent équivaut à ce que les utilisateurs de Web2 sachent avec quel fournisseur de cloud (AWS ou GCP) ils interagissent. L’abstraction de la chaîne est une vision où l’information de la chaîne est abstraite loin de l’utilisateur. L’utilisateur ne connecte son portefeuille qu’à une dApp et signe pour l’opération prévue, les détails pour s’assurer que l’utilisateur a un solde correct sur la chaîne cible, puis l’exécution de l’opération prévue se passe en arrière-plan.

Au cours de cet article, nous observerons que l’abstraction en chaîne est un problème véritablement multidisciplinaire. Impliquant des interactions avec la couche d’application, la couche d’autorisation, la couche de solveur et la couche de règlement. Nous présentons le cadre CAKE (Chain 🎂 Abstraction Key Elements), puis approfondissons les compromis de conception des systèmes d’abstraction de chaîne.

Présentation du framework CAKE

Dans un monde abstrait en chaîne, un utilisateur se rend sur un site Web dApps, connecte son portefeuille, signe l’opération prévue et attend un règlement éventuel. Toute la complexité de l’acquisition des actifs requis dans la chaîne cible et le règlement final sont abstraits de l’utilisateur, se produisant dans les couches d’infrastructure du CAKE. Il y a trois couches d’infrastructure du CAKE :

1. Couche d’autorisation : l’utilisateur connecte son portefeuille à une dApp et demande le devis pour une intention d’utilisateur. Une intention est ce que l’utilisateur attend (c’est-à-dire la sortie) à la fin d’une transaction et non le chemin éventuel emprunté par la transaction. Il peut s’agir de transférer des USDT vers une adresse Tron ou de déposer des USDC dans une stratégie génératrice de rendement sur Arbitrum. Le portefeuille doit être capable à la fois de connaître les actifs des utilisateurs (c’est-à-dire l’état de lecture) et d’exécuter des transactions (c’est-à-dire l’état de mise à jour) sur les chaînes cibles.
2. Couche du solveur : la couche du solveur estime les frais et la vitesse d’exécution en fonction du solde et de l’intention initiaux de l’utilisateur. Ce processus, appelé résolution, est crucial dans un environnement cross-chain où les transactions deviennent asynchrones et les sous-transactions peuvent échouer pendant l’exécution. L’introduction de l’asynchronicité crée un trilemme cross-chain impliquant des frais, une vitesse d’exécution et une garantie d’exécution.
3. Couche de règlement : une fois que l’utilisateur a approuvé la transaction avec sa clé privée, la couche de règlement assure son exécution. Il s’agit de deux étapes : le pontage des actifs de l’utilisateur sur la chaîne cible, puis l’exécution de la transaction. Si le protocole utilise des solveurs sophistiqués pour certaines opérations, il peut apporter sa propre liquidité et exécuter l’opération pour le compte de l’utilisateur sans avoir besoin de pontage.

Pour obtenir l’abstraction de la chaîne, il faut combiner les trois couches d’infrastructure ci-dessus en un produit unifié. L’un des éléments clés de la combinaison de ces couches est la différence entre le transfert d’informations et le transfert de valeur. Le transfert d’informations entre les chaînes doit se faire sans perte et nécessite donc de s’appuyer sur les voies les plus sécurisées. Supposons qu’un utilisateur essaie de voter Oui lors d’un vote de gouvernance d’une chaîne à l’autre, il ne veut pas que son vote soit converti en un Peut-être. D’autre part, le transfert de valeur peut être lossal en fonction des préférences des utilisateurs. Un tiers sophistiqué peut être mis à profit pour offrir à l’utilisateur un transfert de valeur plus rapide, moins cher ou garanti. Notez que 95% de l’espace de bloc Ethereum (pondéré par les frais payés aux validateurs) est consommé pour transférer de la valeur.

Décisions de conception clés

Les trois couches ci-dessus présentent les décisions de conception clés qui doivent être prises par un FAC. Ils sont liés à qui contrôle le pouvoir sur l’exécution de l’intention, quelles informations doivent être révélées aux solveurs et quelles sont les voies de règlement disponibles pour les solveurs. Examinons chacun d’entre eux en détail.

Couche d’autorisation

La couche d’autorisation contient la clé privée de l’utilisateur et signe les messages en son nom, qui sont ensuite exécutés off-chain en tant que transactions. Un CAF support des schémas de signature et des charges utiles de transaction pour toutes les chaînes cibles qu’il souhaite prendre en support. Par exemple, un portefeuille prenant en charge le schéma de signature ECDSA et la norme de transaction EVM sera limité à Ethereum, ses L2 et ses chaînes latérales (par exemple, le portefeuille Metamask). D’autre part, un portefeuille prenant en charge à la fois EVM et SVM (Solana VM) pourra support les deux écosystèmes (par exemple, le portefeuille Phantom). Il est important de noter que le même moyen mnémotechnique peut être utilisé pour générer des portefeuilles sur les chaînes EVM et SVM.

Une seule transaction multi-chaînes se compose de plusieurs sous-transactions qui doivent être exécutées dans le bon ordre. Ces sous-transactions doivent être exécutées sur plusieurs chaînes, chacune avec ses propres frais et nonces variables dans le temps. La manière dont la coordination et le règlement de ces sous-transactions se déroulent est une décision de conception cruciale pour la couche d’autorisation.

1. Les portefeuilles EOA sont des logiciels de portefeuille qui s’exécutent sur les machines des utilisateurs et détiennent leurs clés privées. Il peut s’agir d’extensions basées sur un navigateur (telles que Metamask et Phantom), d’applications mobiles (telles que Coinbase Portefeuille) ou de matériel dédié (tel que Ledger). Les portefeuilles EOA exigent que l’utilisateur signe individuellement chaque sous-transaction, ce qui nécessite actuellement plusieurs clics. Ils exigent également que l’utilisateur conserve des soldes de frais sur la chaîne cible, ce qui introduit des frictions importantes dans le processus. Cependant, la friction des clics multiples peut être évitée à l’utilisateur en lui permettant de signer plusieurs sous-transactions en un seul clic.
2. Dans les portefeuilles d’abstraction de compte (AA), l’utilisateur a toujours accès à sa clé privée, mais il sépare le signataire de la charge utile de la transaction de l’exécuteur de la transaction. Permettre à des parties sophistiquées de regrouper et d’exécuter de manière atomique les transactions des utilisateurs (Avocado, Pimlico). Les portefeuilles AA exigent toujours que l’utilisateur signe individuellement chaque sous-transaction (actuellement via plusieurs clics), mais n’exigent pas la détention de soldes de frais sur chaque chaîne.
3. Les agents basés sur des stratégies détiennent la clé privée de l’utilisateur dans un environnement d’exécution distinct et génèrent des messages signés en son nom en fonction des stratégies utilisateur. Les bots Telegram, l’agrégateur Near Account ou les TEE SUAVE sont des portefeuilles basés sur des politiques, tandis qu’Entropy ou Capsule sont des extensions de portefeuille basées sur des politiques. L’utilisateur n’a qu’à signer une seule approbation et la signature ultérieure des sous-transactions et la gestion des frais peuvent être effectuées à la volée par ces agents.

Solver Layer

Une fois qu’un utilisateur a publié son intention, la couche de résolution implique de renvoyer des frais et une heure de confirmation à l’utilisateur. Ce problème est étroitement lié à la conception d’une enchère de flux d’ordres et a été écrit en détail ici. Un CAF peut soit tirer parti des chemins d’accès au protocole pour exécuter l’intention d’un utilisateur, soit tirer parti de tiers sophistiqués, alias solveurs, pour fournir une expérience utilisateur améliorée à l’utilisateur en compromettant certaines garanties de sécurité. Les deux décisions de conception suivantes surviennent lorsque nous intégrons les solveurs dans un cadre CAF et sont liées à l’information.

Une intention se compose de deux types de valeurs extractibles (EV) : EV_ordering et EV_signal. EV_ordering s’agit d’une valeur spécifique à la blockchain, généralement extraite par des entités qui exécutent les ordres des utilisateurs comme les constructeurs de blocs ou les validateurs. D’autre part, EV_signal représente la valeur accessible à toute entité qui observe le ordre avant qu’il ne soit officiellement enregistré sur la blockchain.

Les différentes intentions de l’utilisateur ont des distributions variables entre EV_ordering et EV_signal. Par exemple, l’intention d’échanger des pièces sur un DEX a généralement un EV_ordering élevé, mais un EV_signal faible. À l’inverse, une transaction de piratage entrante aura une composante de EV_signal plus élevée, car son exécution frontale renverra beaucoup plus de valeur que son exécution. Il est important de noter que EV_signal peuvent parfois être négatifs, comme dans le cas des transactions des teneurs de marché, où les entités exécutant ces ordres peuvent subir des pertes en raison d’une meilleure compréhension des conditions futures du marché par les teneurs de marché.

Lorsqu’une personne a la possibilité d’observer l’intention d’un utilisateur à l’avance, elle peut s’engager dans une course frontale, ce qui entraîne une fuite de valeur. De plus, la possibilité que les EV_signal soient négatives crée un environnement concurrentiel entre les solveurs, ce qui les amène à soumettre des offres plus basses et entraîne une perte de valeur supplémentaire (c’est-à-dire une sélection adverse). En fin de compte, les fuites ont un impact sur l’utilisateur en augmentant les frais ou en offrant des prix moins favorables. Notez que les frais peu élevés ou l’amélioration des prix sont les deux faces d’un même jeton et seront utilisés de manière interchangeable pendant le reste de l’article.

Partage d’informations

Il existe 3 méthodes pour partager des informations avec des solveurs :

1. Mempool public : l’intention de l’utilisateur est diffusée publiquement, soit dans un mempool public, soit dans une couche DA. Le premier solveur qui peut répondre à la demande exécute l’ordre et devient le gagnant. Ce système est très extractif, car les utilisateurs révèlent à la fois le EV_ordering et le EV_signal de leur ordre. Des exemples de ce type d’enchères incluent le mempool public d’Ethereum et divers ponts blockchain. Dans le cas des ponts, les utilisateurs doivent placer leurs actifs sous séquestre avant de les transférer vers la chaîne cible par mesure de précaution contre les attaques de grief. Cependant, ce processus expose involontairement leurs intentions publiquement.
2. Partage partiel : Une FAC peut choisir de limiter la valeur qu’elle révèle aux soumissionnaires en limitant l’information divulguée. Cependant, cette approche entraîne une perte directe de l’optimalité des prix et peut entraîner d’autres problèmes, tels que le spamming d’enchères.
3. Mempool privé : Les développements récents dans les MPC et les TEE ouvrent la possibilité de réaliser des mempools complètement privés. Aucune information n’est divulguée en dehors de l’environnement d’exécution, de sorte que les solveurs encodent leurs préférences, qui correspondent à chaque intention. Bien que les mempool privées capturent EV_ordering, elles ne peuvent pas capturer entièrement la valeur de EV_signal. Imaginez ce qui se passera si une transaction de piratage est envoyée au mempool. La première personne à voir cette ordre peut devancer la vente potentielle et capturer EV_signal. Dans un mempool privé, l’information n’est publiée qu’après la confirmation d’un blocage, et donc quiconque peut voir la transaction peut capturer le EV_signal. On peut imaginer des solveurs faisant tourner attestation nœuds pour attraper EV_signal de blocs neufs frappés par un TEE, transformant EV_signal capture en une course latence.

Liste des solveurs

Les FAC doivent également décider combien et quels enchérisseurs sont autorisés à participer à la vente aux enchères. De manière générale, les options sont les suivantes :

• Libre accès : Les barrières à l’entrée pour la capacité de participer sont aussi faibles que possible. Il s’agit d’un mempool public qui fait l’objet de fuites à la fois EV_signal et EV_ordering.
• Accès fermé : Il existe un certain contrôle sur la capacité d’exécuter un ordre, que ce soit par le biais d’une liste blanche, d’un système de réputation, de frais ou d’une vente aux enchères de sièges. Le mécanisme de contrôle d’accès doit s’assurer que les solveurs du système ne capturent pas EV_signal. Les exemples sont 1inch Auction, Cowswap Auctions et Uniswap X. La compétition pour gagner des commandes capture EV_ordering pour l’utilisateur tandis que le mécanisme de contrôle peut capturer les EV_signal pour le générateur de ordre (Portefeuille, dApps).
• Accès exclusif : L’accès exclusif est un cas particulier de l’enchère de solveurs assis où un seul solveur est sélectionné à chaque période. Étant donné qu’aucune information n’est divulguée à d’autres solveurs, il n’y a pas d’antisélection et de remise en avant. L’émetteur de flux d’ordres capture la valeur attendue de EV_signal et de EV_ordering, car il n’y a pas de concurrence, l’utilisateur ne peut obtenir que l’exécution et pas d’amélioration des prix. Quelques exemples de ces enchères sont les enchères Robinhood et DFlow.

Règlement Couche

Une fois qu’un portefeuille a signé un ensemble de transactions, celles-ci doivent être exécutées sur la blockchain. Les transactions inter-chaînes convertissent le processus de règlement de l’atome à l’asynchrone. Pendant que les transactions initiales sont exécutées et confirmées, l’état de la chaîne cible peut changer, ce qui peut leading à l’échec de la transaction. Cette sous-section étudiera les compromis entre le coût de la sûreté, le délai de confirmation et la garantie d’exécution.

Il est important de noter que l’exécution de la transaction prévue sur la chaîne cible dépend des mécanismes d’inclusion des transactions de la chaîne cible. Y compris la capacité de censurer une transaction et le mécanisme de frais de la chaîne cible, entre autres facteurs. Nous pensons que le choix de la chaîne cible est une décision pour la dApp et nous la considérerons au-delà du cadre de cet article.

Oracle inter-chaînes

Deux blockchains avec des états distincts et des mécanismes de consensus nécessitent un intermédiaire, tel qu’un Oracle, pour faciliter le transfert d’informations entre elles. Les oracles servent de relais pour l’information entre les chaînes. Il s’agit notamment de vérifier des situations telles qu’un utilisateur verrouille des fonds dans un compte séquestre pour un verrou et un mint bridge, ou confirme le solde de tokens d’un utilisateur sur la chaîne d’origine pour la participation au vote de gouvernance sur la chaîne cible.

Les oracles transfèrent des informations entre les chaînes à la vitesse de la chaîne la plus lente. Ceci est nécessaire pour gérer le risque de réorganisation, car Oracle doit attendre un consensus sur la chaîne d’origine. Considérons un scénario dans lequel un utilisateur souhaite bridge USDC de la chaîne d’origine à la chaîne cible. Pour ce faire, l’utilisateur bloque ses fonds dans un séquestre. Toutefois, si Oracle n’attend pas suffisamment de confirmations et procède à la mint des jetons pour l’utilisateur sur la chaîne cible, un problème peut survenir. Dans le cas d’une réorganisation, si l’utilisateur écrase sa transaction d’entiercement, l’Oracle aurait une double dépense.

Il existe deux types d’oracles :

1. Oracle hors protocole exige des validateurs tiers distincts de ceux qui exécutent le consensus pour transférer des informations entre les chaînes. Le besoin de validateurs supplémentaires augmente le coût d’exécution de l’Oracle. LayerZero, Wormhole, ChainLink et le réseau Axelar sont des exemples d’oracles hors protocole.
2. Un Oracle In-Protocol est profondément intégré dans l’algorithme de consensus d’un écosystème et utilise l’ensemble de validateurs exécutant le consensus pour transférer des informations. Cosmos dispose d’IBC pour les chaînes exécutant le SDK Cosmos, l’écosystème Polygon travaille sur AggLayer, tandis qu’Optimism travaille sur la Superchain. Chaque oracle utilise un espace de blocs dédié pour transférer des informations entre les chaînes d’un même écosystème.
3. Les séquenceurs partagés sont des entités hors protocole qui ont des droits de commande de transactions dans le protocole, c’est-à-dire qu’ils peuvent fournir un regroupement de transactions entre les chaînes. Bien qu’ils soient encore en cours de développement, les séquenceurs partagés n’ont pas besoin d’attendre certaines confirmations de bloc pour réduire le risque de réorganisation. Pour vraiment fournir une atomicité cross-chain, les séquenceurs partagés doivent être capables d’exécuter des transactions ultérieures conditionnées par le succès des transactions précédentes, les transformant en une chaîne de chaînes.

Jetons de pontage

Dans un monde multi-chaînes, les soldes de jetons d’utilisateur et de frais sont répartis sur tous les réseaux. Avant chaque opération cross-chain, l’utilisateur doit transférer des fonds de bridge de la chaîne d’origine à la chaîne cible. Actuellement, il y a 34 ponts actifs avec un TVL combiné de 7,7 milliards de dollars et un >volume href="https://defillama.com/bridges"< de 8,6 milliards de dollars au cours des 30 derniers jours.

Le bridging tokens est un cas de transfert de valeur. Cela crée une opportunité de faire appel à des tiers spécialisés qui excellent dans la gestion du capital et qui sont prêts à assumer le risque de réorganisation, réduisant ainsi le coût et le temps requis pour les transactions des utilisateurs.

Il existe 2 types de ponts :

1. Lock and Mint bridge : Un verrou et mint bridge vérifie les dépôts de tokens sur la chaîne d’origine et frappe des tokens sur la chaîne cible. Bien qu’un petit capital soit nécessaire pour démarrer un tel bridge, un investissement important est nécessaire pour le transfert sécurisé des informations de verrouillage entre les chaînes. Les failles de sécurité dans ces ponts ont entraîné la perte de milliards de dollars pour les détenteurs de jetons.
2. Ponts de liquidité : Les ponts de liquidité utilisent des pools de liquidité sur les chaînes d’origine et cible, ainsi qu’un algorithme pour déterminer les taux de conversion entre les jetons d’origine et cible. Bien que ces ponts aient des coûts initiaux plus élevés, ils nécessitent des garanties de sécurité plus faibles. En cas de faille de sécurité, seuls les fonds des pools de liquidité sont à risque.

Dans les deux types de ponts, il y a un coût de liquidité qui doit être payé par l’utilisateur. Dans les ponts Lock et Mint, le coût de liquidité est lors de l’échange du jeton wrappé au jeton souhaité (USDC.e à USDC) sur la chaîne cible, tandis que dans les ponts de liquidité, le coût de liquidité est lors de l’échange du jeton sur la chaîne d’origine au jeton sur la chaîne cible.

Trilemme inter-chaînes

Les 5 décisions de conception ci-dessus donnent hausse au trilemme cross-chain. Un CAF doit choisir 2 propriétés entre la garantie d’exécution, les frais peu élevés et la rapidité d’exécution.

1. Les chemins d’accès au protocole sont des chemins désignés pour le transfert d’informations entre les chaînes. Ces systèmes compte pour la réorganisation risquent de sacrifier la vitesse d’exécution, mais réduisent les coûts en éliminant le besoin d’un ensemble de validateurs supplémentaires ou de coûts de liquidité.
2. L’agrégation de solveurs collecte les citations de plusieurs solveurs afin d’identifier le chemin le moins cher et le plus rapide pour répondre à l’intention d’un utilisateur. Cependant, en raison de l’antisélection et de l’exécution frontale, les solveurs peuvent parfois ne pas satisfaire l’intention, ce qui entraîne une exécution réduite.
3. La compétition d’exécution sélectionne un solveur gagnant en organisant une course entre les solveurs pour exécuter une intention ou en choisissant un seul solveur exclusivement. Les deux approches entraînent des frais élevés pour l’utilisateur, car les solveurs se font concurrence pour l’exécution plutôt que pour l’amélioration des prix.

Les six morceaux de CAKE

Pour écrire cet article, nous avons étudié plus de 20 conceptions différentes d’équipes travaillant à la fois explicitement et implicitement sur l’abstraction de la chaîne. Dans cette section, nous discutons de six implémentations d’AC indépendantes qui, selon nous, présentent des gains d’efficacité et d’adéquation du produit au marché. Ces conceptions ont le potentiel de composer les unes avec les autres si elles sont bien construites.

L’un des principaux points à retenir de cet exercice est que nous avons besoin d’une norme commune pour exprimer les intentions cross-chain. Chacune des équipes travaille sur ses propres méthodes et protocoles d’encodage des intentions des utilisateurs. L’unification vers une norme améliorera la compréhension des utilisateurs du message qu’ils signent, facilitera la compréhension de ces intentions par les solveurs et les oracles et simplifiera l’intégration avec les portefeuilles.

Ponts oints de jetons

Bridge aligné sur l’écosystème

Concurrence sur les prix des solveurs

Messagerie contrôlée par portefeuille

Résolution de la vitesse de la compétition

Ventes aux enchères exclusives par lots

but

Transferts inter-chaînes bon marché

Appel de message inter-chaînes

Swaps inter-chaînes bon marché

Appel de message inter-chaînes

Transferts inter-chaînes rapides

Appel de message inter-chaînes

Exemples

CCTP, CCIP, xERC20

AggLayer, Superchain, IBC

Élastique, Cavalier, Uniswap X

Alfred, Avocat, Compte Proche

De l’autre côté, Orbiter

Na

portefeuille

quelconque

quelconque

Dépend de la mise en œuvre

AA ou basé sur des politiques

quelconque

quelconque

Informations partagées

public

public

Dépend de la mise en œuvre

Dépend de la mise en œuvre

Tout ou aucun

aucun

Liste de solveurs

Dépend de la mise en œuvre

Dépend de la mise en œuvre

Accès fermé

Dépend de la mise en œuvre

Dépend de la mise en œuvre

exclusif

oracle

Dans le protocole

Dans le protocole

Hors protocole

Hors protocole

Hors protocole

Hors protocole

Pontage de jetons

Brûler et mint

Serrure et mint

Dépend du solveur

Dépend du solveur

Liquidité bridge

Dépend de la mise en œuvre

Jeton Ponts oints

Il existe un cas particulier de verrouillage et de mint bridge qui ne paie pas le coût de liquidité également appelé burn and mint bridge (par exemple. USDC CCTP). L’équipe de jetons oint une adresse de jeton canonique sur chaque chaîne tandis que le bridge a le pouvoir de miner le jeton, c’est-à-dire le jeton dont l’utilisateur a besoin.

Si vous plissez les yeux assez fort, un burn and mint bridge est similaire à un transfert de cross-chain à la vitesse d’un nombre suffisant de confirmations de blocage. xERC20 est l’une de ces normes pour oindre les jetons canoniques et leurs ponts autorisés sur les chaînes cibles. Un bridge oint de jeton est un exemple de chemin dans le protocole, c’est-à-dire qu’il compromet la vitesse pour la garantie d’exécution et les frais faibles, par exemple CCTP prend 20 minutes pour exécuter un transfert.

Pont aligné sur l’écosystème

Un bridge aligné sur l’écosystème permet le transfert de messages arbitraires entre des chaînes au sein d’un même écosystème. Il entre dans la catégorie des chemins d’accès au protocole, donnant la priorité à la garantie d’exécution et aux faibles frais plutôt qu’à la vitesse. Les exemples incluent Cosmos IBC, Polygon AggLayer et Optimism Superchain.

Il y a trois ans, l’écosystème Cosmos était confronté à des défis similaires à ceux auxquels Ethereum est confronté aujourd’hui. La liquidité était fragmentée entre les chaînes, chaque chaîne avait son propre jeton de frais et la gestion des comptes multi-chaînes était fastidieuse. L’écosystème Cosmos a résolu ces problèmes en mettant en œuvre des ponts de transmission de messages dans le protocole via IBC, ce qui a permis d’obtenir des comptes multi-chaînes et des transferts cross-chain transparents.

L’écosystème cosmos comprend des chaînes indépendantes ayant une sécurité souveraine et une finalité rapide, ce qui rend le chemin dans le protocole pour la messagerie cross-chain très rapide. D’un autre côté, l’écosystème de cumul dépend de l’expiration de la période de défi (Optimistic Rollups) ou de la validation de zk-proofs (Validity Rollups) pour la finalité. Les chemins d’accès au protocole pour la transmission de messages entre les écosystèmes seront lents en raison de ces contraintes de finalité.

Concours de prix du solveur

Une concurrence de prix de solveur implique le partage d’informations ordre avec tous les solveurs. Les solveurs visent à incorporer la valeur attendue (EV) générée par l’intention de l’ordre et à la fournir aux utilisateurs. La sélection du solveur gagnant dans le système est basée sur la maximisation de l’amélioration du prix à l’utilisateur. Cependant, cette conception comporte un risque de non-exécution et nécessite des mécanismes supplémentaires pour assurer la fiabilité de l’inclusion des ordres. Des exemples de tels mécanismes incluent Uniswap X, Bungee et Jumper.

Portefeuille les messages coordonnés

Portefeuille la messagerie coordonnée utilisent les fonctionnalités fournies par les portefeuilles AA ou basés sur des politiques pour offrir une expérience cross-chain compatible avec n’importe quel type d’intention. Il sert d’agrégateur d’autorité de certification ultime, redirigeant les intentions de l’utilisateur entre différentes conceptions d’autorité de certification pour répondre à des intentions spécifiques. Les exemples incluent le portefeuille Avocado, l’agrégateur de comptes Near et le portefeuille Metamask.

Notez qu’au cours de la dernière décennie, l’écosystème crypto a appris que la relation entre un utilisateur et son portefeuille est très délicate. Personnellement, je ressens une peur mortelle chaque fois que je pense à migrer mon moyen mnémotechnique de Metamask vers un autre portefeuille. C’est aussi la raison pour laquelle, même après 2,5 ans et le soutien de Vitalik Buterin lui-même, EIP-4337 a obtenu . Bien que les nouvelles versions des protocoles de portefeuille puissent offrir à l’utilisateur un meilleur prix (abstraction de compte) ou une meilleure facilité d’utilisation (portefeuilles basés sur des règles), la migration de l’utilisateur à partir de ses portefeuilles actuels est une tâche ardue.

Solver Speed Competition

La compétition de vitesse Solver permet aux utilisateurs d’exprimer leurs intentions pour des transitions de cross-chain spécifiques pour des garanties d’exécution élevées. Il n’aide pas les utilisateurs à minimiser les frais, mais offre plutôt un canal fiable pour inclure des transactions complexes. Le premier solveur à exécuter l’intention en fonction des frais de création de blocs ou de la vitesse d’inclusion remporte l’intention.

La conception vise à atteindre un taux d’inclusion élevé en maximisant l’EV capturé par les solveurs. Cependant, cela se fait au détriment de la centralisation, car il repose sur une gestion sophistiquée du capital sur le réseau principal Ethereum ou une exécution à faible latence sur les L2.

Enchères par lots exclusives

Une enchère par lots exclusive organise une enchère pour les droits exclusifs d’exécution de tous les flux de ordre dans une fenêtre de temps vers un seul solveur. Étant donné que les autres solveurs ne peuvent pas voir les ordres, ils placent l’offre en fonction de la volatilité prévue du marché et de leur qualité d’exécution moyenne. Les enchères par lots exclusives dépendent d’un prix de backstop dans l’ordre pour assurer de bons prix aux utilisateurs et ne peuvent donc pas être utilisées pour améliorer les prix. L’envoi de tout le flux d’ordres à un seul soumissionnaire élimine les fuites d’informations et améliore les garanties d’exécution.

Conclusion

Les cadres d’abstraction de la chaîne (CAF) promettent d’offrir aux utilisateurs une interaction cross-chain transparente. Dans cet article, nous avons étudié les conceptions en production et en développement par plusieurs équipes qui tentent explicitement ou implicitement de résoudre le problème de l’abstraction de la chaîne. Nous pensons que ce sera l’année des FAC et nous nous attendons à ce qu’une concurrence importante se produise entre les différentes conceptions et leurs mises en œuvre au cours des 6 à 12 prochains mois.

Transfert de valeur

Transfert d’informations

Chemins d’accès au protocole

Bridge oint par jeton

Bridge aligné sur l’écosystème

Agrégation de solveurs

Concurrence sur les prix des solveurs

Messagerie coordonnée par portefeuille

Concours d’exécution

Résolution de la vitesse de la compétition

Ventes aux enchères exclusives par lots

Les transferts de valeur inter-chaînes seront acheminés par le biais d’une combinaison de ponts oints par des jetons pour des frais peu élevés et de concours de vitesse ou de prix de solveur pour la rapidité et l’exécution. Tandis que les transferts d’informations seront acheminés via une combinaison de ponts de messages alignés sur l’écosystème, qui viseront à minimiser les coûts pour les utilisateurs, et vers des plates-formes contrôlées par portefeuille qui maximiseront la vitesse. Les mises en œuvre finales se regrouperont autour de ces six conceptions distinctes, car chacune répond à des besoins indépendants et bénéficie des gains d’efficacité existants dans différents coins de la matrice de compromis.

L’un des principaux points à retenir de cet exercice est que nous avons besoin d’une norme commune pour exprimer les intentions cross-chain. Plusieurs équipes travaillent sur leurs protocoles individuels pour l’encodage des intentions des utilisateurs, ce qui entraîne des doublons. L’unification vers une norme améliorera la compréhension de l’utilisateur du message qu’il signe, facilitera le travail des solveurs et des oracles avec les intentions et simplifiera l’intégration avec les portefeuilles.

Gate Learn, et ils la traiteront rapidement.

Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.

Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.