Un des plus grands risques pour Ethereum L1 est la centralisation du proof-of-stake due aux pressions économiques. Si participer aux mécanismes de proof-of-stake centraux présente des économies d'échelle, cela conduirait naturellement à une domination des gros stakers et à l'abandon des petits stakers pour rejoindre de grands pools. Cela entraîne un risque plus élevé d'attaques de 51%, de censure de transactions et d'autres crises. En plus du risque de centralisation, il existe également des risques d'extraction de valeur : un petit groupe capturant de la valeur qui irait autrement aux utilisateurs d'Ethereum.

Au cours de l'année écoulée, notre compréhension de ces risques a considérablement augmenté. Il est bien compris que ces risques existent principalement à deux endroits : (i) la construction des blocs et (ii) la fourniture de capital en participation. Les acteurs de grande envergure peuvent se permettre de faire fonctionner des algorithmes plus sophistiqués (« extraction de MEV ») pour générer des blocs, ce qui leur donne un revenu plus élevé par bloc. Les acteurs très importants peuvent également gérer plus efficacement l'inconvénient de bloquer leur capital en le libérant à d'autres sous forme de jeton de participation liquide (LST). En plus des questions directes concernant les petits et grands participants, il y a également la question de savoir s'il existe (ou existera) trop d'ETH mis en jeu.

La Fléau, feuille de route 2023

Cette année, il y a eu des avancées significatives dans la construction de blocs, notamment la convergence sur les « listes d'inclusion du comité plus une solution ciblée pour l'ordonnancement » comme solution idéale, ainsi que des recherches importantes sur l'économie du proof of stake, y compris des idées telles que les modèles de mise en jeu à deux niveaux et la réduction de l'émission pour plafonner le pourcentage d'ETH mis en jeu.

Le Fléau: objectifs clés

• Minimiser les risques de centralisation au niveau du jalonnement d'Ethereum (notamment, dans la construction de blocs et la fourniture de capital, alias MEV et les pools de jalonnement)
• Minimiser les risques d'extraction excessive de valeur des utilisateurs

Dans ce chapitre

• Réparation du pipeline de construction de blocs
• Correction de l'économie du jalonnement
• Solutions de couche d'application

Réparation du pipeline de construction de blocs

Quel problème résolvons-nous ?

Aujourd'hui, la construction de blocs Ethereum est en grande partie effectuée grâce à une séparation supplémentaire de la construction de propser-constructeur en dehors du protocole.MEVBoost. Lorsqu’un validateur a l’opportunité de proposer un bloc, il vend aux enchères le travail de choix du contenu du bloc à des acteurs spécialisés appelés constructeurs. La tâche de choisir le contenu des blocs qui maximisent les revenus est très intensive en termes d’économies d’échelle : des algorithmes spécialisés sont nécessaires pour déterminer les transactions à inclure, afin d’extraire le plus de valeur possible des gadgets financiers on-chain et des transactions des utilisateurs qui interagissent avec eux (c’est ce qu’on appelle « l’extraction MEV »). Les validateurs se retrouvent avec la tâche relativement économique d’écouter les offres et d’accepter l’offre la plus élevée, ainsi que d’autres responsabilités telles que l’attestation.

Diagramme stylisé de ce que fait MEVBoost : les constructeurs spécialisés prennent en charge les tâches en rouge et les stakers prennent en charge les tâches en bleu.

Il existe diverses versions de cela, y compris “séparation du proposant-constructeur" (PBS) et "séparation attester-proposant" (APS). La différence entre les deux tient aux détails fins sur les responsabilités assignées à chacun des deux acteurs : en gros, dans PBS, les validateurs proposent toujours des blocs, mais reçoivent la charge utile des constructeurs, et dans APS, l'ensemble de la fente devient la responsabilité du constructeur. Récemment, APS est préféré à PBS, car il réduit encore plus les incitations des proposants à se regrouper avec les constructeurs. Notez que APS ne s'appliquerait qu'aux blocs d'exécution, qui contiennent des transactions; les blocs de consensus, qui contiennent des données liées à la preuve d'enjeu telles que les attestations, seraient toujours attribués de manière aléatoire aux validateurs.

Cette séparation des pouvoirs contribue à maintenir la décentralisation des validateurs, mais elle a un coût important : les acteurs qui effectuent les tâches « spécialisées » peuvent facilement devenir très centralisés. Voici la construction des blocs Ethereum aujourd'hui :

Deux acteurs choisissent le contenu d'environ 88% des blocs d'Ethereum. Et si ces deux acteurs décidaient de censurer une transaction? La réponse n'est pas aussi grave qu'il pourrait sembler : ils ne peuvent pas réorganiser les blocs, donc vous n'avez pas besoin de 51% de censure pour empêcher une transaction d'être incluse : vous avez besoin de 100%. Avec une censure de 88%, un utilisateur devrait attendre en moyenne 9 slots pour être inclus (techniquement, une moyenne de 114 secondes au lieu de 6 secondes). Pour certains cas d'utilisation, attendre deux ou même cinq minutes pour certaines transactions est acceptable. Mais pour d'autres cas d'utilisation, par exemple les liquidations de la DeFi, même la capacité de retarder l'inclusion de la transaction de quelqu'un d'autre de quelques blocs représente 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 conséquences négatives pour les utilisateurs. Un "attaque sandwich" pourrait entraîner des pertes importantes pour les utilisateurs effectuant des échanges de jetons en raison du glissement. Les transactions introduites pour effectuer ces attaques encombrent la chaîne, augmentant les prix du gaz pour les autres utilisateurs.

Qu'est-ce que c'est et comment cela fonctionne-t-il?

La solution principale consiste à diviser davantage la tâche de production de blocs : nous confions la tâche de choisir les transactions au proposant (c'est-à-dire un validateur), et le constructeur ne peut choisir que l'ordre et insérer certaines transactions de sa propre initiative. C'est ce que listes d'inclusionchercher à faire.

À l'instant T, un validateur sélectionné au hasard crée une liste d'inclusion, une liste de transactions qui sont valides compte tenu de l'état actuel de la blockchain à ce moment-là. À l'instant T+1, un constructeur de bloc, peut-être choisi à l'avance grâce à un mécanisme d'enchère en protocole, crée un bloc. Ce bloc doit inclure chaque transaction de la liste d'inclusion, mais il peut choisir l'ordre et ajouter ses propres transactions.

Les propositions de listes d'inclusion appliquées par choix de fourche (FOCIL) impliquent un comité de plusieurs créateurs de listes d'inclusion par bloc. Pour retarder une transaction d'un bloc, k des k créateurs de listes d'inclusion (par exemple, k = 16) devraient censurer la transaction. La combinaison de FOCIL avec un proposant final choisi par enchère qui est tenu d'inclure les listes d'inclusion, mais peut réorganiser et ajouter de nouvelles transactions, est souvent appelée “FOCIL + APS”.

Une approche différente du problème est les schémas de plusieurs proposants concurrents (MCP) tels que TRESSE. BRAID cherche à éviter de diviser le rôle du proposant de bloc en une partie à faibles économies d'échelle et une partie à fortes économies d'échelle, et tente plutôt de répartir le processus de production de bloc parmi de nombreux acteurs, de manière à ce que chaque proposant n'ait besoin que d'un niveau moyen de sophistication pour maximiser ses revenus. MCP fonctionne en ayant k proposants parallèles générer des listes de transactions, puis en utilisant un algorithme déterministe (par exemple, ordre selon les frais les plus élevés aux plus bas) pour choisir l'ordre.

BRAID ne cherche pas à atteindre l'objectif d'un fonctionnement optimal des proposants de blocs de tuyaux muets exécutant un logiciel par défaut. Deux raisons faciles à comprendre expliquent pourquoi il ne peut pas le faire :

1. Attaques d'arbitrage de dernier recours : supposons que le temps moyen de soumission des proposants est T, et que le dernier moment possible pour soumettre et être inclus est d'environ T+1. Maintenant, supposons que sur les bourses centralisées, le prix de l'ETH/USDC passe de 2500 $ à 2502 $ entre T et T+1. Un proposant peut attendre une seconde supplémentaire et ajouter une transaction supplémentaire pour arbitrer sur les bourses décentralisées on-chain, réclamant jusqu'à 2 $ par ETH de profit. Les proposants sophistiqués qui sont très bien connectés au réseau ont plus de capacité pour le faire.
2. Flux de commandes exclusif : les utilisateurs ont incitation à envoyer directement leurs transactions à un seul proposant afin de minimiser leur vulnérabilité aux front-runnings et autres attaques. Les proposants sophistiqués ont un avantage car ils peuvent mettre en place une infrastructure pour accepter ces transactions directes des utilisateurs, et ils ont une réputation plus solide, de sorte que les utilisateurs qui leur envoient des transactions peuvent faire confiance au fait que le proposant ne les trahira pas et ne les front-runnera pas (cela peut être atténué avec un matériel de confiance, mais le matériel de confiance comporte ses propres hypothèses de confiance).

Dans BRAID, les validateurs peuvent encore être séparés et exécutés en tant que fonctionnalité de conduit stupide.

En plus de ces deux extrêmes, il existe un spectre de conceptions possibles entre les deux. Par exemple, vous pourriez mettre aux enchères un rôle qui a seulement le droit d'ajouter à un bloc, et non de réorganiser ou de préfixer. Vous pourriez même les laisser ajouter ou préfixer, mais pas insérer au milieu ou réorganiser. L'attrait de ces techniques est que les gagnants du marché aux enchères sontprobablementêtretrès concentré, et il y a donc beaucoup d'avantages à réduire leur autorité.

Mempools cryptés

Une technologie essentielle à la mise en œuvre réussie de nombreuses de ces conceptions (en particulier, soit BRAID soit une version de APS où il y a des limites strictes sur les capacités mises aux enchères) est les mempools cryptés. Les mempools cryptés sont une technologie où les utilisateurs diffusent leurs transactions sous forme chiffrée, avec une sorte de preuve de leur validité, et les transactions sont incluses dans des blocs sous forme chiffrée, sans que le constructeur du bloc ne connaisse le contenu. Le contenu des transactions est révélé plus tard.

Le principal défi dans la mise en œuvre des mempools chiffrés consiste à concevoir un système qui garantit que toutes les transactions seront révélées ultérieurement : un simple schéma de « commit et révéler » ne fonctionne pas, car si la révélation est volontaire, le choix de révéler ou de ne pas révéler est en soi une sorte d'influence de dernier recours sur un bloc qui pourrait être exploité. Les deux principales techniques pour y parvenir sont (i) déchiffrement seuillé, et (ii) retarder le chiffrement, un primitive étroitement lié à fonctions de retard vérifiables (VDFs).

Quels sont quelques liens vers des recherches existantes?

• Explication sur MEV et centralisation des constructeurs: https://vitalik.eth.limo/general/2024/05/17/decentralization.html#mev-and-builder-dependence
• MEVBoost: https://github.com/flashbots/mev-boost
• PBS consacré (une solution proposée antérieurement à ces problèmes):https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710
• La liste de lectures de Mike Neuder sur la liste d'inclusion :https://gist.github.com/michaelneuder/dfe5699cb245bc99fbc718031c773008
• Liste d'inclusion EIP: https://eips.ethereum.org/EIPS/eip-7547
• FOCIL: https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-une proposition de liste d'inclusion basée sur un comité simple
• Présentation sur BRAID par Max Resnick : https://www.youtube.com/watch?v=mJLERWmQ2uw
• « La priorité est tout ce dont vous avez besoin », par Dan Robinson : https://www.paradigm.xyz/2024/06/priority-is-all-you-need
• Sur les gadgets et protocoles multi-proposer :https://hackmd.io/xz1UyksETR-pCsazePMAjw
• VDFresearch.org: https://vdfresearch.org/
• Fonctions de retard vérifiables et attaques (se concentre sur le paramètre RANDAO, mais également applicable aux mempools chiffrés):https://ethresear.ch/t/verifiable-delay-functions-and-attacks/2365
• Capture de la MEV et décentralisation dans les Execution Tickets : https://www.arxiv.org/pdf/2408.11255
• Centralisation dans APS: https://arxiv.org/abs/2408.03116
• MEV multi-block et listes d'inclusion: https://x.com/%5fcharlienoyes/status/1806186662327689441

Que reste-t-il à faire et quels sont les compromis ?

Nous pouvons considérer tous les schémas ci-dessus comme étant différentes façons de diviser l'autorité impliquée dans le jalonnement, disposées sur un spectre allant d'économies d'échelle inférieures (« tuyau bête ») à des économies d'échelle supérieures (« favorables à la spécialisation »). Avant 2021, toutes ces autorités étaient regroupées en un seul acteur :

Le dilemme central est le suivant : toute autorité significative qui reste entre les mains des validateurs, est une autorité qui pourrait finir par être « pertinente pour les MEV ». Nous voulons qu'un ensemble hautement décentralisé d'acteurs ait le plus d'autorité possible ; cela implique (i) de confier beaucoup d'autorité aux validateurs, et (ii) de veiller à ce que les validateurs soient aussi décentralisés que possible, ce qui signifie qu'ils ont peu d'incitations entraînées par les économies d'échelle à se consolider. Il s'agit d'une tension difficile à gérer.

Un défi particulier est le MEV multi-blocs : dans certains cas, les gagnants des enchères d'exécution peuvent gagner encore plus d'argent s'ils capturent plusieurs emplacements à la suite et n'autorisent aucune transaction pertinente au MEV dans des blocs autres que le dernier qu'ils contrôlent. Si les listes d'inclusion les y obligent, ils peuvent essayer de contourner cela en ne publiant aucun bloc du tout pendant ces emplacements. On pourrait créer des listes d'inclusion inconditionnelles, qui deviennent directement le bloc si le constructeur n'en fournit pas, mais celaajoute à la liste d'inclusion pertinent MEV. La solution ici peut impliquer un compromis qui consiste à accepter un faible degré d'incitation à soudoyer les gens pour inclure des transactions dans une liste d'inclusion, et espérer que ce n'est pas suffisamment élevé pour conduire à une externalisation massive.

Nous pouvons voir FOCIL + APS comme suit. Les validateurs continuent d'avoir l'autorité sur la partie gauche du spectre, tandis que la partie droite du spectre est mise aux enchères au plus offrant.

BRAID est assez différent. La partie "staker" est plus grande, mais elle est divisée en deux parties : les stakers légers et les stakers lourds. Pendant ce temps, parce que les transactions sont ordonnées dans l'ordre décroissant des frais de priorité, le choix en haut du bloc est de facto mis aux enchères via le marché des frais, dans un schéma qui peut être considéré comme analogue au PBS consacré.

Notez que la sécurité de BRAID dépend fortement des mempools chiffrés ; sinon, le mécanisme d'enchère en haut de bloc devient vulnérable aux attaques de vol de stratégie (essentiellement : copier les transactions d'autres personnes, échanger l'adresse du destinataire et payer des frais plus élevés de 0,01%). Ce besoin de confidentialité préalable à l'inclusion est également la raison pour laquelle la mise en œuvre de PBS consacrée est si délicate.

Enfin, des versions plus « agressives » de FOCIL + APS, par exemple l'option où APS détermine uniquement la fin du bloc, ressemblent à ceci :

La principale tâche restante consiste à (i) travailler sur la consolidation des différentes propositions et analyser leurs conséquences, et (ii) combiner cette analyse avec une compréhension des objectifs de la communauté Ethereum en termes de formes de centralisation qu'elle tolérera. Il y a également du travail à faire sur chaque proposition individuelle, tel que:

• Continuer le travail sur les conceptions de mempool chiffrées, et arriver au point où nous avons une conception à la fois robuste et raisonnablement simple, et vraisemblablement prête pour l'inclusion.
• Optimisation de la conception de plusieurs listes d'inclusion pour s'assurer que (i) elle ne gaspille pas de données, notamment dans le contexte des listes d'inclusion couvrant les blobs, et (ii) elle est conviviale pour les validateurs sans état.
• Plus de travail sur la conception optimale de l'enchère pour APS.

De plus, il convient de noter que ces différentes propositions ne sont pas nécessairement des fourches incompatibles sur la route les unes des autres. Par exemple, la mise en œuvre de FOCIL + APS pourrait facilement servir de tremplin à la mise en œuvre de BRAID. Une stratégie conservatrice valide consisterait en une approche de «wait-and-see» où nous mettons d'abord en place une solution où l'autorité des stakers est limitée et où la plupart de l'autorité est vendue aux enchères, puis augmentons lentement l'autorité des stakers au fil du temps à mesure que nous en apprenons davantage sur le fonctionnement du marché MEV sur le réseau en direct.

Comment interagit-il avec d'autres parties de la feuille de route?

Il existe des interactions positives entre la résolution d'un goulot d'étranglement de centralisation du staking et la résolution des autres. Pour donner une analogie, imaginez un monde où créer votre propre entreprise nécessitait de cultiver votre propre nourriture, de fabriquer vos propres ordinateurs et d'avoir votre propre armée. Dans ce monde, seules quelques entreprises pourraient exister. Résoudre l'un des trois problèmes aiderait la situation, mais seulement un peu. Résoudre deux problèmes aiderait plus de deux fois plus que d'en résoudre un. Et résoudre trois serait bien plus de trois fois aussi utile - si vous êtes un entrepreneur solo, soit 3/3 problèmes sont résolus, soit vous n'avez aucune chance.

En particulier, les goulots d'étranglement de la centralisation pour le staking sont:

• Centralisation de la construction de blocs (cette section)
• Centralisation du jalonnement pour des raisons économiques (section suivante)
• Centralisation du jalonnement en raison du minimum de 32 ETH (résolu avec Orbit ou d'autres techniques ; voir l'article sur le Fusionner)
• Centralisation du jalonnement en raison des exigences matérielles (résolues dans le Verge, avec des clients sans état et plus tard ZK-EVMs)

Résoudre l'un des quatre augmente les gains de la résolution des autres.

De plus, il existe des interactions entre le pipeline de construction de blocs et la conception de finalité d'un seul créneau, en particulier dans le contexte de la réduction des temps de créneau. De nombreux designs de pipeline de construction de blocs finissent par augmenter les temps de créneau. De nombreux pipelines de construction de blocs impliquent des rôles pour les attestants à plusieurs étapes du processus. Pour cette raison, il peut être utile de réfléchir aux pipelines de construction de blocs et à la finalité d'un seul créneau simultanément.

Réparation de l'économie du jalonnement

Quel problème résolvons-nous?

Aujourd'hui, environ 30% de l'approvisionnement en ETH promeut activement la mise en jeu. Cela suffit largement pour protéger Ethereum contre les attaques de 51%. Si le pourcentage d'ETH mis en jeu augmente beaucoup plus, les chercheurs redoutent un scénario différent : les risques qui apparaîtraient si presque tout l'ETH était mis en jeu. Ces risques comprennent :

• La mise en jeu passe d'une tâche rentable pour les spécialistes à un devoir pour tous les détenteurs d'ETH. Par conséquent, le miseur moyen serait beaucoup moins enthousiaste et choisirait la méthode la plus simple (réaliste, déléguer leurs jetons à l'opérateur centralisé offrant le plus de commodité).
• La crédibilité du mécanisme de réduction des récompenses s'affaiblit si presque tous les ETH sont mis en jeu.
• Un seul jeton de mise en liquidité pourrait prendre en charge la majeure partie de la mise et même s'approprier les effets de réseau de "l'argent" de l'ETH lui-même
• Ethereum émet inutilement un supplémentaire d'environ 1 million d'ETH par an. Dans le cas où un jeton de jalonnement liquide prendrait de l'ampleur, une grande partie de cette valeur pourrait même être capturée par le LST.

Qu'est-ce que c'est et comment cela fonctionne-t-il?

Historiquement, une classe de solution a été la suivante : si tout le monde est inévitable et qu’un jeton de jalonnement liquide est inévitable, alors rendons le jalonnement convivial pour avoir un jeton de jalonnement liquide qui est réellement sans confiance, neutre et décentralisé au maximum. Une façon simple de le faire est de plafonner les pénalités de jalonnement à, par exemple. 1/8, ce qui rendrait 7/8 de l’ETH staké non slashable, et donc éligible pour être placé dans le même token de staking liquide. Une autre option consiste à créer explicitement deux niveaux de mise en jeu: « rémunération du risque » (pouvant être pénalisée) du staking, qui serait limitée à 1/8 de tous les ETH, et le staking « sans risque » (impossible d'être pénalisé), auquel tout le monde pourrait participer.

Cependant, une critique de cette approche est qu'elle @vbuterin/staking_2023_10?type=view">seems économiquement équivalent à quelque chose de beaucoup plus simple : réduire massivement l'émission si la mise approche un plafond prédéterminé. L'argument de base est le suivant : si nous nous retrouvons dans un monde où le niveau de risque supporté rapporte 3,4 % et le niveau sans risque (auquel tout le monde participe) rapporte 2,6 %, c'est en réalité la même chose que dans un monde où la mise en jeu d'ETH rapporte 0,8 % et simplement détenir de l'ETH rapporte 0 %. Les dynamiques du niveau de risque supporté, comprenant à la fois la quantité totale misée et la centralisation, seraient les mêmes dans les deux cas. Et nous devrions donc simplement faire la chose simple et réduire l'émission.

Le principal contre-argument à cette ligne d'argumentation serait si nous pouvions donner au « niveau sans risque » un rôle utile et un certain niveau de risque (par exemple, en tant que proposé par Dankrad ici.

Ces deux lignes de propositions impliquent de modifier la courbe d'émission, de manière à rendre les rendements prohibitivement faibles si le montant de l'enjeu devient trop élevé.

Gauche: une proposition pour une courbe d'émission ajustée, par Justin Drake. Droite: un autre ensemble de propositions, par Anders Elowsson.

En revanche, la mise en jeu à deux niveaux nécessite de définir deux courbes de rendement : (i) le taux de rendement pour la mise en jeu « de base » (sans risque ou à faible risque) et (ii) la prime pour la mise en jeu à risque. Il existe différentes façons de définir ces paramètres : par exemple, si vous définissez un paramètre strict selon lequel 1/8 de la mise en jeu est susceptible d'être réduit, alors la dynamique du marché déterminera la prime sur le taux de rendement que la mise en jeu susceptible d'être réduite reçoit.

Un autre sujet important ici est la capture de la MEV. Aujourd'hui, les revenus de la MEV (par exemple, l'arbitrage DEX, le sandwich…) vont aux proposeurs, c'est-à-dire aux validateurs. Il s'agit de revenus totalement "opaques" pour le protocole : le protocole ne sait pas s'il s'agit d'un taux annuel de 0,01 %, de 1 % ou de 20 %. L'existence de ce flux de revenus est très gênante à plusieurs égards :

1. Il s'agit d'une source de revenus volatile, car chaque staker individuel ne l'obtient que lorsqu'il propose un bloc, ce qui se produit une fois tous les ~4 mois aujourd'hui. Cela crée une incitation à rejoindre des pools pour un revenu plus stable.
2. Cela conduit à une allocation déséquilibrée des incitations : trop pour proposer, trop peu pour attester.
3. Il rend très difficile la mise en place d'un plafonnement des enjeux : même si le taux de rendement « officiel » est nul, les revenus MEV seuls peuvent suffire à inciter tous les détenteurs d'ETH à miser. Par conséquent, une proposition réaliste de plafonnement des enjeux devrait en réalité avoir des rendements approchant l'infini négatif, comme par exemple.@vbuterin/single_slot_finality?type=view#Plafonnement-économique-des-dépôts-totaux">présenté ici. Cela, il va sans dire, crée plus de risques pour les enjeux, en particulier les enjeux solo.

Nous pouvons résoudre ces problèmes en trouvant un moyen de rendre le revenu MEV lisible pour le protocole et de le capturer. La première proposition était Lissage de la MEV de Francesco; aujourd'hui, il est largement admis que tout mécanisme permettant de mettre aux enchères les droits de proposition de bloc (ou, plus généralement, l'autorité suffisante pour capturer presque tous les MEV) à l'avance atteint le même objectif.

Quels sont les liens vers les recherches existantes?

• Issuance.wtf: https://issuance.wtf/
• Économie de mise en jeu de fin de partie, un argument en faveur du ciblage:https://ethresear.ch/t/endgame-staking-economics-a-case-for-targeting/18751
• Propriétés au niveau de l'émission, Anders Elowsson: https://ethresear.ch/t/propriétés-de-consensus-de-niveau-d-émission-des-incitations-et-de-la-variabilité-%C3%A0-travers-les-courbes-de-r%C3%A9compense-potentielles/18448
• Limitation de la taille de l'ensemble de validateurs:@vbuterin/single_slot_finality?type=view#Economic-capping-of-total-deposits"">https://notes.ethereum.org/@vbuterin/single_slot_finality?type=view#Economic-capping-of-total-deposits
• Réflexions sur les idées de mise en jeu à plusieurs niveaux: @vbuterin/staking_2023_10 ?type=vue"">https://notes.ethereum.org/@vbuterin/staking_2023_10?type=view
• Rainbow staking : https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683
• La proposition de participation liquide de Dankrad : https://notes.ethereum.org/Pcq3m8B8TuWnEsuhKwCsFg
• Lissage de la MEV, par Francesco:https://ethresear.ch/t/committee-driven-mev-smoothing/10408
• MEV burn, par Justin Drake:https://ethresear.ch/t/mev-burn-a-simple-design/15590

Que reste-t-il à faire, et quels sont les compromis ?

La principale tâche restante consiste à soit accepter de ne rien faire et d'accepter les risques que presque tout l'ETH soit à l'intérieur des LST, soit finaliser et convenir des détails et des paramètres de l'une des propositions ci-dessus. Un résumé approximatif des avantages et des risques est :

Comment interagit-il avec les autres parties de la feuille de route ?

Un point important d'intersection concerne le solo-staking. Aujourd'hui, les VPS les moins chers capables d'exécuter un nœud Ethereum coûtent environ 60 $ par mois, principalement en raison des coûts de stockage sur disque dur. Pour un staker de 32 ETH (84 000 $ au moment de la rédaction de ces lignes), cela diminue le rendement annuel de (60 * 12) / 84000 ~= 0,85%. Si les rendements totaux du staking chutent en dessous de 0,85%, le solo-staking sera non viable pour de nombreuses personnes à ces niveaux.

Si nous voulons que le solo staking continue à être viable, cela met davantage l'accent sur la nécessité de réduire les coûts d'exploitation du nœud, ce qui sera fait dans le Verge: la non-étatique éliminera les besoins en espace de stockage, ce qui peut être suffisant en lui-même, puis les preuves de validité L1 EVM rendront les coûts complètement négligeables.

D'autre part, la combustion de MEV aide sans doute le solo-staking. Bien qu'elle diminue les rendements pour tout le monde, elle diminue surtout la variance, rendant le staking moins semblable à une loterie.

Enfin, tout changement dans l'émission interagit avec d'autres changements fondamentaux de la conception du staking (par exemple, le staking arc-en-ciel). Un point particulier de préoccupation est que si les rendements du staking deviennent très faibles, cela signifie que nous devons choisir entre (i) rendre les pénalités également faibles, réduisant les désincitatifs contre un mauvais comportement, et (ii) maintenir des pénalités élevées, ce qui augmenterait le nombre de circonstances dans lesquelles même des validateurs bien intentionnés se retrouveraient accidentellement avec des rendements négatifs s'ils ont de la malchance avec des problèmes techniques ou même des attaques.

Solutions de la couche d'application

Les sections ci-dessus se sont concentrées sur les modifications apportées à Ethereum L1 qui peuvent résoudre des risques de centralisation importants. Cependant, Ethereum n'est pas seulement un L1, c'est un écosystème, et il existe également des stratégies importantes au niveau de l'application qui peuvent aider à atténuer les risques mentionnés ci-dessus. Quelques exemples incluent :

• Solutions matérielles de jalonnement spécialisées - certaines entreprises, telles que Dappnode, vendent du matériel spécifiquement conçu pour faciliter au maximum le fonctionnement d'un nœud de mise en jeu. Une façon de rendre cette solution plus efficace est de se poser la question suivante : si un utilisateur consacre déjà des efforts pour faire fonctionner une boîte connectée à Internet 24 heures sur 24 et 7 jours sur 7, quels autres services pourraient-elle fournir (à l'utilisateur ou à d'autres) qui bénéficieraient de la décentralisation ? Des exemples qui me viennent à l'esprit incluent (i) la mise en œuvre de LLMs hébergés localement, pour des raisons de souveraineté et de confidentialité, et (ii) la gestion de nœuds pour un VPN décentralisé.
• Squad staking - celasolution de Obolpermet à plusieurs personnes de miser ensemble selon un format M-sur-N. Cela deviendra probablement de plus en plus populaire avec le temps, car l'état de non-appartenance et plus tard les preuves de validité L1 EVM réduiront les frais généraux liés au fonctionnement de plusieurs nœuds, et le bénéfice pour chaque participant individuel de devoir se soucier beaucoup moins d'être en ligne tout le temps commence à dominer. Il s'agit d'une autre façon de réduire la charge cognitive du staking et de garantir que le staking individuel prospère à l'avenir.
• Airdrops - Starknet a donné un distribution airdrop aux stakers solitaires. D'autres projets souhaitant disposer d'un ensemble d'utilisateurs décentralisé et aligné sur les valeurs peuvent également envisager de distribuer des airdrops ou des réductions aux validateurs identifiés comme étant probablement des stakers solitaires.
• Marchés de construction de blocs décentralisés - en utilisant une combinaison de ZK, MPC et TEEs, il est possible de créer un constructeur de blocs décentralisé qui participe, et gagne, le jeu d'enchères APS, tout en offrant en même temps une confidentialité pré-confirmation et des garanties de résistance à la censure à ses utilisateurs. Il s'agit d'une autre voie vers l'amélioration du bien-être des utilisateurs dans un monde APS.
• Minimisation de l'EVN au niveau de la couche d'application - des applications individuelles peuvent être construites de manière à "fuir" moins d'EVN vers L1, réduisant ainsi l'incitation pour les constructeurs de blocs à créer des algorithmes spécialisés pour le collecter. Une stratégie simple qui est universelle, bien que peu pratique et briseuse de composabilité, consiste pour le contrat à mettre toutes les opérations entrantes dans une file d'attente et à les exécuter dans le prochain bloc, et à mettre aux enchères le droit de sauter la file d'attente. D'autres approches plus sophistiquées comprennent la réalisation de davantage de travail hors chaîne, par exemple.Cowswapfait. Les oracles peuvent également être redessinés pour minimiservaleur extractible par oracle.

Avertissement：

1. Cet article est repris de [ Vitalik Buterin], Tous les droits d'auteur appartiennent à l'auteur original [Vitalik Buterin]. S'il y a des objections à cette réimpression, veuillez contacter le Porte Apprendrel'équipe et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: Les opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.