Auteur : Vitalik, fondateur d'Ethereum ; traduit par : Deng Tong, Jinse Caijing
Note : Cet article est la troisième partie de la série "Développement futur du protocole Ethereum" publiée récemment par le fondateur d'Ethereum, Vitalik, intitulée "Avenirs possibles du protocole Ethereum, partie 3 : La Fléau". La deuxième partie est disponible sur Jinse Caijing "Vitalik : Comment le protocole Ethereum devrait évoluer à l'étape de la Surge", et la première partie est intitulée "Quelles améliorations peuvent encore être apportées au PoS d'Ethereum". Voici 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 de participation due à des pressions économiques. Si la participation au mécanisme central de preuve de participation présente des économies d'échelle, cela conduira naturellement à une domination des grands acteurs, tandis que les petits acteurs quitteront pour rejoindre de grands pools de minage. Cela augmente le risque d'attaques à 51 %, de révisions de transactions et d'autres crises. En plus des risques de centralisation, il existe également un risque d'extraction de valeur : une petite partie des personnes obtient une valeur qui aurait autrement été dirigée vers les utilisateurs d'Ethereum.
L'année dernière, notre compréhension de ces risques a considérablement augmenté. Comme on le sait, ce risque existe à deux endroits clés : (i) la construction de blocs, et (ii) les règles de capital de mise. Les plus grands participants peuvent exécuter des algorithmes plus complexes ("extraction MEV") pour générer des blocs, ce qui leur apporte des revenus de blocs plus élevés. Les grands participants peuvent également résoudre plus efficacement l'inconvénient de l'argent bloqué en libérant des fonds en tant que jetons de mise liquide (LST) à d'autres. En plus des problèmes directs entre les petits et les grands stakers, il y a aussi la question de savoir si (ou si cela va) trop de ETH sera mis.
Feuille de route de Scourge 2023
Cette année, la construction de la blockchain a fait d'importants progrès, le plus notable étant la fusion de "l'inclusion des listes par le comité avec quelques solutions de tri ciblées" en tant que solution idéale, ainsi que des recherches importantes sur l'économie de la preuve d'enjeu, y compris des modèles de staking à deux niveaux et la réduction de l'émission pour limiter le pourcentage d'ETH staké.
Les objectifs clés de La Fléau
Réduire au minimum les risques 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 appelés MEV et pools de staking)
Réduire autant que possible le risque de surexploitation de la valeur des utilisateurs.
Cet article est divisé en trois parties
Réparation du pipeline de construction de blocs
Réparation de l'économie de staking
Solutions de couche applicative
Réparation de la construction de blocs
Quel problème devons-nous résoudre ?
Aujourd'hui, la construction de blocs Ethereum est principalement réalisée grâce à la séparation du propser-builder hors protocole de MEVBoost. Lorsque les validateurs ont l'opportunité de proposer un bloc, ils délèguent le travail de sélection du contenu du bloc à des participants spécialisés appelés constructeurs. La tâche de sélectionner le contenu du bloc qui maximise les revenus est intensivement économique d'échelle : elle nécessite des algorithmes spécialisés pour déterminer quelles transactions inclure afin d'extraire autant de valeur que possible des outils financiers en chaîne et des transactions des utilisateurs qui interagissent avec eux (c'est ce qu'on appelle l'"extraction de MEV"). Les validateurs font face à une tâche de "dumb-pipe" relativement légère en termes d'économies d'échelle, à savoir écouter les enchères et accepter la plus haute offre, ainsi qu'à d'autres responsabilités telles que la preuve.
Graphique programmatique de ce que fait MEVBoost : les constructeurs dédiés prennent en charge les tâches rouges, tandis que les parties prenantes s'occupent des tâches bleues.
Il existe plusieurs versions, y compris la "séparation des proposeurs et des bâtisseurs" (PBS) et la "séparation des validateurs et des proposeurs" (APS). La différence entre elles concerne des détails fins, à savoir quelles responsabilités incombent à chacun des deux participants : en gros, dans PBS, les validateurs continuent de proposer des blocs, mais reçoivent la charge utile des bâtisseurs, tandis que dans APS, l'ensemble du créneau devient la responsabilité du bâtisseur. Récemment, APS a été préféré à PBS car il réduit encore la motivation des proposeurs à coexister avec les bâtisseurs. Notez que l'APS ne s'applique qu'aux blocs d'exécution contenant des transactions ; les blocs de consensus contenant des données liées à la preuve de participation (comme les preuves) continueront d'être distribué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 qui exécutent des tâches "spécialisées" ont tendance à devenir très centralisés. C'est la construction de blocs d'Ethereum d'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 leurs revenus peuvent également avoir d'autres effets négatifs sur les utilisateurs. Les "attaques de sandwich" peuvent entraîner des pertes importantes pour les utilisateurs effectuant des transactions de jetons en raison du slippage. Pour rendre ces transactions introduites par des attaques bloquantes sur la chaîne, les prix du Gas pour les autres utilisateurs ont augmenté.
Qu'est-ce que c'est et comment ça fonctionne ?
La solution de pointe consiste à décomposer davantage les tâches de production de blocs : nous allons redonner aux proposeurs (c'est-à-dire les validateurs) la tâche de sélectionner les transactions, tandis que les constructeurs ne peuvent que choisir le tri et insérer quelques-unes de leurs propres transactions. C'est ce que la liste d'inclusion cherche à réaliser.
À l'heure T, un validateur choisi au hasard crée une liste contenant des transactions valides à l'état actuel de la blockchain. À l'heure T+1, un constructeur de blocs (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 inclure chaque transaction de la liste, mais ils peuvent choisir l'ordre et ajouter leurs propres transactions.
La proposition de liste d'inclusion obligatoire de sélection de fourche (FOCIL) implique un comité composé de plusieurs créateurs de listes d'inclusion pour chaque bloc. Pour retarder une transaction d'un bloc, k créateurs de listes d'inclusion sur k (par exemple k = 16) doivent examiner cette transaction. FOCIL, en combinaison avec le proposeur final sélectionné par enchère, doit inclure la liste d'inclusion, mais peut être réorganisé et de nouvelles transactions peuvent être ajoutées, généralement appelées "FOCIL + APS".
Une autre méthode pour résoudre ce problème est d'avoir plusieurs propositions concurrentes (MCP), par exemple BRAID. BRAID essaie d'éviter de diviser le rôle de proposeur de bloc en parties à faible économie d'échelle et à forte économie d'échelle, mais tente plutôt de répartir le processus de production de blocs entre de nombreux participants, de sorte que chaque proposeur n'ait besoin que d'un niveau de complexité modéré pour maximiser ses revenus. Le fonctionnement de MCP consiste à laisser k proposeurs parallèles générer une liste de transactions, puis à utiliser un algorithme déterministe (par exemple, trier par frais de la plus élevée à la plus basse) pour choisir l'ordre.
BRAID ne cherche pas à réaliser que le proposeur de bloc dumb-pipe exécutant le logiciel par défaut est le meilleur objectif. Les deux raisons faciles à comprendre pour lesquelles il ne peut pas le faire sont :
Attaque d'arbitrage de type backdoor : Supposons que le temps moyen de soumission du proposeur soit T, alors que vous pourriez soumettre en dernier et être encore inclus à peu près à T+1. Maintenant, supposons qu'entre T et T+1, le prix de ETH/USDC sur l'échange centralisé passe de 2500 dollars à 2502 dollars. Le proposeur peut attendre une seconde de plus, puis ajouter des transactions supplémentaires pour réaliser un arbitrage sur l'échange décentralisé en chaîne, réalisant jusqu'à 2 dollars de profit par ETH. Un proposeur aguerri ayant de bonnes connexions au réseau est plus en mesure de 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 en tant que fonction de dumb-pipe.
En plus de ces deux extrêmes, il existe une série de conceptions possibles situées entre les deux. Par exemple, vous pouvez enchérir sur un rôle qui a uniquement le droit de s'attacher à un bloc, sans droit de réorganiser ou de préfixer. Vous pouvez même leur permettre de s'attacher ou de préfixer, mais pas d'insérer au milieu ou de 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 offre de nombreux avantages en réduisant leur autorité.
mémoire pool cryptage
Une technologie cruciale 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 les fonctions d'enchères) est le pool de mémoire cryptée. Le pool de mémoire cryptée est une technologie qui permet aux utilisateurs de diffuser leurs transactions sous forme cryptée, accompagnées d'une preuve de validité, et les transactions sont incluses dans le bloc sous forme cryptée, sans que le constructeur de blocs ne connaisse leur contenu. Le contenu des transactions est publié ultérieurement.
Le principal défi de la mise en œuvre d'un pool de mémoire cryptée est de proposer un design qui garantit que toutes les transactions seront révélées ultérieurement : un simple schéma de "soumission et révélation" ne fonctionne pas, car si la révélation est volontaire, le choix de révéler ou non constitue en soi une influence de "dernier incitateur" sur le bloc exploitable. Les deux principales techniques sont (i) le décryptage par seuil et (ii) le cryptage différé, qui est un primitive étroitement lié à la fonction de retard vérifiable (VDF).
Quelles sont les relations avec les recherches existantes ?
Explication de la centralisation des MEV et des constructeurs :
MEVBoost：
Solution PBS (proposée au début pour ces problèmes) :
Liste des lectures liées à la liste de Mike Neuder :
Liste des EIP inclus :
FOCIL：
Démonstration de BRAID par Max Resnick :
« La priorité est ce dont vous avez besoin », auteur : Dan Robinson :
À propos des outils et protocoles de multi-proposition :
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é :
Multiples MEV et liste des inclusions :
Que faut-il encore faire, quels compromis faut-il envisager ?
Nous pouvons considérer toutes les solutions mentionnées ci-dessus comme différentes manières de diviser les droits de participation au stake, classées de l'économie à petite échelle ("dumb-pipe") à l'économie à grande échelle ("professionnalisation amicale"). Avant 2021, tous ces droits étaient regroupés en un seul participant :
Le problème central est : tout pouvoir significatif encore détenu par les parties prenantes pourrait finalement devenir un pouvoir "lié à MEV". Nous souhaitons qu'un ensemble de participants hautement décentralisés détienne autant de pouvoir que possible ; cela signifie (i) conférer un pouvoir considérable aux parties prenantes, et (ii) s'assurer que les parties prenantes soient aussi décentralisées que possible, ce qui signifie qu'elles n'ont pratiquement aucune incitation à l'intégration motivée par des économies d'échelle. C'est une tension difficile à gérer.
Un défi particulier est le MEV multi-block : dans certaines situations, si le gagnant de l'enchère exécute plusieurs slots consécutifs et qu'il n'est pas autorisé à effectuer des transactions liées au MEV dans d'autres blocs que le dernier qu'il contrôle, il peut gagner plus d'argent. Si une liste d'inclusion les y contraint, ils peuvent essayer de contourner cela en ne publiant tout simplement aucun bloc pendant ces périodes. Les gens peuvent créer des listes d'inclusion inconditionnelles, et si le constructeur ne les fournit pas, cette liste d'inclusion devient directement le bloc, mais cela rend la liste d'inclusion liée au MEV. La solution ici pourrait impliquer quelques compromis, y compris l'acceptation de quelques incitations de bas niveau pour soudoyer les gens à inclure des transactions 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 complètement différent. La partie "stakers" est plus grande, mais elle est divisée en deux parties : les stakers légers et les stakers lourds. En même temps, comme les transactions sont classées par ordre décroissant des frais prioritaires, le choix au sommet du bloc est en fait mis aux enchères par le marché des frais, ce schéma peut être considéré comme similaire à PBS.
Veuillez noter que la sécurité de BRAID dépend en grande partie du pool de mémoire cryptée ; sinon, le mécanisme d'enchères en haut de bloc est facilement vulnérable aux attaques de vol de stratégie (en essence : copier les transactions d'autres personnes, échanger l'adresse du destinataire et payer des frais élevés de 0,01 %). Cette demande de confidentialité pré-incluse est également la raison pour laquelle la mise en œuvre de PBS est si délicate.
Enfin, une version plus "radicale" de FOCIL + APS, par exemple. APS ne détermine que les options à la fin du bloc comme suit :
La tâche principale restante est de (i) s'engager à consolider diverses propositions et à analyser leurs conséquences, ainsi que (ii) à 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 certaines tâches, par exemple :
Continuer à travailler sur la conception de pools de mémoire cryptographique, et atteindre un niveau tel que notre conception est à la fois robuste et assez simple, et semble être prête à ê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 des listes imbriquées contenant des blobs, ainsi que (ii) pour être convivial pour les validateurs sans état.
Plus de travail sur la conception d'enchères optimales APS.
De plus, il convient de noter que ces différentes propositions ne sont pas nécessairement des carrefours incompatibles. Par exemple, la mise en œuvre de FOCIL + APS peut facilement servir de tremplin pour la mise en œuvre de BRAID. Une stratégie conservatrice efficace est l'approche "wait and see", où nous mettons d'abord en œuvre une solution dans laquelle les pouvoirs des stakers sont limités, la majeure partie des pouvoirs étant mise aux enchères, puis, au fil du temps, à mesure que nous en savons plus sur le fonctionnement du marché MEV en temps réel, nous augmentons lentement le pouvoir des parties prenantes.
Particulièrement, le goulot d'étranglement de la centralisation du staking est :
Construction centralisée des blocs (cette section)
Centralisation des staking pour des raisons économiques (section suivante)
La centralisation de la mise en jeu due à un minimum de 32 Éther (à résoudre par Orbit ou d'autres technologies ; voir les articles sur la fusion)
Centralisation du staking en raison des exigences matérielles (résolu dans Verge grâce à un client sans état et au ZK-EVM ultérieur)
Résoudre l'un de ces quatre problèmes augmentera les bénéfices de la résolution de n'importe quel autre problème.
De plus, il existe une interaction entre le pipeline de construction de blocs et la finalité unique de créneau, en particulier dans les cas où l'on essaie de réduire le temps de créneau. De nombreux conceptions de pipeline de construction de blocs finissent par augmenter le temps de créneau. De nombreux pipelines de construction de blocs impliquent le rôle de prouveur à plusieurs étapes du processus. Par conséquent, il vaut la peine de considérer simultanément le pipeline de construction de blocs et la finalité unique.
Réparation de l'économie de la mise en jeu
Quel problème devons-nous résoudre ?
Aujourd'hui, environ 30 % de l'offre d'ETH est activement mise en jeu. Cela suffit à protéger Ethereum contre les attaques à 51 %. Si la proportion d'ETH mis en jeu devient plus grande, les chercheurs craignent qu'une situation différente n'émerge : si presque tout l'ETH est mis en jeu, des risques apparaîtront. Ces risques incluent :
Le staking est passé d'une tâche lucrative pour les experts à une responsabilité pour tous les détenteurs d'ETH. Par conséquent, les stakers ordinaires seront moins enthousiastes et choisiront la méthode la plus simple (en réalité, en déléguant leurs jetons à l'opérateur centralisé le plus pratique).
Si presque tous les ETH sont stakés, la crédibilité du mécanisme de réduction sera affaiblie.
Un seul jeton de liquidité staké peut prendre en charge la majorité des droits de vote, voire le réseau d'effet de "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 les LST.
Qu'est-ce que c'est et comment ça fonctionne ?
Historiquement, une solution de ce type est : si tout le monde doit inévitablement staker, et que les jetons de staking liquide sont inévitables, alors rendons le staking convivial pour avoir des jetons de staking liquide qui sont en réalité sans confiance, neutres et aussi décentralisés que possible. Une méthode simple consiste à limiter la pénalité de staking à 1/8, ce qui rendra 7/8 de l'ETH staké non réductible, donc éligible pour être placé dans le même jeton de staking liquide. Une autre option est de créer explicitement un staking à deux niveaux : le staking "à risque" (réductible).
Cependant, une critique de cette méthode est qu'elle équivaut économiquement à quelque chose de beaucoup plus simple : si la part de capital approche d'un certain plafond prédéterminé, alors l'émission est considérablement réduite. L'argument de base est le suivant : si nous entrons finalement dans un monde où le taux de rendement de la couche de prise de risque est de 3,4 % et celui de la couche sans risque (où tout le monde participe) est de 2,6 %, cela revient en réalité à un monde où le rendement de l'Éther staké est de 0,8 % et le rendement de la simple détention d'Éther est de 0 %. La dynamique de la couche de prise de risque, y compris le montant total staké et le degré de centralisation, est la même dans les deux cas. Donc, nous devrions faire quelque chose de simple et réduire l'émission.
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 de Anders Elowsson.
D'autre part, le staking à deux niveaux nécessite de définir deux courbes de rendement : (i) le taux de rendement du staking "de base" (sans risque ou à faible risque), et (ii) une prime pour le staking à risque. Il existe plusieurs façons de définir ces paramètres : par exemple, si vous définissez un paramètre fixe, c'est-à-dire que 1/8 des droits de vote est réductible, alors la dynamique du marché déterminera la prime du taux de rendement des droits de vote réductibles.
Un autre thème important ici est la capture de MEV. De nos jours, les revenus de MEV (par exemple, l'arbitrage DEX, les sandwichs...) vont aux proposeurs, c'est-à-dire aux stakers. C'est un revenu complètement "opaque" pour le protocole : le protocole ne peut pas savoir s'il s'agit d'un taux d'intérêt de 0,01 %, de 1 % ou de 20 %. Sous plusieurs angles, l'existence de cette source de revenu est très peu pratique :
C'est une source de revenus instable, car chaque partie prenante ne peut l'obtenir qu'en proposant un bloc, 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 des incitations déséquilibrée : trop de propositions, trop peu de preuves.
Cela rend difficile la mise en œuvre d'un plafond d'équité : même si le taux de rendement "officiel" est de zéro, les revenus MEV seuls peuvent suffire à inciter tous les détenteurs d'ETH à participer au staking. Par conséquent, une proposition réaliste de plafond d'équité doit en réalité rendre le rendement proche 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 clairement visibles dans le protocole et de les capturer. La première proposition était le MEV smoothing de Francesco ; aujourd'hui, il est généralement admis que tout mécanisme permettant d'enchérir à l'avance sur 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.
Quelles sont les relations avec les recherches existantes ?
Émettre wtf :
Endgame économie de staking, étude de cas :
Attributs de niveau d'émission, Anders Elowsson :
Limite supérieure de la taille des paramètres du validateur :
Réflexions sur l'idée de la multi-staking :
Pledge Arc-en-ciel :
Proposition de staking liquide de Dankrad :
Lissage MEV, auteur : Francesco :
MEV burn, auteur : Justin Drake :
Que faut-il encore faire, quels compromis faut-il envisager ?
La principale tâche restante est soit d'accepter de ne prendre aucune mesure et d'accepter le risque que presque tous les ETH soient dans 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é approximatif des bénéfices et des risques est le suivant :
Comment interagit-il avec les autres parties de la feuille de route ?
Un point de croisement important concerne le staking individuel. Aujourd'hui, le VPS le moins cher capable de faire fonctionner un nœud Ethereum coûte environ 60 dollars par mois, principalement en raison des coûts de stockage sur disque. Pour les stakers de 32 ETH (84 000 dollars au moment de la rédaction), cela réduit l'APY à (60 * 12) / 84000 ~= 0,85 %. Si le taux de retour total du staking est inférieur à 0,85 %, alors pour de nombreuses personnes à ce niveau, le staking individuel devient non viable.
Si nous souhaitons que le staking individuel reste viable, cela souligne davantage la nécessité de réduire les coûts d'exploitation des nœuds, ce qui sera réalisé dans Verge : l'absence d'état éliminera les besoins en espace de stockage, ce qui pourrait suffire en soi, puis la preuve d'efficacité de l'EVM L1 rendra les coûts dérisoires.
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 tout le monde, il est encore plus important de diminuer la variance, rendant le staking moins semblable à une loterie.
Enfin, tout changement dans l’émission interagira avec d'autres changements fondamentaux dans la conception du staking (comme le staking arc-en-ciel). Une question particulièrement préoccupante est que si les récompenses de staking deviennent très faibles, cela signifie que nous devons faire un choix entre : (i) réduire la sévérité des pénalités, diminuant ainsi les incitations à un comportement inapproprié ; (ii) maintenir une sévérité élevée des pénalités, ce qui pourrait entraîner une série de situations où même des validateurs de bonne foi, s'ils rencontrent des problèmes techniques ou même des attaques, pourraient accidentellement subir des pertes.
Solutions de couche d'application
La partie ci-dessus met en avant les changements de l'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 d'importantes stratégies de couche d'application qui peuvent aider à atténuer les risques mentionnés ci-dessus. Quelques exemples incluent :
Solutions matérielles de staking dédiées — Certaines entreprises (comme Dappnode) vendent du matériel spécialement conçu pour faciliter l'exploitation des nœuds de staking. Une façon de rendre cette solution plus efficace est de poser une question : si un utilisateur a déjà investi des efforts pour faire fonctionner une boîte et se connecter à Internet, quels autres services (pour l'utilisateur ou d'autres) pourraient également bénéficier de la décentralisation ? Des exemples qui me viennent à l'esprit incluent (i) l'exécution d'un Master en Droit auto-hébergé pour des raisons de souveraineté personnelle et de confidentialité, ainsi que (ii) l'exploitation de nœuds de VPN décentralisés.
Staking en équipe —— La 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 de validité sans état et les EVM L1 ultérieurs réduiront les frais d'exploitation de plus nœuds, et chaque participant n'aura plus à se soucier des bénéfices d'être toujours en ligne, qui commenceront à dominer. C'est une autre méthode pour réduire la surcharge cognitive du staking et garantir que le staking individuel prospère à l'avenir.
Airdrop —— Starknet offre des airdrops aux stakers individuels. D'autres projets souhaitant disposer d'une communauté d'utilisateurs décentralisée et partageant des valeurs similaires peuvent également envisager d'offrir des airdrops ou des réductions aux validateurs identifiés comme 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é, de participer et de gagner au jeu d'enchères APS, tout en offrant des garanties de confidentialité pré-confirmées et de résistance à la censure pour ses utilisateurs. C'est une autre voie pour améliorer le bien-être des utilisateurs dans le monde d'APS.
Minimisation de l'MEV au niveau de l'application —— Une application unique peut être construite de manière à « fuir » moins d'MEV vers L1, réduisant ainsi l'incitation pour les créateurs de blocs à créer des algorithmes spécialisés pour collecter l'MEV. Une stratégie simple mais générale consiste à placer toutes les opérations entrantes dans une file d'attente et à les exécuter dans le bloc suivant, tout en mettant aux enchères le droit de passer devant, bien que cela soit peu pratique et nuisible à la combinabilité. D'autres méthodes plus complexes incluent de faire plus de travail hors chaîne, comme ce que fait Cowswap. Les oracles peuvent également être redessinés pour minimiser la valeur pouvant être extraite par les oracles.
Un grand merci à Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes et Max Resnick pour leurs retours et leurs révisions, ainsi qu'aux 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 : les objectifs clés de la phase Scourge d'Ethereum
Auteur : Vitalik, fondateur d'Ethereum ; traduit par : Deng Tong, Jinse Caijing
Note : Cet article est la troisième partie de la série "Développement futur du protocole Ethereum" publiée récemment par le fondateur d'Ethereum, Vitalik, intitulée "Avenirs possibles du protocole Ethereum, partie 3 : La Fléau". La deuxième partie est disponible sur Jinse Caijing "Vitalik : Comment le protocole Ethereum devrait évoluer à l'étape de la Surge", et la première partie est intitulée "Quelles améliorations peuvent encore être apportées au PoS d'Ethereum". Voici 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 de participation due à des pressions économiques. Si la participation au mécanisme central de preuve de participation présente des économies d'échelle, cela conduira naturellement à une domination des grands acteurs, tandis que les petits acteurs quitteront pour rejoindre de grands pools de minage. Cela augmente le risque d'attaques à 51 %, de révisions de transactions et d'autres crises. En plus des risques de centralisation, il existe également un risque d'extraction de valeur : une petite partie des personnes obtient une valeur qui aurait autrement été dirigée vers les utilisateurs d'Ethereum.
L'année dernière, notre compréhension de ces risques a considérablement augmenté. Comme on le sait, ce risque existe à deux endroits clés : (i) la construction de blocs, et (ii) les règles de capital de mise. Les plus grands participants peuvent exécuter des algorithmes plus complexes ("extraction MEV") pour générer des blocs, ce qui leur apporte des revenus de blocs plus élevés. Les grands participants peuvent également résoudre plus efficacement l'inconvénient de l'argent bloqué en libérant des fonds en tant que jetons de mise liquide (LST) à d'autres. En plus des problèmes directs entre les petits et les grands stakers, il y a aussi la question de savoir si (ou si cela va) trop de ETH sera mis.
Feuille de route de Scourge 2023
Cette année, la construction de la blockchain a fait d'importants progrès, le plus notable étant la fusion de "l'inclusion des listes par le comité avec quelques solutions de tri ciblées" en tant que solution idéale, ainsi que des recherches importantes sur l'économie de la preuve d'enjeu, y compris des modèles de staking à deux niveaux et la réduction de l'émission pour limiter le pourcentage d'ETH staké.
Les objectifs clés de La Fléau
Cet article est divisé en trois parties
Réparation de la construction de blocs
Quel problème devons-nous résoudre ?
Aujourd'hui, la construction de blocs Ethereum est principalement réalisée grâce à la séparation du propser-builder hors protocole de MEVBoost. Lorsque les validateurs ont l'opportunité de proposer un bloc, ils délèguent le travail de sélection du contenu du bloc à des participants spécialisés appelés constructeurs. La tâche de sélectionner le contenu du bloc qui maximise les revenus est intensivement économique d'échelle : elle nécessite des algorithmes spécialisés pour déterminer quelles transactions inclure afin d'extraire autant de valeur que possible des outils financiers en chaîne et des transactions des utilisateurs qui interagissent avec eux (c'est ce qu'on appelle l'"extraction de MEV"). Les validateurs font face à une tâche de "dumb-pipe" relativement légère en termes d'économies d'échelle, à savoir écouter les enchères et accepter la plus haute offre, ainsi qu'à d'autres responsabilités telles que la preuve.
Graphique programmatique de ce que fait MEVBoost : les constructeurs dédiés prennent en charge les tâches rouges, tandis que les parties prenantes s'occupent des tâches bleues.
Il existe plusieurs versions, y compris la "séparation des proposeurs et des bâtisseurs" (PBS) et la "séparation des validateurs et des proposeurs" (APS). La différence entre elles concerne des détails fins, à savoir quelles responsabilités incombent à chacun des deux participants : en gros, dans PBS, les validateurs continuent de proposer des blocs, mais reçoivent la charge utile des bâtisseurs, tandis que dans APS, l'ensemble du créneau devient la responsabilité du bâtisseur. Récemment, APS a été préféré à PBS car il réduit encore la motivation des proposeurs à coexister avec les bâtisseurs. Notez que l'APS ne s'applique qu'aux blocs d'exécution contenant des transactions ; les blocs de consensus contenant des données liées à la preuve de participation (comme les preuves) continueront d'être distribué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 qui exécutent des tâches "spécialisées" ont tendance à devenir très centralisés. C'est la construction de blocs d'Ethereum d'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 leurs revenus peuvent également avoir d'autres effets négatifs sur les utilisateurs. Les "attaques de sandwich" peuvent entraîner des pertes importantes pour les utilisateurs effectuant des transactions de jetons en raison du slippage. Pour rendre ces transactions introduites par des attaques bloquantes sur la chaîne, les prix du Gas pour les autres utilisateurs ont augmenté.
Qu'est-ce que c'est et comment ça fonctionne ?
La solution de pointe consiste à décomposer davantage les tâches de production de blocs : nous allons redonner aux proposeurs (c'est-à-dire les validateurs) la tâche de sélectionner les transactions, tandis que les constructeurs ne peuvent que choisir le tri et insérer quelques-unes de leurs propres transactions. C'est ce que la liste d'inclusion cherche à réaliser.
À l'heure T, un validateur choisi au hasard crée une liste contenant des transactions valides à l'état actuel de la blockchain. À l'heure T+1, un constructeur de blocs (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 inclure chaque transaction de la liste, mais ils peuvent choisir l'ordre et ajouter leurs propres transactions.
La proposition de liste d'inclusion obligatoire de sélection de fourche (FOCIL) implique un comité composé de plusieurs créateurs de listes d'inclusion pour chaque bloc. Pour retarder une transaction d'un bloc, k créateurs de listes d'inclusion sur k (par exemple k = 16) doivent examiner cette transaction. FOCIL, en combinaison avec le proposeur final sélectionné par enchère, doit inclure la liste d'inclusion, mais peut être réorganisé et de nouvelles transactions peuvent être ajoutées, généralement appelées "FOCIL + APS".
Une autre méthode pour résoudre ce problème est d'avoir plusieurs propositions concurrentes (MCP), par exemple BRAID. BRAID essaie d'éviter de diviser le rôle de proposeur de bloc en parties à faible économie d'échelle et à forte économie d'échelle, mais tente plutôt de répartir le processus de production de blocs entre de nombreux participants, de sorte que chaque proposeur n'ait besoin que d'un niveau de complexité modéré pour maximiser ses revenus. Le fonctionnement de MCP consiste à laisser k proposeurs parallèles générer une liste de transactions, puis à utiliser un algorithme déterministe (par exemple, trier par frais de la plus élevée à la plus basse) pour choisir l'ordre.
BRAID ne cherche pas à réaliser que le proposeur de bloc dumb-pipe exécutant le logiciel par défaut est le meilleur objectif. Les deux raisons faciles à comprendre pour lesquelles il ne peut pas le faire sont :
Dans BRAID, le prouveur peut toujours se séparer et fonctionner en tant que fonction de dumb-pipe.
En plus de ces deux extrêmes, il existe une série de conceptions possibles situées entre les deux. Par exemple, vous pouvez enchérir sur un rôle qui a uniquement le droit de s'attacher à un bloc, sans droit de réorganiser ou de préfixer. Vous pouvez même leur permettre de s'attacher ou de préfixer, mais pas d'insérer au milieu ou de 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 offre de nombreux avantages en réduisant leur autorité.
mémoire pool cryptage
Une technologie cruciale 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 les fonctions d'enchères) est le pool de mémoire cryptée. Le pool de mémoire cryptée est une technologie qui permet aux utilisateurs de diffuser leurs transactions sous forme cryptée, accompagnées d'une preuve de validité, et les transactions sont incluses dans le bloc sous forme cryptée, sans que le constructeur de blocs ne connaisse leur contenu. Le contenu des transactions est publié ultérieurement.
Le principal défi de la mise en œuvre d'un pool de mémoire cryptée est de proposer un design qui garantit que toutes les transactions seront révélées ultérieurement : un simple schéma de "soumission et révélation" ne fonctionne pas, car si la révélation est volontaire, le choix de révéler ou non constitue en soi une influence de "dernier incitateur" sur le bloc exploitable. Les deux principales techniques sont (i) le décryptage par seuil et (ii) le cryptage différé, qui est un primitive étroitement lié à la fonction de retard vérifiable (VDF).
Quelles sont les relations avec les recherches existantes ?
Explication de la centralisation des MEV et des constructeurs :
MEVBoost：
Solution PBS (proposée au début pour ces problèmes) :
Liste des lectures liées à la liste de Mike Neuder :
Liste des EIP inclus :
FOCIL：
Démonstration de BRAID par Max Resnick :
« La priorité est ce dont vous avez besoin », auteur : Dan Robinson :
À propos des outils et protocoles de multi-proposition :
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é :
Multiples MEV et liste des inclusions :
Que faut-il encore faire, quels compromis faut-il envisager ?
Nous pouvons considérer toutes les solutions mentionnées ci-dessus comme différentes manières de diviser les droits de participation au stake, classées de l'économie à petite échelle ("dumb-pipe") à l'économie à grande échelle ("professionnalisation amicale"). Avant 2021, tous ces droits étaient regroupés en un seul participant :
Le problème central est : tout pouvoir significatif encore détenu par les parties prenantes pourrait finalement devenir un pouvoir "lié à MEV". Nous souhaitons qu'un ensemble de participants hautement décentralisés détienne autant de pouvoir que possible ; cela signifie (i) conférer un pouvoir considérable aux parties prenantes, et (ii) s'assurer que les parties prenantes soient aussi décentralisées que possible, ce qui signifie qu'elles n'ont pratiquement aucune incitation à l'intégration motivée par des économies d'échelle. C'est une tension difficile à gérer.
Un défi particulier est le MEV multi-block : dans certaines situations, si le gagnant de l'enchère exécute plusieurs slots consécutifs et qu'il n'est pas autorisé à effectuer des transactions liées au MEV dans d'autres blocs que le dernier qu'il contrôle, il peut gagner plus d'argent. Si une liste d'inclusion les y contraint, ils peuvent essayer de contourner cela en ne publiant tout simplement aucun bloc pendant ces périodes. Les gens peuvent créer des listes d'inclusion inconditionnelles, et si le constructeur ne les fournit pas, cette liste d'inclusion devient directement le bloc, mais cela rend la liste d'inclusion liée au MEV. La solution ici pourrait impliquer quelques compromis, y compris l'acceptation de quelques incitations de bas niveau pour soudoyer les gens à inclure des transactions 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 complètement différent. La partie "stakers" est plus grande, mais elle est divisée en deux parties : les stakers légers et les stakers lourds. En même temps, comme les transactions sont classées par ordre décroissant des frais prioritaires, le choix au sommet du bloc est en fait mis aux enchères par le marché des frais, ce schéma peut être considéré comme similaire à PBS.
Veuillez noter que la sécurité de BRAID dépend en grande partie du pool de mémoire cryptée ; sinon, le mécanisme d'enchères en haut de bloc est facilement vulnérable aux attaques de vol de stratégie (en essence : copier les transactions d'autres personnes, échanger l'adresse du destinataire et payer des frais élevés de 0,01 %). Cette demande de confidentialité pré-incluse est également la raison pour laquelle la mise en œuvre de PBS est si délicate.
Enfin, une version plus "radicale" de FOCIL + APS, par exemple. APS ne détermine que les options à la fin du bloc comme suit :
La tâche principale restante est de (i) s'engager à consolider diverses propositions et à analyser leurs conséquences, ainsi que (ii) à 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 certaines tâches, par exemple :
De plus, il convient de noter que ces différentes propositions ne sont pas nécessairement des carrefours incompatibles. Par exemple, la mise en œuvre de FOCIL + APS peut facilement servir de tremplin pour la mise en œuvre de BRAID. Une stratégie conservatrice efficace est l'approche "wait and see", où nous mettons d'abord en œuvre une solution dans laquelle les pouvoirs des stakers sont limités, la majeure partie des pouvoirs étant mise aux enchères, puis, au fil du temps, à mesure que nous en savons plus sur le fonctionnement du marché MEV en temps réel, nous augmentons lentement le pouvoir des parties prenantes.
Particulièrement, le goulot d'étranglement de la centralisation du staking est :
Résoudre l'un de ces quatre problèmes augmentera les bénéfices de la résolution de n'importe quel autre problème.
De plus, il existe une interaction entre le pipeline de construction de blocs et la finalité unique de créneau, en particulier dans les cas où l'on essaie de réduire le temps de créneau. De nombreux conceptions de pipeline de construction de blocs finissent par augmenter le temps de créneau. De nombreux pipelines de construction de blocs impliquent le rôle de prouveur à plusieurs étapes du processus. Par conséquent, il vaut la peine de considérer simultanément le pipeline de construction de blocs et la finalité unique.
Réparation de l'économie de la mise en jeu
Quel problème devons-nous résoudre ?
Aujourd'hui, environ 30 % de l'offre d'ETH est activement mise en jeu. Cela suffit à protéger Ethereum contre les attaques à 51 %. Si la proportion d'ETH mis en jeu devient plus grande, les chercheurs craignent qu'une situation différente n'émerge : si presque tout l'ETH est mis en jeu, des risques apparaîtront. Ces risques incluent :
Qu'est-ce que c'est et comment ça fonctionne ?
Historiquement, une solution de ce type est : si tout le monde doit inévitablement staker, et que les jetons de staking liquide sont inévitables, alors rendons le staking convivial pour avoir des jetons de staking liquide qui sont en réalité sans confiance, neutres et aussi décentralisés que possible. Une méthode simple consiste à limiter la pénalité de staking à 1/8, ce qui rendra 7/8 de l'ETH staké non réductible, donc éligible pour être placé dans le même jeton de staking liquide. Une autre option est de créer explicitement un staking à deux niveaux : le staking "à risque" (réductible).
Cependant, une critique de cette méthode est qu'elle équivaut économiquement à quelque chose de beaucoup plus simple : si la part de capital approche d'un certain plafond prédéterminé, alors l'émission est considérablement réduite. L'argument de base est le suivant : si nous entrons finalement dans un monde où le taux de rendement de la couche de prise de risque est de 3,4 % et celui de la couche sans risque (où tout le monde participe) est de 2,6 %, cela revient en réalité à un monde où le rendement de l'Éther staké est de 0,8 % et le rendement de la simple détention d'Éther est de 0 %. La dynamique de la couche de prise de risque, y compris le montant total staké et le degré de centralisation, est la même dans les deux cas. Donc, nous devrions faire quelque chose de simple et réduire l'émission.
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 de Anders Elowsson.
D'autre part, le staking à deux niveaux nécessite de définir deux courbes de rendement : (i) le taux de rendement du staking "de base" (sans risque ou à faible risque), et (ii) une prime pour le staking à risque. Il existe plusieurs façons de définir ces paramètres : par exemple, si vous définissez un paramètre fixe, c'est-à-dire que 1/8 des droits de vote est réductible, alors la dynamique du marché déterminera la prime du taux de rendement des droits de vote réductibles.
Un autre thème important ici est la capture de MEV. De nos jours, les revenus de MEV (par exemple, l'arbitrage DEX, les sandwichs...) vont aux proposeurs, c'est-à-dire aux stakers. C'est un revenu complètement "opaque" pour le protocole : le protocole ne peut pas savoir s'il s'agit d'un taux d'intérêt de 0,01 %, de 1 % ou de 20 %. Sous plusieurs angles, l'existence de cette source de revenu est très peu pratique :
Nous pouvons résoudre ces problèmes en trouvant un moyen de rendre les revenus MEV clairement visibles dans le protocole et de les capturer. La première proposition était le MEV smoothing de Francesco ; aujourd'hui, il est généralement admis que tout mécanisme permettant d'enchérir à l'avance sur 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.
Quelles sont les relations avec les recherches existantes ?
Émettre wtf :
Endgame économie de staking, étude de cas :
Attributs de niveau d'émission, Anders Elowsson :
Limite supérieure de la taille des paramètres du validateur :
Réflexions sur l'idée de la multi-staking :
Pledge Arc-en-ciel :
Proposition de staking liquide de Dankrad :
Lissage MEV, auteur : Francesco :
MEV burn, auteur : Justin Drake :
Que faut-il encore faire, quels compromis faut-il envisager ?
La principale tâche restante est soit d'accepter de ne prendre aucune mesure et d'accepter le risque que presque tous les ETH soient dans 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é approximatif des bénéfices et des risques est le suivant :
Comment interagit-il avec les autres parties de la feuille de route ?
Un point de croisement important concerne le staking individuel. Aujourd'hui, le VPS le moins cher capable de faire fonctionner un nœud Ethereum coûte environ 60 dollars par mois, principalement en raison des coûts de stockage sur disque. Pour les stakers de 32 ETH (84 000 dollars au moment de la rédaction), cela réduit l'APY à (60 * 12) / 84000 ~= 0,85 %. Si le taux de retour total du staking est inférieur à 0,85 %, alors pour de nombreuses personnes à ce niveau, le staking individuel devient non viable.
Si nous souhaitons que le staking individuel reste viable, cela souligne davantage la nécessité de réduire les coûts d'exploitation des nœuds, ce qui sera réalisé dans Verge : l'absence d'état éliminera les besoins en espace de stockage, ce qui pourrait suffire en soi, puis la preuve d'efficacité de l'EVM L1 rendra les coûts dérisoires.
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 tout le monde, il est encore plus important de diminuer la variance, rendant le staking moins semblable à une loterie.
Enfin, tout changement dans l’émission interagira avec d'autres changements fondamentaux dans la conception du staking (comme le staking arc-en-ciel). Une question particulièrement préoccupante est que si les récompenses de staking deviennent très faibles, cela signifie que nous devons faire un choix entre : (i) réduire la sévérité des pénalités, diminuant ainsi les incitations à un comportement inapproprié ; (ii) maintenir une sévérité élevée des pénalités, ce qui pourrait entraîner une série de situations où même des validateurs de bonne foi, s'ils rencontrent des problèmes techniques ou même des attaques, pourraient accidentellement subir des pertes.
Solutions de couche d'application
La partie ci-dessus met en avant les changements de l'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 d'importantes stratégies de couche d'application qui peuvent aider à atténuer les risques mentionnés ci-dessus. Quelques exemples incluent :
Un grand merci à Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes et Max Resnick pour leurs retours et leurs révisions, ainsi qu'aux discussions de la communauté ethstakers.