Auteur original : Archive de lectures miroir préférées
Compilation originale : Shenchao TechFlow
Résumé des points clés
L'expérience utilisateur actuelle du chiffrement par défaut permet aux utilisateurs de toujours savoir avec quel réseau ils interagissent. Cependant, les internautes n’ont pas besoin de savoir avec quel fournisseur de cloud ils interagissent. Apporter cette approche à la blockchain est ce que nous appelons l’abstraction de la chaîne.
Cet article présente le cadre Chain Abstraction Key Elements (CAKE). Le cadre se compose de quatre parties : la couche d'application, la couche d'autorisation, la couche de solveur et la couche de règlement, visant à offrir aux utilisateurs une expérience opérationnelle inter-chaînes transparente.
La mise en œuvre de l'abstraction de la chaîne nécessite un ensemble complexe de technologies pour garantir la fiabilité, la rentabilité, la sécurité, la rapidité et la confidentialité du processus d'exécution.
Nous définissons les compromis entre chaînes dans l'abstraction de la chaîne comme un trilemme et proposons six alternatives de conception, chacune avec ses avantages uniques.
Pour réussir le saut vers un avenir d’abstraction enchaînée, en tant qu’industrie, nous devons définir et adopter une norme commune pour la transmission des informations entre les couches de CAKE. Un bon niveau est la cerise sur le gâteau.
Introduction
En 2020, le réseau Ethereum est passé à une feuille de route de mise à l’échelle centrée sur le cumul. Quatre ans plus tard, plus de 50 couches de rollup (L2) sont utilisées. Bien que la couche de cumul fournisse la mise à l'échelle horizontale requise, elle interrompt complètement l'expérience utilisateur.
Les utilisateurs ne doivent pas se soucier ni comprendre avec quel rollup ils interagissent. Les utilisateurs de crypto savent quel rollup ils utilisent (Optimism ou Base), ce qui équivaut aux utilisateurs Web2 sachant quel fournisseur de cloud ils utilisent (AWS ou GCP). La vision de Chain Abstraction est d’abstraire les informations de la chaîne du champ de vision de l’utilisateur. L'utilisateur connecte simplement le portefeuille à la dApp et signe les actions prévues. Les détails permettant de garantir que l'utilisateur dispose du bon équilibre sur la chaîne cible et exécute les actions prévues sont tous pris en charge en coulisses.
Dans cet article, nous explorerons comment l'abstraction de chaîne est un problème véritablement multidisciplinaire impliquant l'interaction de la couche application, de la couche autorisations, de la couche solveur et de la couche règlement. Nous introduisons le cadre des éléments clés de l'abstraction de chaîne (CAKE) et approfondissons les compromis de conception des systèmes d'abstraction de chaîne.
Présentation du framework CAKE
Dans le monde de l'abstraction de la chaîne, les utilisateurs visitent le site Web dApp, se connectent à leur portefeuille, signent les opérations et attendent le règlement final. Toutes les opérations complexes sont effectuées dans la couche infrastructure de CAKE. Les trois couches d'infrastructure de CAKE comprennent :
Couche d'autorisations : les utilisateurs connectent leurs portefeuilles aux dApps et demandent des devis en fonction de l'intention de l'utilisateur. L'intention fait référence au résultat que l'utilisateur s'attend à obtenir à la fin de la transaction, et non au chemin de la transaction. Par exemple, transférez l'USDT vers une adresse Tron ou déposez l'USDC dans une stratégie génératrice de rendement sur Arbitrum. Le portefeuille doit être capable de lire les actifs de l'utilisateur (c'est-à-dire l'état de lecture) et d'effectuer des transactions sur la chaîne cible (c'est-à-dire l'état de mise à jour).
Couche Solveur : La couche Solveur estime les frais et la vitesse d'exécution en fonction du solde initial et de l'intention de l'utilisateur. Dans un environnement inter-chaînes, ce processus, appelé résolution, est essentiel car les transactions sont asynchrones et les sous-transactions peuvent échouer pendant l'exécution. L'asynchronicité introduit un trilemme inter-chaînes impliquant les frais, la vitesse d'exécution et les garanties d'exécution.
Couche de règlement : une fois qu'un utilisateur a approuvé une transaction à l'aide d'une clé privée, la couche de règlement assure son exécution. Elle se compose de deux étapes : relier les actifs de l'utilisateur à la chaîne cible, puis exécuter la transaction. Si les protocoles utilisent des solveurs complexes pour certaines opérations, ils peuvent fournir leur propre liquidité et effectuer des opérations pour le compte des utilisateurs sans avoir besoin de ponts.
La mise en œuvre de l'abstraction de la chaîne signifie fusionner les trois couches d'infrastructure ci-dessus en un produit unifié. Un élément clé de la fusion de ces couches est la différence entre la fourniture d’informations et la fourniture de valeur. Le transfert d’informations entre les chaînes doit se faire sans perte, alors comptez sur le chemin le plus sûr. Par exemple, les utilisateurs votant « oui » d'une chaîne à un vote de gouvernance sur une autre chaîne ne veulent pas que leur vote devienne « peut-être ». D’un autre côté, selon les préférences de l’utilisateur, la livraison de valeur peut être perdue. Un tiers établi peut être exploité pour fournir aux utilisateurs une livraison plus rapide, moins chère ou à valeur garantie. Il est important de noter que 95 % de l’espace de bloc d’Ethereum est utilisé pour le transfert de valeur, tel que mesuré par les frais payés aux validateurs.
décisions de conception clés
Les trois niveaux ci-dessus présentent les décisions de conception clés que le CAF doit prendre. Ces décisions impliquent qui contrôle l'autorité nécessaire pour exécuter l'intention, quelles informations sont divulguées au solveur et quelles voies de règlement sont disponibles pour le solveur. Vous trouverez ci-dessous une analyse détaillée de chaque niveau.
Niveau d'autorisation
La couche d'autorisation contient la clé privée de l'utilisateur et signe les messages au nom de l'utilisateur, qui sont ensuite exécutés sous forme de transactions en chaîne. CAF doit prendre en charge les systèmes de signature et les charges utiles de transaction de toutes les chaînes cibles. Par exemple, les portefeuilles prenant en charge le système de signature ECDSA et la norme de transaction EVM seront limités à Ethereum, à son L2 et à ses sidechains (comme le portefeuille Metamask). En revanche, les portefeuilles prenant en charge EVM et SVM (Solana VM) pourront prendre en charge ces deux écosystèmes (comme le portefeuille Phantom). Il convient de noter que la même phrase mnémonique peut être utilisée pour générer des portefeuilles sur les chaînes EVM et SVM.
Une 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 occasionnels variables dans le temps. La manière dont ces sous-transactions sont coordonnées et réglées est une décision de conception clé pour la couche d'autorisations.
Le portefeuille EOA est un logiciel de portefeuille qui s'exécute sur la machine de l'utilisateur et contient sa clé privée. Il peut s'agir d'extensions basées sur un navigateur comme Metamask et Phantom, d'applications mobiles comme Coinbase Wallet ou de matériel spécialisé comme Ledger. Les portefeuilles EOA exigent que les utilisateurs signent chaque sous-transaction individuellement, ce qui nécessite actuellement plusieurs clics. Ils obligent également les utilisateurs à conserver des soldes de frais sur la chaîne cible, ce qui introduit des frictions importantes dans le processus. Cependant, en permettant aux utilisateurs de signer plusieurs sous-transactions en un seul clic, la friction de plusieurs clics peut être soustraite à l'utilisateur.
Dans un portefeuille Account Abstraction (AA), les utilisateurs ont toujours accès à leurs clés privées, mais ils séparent le signataire de la charge utile de la transaction de l'exécuteur de la transaction. Permet à des parties complexes de regrouper et d'exécuter les transactions des utilisateurs de manière atomique (Avocado, Pimlico). Les portefeuilles AA exigent toujours que les utilisateurs signent chaque sous-transaction individuellement (actuellement via plusieurs clics), mais n'exigent pas qu'un solde de frais soit détenu sur chaque chaîne.
Les agents basés sur des stratégies enregistrent la clé privée de l'utilisateur dans un environnement d'exécution distinct et génèrent des messages signés au nom de l'utilisateur en fonction de la stratégie de l'utilisateur. Telegram Bot, Near Account Aggregator ou SUAVE TEE sont des portefeuilles basés sur une stratégie tandis qu'Entropy ou Capsule sont des extensions de portefeuille basées sur une stratégie. Les utilisateurs doivent uniquement signer un formulaire d'approbation, et la signature ultérieure des sous-transactions et de la gestion des dépenses peut être complétée par ces agents pendant l'opération.
couche de solveur
Une fois que l'utilisateur a publié l'intention, la couche du solveur implique le renvoi des frais et du délai de confirmation à l'utilisateur. Cette question est étroitement liée à la conception des enchères de flux d’ordres et est discutée en détail ici. CAF peut exploiter les chemins intra-protocoles pour exécuter l'intention de l'utilisateur, ou tirer parti de tiers complexes (c'est-à-dire des solveurs) pour compromettre certaines garanties de sécurité afin d'offrir aux utilisateurs une expérience utilisateur améliorée. L’introduction du solveur dans le cadre CAF mènera aux deux prochaines décisions de conception, qui sont étroitement liées aux informations.
Les intentions se composent de deux types de valeurs extractibles (EV) : les valeurs EV_ordering et EV_signal.
EV_ordering est une valeur spécifique à la blockchain qui est généralement extraite par l'entité qui exécute les commandes des utilisateurs (telles que les constructeurs de blocs ou les validateurs).
EV_signal représente la valeur accessible à toute entité se conformant à la commande avant son enregistrement officiel sur la blockchain.
Différentes intentions d'utilisateur ont des distributions différentes entre EV_ordering et EV_signal. Par exemple, l’intention d’échanger des pièces sur un DEX a généralement une valeur EV_ordering élevée mais une faible valeur EV_signal. À l’inverse, la composante EV_signal d’une transaction piratée sera plus élevée car le front-running gagnera plus de valeur que l’exécution de la transaction. Il convient de noter que EV_signal peut parfois être négatif, comme dans le cas des opérations de teneur de marché, où l'entité exécutant ces ordres peut subir des pertes puisque le teneur de marché a une meilleure connaissance des conditions futures du marché.
Lorsque quelqu'un est capable d'observer l'intention d'un utilisateur à l'avance, il peut aller de l'avant, provoquant une fuite de valeur. De plus, la possibilité d'un EV_signal négatif crée un environnement concurrentiel entre les solveurs, les obligeant à soumettre des offres plus basses, provoquant ainsi une fuite de valeur supplémentaire (c'est-à-dire une sélection adverse). En fin de compte, les fuites ont un impact sur les utilisateurs en augmentant les frais ou en proposant de meilleures offres. Veuillez noter que des frais faibles ou des prix plus élevés sont les deux faces d’une même médaille et seront utilisés de manière interchangeable dans le reste de cet article.
Partage d'information
Il existe trois manières de partager des informations avec le solveur :
Public Mempool : les intentions des utilisateurs sont diffusées publiquement vers le mempool public ou la couche de disponibilité des données, et le premier solveur capable de satisfaire la demande exécute la commande et devient le gagnant. Ce système est hautement extractif d'informations sur les utilisateurs car les utilisateurs exposent leur EV_ordering et EV_signal. Par exemple, le pool de mémoire public d’Ethereum et divers ponts blockchain. Dans le cas d'un pont, les utilisateurs doivent placer les actifs sous séquestre avant de les transférer vers la chaîne cible pour éviter les attaques malveillantes, mais ce processus rend publiques par inadvertance leurs intentions.
Partage partiel : la CAF peut réduire le montant de la valeur divulguée aux soumissionnaires en limitant les informations divulguées. Cependant, cette approche entraînera directement une perte d’optimalité des prix et pourrait entraîner des problèmes tels que le spam d’enchères.
Mempools privés : les développements récents de MPC et TEE rendent possibles des mempools entièrement privés. Aucune information n'est divulguée en dehors de l'environnement d'exécution, et les solveurs encodent leurs préférences et correspondent à chaque intention. Bien que le pool de mémoire privé capture EV_ordering, il ne peut pas capturer entièrement EV_signal. Par exemple, si une transaction piratée est envoyée à Mempool, la première personne à voir la commande peut anticiper la transaction et capturer le signal EV. Dans un pool de mémoire privé, les informations ne sont publiées qu'après confirmation du blocage, de sorte que toute personne voyant la transaction peut capturer le signal EV_signal. Il est concevable que le solveur établisse des nœuds d'authentification pour capturer le signal EV à partir de blocs de TEE nouvellement créés, transformant ainsi la capture du signal EV en une compétition retardée.
Liste des solveurs
La CAF doit également décider combien et quels enchérisseurs seront autorisés à participer aux enchères. Les principales options sont les suivantes :
Libre accès : la barrière la plus basse possible à l’entrée pour la possibilité de participer. Ceci est similaire à l'exposition de mempool, qui fuit EV_signal et EV_ordering.
Restreindre l'accès : contrôler les capacités d'exécution des ordres via des listes blanches, des systèmes de réputation, des frais ou des enchères de sièges. Le mécanisme de déclenchement est nécessaire pour garantir que le signal EV_signal n'est pas capturé par les solveurs du système. Par exemple, 1inch Auction, Cowswap Auction et Uniswap X Auction. La concurrence gagnante des commandes capture EV_ordering pour les utilisateurs, tandis que les mécanismes de contrôle capturent EV_signal pour les générateurs de commandes (portefeuilles, dApps).
Accès exclusif : L'accès exclusif est un format d'enchère spécial dans lequel un seul solveur est sélectionné par période. Puisqu’aucune information n’est divulguée à d’autres solveurs, il n’y a pas de sélection adverse ni de remises anticipées. L'initiateur du flux d'ordres capture les valeurs attendues de EV_signal et EV_ordering, et comme il n'y a pas de concurrence, les utilisateurs obtiennent uniquement des exécutions mais pas d'améliorations de prix. Des exemples de telles enchères sont les enchères Robinhood et DFlow.
couche de peuplement
Une fois qu’un portefeuille signe un ensemble de transactions, celles-ci doivent être exécutées sur la blockchain. Les transactions inter-chaînes transforment le processus de règlement d’une opération atomique en une opération asynchrone. Lors de l'exécution et de la confirmation initiales de la transaction, l'état de la chaîne cible peut changer, entraînant potentiellement l'échec de la transaction. Cette sous-section explore les compromis entre le coût de la sécurité, le délai de confirmation et les garanties d'exécution.
Il est important de noter que l’exécution de la transaction prévue sur la chaîne cible dépend du mécanisme d’inclusion des transactions de la chaîne cible, y compris la capacité d’examiner les transactions 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 de dApp et dépasse le cadre de cet article.
Oracle inter-chaînes
Deux blockchains avec des états et des mécanismes de consensus différents nécessitent un intermédiaire, tel qu'un oracle, pour faciliter le transfert d'informations entre elles. L'oracle agit comme un relais pour le transfert d'informations entre les chaînes, notamment en vérifiant qu'un utilisateur a bloqué des fonds sur un compte séquestre dans un pont de verrouillage et de frappe, ou en confirmant le solde de jetons d'un utilisateur sur la chaîne d'origine pour participer aux votes de gouvernance sur la chaîne d'origine. chaîne cible.
L'oracle transmet les informations à la vitesse de la chaîne la plus lente. Ceci pour gérer le risque de réorganisation, car l'oracle doit attendre le consensus de la chaîne d'origine. Supposons qu'un utilisateur souhaite relier l'USDC de la chaîne d'origine à la chaîne cible, et qu'à cette fin, l'utilisateur verrouille ses fonds en dépôt. Cependant, des problèmes peuvent survenir si l'oracle n'attend pas suffisamment de confirmations et continue de créer des jetons pour l'utilisateur sur la chaîne cible. Si une réorganisation se produit et que les utilisateurs écrasent leurs transactions de dépôt, l'oracle entraînera une double dépense.
Il existe deux types d'oracles :
Oracles hors protocole : doivent être distincts des validateurs tiers qui gèrent le consensus pour transmettre les informations entre les chaînes. Des validateurs supplémentaires augmentent le coût de fonctionnement d'un oracle. LayerZero, Wormhole, ChainLink et Axelar Networks sont des exemples d'oracles hors protocole.
Oracles dans le protocole : profondément intégrés dans l'algorithme de consensus de l'écosystème et communiquent des informations à l'aide de l'ensemble des validateurs exécutant le consensus. L'IBC de Cosmos est utilisé pour les chaînes exécutant le SDK Cosmos, l'écosystème Polygon développe AggLayer et Optimism développe Superchain. Chaque oracle utilise un espace de bloc dédié pour transmettre des informations entre les chaînes du même écosystème.
Les séquenceurs partagés sont des entités extérieures au protocole qui disposent de droits de commande de transactions au sein du protocole, c'est-à-dire qu'ils peuvent regrouper les transactions entre les chaînes. Bien qu'encore en développement, le séquenceur partagé n'a pas besoin d'attendre des confirmations de blocs spécifiques pour réduire les risques de réorganisations. Pour parvenir réellement à une atomicité inter-chaînes, le séquenceur partagé doit être capable d'exécuter les transactions suivantes si les transactions précédentes réussissent, les transformant ainsi en chaînes.
jeton de pontage
Dans un monde multi-chaînes, les soldes de jetons et de frais d’un utilisateur sont dispersés sur tous les réseaux. Avant chaque opération inter-chaînes, les utilisateurs doivent transférer les fonds de la chaîne d'origine 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 ponts au cours des 30 derniers jours de 8,6 milliards de dollars.
Les jetons de transition sont un cas de transfert de valeur. Cela crée des opportunités de faire appel à des tiers professionnels qui maîtrisent bien la gestion du capital et sont prêts à supporter les risques de restructuration, réduisant ainsi le coût et le temps nécessaires aux utilisateurs pour négocier.
Il existe deux types de ponts à chaînes croisées :
Lock and Mint Bridge : Le Lock and Mint Bridge vérifie les dépôts de jetons sur la chaîne d'origine et frappe les jetons sur la chaîne cible. Le capital requis pour lancer un tel pont est faible, mais le transfert sécurisé d'informations verrouillées nécessite des investissements importants. Les failles de sécurité sur ces ponts ont entraîné des pertes de plusieurs milliards de dollars pour les détenteurs de jetons.
Liquidity Bridge : Liquidity Bridge utilise les pools de liquidités de la chaîne d'origine et de la chaîne cible, et utilise des algorithmes pour déterminer le taux de conversion entre la chaîne d'origine et le jeton cible. Bien que ces ponts aient un coût initial plus élevé, ils nécessitent des garanties de sécurité moindres. En cas de faille de sécurité, seuls les fonds du pool de liquidité sont menacés.
Dans les deux ponts inter-chaînes, les utilisateurs doivent payer des coûts de liquidité. Dans un pont de verrouillage et de frappe, le coût de liquidité est encouru lors de l'échange du jeton d'emballage vers le jeton souhaité (USDC.e en USDC) sur la chaîne cible, tandis que dans un pont de liquidité, le coût de liquidité est encouru lors de l'échange du jeton d'origine. token vers USDC Se produit lorsque les jetons de la chaîne sont échangés contre des jetons sur la chaîne cible.
Trilemme inter-chaînes
Les cinq décisions de conception ci-dessus soulèvent le trilemme inter-chaînes. La CAF doit choisir deux attributs entre la garantie d’exécution, les frais peu élevés et la rapidité d’exécution.
Chemin intra-protocole : il s'agit du chemin de transmission d'informations inter-chaînes désigné. Ces systèmes prennent en compte le risque de réorganisation, sacrifiant la vitesse d'exécution mais réduisant les coûts en éliminant les ensembles de validateurs supplémentaires ou les coûts de liquidité.
Agrégation de solveurs : collectez les devis de plusieurs solveurs pour identifier le chemin le moins cher et le plus rapide pour exécuter l'intention de l'utilisateur. Cependant, en raison de la sélection adverse et du front-running, il arrive parfois que le solveur ne parvienne pas à répondre à l'intention, ce qui entraîne une exécution réduite.
Concours d'exécution : sélectionnez le solveur gagnant en organisant les solveurs pour faire courir les intentions d'exécution ou en sélectionnant un seul solveur. Les deux approches entraînent des frais d'utilisation élevés, car les solveurs se disputent l'exécution plutôt que l'amélioration des prix.
Les six composants de CAKE
Pour cet article, nous avons étudié plus de 20 conceptions d’équipes qui travaillent directement et indirectement sur l’abstraction de la chaîne. Dans cette section, nous discutons de six implémentations indépendantes d’AC qui, selon nous, présentent une efficacité inhérente et une adéquation produit-marché. Si elles sont construites correctement, ces conceptions ont le potentiel de se combiner les unes avec les autres.
Une conclusion clé est que nous avons besoin d’une norme unifiée pour l’expression des intentions entre chaînes. Chaque équipe travaille sur ses propres méthodes et protocoles pour coder l’intention de l’utilisateur. Une norme unifiée améliorera la compréhension des utilisateurs de leurs messages signés, permettra aux solveurs et aux oracles de comprendre plus facilement ces intentions et simplifiera l'intégration avec les portefeuilles.
Pont désigné par jeton
Il existe un cas particulier de ponts lock-and-mint qui ne paient pas de coûts de liquidité, également appelés ponts burn-and-mint (par exemple USDC CCTP). L'équipe des jetons attribue une adresse de jeton canonique sur chaque chaîne, et le pont a le pouvoir de créer les jetons dont l'utilisateur a besoin.
Si vous regardez attentivement, vous verrez que le pont Burn and Mint est similaire à un transfert inter-chaînes avec une vitesse de confirmation de bloc suffisante. xERC 20 est une norme permettant de spécifier les jetons canoniques et leurs ponts délégués sur une chaîne cible. Les ponts spécifiés par jeton sont un exemple de chemin intra-protocole qui sacrifie la vitesse pour une exécution garantie et des frais faibles, par exemple CCTP prend 20 minutes pour effectuer un transfert.
Pont de coordination des écosystèmes
Ecosystem Coordination Bridge peut transmettre des messages arbitraires entre les chaînes au sein du même écosystème. De tels ponts sont des chemins intra-protocoles qui donnent la priorité aux garanties 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é est dispersée entre différentes chaînes, chaque chaîne a son propre jeton de frais et la gestion des comptes multi-chaînes est très lourde. L'écosystème Cosmos résout ces problèmes en mettant en œuvre un pont de messagerie intra-protocole IBC, permettant une gestion transparente des comptes multi-chaînes et des transferts inter-chaînes.
L'écosystème Cosmos se compose de chaînes indépendantes dotées d'une sécurité souveraine et d'une finalité rapide, ce qui rend la messagerie inter-chaînes au sein du protocole très rapide. L'écosystème de rollup s'appuie sur la fin de la période de challenge (cumuls optimistes) ou sur la soumission de preuves zk (cumuls de validité) pour atteindre la finalité. En raison de ces restrictions de finalité, la transmission des messages à travers l’écosystème sera plus lente.
Concurrence sur les prix des solveurs
La concurrence sur les prix des solveurs implique le partage des informations de commande avec tous les solveurs. Le solveur est conçu pour combiner la valeur attendue (EV) générée par l'intention de commande et la fournir à l'utilisateur. La sélection du solveur gagnant dans le système est basée sur la maximisation de l'amélioration du prix utilisateur. Cependant, cette conception comporte un risque de non-exécution et nécessite des mécanismes supplémentaires pour garantir la fiabilité des ordres. Des exemples de tels mécanismes incluent Uniswap X, Bungee et Jumper.
Messages de rapprochement du portefeuille
Les messages de coordination de portefeuille exploitent les fonctionnalités fournies par AA ou les portefeuilles basés sur des politiques pour offrir une expérience inter-chaînes compatible avec tout type d'intention. Il agit comme l'agrégateur d'autorité de certification ultime, redirigeant l'intention de l'utilisateur entre différentes conceptions d'autorité de certification pour répondre à une intention spécifique. Les exemples incluent Avocado Wallet, Near Account Aggregator et Metamask Portfolio.
Il est important de noter qu’au cours de la dernière décennie, l’écosystème cryptographique a appris que la relation entre les utilisateurs et leurs portefeuilles est très délicate. Chaque fois que je pense à migrer ma phrase mnémonique de Metamask vers un autre portefeuille, je me sens extrêmement terrifié. C'est également la raison pour laquelle l'EIP-4337 a toujours un faible taux d'adoption après 2,5 ans, même avec le soutien de Vitalik Buterin lui-même. Bien que les versions plus récentes du protocole de portefeuille puissent offrir aux utilisateurs de meilleurs prix (abstraction de compte) ou une facilité d'utilisation améliorée (portefeuilles basés sur des politiques), la migration des utilisateurs depuis leurs portefeuilles actuels est une tâche ardue.
Concours de vitesse de solveur
La compétition de vitesse du solveur permet aux utilisateurs d'exprimer leurs intentions pour des transformations inter-chaînes spécifiques afin d'obtenir des garanties d'exécution élevées. Il n'aide pas les utilisateurs à minimiser les frais, mais fournit un canal fiable pour contenir les transactions complexes. Le premier solveur à exécuter une intention basée sur les frais de création de blocs ou à inclure la vitesse remportera cette intention.
La conception vise à atteindre des taux d'inclusion élevés en maximisant l'EV capturé par le solveur. Cependant, cela se fait au détriment de la centralisation, car cela repose sur une gestion complexe du capital sur le réseau principal Ethereum ou sur une exécution à faible latence sur L2.
Enchères groupées exclusives
Une enchère par lots exclusive organise une enchère pour le droit exclusif d'exécuter tous les flux d'ordres dans un laps de temps donné. Étant donné que les autres solveurs ne peuvent pas voir les ordres, ils enchérissent en fonction de la volatilité prévue du marché et de la qualité d'exécution moyenne. Les enchères par lots exclusives reposent sur un prix de repli pour garantir de bons prix aux utilisateurs et ne peuvent donc pas être utilisées pour améliorer les prix. L'envoi de tous les flux de commandes à un seul enchérisseur élimine les fuites d'informations et améliore l'assurance d'exécution.
en conclusion
Le Chain Abstraction Framework (CAF) promet de fournir aux utilisateurs des interactions inter-chaînes transparentes. Dans cet article, nous examinons les conceptions en production et en développement de 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 du CAF et nous nous attendons à ce qu'une concurrence significative entre les différentes conceptions et leurs mises en œuvre se produise au cours des 6 à 12 prochains mois.
Les transferts de valeur entre chaînes seront rendus possibles par un pontage délégué par jetons pour des frais faibles et une exécution rapide grâce à la vitesse du solveur ou à des compétitions de prix. Les transferts de messages sont acheminés via des ponts de messagerie adaptés à l'écosystème, conçus pour minimiser les coûts d'utilisation et maximiser la vitesse via une plate-forme contrôlée par portefeuille. En fin de compte, ces six options de conception différentes formeront un cluster car elles répondent chacune à des besoins différents et tirent parti des gains d’efficacité dans différents domaines de la matrice de compromis.
Une conclusion importante que nous avons tirée de ce processus est que nous avons besoin d’une norme commune pour exprimer les intentions entre les chaînes. Actuellement, plusieurs équipes travaillent indépendamment sur des protocoles de codage des intentions des utilisateurs, ce qui entraîne une duplication des efforts. Une norme unifiée contribuera à améliorer la compréhension des utilisateurs des messages signés, à faciliter le traitement des intentions par les solveurs et les oracles et à simplifier l'intégration avec les portefeuilles.
Lien d'origine