Mécanismes d'allocation de l'espace dans les blocs - coécrit par des chercheurs Ethereum et des chercheurs a16z
TechFlow SélectionTechFlow Sélection
Mécanismes d'allocation de l'espace dans les blocs - coécrit par des chercheurs Ethereum et des chercheurs a16z
Comment les mécanismes d'allocation de l'espace dans les blocs influencent-ils le MEV ?
Dédié à des analyses Web3 approfondiesRédaction : mike, chercheur Ethereum ; Pranav Garimidi, Tim Roughgarden, chercheurs a16z
Traduction : 0XNATALIE
L'article « On block-space distribution mechanisms », rédigé conjointement par le chercheur Ethereum mike et les chercheurs a16z Pranav Garimidi et Tim Roughgarden, examine systématiquement comment les mécanismes de distribution de l'espace bloc influencent la MEV. Il commence par établir la nécessité d'introduire des mécanismes internes au protocole pour gérer la distribution de l'espace bloc, puis utilise le cadre « Qui, Quoi, Quand, Où, Comment » (W^4H) afin d'évaluer et comparer les schémas existants. Enfin, il analyse en profondeur le modèle des tickets d'exécution (execution tickets), montrant comment celui-ci équilibre perception de la MEV et équité dans la distribution. Voici la traduction de cet article.
TL;DR : L’espace bloc, c’est-à-dire la capacité d’inclusion des transactions, est la principale ressource produite par une blockchain. À mesure que l’écosystème cryptographique s’étend et se spécialise, la valeur générée par une utilisation efficace de l’espace bloc (MEV) joue un rôle central dans l’économie des mécanismes de consensus sans permission. La communauté de recherche a publié de nombreux articles sur la manière dont le protocole devrait traiter la MEV (voir travaux connexes). Les discussions des dernières années ressemblent à la fable du « aveugle et de l’éléphant », offrant plusieurs points de vue, solutions et théories, mais chaque angle semble fragmenté et difficile à comparer. La première moitié de cet article vise à présenter une vision globale de cet « éléphant MEV » en extrayant un ensemble de questions fondamentales et en explorant comment les propositions existantes y répondent. La seconde moitié se concentre sur les mécanismes de distribution activés par les tickets d’exécution, révélant un nouvel aperçu important : il existe un compromis entre la qualité de l’oracle interne de MEV et l’équité du mécanisme.
Structure de l'article : La section 1 explique pourquoi un mécanisme interne au protocole est nécessaire pour gérer la distribution de l’espace bloc, comme partie intégrante de la « fin ultime » du Proof-of-Stake. La section 2 présente cinq dimensions permettant d’évaluer les mécanismes de distribution de l’espace bloc, en utilisant un ensemble de questions familières : Qui, Quoi, Quand, Où, Comment (appelées brièvement questions W^4H). La section 3 explore le choix des constructeurs de blocs, en mettant l’accent sur le modèle des tickets d’exécution. La section 4 conclut en résumant et en soulevant des questions ouvertes.
Note : Cet article est long et contient des éléments techniques. Nous encourageons les lecteurs à se concentrer sur les parties qui les intéressent le plus. Les sections 1, 2 et 4 offrent une perspective large sur les propositions existantes et notre méthode d’analyse. La section 3 (environ 44 % du texte, mais contenant 100 % du contenu mathématique) fournit une analyse détaillée des mécanismes de distribution activés par les tickets d’exécution. Cette partie peut être lue séquentiellement, indépendamment, ou complètement ignorée — vous décidez !
(1) Motivation
Avant de plonger dans ce sujet complexe, clarifions rapidement la nécessité d’un mécanisme de distribution de l’espace bloc. Dans le Proof-of-Stake, les validateurs ont pour tâche de produire et de voter pour des blocs. L’image ci-dessous, tirée de l’article de Barnabé « More pictures about proposers and builders », illustre ces rôles comme des droits de proposition (proposing) et d’attestation (attesting).
1) Quoi
Un mécanisme de distribution de l’espace bloc est le processus par lequel le protocole détermine qui obtient le droit de proposer ou de construire un bloc. Les protocoles Proof-of-Stake utilisent généralement l'une des règles suivantes :
-
Droit de bloc (proposition) – Un validateur est choisi aléatoirement comme leader et autorisé à créer le prochain bloc.
-
Droit de vote (attestation) – Tous les validateurs votent pendant une fenêtre temporelle donnée pour le bloc qu’ils considèrent comme la tête canonique.
Les validateurs sont récompensés pour avoir accompli ces tâches. Nous classons ces récompenses selon leur origine : couche de consensus (émission par protocole, par exemple ETH nouvellement frappés) ou couche d’exécution (frais de transaction et MEV) :
Couche de consensus
a. Récompense d’attestation – (voir attestation deltas).
b. Récompense de bloc – (voir get_proposer_reward).
Couche d’exécution
a. Frais de transaction – (voir gas tracker).
b. MEV (ordonnancement des transactions) – (voir mevboost.pics).
Les récompenses 1a, 1b et 2a sont bien connues et « visibles par le protocole ». En revanche, la récompense MEV est plus problématique, car il est difficile de capturer entièrement la valeur générée par l’ordonnancement des transactions. Contrairement aux autres récompenses, la quantité de MEV dans un bloc est essentiellement incertaine (dans un système sans permission et anonyme, on ne peut pas tracer qui contrôle chaque compte ni les activités hors chaîne potentiellement lucratives). Le montant de MEV varie aussi fortement dans le temps (par exemple à cause des fluctuations de prix), rendant les récompenses de la couche d’exécution plus volatiles que celles de la couche de consensus. De plus, lors de son implémentation, le protocole Ethereum n’a aucune visibilité sur la MEV générée ou extraite par ses transactions. Pour améliorer cette visibilité, de nombreux mécanismes tentent d’estimer la MEV d’un bloc donné, appelés oracles de MEV. Les mécanismes de distribution d’espace bloc peuvent souvent produire de tels oracles, rendant ainsi le protocole « sensible à la MEV ».
Cela soulève la question : pourquoi le protocole devrait-il se préoccuper de la sensibilité à la MEV ? Une réponse est : cela pourrait aider le protocole à maintenir une égalité des récompenses même lorsque les validateurs ont des niveaux de sophistication différents. Par exemple, si le protocole pouvait brûler toute la MEV avec précision, les incitations des validateurs seraient entièrement visibles (comme 1a, 1b et 2a ci-dessus). Ou encore, un mécanisme permettant de partager toute la MEV entre tous les validateurs indépendamment de leur niveau de compétence (par exemple, via mev-smoothing) favoriserait un ensemble plus grand, diversifié et décentralisé de validateurs, tout en conservant la MEV comme incitation supplémentaire au staking. Sans perception de la MEV, les validateurs les plus performants (par leurs relations avec les constructeurs, algorithmes propriétaires, accès à des flux exclusifs ou économies d’échelle) pourraient obtenir des récompenses disproportionnées, exerçant ainsi une pression centralisatrice forte sur le protocole.
La conception du protocole Ethereum fait tout son possible pour maintenir un ensemble décentralisé de validateurs. C’est implicite, mais pour être complet : la neutralité digne de confiance, la résistance à la censure et l’accès sans permission du protocole dépendent directement d’un ensemble de validateurs décentralisés.
Distribution actuelle de l’espace bloc
Sur Ethereum aujourd’hui, mev-boost représente environ 90 % des blocs. Avec mev-boost, le proposeur (un validateur leader choisi aléatoirement) vend aux enchères son droit de construction du bloc au soumissionnaire offrant le prix le plus élevé. L’image ci-dessous illustre ce processus (nous omettons les relais, car ils sont essentiellement des extensions des constructeurs).
Le proposeur est incité à externaliser la construction du bloc, car les constructeurs (des agents spécialisés dans l’ordonnancement des transactions pour extraire la MEV) lui paient plus qu’il ne pourrait obtenir en construisant lui-même. Revenons à notre objectif initial : maintenir l’égalité des récompenses des validateurs malgré la présence de MEV. mev-boost permet à tous les validateurs d’accéder au marché des constructeurs, assurant ainsi des récompenses MEV presque identiques entre les stakers individuels et les fournisseurs professionnels — excellent ! Mais…
Bien sûr, mev-boost présente des inconvénients qui continuent de préoccuper certains membres de la communauté Ethereum. En bref, voici quelques effets secondaires négatifs de l’utilisation de mev-boost :
-
Relais – Ces tiers de confiance facilitent la vente des blocs entre proposeurs et constructeurs. La forte dépendance aux relais augmente la vulnérabilité globale du protocole, comme illustré par des incidents répétés. De plus, les relais n’ayant pas de source de revenus intrinsèque, des méthodes de capture de profit (souvent fermées et propriétaires) sont mises en œuvre (ex. jeux de timing et ajustement des offres).
-
Fragilité logicielle hors protocole – Outre les relais, participer au marché mev-boost oblige les validateurs à exécuter un logiciel supplémentaire. La suite standard pour un staker individuel inclut désormais quatre binaires : (i) nœud beacon de consensus, (ii) client validateur de consensus, (iii) client d’exécution, et (iv) mev-boost. Cela ajoute non seulement une surcharge significative, mais introduit aussi un point de défaillance potentiel lors des hard forks. Voir les incidents Shapella et la mise à jour Dencun pour comprendre la complexité induite par davantage de logiciels externes.
-
Centralisation des constructeurs et censure – Bien que cela puisse être inévitable, l’adoption massive de mev-boost a accéléré la centralisation des constructeurs. Trois constructeurs réalisent environ 95 % des blocs mev-boost (soit 85 % de tous les blocs Ethereum). mev-boost implémente une enchère ouverte au premier prix, gagnant-tout, entraînant une forte concentration des constructeurs et des stratégies de soumission. Aucune liste d’inclusion ni outil anti-censure n’a été mis en œuvre, et les constructeurs ont un grand pouvoir sur l’inclusion ou l’exclusion des transactions — (voir censorship.pics).
-
Jeux de timing – Bien que les jeux de timing soient un problème fondamental des protocoles Proof-of-Stake, mev-boost pousse les fournisseurs de staking à concurrencer sur de faibles marges. De plus, les relais (agissant pour les proposeurs lors des enchères mev-boost) agissent comme des intermédiaires complexes qui facilitent ces jeux. On observe donc des campagnes marketing incitant à staker avec des fournisseurs spécifiques pour augmenter les revenus.
(2) Énumération
Après cette introduction nécessaire, examinons de plus près l’essence des mécanismes de distribution de l’espace bloc.
Éléments de la distribution de l’espace bloc
Considérons le jeu consistant à acquérir l’espace bloc ; la MEV incite les agents à participer, tandis qu’une combinaison de logiciels internes et externes au protocole définit les règles. Quels éléments doivent être pris en compte lors de la conception de ce jeu ? Pour répondre, nous utilisons le schéma rhétorique familier « Qui, Quoi, Quand, Où, Comment » (l’objectif « Pourquoi » ayant été suffisamment abordé dans la section 1), que nous appelons les questions W^4H.
-
Qui contrôle le résultat du jeu ?
-
Quel bien les joueurs se disputent-ils ?
-
Quand le jeu a-t-il lieu ?
-
D’où provient l’oracle de MEV ?
-
Comment choisir les constructeurs de blocs ?
Ces questions semblent trop simples, mais prises isolément, chacune peut être vue comme un axe d’évaluation de l’espace de conception des mécanismes. Pour le démontrer, nous mettons en lumière différentes catégories de mécanismes de distribution de l’espace bloc déjà explorées. Bien qu’elles semblent non liées, leurs relations deviennent claires à travers leurs réponses aux questions W^4H.
Tickets d’exécution et autres approches
Nous présentons ici un aperçu de plusieurs mécanismes de proposition distincts. Notez que ceci n’est qu’un sous-ensemble de la littérature assez vaste autour de ces conceptions — (voir infinite buffet). Pour chacun, nous résumons uniquement l’idée principale (voir travaux connexes pour plus de détails).
Tickets d’exécution
Idée clé : Le droit de construire et de proposer un bloc est vendu directement par le protocole via des « tickets ». Les détenteurs de tickets sont sélectionnés aléatoirement comme constructeurs de blocs, avec un préavis. Ils ont le droit de produire un bloc pendant une période allouée.
PBS aux enchères de blocs (Proposer-Builder Separation)
Idée clé : Le protocole attribue le droit de production de bloc via un processus d’élection aléatoire de leaders. Le validateur sélectionné peut vendre directement son bloc au marché des constructeurs ou le construire localement. Les constructeurs doivent s’engager sur un bloc spécifique lors de l’enchère. mev-boost est une instance hors protocole de PBS ; ePBS en est l’équivalent intégré au protocole.
Brûlage ou nivellement de la MEV
Idée clé : Un comité impose une valeur minimale aux offres choisies par les proposeurs lors de l’enchère. En exigeant des offres « suffisamment élevées », un oracle de MEV est créé. La MEV est soit nivelée entre les membres du comité, soit brûlée (nivelée vers tous les détenteurs d’ETH).
PBS aux enchères de slot
Idée clé : Similaire à PBS aux enchères de blocs, mais au lieu de vendre un bloc spécifique, le slot est vendu sans engagement de contenu — parfois appelé futur de l’espace bloc. En ne demandant pas d’engagement sur le contenu, les slots futurs peuvent être vendus à l’avance, plutôt qu’en attendant le slot lui-même.
Enchères partielles de blocs
Idée clé : Permettre une unité plus flexible de vente d’espace bloc. Plutôt que de vendre un bloc ou un slot entier, le proposeur peut vendre une _partie_ de son bloc, par exemple le sommet (le plus précieux pour les arbitragistes), tout en gardant le reste. Fonctionne déjà sur d’autres réseaux Proof-of-Stake, comme le moteur de blocs Jito ou la voie MEV Skip.
APS Brûler pour exécuter (Auction to Pay for Service)
Idée clé : Une nouvelle proposition de Barnabé forçant le proposeur à vendre à l’avance le droit de construction et de proposition. Le slot est vendu à l’avance (temps fixe), sans engagement de contenu ; un comité (comme dans le brûlage/nivellement de MEV) garantit que l’offre est suffisamment élevée.
En comparant les réponses de ces propositions aux questions W^4H, on voit qu’elles représentent différentes facettes d’un même espace de conception.
Application de W^4H : Analyse comparative
Pour chaque question W^4H, nous décrivons les compromis différents entre les propositions ci-dessus. Par souci de concision, nous n’analysons pas chaque proposition pour chaque question, mais mettons en avant les différences clés apportées par chaque axe.
Qui contrôle le résultat du jeu ?
-
Dans les tickets d’exécution, le protocole détermine le gagnant en choisissant aléatoirement parmi les détenteurs de tickets.
-
Dans PBS aux enchères de blocs, le proposeur (leader désigné par le protocole) choisit unilatéralement le gagnant.
-
Dans le mécanisme de brûlage de MEV, le proposeur choisit toujours le gagnant, mais l’offre gagnante est contrainte par un comité, réduisant ainsi l’autonomie du proposeur.
Que se dispute-t-on ?
-
Dans PBS aux enchères de blocs, un bloc entier est vendu, mais l’offre doit s’engager sur le contenu.
-
Dans PBS aux enchères de slot, un bloc entier est vendu, sans engagement sur le contenu.
-
Dans PBS aux enchères partielles, seule une portion du bloc est vendue.
Quand le jeu a-t-il lieu ?
-
Dans PBS aux enchères de blocs, l’enchère a lieu pendant le slot.
-
Dans PBS aux enchères de slot, l’enchère peut avoir lieu plusieurs slots (ex. 32) à l’avance, grâce à l’absence d’engagement sur le contenu.
-
Dans les tickets d’exécution, les tickets sont attribués à des slots avec un délai fixe.
D’où vient l’oracle de MEV ?
-
Dans les mécanismes de brûlage/nivellement de MEV, le comité impose que l’offre retenue soit suffisamment élevée, servant ainsi d’oracle.
-
Dans les tickets d’exécution, la dépense totale en tickets sert d’oracle.
Comment choisir les constructeurs de blocs ?
-
Dans PBS aux enchères de blocs, toute production externalisée suit une allocation gagnant-tout : le plus offrant obtient le droit de construire le bloc.
-
Dans les tickets d’exécution, de nombreux mécanismes d’allocation sont possibles. Par exemple, dans la proposition initiale, les tickets sont choisis aléatoirement selon un mécanisme « proportionnel au nombre de tickets » ; ainsi, le plus offrant (celui qui détient le plus de tickets) a seulement une probabilité plus élevée d’être sélectionné, sans garantie.
Si tout cela semble obscur, ne vous inquiétez pas. La suite explorera en détail ces différents mécanismes d’allocation.
Retour sur la motivation
Avant de poursuivre, rappelons notre motivation initiale :
Les mécanismes de distribution de l’espace bloc visent à maintenir l’homogénéité des récompenses des validateurs en présence de MEV.
C’est une bonne base, mais si c’est notre seul objectif, pourquoi ne pas continuer avec mev-boost ? Rappelez-vous, mev-boost a des effets négatifs que nos protocoles finaux devront peut-être résister. Nous soulignons quatre autres objectifs potentiels de conception :
-
Encourager une concurrence plus large entre les constructeurs.
-
Permettre des interactions de confiance entre validateurs et constructeurs.
-
Intégrer la conscience de la MEV au niveau du protocole de base.
-
Supprimer complètement la MEV des récompenses des validateurs.
Notez que bien que (1, 2, 3) soient relativement incontestés, (4) est plus controversé (et nécessite (3) comme préalable). Le protocole pourrait vouloir supprimer les récompenses MEV afin que les récompenses de la couche de consensus (contrôlées par protocole) reflètent plus précisément l’incitation globale du système. Cela touche aussi à la macroéconomie du staking et à l’émission du protocole — un débat plus politique. D’un autre côté, la MEV est un sous-produit de l’utilisation du réseau ; elle peut être perçue comme un mécanisme de capture de valeur du jeton natif. Nous ne cherchons pas ici à trancher, mais à explorer comment différentes réponses influencent la conception du mécanisme.
Que pouvons-nous faire au niveau de la conception du protocole pour atteindre ces objectifs ? Comme mentionné, de nombreux compromis sont à considérer, mais dans la suite, nous explorerons « Comment choisir les constructeurs de blocs ? » pour améliorer certaines dimensions.
(3) Interrogation
Note de rédaction : Comme mentionné précédemment, cette section est plus longue et technique — si vous manquez de temps (ou d’intérêt), vous pouvez passer directement à la section 4.
Objectif partiel : Montrer le compromis quantitatif entre la qualité de l’oracle de MEV et l’équité du mécanisme, entre deux méthodes bien connues d’allocation des droits de proposition (appelées « proportionnel-tout-payant » et « gagnant-tout »).
Nous atteindrons cet objectif via les sous-sections suivantes :
Bases
Avant d’explorer les mécanismes d’allocation permis par les tickets d’exécution, établissons un modèle. Considérons un protocole vendant des tickets d’exécution selon les règles suivantes :
-
Prix fixe à 1 WEI,
-
Quantité illimitée d’achat et de vente de tickets.
Note : Cette version des tickets d’exécution revient en pratique à créer deux mécanismes de staking indépendants — un pour l’attestation, un pour la proposition. De petites modifications, comme interdire la revente des tickets au protocole, pourraient grandement affecter le fonctionnement du marché, mais ce n’est pas notre sujet ici. Nous nous concentrons étroitement sur le problème de l’allocation de l’espace bloc parmi les détenteurs existants de tickets.
Notons que du point de vue du protocole, producteurs de blocs et attestateurs sont des entités distinctes — chaque individu choisit sa participation via le staking ou l’achat de tickets. Un marché secondaire de tickets pourrait émerger, où les droits de construction sont vendus à temps dans un marché aux enchères (comme mev-boost aujourd’hui).
De plus, les constructeurs pourraient choisir d’interagir directement avec le protocole en achetant des tickets, mais leur capital pourrait mieux servir en liquidité active pour capter des arbitrages entre places de marché. Ils préféreraient alors acheter l’espace bloc sur le marché secondaire au moment de l’enchère.
Pourquoi nous limiter à ce mécanisme à prix fixe et offre illimitée ? Deux raisons :
1. Il n’est pas clair qu’un marché complexe puisse être implémenté au niveau de la couche de consensus. L’optimisation des clients permet à tout validateur avec du matériel grand public de participer. Cette exigence pourrait entrer en conflit avec des enchères rapides, des courbes de liaison ou d’autres mécanismes possibles de vente de tickets. Des questions comme la quantité de tickets vendus, la MEV générée par les transactions liées à la vente (méta-MEV ?!) et le timing de la vente semblent plus proches des préoccupations de la couche d’exécution que de ce que le consensus Ethereum peut raisonnablement supporter tout en maintenant des exigences matérielles limitées.
« On peut imaginer que l’inclusion de transactions liées au marché ET pourrait générer de la MEV, que ces transactions soient incluses dans un bloc beacon ou une charge utile d’exécution. » — Barnabé, dans « More pictures about proposers and builders ».
2. Même si (hypothèse forte) le protocole pouvait implémenter un marché de tickets plus strict, l’espace de conception serait immense. De nombreux mécanismes de tarification ont été discutés (courbes de liaison, tarification dynamique à la 1559, enchères, etc.) ; une généralisation dépasse le cadre de cet article.
Nous nous concentrons donc sur la version « quantité illimitée, prix fixe à 1 WEI » des tickets d’exécution, où la complexité internalisée par le protocole est minimale. Dans ce cadre, posons la question brûlante : « Étant donné un ensemble de détenteurs de tickets, comment choisir le gagnant ? »... Cela semble simple, n’est-ce pas ? Il s’avère qu’on peut dire beaucoup même sur une question apparemment simple ; explorons différentes options.
x:b→[0,1]n ∑ixi(b)=1 p:b→Rn≥0
Modèle
Considérons un jeu répété où les participants obtiennent des récompenses MEV via l’achat de tickets d’exécution :
-
À chaque cycle, chaque joueur soumet une offre, représentant le nombre de tickets achetés. Soit b le vecteur d’offres, bi étant l’offre du joueur i.
-
Chaque joueur attribue une valeur à la victoire dans la production du bloc. Soit v le vecteur des valeurs, vi étant la valeur du joueur i.
-
À chaque pas de temps, un mécanisme d’allocation détermine la part accordée à chaque joueur selon le vecteur d’offres. En supposant des joueurs neutres au risque, on peut dire qu’ils reçoivent chacun une « partie du bloc », interprétable comme une « probabilité de gagner un bloc ». Dans un jeu à n joueurs, soit x: b → [0,1]^n la fonction d’allocation, xi(b) étant la part du joueur i, sous la contrainte ∑i xi(b) = 1 (le mécanisme distribue entièrement).
-
Le paiement de chaque joueur est collecté chaque tour. Soit p: b → R^n≥0 la règle de paiement, pi(b) étant le paiement du joueur i.
-
L’utilité du joueur i est définie par Ui(b) = vi xi(b) - pi(b), soit la valeur du bloc remporté fois la part obtenue, moins le paiement effectué.
Mécanismes d’allocation familiers
Considérons deux mécanismes possibles (très différents).
Pro
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
a16z
