Un diagramme en chandeliers de gâteau pour vous aider à comprendre rapidement les éléments clés de l'abstraction de chaîne
TechFlow SélectionTechFlow Sélection
Un diagramme en chandeliers de gâteau pour vous aider à comprendre rapidement les éléments clés de l'abstraction de chaîne
Cet article présente le cadre CAKE (Chain Abstraction Key Elements).
Dédié à des analyses Web3 approfondiesAuteur : Favorite Mirror Reads Archive
Traduction : TechFlow
Résumé des points clés
-
L'expérience utilisateur par défaut actuelle en matière de cryptographie suppose que l'utilisateur sait toujours avec quel réseau il interagit. Pourtant, les utilisateurs du web n'ont pas besoin de savoir sur quel fournisseur cloud ils opèrent. Introduire cette approche dans le domaine des blockchains est ce que nous appelons l’abstraction des chaînes (Chain Abstraction).
-
Cet article présente le cadre CAKE (Éléments Clés de l’Abstraction des Chaînes). Ce cadre repose sur quatre composantes : couche applicative, couche d’autorisation, couche de résolution (solver) et couche de règlement, visant à offrir aux utilisateurs une expérience fluide pour les opérations inter-chaînes.
-
La mise en œuvre de l’abstraction des chaînes nécessite un ensemble complexe de technologies garantissant fiabilité, efficacité coûts, sécurité, rapidité et confidentialité du processus d’exécution.
-
Nous définissons les compromis liés à l’interchaîne dans l’abstraction des chaînes comme un dilemme à trois composantes, et proposons six modèles de conception, chacun ayant ses avantages spécifiques.
-
Pour réussir le passage vers un futur fondé sur l’abstraction des chaînes, notre secteur doit définir et adopter une norme commune pour la transmission d’informations entre les couches du modèle CAKE. Une bonne norme fera toute la différence.
Introduction
En 2020, le réseau Ethereum a amorcé sa transition vers une feuille de route d’évolutivité centrée sur les rollups. Quatre ans plus tard, plus de 50 chaînes de niveau 2 (L2) basées sur rollup sont désormais opérationnelles. Bien que ces solutions apportent l’évolutivité horizontale souhaitée, elles ont gravement détérioré l’expérience utilisateur.
Les utilisateurs ne devraient pas avoir à se préoccuper ni même savoir avec quel rollup ils interagissent. Le fait qu’un utilisateur de cryptomonnaies sache qu’il utilise Optimism ou Base équivaut à ce qu’un utilisateur Web2 sache qu’il utilise AWS ou GCP. La vision de l’abstraction des chaînes (Chain Abstraction) est de dissimuler cette information aux yeux de l’utilisateur. L’utilisateur connecte simplement son portefeuille à une dApp, signe l’action souhaitée, tandis que tous les détails — garantir un solde suffisant sur la chaîne cible et exécuter l’opération — sont gérés en arrière-plan.
Dans cet article, nous montrons que l’abstraction des chaînes constitue un problème véritablement pluridisciplinaire, impliquant l’interaction entre la couche applicative, la couche d’autorisation, la couche de résolution (Solver) et la couche de règlement. Nous présentons le cadre CAKE (Éléments Clés de l’Abstraction des Chaînes) et examinons en détail les compromis inhérents à la conception d’un système d’abstraction des chaînes.
Présentation du cadre CAKE
Dans un monde où l’abstraction des chaînes est effective, l’utilisateur accède au site d’une dApp, connecte son portefeuille, signe une intention, puis attend le règlement final. Toutes les opérations complexes sont traitées au niveau de l’infrastructure CAKE. Les trois couches d’infrastructure CAKE sont :
-
Couche d’autorisation : l’utilisateur connecte son portefeuille à la dApp et demande un devis pour son intention. Une intention désigne le résultat escompté par l’utilisateur à la fin de la transaction, et non le chemin de transaction. Par exemple, transférer des USDT vers une adresse Tron ou déposer des USDC dans une stratégie générant des rendements sur Arbitrum. Le portefeuille doit pouvoir lire les actifs de l’utilisateur (lecture d’état) et exécuter des transactions sur la chaîne cible (mise à jour d’état).
-
Couche de résolution (Solver) : cette couche estime les frais et la vitesse d’exécution en fonction du solde initial et de l’intention de l’utilisateur. Dans un contexte inter-chaînes, ce processus est appelé « résolution » et est crucial car les transactions sont asynchrones, et certaines sous-transactions peuvent échouer pendant l’exécution. Ce caractère asynchrone introduit un dilemme à trois composantes : frais, rapidité d’exécution et garantie d’exécution.
-
Couche de règlement : une fois que l’utilisateur a approuvé la transaction via sa clé privée, cette couche assure son exécution. Elle comprend deux étapes : pontage des actifs de l’utilisateur vers la chaîne cible, puis exécution de la transaction. Si le protocole utilise un solver sophistiqué pour certaines opérations, il peut fournir sa propre liquidité et agir au nom de l’utilisateur sans recourir au pontage.
Réaliser l’abstraction des chaînes consiste à intégrer ces trois couches d’infrastructure en un seul produit unifié. Un point clé de cette intégration réside dans la distinction entre transmission d’information et transmission de valeur. La transmission d’information entre chaînes doit être sans perte, ce qui exige d’emprunter le chemin le plus sécurisé possible. Par exemple, si un utilisateur vote « pour » lors d’un vote de gouvernance sur une autre chaîne, il ne souhaite pas que son vote soit transformé en « peut-être ». En revanche, la transmission de valeur peut comporter une perte, selon les préférences de l’utilisateur. On peut alors utiliser un tiers spécialisé pour offrir une transmission de valeur plus rapide, moins chère ou garantie. À noter que, mesuré en frais versés aux validateurs, 95 % de l’espace bloc Ethereum est utilisé pour la transmission de valeur.
Décisions clés de conception
Les trois couches décrites ci-dessus imposent des décisions critiques au sein du Cadre d’Abstraction des Chaînes (CAF). Ces décisions concernent qui contrôle le pouvoir d’exécution des intentions, quelles informations sont divulguées aux solvers, et quels chemins de règlement sont accessibles aux solvers. Voici une analyse détaillée de chaque couche.
Couche d’autorisation
La couche d’autorisation détient les clés privées de l’utilisateur et signe des messages en son nom, qui seront ensuite exécutés comme transactions sur la blockchain. Le CAF doit supporter les schémas de signature et formats de transaction de toutes les chaînes cibles. Par exemple, un portefeuille supportant ECDSA et les standards EVM sera limité à Ethereum, ses L2 et sidechains (comme Metamask). En revanche, un portefeuille compatible EVM et SVM (Solana VM) peut couvrir les deux écosystèmes (comme Phantom). Notons qu’une même phrase mnémonique peut générer des portefeuilles sur les chaînes EVM et SVM.
Une transaction multichaîne comporte plusieurs sous-transactions devant être exécutées dans l’ordre correct. Ces sous-opérations doivent s’exécuter sur différentes chaînes, chacune avec ses propres frais variables dans le temps et numéros de séquence (nonce). La coordination et le règlement de ces sous-transactions constituent une décision cruciale au niveau de la couche d’autorisation.
-
Portefeuilles EOA sont des logiciels fonctionnant sur la machine de l’utilisateur et détenant ses clés privées. Ils peuvent prendre la forme d’extensions navigateur (comme Metamask et Phantom), d’applications mobiles (comme Coinbase Wallet) ou de matériel dédié (comme Ledger). Les portefeuilles EOA exigent une signature distincte pour chaque sous-transaction, ce qui implique actuellement plusieurs clics. Ils obligent aussi l’utilisateur à détenir des fonds pour les frais sur la chaîne cible, créant ainsi une friction importante. Toutefois, cette friction peut être atténuée en permettant à l’utilisateur de signer plusieurs sous-transactions d’un seul clic.
-
Dans les portefeuilles à abstraction de compte (AA), l’utilisateur conserve l’accès à ses clés privées mais sépare l’entité signataire du charge utile de transaction de celle qui exécute la transaction. Cela permet à des entités complexes d’agréger et d’exécuter atomiquement plusieurs transactions utilisateur (ex. Avocado, Pimlico). Les portefeuilles AA exigent encore une signature par sous-transaction (actuellement via plusieurs clics), mais n’obligent pas l’utilisateur à détenir des frais sur chaque chaîne.
-
Les mandataires basés sur stratégie conservent les clés privées de l’utilisateur dans un environnement d’exécution distinct, et génèrent des signatures au nom de l’utilisateur conformément à une stratégie prédéfinie. Des robots Telegram, des agrégateurs de comptes proches ou SUAVE TEE sont des exemples de portefeuilles basés sur stratégie, tandis qu’Entropy ou Capsule sont des extensions de portefeuilles basées sur stratégie. L’utilisateur signe une seule autorisation initiale ; les signatures suivantes pour les sous-transactions et la gestion des frais sont ensuite réalisées automatiquement par le mandataire pendant le processus.
Couche de résolution (Solver)
Après publication de son intention, l’utilisateur reçoit de la part de la couche de résolution une estimation des frais et du délai de confirmation. Ce problème est étroitement lié à la conception des enchères de flux d’ordres, dont une discussion détaillée se trouve ici. Le CAF peut exploiter des chemins internes au protocole pour exécuter l’intention utilisateur, ou bien faire appel à des tiers sophistiqués (c’est-à-dire des solvers), en sacrifiant un peu de sécurité pour améliorer l’expérience utilisateur. L’intégration de solvers dans le cadre CAF soulève deux autres décisions de conception, étroitement liées à la gestion de l’information.
Une intention est composée de deux types de valeurs extractibles (EV) : EV_ordering et EV_signal.
-
EV_ordering est une valeur spécifique à la blockchain, généralement capturée par l’entité exécutant l’ordre (comme un constructeur de blocs ou un validateur).
-
EV_signal représente la valeur accessible à toute entité respectant l’ordre avant qu’il ne soit officiellement enregistré sur la blockchain.
Différentes intentions présentent des distributions variées entre EV_ordering et EV_signal. Par exemple, une intention d’échange sur une DEX a souvent une forte valeur EV_ordering, mais une faible valeur EV_signal. Inversement, une transaction de piratage aura une composante EV_signal plus élevée, car devancer l’exécution rapporte plus que l’exécution elle-même. Notons que EV_signal peut parfois être négatif, comme dans le cas des transactions de market makers, où l’entité exécutant l’ordre peut subir une perte, car le market maker a une meilleure connaissance des conditions futures du marché.
Quand un tiers peut observer à l’avance l’intention d’un utilisateur, il peut la devancer, causant une fuite de valeur. De plus, la possibilité d’une valeur EV_signal négative crée un environnement concurrentiel parmi les solvers, les incitant à soumettre des offres plus basses, amplifiant ainsi la fuite de valeur (aussi appelée sélection adverse). En fin de compte, ces fuites affectent l’utilisateur via des frais plus élevés ou des prix moins avantageux. Précisons que des frais bas ou des prix améliorés sont deux faces d’une même pièce, et seront utilisés indifféremment dans la suite de cet article.
Partage d’information
Trois méthodes permettent de partager l’information avec les solvers :
-
Mempool public : l’intention utilisateur est diffusée publiquement vers un mempool ou une couche de disponibilité des données. Le premier solver capable de satisfaire la requête exécute l’ordre et remporte l’enchère. Ce système extrait fortement l’information utilisateur, car les valeurs EV_ordering et EV_signal sont exposées publiquement. Par exemple, le mempool public d’Ethereum ou divers ponts blockchain. Dans le cas des ponts, l’utilisateur doit placer ses actifs en dépôt de garantie avant le transfert vers la chaîne cible afin d’éviter les attaques malveillantes, mais cela révèle involontairement son intention.
-
Partage partiel : le CAF peut limiter la quantité d’information divulguée aux enchérisseurs, réduisant ainsi la valeur exposée. Toutefois, cette méthode entraîne directement une perte d’optimalité des prix et peut provoquer des spams d’enchères.
-
Mempool privé : les progrès récents autour des MPC et des TEE rendent possible un mempool totalement privé. Aucune information n’est divulguée en dehors de l’environnement d’exécution ; les solvers codent leurs préférences et sont appariés à chaque intention. Bien que le mempool privé capture EV_ordering, il ne peut pas complètement capturer EV_signal. Par exemple, si une transaction de piratage est envoyée au mempool, la première personne à la voir peut la devancer et capter EV_signal. Dans un mempool privé, l’information n’est révélée qu’après confirmation du bloc, donc tout observateur peut alors capter EV_signal. On imagine que des solvers pourraient déployer des nœuds certifiés pour extraire EV_signal depuis les nouveaux blocs créés par le TEE, transformant la capture de EV_signal en une course à la latence.
Liste des solvers
Le CAF doit également décider combien et quels solvers peuvent participer aux enchères. Les options principales sont :
-
Accès ouvert : le seuil d’entrée pour participer est aussi bas que possible. Cela ressemble à un mempool public, exposant EV_signal et EV_ordering.
-
Accès restreint : l’accès à l’exécution des ordres est contrôlé par liste blanche, système de réputation, frais ou vente aux enchères de places. Ce mécanisme de contrôle doit garantir que les solvers ne capturent pas EV_signal. Exemples : 1inch Auction, Cowswap Auctions, enchères Uniswap X. La concurrence entre solvers permet de capturer EV_ordering pour l’utilisateur, tandis que le mécanisme de contrôle permet au générateur d’ordres (portefeuille, dApp) de capturer EV_signal.
-
Accès exclusif : forme particulière d’enchère où un seul solver est sélectionné pour chaque période. Aucune information n’est divulguée aux autres solvers, évitant ainsi la sélection adverse et les rabais anticipés. Le lanceur d’ordres capture la valeur espérée de EV_signal et EV_ordering, mais en l’absence de concurrence, l’utilisateur obtient uniquement l’exécution, sans amélioration de prix. Exemples : Robinhood et DFlow auctions.
Couche de règlement
Une fois qu’un lot de transactions est signé par le portefeuille, il doit être exécuté sur la blockchain. Une transaction inter-chaînes transforme le processus de règlement d’une opération atomique en une opération asynchrone. Pendant l’exécution et la confirmation de la transaction initiale, l’état sur la chaîne cible peut changer, menant potentiellement à un échec de transaction. Cette section explore les compromis entre coût de sécurité, délai de confirmation et garantie d’exécution.
Notons que l’exécution de la transaction attendue sur la chaîne cible dépend du mécanisme d’inclusion des transactions de cette dernière, y compris la capacité de censure des transactions et le mécanisme de frais. Nous considérons que le choix de la chaîne cible relève de la décision de la dApp, hors du champ de cet article.
Oracle inter-chaînes
Deux blockchains aux états et mécanismes de consensus différents ont besoin d’un intermédiaire, tel qu’un oracle, pour faciliter l’échange d’informations. L’oracle agit comme relais pour la transmission d’information entre chaînes, par exemple en vérifiant que l’utilisateur a bien verrouillé des fonds dans un compte de garantie pour un pont « lock-and-mint », ou en confirmant le solde du jeton de l’utilisateur sur la chaîne source afin de lui permettre de voter dans une gouvernance sur la chaîne cible.
Les oracles transmettent l’information à la vitesse de la chaîne la plus lente, afin de gérer le risque de réorganisation, car ils doivent attendre la consolidation du consensus sur la chaîne source. Supposons qu’un utilisateur veuille transférer des USDC de la chaîne source vers la chaîne cible, plaçant ses fonds en garantie. Si l’oracle ne patiente pas assez longtemps avant de frapper les jetons sur la chaîne cible, un problème survient : en cas de réorganisation, l’utilisateur pourrait annuler sa transaction de dépôt, et l’oracle causerait une double dépense.
Il existe deux types d’oracles :
-
Oracles hors protocole : nécessitent des validateurs tiers, séparés du consensus principal, pour transmettre l’information entre chaînes. Ces validateurs supplémentaires augmentent le coût de fonctionnement de l’oracle. LayerZero, Wormhole, ChainLink et Axelar Network sont des exemples d’oracles hors protocole.
-
Oracles intra-protocole : profondément intégrés dans l’algorithme de consensus de l’écosystème, utilisant le même ensemble de validateurs pour transmettre l’information. IBC de Cosmos pour les chaînes basées sur Cosmos SDK, AggLayer en cours de développement dans l’écosystème Polygon, et Superchain d’Optimism. Chaque oracle utilise un espace bloc dédié pour transmettre des informations entre chaînes du même écosystème.
-
Les séquenceurs partagés sont des entités hors protocole disposant d’un pouvoir de séquencement intra-protocole, pouvant regrouper des transactions entre chaînes. Bien qu’encore en développement, les séquenceurs partagés n’ont pas besoin d’attendre la confirmation d’un bloc spécifique pour réduire le risque de réorganisation. Pour atteindre une atomicité inter-chaînes réelle, un séquenceur partagé doit pouvoir exécuter une transaction conditionnellement au succès d’une précédente, les liant ainsi en chaîne.
Ponts de jetons
Dans un monde multichaîne, les jetons et soldes de frais des utilisateurs sont dispersés sur tous les réseaux. Avant chaque opération inter-chaînes, l’utilisateur doit pontifier ses fonds de la chaîne source vers la chaîne cible. Il existe actuellement 34 ponts inter-chaînes actifs, avec une TVL totale de 7,7 milliards de dollars et un volume de pontage de 8,6 milliards de dollars sur les 30 derniers jours.
Les ponts de jetons illustrent le transfert de valeur. Cela ouvre la voie à des tiers spécialisés, compétents en gestion de capital et acceptant de prendre le risque de réorganisation, réduisant ainsi le coût et le temps des transactions utilisateur.
Deux types de ponts inter-chaînes existent :
-
Ponts lock-and-mint : ces ponts vérifient le dépôt du jeton sur la chaîne source et frappent le jeton correspondant sur la chaîne cible. Le capital nécessaire pour lancer un tel pont est faible, mais la transmission sécurisée des informations de verrouillage exige un investissement important. Les failles de sécurité de ces ponts ont coûté des milliards de dollars aux détenteurs de jetons.
-
Ponts de liquidité : ces ponts exploitent des pools de liquidité sur la chaîne source et la chaîne cible, et utilisent des algorithmes pour déterminer le taux de conversion entre les jetons. Bien que leur coût initial soit élevé, ils exigent moins de garanties de sécurité. En cas de faille, seuls les fonds présents dans les pools de liquidité sont exposés.
Dans les deux types de ponts, l’utilisateur paie un coût de liquidité. Sur les ponts lock-and-mint, ce coût intervient lors de l’échange du jeton emballé contre le jeton souhaité sur la chaîne cible (USDC.e contre USDC). Sur les ponts de liquidité, le coût survient lors de l’échange du jeton sur la chaîne source contre celui sur la chaîne cible.
Le dilemme inter-chaînes
Les cinq décisions de conception ci-dessus engendrent un dilemme inter-chaînes. Le CAF doit choisir deux attributs parmi trois : garantie d’exécution, faibles frais et rapidité d’exécution.
-
Chemins intra-protocole : désignent des chemins prédéfinis pour la transmission d’information inter-chaînes. Ces systèmes tiennent compte du risque de réorganisation, sacrifiant la rapidité d’exécution, mais réduisent les coûts en supprimant les validateurs supplémentaires ou les coûts de liquidité.
-
Agrégation de solvers : collecte des devis de plusieurs solvers pour identifier le chemin le moins cher et le plus rapide pour exécuter l’intention utilisateur. Toutefois, en raison de la sélection adverse et des transactions devancées, certains solvers peuvent ne pas honorer l’intention, réduisant ainsi l’exécution.
-
Concurrence d’exécution : organise une course entre solvers pour exécuter l’intention ou choisit un seul solver gagnant. Ces deux méthodes entraînent des frais élevés pour l’utilisateur, car les solvers rivalisent pour l’exécution plutôt que pour l’amélioration des prix.
Les six composants de CAKE
Pour rédiger cet article, nous avons étudié plus de 20 équipes travaillant directement ou indirectement sur l’abstraction des chaînes. Dans cette section, nous analysons six implémentations indépendantes de CA que nous jugeons intrinsèquement efficaces et bien adaptées au marché. Correctement conçues, ces architectures pourraient être combinées entre elles.
Une conclusion majeure est que nous avons besoin d’une norme unifiée pour exprimer les intentions inter-chaînes. Chaque équipe développe sa propre méthode et protocole pour coder les intentions utilisateur, entraînant des redondances. Une norme commune améliorerait la compréhension par l’utilisateur des messages signés, faciliterait le traitement des intentions par les solvers et oracles, et simplifierait l’intégration avec les portefeuilles.
Ponts de jetons désignés
Un cas particulier de pont lock-and-mint, qui n’implique aucun coût de liquidité, également appelé pont burn-and-mint (ex. USDC CCTP). L’équipe du jeton spécifie une adresse canonique sur chaque chaîne, et le pont a le droit de frapper le jeton désiré par l’utilisateur.
À y regarder de près, un pont burn-and-mint ressemble à un transfert inter-chaînes effectué à la vitesse de confirmation des blocs. xERC20 est une telle norme, spécifiant sur la chaîne cible l’adresse canonique du jeton et son pont autorisé. Les ponts de jetons désignés sont un exemple de chemin intra-protocole, sacrifiant la vitesse au profit de la garantie d’exécution et des faibles frais — par exemple, CCTP nécessite 20 minutes pour achever un transfert.
Ponts de coordination d’écosystème
Les ponts de coordination d’écosystème permettent de transmettre des messages arbitraires entre chaînes d’un même écosystème. Ces ponts relèvent des chemins intra-protocole, privilégiant la garantie d’exécution et les faibles frais au détriment de la vitesse. Exemples : IBC de Cosmos, AggLayer de Polygon et Superchain d’Optimism.
Il y a trois ans, l’écosystème Cosmos faisait face à des défis similaires à ceux qu’Ethereum connaît aujourd’hui. La liquidité était fragmentée, chaque chaîne avait son propre jeton de frais, et la gestion des comptes multichaînes était fastidieuse. L’écosystème Cosmos a résolu ces problèmes grâce à IBC, un pont de messagerie intra-protocole, permettant une gestion fluide des comptes multichaînes et des transferts inter-chaînes.
L’écosystème Cosmos est constitué de chaînes indépendantes dotées de sécurité souveraine et de finalité rapide, rendant la messagerie inter-chaînes très rapide. En revanche, les écosystèmes de rollups dépendent de la fin de périodes de contestation (Rollups optimistes) ou de la soumission de preuves zk (Rollups validité) pour atteindre la finalité. En raison de ces limitations, la messagerie inter-écosystèmes est plus lente.
Concurrence sur les prix des solvers
La concurrence sur les prix des solvers implique de partager l’information de commande avec tous les solvers. Les solvers cherchent à combiner la valeur attendue (EV) générée par l’intention et à la restituer à l’utilisateur. Le solver gagnant est choisi selon le critère maximisant l’amélioration du prix pour l’utilisateur. Toutefois, cette conception comporte un risque de non-exécution, nécessitant des mécanismes supplémentaires pour assurer la fiabilité. Exemples : Uniswap X, Bungee et Jumper.
Messages coordonnés par portefeuille
Les messages coordonnés par portefeuille exploitent les fonctionnalités offertes par les portefeuilles AA ou basés sur stratégie, offrant une expérience inter-chaînes compatible avec tout type d’intention. Il agit comme agrégateur ultime de CA, redirigeant l’intention utilisateur vers divers designs de CA pour répondre à une intention spécifique. Exemples : portefeuille Avocado, Near Account Aggregator et Metamask Portfolio.
Notons qu’au cours des dix dernières années, l’écosystème crypto a appris que la relation entre l’utilisateur et son portefeuille est extrêmement fidèle. Chaque fois que je pense à migrer ma phrase mnémonique de Metamask vers un autre portefeuille, j’éprouve une peur intense. C’est pourquoi, même avec le soutien de Vitalik Buterin, l’EIP-4337 affiche après 2,5 ans un taux d’adoption faible. Même si de nouvelles versions de protocoles de portefeuille offrent aux utilisateurs de meilleurs prix (AA) ou une meilleure convivialité (portefeuilles basés sur stratégie), migrer les utilisateurs de leur portefeuille actuel reste une tâche ardue.
Concurrence sur la vitesse des solvers
La concurrence sur la vitesse des solvers permet à l’utilisateur d’exprimer une intention de conversion inter-chaînes pour obtenir une forte garantie d’exécution. Elle n’aide pas l’utilisateur à minimiser les frais, mais fournit un canal fiable pour inclure des transactions complexes. Le premier solver à exécuter l’intention selon les frais du constructeur de blocs ou la vitesse d’inclusion remporte l’intention.
Ce design vise un taux d’inclusion élevé en maximisant la capture d’EV par les solvers. Toutefois, cela se fait au prix d’une centralisation accrue, car il dépend d’une gestion complexe du capital sur le réseau principal Ethereum ou d’une exécution à faible latence sur les L2.
Enchères groupées exclusives
Les enchères groupées exclusives organisent une enchère pour le droit exclusif d’exécuter tous les flux d’ordres pendant une fenêtre temporelle donnée. Comme les autres solvers ne voient pas les ordres, ils misent sur la base de la volatilité de marché prévue et de la qualité moyenne d’exécution. Ces enchères reposent sur un prix de secours pour garantir un bon prix utilisateur, et ne peuvent donc pas servir à améliorer les prix. Envoyer tout le flux d’ordres à un seul soumissionnaire élimine les fuites d’information et renforce la garantie d’exécution.
Conclusion
Le cadre d’abstraction des chaînes (CAF) promet une interaction inter-chaînes transparente pour l’utilisateur. Dans cet article, nous avons étudié plusieurs équipes dont les conceptions, en production ou en développement, tentent explicitement ou implicitement de résoudre le problème de l’abstraction des chaînes. Nous pensons que cette année sera celle du CAF, et prévoyons une concurrence significative entre différentes conceptions et implémentations dans les 6 à 12 mois à venir.
Le transfert de valeur inter-chaînes s’effectuera à faible coût via des ponts autorisés par les jetons, et à grande vitesse via des compétitions de prix ou de vitesse entre solvers. La transmission d’information sera routée via des ponts de messagerie adaptés à l’écosystème, visant à minimiser le coût utilisateur, tandis que les plateformes pilotées par les portefeuilles maximiseront la rapidité. Finalement, ces six modèles de conception distincts formeront un écosystème cohérent, répondant chacun à des besoins spécifiques et tirant parti de l’efficacité dans différentes zones du matrice des compromis.
Une conclusion essentielle tirée de cette analyse est la nécessité d’une norme commune pour exprimer les intentions inter-chaînes. Actuellement, de nombreuses équipes développent leurs propres protocoles pour coder les intentions utilisateur, entraînant des efforts redondants. Une norme unifiée améliorerait la compréhension par l’utilisateur des messages signés, faciliterait le traitement des intentions par les solvers et oracles, et simplifierait l’intégration avec les portefeuilles.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
