Partie 1: Comment nous en sommes arrivés là

Ethereum a été initialement conçu avec l'idée qu'une seule partie gérerait l'ensemble du processus de création de bloc. Cela impliquait d'agréger les transactions de la mempool, de créer l'en-tête du bloc et de trouver le nonce doré dans la preuve de travail ou simplement de signer l'en-tête du bloc dans la preuve d'enjeu. Pendant ses premières années, la construction de blocs était simple : les nœuds miniers tiraient les transactions de leur mempool, les ordonnaient en fonction du prix du gaz, qui signifie le travail de calcul de chaque transaction, et restaient dans la limite de gaz par bloc. Cependant, avec l'essor de la finance décentralisée (DeFi), cette approche de construction de blocs a connu des changements significatifs.

La menace de centralisation de MEV

Dans la DeFi, l’ordre dans lequel les transactions sont ordonnées peut faire une grande différence. Disons qu’il y a une transaction en attente dans le mempool qui vise à échanger 1 ETH contre du BITCOIN (je parle de HarryPotterObamaSonic10Inu, bien sûr) sur UniSwap. Le montant de BITCOIN que vous recevrez est basé sur le ratio ETH/BITCOIN actuel dans le pool UniSwap. Si la transaction de quelqu’un d’autre, l’échange de 2 ETH contre des BITCOIN, est traitée juste avant la vôtre, vous vous retrouverez avec moins de BITCOIN car le ratio ETH/BITCOIN a changé. Compte tenu de l’importance de l’ordre des transactions, et les mineurs contrôlent cet ordre, cela a conduit à l’émergence de ce que nous appelons MEV, ou Miner/Maximum Extractible Value. Le MEV représente le profit potentiel qu’un mineur peut réaliser en choisissant les transactions à inclure, à exclure ou à réorganiser.

Le MEV peut sembler inoffensif au premier abord. Heck, cela pourrait même apparaître comme un booster pour la sécurité du réseau, plus d’incitations pour le minage ou la validation, n’est-ce pas ? En plus des récompenses de bloc et des frais de transaction habituels, il y a maintenant des MEV à gagner. Mais la réalité est loin d’être anodine. S’il n’est pas contrôlé, le MEV pourrait devenir une puissante force centralisatrice. Voici une histoire pour illustrer cela : Imaginez que vous venez d’avoir vent de ce jeu MEV et que vous entendez que les validateurs engrangent plus de 10 % d’APR à cause de cela. Tentant, n’est-ce pas ? Vous êtes à fond dedans ! Ainsi, vous envoyez vos 32 ETH au contrat de staking et lancez un nœud de validation. Mais attendez une minute... Vous ne voyez qu’un rendement de 4 %. Lorsque vient votre tour de proposer un bloc, les transactions s’alignent simplement en fonction de leur prix de gaz. Pas de magie MEV. Vous n’êtes pas armé des algorithmes et des tactiques complexes pour extraire cet or MEV. Sans le savoir-faire, vous êtes coincé avec la valeur par défaut : classer les transactions par prix de l’essence.

C'est ici que l'attraction centralisatrice entre en jeu. Même si vous êtes quant, votre ordinateur simple, peut-être un raspberry pi, ne fait pas le poids face à leurs supercalculateurs exécutant des stratégies d'extraction de MEV de niveau supérieur. L'objectif évident ici est d'éteindre votre validateur et d'envoyer plutôt votre ETH à ces configurations surpuissantes qui promettent une part du gâteau MEV. En avançant rapidement, vous pourriez voir une poignée de ces géants diriger essentiellement le réseau, un résultat centralisé vraiment inquiétant. Si c'est là que les choses se dirigent, alors les objectifs fondamentaux d'Ethereum ont échoué. Un réseau dominé par quelques-uns pourrait tout aussi bien être une base de données centralisée à ce stade.

La naissance des flashbots

Phil Daian, un doctorant à Cornell spécialisé dans la sécurité des contrats intelligents, a été parmi les premiers à identifier le problème du MEV. En août 2017, il a publié un blog intitulé « Le Coût de la Décentralisation dans 0x et EtherDelta ». Ce blog a été inspiré par les vulnérabilités de front-running qu'il a identifiées lors de l'ICO de 0x.

Le front-running consiste à repérer une transaction dans le mempool qui vise à échanger le Token A contre le Token B. Un front-runner initie alors de manière programmatique une transaction similaire offrant un prix du gaz plus élevé. Cette stratégie garantit que la transaction du front-runner est traitée avant l'originale. Après le traitement de la transaction initiale, le front-runner peut immédiatement échanger le Token B contre le Token A, se retrouvant avec une quantité plus importante de Token A qu'au départ. Cette tactique est parfois appelée une attaque sandwich, car la transaction de l'utilisateur se retrouve coincée entre deux transactions initiées par le front-runner. En conséquence, tandis que le front-runner réalise un profit, l'individu derrière la transaction initiale reçoit moins de Token B. Bien que les attaques sandwich soient courantes, il existe différentes stratégies que les individus peuvent utiliser pour extraire efficacement la valeur de l'arbitrage des transactions avant l'inclusion dans un bloc (MEV).

Visualiser l'attaque du sandwich : Comment les préempteurs profitent au détriment des autres

Pendant le boom des ICO, Phil et une équipe ont déployé un bot qui rapportait environ un million de dollars par an. Après avoir partagé leur méthodologie dans le billet de blog que j'ai mentionné précédemment, plusieurs bots similaires ont émergé, créant un paysage concurrentiel où les bots surenchériraient sur les prix du gaz les uns des autres pour obtenir la priorité des transactions. Cela a incité Phil à déployer des nœuds à l'échelle mondiale, capturant des données transactionnelles en temps réel. Cette recherche a abouti à son célèbre Papier "Flash Boys 2.0", qui a exploré en profondeur les défis MEV causés par les échanges décentralisés.

Voici une histoire amusante connexe que Phil a partagée lorsqu'il était invité sur le Billot. Lorsque Hayden Adams, le fondateur de UniSwap, a partagé son concept de ce qui est maintenant l'échange décentralisé le plus populaire sur ethresear.ch. Phil a immédiatement envoyé ses préoccupations à la fois à Vitalik et à Hayden. Phil pensait que le concept de UniSwap causerait une quantité significative de MEV, en faisant une cible principale pour l'exploitation et mettant les utilisateurs en danger de réorganisation des transactions et d'attaques de sandwich. Vitalik a répondu en suggérant que cela pourrait simplement être considéré comme un mécanisme de frais supplémentaire pour utiliser la blockchain. Phil était tellement furieux contre cette réponse et il pensait que de puissantes entités financières comme Goldman Sachs viendraient et mangeraient le déjeuner des détaillants exactement comme le système financier actuel. Cependant, avec le temps, Phil a adopté la perspective de Vitalik (tout loue le seigneur Vitalik).

Reconnaissant l'importance et les défis de l'espace MEV, Phil a cofondé Flashbots, une entreprise axée sur la recherche et les solutions dans l'arène MEV. Flashbots a réalisé que le MEV allait exister et que la mission de Flashbots est de veiller à ce que l'existence du MEV ne conduise pas à un système où le fait d'être une mauvaise personne ou de créer des externalités négatives est à la fois meilleur pour vous individuellement et plus rentable que d'être un bon acteur. Un exemple en TradFi, les stratégies les plus rentables impliquent souvent l'exploitation des marges du système. De plus, Flashbots pensait qu'il pourrait y avoir un moyen d'exploiter l'énergie du MEV pour les utilisateurs et de subventionner les personnes qui sécurisent le réseau et aussi de subventionner les transactions sur le réseau pour offrir aux gens de meilleurs prix pour leur donner l'exécution qu'ils veulent dans ces systèmes. Bien conçu, le MEV pourrait faire partie de ce qui fait surperformer la crypto par rapport aux systèmes traditionnels.

Exploiter le MEV : le rôle des enchères et la séparation entre le soumissionnaire et le constructeur

Flashbots a reconnu que le monopole des mineurs sur l'ordonnancement des transactions était une ressource précieuse. Leur première étape pour démocratiser le MEV a consisté à créer un système d'enchères pour les droits d'ordonnancement des transactions. Cela a conduit à la création de MEV GETH, qui a d'abord introduit le concept de séparation proposant-constructeur (PBS). Barnabé Monnot de la Fondation Ethereum décrit le PBS comme suit : "Une philosophie de conception où les participants au protocole peuvent utiliser des services tiers lors de leurs devoirs de consensus." Jusqu'à ce point, les mineurs avaient un contrôle total : ils décidaient de l'ordre des transactions, faisaient le hachage, puis ajoutaient le bloc. Mais MEV GETH a changé la donne. Il a introduit des acteurs extérieurs, appelés chercheurs, qui ont payé pour le droit d'inclure leur ensemble de transactions dans le bloc des mineurs.

Avec MEV GETH, les mineurs disposaient d'un nouveau point de terminaison. Ils pouvaient recevoir des paquets de transactions optimisés pour le MEV des chercheurs. Chaque paquet contiendrait également une transaction offrant aux mineurs des frais, les incitant à sélectionner ce paquet particulier. Naturellement, les mineurs choisissaient le paquet offrant les frais les plus élevés. Lorsque les chercheurs se disputent les opportunités MEV dans le mempool public, leurs offres augmentent naturellement en raison de cette concurrence. Cette compétition garantit que les mineurs reçoivent la part du lion des avantages MEV.

Penchons-nous sur un exemple : Imaginons qu'Alice soit une chercheuse et repère une opportunité d'arbitrage entre deux échanges décentralisés. Elle pourrait réaliser un profit de 0,07 ETH en achetant le Token X sur UniSwap puis en le revendant immédiatement sur SushiSwap à un prix plus élevé. Elle crée donc un ensemble de transactions optimisé pour l'opportunité MEV de 0,07 ETH et est prête à payer un mineur 0,05 ETH pour donner la priorité à ses transactions dans le prochain bloc. Bob, un autre chercheur, identifie la même opportunité. Il construit un ensemble similaire mais propose un paiement de 0,06 ETH aux mineurs pour le même privilège. Alice et Bob envoient tous deux leurs ensembles de transactions optimisés pour le MEV aux mineurs. De leur côté, un mineur reçoit ces ensembles et doit décider lequel inclure dans le prochain bloc. Naturellement, le mineur choisit l'ensemble de Bob en raison du montant de frais plus élevé offert, garantissant ainsi au mineur de maximiser les bénéfices. C'est une situation gagnant-gagnant.

Le mineur capture la majorité de l'opportunité MEV, recevant 0,06 ETH sur l'opportunité de 0,07 ETH. Pendant ce temps, le chercheur réalise un bénéfice net de 0,01 ETH, qu'il n'aurait pas pu obtenir autrement. L'essence du mécanisme MEV GETH est cette enchère compétitive. Alice et Bob s'affrontent, s'offrant des incitations au mineur, garantissant ainsi que le mineur capture une part significative des avantages MEV.

Cependant, s'ils ouvraient simplement un point de terminaison pour que quiconque envoie des paquets aux mineurs, des acteurs malveillants pourraient exploiter cette ouverture pour surcharger leur système, lançant potentiellement une attaque DOS. Pour remédier à cette vulnérabilité, Flashbots a introduit le Flashbots Relay. Ce relais joue un rôle de filtrage crucial : il évalue les paquets de transactions entrants en fonction de leur rentabilité potentielle pour les mineurs, de la validité des transactions et des frais offerts. Seuls les paquets optimaux sont ensuite transmis aux mineurs. Cette méthode introduit en effet un niveau de centralisation, car le processus dépend du Flashbots Relay pour filtrer le trafic indésirable ou potentiellement nuisible. Fait intéressant, un niveau de PBS existait déjà entre l'opérateur du pool minier et leurs travailleurs. En général, l'opérateur construisait le corps du bloc, y compris les paquets envoyés depuis les relais, hashait l'en-tête du bloc une fois, et le transmettait aux travailleurs pour continuer le hachage et trouver le nonce d'or.

Aperçu de MEV GETH : Le parcours de la recherche à l'inclusion du bundle de transactions dans le bloc du mineur

Partie Deux: Le Paysage Actuel

Lorsque Ethereum est passé de la preuve de travail (PoW) à la preuve d'enjeu (PoS), le paysage de la validation des transactions et de la proposition de blocs a considérablement changé. Alors que la PoW s'appuyait sur les mineurs et la puissance de calcul (taux de hachage) pour valider et ajouter de nouveaux blocs à la blockchain, la PoS a déplacé cette responsabilité vers les validateurs qui miseraient leur ETH pour devenir des proposants de blocs.

MEV GETH était utilisé par presque tous les pools de minage, mais avec la transition d’Ethereum vers le PoS, le système nécessitait des modifications. Le PoS a été conçu pour s’adapter aux stakers solitaires : des validateurs individuels opérant sur des appareils à faibles ressources comme un Raspberry Pi. Le PoS a été conçu dans le but d’assurer un paysage équilibré : que vous soyez un staker solo ou que vous fassiez partie d’un pool de staking important, il n’y aurait aucun avantage inhérent au processus de validation pour un participant. Avant la transition PoS, quelques pools de minage dominaient le taux de hachage. Cela a permis d’établir une relation de confiance entre ces pools et le Flashbots Relay. Toute action malhonnête, telle qu’un pool de minage volant des MEV à un chercheur, pourrait mettre en péril cette relation. Supposons qu’un mineur reçoive un paquet avec une attaque sandwich de la part d’un chercheur. Si le mineur prenait en sandwich le chercheur avec ses propres transactions, cela apporterait un gain à court terme, mais cela romprait les liens avec les Flashbots, ce qui leur coûterait des revenus futurs en MEV car ils perdraient l’accès au relais des Flashbots.

Présentation de MEV Boost

Les validants en solo, contrairement aux grands pools de minage, pourraient ne pas avoir de motivations à long terme pour maintenir la confiance. Dans certains scénarios, ils pourraient trouver plus rentable d'exploiter le MEV d'un constructeur, puis disparaître ultérieurement du réseau. Cette action entraînerait une amende complète, avec une perte de tous les 32 ETH, mais dans certains cas, le profit potentiel du vol de MEV peut compenser cette perte. Cela s'est effectivement produit en avril, lorsqu'un validateur malveillant a subtilisé 20 millions de dollars à un bot de sandwich avant de fermer son validateur.Pour en savoir plus sur cet incident.

En réponse à ce nouveau vecteur d'attaque, Flashbots a déployé MEV Boost, un système conçu pour un environnement avec des validateurs solo.

Les mécanismes du Boost de MEV :

• Relais : Contrairement au système précédent où seuls les Flashbots agissaient en tant que relais, MEV Boost démocratise cela. Maintenant, n'importe qui peut servir de relais, élargissant ainsi la participation et la sécurité. Flashbots a également rendu leur code relais open-source.
• Constructeurs: Un nouveau rôle émerge - le Constructeur. Ces entités collectent des paquets de transactions des chercheurs et les combinent en blocs complets.
• Système d'enchères : Les constructeurs font des offres pour inclure leur bloc complet et les soumettent aux relais. Les relais effectuent une étape de vérification cruciale pour garantir la validité du bloc.
• Interaction du validateur: les relais transmettent l'offre la plus élevée, ainsi que l'en-tête de bloc correspondant, qu'ils reçoivent des constructeurs concurrents au validateur chargé de proposer un bloc au réseau Ethereum.
• Engagement de bloc : Le validateur désigné signe l'en-tête du bloc, qui est un engagement. Une fois signé, ils sont liés à ce bloc. S'ils tentent de signer un autre bloc, cela serait considéré comme un acte malveillant et ils seraient pénalisés.
• Proposition finale : Avec un engagement en place, le relais envoie les détails complets du bloc au validateur, et c'est formellement proposé au réseau.

Le processus MEV Boost

Ce paramétrage introduit des problèmes de confiance :

• La confiance Builder-Relay : Les constructeurs doivent avoir confiance que les relais ne voleront pas leur MEV. Envisagez un scénario où un relais, après avoir reçu un bloc d'un constructeur, échange l'adresse du constructeur dans une transaction sandwich pour la sienne. Ensuite, ils transmettent l'en-tête manipulé au proposant.
• Proposer-Relay Trust: Les proposants, en revanche, doivent avoir confiance que les en-têtes de bloc qu'ils signent sont valides. Proposer un bloc invalide entraînerait la perte des récompenses de bloc car le réseau rejetterait un tel bloc.

Les conceptions PBS rencontrent un défi récurrent : alors que les interactions entre le proposant et les acteurs de l'ordonnancement des transactions sont données, il est clairement nécessaire d'avoir un mécanisme où :

• Les proposants peuvent s'engager sur un bloc de constructeur sans connaître son contenu mais restent assurés de la validité du bloc.
• Les constructeurs peuvent envoyer en toute sécurité leur bloc au proposant, en étant convaincus que leur MEV ne sera pas volé.

MEV Boost supposer des confiances

Avant de plonger plus profondément dans MEV Boost, il est essentiel de comprendre la manière par défaut dont Ethereum crée des blocs sans utiliser MEV Boost. Cette configuration repose sur la collaboration entre un client d'exécution de validateurs et un client de consensus. Lorsqu'une transaction est reçue par le client d'exécution, il vérifie le format, l'ajoute à son mempool, mais ne la traite pas. Simultanément, le client de consensus gère le consensus de PoS, choisissant un validateur pour créer le prochain bloc. Le client d'exécution du validateur sélectionné organise ensuite les transactions par prix du gaz dans un nouveau bloc, qui est ensuite transmis au client de consensus et présenté au réseau. D'autres validateurs attestent de l'exactitude du bloc et une fois vérifié, il devient le maillon le plus récent de la chaîne.

Ce processus change si le validateur choisit d'utiliser MEV Boost. Les validateurs intégrant MEV Boost le font avec leur client de consensus. Lorsqu'ils sont prêts à proposer un bloc, ils ne comptent plus sur leur client d'exécution et se connectent plutôt à un réseau de relais. Les validateurs peuvent choisir les relais auxquels se connecter.

MEV Boost est facultatif, mais 95% des validateurs l'utilisent. Essentiellement, presque tous les validateurs, à l'exception de ceux gérés par Vitalik, délèguent la construction de blocs à un tiers. Cette délégation indique qu'une fonction essentielle du protocole Ethereum, la construction de blocs, est désormais principalement effectuée en dehors du système Ethereum lui-même. Un acteur clé de cette configuration est le relais et leur rôle contraste quelque peu avec les principes fondamentaux d'Ethereum. Actuellement, il y a environ 9 relais actifs, mais seulement 6 d'entre eux ont une part de blocs relayés >9%.

Répartition des principaux relais et constructeurs par part de marché au cours des 7 derniers jours. Source: https://www.relayscan.io/

La confiance devient un problème car la relation entre les relais et le constructeur et le relais et le validateur n’est pas sans confiance. Il y a aussi une inquiétude au sujet de la résistance à la censure. Les relais, lors de leurs enchères, ont le pouvoir discrétionnaire de déterminer la validité des blocs. Ce pouvoir discrétionnaire leur permet d’exclure les blocs contenant des transactions liées à des adresses sanctionnées. À titre d’exemple, lorsque les sanctions de l’OFAC Tornado Cash ont eu lieu, certains relais ont exercé ce pouvoir. Des données récentes montrent que 38 % des blocages de la semaine dernière ont respecté les directives de l’OFAC en raison d’une telle censure imposée par le relais.

Partie Trois: Regarder vers l'avenir

Ethereum élabore une stratégie pour réincorporer les processus qui fonctionnent actuellement en dehors de son protocole de base. L'objectif est de rendre obligatoire que les proposants obtiennent des blocs des constructeurs, en laissant essentiellement le protocole gérer les tâches actuelles du relais. Le système de relais tel qu'il existe présente des vulnérabilités. Par exemple, un relais pourrait ne pas valider correctement un bloc, mal vérifier l'offre du constructeur par rapport au paiement prévu pour le proposant, voire retarder ou échouer dans la livraison du bloc. De plus, exploiter un relais a un coût. À l'heure actuelle, il n'existe pas de modèle de financement durable pour eux. Le relais à ultrasons, le relais le plus utilisé, estime que ses coûts d'exploitation s'élèvent entre 70 000 et 80 000 euros par an, sans compter d'autres dépenses telles que la maintenance logicielle. Les relais fonctionnent actuellement comme des services publics.

Il convient également de noter que, comme MEV Boost est un logiciel externe développé par une entreprise (Flashbots), il n'est pas aussi rigoureusement testé que les logiciels intégrés au protocole. Cela a été évident avec le client Prism après la mise à niveau de Shapella : un bogue d'intégration avec MEV Boost a causé des problèmes avec la signature du proposant, entraînant des créneaux manqués et des pénalités. L'objectif de l'intégration de ce processus dans le protocole Ethereum est de relever ces défis, en veillant à ce que même si un accord entre le proposant et le constructeur échoue, le proposant reste remboursé. Ainsi, si un constructeur fournit un bloc défectueux, le proposant reçoit quand même l'offre complète, laissant au constructeur les conséquences à assumer. Alors que les détails de cette intégration, appelée ePBS (séparation proposant-constructeur consacrée), sont encore en cours de recherche, et peut-être à quelques années de la réalisation, il existe déjà de nombreuses idées différentes sur la manière dont cela pourrait éventuellement se présenter.

Comment consacrer la séparation entre le proposant et le constructeur

Pour comprendre les mises en œuvre potentielles de ePBS, il est essentiel de comprendre d'abord certains composants de base de l'algorithme PoS d'Ethereum. Dans Ethereum, le temps est segmenté en intervalles de 12 secondes appelés slots. 32 de ces slots se regroupent pour former une époque. À chaque slot, un validateur est sélectionné de manière aléatoire pour proposer un bloc. Simultanément, un comité est désigné pour attester de la validité du bloc qu'ils jugent conforme aux règles de choix de fork PoS d'Ethereum, en attestant idéalement du bloc le plus récemment proposé comme tête de la blockchain. Si aucun bloc n'est proposé dans le slot donné, alors 4 secondes plus tard, les validateurs attestants attestent du bloc précédent.

Passons maintenant aux conceptions ePBS. Le modèle le plus apprécié s’étend sur deux emplacements. Tout d’abord, il y a une phase d’appel d’offres, au cours de laquelle les constructeurs envoient leurs offres aux validateurs. Ensuite, l’emplacement 1 commence par le soumissionnaire qui choisit une offre et s’y engage en publiant un bloc qui s’engage dans l’offre de ce constructeur. Un groupe d’attestateurs a alors voté en faveur de ce bloc, assurant ainsi sa place dans la chaîne. Dans l’emplacement 2, les constructeurs voient l’offre qui a été engagée dans le bloc engagé du soumissionnaire et les attestations qui s’y trouvent. Reconnaissant l’engagement irréversible du soumissionnaire, le constructeur dont l’offre a été retenue libère son bloc et est assuré que son VEM ne peut pas être volé. Enfin, les attestateurs valident ce nouveau bloc.

Conception ePBS à "deux fentes"

Un modèle récemment publié est similaire à l'approche en deux étapes mais introduit un comité de ponctualité de charge utile. D'abord, une offre du constructeur est sélectionnée et engagée par le proposant, ensuite le comité des validateurs donne son attestation. Par la suite, le constructeur révèle la charge utile du bloc (ses transactions), et le comité de ponctualité de charge utile confirme que la charge utile a été fournie à temps et sa validité. Les autres différences entre ces deux méthodes résident dans les spécificités des opérations de Preuve d'Enjeu d'Éthereum, mais cela dépasse le cadre de cette publication.

Conception ePBS avec un comité de ponctualité des charges utiles

Un autre design tourne autour du concept d'enchère de slot. Ici, les constructeurs, lors de leur soumission, s'engagent à un emplacement dans l'époque sans spécifier le bloc. Ils s'engagent essentiellement à créer un bloc pendant leur créneau alloué, offrant un certain prix pour le faire. Cela offre une adaptabilité, en particulier pour le MEV inter-domaines qui nécessite une action en temps réel.

Jusqu'à présent, tous les designs ePBS accordent au constructeur un contrôle total sur les transactions du bloc. Une solution de contournement potentielle est l'utilisation d'une liste d'inclusion. Cette liste, envoyée par le proposant au constructeur, idéalement toutes les transactions actuellement dans le mempool ou pas nécessairement, contient les transactions qui doivent faire partie du bloc du constructeur s'il y a de la place. Si le bloc du constructeur est plein, ils doivent l'indiquer, affirmant qu'ils ont pris connaissance de la liste. Une telle méthode renforce la résistance à la censure du réseau. Si un constructeur souhaite censurer une transaction, cela deviendra difficile et coûteux avec le temps. En raison de l'EIP 1559, des blocs remplis consécutivement feront augmenter de manière exponentielle les frais de base. Par conséquent, si un constructeur censure continuellement une transaction en remplissant un bloc avec des transactions fictives, les coûts croissants rendent cela irréalisable avec le temps.

Il se peut que le proposant souhaite parfois influencer la création de blocs. Une autre fonctionnalité ePBS pourrait impliquer que le proposant crée une partie du bloc (soit le début, soit la fin) et délègue le reste à un constructeur. Toutes ces conceptions et fonctionnalités ne sont pas mutuellement exclusives, il s'agit plutôt d'équilibrer leurs avantages et leurs inconvénients.

L'approche de relais optimiste

Une autre approche de l'ePBS exploite nos relais de confiance existants. L'idée est de réduire progressivement les responsabilités du relais jusqu'à ce qu'il serve principalement d'optimiseur, plutôt que de composant crucial. Dans sa première phase, nous nous déchargeons de la responsabilité du relais de vérifier la validité du bloc. Cela réduit considérablement le coût de fonctionnement d'un relais car il n'est plus nécessaire de simuler un bloc pour garantir sa validité. De plus, cela rationalise le rôle du relais, réduisant d'environ 100 à 200 millisecondes la latence dans leurs communications avec les proposants et les constructeurs. Alors, comment garantir que le proposant reçoit son paiement si un bloc s'avère invalide ? Les constructeurs seraient tenus de fournir une garantie, égale à leur enchère, lorsqu'ils soumissionnent. Si le bloc est invalide, la garantie couvre le paiement que le proposant aurait reçu. Ce concept est appelé Relais Optimiste V1.

Relais Optimiste V1

En poussant le relais optimiste un pas de plus vers la V2, nous pouvons éliminer le besoin de télécharger le bloc, réduisant ainsi de 50 à 100 millisecondes de latence. Les mêmes garanties s'appliquent : si un bloc n'est jamais téléchargé, la garantie du constructeur est activée.

Relais Optimiste V2

Finalement, l'objectif final du relais optimiste ressemble beaucoup au modèle de comité de ponctualité de la charge utile dont j'ai parlé plus tôt. Voici la séquence : les constructeurs soumettent leurs offres sur une couche pair à pair. Le proposant accepte une offre et fait un suivi avec un en-tête signé. Ensuite, le constructeur déploie le bloc. À ce stade, le rôle du relais consiste uniquement à superviser le mempool de la couche pair à pair, en chronométrant essentiellement les différentes activités. Le rôle du relais devient très léger, il suffit de garder un œil sur le mempool. Cela fait fonctionner le relais de manière très similaire au comité de ponctualité de la charge utile. Toutes ces étapes visent à un avenir où le relais est remplacé par le comité de ponctualité de la charge utile, rationalisant l'ensemble du protocole.

Utilisation des constructeurs pour des améliorations de protocole supplémentaires

PBS est apparu en réponse de la part de Flashbots aux effets de centralisation de l'EMV, visant à tenter d'exploiter l'EMV pour des résultats positifs. Étant donné le nouveau rôle dans Ethereum spécialisé dans la construction de blocs, il y a une opportunité pour ces entités d'agir comme des supercalculateurs, contrastant avec les validateurs légers. Des conceptions de protocole émergent qui capitalisent sur ces constructeurs puissants. L'idée est de maintenir les validateurs simples et directs (certains pourraient même dire cucks) , tandis que les constructeurs, n'ayant pas de telles restrictions, peuvent fonctionner à un niveau de calcul beaucoup plus élevé. Une application principale pour ces constructeurs améliorés est la mise à l'échelle.

La conception Danksharding du chercheur en Ethereum Dankrad Feist suggère que ces constructeurs à forte intensité de ressources peuvent construire un gros bloc contenant toutes les données. Ces données sont ensuite segmentées et validées par de multiples engagements KZG. La construction de ce bloc nécessite des ressources considérables, mais leur validation est relativement peu coûteuse. Des validateurs légers peuvent ensuite appliquer l'échantillonnage de disponibilité des données pour inspecter une petite section du bloc et être presque certains de l'accessibilité de l'ensemble des données, offrant un ajout d'environ 16 fois plus de débit de données à partir de Proto-Danksharding. Les subtilités du Danksharding sont complexes et ne sont pas couvertes ici, mais le point clé est que ces constructeurs avancés peuvent se voir confier des rôles supplémentaires pour renforcer davantage le réseau.

Une autre idée pour tirer parti des constructeurs est la réalisation potentielle de rollups basés. Il y a quelques années, Vitalik a discuté des modèles de séquençage des rollups, en inventant le terme Total Anarchy pour l'un d'entre eux, dans lequel n'importe qui peut publier un bloc rollup et la première séquence qui atteint la chaîne est le bloc officiel. Cette approche présentait de nombreux inconvénients, tels que le spam onchain et l'ambiguïté sur la séquence gagnante. Cependant, l'article récent de Justin Drake sur rollups basésa mis en évidence une stratégie plus efficace tirant parti des constructeurs. Dans ce modèle, le constructeur de la première couche fonctionne comme le séquenceur rollup, sélectionnant soigneusement la séquence optimale à inclure onchain. Cela garantit que seules les séquences optimales sont incorporées.

Au-delà des rollups, l'introduction de constructeurs puissants peut stimuler d'autres structures innovantes, comme les clients sans état. Ils permettent aux nœuds de fonctionner comme d'habitude, mais sans le fardeau de conserver des états obsolètes. Cela permet aux nœuds d'être plus légers et de dépendre de la capacité du constructeur à générer des preuves cryptographiques spécifiques.

PEPC: Engagements de proposition imposés par le protocole

Les engagements des proposants imposés par le protocole (PEPC, prononcé pepsi) est un concept introduit par le chercheur de la Fondation Ethereum Barnabé Monnot en octobre 2022. Vous pouvez approfondir le post original de Barnabé ici. Au cœur de PEPC, l'objectif est de donner aux proposants un plus grand pouvoir dans la construction de blocs, qu'ils ont perdu en confiant l'ensemble de la tâche à des constructeurs spécialisés. Dans PEPC, les proposants peuvent ajouter des conditions supplémentaires pour qu'un bloc soit considéré comme valide, en plus des exigences habituelles d'Ethereum. Si un bloc ne satisfait pas à l'une de ces conditions supplémentaires, il est considéré comme invalide, et les attesteurs devraient le rejeter. Cela diffère des engagements d'EigenLayer où les validateurs avec des engagements supplémentaires perdent soit une partie des ETH mis en jeu pour non-conformité, soit sont récompensés pour les avoir remplis. Cependant, le bloc reste valide quel que soit ces engagements.

Imaginez qu'Alice est une proposante dans le réseau Ethereum. Avec PEPC, Alice a la flexibilité de prendre un engagement spécifique pour le bloc à venir. Elle pourrait s'engager à ce que son bloc contienne au moins trois transactions relatives à un contrat intelligent particulier, et elle est prête à allouer 70 % du gaz du bloc pour celles-ci. Elle communique cet engagement, qui devient une partie des conditions de validité de son bloc. Maintenant, Bob, un Constructeur, voit l'engagement d'Alice. Il regroupe un ensemble de transactions correspondant aux critères d'Alice et les lui envoie. Si le bloc d'Alice, une fois construit, correspond à son engagement (c'est-à-dire contient les transactions spécifiées consommant le gaz désigné), alors le bloc est jugé valide et peut être ajouté à la blockchain. Sinon, le bloc d'Alice ne sera pas accepté, garantissant qu'elle respecte ses engagements déclarés.

Une différence clé entre ePBS et PEPC réside dans la nature des engagements. Dans ePBS, les proposants et les constructeurs suivent une procédure fixe et uniforme. C'est une sorte d'approche taille unique. Un proposant s'engage à un hachage de bloc spécifique, et le constructeur produit alors une charge correspondante. Cependant, PEPC introduit de la variété. Chaque proposant peut définir des conditions uniques, offrant beaucoup plus de flexibilité. Il est crucial de noter que l'existence de PEPC dépend d'ePBS, ils se complètent mutuellement. Le fonctionnement exact de PEPC est encore en cours de discussion et de recherche.

Conclusion

PBS n'est pas une implémentation spécifique, c'est une philosophie de conception. Il affirme qu'il existe des incitations à la division du travail et que les acteurs du protocole délègueront certaines responsabilités à des entités externes plus spécialisées. L'objectif du protocole est d'offrir une interface fiable, aussi décentralisée que possible, pour garantir que cette délégation se déroule de manière fluide, équitable et inclusive. Sans cela, certains acteurs pourraient avoir un avantage, ce qui entraînerait les problèmes de centralisation observés pour la première fois avec MEV avant l'ère de PBS. Au cœur de PBS, l'accent est mis sur l'équité et la décentralisation. Alors que les éléments exacts à intégrer dans le protocole seront vus dans les futures mises à jour d'Ethereum, l'objectif global d'Ethereum reste clair : informatique étatique accessible, ouverte et digne de confiance, supervisée par un groupe décentralisé de validateurs légers.

Avertissement：

1. Cet article est repris de Miroir]. Tous les droits d'auteur appartiennent à l'auteur original [Chaskin Chaîne]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe Gate Learn, 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 interdit.