La (résistance à la) censure faible - Censorship.wtf

Source : https://www.youtube.com/watch?v=sTfATirYqGA

La (résistance à la) censure faible - Censorship.wtf

Définitions

Définition de la censure (0:50)

La censure peut être vue comme un "test d'ajout". Si une transaction publiquement disponible n'a pas été ajoutée à un bloc, demandez si elle aurait pu être ajoutée à la fin de ce bloc :

  • Si oui, elle a été censurée.
  • Si non, alors elle n'a pas été censurée (par exemple : transaction invalide, bloc plein, validateur hors ligne)

Censure faible et forte (1:45)

Il y a 2 types de censure :

  • Censure faible - La transaction est retardée de quelques secondes/minutes mais finit par être ajoutée sur la chaîne.
  • Censure forte - La transaction est définitivement bloquée pour être ajoutée sur la chaîne. Cela équivaut à une attaque à 51%.

Jusqu'à présent sur Ethereum, il n'y a eu que de la censure faible et aucun cas observé de censure forte/permanente. Cet exposé se concentrera sur la censure faible qui provoque des retards de transaction.

Chaîne d'approvisionnement de la MEV (2:30)

La chaîne d'appro de la MEV commence avec l'utilisateur et se termine avec l'attesteur.

  • L'utilisateur et le wallet sont dans le "domaine privé" off-chain, on ne peut pas faire grand-chose à ce sujet.
  • La censure faible provient du milieu, du chercheur au proposeur.
  • La censure forte vient des attesteurs/validateurs, équivalent à une attaque à 51%.

La censure faible se produit entre le domaine privé de l'utilisateur et les attesteurs, des chercheurs identifiant des opportunités MEV aux proposeurs incluant ou excluant certaines transactions.

Nous nous concentrerons sur la façon dont la censure faible survient dans la partie chercheur-proposeur

Problèmes

Vue d'ensemble (3:20)

En réalité, la latence est le problème auquel les gens pensent immédiatement, mais c'est le moins important.

Le plus important est les mimétiques d'inclusion, du moins selon Justin Drake (l'intervenant).

Latence d'inclusion (4:00)

Formule de latence d'inclusion : on prend la latence normale (par exemple 12 secondes) et on divise par la fraction de blocs non censurés.

Cela montre comment la censure augmente la latence. Exemple : Si seulement 25 % des blocs ne sont pas censurés, la latence est multipliée par 4x le temps de bloc. Cela affecte les transactions Tornado Cash aujourd'hui, car environ 75 % de censure signifie une latence augmentée de 4x.

La bande passante d'inclusion affecte les rollups. Si un rollup est censuré, il ne peut utiliser que l'espace de bloc non censuré.

Exemple : Si 25 % des blocs ne sont pas censurés, un rollup affecté ne peut utiliser que 25 % de la bande passante/capacité (comme Aztec).

Une latence accrue peut être tolérée, mais une bande passante/capacité réduite affecte gravement les rollups et c'est un problème plus important que la latence.

Mimétiques (6:00)

Le plus gros problème avec la censure faible est la perception négative et la "mauvaises pub" d'avoir la majorité des blocs Ethereum censurés.

Cela donne l'impression que les gouvernements ont une influence indirecte sur Ethereum. La censure est perçue négativement, donc c'est mauvais pour l'image et le marketing d'Ethereum. Cela a été utilisé pour critiquer Ethereum par des journalistes, des bitcoiners, etc.

Résoudre la censure est important parce que la résistance à la censure est le début d'une "chaîne mimétique" menant à la légitimité sociale et à une "prime" monétaire.

La censure sur le layer 1 à l'heure actuelle (7:20)

Actuellement, 5 des 6 principaux constructeurs/validateurs Ethereum (60 %+ des blocs) censurent des transactions.

Au total, environ 75 % de l'espace de bloc Ethereum est censuré par les principaux constructeurs/validateurs.

Situation précaire (7:50)

L'état de la censure s'aggrave, avec des constructeurs auparavant neutres comme Beaver et Gambit qui commencent récemment à censurer des transactions.

La part des blocs neutres et auto-construits diminue également avec le temps, à mesure que de plus en plus de validateurs activent MEV-boost au lieu de s'auto-construire.

Les chercheurs ont beaucoup de pouvoir : si un chercheur majeur comme Citadel ne fournit des flux de lots qu'à des constructeurs censeurs, les constructeurs neutres seront obligés de fermer.

Si les principaux chercheurs commencent à orienter les lots exclusivement vers les constructeurs censeurs, cela pourrait conduire à l'éradication des constructeurs neutres, avec seulement 6% d'espace de bloc neutre restants provenant des validateurs qui construisent des blocs eux-mêmes.

Solutions

Overview (10:15)

Il existe 4 solutions qui peuvent aider à résoudre la censure :

  • Mempools encryptées : Donne aux utilisateurs la possibilité de chiffrer des transactions pour résister à la censure.
  • Listes d'inclusion : Donne aux proposeurs le pouvoir d'inclure de force certaines transactions
  • MEV Burn : Oblige les proposeurs à choisir les blocs les plus précieux, rendant la censure coûteuse.
  • Enshrined PBS : Permet aux relais d'éviter la censure en disparaissant si nécessaire.

Enshrined PBS (11:45)

L'idée de l'ePBS est de supprimer complètement les relais, de sorte que la censure des relais tombe à zéro (aussi simple que cela).

Listes d'inclusion anticipées (12:00)

Les proposeurs peuvent s'auto-construire un modèle de bloc que le constructeur suivant doit inclure toutes les transactions, mais peut les réorganiser/ajouter des transactions.

Sans listes d'inclusion, l'espace de bloc neutre est simplement ce que les constructeurs neutres produisent. Avec les listes d'inclusion, il y a un espace de bloc neutre supplémentaire provenant des proposeurs forçant des transactions dans les blocs.

Exemple :

  • 50% constructeurs neutres
  • 50% proposeurs forçant l'inclusion

Le Total serait de 50% + 50% = 100%, mais il y a un chevauchement de 25%. Donc l'espace net de bloc neutre/non censuré est de 75%.

Les listes d'inclusion peuvent augmenter de manière significative l'espace de bloc neutre/non censuré au Layer 1 au-delà de ce que les constructeurs neutres créent.

Mempools encryptées (13:30)

Actuellement, le coût de la censure est très faible. En fait, il s'agit seulement des petits pourboires de quelques transactions censurées.

Les mempools encryptées transforment le coût en la somme des pourboires de toutes les transactions chiffrées. Ainsi, les constructeurs censeurs doivent :

  • Inclure les transactions chiffrées, mais risquent d'inclure des transactions censurées.
  • Ou censurer toutes les transactions chiffrées.

Si la plupart des transactions sont chiffrées, les constructeurs doivent finalement tout censurer et ça leur coûte beaucoup plus cher.

MEV Burn (15:10)

Le MEV Burn ajoute les frais de base des transactions censurées au coût de la censure, en plus des pourboires.

Les pourboires sont d'environ 1 gwei par gaz, mais les frais de base sont d'environ 30 gwei par gaz. Donc le MEV Burn multiplie les coûts de censure par 30.

Combiné aux mempools encryptées, le coût total rendrait la censure non rentable pour les constructeurs.

Listes d'inclusion obligatoires (17:00)

Une idée supplémentaire est de maximiser les frais de base de la liste d'inclusion, d'une façon similaire au MEV Burn. Cela incite les proposeurs à inclure toutes les transactions dans les listes d'inclusion.

Malgré la situation précaire, Justin pense que ce n'est qu'une question de temps avant que ces solutions ne soient mises en œuvre et que la censure faible soit un problème résolu.