Cela facilitera la vie des développeurs de technologies, ainsi que des constructeurs d’infrastructures de support telles que les clients légers.
Écrit par : Vitalik Buterin, ethresearch
Compilé par : Songxue, Golden Finance
La principale différence entre Ethereum et la plupart des autres systèmes de preuve de participation (finalité) est qu’Ethereum tente de prendre en charge un très grand nombre d’objets validateurs : nous avons actuellement 895 000 objets validateurs, et une simple analyse de la loi de Zipf montre que cela correspond à des dizaines de des milliers d’objets validateurs sont des individus/entités uniques. Le but est de soutenir la décentralisation et même de permettre aux individus ordinaires de participer au jalonnement sans exiger que chacun abandonne son agence et donne le contrôle à l’un des rares pools de jalonnement.
Cependant, cette approche nécessite que la chaîne Ethereum traite un grand nombre de signatures par slot (environ 28 000 aujourd’hui ; 1 790 000 après SSF), ce qui représente une charge très élevée. Supporter cette charge nécessite des sacrifices techniques importants :
- Cela nécessite un mécanisme complexe de propagation de la preuve impliquant la répartition de la preuve sur plusieurs sous-réseaux, nécessitant une hyper-optimisation des opérations de signature BLS pour vérifier ces signatures, etc.
- Nous n’avons pas d’alternative claire suffisamment efficace pour être résistante aux quantiques.
- Les correctifs de sélection par fourchette, comme la fusion de vues, deviennent plus complexes car les signatures individuelles ne peuvent pas être extraites.
- L’enregistrement des signatures SNARK est difficile en raison de leur grand nombre. Helios a besoin de fonctionner sur une signature supplémentaire dédiée, appelée signature du comité de synchronisation.
- Il augmente le créneau horaire minimum de sécurité en exigeant trois sous-créneaux horaires dans un créneau horaire au lieu de deux.
Le 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 tous les aspects.
De plus, il ne remplit même pas son objectif. L’exigence minimale de mise est toujours de 32 ETH, ce qui est hors de portée pour beaucoup. D’après une simple analyse logique, à long terme, il semble impossible qu’un système dans lequel tout le monde se connecte puisse véritablement fournir du staking aux gens ordinaires : si Ethereum compte 500 millions d’utilisateurs et que 10 % d’entre eux s’engagent, alors cela signifie qu’il y en a 100 millions. signatures par emplacement. En termes de théorie de l’information, les réductions de traitement dans cette conception nécessitent au moins 12,5 Mo d’espace libre de données par emplacement, soit à peu près autant que l’objectif d’un daksharding complet (!!!). C’est peut-être faisable, mais exiger que le jalonnement lui-même s’appuie sur l’échantillonnage de la disponibilité des données entraînerait un gain de complexité important - même si cela ne représente qu’environ 0,6 % de la population mondiale, et cela ne commence même pas à entrer dans les problèmes informatiques de vérification. tant de signatures.
Ainsi, au lieu de compter sur les cryptographes pour créer une solution miracle (ou un gilet pare-balles magique) permettant d’avoir un nombre toujours croissant de signatures dans chaque plage horaire, je suggère que nous fassions un changement philosophique : abandonnons de telles attentes dans le première place . Cela élargirait considérablement l’espace de conception du PoS et permettrait une grande simplification technique, le rendant plus sécurisé en permettant à Helios de SNARK directement sur le consensus Ethereum, et en créant même des schémas de signature ennuyeux de longue date comme Winternitz. résoudre le problème de la résistance quantique.
Pourquoi ne pas « simplement utiliser le comité » ?
De nombreuses blockchains non Ethereum confrontées à ce problème précis utilisent une approche de sécurité basée sur un comité. Dans chaque créneau horaire, ils sélectionnent au hasard N validateurs (par exemple, N est approximativement égal à 1000), et ces validateurs sont chargés de compléter ce créneau horaire. Il convient de rappeler pourquoi cette approche échoue : elle manque de responsabilité.
Pour comprendre pourquoi, imaginez une attaque à 51 %. Il pourrait s’agir d’une ultime attaque de revirement ou d’une attaque de censure. Pour lancer une attaque, l’acteur économique qui contrôle la majorité des parts doit encore accepter de mener l’attaque, c’est-à-dire d’exécuter le logiciel qui participe à l’attaque, ainsi que tous les validateurs qui sont finalement élus au comité. Les mathématiques de l’échantillonnage aléatoire le garantissent. Cependant, la sanction qu’ils encourent pour une telle attaque est faible car la plupart des validateurs qui acceptent l’attaque finissent par ne pas être vus parce qu’ils n’ont pas été élus au comité.
Actuellement, Ethereum prend l’extrême opposé. En cas d’attaque à 51 %, la majorité de l’ensemble des validateurs attaquants verront leur mise réduite. 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 à maximiser les bénéfices de l’attaquant.
Je pense que c’est un coût élevé, et c’est un coût trop élevé, et nous pouvons faire des sacrifices sur cette question. Même si le coût de l’attaque est de 1 à 2 millions d’ETH, c’est tout à fait suffisant. De plus, le principal risque de centralisation qui existe actuellement pour Ethereum réside dans un tout autre endroit : si le montant minimum de mise est réduit à près de zéro, la différence de force entre les pools de mise à grande échelle ne sera pas grande.
C’est pourquoi je préconise une solution modeste : faire quelques sacrifices dans la responsabilité du validateur, tout en gardant le montant total d’ETH réductible assez élevé, et en échange, cela nous donne un ensemble de validateurs plus petit pour la plupart des avantages.
À quoi ressembleraient 8 192 signatures par plage horaire sous SSF ?
En supposant un protocole de consensus traditionnel en deux tours (similaire à celui utilisé par Tendermint, et inévitablement utilisé par SSF), chaque validateur participant nécessite deux signatures par créneau horaire. Nous devons contourner cette réalité. Je vois trois manières principales d’y parvenir.
Méthode 1 : Allez à fond sur le pool de promesses de dons décentralisé
Python a un dicton très crucial :
Il devrait y avoir une manière évidente, de préférence une seule, d’y parvenir.
Concernant la question de l’égalisation des mises, Ethereum viole actuellement cette règle car nous mettons simultanément en œuvre deux stratégies différentes pour atteindre cet objectif : (i) le jalonnement individuel à petite échelle, et (ii) l’utilisation d’un pool de jalonnement décentralisé de la technologie de validation distribuée (DVT). Pour les raisons ci-dessus, (i) seul un sous-ensemble de parieurs individuels peut être pris en charge ; il y aura toujours de nombreuses personnes dont le dépôt minimum est trop important. Cependant, Ethereum paie un coût technique très élevé pour prendre en charge (i).
Une solution possible est d’abandonner (i) et de se lancer à fond dans (ii). Nous pouvons augmenter le montant minimum de mise à 4 096 ETH et fixer un plafond total de 4 096 validateurs (environ 16,7 millions d’ETH). Les petits acteurs devraient rejoindre le pool DVT : soit en fournissant des fonds, soit en devenant 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é d’une manière ou d’une autre par sa réputation, et les pools se feront concurrence en offrant différentes options à cet égard. Le financement se fera sans autorisation.
On peut rendre le pari collectif dans ce modèle plus « indulgent » en limitant les pénalités, par exemple. à 1/8 de la contribution totale fournie. Cela réduira la confiance dans les opérateurs de nœuds, même si cela mérite d’être abordé avec prudence en raison des problèmes décrits ici.
Méthode 2 : Engagement à deux niveaux
Nous créons deux niveaux de jalonnement : un niveau “lourd”, nécessitant 4096 ETH, pour participer à la finalisation, et un niveau “léger”, qui n’a pas d’exigences de mise minimale (pas de délais de dépôt et de retrait, et aucun risque de slashing). ce qui ajoute une autre couche de sécurité. Pour qu’un bloc soit définitif, la couche lourde doit le finaliser et la couche légère a besoin de >= 50 % de validateurs légers en ligne pour l’attester.
Cette hétérogénéité est bénéfique pour la résistance à 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 une autre non, la chaîne s’arrêtera ; si une couche importante est corrompue, elle peut être punie.
Un autre avantage de cette approche est que la couche légère peut inclure de l’ETH qui est également utilisé comme garantie dans l’application. Le principal inconvénient est que cela rend les mises moins égales en établissant une division entre les petits et les grands parieurs.
Méthode 3 : Participer à tour de rôle (c’est-à-dire en comité mais responsable)
L’approche que nous adoptons est similaire à la conception du super comité proposée ici : pour chaque créneau horaire, nous sélectionnons 4 096 validateurs actuellement actifs, et nous ajustons soigneusement cet ensemble pendant chaque créneau horaire pour garantir notre sécurité.
Cependant, nous avons effectué différents choix de paramètres afin d’obtenir le « bénéfice maximum » dans ce cadre. En particulier, nous permettons aux validateurs de participer avec des soldes arbitrairement élevés, et si un validateur possède plus d’un certain montant M d’ETH (qui doit être flottant), alors il participe au comité à chaque époque. Si le vérificateur a N <M ETH，那么他们有 N/M 在任何给定时间段内进入委员会的概率。
Un levier intéressant dont nous disposons ici est de découpler le « poids » à des fins d’incitation du « poids » à des fins de consensus : la récompense pour chaque validateur au sein du comité devrait être la même (au moins pour les validateurs avec ≤M ETH), pour garder la récompense moyenne proportionnelle. Nous pouvons toujours effectuer un décompte consensuel des validateurs du comité en utilisant l’ETH comme poids. Cela garantit que la rupture du caractère définitif nécessite un montant d’ETH égal à plus d’un tiers du montant total d’ETH du comité.
L’analyse de la loi de Zipf calculera le montant d’ETH comme suit :
À chaque niveau quadratique du solde total, le nombre de validateurs est inversement proportionnel à ce niveau de solde, et le solde total de ces validateurs sera le même.
Par conséquent, le comité aura une quantité égale d’ETH participant à chaque niveau de solde, à l’exception des niveaux supérieurs à la barrière M (les validateurs font toujours partie du comité).
Par conséquent, nous avons le niveau Log2(M) pour chaque K validateurs au niveau ci-dessus, et K+K/2+…=2K validateurs de niveau supérieur. Par conséquent, K=4096/Log2(M)+2.
Le plus grand validateur aura M*k ETH. Nous pouvons travailler à rebours : si le plus grand validateur a 2^18=262144 ETH, cela signifie (en gros) M = 1024 et k = 256.
Le montant total de l’ETH promis est de :
Tous les droits et intérêts des 512 principaux validateurs (2^18*1+2^17*2+……+2^10*2^8=2359296)
Plus des paris plus petits issus d’un échantillonnage aléatoire (2^8*(2^9+2^8+2^7…) est approximativement égal à 2^8*2^10=2^18)
Nous avons gagné un total de 2621440 ETH, soit le coût de l’attaque était d’environ 900 000 ETH.
Le principal inconvénient de cette approche est qu’elle introduit un peu plus de complexité dans le protocole pour sélectionner au hasard les validateurs d’une manière qui nous permet de toujours garantir la sécurité du consensus lorsque le comité change.
Son principal avantage est qu’il conserve une forme reconnaissable de staking indépendant, conserve un système unique et permet même de réduire le montant minimum de la mise à des niveaux très bas (par exemple 1 ETH).
Résumer
Si nous déterminons que derrière le protocole SSF, nous voulons nous en tenir à 8 192 signatures, ce qui facilitera la vie des responsables de la mise en œuvre technique, ainsi que des constructeurs d’infrastructures de support telles que les clients légers. Il devient plus facile pour quiconque d’exécuter un client de consensus, et les utilisateurs, les passionnés de jalonnement et autres peuvent immédiatement travailler sur cette hypothèse. La charge future du protocole Ethereum n’est plus inconnue : elle pourrait être améliorée à l’avenir via des hard forks, mais seulement si les développeurs sont convaincus que la technologie s’est suffisamment améliorée pour pouvoir gérer plus de signatures par créneau horaire avec la même facilité.
Le reste consistera à décider laquelle des trois approches ci-dessus nous souhaitons 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 résoudre les problèmes impliqués, comme le jalonnement de liquidité, qui peuvent probablement être résolus séparément des problèmes techniques qui deviennent désormais plus faciles.
