La proposition simplifiée de PoS par Vitalik : maintenir 8192 signatures par slot après SSF
TechFlow SélectionTechFlow Sélection
La proposition simplifiée de PoS par Vitalik : maintenir 8192 signatures par slot après SSF
Cela rendra le travail des techniciens implémentateurs ainsi que celui des développeurs d'infrastructures auxiliaires telles que les clients légers plus facile.
Dédié à des analyses Web3 approfondiesRédaction : Vitalik Buterin, ethresearch
Traduction : Song Xue, Jinse Finance
La principale différence entre Ethereum et la plupart des autres systèmes de preuve d'enjeu (PoS) à finalité déterministe réside dans le fait qu'Ethereum cherche à supporter un très grand nombre d'objets validateurs : nous avons actuellement 895 000 objets validateurs, et une simple analyse selon la loi de Zipf suggère que cela correspond à plusieurs dizaines de milliers de validateurs étant des individus ou entités distincts. L’objectif est de promouvoir la décentralisation, en permettant même aux particuliers ordinaires de participer au staking, sans obliger chacun à renoncer à son autonomie ni à transférer son contrôle à l’un des rares pools de staking.
Toutefois, cette approche exige qu’Ethereum traite un très grand nombre de signatures par slot — environ 28 000 aujourd’hui, et 1 790 000 après SSF — ce qui représente une charge extrêmement élevée. Supporter cette charge nécessite de nombreux compromis techniques :
-
Cela requiert un mécanisme complexe de diffusion des attestations, impliquant leur répartition sur plusieurs sous-réseaux, ainsi qu’une optimisation poussée des opérations de signature BLS pour vérifier efficacement ces signatures, etc.
-
Nous ne disposons pas d'une alternative claire, suffisamment efficace et résistante aux ordinateurs quantiques.
-
Les correctifs de choix de fourchette basés sur des mécanismes tels que la fusion de vues deviennent plus complexes, car il n’est pas possible d’extraire des signatures individuelles.
-
Il est difficile de générer des SNARKs sur les signatures en raison de leur grand nombre. Helios doit opérer sur une signature supplémentaire spécialisée appelée « signature du comité de synchronisation ».
-
Cela augmente la durée minimale sécurisée du slot en imposant trois sous-slots au lieu de deux.
Le système d’agrégation de signatures semble raisonnable en apparence, mais crée en réalité une complexité systémique qui pénètre tous les aspects du protocole.
Pire encore, il ne parvient même pas à atteindre son objectif. Le seuil minimal de staking reste fixé à 32 ETH, ce qui reste inaccessible pour beaucoup. Et simplement sur le plan logique, il semble irréaliste, à long terme, que tout le monde puisse signer personnellement : si Ethereum avait 500 millions d’utilisateurs, dont 10 % faisaient du staking, cela représenterait 100 millions de signatures par slot. D’un point de vue théorique de l’information, traiter les slashes dans cette conception nécessiterait au moins 12,5 Mo d’espace de disponibilité de données par slot, soit à peu près autant que l’objectif complet du daksharding (!!!). Cela pourrait être faisable, mais exiger que le staking lui-même repose sur l’échantillonnage de disponibilité des données ajoute une grande complexité — et ce, même si seulement 0,6 % de la population mondiale participe au staking, sans même aborder les problèmes computationnels liés à la vérification d’autant de signatures.
Par conséquent, plutôt que de compter sur les cryptographes pour inventer une balle magique (ou une armure pare-balles magique) rendant viable le nombre croissant de signatures par slot, je propose un changement de philosophie : abandonner dès le départ cette attente. Cela élargirait considérablement l’espace de conception du PoS et permettrait de nombreuses simplifications techniques, rendrait Helios plus sûr en autorisant des SNARKs directement sur la couche consensus d’Ethereum, et résoudrait le problème de la résistance quantique en rendant viables même des schémas de signature anciens et simples comme Winternitz.
Pourquoi ne pas simplement utiliser un « comité » ?
Beaucoup de blockchains non-Ethereum confrontées à ce problème utilisent une méthode de sécurité fondée sur des comités. À chaque slot, elles sélectionnent aléatoirement N validateurs (par exemple N ≈ 1000), chargés de finaliser ce slot. Il convient de rappeler pourquoi cette approche n’est pas suffisante : elle manque de responsabilité.
Pour comprendre pourquoi, supposons qu’une attaque à 51 % se produise — inversion de finalité ou censure. Pour mener l’attaque, il faut toujours que la majorité économique des participants au staking accepte de coopérer, c’est-à-dire exécute un logiciel malveillant et coordonne les membres du comité sélectionnés. Les mathématiques de l’échantillonnage aléatoire garantissent bien cela. Toutefois, la punition encourue par ces participants reste faible, car la plupart des validateurs complices ne sont jamais sélectionnés dans un comité et donc ne sont jamais détectés.
Actuellement, Ethereum adopte l’extrême opposé. En cas d’attaque à 51 %, une grande partie de l’ensemble des validateurs attaquants serait soumise à slashing. Le coût actuel de l’attaque est d’environ 9 millions d’ETH (environ 20 milliards de dollars), et cela suppose que la synchronisation du réseau soit perturbée de manière maximale en faveur de l’attaquant.
Je pense que ce coût est excessivement élevé, et qu’on peut consentir quelques compromis ici. Un coût d’attaque de 1 à 2 millions d’ETH serait largement suffisant. De plus, le principal risque centralisateur actuel d’Ethereum réside ailleurs : si le montant minimum de staking était abaissé vers zéro, la puissance relative des grands pools de staking ne serait pas si importante.
C’est pourquoi je préconise une solution modérée : consentir un léger compromis sur la responsabilité des validateurs, tout en maintenant une quantité totale d’ETH slashable assez élevée. En échange, nous bénéficierions de la plupart des avantages d’un ensemble de validateurs plus petit.
À quoi ressembleraient 8192 signatures par slot sous SSF ?
En supposant un protocole de consensus classique à deux tours (similaire à Tendermint, et inévitablement utilisé par SSF), chaque validateur participant doit produire deux signatures par slot. Nous devons contourner cette contrainte. Je vois trois grandes approches possibles.
Approche 1 : miser pleinement sur les pools de staking décentralisés
Python a une phrase très célèbre :
Il devrait y avoir une — et de préférence une seule — façon évidente de faire les choses.
Sur la question de l’égalisation du staking, Ethereum viole actuellement cette règle, car nous appliquons simultanément deux stratégies différentes : (i) le staking individuel à petite échelle, et (ii) les pools de staking décentralisés utilisant la technologie DVT (Distributed Validator Technology). Pour les raisons évoquées ci-dessus, (i) ne peut soutenir qu’une fraction des petits stakeurs ; beaucoup trouveront toujours le dépôt minimal trop élevé. Pourtant, Ethereum supporte un fardeau technique très lourd pour maintenir (i).
Une solution possible serait d’abandonner (i) et de se concentrer entièrement sur (ii). Nous pourrions augmenter le montant minimal de staking à 4096 ETH, et fixer une limite totale de 4096 validateurs (soit environ 16,7 millions d’ETH). Les petits stakeurs rejoindraient alors des pools DVT : soit en fournissant des fonds, soit en devenant opérateurs de nœuds. Pour éviter les abus par des attaquants, le rôle d’opérateur de nœud devrait être limité par une forme de réputation, et les pools se différencieraient en proposant divers modèles. La contribution financière resterait permise sans permission.
Nous pourrions rendre le staking groupé plus « indulgent » dans ce modèle, par exemple en limitant les pénalités à 1/8 du total misé. Cela réduirait la confiance exigée envers les opérateurs de nœuds, bien qu’il faille rester prudent face aux problèmes mentionnés ici.
Approche 2 : staking en deux niveaux
Nous créons deux couches de validateurs : une couche « lourde », exigeant 4096 ETH, responsable de la finalisation, et une couche « légère », sans exigence minimale de mise (ni délai de dépôt/retrait, ni risque de slashing), qui apporte une sécurité supplémentaire. Pour qu’un bloc soit finalisé, il faut à la fois que la couche lourde le finalise et qu’au moins 50 % des validateurs légers en ligne l’attestent.
Cette hétérogénéité est bénéfique contre la censure et les attaques, car réussir une attaque nécessite de corrompre simultanément les deux couches. Si une seule couche est compromise, la chaîne s’arrête ; si c’est la couche lourde, elle peut être punie.
Un autre avantage est que la couche légère pourrait inclure des ETH utilisés également comme collatéraux dans des applications. Le principal inconvénient est qu’elle creuse la distinction entre petits et grands stakeurs, rendant le staking moins équitable.
Approche 3 : participation tournante (comité mais responsable)
Nous adoptons une approche similaire au design de super-comité proposé ici : pour chaque slot, nous sélectionnons 4096 validateurs parmi les actifs, en ajustant soigneusement cet ensemble durant chaque slot afin de conserver la sécurité.
Toutefois, nous faisons des choix de paramètres différents pour tirer le meilleur parti de ce cadre. En particulier, nous permettons aux validateurs de participer avec un solde arbitrairement élevé. Si un validateur possède plus de M ETH (M devant être dynamique), il participe au comité à chaque période. S’il a N < M ETH, sa probabilité d’entrer dans le comité pendant une période donnée est de N/M.
Ici, nous avons un levier intéressant : découpler le « poids » à des fins incitatives du « poids » à des fins de consensus. La récompense de chaque validateur dans le comité devrait être identique (au moins pour les validateurs ayant ≤ M ETH), afin de garder la récompense moyenne proportionnelle. Toutefois, pour le consensus, le poids des validateurs dans le comité reste fonction de leurs ETH. Cela garantit qu’il faille plus d’un tiers des ETH présents dans le comité pour briser la finalité.
L’analyse selon la loi de Zipf donne le calcul suivant pour la quantité d’ETH :
À chaque niveau quadratique du solde total, le nombre de validateurs est inversement proportionnel à ce niveau, et le solde total de ces validateurs reste constant.
Ainsi, le comité contiendra une quantité égale d’ETH provenant de chaque niveau de solde, sauf pour les niveaux supérieurs au seuil M (validateurs toujours présents).
Nous aurons donc, pour K validateurs dans chaque niveau ci-dessus, Log₂(M) niveaux, et K + K/2 + … = 2K validateurs au-dessus de ces niveaux. Ainsi, K = 4096 / (Log₂(M) + 2).
Le plus gros validateur aura M×k ETH. Nous pouvons remonter : si le plus gros a 2¹⁸ = 262 144 ETH, alors (approximativement) M = 1024 et k = 256.
Le total des ETH misés est :
Toutes les parts des 512 premiers validateurs (2¹⁸×1 + 2¹⁷×2 + … + 2¹⁰×2⁸ = 2 359 296)
Plus l’échantillonnage aléatoire des petites mises (2⁸ × (2⁹ + 2⁸ + 2⁷ + …) ≈ 2⁸ × 2¹⁰ = 2¹⁸)
Nous obtenons au total 2 621 440 ETH, soit un coût d’attaque d’environ 900 000 ETH.
Le principal inconvénient de cette approche est d’introduire une complexité supplémentaire dans le protocole, pour sélectionner aléatoirement les validateurs d’une manière qui préserve la sécurité de consensus lors des changements de comité.
Son avantage principal est de préserver une forme reconnaissable de staking indépendant, de maintenir un système unique, et même de permettre d’abaisser le seuil de staking à un niveau très bas (par exemple 1 ETH).
Conclusion
Si nous décidons fermement, après le protocole SSF, de maintenir 8192 signatures par slot, cela facilitera considérablement le travail des développeurs de clients consensus, ainsi que celui des concepteurs d’infrastructures secondaires telles que les clients légers. Il deviendra plus facile pour quiconque de lancer un client de consensus, et les utilisateurs, passionnés de staking et autres pourront immédiatement travailler sous cette hypothèse. La charge future du protocole Ethereum ne sera plus une inconnue : elle pourrait être augmentée par hard fork à l’avenir, mais uniquement si les développeurs sont certains que la technologie a suffisamment progressé pour gérer plus de signatures par slot avec la même facilité.
Il restera à choisir parmi les trois méthodes décrites ci-dessus, ou peut-être une approche totalement différente. Ce sera une question de compromis : déterminer lesquels nous sommes prêts à accepter, notamment sur des sujets comme le liquid staking, qui pourrait désormais être abordé séparément, désormais que les obstacles techniques sont plus faciles à résoudre.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@VitalikButerin
