Vitalik imagine une solution à la censure – Le réseau Ethereum a récemment effectué une transition dans son mode de consensus. Ainsi, celui-ci est passé du Proof of Work au Proof of Stake. Cependant, cette transition a lancé une série de débats quant à sa décentralisation et sa résistance à la censure. Évidemment, Vitalik Buterin ne pouvait rester les bras croisés et s’est penché sur le problème.
Centralisation et censure sur Ethereum
Le 15 septembre dernier, la mise à jour The Merge a été déployée sur Ethereum. Celle-ci visait à faire passer le réseau du Proof of Work au Proof of Stake. Bien que cette mise à jour ait été longuement attendue par la communauté Ethereum, celle-ci n’a pas eu que des impacts positifs.
En effet, une quinzaine de jours après son déploiement, le chercheur Toni Wahrstätter a dévoilé un phénomène de censure sur le réseau.
Fonctionnement de la production des blocs sur Ethereum
Avant d’entrer dans le détail, il faut comprendre comment fonctionne cette nouvelle version d’Ethereum.
Suite au passage au Proof of Stake, le réseau se décompose en deux grandes entités :
- La couche d’exécution, qui représente toutes les applications sur Ethereum ;
- La couche consensus, qui opère le Proof of Stake et s’assure de la validation des blocs.
Chacune de ces entités fonctionne grâce à un logiciel communément appelé client. Ainsi, il existe des clients différents pour la couche d’exécution et la couche de consensus. Évidemment, ces deux types de clients communiquent ensemble pour faire fonctionner le système.
Ces deux entités interagissent de la manière suivante. Les transactions ont lieu sur la couche d’exécution et sont envoyées dans la mempool. Les clients de la couche d’exécution (la plupart du temps geth) vont récupérer les transactions en attente, former des blocs avec ces transactions et proposer ces blocs aux clients de la couche de consensus. Les clients de la couche consensus auront pour mission de vérifier et valider ces blocs.
Du moins, c’est ainsi que cela se passe hors MEV.
Le cas du MEV
Le MEV ou Maximum Extractible Value représente la valeur maximale qui peut être extraite lors de la production d’un bloc. Cette valeur est issue de la modification, l’ajout ou la suppression de transactions dans un bloc.
Ainsi, avec un réseau en Proof of Work, plutôt que de laisser les mineurs piocher dans la mempool, les utilisateurs avaient la possibilité d’utiliser les outils développés par FlashBots. Cela leur permettait de proposer des transactions directement aux mineurs afin d’optimiser la MEV.
Cependant, ce modèle a désormais évolué avec le passage au Proof of Stake et la création de Mev-Boost.
Sans trop entrer dans les détails, Mev-Boost permet aux validateurs d’accéder à une marketplace de blocs déjà construits par des logiciels appelés Block Builders. Ces blocs déjà prêts à l’emploi ont déjà été optimisés vis-à-vis de la MEV.
Par la suite, ces blocs sont envoyés à un autre programme appelé « Relay » ou Relais. Ces relais vont alors identifier le bloc le plus rentable et le proposer aux validateurs de la couche de consensus. Ces derniers vont ensuite finaliser le travail en vérifiant et en ajoutant le bloc à la chaîne.
Notons qu’il existe de nombreux relais différents, opérés par différentes entités (entreprise, fondation, etc.). Notons également que les acteurs opérant des relais opèrent également des Block Builders.
La censure engendrée par Mev-Boost sur Ethereum
Revenons à nos moutons. Comme nous l’introduisions plus tôt, le chercheur Toni Wahrstätter a identifié un important problème de censure dans la production des blocs.
Ainsi, celui-ci a découvert que le relais Mev-Boost opéré par la société FlashBots censure de manière systématique les transactions ayant un lien avec le protocole Tornado Cash.
Bien que ce phénomène ne représente que 23% des blocs, celui-ci reste tout de même alarmant. En effet, nous sommes dans une situation de censure au niveau de la production des blocs, une situation inacceptable pour un écosystème qui prône la résistance à la censure.
Sans grande surprise, ce problème a rapidement été au cœur des débats communautaires.
Vitalik imagine une solution au problème de censure
Le 1er octobre, Vitalik Buterin a décidé d’apporter sa pierre à l’édifice en publiant un article intitulé « Dans quelle mesure pouvons-nous contraindre les constructeurs sans faire peser de lourdes charges sur les proposants ? » visant à présenter des pistes pour mettre fin à cette censure.
Dans son article, il explique qu’une des méthodes pourrait être de restreindre le pouvoir qu’ont les Block Builders.
« Au lieu que les constructeurs aient les pleins pouvoirs pour construire le bloc entier s’ils gagnent une enchère, les constructeurs auraient un pouvoir plus limité. Ce pouvoir devrait toujours être suffisant pour capturer la quasi-totalité du MEV qui pourrait être capturé, et il devrait idéalement toujours être suffisant pour capturer d’autres avantages du PBS, mais il devrait être affaibli pour limiter les possibilités d’abus. »
En d’autres termes, Vitalik propose de ne plus permettre aux Block Builders de décider de l’intégralité d’un bloc. Ainsi, il souhaite leur permettre de décider uniquement une partie du contenu des blocs. Et pour cela, il propose plusieurs méthodes.
Listes d’inclusion
La première méthode proposée par Vitalik vise à créer des listes d’inclusion ou inclusion lists. Pour cette méthode, le « proposer » (le validateur qui a été sélectionné pour proposer un bloc) fournit une liste de transactions qui doivent être incluses dans le bloc par le Block Builder. Ainsi, le Block Builder doit ajouter ces transactions, à moins qu’il puisse produire un bloc composé entièrement avec d’autres transactions.
Par conséquent, un Block Builder qui maximise les profits ne rencontrera pas de contrainte. En effet, ajouter des transactions supplémentaires à son bloc ne va pas impacter le Builder. En parallèle, dans le cas où le bloc serait déjà rempli, le Builder devra choisir entre ces transactions et d’autres, la contrainte serait désactivée. Selon Vitalik, « cela n’affecte pas l’inclusion desdites transactions à long terme, car une série de blocs pleins ne peut être soutenue que brièvement.
Toutefois, si un constructeur a le désir de refuser d’inclure des transactions spécifiques qu’il désapprouve ou qu’il est incité à exclure, ce constructeur serait contraint de ne pas participer à l’enchère. »
Le suffixe du validateur via pré-engagement
Cette méthode permet au validateur en charge de la production du bloc de créer un suffixe pour le bloc. En pratique, le validateur va préengager un ensemble de transactions qu’il veut inclure.
De son côté, le Block Builder crée son bloc et le soumet au validateur. Le validateur va ensuite ajouter le suffixe constitué de l’ensemble des transactions qu’il veut inclure et qui n’a pas été ajouté par le Block Builder dans le bloc.
« Le constructeur ne verrait aucune information sur les intentions du validateur lorsqu’il construit un bloc, et le proposant serait en mesure d’ajouter à la fin toute transaction que le constructeur aurait manquée. »
Malheureusement, aucune de ces solutions n’est parfaite. Ainsi, Vitalik Buterin estime qu’il pourrait être intéressant de mettre en place un troisième acteur tiers.
« La nécessité simultanée de minimiser les pouvoirs et les informations dont dispose le constructeur, et la charge imposée au validateur semblent indiquer clairement la nécessité d’un troisième acteur dans le pipeline de production des blocs (à moins que nous ne prenions le taureau par les cornes et acceptions que les constructeurs aient le droit de voir la liste d’inclusion, et donc de discriminer contre des transactions particulières incluses dans le même créneau). Nous devrions commencer à réfléchir plus profondément à la façon dont cela va être géré. »
Comme nous pouvons le voir, il n’existe pas de solution magique au problème de censure sur Ethereum. Cependant, les développeurs peuvent explorer des pistes pour minimiser le problème et réduire le pouvoir des Block Builders.
Évidemment, The Merge a également eu des impacts positifs sur Ethereum. Ainsi, depuis le passage au Proof of Stake, le temps de bloc a diminué de près de 10%, augmentant de fait le nombre de blocs produits chaque jour.
