Remarque : Cet article est la troisième partie de la série « Futurs possibles du protocole Ethereum, partie 3 : Le Fléau » récemment publiée par le fondateur d’Ethereum, Vitalik. Pour la deuxième partie, voir « Vitalik : Comment le protocole Ethereum devrait évoluer dans la phase de surge », et pour la première partie, voir « Quoi d’autre peut être amélioré dans Ethereum PoS ». On trouvera ci-après le texte intégral de la troisième partie :
L’un des plus grands risques auxquels Ethereum L1 est confronté est la centralisation de la preuve d’enjeu en raison des pressions économiques. S’il y a des économies d’échelle en participant au mécanisme de preuve d’enjeu de base, cela conduira naturellement à la domination des grandes parties prenantes et à la sortie des petites parties prenantes pour rejoindre de grands pools de minage. Cela se traduit par un risque plus élevé d’attaques à 51 %, de censure des transactions et d’autres crises. En plus du risque de centralisation, il y a aussi le risque d’extraction de valeur : un petit pourcentage de personnes capte la valeur qui serait autrement transmise aux utilisateurs d’Ethereum.
Au cours de la dernière année, notre compréhension de ces risques s’est considérablement améliorée. Comme nous le savons tous, ce risque existe à deux endroits clés : (i) la construction d’îlots, et (ii) la réglementation du capital de jalonnement. Les participants plus importants peuvent exécuter des algorithmes plus complexes (« extraction MEV ») pour générer des blocs, ce qui se traduit par des revenus de bloc plus élevés pour eux. Les grands participants peuvent également résoudre plus efficacement les inconvénients liés au blocage des fonds en libérant leurs fonds sous forme de jetons de jalonnement liquides (LST) à d’autres. En plus de la question directe des petits stakers contre les grands stakers, il y a aussi la question de savoir si (ou va) dépasser l’ETH.
Feuille de route Scourge 2023
Cette année, des progrès significatifs ont été réalisés dans la construction de blocs, notamment la convergence de la « liste d’inclusion des comités et de certaines solutions de commande ciblées » comme solution idéale, ainsi que des recherches importantes sur l’économie de la preuve d’enjeu, y compris des idées telles que des modèles de jalonnement à deux niveaux et la réduction des émissions pour limiter le pourcentage d’ETH mis en jeu.
Les objectifs clés de The Scourge
Réduire autant que possible le risque de centralisation de la couche de staking d'Ethereum (en particulier en ce qui concerne la construction de blocs et l'approvisionnement en capital, également connus sous le nom de MEV et de pools de staking)
Tenter de réduire le risque d'extraction excessive de valeur des utilisateurs.
Cet article se divise en trois parties
Correction du pipeline de construction de blocs
Réparation de l'économie de mise en jeu (Fixing staking economics)
Solutions de couche application
Réparation de la construction de blocs
Quel problème devons-nous résoudre ?
Aujourd’hui, la construction de blocs Ethereum se fait principalement par le biais de la séparation propser-builder hors protocole de MEVBoost. Lorsque les validateurs ont la possibilité de proposer un bloc, ils confient le travail de sélection du contenu du bloc à des participants spécialisés appelés constructeurs. La sélection du contenu du bloc qui maximise les revenus est une tâche intensive en économies d’échelle : des algorithmes spécialisés sont nécessaires pour déterminer les transactions à inclure afin d’extraire autant de valeur que possible des instruments financiers on-chain et des transactions des utilisateurs qui interagissent avec eux (c’est ce qu’on appelle l'« extraction MEV »). Les validateurs sont confrontés à la tâche « stupide » d’avoir des économies d’échelle relativement légères, c’est-à-dire d’écouter les offres et d’accepter l’offre la plus élevée, ainsi que d’autres responsabilités telles que la preuve.
Graphique programmatique des choses que MEVBoost fait : les constructeurs dédiés assument les tâches rouges, les parties prenantes assument les tâches bleues.
Il existe plusieurs versions, notamment la séparation Proposeur-Constructeur (PBS) et la séparation Prover-Proposant (APS). La différence entre eux est liée aux détails précis de savoir lequel des deux participants porte la responsabilité : en gros, dans PBS, le validateur propose toujours le bloc mais reçoit la charge utile du constructeur, alors que dans APS, l’ensemble de l’emplacement devient la responsabilité du constructeur. Récemment, l’APS a été privilégié par rapport au PBS parce qu’il réduit encore la motivation des proposants à être co-localisés avec les constructeurs. Veuillez noter que l’APS ne s’applique qu’aux blocs exécutés qui contiennent des transactions ; Les blocs de consensus contenant des données liées à la preuve d’enjeu, telles que des preuves, seront toujours attribués de manière aléatoire aux validateurs.
Cette séparation des pouvoirs aide à maintenir la décentralisation des validateurs, mais elle a un coût important : les participants exécutant des tâches "spécialisées" peuvent facilement devenir très centralisés. C'est la construction de blocs d'Ethereum aujourd'hui :
Les deux participants sélectionnent le contenu d’environ 88 % des blocs Ethereum. Que se passe-t-il si ces deux participants décident d’examiner la transaction ? La réponse n’est pas aussi mauvaise qu’il n’y paraît : ils ne peuvent pas réassembler les blocs, vous n’avez donc pas besoin d’un examen minutieux de 51 % pour empêcher les transactions d’être incluses : vous avez besoin de 100 %. Avec 88% des avis, les utilisateurs doivent attendre en moyenne 9 créneaux (techniquement, une moyenne de 114 secondes au lieu de 6). Dans certains cas d’utilisation, il est acceptable d’attendre deux ou même cinq minutes pour certaines transactions. Mais pour d’autres cas d’utilisation, comme la liquidation de la DeFi, le simple fait de pouvoir retarder de quelques pâtés de maisons l’incorporation des transactions d’autres personnes constitue un risque important de manipulation du marché.
Les stratégies que les constructeurs de blocs peuvent utiliser pour maximiser les revenus peuvent également avoir d’autres effets négatifs sur les utilisateurs. Une « attaque sandwich » peut faire subir aux utilisateurs qui négocient des jetons des pertes importantes en raison d’un slippage. Les transactions introduites pour faire engorger la chaîne par ces attaques augmentent le prix du gaz pour les autres utilisateurs.
Qu'est-ce que c'est et comment ça marche ?
La solution de pointe consiste à décomposer davantage les tâches de production de blocs : nous réattribuerons les tâches de sélection des transactions aux proposeurs (c'est-à-dire aux stakers), tandis que les constructeurs ne pourront choisir que le tri et insérer certaines de leurs propres transactions. C'est ce que la liste d'inclusion souhaite réaliser.
À l'instant T, un validateur choisi au hasard crée une liste de transactions valides dans l'état actuel de la blockchain. À l'instant T+1, le constructeur de bloc (qui peut avoir été choisi à l'avance par un mécanisme d'enchères au sein du protocole) crée un bloc. Ce bloc doit contenir chaque transaction de la liste, mais ils peuvent choisir l'ordre et ajouter leurs propres transactions.
La proposition de liste d’inclusion obligatoire à choix bifurqué (FOCIL) implique un comité de plusieurs créateurs de listes d’inclusion pour chaque bloc. Afin de retarder une transaction d’un bloc, k du créateur de la liste contenant (par exemple k = 16) doit examiner la transaction. La combinaison de FOCIL avec les soumissionnaires finaux sélectionnés par le biais de l’enchère doit inclure une liste d’inclusions, mais peut être réorganisée et de nouvelles offres peuvent être ajoutées, souvent appelées « FOCIL + APS ».
Une autre façon de résoudre ce problème est d’utiliser un (MCP) scénario de proposition multi-simultané, tel que BRAID. BRAID essaie d’éviter de diviser le rôle du proposant de blocs en parties économiques à petite échelle et à grande échelle, et essaie plutôt de répartir le processus de production de blocs entre de nombreux participants afin que chaque proposant participant n’ait besoin que d’un niveau de complexité modéré pour maximiser ses revenus. MCP fonctionne en demandant à k proposants parallèles de générer une liste de transactions, puis en utilisant un algorithme déterministe (par exemple, trier par frais du plus élevé au plus bas) pour choisir l’ordre.
BRAID ne cherche pas à réaliser que le meilleur objectif pour un proposeur de blocs dumb-pipe exécutant un logiciel par défaut. Les deux raisons facilement compréhensibles pour lesquelles il ne peut pas le faire sont :
Attaque d’arbitrage tardive : Supposons que le temps moyen pour que le proposant s’engage est de T, et que le temps que vous pouvez soumettre pour la dernière fois et être toujours inclus est d’environ T+1. Maintenant, disons que sur un échange centralisé, le prix de l’ETH/USDC passe de 2500 $ à 2502 $ entre T et T+1. Les proposants peuvent attendre une seconde de plus, puis ajouter des transactions supplémentaires aux échanges décentralisés d’arbitrage sur la chaîne, ce qui permet de réaliser jusqu’à 2 $ de bénéfice par ETH. Les proposants chevronnés disposant de bonnes connexions au réseau sont mieux équipés pour le faire.
Flux d’ordres exclusif : les utilisateurs sont incités à envoyer les transactions directement à un seul proposant afin de minimiser leur vulnérabilité aux attaques de front-running et autres. Les proposants expérimentés ont un avantage parce qu’ils peuvent construire l’infrastructure pour accepter ces transactions directement des utilisateurs, et ils ont une réputation plus forte, de sorte que les utilisateurs qui leur envoient des transactions peuvent être sûrs que le proposant ne trahira pas et ne préemptera pas la transaction (ce qui atténue l’utilisation de matériel de confiance, mais le matériel de confiance a ses propres hypothèses de confiance). ）
Dans BRAID, le prouveur peut toujours se séparer et fonctionner comme une fonctionnalité de pipe idiot.
En plus de ces deux extrêmes, il existe une série de conceptions possibles qui se situent entre les deux. Par exemple, vous pouvez enchérir sur un rôle qui a uniquement le droit de s'ajouter à un bloc, sans avoir le droit de réorganiser ou de préfixer. Vous pouvez même leur permettre de s'ajouter ou de préfixer, mais sans pouvoir insérer au milieu ou réorganiser. L'attrait de ces techniques réside dans le fait que les gagnants du marché aux enchères peuvent être très concentrés, ce qui réduit leur autorité et présente de nombreux avantages.
mémoire du pool crypté
Une technologie essentielle pour la mise en œuvre réussie de nombreux designs de ce type (en particulier les versions BRAID ou APS, qui imposent des restrictions strictes sur la fonction d'enchères) est le pool de mémoire crypté. Le pool de mémoire crypté est une technique où les utilisateurs diffusent leurs transactions sous forme cryptée, accompagnées d'une sorte de preuve de validité, et les transactions sont incluses sous forme cryptée dans le bloc, sans que les constructeurs de blocs ne connaissent leur contenu. Le contenu des transactions est publié ultérieurement.
Le principal défi de la mise en œuvre des crypto-mempools est de trouver un design qui garantisse que toutes les transactions sont divulguées ultérieurement : un simple système de « commit and disclose » ne fonctionnera pas, car si la divulgation est volontaire, le fait de choisir de divulguer ou de ne pas divulguer est lui-même une sorte d’influence du « dernier arrivé » sur les blocs exploitables. Les deux techniques principales sont le décryptage à seuil 019283746574839201i019283746574839201-décryptage à seuil et (ii)-cryptage à retard, qui est une primitive étroitement liée à la fonction de retard vérifiable (VDF).
Quels liens y a-t-il avec la recherche existante ?
Explication de la centralisation de l'MEV et des constructeurs :
MEVBoost：
PBS consacré (solution proposée à ces problèmes dans les premières étapes) :
Liste des lectures associées à la liste d'inclusion de Mike Neuder :
Liste des EIP :
FOCIL :
Démonstration BRAID de Max Resnick :
« La priorité est ce dont vous avez besoin », auteur : Dan Robinson :
À propos des outils et protocoles de plusieurs proposeurs :
VDFResearch.org :
Fonctions de délai vérifiables et attaques (avec un accent sur la configuration RANDAO, mais également applicable aux pools de mémoire cryptographique) :
Capture et décentralisation des tickets d'exécution MEV :
APS centralisé :
Liste des MEV et des blocs inclus :
Que faut-il encore faire, que faut-il peser ?
Nous pouvons considérer toutes les solutions ci-dessus comme différentes manières de diviser les droits de participation au stake, classées selon un éventail allant de l'économie d'échelle faible (« tuyau idiot ») à l'économie d'échelle élevée (« amical spécialisé »). Avant 2021, tous ces droits étaient regroupés en un seul participant :
L’énigme centrale est que tout pouvoir significatif qui reste entre les mains des parties prenantes peut finir par être « lié au MEV ». Nous voulons qu’un groupe d’acteurs très dispersés ait autant de pouvoir que possible ; Cela signifie (i) donner beaucoup de pouvoir aux parties prenantes, et (ii) s’assurer que les parties prenantes sont aussi décentralisées que possible, ce qui signifie qu’elles ont peu d’incitations à l’intégration grâce aux économies d’échelle. C’est une situation tendue qui est difficile à gérer.
L’un des défis particuliers est le MEV multibloc : dans certains cas, les gagnants des enchères d’exécution peuvent gagner plus d’argent s’ils capturent plusieurs créneaux d’affilée et ne sont pas autorisés à effectuer des transactions liées au MEV dans des blocs autres que le dernier bloc qu’ils contrôlent. Si la liste d’inclusion les oblige à le faire, ils peuvent essayer de la contourner en ne postant aucun blocage du tout pendant ces périodes. On peut faire une liste d’inclusion inconditionnelle qui va directement au bloc si le constructeur ne la fournit pas, mais cela rend la liste d’inclusion liée au MEV. La solution ici peut impliquer quelques compromis, y compris l’acceptation d’incitations de bas niveau pour soudoyer des personnes dans la liste d’inclusion.
Nous pouvons examiner FOCIL + APS comme suit. Les stakers conservent le pouvoir sur la partie gauche du spectre, tandis que la partie droite du spectre est mise aux enchères au plus offrant.
BRAID est une autre histoire. La section « stakers » est plus grande, mais elle est divisée en deux parties : les stakers légers et les stakers lourds. Dans le même temps, étant donné que les transactions sont organisées par ordre décroissant de priorité des frais, la sélection au sommet du bloc est en fait adjugée par le biais du marché des frais, un système qui peut être considéré comme similaire au PBS.
Notez que la sécurité de BRAID dépend fortement du pool de mémoire chiffrée ; Sinon, le mécanisme d’enchères par bloc est vulnérable aux attaques de vol stratégique (essentiellement : copier les transactions d’autres personnes, échanger les adresses des destinataires et payer des frais élevés de 0,01 %). Ce besoin de confidentialité pré-contenue est également ce qui rend PBS si difficile à mettre en œuvre.
Enfin, la version plus "agressive" de FOCIL + APS, par exemple. APS ne détermine que les options à la fin du bloc comme indiqué ci-dessous :
La tâche principale restante est (i) de s'engager à consolider diverses propositions et à analyser leurs conséquences, ainsi que (ii) de combiner cette analyse avec une compréhension des objectifs de la communauté Ethereum, c'est-à-dire quelles formes de centralisation elle tolérera. Chaque proposition individuelle doit également accomplir certains travaux, par exemple :
Continuer à s'engager dans la conception de la mémoire tampon cryptographique, et atteindre un tel niveau : notre conception est à la fois robuste et assez simple, et semble déjà prête à y être intégrée.
Optimiser plusieurs conceptions de listes imbriquées pour s'assurer que (i) ne gaspille pas de données, en particulier dans le contexte de listes imbriquées contenant des blobs, ainsi que (ii) amical pour les validateurs sans état.
Plus de travaux sur la conception d'enchères optimales APS.
De plus, il est important de noter que ces différentes propositions ne sont pas forcément incompatibles entre elles à la croisée des chemins. Par exemple, la mise en œuvre de FOCIL + APS peut facilement servir de tremplin vers la mise en œuvre de BRAVE. Une stratégie conservatrice efficace est une approche attentiste, où nous mettons d’abord en œuvre une solution où les autorisations des stakers sont limitées et la plupart d’entre eux sont mis aux enchères, puis nous augmentons lentement le pouvoir des parties prenantes au fil du temps à mesure que nous en apprenons davantage sur le fonctionnement du marché MEV sur le réseau en direct.
En particulier, le goulot d'étranglement de la centralisation des mises est :
Construction de blocs centralisée (cette section)
Centralisation de la mise en jeu pour des raisons économiques (section suivante)
La centralisation du staking due au minimum de 32 ETH (à résoudre par Orbit ou d'autres technologies ; veuillez consulter les publications concernant la fusion)
Centralisation du staking en raison des exigences matérielles (résolu dans Verge par des clients sans état et le ZK-EVM ultérieur)
Résoudre l'un de ces quatre problèmes augmentera les bénéfices de la résolution de tout autre problème.
De plus, il existe une interaction entre le pipeline de construction de blocs et la finalité à un seul créneau, en particulier lorsqu'il s'agit de réduire le temps de créneau. De nombreux designs de pipelines de construction de blocs augmentent finalement le temps de créneau. De nombreux pipelines de construction de blocs impliquent le rôle des validateurs à plusieurs étapes du processus. Par conséquent, il est judicieux de considérer simultanément le pipeline de construction de blocs et la finalité à un seul créneau.
Réparer l'économie des staking
Quel problème devons-nous résoudre ?
Aujourd’hui, environ 30 % de l’offre d’ETH est activement jalonnée. C’est suffisant pour protéger Ethereum d’une attaque à 51%. Si le pourcentage d’ETH mis en jeu augmente, les chercheurs craignent un scénario différent : si presque tous les ETH sont mis en jeu, il y a un risque. Ces risques comprennent :
Le jalonnement est passé d’une tâche lucrative pour les experts à la responsabilité de tous les détenteurs d’ETH. De ce fait, le staker moyen sera encore moins enthousiaste et choisira la méthode la plus simple (en fait, en déléguant ses tokens à l’opérateur centralisé le plus pratique)
Si presque tous les ETH sont mis en jeu, alors la crédibilité du mécanisme de réduction sera affaiblie.
Un seul jeton de liquidité stakée peut prendre en charge la majorité des droits de vote, voire le réseau monétaire "monnaie" de l'ETH lui-même.
Ethereum émet chaque année environ 1 million d'ETH de manière inutile. Dans le cas où un jeton de staking liquide obtient un effet de réseau dominant, une grande partie de cette valeur pourrait même être capturée par le LST.
Qu'est-ce que c'est et comment ça marche ?
Historiquement, un type de solution a été le suivant : si le jalonnement est inévitable pour tout le monde, et que les jetons de jalonnement liquide sont inévitables, alors rendons le jalonnement convivial pour avoir des jetons de jalonnement liquides qui sont en fait sans confiance, neutres et décentralisés au maximum. Un moyen simple de le faire est de limiter la pénalité de staking à 1/8, ce qui rendrait 7/8 de l’ETH staké non réductible et donc éligible pour être placé dans les mêmes tokens de staking liquides. Une autre option consiste à créer explicitement deux niveaux de staking : le staking « risk-taking » (reductible).
Une critique de cette approche, cependant, est qu’elle semble économiquement équivalente à quelque chose de beaucoup plus simple : une réduction drastique des émissions si la participation s’approche d’un certain plafond prédéterminé. L’argument de base est le suivant : si nous nous retrouvons dans un monde où le niveau de prise de risque rapporte 3,4 % et le niveau sans risque (où tout le monde participe) rapporte 2,6 %, alors c’est en fait la même chose que le monde où le jalonnement d’ETH a un rendement de 0,8 % et où la détention uniquement d’ETH a un rendement de 0 %. La dynamique de la couche de prise de risque, y compris le montant total du jalonnement et le degré de centralisation, est la même dans les deux cas. Nous devrions donc faire des choses simples et réduire la circulation.
La principale objection à cet argument est de savoir si nous pouvons faire en sorte que la "couche sans risque" ait encore une certaine utilité et un certain degré de risque (par exemple, comme le propose Dankrad ici).
Ces deux suggestions impliquent un changement de la courbe d'émission. Si le nombre d'actions est trop élevé, le taux de rendement sera très faible.
Gauche : une proposition de Justin Drake pour ajuster la courbe d'émission. Droite : un autre ensemble de propositions d'Anders Elowsson.
Le staking à deux niveaux, en revanche, nécessite deux courbes de rendement : (i) le taux de rendement pour le staking « de base » (sans risque ou à faible risque), et (ii) la prime pour le staking risqué. Il y a plusieurs façons de définir ces paramètres : par exemple, si vous définissez un paramètre dur selon lequel 1/8 des capitaux propres est réductible, alors la dynamique du marché déterminera la prime du taux de rendement sur les fonds propres réductibles.
Un autre sujet important ici est la capture MEV. De nos jours, les revenus des MEV (par exemple, l’arbitrage DEX, les sandwichs...... ) à l’auteur de la proposition, c’est-à-dire au staker. Il s’agit d’un revenu complètement « opaque » pour le protocole : le protocole n’a aucun moyen de savoir s’il s’agit de 0,01 % d’APR, 1 % d’APR ou 20 % d’APR. L’existence de cette source de revenus est très gênante à plusieurs égards :
C'est une source de revenus instable, car chaque participant ne peut le recevoir que lorsqu'un bloc est proposé, ce qui se produit environ tous les 4 mois. Cela incitera les gens à rejoindre le fonds pour obtenir des revenus plus stables.
Cela entraîne une répartition déséquilibrée des incitations : trop de propositions, trop peu de preuves.
Cela rend la limite de participation très difficile à mettre en œuvre : même si le taux de retour "officiel" est de zéro, les revenus MEV seuls pourraient suffire à inciter tous les détenteurs d'ETH à staker. Par conséquent, la proposition réaliste de limite de participation doit en réalité rendre les retours proches de moins l'infini. Cela augmente les risques pour les stakers, en particulier pour les stakers individuels.
Nous pouvons résoudre ces problèmes en trouvant un moyen de rendre les revenus MEV visibles dans le protocole et de les capturer. La première proposition était le lissage MEV de Francesco ; aujourd'hui, il est largement admis que tout mécanisme permettant de vendre à l'avance les droits des proposeurs de blocs (ou, plus généralement, ayant suffisamment de pouvoir pour capturer presque tout le MEV) peut atteindre le même objectif.
Quels liens y a-t-il avec la recherche existante ?
Émettre wtf :
Endgame économie de staking, cas de positionnement :
Niveau d'émission des attributs, Anders Elowsson :
Taille maximale de configuration du validateur :
Réflexions sur l'idée de la mise en jeu multilayer:
Staking arc-en-ciel :
La proposition de jalonnement liquide de Dankrad :
Lissage MEV, auteur : Francesco :
MEV burn, auteur : Justin Drake :
Que faut-il encore faire, quels compromis doivent être envisagés ?
La tâche principale restante est soit d'accepter de ne prendre aucune mesure et d'accepter presque tous les risques liés à l'ETH dans le LST, soit de finaliser et de parvenir à un accord sur les détails et les paramètres de l'une des propositions ci-dessus. Un résumé général des bénéfices et des risques est le suivant :
Comment interagit-il avec les autres parties de la feuille de route ?
Un croisement important concerne les paris individuels. De nos jours, le VPS le moins cher qui peut faire fonctionner un nœud Ethereum coûte environ 60 $ par mois, principalement en raison du coût du stockage sur disque dur. Pour un staker de 32 ETH (84 000 $ au moment de la rédaction), cela réduirait l’APY de (60 * 12) / 84000 ~= 0,85%. Si le rendement total du jalonnement est inférieur à 0,85 %, le jalonnement en solo n’est pas réalisable pour de nombreuses personnes à ce niveau.
Si nous voulons que le jalonnement solo continue d’être viable, cela souligne encore la nécessité de réduire les coûts d’exploitation des nœuds, ce qui sera fait dans Verge : stateless éliminera les besoins en espace de stockage, qui peuvent être suffisants en soi, puis les preuves de validité L1 EVM rendront le coût insignifiant.
D'autre part, la destruction de MEV peut être considérée comme bénéfique pour le staking individuel. Bien qu'elle réduise les rendements pour chacun, il est plus important de diminuer la variance, ce qui fait que le staking n'est plus comme une loterie.
Enfin, toute modification apportée à l’émission interagira avec d’autres modifications fondamentales apportées à la conception du jalonnement (par exemple, le jalonnement arc-en-ciel). Un problème particulièrement préoccupant est que si les rendements du staking deviennent très faibles, cela signifie que nous devons choisir entre les (i) suivantes : réduire les pénalités et réduire les dissuasions en cas de mauvais comportement ; (ii) Le maintien de pénalités élevées ajoute une série de situations où même les validateurs bien intentionnés peuvent recevoir de manière inattendue des récompenses négatives s’ils ont la malchance de rencontrer des problèmes techniques ou même des attaques.
Solutions de couche applicative
La section ci-dessus met en évidence les modifications apportées à Ethereum L1 qui répondent à d’importants risques de centralisation. Cependant, Ethereum est plus qu’un simple L1, c’est un écosystème, et il existe d’importantes stratégies de couche applicative qui peuvent aider à atténuer les risques susmentionnés. En voici quelques exemples :
Certaines entreprises, telles que Dappnode, vendent du matériel spécialement conçu pour faciliter autant que possible l’utilisation d’un nœud de jalonnement. Une façon de rendre cette solution plus efficace est de se poser la question suivante : si l’utilisateur a déjà fait l’effort de faire fonctionner une boîte et de la connecter à Internet, quels autres services peut-elle fournir (à l’utilisateur ou à d’autres) qui bénéficieraient de la décentralisation ? Parmi les exemples qui me viennent à l’esprit, citons les (i) exécutant des LLM hébergés localement pour des raisons d’autonomie et de confidentialité, et les nœuds (ii) exécutant des VPN décentralisés.
Staking en équipe —— Cette solution d'Obol permet à plusieurs personnes de staker ensemble au format M-of-N. Au fil du temps, cela pourrait devenir de plus en plus populaire, car les preuves d'efficacité des EVM L1 sans état et des L1 ultérieures réduiront les coûts d'exécution de plus nœuds, et les avantages de rester toujours en ligne commenceront à dominer sans que chaque participant ait à s'en soucier. C'est une autre façon de réduire les coûts de perception du staking et d'assurer que le staking individuel prospère à l'avenir.
Airdrop —— Starknet propose des airdrops aux stakers individuels. D'autres projets souhaitant avoir une communauté décentralisée et partageant les mêmes valeurs peuvent également envisager d'offrir des airdrops ou des réductions aux validateurs identifiés comme étant de potentiels détenteurs de droits individuels.
Marché de construction de blocs décentralisé —— En utilisant une combinaison de ZK, MPC et TEE, il est possible de créer un constructeur de blocs décentralisé, participant et remportant le jeu d'enchères APS, tout en offrant une confidentialité pré-confirmée et des garanties contre la censure pour ses utilisateurs. C'est une autre voie pour améliorer le bien-être des utilisateurs dans le monde APS.
Minimisation du MEV de la couche application - Une seule application peut être construite de manière à « divulguer » moins de MEV à L1, réduisant ainsi l’incitation des constructeurs de blocs à créer des algorithmes spécialisés pour collecter le MEV. Une stratégie simple mais universelle consiste pour le contrat à mettre en file d’attente toutes les opérations entrantes et à les exécuter dans le bloc suivant, et à mettre aux enchères le droit de file d’attente, bien que la composabilité soit peu pratique et perturbatrice. D’autres méthodes plus complexes incluent de faire plus de travail hors chaîne, par exemple. Tout comme Cowswap l’a fait. Les oracles peuvent également être repensés pour minimiser la valeur qu’ils peuvent extraire.
Un grand merci pour les retours et les examens de Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes et Max Resnick, ainsi que pour les discussions de la communauté ethstakers.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Vitalik : L'objectif clé de la phase Scourge d'Ethereum
Auteur : Vitalik, fondateur d'Ethereum ; Traduction : Deng Tong, Jinse Caijing
Remarque : Cet article est la troisième partie de la série « Futurs possibles du protocole Ethereum, partie 3 : Le Fléau » récemment publiée par le fondateur d’Ethereum, Vitalik. Pour la deuxième partie, voir « Vitalik : Comment le protocole Ethereum devrait évoluer dans la phase de surge », et pour la première partie, voir « Quoi d’autre peut être amélioré dans Ethereum PoS ». On trouvera ci-après le texte intégral de la troisième partie :
L’un des plus grands risques auxquels Ethereum L1 est confronté est la centralisation de la preuve d’enjeu en raison des pressions économiques. S’il y a des économies d’échelle en participant au mécanisme de preuve d’enjeu de base, cela conduira naturellement à la domination des grandes parties prenantes et à la sortie des petites parties prenantes pour rejoindre de grands pools de minage. Cela se traduit par un risque plus élevé d’attaques à 51 %, de censure des transactions et d’autres crises. En plus du risque de centralisation, il y a aussi le risque d’extraction de valeur : un petit pourcentage de personnes capte la valeur qui serait autrement transmise aux utilisateurs d’Ethereum.
Au cours de la dernière année, notre compréhension de ces risques s’est considérablement améliorée. Comme nous le savons tous, ce risque existe à deux endroits clés : (i) la construction d’îlots, et (ii) la réglementation du capital de jalonnement. Les participants plus importants peuvent exécuter des algorithmes plus complexes (« extraction MEV ») pour générer des blocs, ce qui se traduit par des revenus de bloc plus élevés pour eux. Les grands participants peuvent également résoudre plus efficacement les inconvénients liés au blocage des fonds en libérant leurs fonds sous forme de jetons de jalonnement liquides (LST) à d’autres. En plus de la question directe des petits stakers contre les grands stakers, il y a aussi la question de savoir si (ou va) dépasser l’ETH.
Feuille de route Scourge 2023
Cette année, des progrès significatifs ont été réalisés dans la construction de blocs, notamment la convergence de la « liste d’inclusion des comités et de certaines solutions de commande ciblées » comme solution idéale, ainsi que des recherches importantes sur l’économie de la preuve d’enjeu, y compris des idées telles que des modèles de jalonnement à deux niveaux et la réduction des émissions pour limiter le pourcentage d’ETH mis en jeu.
Les objectifs clés de The Scourge
Cet article se divise en trois parties
Réparation de la construction de blocs
Quel problème devons-nous résoudre ?
Aujourd’hui, la construction de blocs Ethereum se fait principalement par le biais de la séparation propser-builder hors protocole de MEVBoost. Lorsque les validateurs ont la possibilité de proposer un bloc, ils confient le travail de sélection du contenu du bloc à des participants spécialisés appelés constructeurs. La sélection du contenu du bloc qui maximise les revenus est une tâche intensive en économies d’échelle : des algorithmes spécialisés sont nécessaires pour déterminer les transactions à inclure afin d’extraire autant de valeur que possible des instruments financiers on-chain et des transactions des utilisateurs qui interagissent avec eux (c’est ce qu’on appelle l'« extraction MEV »). Les validateurs sont confrontés à la tâche « stupide » d’avoir des économies d’échelle relativement légères, c’est-à-dire d’écouter les offres et d’accepter l’offre la plus élevée, ainsi que d’autres responsabilités telles que la preuve.
Graphique programmatique des choses que MEVBoost fait : les constructeurs dédiés assument les tâches rouges, les parties prenantes assument les tâches bleues.
Il existe plusieurs versions, notamment la séparation Proposeur-Constructeur (PBS) et la séparation Prover-Proposant (APS). La différence entre eux est liée aux détails précis de savoir lequel des deux participants porte la responsabilité : en gros, dans PBS, le validateur propose toujours le bloc mais reçoit la charge utile du constructeur, alors que dans APS, l’ensemble de l’emplacement devient la responsabilité du constructeur. Récemment, l’APS a été privilégié par rapport au PBS parce qu’il réduit encore la motivation des proposants à être co-localisés avec les constructeurs. Veuillez noter que l’APS ne s’applique qu’aux blocs exécutés qui contiennent des transactions ; Les blocs de consensus contenant des données liées à la preuve d’enjeu, telles que des preuves, seront toujours attribués de manière aléatoire aux validateurs.
Cette séparation des pouvoirs aide à maintenir la décentralisation des validateurs, mais elle a un coût important : les participants exécutant des tâches "spécialisées" peuvent facilement devenir très centralisés. C'est la construction de blocs d'Ethereum aujourd'hui :
Les deux participants sélectionnent le contenu d’environ 88 % des blocs Ethereum. Que se passe-t-il si ces deux participants décident d’examiner la transaction ? La réponse n’est pas aussi mauvaise qu’il n’y paraît : ils ne peuvent pas réassembler les blocs, vous n’avez donc pas besoin d’un examen minutieux de 51 % pour empêcher les transactions d’être incluses : vous avez besoin de 100 %. Avec 88% des avis, les utilisateurs doivent attendre en moyenne 9 créneaux (techniquement, une moyenne de 114 secondes au lieu de 6). Dans certains cas d’utilisation, il est acceptable d’attendre deux ou même cinq minutes pour certaines transactions. Mais pour d’autres cas d’utilisation, comme la liquidation de la DeFi, le simple fait de pouvoir retarder de quelques pâtés de maisons l’incorporation des transactions d’autres personnes constitue un risque important de manipulation du marché.
Les stratégies que les constructeurs de blocs peuvent utiliser pour maximiser les revenus peuvent également avoir d’autres effets négatifs sur les utilisateurs. Une « attaque sandwich » peut faire subir aux utilisateurs qui négocient des jetons des pertes importantes en raison d’un slippage. Les transactions introduites pour faire engorger la chaîne par ces attaques augmentent le prix du gaz pour les autres utilisateurs.
Qu'est-ce que c'est et comment ça marche ?
La solution de pointe consiste à décomposer davantage les tâches de production de blocs : nous réattribuerons les tâches de sélection des transactions aux proposeurs (c'est-à-dire aux stakers), tandis que les constructeurs ne pourront choisir que le tri et insérer certaines de leurs propres transactions. C'est ce que la liste d'inclusion souhaite réaliser.
! [r2Te1bi0MtSWOHNbbZVGcR78mKIqAxpHTlJXOMIO.jpeg](https ://img.gateio.im/social/moments-f87f49ad4e0712926cd3284ea73c6f44 « 7310355")
À l'instant T, un validateur choisi au hasard crée une liste de transactions valides dans l'état actuel de la blockchain. À l'instant T+1, le constructeur de bloc (qui peut avoir été choisi à l'avance par un mécanisme d'enchères au sein du protocole) crée un bloc. Ce bloc doit contenir chaque transaction de la liste, mais ils peuvent choisir l'ordre et ajouter leurs propres transactions.
La proposition de liste d’inclusion obligatoire à choix bifurqué (FOCIL) implique un comité de plusieurs créateurs de listes d’inclusion pour chaque bloc. Afin de retarder une transaction d’un bloc, k du créateur de la liste contenant (par exemple k = 16) doit examiner la transaction. La combinaison de FOCIL avec les soumissionnaires finaux sélectionnés par le biais de l’enchère doit inclure une liste d’inclusions, mais peut être réorganisée et de nouvelles offres peuvent être ajoutées, souvent appelées « FOCIL + APS ».
Une autre façon de résoudre ce problème est d’utiliser un (MCP) scénario de proposition multi-simultané, tel que BRAID. BRAID essaie d’éviter de diviser le rôle du proposant de blocs en parties économiques à petite échelle et à grande échelle, et essaie plutôt de répartir le processus de production de blocs entre de nombreux participants afin que chaque proposant participant n’ait besoin que d’un niveau de complexité modéré pour maximiser ses revenus. MCP fonctionne en demandant à k proposants parallèles de générer une liste de transactions, puis en utilisant un algorithme déterministe (par exemple, trier par frais du plus élevé au plus bas) pour choisir l’ordre.
! [XniRshdgUP88MpqFF5pD6JIRk02b89dsF2hlcwU2.jpeg](https ://img.gateio.im/social/moments-2dc60b4eb1269bb659b59d9274bc355b « 7310356")
BRAID ne cherche pas à réaliser que le meilleur objectif pour un proposeur de blocs dumb-pipe exécutant un logiciel par défaut. Les deux raisons facilement compréhensibles pour lesquelles il ne peut pas le faire sont :
Attaque d’arbitrage tardive : Supposons que le temps moyen pour que le proposant s’engage est de T, et que le temps que vous pouvez soumettre pour la dernière fois et être toujours inclus est d’environ T+1. Maintenant, disons que sur un échange centralisé, le prix de l’ETH/USDC passe de 2500 $ à 2502 $ entre T et T+1. Les proposants peuvent attendre une seconde de plus, puis ajouter des transactions supplémentaires aux échanges décentralisés d’arbitrage sur la chaîne, ce qui permet de réaliser jusqu’à 2 $ de bénéfice par ETH. Les proposants chevronnés disposant de bonnes connexions au réseau sont mieux équipés pour le faire. Flux d’ordres exclusif : les utilisateurs sont incités à envoyer les transactions directement à un seul proposant afin de minimiser leur vulnérabilité aux attaques de front-running et autres. Les proposants expérimentés ont un avantage parce qu’ils peuvent construire l’infrastructure pour accepter ces transactions directement des utilisateurs, et ils ont une réputation plus forte, de sorte que les utilisateurs qui leur envoient des transactions peuvent être sûrs que le proposant ne trahira pas et ne préemptera pas la transaction (ce qui atténue l’utilisation de matériel de confiance, mais le matériel de confiance a ses propres hypothèses de confiance). ）
Dans BRAID, le prouveur peut toujours se séparer et fonctionner comme une fonctionnalité de pipe idiot.
En plus de ces deux extrêmes, il existe une série de conceptions possibles qui se situent entre les deux. Par exemple, vous pouvez enchérir sur un rôle qui a uniquement le droit de s'ajouter à un bloc, sans avoir le droit de réorganiser ou de préfixer. Vous pouvez même leur permettre de s'ajouter ou de préfixer, mais sans pouvoir insérer au milieu ou réorganiser. L'attrait de ces techniques réside dans le fait que les gagnants du marché aux enchères peuvent être très concentrés, ce qui réduit leur autorité et présente de nombreux avantages.
mémoire du pool crypté
Une technologie essentielle pour la mise en œuvre réussie de nombreux designs de ce type (en particulier les versions BRAID ou APS, qui imposent des restrictions strictes sur la fonction d'enchères) est le pool de mémoire crypté. Le pool de mémoire crypté est une technique où les utilisateurs diffusent leurs transactions sous forme cryptée, accompagnées d'une sorte de preuve de validité, et les transactions sont incluses sous forme cryptée dans le bloc, sans que les constructeurs de blocs ne connaissent leur contenu. Le contenu des transactions est publié ultérieurement.
Le principal défi de la mise en œuvre des crypto-mempools est de trouver un design qui garantisse que toutes les transactions sont divulguées ultérieurement : un simple système de « commit and disclose » ne fonctionnera pas, car si la divulgation est volontaire, le fait de choisir de divulguer ou de ne pas divulguer est lui-même une sorte d’influence du « dernier arrivé » sur les blocs exploitables. Les deux techniques principales sont le décryptage à seuil 019283746574839201i019283746574839201-décryptage à seuil et (ii)-cryptage à retard, qui est une primitive étroitement liée à la fonction de retard vérifiable (VDF).
Quels liens y a-t-il avec la recherche existante ?
Explication de la centralisation de l'MEV et des constructeurs :
MEVBoost：
PBS consacré (solution proposée à ces problèmes dans les premières étapes) :
Liste des lectures associées à la liste d'inclusion de Mike Neuder :
Liste des EIP :
FOCIL :
Démonstration BRAID de Max Resnick :
« La priorité est ce dont vous avez besoin », auteur : Dan Robinson :
À propos des outils et protocoles de plusieurs proposeurs :
VDFResearch.org :
Fonctions de délai vérifiables et attaques (avec un accent sur la configuration RANDAO, mais également applicable aux pools de mémoire cryptographique) :
Capture et décentralisation des tickets d'exécution MEV :
APS centralisé :
Liste des MEV et des blocs inclus :
Que faut-il encore faire, que faut-il peser ?
Nous pouvons considérer toutes les solutions ci-dessus comme différentes manières de diviser les droits de participation au stake, classées selon un éventail allant de l'économie d'échelle faible (« tuyau idiot ») à l'économie d'échelle élevée (« amical spécialisé »). Avant 2021, tous ces droits étaient regroupés en un seul participant :
L’énigme centrale est que tout pouvoir significatif qui reste entre les mains des parties prenantes peut finir par être « lié au MEV ». Nous voulons qu’un groupe d’acteurs très dispersés ait autant de pouvoir que possible ; Cela signifie (i) donner beaucoup de pouvoir aux parties prenantes, et (ii) s’assurer que les parties prenantes sont aussi décentralisées que possible, ce qui signifie qu’elles ont peu d’incitations à l’intégration grâce aux économies d’échelle. C’est une situation tendue qui est difficile à gérer.
L’un des défis particuliers est le MEV multibloc : dans certains cas, les gagnants des enchères d’exécution peuvent gagner plus d’argent s’ils capturent plusieurs créneaux d’affilée et ne sont pas autorisés à effectuer des transactions liées au MEV dans des blocs autres que le dernier bloc qu’ils contrôlent. Si la liste d’inclusion les oblige à le faire, ils peuvent essayer de la contourner en ne postant aucun blocage du tout pendant ces périodes. On peut faire une liste d’inclusion inconditionnelle qui va directement au bloc si le constructeur ne la fournit pas, mais cela rend la liste d’inclusion liée au MEV. La solution ici peut impliquer quelques compromis, y compris l’acceptation d’incitations de bas niveau pour soudoyer des personnes dans la liste d’inclusion.
Nous pouvons examiner FOCIL + APS comme suit. Les stakers conservent le pouvoir sur la partie gauche du spectre, tandis que la partie droite du spectre est mise aux enchères au plus offrant.
BRAID est une autre histoire. La section « stakers » est plus grande, mais elle est divisée en deux parties : les stakers légers et les stakers lourds. Dans le même temps, étant donné que les transactions sont organisées par ordre décroissant de priorité des frais, la sélection au sommet du bloc est en fait adjugée par le biais du marché des frais, un système qui peut être considéré comme similaire au PBS.
Notez que la sécurité de BRAID dépend fortement du pool de mémoire chiffrée ; Sinon, le mécanisme d’enchères par bloc est vulnérable aux attaques de vol stratégique (essentiellement : copier les transactions d’autres personnes, échanger les adresses des destinataires et payer des frais élevés de 0,01 %). Ce besoin de confidentialité pré-contenue est également ce qui rend PBS si difficile à mettre en œuvre.
Enfin, la version plus "agressive" de FOCIL + APS, par exemple. APS ne détermine que les options à la fin du bloc comme indiqué ci-dessous :
La tâche principale restante est (i) de s'engager à consolider diverses propositions et à analyser leurs conséquences, ainsi que (ii) de combiner cette analyse avec une compréhension des objectifs de la communauté Ethereum, c'est-à-dire quelles formes de centralisation elle tolérera. Chaque proposition individuelle doit également accomplir certains travaux, par exemple :
De plus, il est important de noter que ces différentes propositions ne sont pas forcément incompatibles entre elles à la croisée des chemins. Par exemple, la mise en œuvre de FOCIL + APS peut facilement servir de tremplin vers la mise en œuvre de BRAVE. Une stratégie conservatrice efficace est une approche attentiste, où nous mettons d’abord en œuvre une solution où les autorisations des stakers sont limitées et la plupart d’entre eux sont mis aux enchères, puis nous augmentons lentement le pouvoir des parties prenantes au fil du temps à mesure que nous en apprenons davantage sur le fonctionnement du marché MEV sur le réseau en direct.
En particulier, le goulot d'étranglement de la centralisation des mises est :
Résoudre l'un de ces quatre problèmes augmentera les bénéfices de la résolution de tout autre problème.
De plus, il existe une interaction entre le pipeline de construction de blocs et la finalité à un seul créneau, en particulier lorsqu'il s'agit de réduire le temps de créneau. De nombreux designs de pipelines de construction de blocs augmentent finalement le temps de créneau. De nombreux pipelines de construction de blocs impliquent le rôle des validateurs à plusieurs étapes du processus. Par conséquent, il est judicieux de considérer simultanément le pipeline de construction de blocs et la finalité à un seul créneau.
Réparer l'économie des staking
Quel problème devons-nous résoudre ?
Aujourd’hui, environ 30 % de l’offre d’ETH est activement jalonnée. C’est suffisant pour protéger Ethereum d’une attaque à 51%. Si le pourcentage d’ETH mis en jeu augmente, les chercheurs craignent un scénario différent : si presque tous les ETH sont mis en jeu, il y a un risque. Ces risques comprennent :
Qu'est-ce que c'est et comment ça marche ?
Historiquement, un type de solution a été le suivant : si le jalonnement est inévitable pour tout le monde, et que les jetons de jalonnement liquide sont inévitables, alors rendons le jalonnement convivial pour avoir des jetons de jalonnement liquides qui sont en fait sans confiance, neutres et décentralisés au maximum. Un moyen simple de le faire est de limiter la pénalité de staking à 1/8, ce qui rendrait 7/8 de l’ETH staké non réductible et donc éligible pour être placé dans les mêmes tokens de staking liquides. Une autre option consiste à créer explicitement deux niveaux de staking : le staking « risk-taking » (reductible).
Une critique de cette approche, cependant, est qu’elle semble économiquement équivalente à quelque chose de beaucoup plus simple : une réduction drastique des émissions si la participation s’approche d’un certain plafond prédéterminé. L’argument de base est le suivant : si nous nous retrouvons dans un monde où le niveau de prise de risque rapporte 3,4 % et le niveau sans risque (où tout le monde participe) rapporte 2,6 %, alors c’est en fait la même chose que le monde où le jalonnement d’ETH a un rendement de 0,8 % et où la détention uniquement d’ETH a un rendement de 0 %. La dynamique de la couche de prise de risque, y compris le montant total du jalonnement et le degré de centralisation, est la même dans les deux cas. Nous devrions donc faire des choses simples et réduire la circulation.
La principale objection à cet argument est de savoir si nous pouvons faire en sorte que la "couche sans risque" ait encore une certaine utilité et un certain degré de risque (par exemple, comme le propose Dankrad ici).
Ces deux suggestions impliquent un changement de la courbe d'émission. Si le nombre d'actions est trop élevé, le taux de rendement sera très faible.
Gauche : une proposition de Justin Drake pour ajuster la courbe d'émission. Droite : un autre ensemble de propositions d'Anders Elowsson.
Le staking à deux niveaux, en revanche, nécessite deux courbes de rendement : (i) le taux de rendement pour le staking « de base » (sans risque ou à faible risque), et (ii) la prime pour le staking risqué. Il y a plusieurs façons de définir ces paramètres : par exemple, si vous définissez un paramètre dur selon lequel 1/8 des capitaux propres est réductible, alors la dynamique du marché déterminera la prime du taux de rendement sur les fonds propres réductibles.
Un autre sujet important ici est la capture MEV. De nos jours, les revenus des MEV (par exemple, l’arbitrage DEX, les sandwichs...... ) à l’auteur de la proposition, c’est-à-dire au staker. Il s’agit d’un revenu complètement « opaque » pour le protocole : le protocole n’a aucun moyen de savoir s’il s’agit de 0,01 % d’APR, 1 % d’APR ou 20 % d’APR. L’existence de cette source de revenus est très gênante à plusieurs égards :
Nous pouvons résoudre ces problèmes en trouvant un moyen de rendre les revenus MEV visibles dans le protocole et de les capturer. La première proposition était le lissage MEV de Francesco ; aujourd'hui, il est largement admis que tout mécanisme permettant de vendre à l'avance les droits des proposeurs de blocs (ou, plus généralement, ayant suffisamment de pouvoir pour capturer presque tout le MEV) peut atteindre le même objectif.
Quels liens y a-t-il avec la recherche existante ?
Émettre wtf :
Endgame économie de staking, cas de positionnement :
Niveau d'émission des attributs, Anders Elowsson :
Taille maximale de configuration du validateur :
Réflexions sur l'idée de la mise en jeu multilayer:
Staking arc-en-ciel :
La proposition de jalonnement liquide de Dankrad :
Lissage MEV, auteur : Francesco :
MEV burn, auteur : Justin Drake :
Que faut-il encore faire, quels compromis doivent être envisagés ?
La tâche principale restante est soit d'accepter de ne prendre aucune mesure et d'accepter presque tous les risques liés à l'ETH dans le LST, soit de finaliser et de parvenir à un accord sur les détails et les paramètres de l'une des propositions ci-dessus. Un résumé général des bénéfices et des risques est le suivant :
Comment interagit-il avec les autres parties de la feuille de route ?
Un croisement important concerne les paris individuels. De nos jours, le VPS le moins cher qui peut faire fonctionner un nœud Ethereum coûte environ 60 $ par mois, principalement en raison du coût du stockage sur disque dur. Pour un staker de 32 ETH (84 000 $ au moment de la rédaction), cela réduirait l’APY de (60 * 12) / 84000 ~= 0,85%. Si le rendement total du jalonnement est inférieur à 0,85 %, le jalonnement en solo n’est pas réalisable pour de nombreuses personnes à ce niveau.
Si nous voulons que le jalonnement solo continue d’être viable, cela souligne encore la nécessité de réduire les coûts d’exploitation des nœuds, ce qui sera fait dans Verge : stateless éliminera les besoins en espace de stockage, qui peuvent être suffisants en soi, puis les preuves de validité L1 EVM rendront le coût insignifiant.
D'autre part, la destruction de MEV peut être considérée comme bénéfique pour le staking individuel. Bien qu'elle réduise les rendements pour chacun, il est plus important de diminuer la variance, ce qui fait que le staking n'est plus comme une loterie.
Enfin, toute modification apportée à l’émission interagira avec d’autres modifications fondamentales apportées à la conception du jalonnement (par exemple, le jalonnement arc-en-ciel). Un problème particulièrement préoccupant est que si les rendements du staking deviennent très faibles, cela signifie que nous devons choisir entre les (i) suivantes : réduire les pénalités et réduire les dissuasions en cas de mauvais comportement ; (ii) Le maintien de pénalités élevées ajoute une série de situations où même les validateurs bien intentionnés peuvent recevoir de manière inattendue des récompenses négatives s’ils ont la malchance de rencontrer des problèmes techniques ou même des attaques.
Solutions de couche applicative
La section ci-dessus met en évidence les modifications apportées à Ethereum L1 qui répondent à d’importants risques de centralisation. Cependant, Ethereum est plus qu’un simple L1, c’est un écosystème, et il existe d’importantes stratégies de couche applicative qui peuvent aider à atténuer les risques susmentionnés. En voici quelques exemples :
Certaines entreprises, telles que Dappnode, vendent du matériel spécialement conçu pour faciliter autant que possible l’utilisation d’un nœud de jalonnement. Une façon de rendre cette solution plus efficace est de se poser la question suivante : si l’utilisateur a déjà fait l’effort de faire fonctionner une boîte et de la connecter à Internet, quels autres services peut-elle fournir (à l’utilisateur ou à d’autres) qui bénéficieraient de la décentralisation ? Parmi les exemples qui me viennent à l’esprit, citons les (i) exécutant des LLM hébergés localement pour des raisons d’autonomie et de confidentialité, et les nœuds (ii) exécutant des VPN décentralisés.
Un grand merci pour les retours et les examens de Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes et Max Resnick, ainsi que pour les discussions de la communauté ethstakers.