Unichain - Sponsor Image Unichain - Faster swaps. Lower fees. Deeper liquidity. Explore Unichain on web and wallet. Friend & Sponsor Learn more

Guide du débutant sur la censure de l'Ethereum

Ethereum n'est pas à l'abri de la censure... pour l'instant. Voici ce que font les développeurs à ce sujet.
Guide du débutant sur la censure de l'Ethereum
38
0

Subscribe to Bankless or sign in

Chère nation sans banque,

Les régulateurs s'attaquent aux crypto-monnaies.

Mais DeFi, c'est bien parce que c'est décentralisé, n'est-ce pas ?

Umm... non. Malheureusement, il existe encore trop de vecteurs centralisés.

Et lorsque les régulateurs frapperont, c'est là qu'ils viseront.

Si nous voulons un Ethereum Ethereum qui fonctionne, nous devons d'abord mieux comprendre les faiblesses de DeFi.

Nous avons fait un podcast le mois dernier avec Justin Drake Justin Drake qui détaille cela. (📺 Regardez-le ici !)

La newsletter d'aujourd'hui est une distillation de ce pod en un guide 101 pour comprendre la dynamique de censure à travers Ethereum.

Donovan résume tous les points d'étranglement centralisés, puis comment Ethereum ouvre la voie à un avenir résistant à la censure.

Il est temps de commencer à construire.

- L'équipe Bankless


Le 8 août 2022, le Trésor américain a sanctionné Tornado Cash.

Tout le monde sait que les régulateurs détestent les crypto-monnaies, mais les sanctions ont pris DeFi par surprise. Il s'agissait d'un effort sans précédent de la part des régulateurs américains pour attaquer officiellement les crypto-monnaies.

D'une certaine manière, les sanctions contre Tornado Cash Tornado Cash ont été une bénédiction déguisée. Le choc réglementaire a rappelé à DeFi ses principes fondamentaux et a ouvert la voie à un examen minutieux de tous les points d'étranglement centralisés du paysage financier décentralisé.

Surprise, surprise : la décentralisation est vraiment importante.

Tout raccourci de centralisation que vous prenez peut être et sera utilisé contre vous.

Le sujet de la censure est difficile à suivre. Essayer de comprendre les préoccupations autour de la centralisation d'Ethereum nécessite des connaissances techniques, et la mer de jargon cryptographique est incroyablement difficile à parcourir.

Cet article est une tentative de démystifier tous les problèmes de censure sur Ethereum au cours des derniers mois, et de les distiller en termes facilement compréhensibles pour n'importe quel citoyen crypto (ou même les haters !).

J'expose tous les principaux vecteurs de centralisation sur le protocole Ethereum, et je parle brièvement des différentes solutions techniques et de marché sur lesquelles les entrepreneurs et les développeurs travaillent.


⛓️ Un bref résumé de la chaîne d'approvisionnement d'Ethereum

L'Ethereum, tel qu'il a été conçu à l'origine, n'impliquait en théorie que deux acteurs : un utilisateur pour gérer son propre nœud qui enverrait des transactions sur le réseau peer-to-peer à des validateurs de blocs qui construiraient un bloc et incluraient la transaction.

Les validateurs de la blockchain (que nous appelons mineurs dans PoW, stakers dans PoS) étaient censés être des participants neutres validant les blocs.

Dans la pratique, ce processus est beaucoup plus complexe. Les validateurs sont confrontés à des incitations perverses à la discrimination en vendant des blocs à des chercheurs qui utilisent des robots d'arbitrage. Il en résulte des coûts de transaction plus élevés et une congestion de la blockchain pour les utilisateurs moyens - un phénomène connu sous le nom de valeur maximale extractible (VME). La VME s'est élevée à 675 millions de dollars sur Ethereum au cours des deux dernières années(estimée à 6,7 millions de dollars sur Cosmos).

Dans l'Ethereum post-fusion, voici l'ordre général des transactions :

  1. Les utilisateurs créent des transactions avec un portefeuille via le frontend d'une dapp. Ces transactions sont envoyées au mempool.

  2. Les chercheurs lancent des robots d'arbitrage et analysent le pool de mémoire, puis regroupent les transactions

  3. Les transactions regroupées sont transmises aux constructeurs de blocs, qui y ajoutent des offres de frais.

  4. Si les constructeurs et les validateurs sont tous deux connectés à un relais , ce dernier est alors chargé de dissimuler le bloc regroupé avant de le proposer aux enchères.

  5. Les validateurs (également appelés proposants de blocs) choisissent les offres de frais et proposent le bloc.

    1. Les assesseurs attestent les blocs avant qu'ils n'entrent finalement dans la chaîne.

⚠️ Dans cet article, les termes "validateurs" et "proposants" sont utilisés de manière interchangeable.

Des vecteurs de centralisation existent à chaque étape de cet ordre transactionnel.

Examinons-les dans l'ordre, en commençant par le frontend.


💁‍♂️ 1. Interfaces frontales

Vous voulez acheter de l'ETH. Vous vous rendez sur uniswap.com, où une interface utilisateur rose et blanche élégante vous attend pour vous aider à naviguer facilement dans votre transaction. Vous connectez MetaMask, choisissez votre pool de liquidité et cliquez sur "envoyer" pour exécuter votre transaction. Nous prenons ce processus simple pour acquis, mais il y a déjà de nombreuses menaces de centralisation qui font surface sur ces intermédiaires.

⚠️🛑 La menace de la censure

La réalité de nombreuses interfaces frontales de dapp aujourd'hui est qu'elles sont centralisées. La courte histoire de Web3 a montré que lorsque les régulateurs viennent frapper, DeFi répond à la porte. C'est ce qui s'est passé lorsque Balancer a caché un pool de liquidités de 20 millions de dollars dans son interface, ou lorsque Uniswap Uniswap Labs a rapidement retiré de la liste des dizaines de jetons dérivés synthétiques dans son interface afin d'éviter l'examen de la SEC. MetaMask MetaMask et Infura ont fait de même pour bloquer les adresses des portefeuilles conformément aux sanctions imposées par Tornado Cash.

Passer le frontend n'est que la partie émergée de l'iceberg. Les applications que nous utilisons s'appuient sur des nœuds RPC (serveurs) pour communiquer les intentions de l'utilisateur. Les nœuds sont un point de connexion - pensez-y comme une API - qui accède aux informations, communique et exécute des transactions sur la blockchain.

Dans un monde idéal, chacun gérerait ses propres nœuds. Mais comme l'a souligné le fondateur de Signal, Moxie Marlinspike, dans une critique de Web3, la plupart des gens ne gèrent pas leurs propres nœuds, ce qui crée une dépendance à l'égard de fournisseurs de services de nœuds centralisés tels qu'Infura Infura et Alchemy. Ils ont rendu la vie de DeFi beaucoup plus facile, mais comme vous le savez, il y a des compromis. Étant donné qu'un large éventail de dapps comme Uniswap et Metamask dépendent à leur tour d'Infura pour faire fonctionner les nœuds, un vecteur de centralisation important a émergé de ce côté.

Une entreprise centralisée comme Infura, si elle était ciblée par les régulateurs, provoquerait des perturbations majeures sur Ethereum. C'est d'ailleurs ce qui s'est produit lorsqu'Infura a banni les adresses IP iraniennes pour se conformer aux sanctions politiques américaines en mars. Des raisons techniques expliquent également pourquoi les fournisseurs de nœuds centralisés posent problème. Ethereum a connu une telle panne de réseau en novembre 2020, lorsque de nombreux dapps sont devenus inutilisables après que l'API du réseau principal d'Infura a cessé de fonctionner parce que son client Geth n'était pas à jour.

Enfin, les nœuds doivent être hébergés quelque part. En réalité, de nombreux nœuds Ethereum sont hébergés chez des fournisseurs de services en nuage centralisés comme AWS, Hetzner et Google Cloud (comme c'est le cas pour Solana et Bitcoin). Le vecteur de centralisation est ici évident : les fournisseurs de services en nuage peuvent arbitrairement interrompre les opérations des serveurs. La communauté a reçu ce même rappel en août lorsque Hetzner a précisé que l'exécution de nœuds Ethereum sur ses serveurs constituait une violation de ses conditions de service.

Source : ethernodes.org

Autant de vecteurs de centralisation, et nous n'avons même pas encore abordé le mempool.

Qu'est-ce qu'on fait ?

💡 Solution #1

La centralisation frontale est un problème, mais un problème relativement faible. Ceci est dû à un écosystème de middleware DeFi en plein essor qui nous permet de contourner les frontends censurés par le biais de sites alternatifs de différentes manières. Les exemples incluent les trackers de portefeuille comme Zapper et Zerion, les portefeuilles de crypto-monnaies avec des fonctionnalités intégrées de "swapping", les agrégateurs de DeFi comme 1inch et Paraswap. Ils vous permettent d'accéder aux dapps sans avoir à les visiter directement. La plupart des dapps, comme Uniswap, se sont également engagées à ouvrir le code de leurs frontends, ce qui permet à n'importe quel individu ou même à une DAO spécialisée de recréer le frontend.

Pour contourner les frontends censurés, des fournisseurs de stockage décentralisés comme IPFS sont également utilisés pour héberger des domaines de frontend au contenu statique. Pour les frontends à contenu dynamique (médias sociaux), des protocoles d'indexation décentralisés comme The Graph sont utilisés pour interroger les données à travers les blockchains et les dapps au moyen d'un langage d'interrogation unifié. Et pour les domaines censurés, les services de domaine décentralisés comme ENS ENS offrent un moyen plus résistant à la censure d'héberger des domaines en les construisant sur des contrats intelligents Ethereum. Contrairement à la plupart des sites web actuels qui sont stockés sur des serveurs DNS centralisés, et donc sujets à la saisie de noms de domaine ou au blocage d'adresses IP.

Mis ensemble, ces protocoles d'infrastructure décentralisés font les blocs de construction fondamentaux d'une économie Web3 décentralisée pour les frontaux DeFi.

Solution n° 2

En abordant le problème de la centralisation des nœuds, la solution technique clé sont les clients légers. Le hard fork d'Ethereum Altair a ouvert la voie à ces derniers. Ces clients ultra-légers nous permettent de créer notre propre version souveraine et native d'Ethereum sur nos propres ordinateurs, appareils mobiles ou navigateurs web, à laquelle nous pouvons diffuser des transactions et faire des demandes à n'importe quel nœud complet qui accepte les requêtes des clients légers. Ce faisant, les dapps peuvent faciliter les transactions au lieu d'appeler un point de terminaison RPC centralisé comme Infura ou Alchemy.

Les clients légers n'essaient pas de récupérer la totalité de la chaîne Beacon ou de l'ensemble des validateurs. Cela nécessiterait des calculs intensifs - d'où le nom "light" ! Ils synchronisent simplement les en-têtes de blocs en connaissant les nœuds homologues. La clé est que ce processus est effectué sans confiance par des groupes de validateurs attribués de manière aléatoire (comités de synchronisation). Les clients légers PoS de la chaîne de balises sont également beaucoup plus simples à construire que les clients légers PoW. Avec seulement quelques nœuds complets non censurés qui répondent à ces requêtes, les problèmes de centralisation des nœuds sont atténués. Pour en savoir plus sur les clients légers, voir ici.

💡 Solution #3

Dans la mesure où nous voulons nous appuyer sur des fournisseurs de nœuds externes, il existe des alternatives décentralisées comme Pocket Network ou Ankr qui minimisent le besoin d'Infura.

Rappelons que le problème ici est le manque d'incitation à gérer ses propres nœuds. Ces fournisseurs de nœuds RPC introduisent des incitations économiques à le faire. Avec Pocket Network, par exemple, les fournisseurs de nœuds misent des POKT pour faire fonctionner des nœuds de blockchain et relayer des données entre différentes blockchains, en fournissant des services aux dapps qui demandent des données sur la chaîne. Dans ce marché sans permission, plus ils servent de relais, plus ils gagnent en récompenses POKT. Du côté de la demande, les utilisateurs/apps misent également sur POKT, ce qui leur permet de demander des relais sur le réseau. Il est à noter que des points de centralisation existent au sein même de ces projets, mais qu'il existe une feuille de route pour les supprimer.

Source : Sami Kassab : Sami Kassab

💡 Solution #4

Le problème de l'hébergement des nœuds est un risque de centralisation qui doit être constamment surveillé, mais ce n'est pas une grande menace en raison des faibles barrières de sortie. Si AWS décide de restreindre l'hébergement de nœuds sur ses serveurs cloud, les opérateurs de nœuds peuvent facilement passer à un autre serveur cloud sans être enfermés nulle part. Grâce à la fusion, la mise en place de votre propre nœud est encore plus facile aujourd'hui avec du matériel de bricolage (Raspberry Pi) et des solutions plug & play (Avado).


📡 2. Chercheurs

Une fois que les transactions des utilisateurs ont été soumises avec succès, il entre dans le mempool, abréviation de "memory pool". Le mempool est une base de données de transactions en attente qui ont été soumises par des utilisateurs comme vous et moi, parfois appelée la "forêt sombre 🌳" d'Ethereum. C'est ici que les jeux MEV commencent.

Une fois que les transactions sont dans le mempool, les chercheurs commencent à scanner la forêt sombre pour trouver des opportunités MEV rentables. Les chercheurs sont généralement de grandes institutions et des bureaux de trading propriétaires qui utilisent des robots d'arbitrage, mais parfois aussi des particuliers. Ils paient des frais d'essence élevés pour que les validateurs acceptent leurs ordres de transaction au lieu de passer par le pool public.

Il convient de noter ici que, bien que l'on parle généralement du MEV comme d'une chose exclusivement mauvaise , il y a aussi du bon MEV. Un protocole DeFi qui a besoin de liquider rapidement la garantie d'un prêteur dans un contexte de fluctuations volatiles du prix des crypto-monnaies veut payer des frais de gaz élevés pour s'assurer que sa transaction est exécutée rapidement. Si les blockchains étaient conçues sur la base du premier arrivé, premier servi, il y aurait des inefficacités extraordinaires dans DeFi. Les chercheurs jouent un rôle important dans l'égalisation de ces inefficacités et la construction de blocs efficaces.

En ce qui concerne le mauvais MEV, bien que les chercheurs ne constituent pas un risque de centralisation en soi, ils jouent un rôle en permettant un énorme vecteur de centralisation en s'associant avec les constructeurs de blocs. Leur rôle dans la couche de protocole consiste à regrouper les transactions et à les transmettre aux constructeurs de blocs dans l'échelon suivant de la forêt obscure.


🏗️ 3. Constructeurs de blocs et validateurs/proposants

Avant la séparation proposant-constructeur (PBS)

Dans l'Ethereum pré-Fusion, la construction des blocs était effectuée par une seule entité : les mineurs. Cela donnait aux mineurs le pouvoir de capitaliser sur l'arbitrage DEX et les liquidations en discriminant entre les transactions dans le pool de mémoire.

Au fil du temps, le problème s'est aggravé. Les chercheurs et les mineurs ont commencé à s'entendre sur un marché souterrain pour sélectionner le plus efficacement possible les transactions afin de maximiser leurs propres profits. Cela a fini par gonfler les coûts fixes des mineurs, car les grands exploitants de pools miniers disposant du capital nécessaire pour exécuter des algorithmes complexes ont surpassé les mineurs ordinaires, donnant ainsi naissance à ce que nous connaissons sous le nom de MEV. Au cours des deux dernières années, le MEV total extrait s'est élevé à ~675 millions de dollars sur Ethereum !

Les problèmes liés au risque de centralisation sont doubles : d'une part, ils nuisent aux utilisateurs d'Ethereum qui finissent par attendre plus longtemps ou par payer plus cher leurs transactions ; d'autre part, les validateurs de blocs bien capitalisés sont beaucoup plus à même de censurer les transactions en raison de la pression politique.

En réponse, les développeurs d'Ethereum mettent au point une solution in-protocole connue sous le nom de séparation proposant-constructeur (PBS). Comme son nom l'indique, la PBS divise le rôle de validateur en deux rôles natifs distincts :

  1. les proposants (c'est-à-dire les validateurs qui misent 32 ETH et construisent des blocs)
  2. Les constructeurs de blocs

Dans le cadre du PBS, les constructeurs de blocs sont en concurrence les uns avec les autres pour créer des listes ordonnées et agrégées de transactions provenant des chercheurs. Ces groupes de transactions sont optimisés pour maximiser les frais MEV du constructeur, qui sont ensuite répercutés sur le proposant du bloc. Les proposants sont incités à sélectionner les transactions sur la base des frais les plus élevés pour eux-mêmes afin de créer des blocs et de les envoyer au réseau pour qu'ils soient inclus dans la chaîne.

L'intérêt du PBS est de réduire le pouvoir centralisé de censure des auteurs de propositions de blocs, car la personne qui construit le bloc n'est pas la même que celle qui sélectionne les transactions à inclure dans le bloc. Comme le décrit Vitalik dans Endgame, le PBS vise à maximiser la décentralisation des validateurs.

Mais PBS est techniquement complexe et ne sera pas prêt avant plusieurs années (peut-être dans 2 à 8 ans !). La bonne nouvelle, c'est que des solutions provisoires sont apparues entre-temps pour résoudre le problème de la centralisation des validateurs.

Tout d'abord, dans le cadre de la fusion, les validateurs sont sélectionnés de manière aléatoire pour être les proposants de blocs dans chaque créneau. Contrairement à ce qui se passait dans le cadre du PoW antérieur à la fusion, où tous les mineurs s'affrontaient pour résoudre des énigmes mathématiques afin de valider les nouvelles transactions, les validateurs sont choisis au hasard. Une fois que l'un des 420 000 validateurs d'Ethereum a été sélectionné au hasard pour proposer un bloc, un autre comité de validateurs est choisi au hasard pour soumettre une attestation (vote) sur la validité du bloc proposé. Cette double couche de mélange aléatoire sert à freiner la centralisation des validateurs sur Ethereum, ce qui rend plus difficile pour un attaquant de censurer ou de perturber le réseau.

Deuxièmement, des entreprises comme Flashbots 🤖 sont intervenues pour créer artificiellement des PBS. Flashbots a développé un client logiciel(MEV-Geth pour PoW Ethereum, MEV-Boost pour PoS Ethereum) que les validateurs peuvent simplement brancher sur leur client de consensus et exécuter sur leurs nœuds. Cela a pour effet d'externaliser le travail de construction des blocs en le confiant à un constructeur spécialisé(séparation entre le proposant et le constructeur !).

Pourquoi utiliser les Flashbots ? Les validateurs le font tout simplement parce que c'est plus rentable pour eux en termes de récompenses. Le logiciel Flashbots distribue la valeur MEV plus équitablement entre les proposants et les constructeurs, plutôt que de la partager entre les grands pools miniers et les chercheurs. Flashbots contrecarre ce marché de collusion entre les chercheurs et les mineurs en créant un marché transparent et ouvert pour la découverte des prix. Selon Hasu, l'utilisation de MEV-Boost a permis d'augmenter de 135 % les récompenses des validateurs après la fusion.

Source : Flashbots

Il convient de noter que MEV-Boost est facultatif et que les validateurs peuvent toujours choisir de construire eux-mêmes des blocs sur leurs clients d'exécution.

À l'ère du PBS

PBS supprime le pouvoir de centralisation des grands validateurs. Mais même après la conception de PBS, nous n'avons pas encore atteint les terres promises de la décentralisation. Les vecteurs de centralisation, bien qu'atténués, existeront toujours dans un monde post-PBS. Le reste de cette section détaille brièvement les différentes menaces de censure auxquelles Ethereum est confronté et les solutions d'accompagnement en cours d'élaboration.

⚠️🛑 Menace de censure n° 1

Alors que PBS atténue les problèmes de centralisation précédents, il introduit également de nouveaux vecteurs de centralisation au niveau des constructeurs en leur donnant la capacité accrue de censurer les transactions. En créant un rôle de constructeur spécialisé, les constructeurs peuvent être en mesure de surenchérir pour les blocs et d'exclure certaines transactions.

Solution n° 1

La première solution est une liste de résistance à la censure (crList) ou ce que l'on appelle également un "PBS hybride". Supposons que nous soupçonnions que les constructeurs tentent de censurer les transactions. Nous le savons parce que les blocs qu'ils ont construits pour les proposants ne sont pas pleins et qu'il y a des transactions éligibles dans le mempool qui attendent d'être incluses.

Une crList permet aux proposants de forcer les constructeurs à utiliser pleinement l'espace de blocs vide, sans permettre aux proposants de dicter spécifiquement l'ordre des transactions à inclure : "Hé, constructeurs, veuillez remplir votre bloc vide ou les transactions que j'ai sélectionnées seront incluses".

Un constructeur qui persiste à censurer les transactions et à ignorer la crList d'un proposant se verra opposer un rejet du bloc par les attestateurs(les attestateurs sont des validateurs sélectionnés au hasard qui votent sur la tête de la chaîne canonique après que les validateurs proposant un bloc l'ont proposé). En bref, les crLists sont un mécanisme indirect qui permet aux proposants de contrôler un marché centralisé de construction de blocs sans aller à l'encontre de l'objectif même du PBS(décentraliser les proposants !).

Solution n° 2

Mais si les auteurs de propositions peuvent demander aux constructeurs d'inclure des transactions, que se passe-t-il s'ils s'entendent avec les constructeurs pour leur dire de ne pas le faire? Cela nous amène à la deuxième solution en cours d'élaboration : Le lissage MEV. Tout comme les crLists permettent de contrôler les constructeurs, le lissage MEV permet de contrôler les auteurs de propositions en leur retirant leur pouvoir discrétionnaire.

L'idée est de demander aux attestateurs d'être attentifs au marché de la construction de blocs, en particulier aux offres d'honoraires liées aux blocs, puis de n'attester que les blocs ayant fait l'objet de l'offre la plus élevée de la part des proposants. Si les proposants ne proposent pas les blocs les plus rentables déjà construits pour eux, c'est qu'il y a quelque chose qui cloche, et les attestateurs demandent alors : "Hé, proposant, détestez-vous simplement gagner de l'argent ou essayez-vous de vous censurer ?

En effet, le lissage MEV vise à égaliser les profits MEV pour tous les proposants et crée un marché parfaitement efficace, en supprimant l'incitation des proposants à s'engager dans une censure discriminatoire.

Solution n° 3

La troisième solution est l'utilisation de mempools cryptés. Alors que les crLists contrent les constructeurs, et que le lissage MEV contrent les proposants, les mempools chiffrés sont conçus pour contrer les deux. Ce mécanisme est facile à comprendre : il crypte le contenu des transactions d'un utilisateur et les adresses d'envoi et de réception avant qu'il n'entre dans le mempool, et n'est décrypté que lorsqu'il se trouve sur la chaîne. Il est donc difficile pour les acteurs de censurer ou de s'engager dans des techniques d'extraction de MEV comme le frontrunning des transactions. Il n'est donc plus nécessaire d'avoir recours à des mempools privés comme Flashbots Protect. La technologie mempool cryptée est quelque chose que les développeurs de Cosmos, Flashbots et les chaînes axées sur la confidentialité comme Aztec expérimentent également.

Solution #4

La quatrième et dernière solution est celle sur laquelle nous voulons le moins compter, mais qui est agréable à avoir : l'auto-construction altruiste, où les proposants choisissent simplement de construire leurs propres blocs, plutôt que de l'externaliser à un constructeur. L'avantage est qu'Ethereum peut continuer à fonctionner même avec une petite minorité d'environ 10 % de constructeurs altruistes.

L'inconvénient évident est que cela va à l'encontre des incitations économiques - rappelons que les validateurs veulent utiliser MEV-Boost parce qu'il génère plus de frais. C'est pourquoi il est important de promouvoir une culture de résistance à la censure et de préserver la décentralisation au niveau social.

⚠️🛑 Menace de censure #2

Pour participer en tant que validateur Ethereum aujourd'hui, vous devez miser 32 ETH dans un contrat de dépôt tout en exécutant deux clients logiciels : un client d'exécution(pour exécuter les transactions) et un client de consensus(pour atteindre le consensus sur les blocs nouvellement produits). La menace actuelle est que trop de validateurs utilisent le même client d'exécution Geth.

Source : clientdiversity.org

Cette situation accroît le risque d'interruption du réseau si un client est victime d'un bogue ou d'une attaque. Il ne s'agit pas d'une spéculation théorique, comme l'a montré l'attaque DOS de Shanghai en 2016, lorsque les attaquants ont trompé le client Geth en ralentissant le traitement. Sur l'Ethereum post-fusion, une supermajorité de ⅔ des ETH mis en jeu est nécessaire pour finaliser la transaction. Le dysfonctionnement d'un client dominant pourrait temporairement bloquer (ou pire : diviser) le réseau Ethereum - c'est pourquoi il est essentiel qu'un client donné ne soit pas exécuté sur plus de ⅔ des nœuds de validation !

Le problème de la concentration de clients est si aigu que même les entreprises qui utilisent le plus de clients, comme Prysmatic Labs, recommandent aux validateurs de nœuds d'"utiliser leurs concurrents". Après tout, si Ethereum tombe en panne, c'est une perte pour tous.

💡 La solution

Notez que les menaces de censure s'appliquent ici non seulement aux solo stakers, mais aussi aux fournisseurs de nœuds centralisés comme Infura et Alchemy, ou aux fournisseurs de nœuds décentralisés comme Pocket Network. Les solutions que les développeurs d'Ethereum ont mises en œuvre comprennent diverses punitions pour réduire l'enjeu des validateurs inactifs, comme le mécanisme de fuite d'inactivité (Inactivity Leak Mechanism). Sur la chaîne Beacon actuelle, il existe également des pénalités anti-corrélation qui punissent plus lourdement les validateurs qui se comportent mal s'ils échouent tous sur le même client. En effet, cela favorise une culture multi-clients tout en encourageant les validateurs à prendre en compte non seulement les risques techniques mais aussi les incitations économiques lorsqu'ils choisissent un client.

⚠️🛑 Menace de censure n° 3

Enfin, il serait négligent de ne pas mentionner une autre menace de censure souvent évoquée au niveau des validateurs : la concentration d'ETH dans les services de staking. Les deux plus gros morceaux appartiennent aux protocoles de jalonnement liquide qui contrôlent ~37% de tous les ETH jalonnés et ~31% par les CEX. Il s'agit d'une préoccupation sérieuse car toute entité détenant plus de 33 % de l'ensemble de l'ETH peut se livrer à des attaques de double dépense.

Source : Dune Analytics : Dune Analytics

💡 La solution

Il n'y a pas de solution facile ici, mais il y a des raisons d'être optimiste. Tout d'abord, bien que Lido Lido contrôle un pourcentage disproportionné de 30 % des ETH mis en jeu, il n'existe pas en tant qu'entité unique et n'a pas d'influence directe sur la construction des blocs. Le trésor de guerre de Lido en ETH est transmis à 28 opérateurs de nœuds qui les mettent en jeu à travers des dizaines de milliers de nœuds, empêchant ainsi toute forme d'attaque unilatérale du réseau.

Les maxis de la décentralisation ne trouveront pas beaucoup de réconfort dans 28 opérateurs de nœuds, ce qui est encore beaucoup trop peu compte tenu de ce qui est en jeu(le réseau Ethereum !). Une solution technique susceptible de remédier à la concentration d'ETH est la technologie du validateur distribué (DVT), également connue sous le nom de technologie du validateur partagé secret, un domaine que la fondation Ethereum étudie activement depuis 2019. La société à l'origine du développement de la DVT est RockX, un fournisseur institutionnel de nœuds de blockchain et l'un des 28 opérateurs de nœuds du Lido.

DVT est un protocole open-source qui décentralise les activités opérationnelles des nœuds entre différents validateurs, plutôt qu'un seul. Il utilise des processus informatiques multipartites (MPC) pour garantir que les nœuds peuvent être gérés conjointement par plusieurs validateurs, car les clés privées sont "partagées". Par conséquent, aucun acteur n'a un accès complet à la clé privée nécessaire pour signer les messages. Cela permet également aux validateurs de remplacer un autre validateur en cas de dysfonctionnement de l'infrastructure.

Enfin, alors que les protocoles de staking liquide détenant trop d'ETH sont extrêmement inquiétants, il est intéressant d'envisager un monde contrefactuel dans lequel la Lido DAO n'existerait pas. Dans ce monde, l'ETH serait mis en jeu avec des entités encore plus vulnérables politiquement comme Coinbase Coinbase et Kraken, qui détiennent déjà une grande quantité d'ETH, une situation qui serait bien pire que le statu quo.


🔌 4. Relais

Les relayeurs agissent comme des intermédiaires "courtiers" assis entre les proposants et les constructeurs dans le modèle MEV-Boost que tout le monde peut facilement filer. Les relais sont un vecteur de centralisation unique qui est apparu à la suite des tentatives des Flashbots pour résoudre le problème de la MEV. Pour comprendre la menace de censure, il faut d'abord comprendre pourquoi les relais sont dans le tableau.

Rappelons que la raison pour laquelle on a voulu séparer le rôle de validateur en proposant et en construisant dans le cadre du PBS était de limiter les pouvoirs de censure des validateurs et d'empêcher un scénario dans lequel une entité(par exemple Coinbase ou Lido) détenant une quantité massive d'ETH mis en jeu pourrait décider arbitrairement de ce qu'il faut inclure sur la chaîne.

Par conséquent, pour que le PBS fonctionne, les proposants doivent être dans l'ignorance du contenu des blocs qu'ils reçoivent des constructeurs. Dans le cas contraire, les proposants seraient en mesure de discriminer entre les blocs qu'ils pensent devoir être sur la chaîne, et nous reviendrions à la case départ avant le PBS.

C'est là que les relais interviennent dans le cadre du modèle MEV-Boost des Flashbots. Les constructeurs envoient un bloc assemblé avec une offre de frais au relais, après quoi le relais envoie le bloc à un dépôt caché et ne révèle que le prix à tout proposant acceptant des charges utiles de ce relais.

Le contenu du bloc n'est révélé qu'une fois qu'un proposant s'est engagé à signer l'en-tête du bloc et à accepter l'offre. De cette façon, un proposant qui veut censurer les transactions Tornado Cash n'a pas d'autre choix que de continuer à proposer le bloc sur la chaîne, parce qu'il a déjà payé pour cela, ou d'être réduit à néant s'il essaie de proposer deux blocs à la fois.

Source : Devcon : Devcon

⚠️🛑 La menace de la censure

Mais que se passe-t-il si le relayeur lui-même choisit de censurer ? Cela nous amène au cœur du risque de centralisation au niveau du relayeur. Aujourd'hui, 58% de tous les blocs relayés sur Ethereum censurent les transactions Tornado Cash c'est-à-dire conformes à l'OFAC. La majorité - 80 % - de ces 58 % provient du relais de Flashbots (voir l'image ci-dessous).

Il est à noter que de nombreux autres validateurs continuent d'accepter des blocs contenant des transactions en Tornado Cash. Il s'agit donc d'une forme de censure "douce" qui se manifeste par un retard de quelques minutes, plutôt que d'une forme de censure "dure". Tant que les relayeurs disposent d'une minorité non censurée, ce problème restera davantage un inconvénient pour les utilisateurs que ce que nous considérons traditionnellement comme de la "censure". Néanmoins, c'est un problème qui a conduit à une préoccupation généralisée autour d'Ethereum censuré au cours des derniers mois(voir ici pour plus d'informations).

💡 La solution

La solution évidente ici est d'encourager une plus grande diversité de relais. Les validateurs sont généralement connectés à plusieurs relais à la fois. Comme nous l'avons vu plus haut, trois des sept relais(BloXroute et Manifold) ne censurent pas les transactions Tornado Cash. Les relais étant une entité sans permission, il est facile pour quiconque de créer le sien(les Flashbots eux-mêmes ont ouvert leur propre relais en toute bonne foi). Les barrières à l'entrée pour créer un relais sans censure sont faibles, ce qui signifie que ce vecteur de centralisation est beaucoup moins grave que s'il se situait au niveau du validateur, où il serait beaucoup plus coûteux de dissuader les acteurs malhonnêtes ou peu scrupuleux.

La bonne nouvelle est que les relais sont un vecteur de censure temporaire à long terme. Lorsque le PBS sera formellement inscrit dans le protocole, les relais ne seront plus nécessaires car les constructeurs se connecteront aux proposants.


🦇🔊 En conclusion...

Nous y voilà. L'ensemble de la chaîne d'approvisionnement des VME et ce que nous faisons à ce sujet. N'hésitez pas à ajouter dans les commentaires ce que j'ai omis.

Notez que cet article ne couvre que les formes douces de censure, qui se traduisent généralement par un retard de l'inclusion des blocs en secondes/minutes.

L'article ne prétend pas être exhaustif - j'ai omis de nombreux autres protocoles d'intergiciels tels que les oracles, les chaînes latérales et les roll-ups qui contiennent leurs propres vecteurs de centralisation. Les formes dures de censure, comme les attaques à 51 %, et les solutions techniques et sociales pour y remédier ont également été laissées de côté.


Mesures d'action


38
0
Donovan Choy

Written by Donovan Choy

85 Articles View all      

Former writer at Bankless.

No Responses
Rechercher sur Bankless