Titre original : « S’en tenir à 8192 signatures par créneau post-SSF : comment et pourquoi »
Article original de Vitalik Buterin, recherche ETH
Compilation originale : Luccy, BlockBeats
*Note de l’éditeur : SSF (Single Slot Finality) est l’abréviation de Single Slot Finality, qui permet de réduire considérablement la latence d’Ethereum. Dans le mécanisme de consensus Blockchain, la finalité signifie qu’une transaction ou un bloc devient irrévocable, garantissant qu’il ne peut pas être altéré ou inversé. L’atteinte de la finalité est essentielle pour la confiance et la sécurité des systèmes de décentralisation, car elle élimine le risque de double dépense et d’autres activités malveillantes. *
*Le SSF suggère que dans le mécanisme de consensus de la blockchain, un seul créneau horaire ou une seule unité de temps peut être considéré comme « définitif ». Contrairement à l’EthereumConsensus original, il permet à tous les validateurs de participer à la reconnaissance ou à la signature des créneaux horaires, ce qui réduit le temps de confirmation des transactions et améliore l’expérience globale de l’utilisateur. *
Vitalik « revient » ETH recherche explore pourquoi il est nécessaire que les validateurs participants aient deux signatures par créneau après SSF, c’est-à-dire pour atteindre 8192 signatures, et avance 3 hypothèses sur la façon d’atteindre cet objectif, à savoir le jalonnement complet, le jalonnement à deux niveaux et la participation rotationnelle, analyse comment gérer plus efficacement le nombre de signatures par emplacement tout en maintenant la sécurité du protocole, et discute de leurs avantages et inconvénients et de l’impact sur le protocole et les utilisateurs. BlockBeats a compilé le texte original comme suit :
Une différence majeure entre Ethereum et la plupart des autres systèmes PoS (avec finalité) est qu’Ethereum s’efforce de prendre en charge un très grand nombre de validateurs : nous avons actuellement 895 000 validateurs, ce qui, selon l’analyse de la loi de Zipf, équivaut à des dizaines de milliers d’individus ou d’entités indépendants. L’objectif est de soutenir la décentralisation, en permettant aux gens ordinaires de participer au staking sans obliger chacun à renoncer à sa capacité d’action et à céder le contrôle à l’un des rares pools de staking.
Cependant, cette approche nécessite que la chaîne Ethereum traite un grand nombre de signatures par emplacement (environ 28 000 aujourd’hui ; 1 790 000 après SSF), ce qui représente une charge très élevée. Afin de supporter cette charge, un certain nombre de sacrifices techniques doivent être faits :
- Cela nécessite un mécanisme complexe de propagation des preuves où les preuves sont réparties sur plusieurs sous-réseaux, des opérations de signature BLS super-optimisées pour vérifier ces signatures, etc.
- Nous n’avons actuellement pas d’alternative claire et efficace à la résistance quantique.
- Les corrections de sélection de duplication comme la fusion de vues sont rendues plus compliquées par l’impossibilité d’extraire des signatures individuelles.
- Le traitement SNARK est difficile pour un si grand nombre de signatures. Helios doit fonctionner sur une signature supplémentaire spécialisée, appelée signature de comité synchrone.
- Il nécessite trois sous-emplacements dans un emplacement au lieu de deux, ce qui augmente le temps de créneau minimum de sécurité.
Un système d’agrégation de signatures peut sembler raisonnable à première vue, mais en réalité, il crée une complexité systémique qui imprègne l’ensemble du système.
De plus, il n’a même pas atteint ses objectifs. L’exigence minimale pour le staking est toujours de 32 ETH, ce qui est hors de portée pour beaucoup de gens. Du seul point de vue de l’analyse logique, l’objectif d’un système qui permet à tout le monde de signer chaque slot sur le long terme ne semble pas réalisable pour vraiment fournir du staking aux gens ordinaires : si Ethereum compte 500 millions d’utilisateurs, dont 10% participent au staking, cela signifie 100 millions de signatures par slot. Du point de vue de la théorie de l’information, le traitement des pénalités dans cette conception nécessite au moins 12,5 Mo d’espace libre de données par emplacement, ce qui équivaut à peu près à l’objectif d’un partitionnement complet. C’est peut-être possible, mais le fait d’exiger que le jalonnement lui-même s’appuie sur l’échantillonnage de la disponibilité des données représente un gain de complexité important. Et même dans ce cas, seulement environ 0,6 % de la population mondiale participe au jalonnement, et cela n’a pas encore commencé à impliquer le problème informatique de la vérification d’autant de signatures.
Ainsi, au lieu de s’appuyer sur la cryptographie pour créer des balles magiques (ou des balles magiques) afin d’obtenir un nombre toujours croissant de signatures par emplacement, je suggère un changement philosophique : abandonnez d’abord de telles attentes. Cela élargirait considérablement l’espace de conception PoS et permettrait une grande simplification technique, le rendrait plus sûr en permettant à Helios de SNARK directement sur le consensus Ethereum, et résoudrait le problème de la résistance quantique en rendant possible même un schéma de signature inintéressant mais de longue date comme Winternitz.
Pourquoi ne pas « Utiliser uniquement les comités » ?
De nombreux non-EthereumBlockchain confrontés à ce problème précis adoptent une approche de la sécurité basée sur des comités. Au cours de chaque créneau, ils sélectionnent au hasard N validateurs (par exemple, N ≈ 1000) qui sont chargés de confirmer le créneau. Il convient de rappeler pourquoi cette approche n’est pas suffisante, car elle n’assure pas la reddition de comptes.
Pour comprendre pourquoi, disons que 51 % des attaques ont eu lieu. Il peut s’agir d’une attaque d’inversion terminale ou d’une attaque de censure. Pour mener à bien l’attaque, il faut encore que l’acteur économique contrôle la majorité de la participation pour se mettre d’accord sur l’attaque, c’est-à-dire faire tourner le logiciel impliqué dans l’attaque et participer à l’attaque avec tous les validateurs qui sont finalement élus au comité. C’est ce que garantit l’échantillonnage mathématiquement aléatoire. Cependant, les pénalités qu’ils ont reçues pour cela ont été minimes, car la plupart des validateurs qui ont accepté l’attaque n’ont finalement pas été élus au comité et n’ont donc pas été vus.
Actuellement, Ethereum fait exactement le contraire. Si une attaque à 51 % se produit, la majorité de l’ensemble de la collection de validateurs d’attaque verra son dépôt réduit. Le coût actuel de l’attaque est d’environ 9 millions de ETH (environ 20 milliards de dollars), et il est supposé que la panne de synchronisation du réseau est effectuée de la manière la plus favorable pour l’attaquant.
Je pense que c’est un coût élevé, mais c’est un prix trop élevé à payer, et nous pouvons faire des sacrifices sur cette question. Même un coût d’attaque de 1 à 2 millions de ETH est parfaitement suffisant. De plus, le principal risque de centralisation qui existe actuellement dans Ethereum se reflète dans un endroit complètement différent : si le montant minimum de dépôt est ramené à près de zéro, la puissance des pools de jalonnement à grande échelle ne sera pas beaucoup diminuée.
C’est pourquoi je préconise une solution intermédiaire : faites quelques sacrifices sur les responsabilités des validateurs tout en maintenant un montant ETH total découpable élevé, et en échange, nous pouvons profiter de la plupart des avantages d’un ensemble plus restreint de validateurs.
Que se passe-t-il s’il y a 8192 signatures par emplacement sous SSF ?
En supposant un protocole de consensus traditionnel à deux tours (comme le protocole utilisé par Tendermint et le protocole que SSF utilise inévitablement), chaque validateur participant a besoin de deux signatures par emplacement. Nous devons nous attaquer à cette réalité, et je vois qu’il y a trois façons principales de résoudre ce problème.
Méthode 1 : Adopter pleinement les pools de jalonnement de décentralisation
Le Python Zen contient une phrase très cruciale :
Il devrait y avoir une - et de préférence une seule - façon évidente de le faire. ）
Ethereum enfreint actuellement cette règle lorsqu’il s’agit de rendre le jalonnement égal, car nous mettons simultanément en œuvre deux stratégies différentes pour atteindre cet objectif : (i) le jalonnement indépendant à petite échelle et (ii) les pools de jalonnement de décentralisation utilisant la technologie de validation distribuée (DVT). Pour les raisons ci-dessus, (i) seuls quelques stakers individuels peuvent être pris en charge, et il y aura toujours beaucoup de personnes dont le montant minimum de dépôt est trop élevé. Cependant, Ethereum paie un coût de charge technique très élevé pour le support (i).
Une solution possible est d’abandonner (i) et d’y aller à fond (ii). Nous pouvons augmenter le montant minimum du dépôt à 4096 ETH et fixer le plafond total du validateur à 4096 (environ 16,7 millions de ETH). On s’attend à ce que les petits jalonneurs rejoignent le pool DVT : en fournissant des capitaux ou en devenant des opérateurs de nœuds. Pour éviter les abus de la part des attaquants, le rôle d’opérateur de nœud doit être limité par le seuil de prestige d’une manière ou d’une autre, et les pools seront en concurrence en offrant différentes options à cet égard. La mise à disposition de capitaux se fera sans autorisation.
Nous pouvons rendre le staking dans ce modèle plus « indulgent » en fixant un plafond de pénalité (par exemple, 1/8 du dépôt total fourni). Cela permettra de faire moins confiance aux opérateurs de nœuds, bien que cela vaille la peine d’être traité avec prudence en raison des problèmes décrits.
Méthode 2 : Deux couches de jalonnement
Nous avons créé deux couches de stakers : une couche « lourde » qui nécessite 4096 ETH pour participer à la confirmation finale de l’état, et une couche « légère » sans exigences minimales (pas de délais de dépôt et de retrait, pas de vulnérabilités réduites), ajoutant une deuxième couche de sécurité. Pour qu’un bloc soit confirmé, il faut à la fois une confirmation de l’état final de la couche lourde et au moins 50 % de la couche légère des preuves de validation de la lumière en ligne.
Cette hétérogénéité est bénéfique pour la censure et la résistance aux attaques, car les couches lourdes et légères doivent être corrompues pour qu’une attaque réussisse. Si une couche est corrompue et que l’autre ne l’est pas, la chaîne s’arrêtera, et si la couche lourde est corrompue, elle peut être punie.
Un autre avantage est que le niveau léger peut contenir des ETH qui sont également utilisés comme support dans l’application. Le principal inconvénient est que le jalonnement devient moins égalitaire en établissant un fossé entre les jalonneurs à petite échelle et les jalonneurs à grande échelle.
Méthode 3 : Participation par rotation (c.-à-d. comité, mais responsabilisation)
Nous adoptons une approche similaire à la conception du super-comité proposée ici : pour chaque emplacement, nous sélectionnons 4096 validateurs actuellement actifs et ajustons soigneusement l’ensemble dans chaque emplacement afin d’avoir toujours la sécurité.
Cependant, nous avons fait des choix de paramètres différents dans ce cadre afin d’obtenir un « rapport qualité-prix ». En particulier, nous permettons aux validateurs de participer avec des soldes arbitrairement élevés, et si les validateurs ont plus d’un certain nombre de ETH (qui devrait être flottant), ils participent à des comités dans chaque créneau. Si un validateur a N<M ETH, alors il a une probabilité de N/M dans n’importe quel créneau donné pour participer au comité.
Nous avons ici un levier intéressant pour découpler le « poids » sur l’objectif d’incitation du « poids » sur l’objectif de consensus : la récompense pour chaque validateur dans le comité devrait être la même (au moins pour les validateurs utilisant ≤M ETH) pour garder la récompense moyenne proportionnelle à l’équilibre, mais nous pouvons toujours calculer les poids des validateurs de consensus dans le comité en pondérant ETH. Cela permet de s’assurer que la quantité de ETH nécessaire pour briser le caractère définitif est égale à plus d’un tiers du total des ETH au sein du comité.
Une analyse approximative de la loi de Zipf calcule cette quantité de ETH comme suit :
- À chaque niveau quadratique de l’équilibre total, le nombre de validateurs est inversement proportionnel à ce niveau d’équilibre, et le solde total de ces validateurs sera le même.
- En conséquence, le comité aura un nombre égal de ETH de chaque niveau de solde participant, à l’exception de ceux qui dépassent la barrière M, où les validateurs sont toujours sur le comité.
Remarque : Afin d’afficher les données calculées plus clairement, les étapes suivantes seront des captures d’écran
Le principal inconvénient de cette approche est une légère augmentation de la complexité de la sélection aléatoire des validateurs dans le protocole afin que nous puissions obtenir une sécurité consensuelle en cas de changement de comité.
Le principal avantage est qu’il conserve le staking indépendant sous une forme reconnaissable, maintient un système à classe unique et permet même de faire baisser le montant minimum du dépôt à un niveau très bas (par exemple 1 ETH).
En conclusion
Si nous décidons de nous en tenir à 8192 signatures après le protocole SSF, cela facilitera grandement le travail des implémenteurs technologiques et des constructeurs d’infrastructures secondaires telles que les clients légers. Les clients de consensus peuvent être gérés plus facilement par n’importe qui, et les utilisateurs, les amateurs de jalonnement et d’autres peuvent immédiatement travailler sur cette hypothèse. La charge future du protocole Ethereum n’est plus inconnue : l’avenir peut être boosté par un hard fork, mais seulement si les développeurs sont convaincus que la technologie s’est suffisamment améliorée pour gérer plus de signatures par slot au même niveau de facilité.
Le reste du travail consistera à décider laquelle des trois méthodes nous voulons adopter, ou peut-être une approche complètement différente. Il s’agira de savoir avec quels compromis nous sommes à l’aise, en particulier comment nous gérons les problèmes connexes tels que le jalonnement liquide, qui peuvent être résolus séparément des problèmes techniques qui sont maintenant beaucoup plus faciles.
Lien vers l’article original
