À l'origine, « la Fusion » désignait l'événement le plus important de l'histoire du protocole Ethereum depuis son lancement : la transition tant attendue et durement gagnée du proof of work au proof of stake. Aujourd'hui, Ethereum fonctionne de manière stable en proof of stake depuis presque exactement deux ans, et ce proof of stake a été remarquablement performant dans stabilité, performance et éviter les risques de centralisation. Cependant, il reste encore quelques domaines importants dans lesquels la preuve d'enjeu doit s'améliorer.

Mon schéma directeur de 2023 a séparé cela en compartiments : amélioration des caractéristiques techniques telles que la stabilité, les performances et l'accessibilité aux petits validateurs, et modifications économiques pour faire face aux risques de centralisation. Le premier a pris la tête de "la Fusion", et le dernier est devenu une partie de "le Fléau".

La fusion, édition de la feuille de route 2023.

Ce post se concentrera sur la partie "Fusion" : qu'est-ce qui peut encore être amélioré dans la conception technique de la preuve d'enjeu, et quels sont quelques chemins pour y parvenir ?

Il ne s'agit pas d'une liste exhaustive des choses qui pourraient être faites pour la preuve d'enjeu ; plutôt, c'est une liste d'idées qui sont activement envisagées.

La fusion : objectifs clés

• Finalité d'un seul créneau
• Confirmation et finalisation de la transaction aussi rapidement que possible, tout en préservant la décentralisation
• Améliorer la viabilité du jalonnement pour les jalonneurs solitaires
• Améliorer la robustesse
• Améliorer la capacité d'Ethereum à résister et à se remettre des attaques de 51 % (y compris la réversion de la finalité, le blocage de la finalité et la censure)

Dans ce chapitre

• Finalité d'un seul slot et démocratisation du jalonnement
• Élection d'un seul leader secret
• Confirmations de transactions plus rapides
• Autres domaines de recherche

Finalité d'une seule fente et démocratisation du jalonnement

Quel problème résolvons-nous ?

Aujourd'hui, il faut 2 à 3 époques (~15 min) pour finaliser un bloc, et 32 ETH sont nécessaires pour être un validateur. Il s'agissait à l'origine d'un compromis destiné à @VitalikButerin/paramétriser-casper-le-compromis-décentralisation-temps-finalité-surcharge-3f2011672735">équilibre entre trois objectifs:

• Maximiser le nombre de validateurs pouvant participer au jalonnement (ce qui implique directement de minimiser le montant minimum d'ETH requis pour le jalonnement)
• Minimiser le temps de finalité
• Minimiser les frais généraux liés à l'exécution d'un nœud, dans ce cas le coût du téléchargement, de la vérification et de la retransmission de toutes les signatures des autres validateurs

Les trois objectifs sont en conflit : pour que la finalité économique soit possible (ce qui signifie qu'un attaquant devrait brûler une grande quantité d'ETH pour revenir en arrière sur un bloc finalisé), vous avez besoin que chaque validateur signe deux messages à chaque fois que la finalité se produit. Donc, si vous avez de nombreux validateurs, soit vous avez besoin de beaucoup de temps pour traiter toutes leurs signatures, soit vous avez besoin de nœuds très puissants pour traiter toutes les signatures en même temps.

Notez que tout ceci est conditionnel à un objectif clé d'Ethereum : garantir qu'un attaquant subit des coûts élevés même en cas d'attaques réussies. C'est ce que l'on entend par le terme de "finalité économique". Si nous n'avions pas cet objectif, nous pourrions résoudre ce problème en sélectionnant aléatoirement un comité pour finaliser chaque créneau. Les chaînes qui ne cherchent pas à atteindre une finalité économique, telles qu'Algorand, souvent fait exactement celaMais le problème avec cette approche est que si un attaquant contrôle effectivement 51 % des validateurs, il peut alors mener une attaque (en revenant sur un bloc finalisé, en censurant ou en retardant la finalité) à très faible coût : seule la partie de leurs nœuds présents dans le comité pourrait être détectée comme participant à l'attaque et pénalisée, que ce soit parréductionoufourchette douce coordonnée socialement. Cela signifie qu'un attaquant pourrait attaquer à plusieurs reprises la chaîne de nombreuses fois, ne perdant qu'une petite partie de leur mise à chaque attaque. Par conséquent, si nous voulons une finalité économique, une approche basée sur un comité naïf ne fonctionne pas, et il semble à première vue que nous avons besoin de l'ensemble complet des validateurs pour participer.

Idéalement, nous voulons préserver la finalité économique, tout en améliorant simultanément le statu quo dans deux domaines:

1. Finaliser les blocs en un slot (idéalement, conserver voire réduire la longueur actuelle de 12s), au lieu de 15 min
2. Permettre aux validateurs de miser avec 1 Éther (au lieu de 32 Éther)

Le premier objectif est justifié par deux objectifs, tous deux pouvant être considérés comme "alignant les propriétés d'Ethereum sur celles des chaînes L1 plus centralisées axées sur la performance".

Tout d’abord, il garantit que tous les utilisateurs d’Ethereum bénéficient réellement du niveau plus élevé de garanties de sécurité obtenu grâce au mécanisme de finalité. Aujourd’hui, la plupart des utilisateurs ne le font pas, car ils ne sont pas prêts à attendre 15 minutes ; Avec la finalité à emplacement unique, les utilisateurs verront leurs transactions finalisées presque dès qu’elles seront confirmées. Deuxièmement, cela simplifie le protocole et l’infrastructure environnante si les utilisateurs et les applications n’ont pas à s’inquiéter de la possibilité d’un retour en arrière de la chaîne, sauf dans le cas relativement rare d’un fuite d'inactivité.

Le deuxième objectif est justifié par le désir de soutenir les stakers individuels. Sondage après sondage montre à plusieurs reprises que le principal facteur empêchant plus de personnes de faire du staking individuel est le minimum de 32 ETH. En réduisant le minimum à 1 ETH, ce problème serait résolu, au point que d'autres préoccupations deviennent le facteur dominant limitant le staking individuel.

Il y a un défi : les objectifs d'une finalité plus rapide et d'une participation plus démocratisée entrent en conflit avec l'objectif de minimiser les frais généraux. Et en effet, c'est toute la raison pour laquelle nous n'avons pas commencé avec une finalité à un seul emplacement au départ. Cependant, des recherches plus récentes présentent quelques chemins possibles pour contourner le problème.

Qu'est-ce que c'est et comment ça marche?

La finalité en un seul slot consiste à utiliser un algorithme de consensus qui finalise les blocs en un seul slot. En soi, ce n'est pas un objectif difficile : de nombreux algorithmes, tels que consensus Tendermint, déjà faire cela avec des propriétés optimales. Une propriété souhaitée unique à Ethereum, que Tendermint ne prend pas en charge, est fuites d'inactivité, ce qui permet à la chaîne de continuer et éventuellement de récupérer même lorsque plus d'un tiers des validateurs se déconnectent. Heureusement, ce souhait a déjà été pris en compte : il y en adéjà des propositionsqui modifient le consensus de style Tendermint pour accommoder les fuites d'inactivité.

Une proposition de finalité de slot unique leader

La partie la plus difficile du problème est de trouver comment faire fonctionner la finalité à un seul emplacement avec un nombre très élevé de validateurs, sans entraîner une surcharge extrêmement élevée pour les opérateurs de nœuds. Pour cela, il existe quelques solutions principales :

• Option 1: Force brute - travailler dur pour mettre en œuvre de meilleurs protocoles d'agrégation de signatures, potentiellement en utilisant des ZK-SNARKs, ce qui nous permettrait effectivement de traiter les signatures de millions de validateurs dans chaque créneau.

Horn, l'un des designs proposés pour un meilleur protocole d'agrégation.

• Option 2: Comités d'orbite- un nouveau mécanisme qui permet à un comité de taille moyenne sélectionné de manière aléatoire d'être responsable de la finalisation de la chaîne, mais de manière à préserver les propriétés de coût d'attaque que nous recherchons.

  Une manière de penser à Orbit SSF est qu'il ouvre un espace d'options de compromis le long d'un spectre de x=0 (comités de style Algorand, pas de finalité économique) à x=1 (statu quo Ethereum), en ouvrant des points au milieu où Ethereum a toujours une finalité économique suffisante pour être extrêmement sécurisé, mais en même temps, nous obtenons les avantages d'efficacité en ayant seulement besoin d'un échantillon aléatoire de taille moyenne de validateurs pour participer à chaque créneau.

Orbit tire parti de l'hétérogénéité préexistante des tailles de dépôt des validateurs pour obtenir autant de finalité économique que possible, tout en donnant toujours aux petits validateurs un rôle proportionnel. De plus, Orbit utilise une rotation lente du comité pour garantir un chevauchement élevé entre les quorums adjacents, garantissant que sa finalité économique s'applique toujours aux limites de commutation du comité.

• Option 3: mise en jeu à deux niveaux - un mécanisme où il y a deux classes de stakers, l'une avec des exigences de dépôt plus élevées et l'autre avec des exigences de dépôt plus faibles. Seule la tranche à dépôt plus élevé serait directement impliquée dans la fourniture de finalité économique. Il existe diverses propositions (par exemple, voir le post d'empilage Rainbow) pour savoir exactement quels sont les droits et responsabilités du niveau de dépôt inférieur. Les idées courantes incluent:
  • le droit de déléguer la mise à un staker de niveau supérieur
  • un échantillon aléatoire de stakers de niveau inférieur attestant, et étant nécessaires pour finaliser, chaque bloc
  • le droit de générerlistes d'inclusion

Quels sont quelques liens vers des recherches existantes?

• Chemins vers la finalité d'un seul créneau (2022): @vbuterin/single_slot_finality"">https://notes.ethereum.org/@vbuterin/single_slot_finality
• Une proposition concrète pour un protocole de finalité à emplacement unique pour Ethereum (2023) : https://eprint.iacr.org/2023/280
• Orbit SSF: https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928
• Analyse approfondie des mécanismes de style Orbit : https://ethresear.ch/t/vorbit-ssf-with-circular-and-spiral-finality-validator-selection-and-distribution/20464
• Horn, protocole d'agrégation de signatures (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219
• Fusion de signatures pour un consensus à grande échelle (2023) :https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn
• Protocole d'agrégation de signature proposé par Khovratovich et al: @7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/"">https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/
• Agrégation de signatures basée sur STARK (2022): @vbuterin/stark_aggregation"">https://hackmd.io/@vbuterin/stark_aggregation
• Staking Rainbow : https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683

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

Il existe quatre principales voies possibles à emprunter (et nous pouvons également emprunter des voies hybrides):

1. Maintenir le statu quo
2. SSF par force brute
3. Orbit SSF
4. SSF avec un jalonnement à deux niveaux

(1) signifie ne rien faire et laisser le jalonnement tel quel, mais cela laisse l'expérience de sécurité d'Ethereum et les propriétés de centralisation du jalonnement pires qu'elles ne pourraient l'être.

(2) force brute le problème avec une haute technologie. Pour que cela se produise, il faut agréger un très grand nombre de signatures (1 million et plus) en très peu de temps (5-10s). Une façon de voir cette approche est qu'elle impliqueminimiser la complexité systémique en acceptant pleinement la complexité encapsulée.

(3) évite le "high tech", et résout le problème en repensant astucieusement les hypothèses du protocole : nous relâchons l'exigence de "finalité économique" de sorte que nous exigions que les attaques soient coûteuses, mais nous acceptons que le coût de l'attaque soit peut-être 10 fois moins élevé qu'aujourd'hui (par exemple, un coût d'attaque de 2,5 milliards de dollars au lieu de 25 milliards de dollars). Il est couramment admis qu'Ethereum dispose actuellement d'une finalité économique bien plus importante que nécessaire, et que ses principaux risques en termes de sécurité se situent ailleurs, de sorte que c'est probablement un sacrifice acceptable à faire.

Le travail principal à faire consiste à vérifier que le mécanisme Orbit est sûr et possède les propriétés que nous voulons, puis à le formaliser et à le mettre en œuvre de manière exhaustive. De plus, EIP-7251 (augmenter le solde effectif maximal)permet la consolidation volontaire des soldes des validateurs, ce qui réduit immédiatement quelque peu la surcharge de vérification de la chaîne, et agit comme une étape initiale efficace pour le déploiement d'Orbit.

(4) évite une refonte astucieuse et haute technologie, mais crée tout de même un système de mise en jeu à deux niveaux qui comporte encore des risques de centralisation. Les risques dépendent fortement des droits spécifiques que le niveau inférieur de mise en jeu obtient. Par exemple :

• Si un staker de bas niveau doit déléguer ses droits de validation à un staker de haut niveau, alors la délégation pourrait se centraliser et nous nous retrouverions ainsi avec deux niveaux de participation très centralisés.
• Si un échantillon aléatoire du niveau inférieur est nécessaire pour approuver chaque bloc, alors un attaquant pourrait dépenser une très petite quantité d'ETH pour bloquer la finalité.
• Si les validateurs de niveau inférieur ne peuvent faire que des listes d'inclusion, alors la couche d'attestation peut rester centralisée, à ce stade, une attaque à 51% sur la couche d'attestation peut censurer les listes d'inclusion elles-mêmes.

Plusieurs stratégies peuvent être combinées, par exemple:

(1 + 2): utilisez des techniques de force brute pour réduire la taille minimale du dépôt sans effectuer de finalité de slot unique. La quantité d'agrégation requise est 64 fois inférieure à celle du cas pur (3), le problème devient donc plus facile.

(1 + 3): ajouter Orbit sans effectuer de finalité de slot unique

(2 + 3): faire Orbit SSF avec des paramètres conservateurs (par exemple 128k comité de validateurs au lieu de 8k ou 32k), et utiliser des techniques de force brute pour le rendre ultra-efficace.

(1 + 4): ajouter le staking arc-en-ciel sans effectuer de finalité de slot unique

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

En plus de ses autres avantages, la finalité d'un seul slot réduit le risque de certains types d’attaques MEV multiblocsDe plus, les conceptions de séparation attester-proposer et d'autres pipelines de production de blocs en protocole devraient être conçues différemment dans un monde de finalité à un seul emplacement.

Les stratégies de force brute ont pour faiblesse de rendre plus difficile la réduction des temps de slot.

Élection d'un seul chef secret

Quel problème résolvons-nous?

Aujourd'hui, le validateur qui va proposer le prochain bloc est connu à l'avance. Cela crée une vulnérabilité de sécurité : un attaquant peut surveiller le réseau, identifier quels validateurs correspondent à quelles adresses IP, et attaquer par déni de service chaque validateur juste au moment où ils s'apprêtent à proposer un bloc.

Qu'est-ce que c'est et comment ça marche?

La meilleure façon de corriger le problème de DoS est de masquer l'information sur le validateur qui va produire le prochain bloc, du moins jusqu'au moment où le bloc est effectivement produit. Notez que c'est facile si nous supprimons l'exigence "unique".une solutionest de permettre à n'importe qui de créer le prochain bloc, mais d'exiger le révélation randaoêtre inférieur à 2256 / N. En moyenne, un seul validateur serait en mesure de répondre à cette exigence - mais parfois il y en aurait deux ou plus et parfois il n'y en aurait aucun. Combiner l'exigence de "secrecy" avec l'exigence de "single" a longtemps été le problème difficile.

Les protocoles de sélection de leader unique résolvent ce problème en utilisant certaines techniques cryptographiques pour créer un ID de validateur "aveuglé" pour chaque validateur, puis en donnant à de nombreux proposants l'opportunité de mélanger et de re-blinder le pool d'IDs aveuglés (ceci est similaire à la façon dont un mixnetfonctionne). Pendant chaque créneau, un ID aveuglé aléatoire est sélectionné. Seul le propriétaire de cet ID aveuglé est capable de générer une preuve valide pour proposer le bloc, mais personne d'autre ne sait à quel validateur cet ID aveuglé correspond.

Protocole SSLE de fouet

Quels sont quelques liens vers des recherches existantes?

• Article de Dan Boneh (2020): https://eprint.iacr.org/2020/025.pdf
• Whisk (proposition concrète pour Ethereum, 2022): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763
• Étiquette d'élection de leader secret unique sur ethresear.ch : https://ethresear.ch/tag/single-secret-leader-election
• SSLE simplifié utilisant des signatures d'anneau: https://ethresear.ch/t/simplified-ssle/12315

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

De manière réaliste, ce qu'il reste à faire, c'est trouver et mettre en œuvre un protocole suffisamment simple pour que nous soyons à l'aise de le mettre en œuvre sur le réseau principal. Nous attachons une grande valeur au fait qu'Ethereum soit un protocole raisonnablement simple, et nous ne voulons pas que la complexité augmente davantage. Les implémentations SSLE que nous avons vues ajoutent des centaines de lignes de code spécifique, et introduisent de nouvelles hypothèses en cryptographie compliquée. Trouver une implémentation SSLE suffisamment efficace et résistante aux attaques quantiques est également un problème ouvert.

Il se peut que la complexité supplémentaire introduite par SSLE ne diminue suffisamment que lorsque nous franchissons le pas et introduisons la machinerie permettant de réaliser des preuves de connaissance zéro à usage général dans le protocole Ethereum au niveau L1 pour d'autres raisons (par exemple, les arbres d'état, ZK-EVM).

Une option alternative consiste tout simplement à ne pas se préoccuper du SSLE et à utiliser des atténuations en dehors du protocole (par exemple, au niveau de la couche p2p) pour résoudre les problèmes de DoS.

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

Si nous ajoutons un mécanisme de séparation attester-proposer (APS), par exemple. tickets d'exécution, alors les blocs d'exécution (c'est-à-dire les blocs contenant des transactions Ethereum) n'auront pas besoin de SSLE, car nous pourrions compter sur des constructeurs de blocs spécialisés. Cependant, nous bénéficierions toujours de SSLE pour les blocs de consensus (c'est-à-dire les blocs contenant des messages de protocole tels que des attestations, peut-être des morceaux de listes d'inclusion, etc).

Confirmations de transactions plus rapides

Quel problème résolvons-nous?

Il y a de la valeur dans l'Éthereum temps de confirmation de la transaction diminuant encore, de 12 secondes à par exemple 4 secondes. Faire cela améliorerait considérablement l'expérience utilisateur à la fois des L1 et des rollups basés, tout en rendant les protocoles de defi plus efficaces. Cela rendrait également plus facile la décentralisation des L2, car cela permettrait à une grande classe d'applications L2 de fonctionner sur rouleaux basés, réduisant la demande pour que les L2 construisent leur propre séquençage décentralisé basé sur des comités.

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

Il existe globalement deux familles de techniques ici :

1. Réduisez les temps de slot, jusqu'à par exemple. 8 secondesou 4 secondes. Cela ne signifie pas nécessairement une finalité de 4 secondes : la finalité nécessite trois cycles de communication, nous pouvons donc faire en sorte que chaque cycle de communication soit un bloc séparé, ce qui permettrait d'obtenir au moins une confirmation préliminaire après 4 secondes.
2. Permettre aux proposants de publier des pré-confirmations tout au long d'un créneau. Dans l'extrême, un proposant pourrait inclure en temps réel les transactions qu'il voit dans son bloc et publier immédiatement un message de pré-confirmation pour chaque transaction ("Ma première transaction est 0×1234…", "Ma deuxième transaction est 0×5678…"). Le cas d'un proposant publiant deux confirmations conflictuelles peut être traité de deux manières : (i) en amputant le proposant, ou (ii) en utilisant des témoins pour voter sur laquelle est intervenue en premier.

Quels sont quelques liens vers des recherches existantes?

• Préconfirmations basées: https://ethresear.ch/t/based-preconfirmations/17353
• Engagements des proposants imposés par le protocole (PEPC) : https://ethresear.ch/t/dégroupage-pbs-vers-des-engagements-de-proposant-imposés-par-le-protocole-pepc/13879
• Périodes échelonnées à travers des chaînes parallèles (une idée de l'ère 2018 pour atteindre une faible latence): https://ethresear.ch/t/staggered-periods/1793

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

Il n'est pas du tout clair à quel point il est pratique de réduire les temps de fente. Même aujourd'hui, les validateurs dans de nombreuses régions du monde ont du mal à faire inclure suffisamment rapidement les attestations. Tenter des temps de fente de 4 secondes comporte le risque de centraliser l'ensemble des validateurs et de rendre impraticable le fait d'être un validateur en dehors de quelques géographies privilégiées en raison de la latence. Plus précisément, passer à des temps de fente de 4 secondes nécessiterait de réduire la limite de latence du réseau ("delta") à deux secondes.

L'approche de préconfirmation du proposant a pour faiblesse qu'elle peut grandement améliorer les temps d'inclusion dans le cas moyen, mais pas dans le pire des cas : si le proposant actuel fonctionne bien, votre transaction sera pré-confirmée en 0,5 seconde au lieu d'être incluse (en moyenne) en 6 secondes, mais si le proposant actuel est hors ligne ou ne fonctionne pas bien, vous devrez quand même attendre jusqu'à 12 secondes complètes pour que la prochaine tranche démarre et fournisse un nouveau proposant.

De plus, il y a la question ouverte de savoir comment les pré-confirmations seront incitées. Les proposants sont incités à maximiser leur optionnalité aussi longtemps que possible. Si les certificateurs approuvent la ponctualité des préconfirmations, les expéditeurs de transactions pourraient subordonner une partie des frais à une pré-confirmation immédiate, mais cela imposerait un fardeau supplémentaire aux attesteurs et rendrait potentiellement plus difficile pour les attesteurs de continuer à fonctionner comme un « tuyau muet » neutre.

D'autre part, si nous n'essayons pas cela et maintenons les délais de finalité à 12 secondes (ou plus longs), l'écosystème accordera plus de poids aux mécanismes de pré-confirmation créés par les couches 2, et l'interaction entre les couches 2 prendra plus de temps.

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

Les préconfirmations basées sur le proposant dépendent réaliste d'un mécanisme de séparation attester-proposant (APS), par exemple. billets d'exécutionSinon, la pression pour fournir des préconfirmations en temps réel peut être trop centralisatrice pour les validateurs réguliers.

La durée exacte des créneaux courts dépend également de la structure du créneau, qui dépend fortement des versions des APS, des listes d'inclusion, etc. que nous finissons par implémenter. Il existe des structures de créneaux qui contiennent moins de tours et qui sont donc plus favorables aux créneaux courts, mais elles font des compromis à d'autres endroits.

Autres domaines de recherche

Récupération après une attaque de 51%

Il est souvent supposé que si une attaque de 51% se produit (y compris des attaques qui ne sont pas cryptographiquement prouvables, telles que la censure), la communauté se réunira pour mettre en œuvre un minorité soft forkqui garantit que les gentils gagnent, et que les méchants sont inactifs ou réduits. Cependant, ce degré de dépendance excessive à la couche sociale est discutablement malsain. Nous pouvons essayer de réduire la dépendance à la couche sociale en rendant le processus de récupération aussi automatisé que possible.

L’automatisation complète est impossible, car si c’était le cas, cela compterait comme un algorithme de consensus tolérant aux pannes de >50 %, et nous connaissons déjà le (très restrictif) limites mathématiquement prouvables de ces types d'algorithmes. Mais nous pouvons atteindre une automatisation partielle : par exemple, un client pourrait automatiquement refuser d'accepter une chaîne comme finalisée, ou même comme étant la tête du choix de la fourchette, si elle censure les transactions que le client a vues pendant assez longtemps. Un objectif clé serait de s'assurer que les méchants lors d'une attaque ne peuvent au moins pas obtenir une victoire rapide et facile.

Augmentation du seuil de quorum

Aujourd’hui, un bloc se finalise si 67% des stakers le soutiennent. Certains prétendent que c’est trop agressif. Il n’y a eu qu’un seul (très bref) échec de la finalité dans toute l’histoire d’Ethereum. Si ce pourcentage est augmenté, par exemple. à 80 %, alors le nombre supplémentaire de périodes de non-finalité sera relativement faible, mais Ethereum gagnerait des propriétés de sécurité : en particulier, de nombreuses situations plus litigieuses entraîneront l’arrêt temporaire de la finalité. Cela semble être une situation beaucoup plus saine que « le mauvais côté » obtenant une victoire instantanée, à la fois lorsque le mauvais côté est un attaquant et lorsqu’il s’agit d’un client qui a un bogue.

Cela donne également une réponse à la question « quel est l'intérêt des stakers solo » ? Aujourd'hui, la plupart des stakers misent déjà via des pools, et il semble très peu probable d'atteindre 51 % de ETH misé en solo. Cependant, amener les stakers solo à constituer une minorité bloquante de quorum, surtout si le quorum est de 80 % (une minorité bloquante de quorum aurait seulement besoin de 21 %), semble potentiellement réalisable si nous travaillons dur. Tant que les stakers solo ne participent pas à une attaque de 51 % (qu'il s'agisse de réversion de finalité ou de censure), une telle attaque ne remporterait pas une « victoire propre », et les stakers solo seraient motivés pour aider à organiser une mise à jour logicielle de minorité.

Notez qu'il existe des interactions entre les seuils de quorum et le mécanisme Orbit : si nous finissons par utiliser Orbit, alors ce que signifie exactement "21% des validateurs" deviendra une question plus compliquée, et dépendra en partie de la répartition des validateurs.

Résistance quantique

Metaculus croit actuellement, bien que avec de larges barres d'erreur, il est probable que les ordinateurs quantiques commenceront probablement à casser la cryptographie quelque part dans les années 2030 :

Les experts en informatique quantique tels que Scott Aaronson ont également récemment commencé à envisager la possibilité que les ordinateurs quantiques fonctionnent réellement à moyen termebeaucoup plus sérieusement. Cela a des conséquences sur l’ensemble de la feuille de route d’Ethereum : cela signifie que chaque élément du protocole Ethereum qui dépend actuellement de courbes elliptiques devra avoir un remplacement basé sur le hachage ou autrement résistant au quantique. Cela signifie en particulier que nous ne pouvons pas supposer que nous pourrons nous appuyer sur les excellentes propriétés de l’agrégation BLSpour traiter les signatures d'un grand ensemble de validateurs pour toujours. Cela justifie le conservatisme dans les hypothèses concernant les performances des conceptions de preuve d'enjeu, et est également une raison d'être plus proactif dans le développement d'alternatives résistantes à la cryptographie quantique.

Avertissement：

1. Cet article est reproduit à partir de [Vitalik Buterin], Tous les droits d'auteur appartiennent à l'auteur original [Vitalik Buterin]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.