Cet article présentera la fonctionnalité de "Confidentialité programmable" qui offre des transactions plus avancées et une conception de marché MEV plus ouverte et plus équitable, transversale - SUAVE. Avant d'entrer dans le sujet principal de l'explication de SUAVE, veuillez d'abord comprendre le concept d'Intent.

Intention

Expérience actuelle d'utilisation des transactions blockchain

En prenant les transactions Ethereum comme exemple, en supposant qu'un utilisateur souhaite échanger ses USDT contre de l'ETH, il peut se rendre sur la page web d'Uniswap pour vérifier le prix, et après avoir défini le glissement de prix autorisé, signer et envoyer la transaction, puis attendre le résultat de la transaction.

Sa transaction ressemblera probablement à ceci : “Je signe et envoie cette transaction, avec une valeur de Nonce de 23 et des frais de gaz de 30 Gwei. Il exécutera le contrat Uniswap pour échanger mes 1000 USDT contre 0,5 ETH, avec un glissement maximal de 1%.”

△ Nonce ? Gwei ? Source de l'image :https://www.reddit.com/r/MemeRestoration/comments/ejcvd3/confused_math_lady_4080x2663px

Supposons qu'Alice soit une utilisatrice novice et qu'elle veuille simplement échanger ses USDT contre de l'ETH, mais elle doit franchir de nombreux obstacles pour réaliser ce petit souhait :

• La première consiste à trouver le canal d'échange. Supposons qu'elle fasse une recherche sur Google et trouve la page Uniswap (au moins il y a un menu d'actifs numériques clair et un bouton Swap), puis elle doit comprendre et régler le glissement (ou utiliser la valeur par défaut).
• Après avoir cliqué sur le bouton d'échange, l'écran de signature de transaction s'affiche, contenant le Nonce et le Gwei des frais de traitement.
• Finalement, elle envoie la transaction, mais probablement rien ne se passe et Alice ne peut que attendre dans la confusion et prier pour que la transaction soit exécutée avec succès.

Chaque niveau est une question que les utilisateurs novices n'ont pas réellement besoin de comprendre mais sont forcés de faire un choix : Où échanger ? Voulez-vous définir un glissement ? Quel pourcentage doit être défini pour le glissement ? Voulez-vous ajuster les frais de gaz (frais de traitement) ? Combien de Gwei doit-il être ajusté ? Pourquoi la transaction a-t-elle échoué ? Pourquoi la transaction est-elle bloquée depuis si longtemps (peut-être un problème avec le Nonce ou les frais de traitement) ? Que dois-je faire ?

Expérience d'utilisation de transaction d'intention

Contrairement à la transaction, qui nécessite de spécifier divers détails d’une transaction, l’intention demande seulement à l’utilisateur de spécifier les résultats qu’il souhaite obtenir et les conditions d’exécution, et de laisser le reste à des personnes plus professionnelles.

Dans l'intention, Alice a spécifié que 1000 USDT devraient être échangés contre 0,5 ETH, mais compte tenu des frais de traitement, le prix a été ajusté à 0,495 ETH, puis l'ordre a été signé et envoyé. La transaction d'Alice ressemblera à ceci : "Je signe et envoie cet ordre. Je veux échanger 1000 USDT contre 0,495 ETH. Cet ordre est valide tant que je peux obtenir 0,495 ETH."

C'est très simple, n'est-ce pas ? Il s'agit de l'expérience d'utilisation d'un ordre limite (Limit Order), et c'est aussi l'expérience générale d'utilisation des agrégateurs DEX (comme 1inch et Tokenlon).

△ La différence entre Transaction (en haut) et Intention (en bas). Avec l'Intention, les utilisateurs n'ont qu'à spécifier les conditions et ne pas se soucier de la façon de les réaliser. Légende :https://www.paradigm.xyz/2023/06/intents

Grâce à l'intention, les utilisateurs n'ont plus besoin de traiter et de se soucier des divers détails fastidieux et confus entre la génération, la signature et l'exécution des transactions. Ils n'ont même pas besoin de comprendre le problème et de continuer à essayer en cas d'échec d'une transaction. De plus, les différentes chaînes auront des processus et des pièges de transaction différents!

Grâce à l'intention, l'utilisateur n'a besoin que de spécifier les conditions d'exécution et les résultats attendus de son intention. Le reste est pour le Solveur professionnel de réaliser l'intention de l'utilisateur - comment envoyer des transactions, surveiller des transactions, accélérer des transactions, etc. Gérer les problèmes gênants tels que l'échec de la transaction, et l'intention ne peut être mise en œuvre que lorsque les conditions d'exécution et les résultats attendus sont atteints, donc les utilisateurs n'ont pas à se soucier qu'un accident fasse disparaître des actifs.

L'intention améliorera grandement l'expérience de la blockchain.

Conseil de lecture 1 : En fait, il existe déjà de nombreux exemples d'utilisation de l'intention, tels que la signature d'un portefeuille multi-signatures, le concept de clé de session qui accorde à un tiers des autorisations d'exécution spécifiques et des limites de temps, ou un mécanisme de transaction de correspondance en lot tel que CowSwap. Même dans le monde Web2, il y a des traces d'intention, comme les moteurs de recherche (je saisis ce que je veux interroger, et le moteur de recherche trouve des informations pertinentes pour moi à travers divers canaux) ou le tir en ligne de commerce électronique (je saisis ce que je veux acheter). Quelque chose, l'entreprise de commerce électronique l'a trouvé à travers divers canaux et me l'a livré). C'est juste que le mot Intention est récemment devenu populaire dans le monde Web3.

Conseil de lecture 2: En anglais, le mot Impératif ("impératif") est utilisé pour décrire l'expérience de l'utilisation de Transaction, qui consiste à émettre une commande complète pour atteindre l'objectif; tandis que le mot "Déclaratif" ("déclaration") est utilisé pour décrire l'expérience de l'utilisation de l'Intention. Descriptif, indiquant qu'il est utilisé en énonçant les conditions d'exécution et les résultats de l'exécution.

Intention dans le monde inter-chaînes

Dans les applications inter-chaînes telles que les ponts inter-chaînes et les DEX inter-chaînes, parce que deux chaînes ou plus sont impliquées, les utilisateurs doivent traiter avec plus de transactions sur des chaînes différentes.

À l'exclusion des applications inter-chaînes par le multi-signature de la partie projet, cela peut offrir une meilleure expérience utilisateur (par exemple, après que l'utilisateur envoie une transaction sur la chaîne source, le multi-signature de la partie projet enverra automatiquement les actifs à l'utilisateur sur la chaîne cible) L'adresse spécifiée ne nécessite pas que l'utilisateur effectue des opérations sur la chaîne cible). D'autres applications inter-chaînes plus décentralisées telles que Nomad et Succinct n'offrent pas une expérience aussi bonne. Les utilisateurs peuvent avoir besoin d'envoyer des transactions à la chaîne cible pour compléter l'opération.

Par conséquent, l’amélioration de l’expérience utilisateur que l’intention peut apporter est encore plus importante et urgente dans le monde cross-chain.

Grâce à l'intention, les opérations cross-chain ne nécessiteront que la signature des utilisateurs, et ils n'auront plus à se soucier des règles et des détails de transaction de chaque chaîne. Les utilisateurs pourront opérer sur différentes chaînes avec la même expérience utilisateur, et ne percevront même pas le fait qu'il existe des chaînes différentes.

ÉLÉGANT

Le nom complet de SUAVE est Single Unifying Auction for Value Expression, le but est de devenir un marché MEV unifié sur plusieurs chaînes. Dans ce marché, les utilisateurs peuvent exprimer les conditions de clôture et les récompenses d'une transaction de manière efficace. En même temps, les exécuteurs (Executors) vont rivaliser les uns avec les autres, et coopéreront efficacement pour répondre aux demandes des utilisateurs.

SUAVE peut servir de pool de transactions pour une blockchain et agir également en tant que rôle de Builder responsable de la production de contenu de bloc de cette blockchain. Cependant, SUAVE n'est pas destiné à remplacer le pool de transactions existant et la fonctionnalité de Builder d'une blockchain, mais plutôt à se connecter de manière transparente à une blockchain existante de manière plug and play.

Une fois que SUAVE est connecté à une blockchain, la blockchain équivaut à disposer d’un Builder décentralisé, très professionnel et puissant qui s’étend sur plusieurs sources de transactions blockchain. Le fait d’avoir plusieurs sources de transactions blockchain en même temps offrira d’énormes avantages sur le marché des MEV inter-domaines qui se développera progressivement à l’avenir. Les constructeurs ayant cet avantage seront plus compétitifs que les constructeurs opérant sur une seule chaîne.

De Flashbot à MEV-Boost à SUAVE

De Flashbot à MEV-Boost, l'esprit qu'ils incarnent est de reconnaître l'existence de MEV et de s'efforcer de mettre en avant les activités économiques cachées. Leur objectif est d'établir un marché public où tout le monde peut participer, afin d'éviter le scénario où quelques individus contrôlent et dominent silencieusement cet immense intérêt économique, conduisant progressivement à la concentration des ressources entre leurs mains et impactant finalement la décentralisation et la sécurité de l'ensemble du réseau blockchain.

Mais à mesure que les gens en apprennent de plus en plus sur le MEV, ils réalisent progressivement que, en plus du marché mature du MEV sur Ethereum, il existe également des marchés transfrontaliers et transfrontaliers du MEV. Ce marché transfrontalier du MEV sera beaucoup plus important que celui d'Ethereum, et les transactions transfrontalières auront plus d'opportunités pour extraire le MEV que les transactions sur la même chaîne.

Si quelqu'un comme Flashbot n'avait pas été là pour exposer le marché MEV inter-chaînes, le mettre en lumière et permettre une participation équitable pour tous, les quelques individus qui exploitent le MEV inter-chaînes auraient encore plus d'avantages, ce qui finirait par affecter la sécurité de l'ensemble du réseau blockchain.

Un autre phénomène qui affectera la centralisation et la sécurité est le Flux d'Ordre Privé : les transactions des utilisateurs ne circulent plus vers le pool de transactions public, mais directement vers le Chercheur ou le Constructeur. Le Flux d'Ordre Privé peut provenir du Chercheur ou du Constructeur achetant le droit de gagner des revenus à partir des transactions des utilisateurs, ou du Constructeur proposant des services attractifs, tels que (1) l'annulation gratuite des transactions ou des ordres DEX envoyés par les utilisateurs, ou (2) la fourniture de la Pré-Confirmation, avant que la transaction ne soit reçue, l'utilisateur est assuré de la rapidité avec laquelle la transaction sera reçue, de sorte que l'utilisateur n'ait pas à se soucier de la réception de la transaction et du temps nécessaire pour la recevoir.

Bien que le flux de commandes privé puisse bénéficier initialement aux utilisateurs, à long terme, il entraînera une centralisation. Les Chercheurs/Constructeurs avec un flux de commandes privé auront un avantage concurrentiel et obtiendront plus d'avantages par rapport à ceux qui n'en ont pas, ce qui aura un impact préjudiciable sur la concurrence. De plus, étant donné qu'il n'y a pas d'incitation à partager le flux de commandes privé avec de nouveaux Chercheurs/Constructeurs, ces nouveaux venus seront désavantagés au démarrage du jeu.

Pourquoi les blocs des transactions de l'utilisateur vers le Bundle créé par le Searcher doivent-ils être collectés via Private Order Flow ? C'est parce que les contenus des transactions et du Bundle sont publics et non chiffrés. S'ils sont vus et obtenus par d'autres, cela peut nuire à l'utilisateur ou au Searcher. Par exemple, d'autres peuvent extraire le MEV de la transaction de l'utilisateur via une attaque en pince ou démanteler le Bundle, en arrachant le MEV. C'est pourquoi les utilisateurs et les Searchers doivent actuellement faire confiance au Builder, car ils doivent remettre le contenu original de la transaction et du Bundle au Builder et faire confiance au fait que le Builder ne causera aucun dommage.

L'émergence de SUAVE vise à résoudre les risques de centralisation causés par le MEV et le flux d'ordres privés transfrontaliers.

Tout d’abord, en établissant un marché public qui sert des MEV inter-chaînes, les utilisateurs ou les chercheurs peuvent exprimer leurs conditions de revenus pour les transactions ou les forfaits sur ce marché. Par exemple, si un utilisateur a deux transactions qui doivent être acheminées vers Ethereum et Arbitrum respectivement, et que les deux transactions doivent être incluses et exécutées avant un certain temps, il peut spécifier ces conditions sur le marché. Les Exécuteurs sur le marché (qui peuvent être des Chercheurs ou des Bâtisseurs) seront en concurrence pour répondre à ces demandes afin de gagner des récompenses. Mais comment les utilisateurs ou les internautes peuvent-ils avoir confiance en lançant leurs transactions ou leurs offres groupées sur ce marché public ? C’est là qu’intervient la technologie de protection de la vie privée. En cryptant les transactions, les utilisateurs ou les chercheurs n’ont plus à s’inquiéter des dommages potentiels causés par d’autres personnes qui consultent leurs transactions. Ce n’est qu’avec la confidentialité des transactions qu’un flux d’ordres ouvert peut être possible.

SUAVE propose en outre le concept de Confidentialité Programmable, permettant aux utilisateurs ou aux chercheurs de choisir s'ils souhaitent divulguer des parties spécifiques des transactions ou des contenus regroupés (comme l'adresse du contrat d'exécution de la transaction) au lieu de se limiter à choisir entre un cryptage complet ou aucun cryptage.

Par rapport aux transactions entièrement cryptées, les transactions qui divulguent des informations spécifiques peuvent être incorporées plus efficacement et rapidement dans des bundles ou des blocs, et même recevoir des pots-de-vin, comme détaillé dans la section MEV-Share du quatrième article. En divulguant des informations spécifiques, les Searchers peuvent même collaborer les uns avec les autres. Le Searcher B peut construire sur la base du bundle du Searcher A : le bundle du Searcher A suit la transaction de l'utilisateur pour l'arbitrage, et le bundle du Searcher B suit le bundle du Searcher A pour l'arbitrage. La confidentialité est essentielle pour un flux de commandes ouvert. La confidentialité permet aux Searchers de coopérer les uns avec les autres, se bénéficiant mutuellement plutôt que de rivaliser pour les opportunités MEV.

Autres avantages de SUAVE

• Grâce à SUAVE, les transactions DEX inter-chaînes peuvent obtenir de meilleurs prix, et les Intentions inter-chaînes peuvent être exécutées de manière plus efficace.
• Si SUAVE est considéré comme un Builder énorme mais décentralisé, il aura plus d'avantages qu'un Builder centralisé car il rassemble plus de Flux de Commandes, ce qui peut également attirer plus de Builders à rejoindre SUAVE, et peut en outre réduire les risques causés par la centralisation des Builders.
• Grâce à SUAVE, chaque chaîne n'a pas à construire sa propre piscine de transactions privées et son propre marché MEV de la chaîne, et peut concentrer ses ressources et son énergie sur la résolution d'autres problèmes ou la fourniture de meilleurs services.

L’architecture SUAVE

Tableau d'affichage des préférences utilisateur

SUAVE peut être décrit comme un « tableau d’affichage des préférences de l’utilisateur ». Le terme « utilisateur » ici ne fait pas nécessairement référence aux utilisateurs généraux de la blockchain, mais les chercheurs peuvent également être des utilisateurs de SUAVE. Dans ce qui suit, « Utilisateur » fera référence aux utilisateurs généraux de la blockchain, et « Utilisateur SUAVE » fera référence aux utilisateurs de SUAVE.

La préférence de l'utilisateur de SUAVE est comme une intention spécialisée qui se concentre sur le tri des transactions. Ce n'est pas comme les intentions générales que les lecteurs peuvent voir ailleurs, qui peuvent spécifier diverses conditions. Tout comme les utilisateurs spécifient des préférences et des conditions dans les intentions, dans les Préférences, les utilisateurs de SUAVE spécifient des préférences ou des conditions pour "les transactions ou les revenus de bundle entrant dans le bloc," telles que :

• "Je veux que ma transaction soit triée avant la transaction 0xabcd et soit incluse avant le bloc 110050." En fait, c'est tout comme les conditions spécifiées par le Bundle of Searcher lors de l'utilisation de Flashbot.
• « Je veux que mon Bundle soit inclus et me rapporte 0,05 ETH de revenus. »
• « Je veux que l’intention A et l’intention B soient incluses dans le bloc 1001 de la chaîne X et le bloc 50900 de la chaîne Y respectivement. »

Conseil de lecture : Les utilisateurs peuvent également envoyer des transactions blockchain générales (sans spécifier de préférence) à SUAVE, c'est-à-dire simplement utiliser SUAVE comme pool de trading général ou Flashbot, comme envoyer directement ses transactions de transfert ETH ou transactions Uniswap à SUAVE.

Bien sûr, si vous spécifiez simplement des conditions, il n'est pas nécessaire de concevoir une nouvelle architecture pour cela, il suffit d'utiliser le Flashbot d'origine. Ainsi, en fait, les préférences spécifiées dans SUAVE doivent être assorties de récompenses, sinon personne ne sera prêt à compléter vos préférences de manière inconditionnelle. Bien sûr, la condition préalable au paiement doit être que les préférences aient été satisfaites.

En transformant la désignation des préférences et les récompenses en contrats intelligents à remplir, les parties demandées (telles que les utilisateurs ou les chercheurs) seront en mesure de présenter des exigences de préférence plus détaillées et diverses, et ces exigences sont satisfaites par des incitations économiques plutôt que de compter sur la gentillesse du constructeur.

• « Je veux que ma transaction soit triée avant la transaction 0xabcd et soit incluse avant le bloc 110050. Si cela est réalisé, je vous donnerai 3 ETH. »
• "Je veux que mon Bundle soit inclus et me rapporte 0,05 ETH de revenus. S’il est atteint, je vous donnerai 0,02 ETH.
• "Je veux que l'intention A et l'intention B soient incluses respectivement dans le 1001ème bloc de la chaîne X et le 50900ème bloc de la chaîne Y. Si cela est réalisé, je vous donnerai 1,8 ETH".

Architecture

SUAVE peut être considéré comme étant composé de trois composantes : Environnement de préférence, Marché d'exécution et Construction de blocs décentralisée.

• L'environnement de préférence est un endroit qui accueille les préférences de l'utilisateur et les récompenses de diverses chaînes, y compris la chaîne SUAVE et son pool de transactions. L'utilisateur SUAVE peut être un utilisateur général ou un chercheur.
• Le marché d'exécution est un groupe d'exécuteurs professionnels qui trouvent et exécutent les préférences des utilisateurs (en exécutant les préférences des utilisateurs en les regroupant en bundles) pour gagner des récompenses. L'exécuteur peut être un chercheur ou un constructeur
• La construction de blocs décentralisée est le processus d'assemblage de plusieurs bundles en blocs pour une ou plusieurs chaînes.

△ Le PE à gauche rassemble les intentions et les transactions d'arbitrage sur différentes chaînes, puis les exécuteurs au milieu tentent de satisfaire ces préférences et de les regrouper en bundles, et remettent ces bundles au rôle à droite qui a le droit de produire des blocs pour assembler les blocs. Source de l'image :https://writings.flashbots.net/the-future-of-mev-is-suave

SUAVE aura sa propre chaîne et son propre pool de transactions. SUAVE appelle la chaîne Layer de règlement et le pool de transactions Layer de messagerie.

Les contrats intelligents peuvent être déployés sur la chaîne pour établir des contrats entre Préférence et récompenses. Le pool de transactions sera rempli de transactions dans lesquelles l'utilisateur SUAVE déclare sa préférence et l'exécuteur reçoit des récompenses.

Le cycle de vie d'une transaction SUAVE

1. Expression de préférence: L'utilisateur SUAVE spécifie la préférence et fait des offres pour un ou plusieurs de ses intentions/transactions.
2. Optimisation de l'exécution : l'exécuteur trouve un chemin d'exécution qui satisfait les préférences de l'utilisateur, et peut même trouver le chemin optimal pour cela.
3. Règlement de préférence : Le ou les bundles de l'Exécuteur sont inclus avec succès dans le bloc de la chaîne cible et répondent à la préférence spécifiée par l'utilisateur SUAVE.
4. Règlement des paiements : Oracle renvoie l'état de la chaîne cible à la chaîne SUAVE, et l'Exécuteur exécute le contrat intelligent. Après que le contrat confirme que la Préférence a été satisfaite, la récompense de l'Utilisateur SUAVE est donnée à l'Exécuteur.

△ Préférence quatre étapes de l'établissement à l'exécution au règlement. Source de l'image :https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

MEVM

SUAVE doit être capable d'écrire la Préférence dans un langage de programmation et de le convertir en smart contract afin de remplir le contrat entre l'Utilisateur SUAVE et l'Exécuteur. SUAVE est censé concevoir un EVM spécifique à la MEV basé sur l'EVM - MEVM.

MEVM ajoutera un nouveau contrat Precompile et un type de transaction spécifiquement pour MEV. Les fonctions de Préférence de l'utilisateur, d'Emballage de Bundle et de Construction de Bloc peuvent toutes être facilement réalisées dans MEVM.

Le code du programme d'exemple dans la figure ci-dessous écrit l'algorithme de construction de bloc de prix du gaz efficace (EGP) en utilisant Solidity et des contrats MEVM Precompile.

Le tri des Bundles de construction de blocs EGP est effectué selon le Prix du Gaz donné par chaque Bundle. Les Bundles avec un Prix du Gaz plus élevé seront classés en tête du bloc :

△ La fonction rose dans l'image est la fonction de précompilation de MEVM, spécialement conçue pour une utilisation MEV. Source de l'image :https://writings.flashbots.net/mevm-suave-centauri-and-beyond

Conseil de lecture : L'exécution de l'algorithme de construction de blocs ne se produit pas réellement sur la chaîne SUAVE, mais le constructeur de blocs simule l'exécution hors chaîne (tout comme le nœud simulera l'exécution d'une transaction localement), donc ce processus d'exécution ne deviendra pas vraiment une transaction qui occupe l'espace de bloc et les ressources informatiques de la chaîne SUAVE, et ne sera pas limité par les performances de sortie de la chaîne SUAVE.

Grâce à la composabilité du contrat EVM, Searcher et Searcher ou Searcher et Builder pourront coopérer à travers des contrats, remplaçant la relation de confiance unilatérale originale. La coopération améliorera également l'efficacité du Bundle et permettra d'extraire davantage de MEV, ce qui peut profiter à chaque participant de la chaîne d'approvisionnement en MEV. De plus, les participants peuvent directement utiliser des outils de développement basés sur l'EVM et des infrastructures, tels que le fournisseur RPC, des outils de test comme Foundry, etc., et l'expérience de développement sera très bonne.

De plus, MEVM fournira la fonction de confidentialité des transactions, car sans confidentialité, il n'y a aucune possibilité de coopération. Sans confidentialité, les chercheurs doivent craindre que leur MEV soit volé. Au stade initial, cette confidentialité sera réalisée grâce au matériel de confiance SGX. La transaction sera chiffrée puis envoyée à SGX pour exécution. On croit que SGX exécutera son code de programme désigné sans voler le MEV à volonté. À l'avenir, lorsque d'autres technologies cryptographiques avancées mûriront progressivement, la cryptographie pourra être utilisée pour remplacer le matériel de confiance. Pour plus de détails, veuillez vous référer à l'article précédent surMempools cryptées.

Conseil de lecture : Cependant, il existe également des inconvénients basés sur l'EVM, tels que l'EVM est trop expressif : En fait, pour écrire les fonctions requises par MEV, vous n'avez pas besoin de nombreux opcodes dans l'EVM. Autoriser l'utilisation de ces opcodes peut permettre à des personnes désireuses d'écrire des exécutions très complexes, puis de laisser la transaction échouer à la fin de l'exécution, ce qui entraîne le gaspillage d'une multitude de ressources informatiques par le nœud, constituant une attaque par déni de service (DoS). Le projet Anoma redessine un langage de programmation et un environnement d'exécution spécifiquement pour exprimer et exécuter des intentions. À l'avenir, SUAVE pourrait également utiliser l'architecture d'Anoma pour remplacer le MEVM.

Plug-N-Play SUAVE

Si le développeur de bloc ou le validateur d'une chaîne connaît l'existence de SUAVE et a l'intention d'utiliser SUAVE, alors il considérera SUAVE comme un constructeur de blocs. Si SUAVE propose un prix d'enchère plus élevé pour les blocs qu'il construit, alors les mineurs ou les validateurs utiliseront les blocs de SUAVE. En prenant le MEV-Boost actuel sur Ethereum comme exemple, les blocs composés par SUAVE seront convertis en un format conforme au mécanisme d'enchères MEV-Boost grâce au plug-in fourni par SUAVE. Le proposant n'a pas besoin de faire de changements pour adopter les blocs de SUAVE.

Si le développeur de bloc ou le validateur d'une chaîne ne connaît pas l'existence de SUAVE, alors l'exécuteur de SUAVE fera une offre pour recevoir son Bundle selon les règles de frais de la chaîne.

Défis de MEV cross-chain

Chaque chaîne a son propre développeur de blocs et validateur. Le bloc B1 de SUAVE reçu par la chaîne X ne signifie pas que le bloc B2 sera également reçu avec succès par le validateur de la chaîne Y. Les mécanismes de production de blocs et les marchés de la chaîne X et de la chaîne Y sont indépendants. À moins que la chaîne X et la chaîne Y n'utilisent un Séquenceur partagé, et que le même Séquenceur produise des blocs pour les deux chaînes en même temps, alors seulement en combinant SUAVE, nous pouvons garantir l'Inclusion Atomique : les deux chaînes ne doivent pas “collecter des transactions spécifiées (ou des blocs) ensemble”. Yuan)”, ou “aucun revenu du tout”.

Et même si le séquenceur partagé peut garantir l'inclusion atomique, cela ne signifie pas que la transaction sera exécutée avec succès après avoir été incluse. Si les deux transactions ne sont pas exécutées avec succès, cela signifie que le MEV inter-chaîne a échoué. En supposant qu'un utilisateur de SUAVE souhaite effectuer une arbitrage inter-chaîne, les transactions sur les deux chaînes doivent être générées en temps réel et exécutées avec succès avant qu'il puisse en bénéficier :

• Si l'utilisateur SUAVE ne souhaite pas supporter le risque d'échec de l'exécution de la transaction, alors sa préférence exigera que les deux transactions doivent être exécutées avec succès avant d'être complétées, puis l'exécuteur sera payé et celui-ci assumera le risque. Il peut contraindre le "résultat de l'exécution réussie" en spécifiant le statut sur la chaîne, par exemple, en spécifiant qu'un contrat doit émettre un événement spécifique, ou en spécifiant de combien le solde de jetons d'une certaine adresse doit être supérieur. Ensuite, l'exécuteur qui est prêt à prendre des risques essaiera de rendre les deux transactions en temps réel et exécutées avec succès. Si l'une d'entre elles est seulement reçue ou si l'exécution de l'une des transactions "échoue", l'exécuteur ne recevra pas la récompense.
• Si l'utilisateur SUAVE est prêt à prendre des risques, alors sa préférence peut simplement exiger que les deux transactions soient reçues, et il est également acceptable si l'exécution de la transaction échoue (c'est-à-dire la réversion de la transaction). L'exécuteur essaiera toujours de mener à bien les deux transactions (une exécution réussie pouvant entraîner une récompense plus élevée), mais tant qu'il y a des revenus, vous pouvez obtenir la récompense.

En prenant l'image ci-dessous comme exemple, l'utilisateur SUAVE souhaite effectuer une arbitrage de transaction cross-chain entre Rollup 1 et Rollup 2 : acheter un ETH à un prix plus bas sur Rollup 1, et vendre un ETH à un prix plus élevé sur Rollup 2.

Si les deux transactions sont payées en temps réel et exécutées avec succès, l'utilisateur SUAVE peut gagner la différence de prix. Les scénarios 1 et 2 dans le tableau de l'image sont respectivement "l'utilisateur SUAVE est prêt à assumer le risque lui-même" et "l'exécuteur est prêt à assumer le risque".

Les trois dernières colonnes du tableau sont «récompenses pour les deux succès», «récompenses pour un seul succès» et «résultat final pour un seul succès» :

• Récompenses pour les deux transactions réussies (l'utilisateur SUAVE gagne la différence de prix) :
  • Scénario 1 : L'utilisateur SUAVE paie des frais de manutention de 50 $ à l'Exécuteur.
  • Scénario 2: L'utilisateur SUAVE paie des frais de traitement de 70 $ à l'Exécuteur (plus cher car l'Exécuteur supporte le risque).
• Il n'y a qu'une seule récompense pour le succès (l'utilisateur SUAVE n'a pas gagné le spread) :
  • Scénario 1 : L'utilisateur SUAVE paie des frais de gestion de 25 $ à l'exécuteur. Les utilisateurs SUAVE absorbent eux-mêmes les risques.
  • Scénario 2 : L’utilisateur SUAVE n’a pas à payer de frais ni à prendre de risques.
• Il n'y a qu'un seul résultat réussi (l'utilisateur SUAVE n'a pas gagné l'écart):
  • Scénario 1: L'utilisateur SUAVE paie des frais de traitement de 25 $ à l'exécuteur et a un ETH supplémentaire en main.
  • Scénario 2: L'utilisateur SUAVE n'a pas à payer de frais de traitement à l'exécuteur et n'aura pas de ETH supplémentaire en main. Et l'exécuteur a un ETH de plus en main.

△ Différents résultats d'exécution selon les situations. Source de l'image :https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

La MEV inter-chaînes nécessite que les exécuteurs disposent de capital, soient prêts à prendre des risques et aient une technologie suffisante pour garantir des revenus atomiques en temps réel et une exécution réussie. Il peut s'agir d'un travail lucratif mais relativement à haut niveau de barrière.

Pourquoi SUAVE a-t-il besoin de sa propre chaîne ?

Pourquoi ne pouvons-nous pas simplement transférer et partager les préférences via le réseau P2P ? Parce qu’un réseau P2P pur ne peut pas empêcher le réseau d’être rempli d’innombrables préférences (c’est-à-dire des attaques DoS). S’il s’agit d’une chaîne, les attaques par déni de service peuvent être évitées grâce à des frais de gestion.

Pourquoi SUAVE n'utilise-t-il pas la chaîne existante? Parce que SUAVE a besoin de sa propre fonction (MEV) et de ses propres paramètres de chaîne tels que le temps de bloc et la taille de bloc. Si vous le construisez directement sur Ethereum, vous rencontrerez des problèmes tels que des coûts trop élevés, un temps de bloc trop long et des fonctions limitées.

De plus, comme SUAVE doit obtenir des informations provenant d'autres chaînes pour vérifier si la Préférence est satisfaite, une Chaîne SUAVE indépendante peut maintenir sa neutralité en recueillant des informations de toutes les autres chaînes.

Cependant, SUAVE a sa propre chaîne, ce qui signifie également que (1) L'utilisateur de SUAVE peut avoir besoin de transférer des actifs d'autres chaînes vers la chaîne SUAVE pour utiliser SUAVE, et (2) SUAVE doit compter sur Oracle pour rapporter des informations provenant d'autres chaînes. Cela signifie que SUAVE lui-même a une exigence de confiance supplémentaire pour Oracle. Si Oracle n'est pas sécurisé, cela affectera la sécurité du contrat sur SUAVE.

Conseil de lecture : Il n'y a pas encore beaucoup de détails sur le fait que SUAVE aura sa propre jeton, sur le fait que les actifs doivent être transférés à la Chaîne SUAVE pour être utilisés, ou sur la manière de transférer vers la Chaîne SUAVE. Il est seulement mentionné dans la vidéo et l'article que "L'utilisateur SUAVE doit d'abord transférer des actifs d'autres chaînes vers la Chaîne SUAVE avant de pouvoir l'utiliser."

Le modèle de conception et de sécurité de SUAVE Chain lui-même est encore en discussion. Si SUAVE Chain est un Rollup sur Ethereum, vous pouvez directement utiliser le mécanisme Rollup pour transférer des actifs et lire d'autres informations Rollup. Ce sera mieux que de compter sur d'autres rollups. La technologie inter-chaînes et les services Oracle apportent beaucoup de sécurité.

Si le validateur de la chaîne SUAVE peut être combiné avec Eigenlayer, il sera plus sûr et plus fiable d'utiliser directement le validateur Ethereum en tant que validateur de la chaîne SUAVE que de générer un ensemble de validateurs par SUAVE lui-même. Mais bien sûr, ces conceptions ont également des inconvénients correspondants. Pour plus de discussion sur la conception de la chaîne SUAVE, veuillez vous référer à cet article.

Résumé des défis de SUAVE

• Temps de bloc de la chaîne SUAVE : Le temps de bloc de la chaîne SUAVE doit être suffisamment court pour que l'utilisateur SUAVE puisse déclarer sa préférence à l'Exécuteur pour le voir. Si le temps de la chaîne SUAVE est plus long que la chaîne à laquelle elle est connectée (comme Solana ou d'autres Rollup), il est facile pour l'utilisateur SUAVE de ne pas avoir le temps de faire savoir à l'Exécuteur SUAVE qu'il souhaite que la transaction soit incluse dans le prochain bloc d'une certaine chaîne. Un bloc a été produit.
• Risque Oracle : Oracle est responsable de fournir des informations sur d'autres chaînes, et peut également être responsable du transfert des actifs de l'utilisateur SUAVE vers la chaîne SUAVE, donc l'importance d'Oracle n'est pas négligeable.
• Expérience d'utilisation inter-chaînes : L'utilisateur de SUAVE doit transférer des actifs à la chaîne SUAVE, ce qui est également un inconvénient en termes d'expérience d'utilisation.
• Modèle économique : SUAVE a-t-il besoin d'émettre ses propres actifs, comment inciter le validateur SUAVE, comment empêcher le mécanisme d'incitation économique de SUAVE d'affecter la sécurité économique d'autres chaînes, etc.
• Technologie de confidentialité : À court terme, SUAVE devra s'appuyer sur du matériel de confiance tel que SGX pour fournir des fonctions de confidentialité des transactions, mais à long terme, il devra passer à une approche plus décentralisée et sécurisée pour réduire les risques.
• Langue de préférence appropriée : L'EVM est-elle adaptée comme moyen d'exprimer et d'exécuter des préférences ?

Résumé et points saillants

• L'émergence de SUAVE vise à (1) résoudre le risque de centralisation causé par la différence d'avantages des Constructeurs pouvant résulter de MEV entre domaines, et (2) ouvrir la voie à la collaboration entre Chercheurs / Constructeurs grâce à l'introduction de la confidentialité programmable, réduisant ainsi le risque de centralisation pouvant découler du Flux d'Ordres Privés.
• Les transactions entièrement privées rendent le travail des chercheurs difficile, car ils ne peuvent pas efficacement rétrograder les transactions des utilisateurs, ce qui conduit à une efficacité on-chain réduite. Cependant, les utilisateurs n'ont pas à choisir entre la "confidentialité" et l'"efficacité". Au lieu de cela, ils peuvent utiliser la confidentialité programmable pour choisir de divulguer des informations partielles, rendant le travail des chercheurs plus facile et améliorant l'efficacité on-chain et les récompenses de rétro-ingénierie.
• Avec SUAVE, les utilisateurs de SUAVE peuvent spécifier leurs intentions/préférences de transactions et diverses conditions, tandis que le reste est géré par des exécuteurs professionnels pour atteindre les conditions et réclamer les récompenses promises par les utilisateurs de SUAVE à leur réalisation.
• SUAVE aura sa propre chaîne car le P2P pur ne peut pas empêcher les attaques par déni de service, et SUAVE aura ses propres caractéristiques et paramètres uniques pour la chaîne (MEV), de sorte que les chaînes existantes ne peuvent pas être directement utilisées. Cette chaîne sera basée sur une modification EVM, ajoutant les fonctionnalités nécessaires pour MEV, appelées MEVM.
• Le MEV inter-chaînes est une opération très complexe, car elle nécessite de garantir l'inclusion atomique et de garantir l'exécution réussie des transactions. Les utilisateurs de SUAVE peuvent spécifier des états pour exiger que les transactions doivent être exécutées avec succès avant de récompenser l'exécuteur, transférant ainsi le risque à l'exécuteur. Le séquenceur partagé peut garantir l'inclusion atomique mais ne garantit pas que les transactions seront exécutées de manière « réussie ».
• Le fait que SUAVE soit sa propre chaîne signifie également que les utilisateurs de SUAVE doivent transférer des actifs vers la chaîne SUAVE avant de pouvoir utiliser SUAVE. De plus, un Oracle sécurisé est nécessaire pour rapporter des informations provenant d'autres chaînes à la chaîne SUAVE afin de vérifier si les préférences sont satisfaites.
• SUAVE doit encore relever de nombreux défis techniques et de conception, tels que l'Oracle sécurisé, les techniques de confidentialité sécurisées, le langage de préférence et les modèles économiques, entre autres.

Avertissement：

1. Cet article est repris de [ imToken Labs]. Tous les droits d'auteur appartiennent à l'auteur original [Nic]. If there are objections to this reprint, please contact the Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdite.