Valeur Extractible par les Mineurs (MEV) et Argent Programmable : Le Bon, le Mauvais et le Laid
Blockstream Research

Valeur Extractible par les Mineurs (MEV) et Argent Programmable : Le Bon, le Mauvais et le Laid

Kiara Bickers
Kiara Bickers

Le cœur du modèle de sécurité de Bitcoin repose sur cette théorie des jeux fondamentale : les mineurs, armés de leurs pioches numériques, sont dans une course incessante pour le profit. Et c'est cette quête qui maintient le réseau sécurisé. Le minage de base implique la production de blocs pour gagner les récompenses de bloc et les frais de transaction, mais avez-vous déjà envisagé que les mineurs pourraient avoir d'autres moyens d'extraire de la valeur de la blockchain au-delà de ce processus de minage standard ? Y a-t-il d'autres voies de profit sur la blockchain où les mineurs peuvent tirer parti de leur position unique en tant que validateurs ?

Qu'est-ce que la MEV ?

Dans les systèmes de preuve de travail, la "Miner Extractable Value" (MEV) est un terme qui décrit les profits que les mineurs peuvent réaliser en manipulant la manière dont les transactions sont prioritaires, exclues, réarrangées ou modifiées dans les blocs qu'ils minent. Cependant, depuis la mise à jour d'Ethereum vers Ethereum 2.0, qui a déplacé le réseau vers la preuve d'enjeu, le concept de MEV a pris un nouveau nom et est maintenant appelé "Maximal Extractable Value" dans les systèmes de preuve d'enjeu. Dans ce contexte, ce sont les proposeurs de blocs au lieu des mineurs - qui sont les validateurs - qui ont l'opportunité d'extraire cette valeur.

Les mineurs (ou validateurs dans Ethereum) ont un rôle spécial dans ces réseaux en confirmant les transactions dans les blocs. Leur position les place un pas en avant des autres utilisateurs et leur permet de déterminer l'ordre final des transactions dans la chaîne. À l'intérieur d'un bloc, les transactions sont généralement ordonnées avec les frais les plus élevés en haut, mais de temps en temps, des opportunités s'ouvrent permettant aux mineurs de réaliser un profit supplémentaire en modifiant stratégiquement l'ordre des transactions à leur avantage.

Vous pourriez penser, quel est le mal à laisser les mineurs prendre un peu de profit supplémentaire ? Les préoccupations commencent à apparaître lorsque certains de ces mineurs, ceux équipés de capacités analytiques plus avancées et d'une puissance de calcul plus élevée, peuvent identifier et exploiter les opportunités de profit MEV plus efficacement que d'autres.

Ces opportunités peuvent ne pas toujours être faciles à repérer, mais plus il est possible d'extraire de la valeur en analysant la chaîne, plus l'incitation est forte pour les équipes de recherche équipées de bots pour faire ce travail. Avec le temps, cette disparité dans la capacité de profit des mineurs crée une tendance à la centralisation au sein du réseau. Finalement, cela sape le principe fondamental de la blockchain : la décentralisation.

C'est exactement le scénario que la communauté des développeurs de Bitcoin cherche à éviter en envisageant comment mieux gérer plus d'expressivité sur Bitcoin.

Pourquoi voulons-nous de l'argent programmable ?

Historiquement, Bitcoin a fonctionné avec des contrats intelligents relativement simples. Cependant, ce modèle a du mal avec des transactions même modérément complexes. Bitcoin Script ne peut valider que les données d'authentification, il n'a pas la capacité d'imposer des limites de vitesse sur les transactions ou de définir des destinations de pièces parce que Bitcoin Script n'a pas accès aux données des transactions.

Comme problème quelque peu distinct, travailler avec et écrire des contrats intelligents Bitcoin peut être difficile pour les utilisateurs qui ne comprennent pas pleinement ses exigences de sécurité. Une fonctionnalité proposée, connue sous le nom de "coffres", vise à résoudre certains de ces points douloureux en introduisant des conditions de verrouillage temporel pour les transactions. Essentiellement, les coffres pourraient servir de "trappe d'urgence", permettant aux utilisateurs de récupérer leurs fonds en cas de compromission des clés privées. Mais des fonctionnalités comme celle-ci ne sont possibles qu'avec plus d'expressivité.

Ethereum est largement reconnu pour ses capacités de script très expressives, mais il lutte également avec le problème de la MEV. La plupart des utilisateurs supposent généralement que Bitcoin n'a pas de MEV, contrairement à Ethereum, qui est considéré comme un territoire sauvage pour cela. Mais est-ce toute l'histoire ?

Est-ce que des contrats intelligents plus expressifs incitent automatiquement à plus de scénarios de MEV ?

Il y a plusieurs facteurs qui contribuent à la MEV : (1) la transparence du mempool, (2) la transparence des contrats intelligents, et (3) l'expressivité des contrats intelligents. Chacun de ces facteurs ouvre de nouvelles voies pour la MEV ; nous examinerons chacun d'eux ici.

Le Mauvais : (1) Transparence du Mempool

Comme le mempool de Bitcoin, les mempools de la plupart des blockchains sont entièrement transparents, ouverts et visibles, de sorte que tout le monde peut voir quelles transactions sont en attente avant d'être validées et confirmées dans un bloc. Les blocs de Bitcoin prennent généralement environ 10 minutes à trouver, ce qui donne théoriquement aux mineurs le même temps pour profiter et devancer.

En pratique, sur Bitcoin, ce n'est pas une source de MEV pour quelques raisons : (1) les transactions Bitcoin sont assez simples pour qu'aucun mineur n'ait un avantage analytique significatif sur les autres mineurs, et (2) les transactions Bitcoin ne réalisent généralement pas de transactions multi-actifs telles que des swaps ou des échanges ouverts pouvant être devancés.

Contrastez cela avec Ethereum, qui a certaines des transactions multi-actifs les plus complexes se déroulant sur des échanges décentralisés (DEX) publics. Officiellement, le temps de bloc sur Ethereum est de 15 secondes, mais pendant les périodes de forte circulation dans le mempool, les frais de gaz requis pour une inclusion immédiate dans le bloc peuvent facilement dépasser cent dollars. En conséquence, les transactions avec des frais plus bas attendent souvent des minutes ou même des heures avant d'être incluses dans un bloc. Cela peut prolonger la fenêtre pour ces opportunités de devancement néfastes, déjà plus répandues sur Ethereum en raison de la valeur substantielle enveloppée dans les jetons de couche-2.

Le Mauvais : (2) Transparence des Contrats Intelligents

Dans Bitcoin, les "contrats intelligents" sont le mécanisme simple de verrouillage et de déverrouillage inhérent à Bitcoin Script. Les valeurs de transaction, les détails de l'expéditeur et du destinataire sont tous publiquement visibles sur la blockchain. Bien que cette transparence totale ne soit pas idéale d'un point de vue de la confidentialité, elle fait partie de la manière dont Bitcoin permet à tous les participants du réseau de vérifier l'état complet de la blockchain. Tout observateur peut analyser ces détails de contrat, ouvrant potentiellement la porte à certaines stratégies liées à la MEV.

Mais le langage de script de Bitcoin est, par conception, assez limité, se concentrant principalement sur les fonctions de base d'envoi et de réception de fonds, et de validation des transactions avec des signatures ou des verrous de hachage. Cette simplicité limite intrinsèquement la portée des stratégies de MEV sur Bitcoin, rendant ces opportunités relativement rares par rapport à d'autres chaînes.

Les plateformes comme Ethereum, Solana et Cardano ont également des contrats intelligents totalement transparents, mais elles divergent de Bitcoin en ayant également des langages de script hautement complexes et expressifs. Leurs systèmes Turing-complets rendent possible l'exécution théorique de pratiquement toute tâche computationnelle, ce qui inclut : des contrats auto-exécutants, l'intégration de données du monde réel via des oracles, des applications décentralisées (dApps), des jetons de couche-2, des swaps au sein des DEX, et des teneurs de marché automatisés (AMM). Ces éléments se combinent pour favoriser un environnement riche en opportunités de MEV. Les schémas basés sur des preuves à divulgation nulle, tels que STARKex, pourraient théoriquement éviter certains de ces problèmes, mais ce compromis viendrait avec d'autres complexités.

Le Laid : (3) Expressivité des Contrats Intelligents

Les opportunités de MEV sont si lucratives sur certaines chaînes qu'il existe des "entreprises de trading MEV" générant des "bénéfices élevés à cinq chiffres, moyens à six chiffres" par mois. Cette tendance est devenue si marquée qu'il existe des tableaux de bord publics dédiés à la recherche d'opportunités profitables sur Ethereum et Solana. Leur rentabilité est générée en exécutant l'ensemble des stratégies de MEV : devancement, trading sandwich, arbitrage de jetons, suivi, et liquidations pour n'en nommer que quelques-unes. Chaque stratégie exploitant une dynamique différente des contrats intelligents pour le profit.

Certaines de ces stratégies MEV s'appliquent à la fois à la couche-1 et à la couche-2.

Front-Running Généralisé: Les bots scannent le mempool à la recherche de transactions profitables, puis devancent la transaction originale pour un profit.

Trading Sandwich: L'attaquant passe des ordres avant et après une grande transaction pour manipuler les prix des actifs à des fins lucratives. Cette stratégie exploite le mouvement de prix prévisible causé par la grande transaction.

Ensuite, certaines stratégies sont uniques aux jetons et contrats intelligents de couche-2.

Arbitrage Entre Différents DEX: Les bots exploitent les différences de prix pour le même actif

 sur différents DEX en achetant bas sur l'un et en vendant haut sur un autre.

Back-Running dans les Courbes de Liaison DeFi: Les bots MEV profitent des hausses de prix prévisibles dans les courbes de liaison DeFi en passant des transactions immédiatement après de grandes transactions, achetant lors des tendances haussières et vendant pour le profit.

Liquidations DeFi: Les bots MEV repèrent des opportunités dans les prêts DeFi où les valeurs des garanties tombent en dessous des seuils fixés, permettant aux validateurs de prioriser leurs transactions pour acheter la garantie liquidée à des prix plus bas.

La complexité des contrats contribue de manière significative aux défis associés à la MEV.

Attaques de Réentrance: Ces attaques exploitent les failles logiques des contrats intelligents, permettant aux attaquants d'appeler à plusieurs reprises une fonction avant que la première exécution ne soit terminée, extrayant plusieurs fois des fonds. Dans le contexte de la MEV, les individus qualifiés peuvent en tirer un profit significatif, en particulier dans les contrats avec des fonds substantiels.

Contrats Interconnectés et État Global: Sur des plateformes comme Ethereum, les contrats intelligents peuvent interagir, entraînant des réactions en chaîne à travers plusieurs contrats à partir d'une seule transaction. Cette interconnexion permet des stratégies MEV complexes, où une transaction dans un contrat peut en affecter un autre, offrant une réaction en chaîne d'opportunités de profit.

Une partie du problème ici est que la valeur totale créée par les jetons et dApps construits sur la couche-2 dépasse souvent la valeur de l'actif natif de la blockchain sur la couche-1, sapant l'incitation des validateurs à sélectionner et confirmer les transactions uniquement sur la base des frais.

Pour aggraver les choses, beaucoup de ces opportunités ne sont pas strictement limitées aux validateurs du réseau. D'autres participants du réseau avec des bots de balayage MEV peuvent rivaliser pour ces mêmes opportunités, causant une congestion du réseau, augmentant les frais de gaz, et élevant les coûts de transaction. Ce scénario crée une externalité négative pour le réseau et ses utilisateurs, qui sont tous affectés par la hausse des frais de transaction, alors que la chaîne devient moins efficace et plus coûteuse à exploiter. La MEV dans DeFi est si courante que les utilisateurs l'ont presque acceptée comme une taxe invisible sur tout le monde dans le réseau.

Ces opportunités MEV émergent-elles naturellement comme un sous-produit des contrats intelligents hautement expressifs, ou existe-t-il une autre voie vers le rêve d'un argent entièrement programmable ?

À défaut d'éviter les protocoles avec des contrats intelligents hautement expressifs et des jetons de couche-2, les utilisateurs peuvent éviter certains de ces risques en utilisant des protocoles qui prennent en charge les Transactions Confidentielles, comme Liquid, qui dissimulent les détails des transactions. Mais contrairement à ces plateformes avec des langages de script plus expressifs, Bitcoin manque de la capacité de faire ce que l'on pourrait s'attendre à pouvoir faire avec de l'argent programmable.

Le Bon : Les Compromis de l'Argent Programmable

En envisageant l'évolution des contrats intelligents sur Bitcoin, les options qui nous sont offertes sont (1) de pousser la complexité hors chaîne, (2) d'intégrer prudemment des fonctionnalités de covenant étroites ou limitées, ou (3) d'adopter le chemin de l'expressivité totale. Explorons quelques-unes des propositions de chacune de ces options.

(1) Une Nouvelle Structure pour les Contrats Hors Chaîne : ANYPREVOUT

Les solutions hors chaîne, comme le Lightning Network, visent à améliorer l'évolutivité et la fonctionnalité de Bitcoin sans alourdir la chaîne principale, en gardant les transactions rapides et les frais bas. Tout cela semble bon jusqu'à présent.

SIGHASH_ANYPREVOUT (APO) est une proposition pour un nouveau type de clé publique qui permet certains ajustements à une transaction même après qu'elle soit signée. Elle simplifie la manière dont les transactions sont mises à jour, permettant aux transactions de se référer plus facilement aux UTXOs précédents, rendant les canaux du Lightning Network plus rapides, moins chers, plus sûrs et plus simples, en particulier pour résoudre les litiges.

Sous le capot, APO est un nouveau type proposé de flag sighash. Chaque transaction Bitcoin doit avoir une signature pour prouver qu'elle est légitime. Lors de la création de cette signature, vous utilisez un "flag sighash" pour déterminer quelles parties de la transaction vous signez. Avec APO, un expéditeur signerait toutes les sorties et aucune des entrées, pour engager les sorties de la transaction, mais pas spécifiquement la transaction à partir de laquelle les fonds proviendront.

APO permet Eltoo, permettant aux utilisateurs d'échanger des transactions pré-signées hors chaîne. Cependant, APO pourrait involontairement introduire de la MEV en rendant les transactions réordonnables. Dès que vous permettez une signature qui lie le graphe de la transaction, vous avez la capacité de remplacer les transactions. Les entrées peuvent être échangées, tant que les nouvelles entrées sont toujours compatibles avec la signature.

(2) Covenants : CAT + CSFS et CTV

Les covenants permettraient aux utilisateurs de contrôler où les pièces peuvent se déplacer, en imposant des limites de vitesse ou en définissant des destinations spécifiques pour les pièces dans une transaction. Il existe deux catégories différentes de covenants : récursifs et non-récursifs.

Les covenants récursifs permettent aux pièces de revenir continuellement à des covenants du même type.

Les covenants non-récursifs limitent ce contrôle à la transaction suivante, nécessitant que le chemin futur des pièces soit défini à l'avance.

CAT + CSFS est une proposition de covenant qui permet aux scripts de construire ou de définir certaines parties d'une transaction future. CHECKSIGFROMSTACK (CSFS) vérifie une signature par rapport aux données que OP_CAT a construites. En utilisant CSFS pour exiger que la signature corresponde à un format construit dynamiquement à partir d'OP_CAT, nous pouvons définir comment ces UTXOs peuvent être dépensés à l'avenir et créer un covenant récursif, bien que de manière maladroite.

OP_CHECKTEMPLATEVERIFY (CTV) est un moyen de créer des covenants non-récursifs. Au lieu de définir et de vérifier par rapport à des parties spécifiques d'une transaction, CTV restreint comment les fonds peuvent être dépensés, sans spécifier l'adresse exacte à laquelle ils doivent aller. Il définit un "modèle" que la prochaine transaction doit confirmer.

Un risque avec les covenants récursifs pourrait être de créer un scénario où les pièces doivent suivre un ensemble de règles qui se répètent encore et encore, se retrouvant piégées dans une boucle sans moyen de sortir. Un autre est que, parce que les covenants sont transparents et auto-exécutants, ils pourraient ouvrir Bitcoin à certaines des stratégies de MEV que nous voyons sur d'autres chaînes.

Quelle est la bonne nouvelle ici ?

La bonne nouvelle est que ces propositions introduisent toutes de nouvelles expressivités !

Maintenant, quelle est la quantité maximale d'expressivité que nous pouvons obtenir ?

(3) Expressivité Totale : Simplicity

Simplicity est un langage de programmation basé sur la blockchain qui diffère des autres langages de script en ce qu'il est très bas niveau. Ce n'est pas un langage sur Bitcoin Script ou un nouvel opcode à l'intérieur de celui-ci, c'est une alternative à celui-ci. Théoriquement, il est possible de mettre en œuvre toutes les propositions de covenants dans Simplicity, et de mettre en œuvre de nombreux autres contrats que les cypherpunks veulent de l'argent programmable, mais avec moins des externalités négatives d'Ethereum.

Simplicity maintient le principe de conception de Bitcoin de transactions autonomes dans lesquelles les programmes n'ont pas accès à des informations extérieures à la transaction. Conçu à la fois pour une expressivité maximale et la sécurité, Simplicity prend en charge la vérification formelle et l'analyse statique, donnant aux utilisateurs des contrats intelligents plus fiables.

Comparez Simplicity et Simfony (l'interface de Simplicity) à : (1) les propositions de covenants Bitcoin et (2) les langages de script sur d'autres blockchains :

Les propositions de covenants sur Bitcoin Script, bien que beaucoup plus simples que Simplicity, manquent d'expressivité pour gérer l'estimation des frais dans Script, en raison de l'absence de fonctions arithmétiques de Bitcoin. Il n'y a aucun moyen de multiplier ou de diviser, pas de conditionnels ou d'opcodes de manipulation de pile ; il est également très difficile d'estimer un frais raisonnable à associer à un contrat ou un covenant donné. Les utilisateurs finissent par avoir du code spaghetti, où 80% de leur logique de contrat est consacrée à essayer de déterminer quel devrait être leur taux de frais. Rendant ces contrats de covenants super compliqués et difficiles à raisonner.

L'EVM a des constructions de bouclage qui rendent l'analyse statique de l'utilisation du gaz très difficile. Alors qu'avec Script ou Simplicity, vous pouvez simplement compter chaque opcode, ou ajouter récursivement le coût de chaque fonction. Parce que Simplicity a un modèle formel, vous pouvez raisonner formellement sur le comportement du programme. Vous ne pouvez pas faire cela avec Script même si vous pouvez faire une analyse statique de l'utilisation des ressources.

Simplicity offrirait

 aux utilisateurs le plus haut degré d'expressivité, ainsi que d'autres fonctionnalités précieuses comme l'analyse statique et la vérification formelle. Les utilisateurs sont incités, bien que non restreints, à construire des contrats intelligents résistants à la MEV. De plus, une combinaison de différents contrats ensemble peut donner lieu à de la MEV, même lorsqu'individuellement ils ne le font pas. Cela représente un compromis fondamental.

L'idée de faire évoluer les fonctionnalités des contrats intelligents de Bitcoin est indéniablement prometteuse et excitante. Mais il est important de reconnaître que toutes ces propositions comportent un certain degré de risque MEV - bien que probablement pas dans la mesure que nous voyons sur d'autres chaînes. En envisageant d'apporter plus d'argent programmable à Bitcoin, il y a des questions que nous devons nous poser :

Pouvons-nous construire un protocole avec un risque MEV nul, ou est-ce un idéal inatteignable ?

Compte tenu des risques inhérents de la MEV dans de nombreuses propositions, quel niveau de risque MEV est acceptable ?

Et enfin, quelle est la proposition la plus simple qui offre le plus grand degré d'expressivité ?

Chaque proposition a son propre ensemble d'avantages et d'inconvénients. Cependant, quelle que soit la direction que nous prenons, nous devrions toujours viser à prioriser la sécurité et à respecter le principe de décentralisation.

Pour des mises à jour détaillées et plus d'informations, gardez un œil sur le fil de recherche Blockstream 𝕏.

Note : cet article a été publié à l'origine dans Bitcoin Magazine et peut être lu ici.

If you have specific preferences, please, mark the topic(s) you would like to read: