Cette série de 75 Tweets peut être trouvé sur la page Twitter de Vitalik Buterin. Nous l'avons transcrite et traduite ici pour plus de commodité.
«Aujourd'hui, je vais faire une tempête de tweet pour expliquer l'histoire et l'état de la recherche d'Ethereum sur Casper, y compris les guerres FFG vs CBC, le switch hybride =>, le rôle du hasard, les problèmes de conception des mécanismes, etc.
La recherche de Preuve de l’Enjeu («Proof of Stake » ou « POS ») d'Ethereum a commencé en janvier 2014 avec Slasher. Bien que l'algorithme soit très sous-optimal, il a introduit des idées importantes, plus particulièrement l'utilisation de pénalités pour résoudre le problème du « Nothing at Stake ».
Voici la réplique de Vlad:
L'histoire de Casper - Partie 1
Republié du blog Ethereum à la demande de Steve D. Mckie.medium.com
Nous avons passé une bonne partie de la fin de 2014 à essayer de gérer les «attaques à longue distance», qui permettent aux attaquants de retirer leur mise des dépôts de la chaîne principale et de créer une «chaîne d’attaque» avec plus de signatures que la chaîne principale et au’ils pourraient utiliser pour tromper les clients.
Si la chaîne d'attaque diverge de la chaîne principale à un moment relativement récent, ce n'est pas un problème car si les validateurs signent deux messages contradictoires pour les deux chaînes en conflit, cela peut servir de preuve pour les pénaliser et leur enlever leurs dépôts. Mais si la divergence s'est produite il y a longtemps (donc, une attaque à longue distance), les attaquants pourraient retirer leurs dépôts, empêchant ainsi les pénalités sur l'une ou l'autre chaîne.
Nous avons finalement décidé que les attaques à longue portée étaient inévitables pour les raisons que les partisans de la Preuve du Travail (« Proof of Work » ou « POW ») déclarent (par exemple, https://download.wpsoftware.net/bitcoin/pos.pdf).
Cependant, nous n’avons pas accepté leurs conclusions. Nous avons réalisé que nous pouvions gérer les attaques à long portée en introduisant une hypothèse de sécurité supplémentaire: les clients se connectent au moins une fois tous les quatre mois (et les dépôts prennent quatre mois pour se retirer) et les clients refusent simplement de revenir plus loin.
Proof of work
C'était un anathème pour les promoteurs de la Preuve du Travail, car cela ressemble à une hypothèse de confiance: vous devez obtenir la chaîne de blocs à partir d'une source fiable lorsque vous synchronisez pour la première fois. Mais pour nous, pauvres subjectivistes, cela ne semblait pas être un gros problème; vous avez besoin d’une source de confiance pour vous dire quelles sont les règles de consensus de la blockchain dans tous les cas (et ne pas oublier les mises à jour logicielles).
Voici la réplique de Vlad:
L'histoire de Casper - Chapitre 2
Maintenant que nous avons réglé les dépôts et les pénalités, nous avons dû décider quels étaient ces dépôts et ces pénalités. Nous savions que nous voulions une propriété de «finalité économique», dans laquelle les valideurs signaient les blocs de telle manière qu'une fois qu'un bloc était «finalisé», aucun bloc en conflit ne pourrait être finalisé sans qu'une grande partie des validateurs doive signer des messages qui entrent en conflit avec leurs messages précédents de manière à ce que la blockchain puisse les détecter et donc les pénaliser.
Je suis allé sur une longue et finalement improductive tangente dans une direction que j'ai appelée «consensus par pari»:
Comprendre Serenity, partie 2: Casper
Le « consensus par pari » est une construction intéressante dans laquelle les validateurs miseraient sur le bloc qui serait finalisé et les paris eux-mêmes détermineraient quelle chaîne le consensus favoriserait. La théorie était que le PoW possède également cette propriété, car l'exploitation minière est un pari où si vous misez sur la bonne chaîne, vous gagnez (récompense - frais d'exploitation), et si vous misez sur la mauvaise chaîne, avec PoS nous pourrions pousser les chances sur les paris beaucoup plus élevés.
Les probabilités sur les paris des validateurs commenceraient bas, mais comme les validateurs se voyaient de plus en plus confiants dans un bloc, les probabilités de chacun augmenteraient de manière exponentielle, en parallèle, jusqu’à ce qu’ils finissent par miser tous leurs dépôts sur un bloc. Ce serait la «finalité».
Pendant ce temps, Vlad a commencé à faire des recherches approfondies sur la conception des mécanismes, en particulier pour rendre Casper plus robuste face aux oligopoles, et nous avons également commencé à examiner des algorithmes consensuels inspirés de la théorie de la tolérance aux fautes byzantine traditionnelle, telle que Tendermint.
Vlad a décidé que le BFT traditionnel était boiteux (il a particulièrement détesté les seuils durs, comme le 2/3 dans PBFT et Tendermint), et il essaierait de réinventer efficacement la théorie du BFT en utilisant une approche qu'il a appelée «Correct by Construction» (CBC). )
Dans les propres mots de Vlad:
L'histoire de Casper - Chapitre 5
La philosophie de la CBC est très différente de celle du BFT traditionnel, en ce sens que la «finalité» est entièrement subjective. Dans la philosophie de la CBC, les validateurs signent des messages et, s’ils signent un message qui entre en conflit avec leur message précédent, ils doivent soumettre une «justification» prouvant que, dans le sens le plus pertinent, La nouvelle chose pour laquelle ils votent a davantage de support que la vieille chose pour laquelle ils votaient, et ils ont donc le droit de changer.
Pour détecter la finalité, les clients recherchent des modèles de messages qui prouvent que la majorité des validateurs votent de manière fiable pour certains blocs B de telle manière qu’ils ne peuvent pas s’écarter de B sans qu'une grande partie des validateurs changent illégalement leurs votes.
Ethereum lighter
Par exemple, si tout le monde vote pour B, alors tout le monde vote sur un bloc qui contient les votes de tous pour B, ce qui prouve qu'ils supportent B et sont conscients que tout le monde supporte B, que B.
J'ai finalement renoncé au consensus, parce que cette approche semblait trop risquée, et je suis donc revenu à essayer de comprendre comment fonctionnent les algorithmes tels que PBFT. Cela a pris du temps, mais après quelques mois, j'ai compris.
J'ai réussi à simplifier PBFT et à le traduire dans le contexte de la blockchain, en le décrivant comme quatre «conditions tranchantes», règles qui définissent quelles combinaisons de messages sont contradictoires et donc illégales:
Conditions de coupure minimales
J'ai défini une règle pour déterminer quand un bloc est finalisé et prouvé les propriétés clés «sécurité» et «vivacité plausible»: (i) si un bloc est finalisé, il est impossible qu'un bloc en conflit soit finalisé sans> = 1/3 violant une condition de coupure, moneybalresistent à (ii) si un bloc est finalisé, 2/3 des validateurs honnêtes peuvent toujours coopérer pour finaliser un nouveau bloc. Ainsi, l'algorithme ne peut ni «revenir sur ses mots» ni «rester bloqué» tant que 2/3 sont honnêtes.
J'ai finalement simplifié les conditions minimales tranchantes de quatre à deux et à partir de là, Casper, le Friendly Finality Gadget (FFG), a été conçu pour être utilisé en superposition sur tout PoW, PoS ou autre blockchain pour ajouter des garanties de finalité.
La finalité est une avancée très importante: une fois qu'un bloc est finalisé, il est sécurisé quelle que soit la latence du réseau (contrairement aux confirmations dans le PoW), et revenir sur un block nécessite >= 1/3 de validateurs qui tichent d’une manière qui peut être détectée et utilisée pour détruire leurs dépôts. Par conséquent, le coût du retour à la finalité peut atteindre les milliards de dollars. Les approches Casper CBC et Casper FFG permettent d’atteindre cet objectif, mais de manière techniquement différente.
Notez que Casper CBC et Casper FFG sont * les deux * “superpositions” qui doivent être appliquées par-dessus une règle de choix de fourche existante, bien que les abstractions fonctionnent de différentes manières.
En termes simples, dans Casper CBC, la superposition de finalité s’adapte à la règle de choix de fourche, tandis que dans Casper FFG, la règle de choix de fourche s’adapte à la superposition de finalité.
Casper
La préférence initiale de Vlad pour la règle du choix de la fourchette était «“Le dernier GHOST piloté par les messages”, une adaptation de GHOST (https://eprint.iacr.org/2013/881.pdf) à la Preuve de l'Enjeu, et ma préférence initiale était de commencer avec le PoS hybride, en utilisant la Preuve du Travail comme règle de choix de la fourchette de base.
Dans la version initiale de Casper FFG, la Preuve du Travail «exécuterait» la chaîne bloc par bloc, et la Preuve de l'Enjeu suivrait de près pour finaliser les blocs. Casper CBC était une preuve complète d’enjeu dès le départ. Dans le même temps, Vlad et moi-même étions en train de créer nos propres écoles de pensée sur la théorie du consensus *.
Ici, une distinction très importante est entre * les fautes attribuables de manière unique *, où vous pouvez dire qui est responsable et peut donc les pénaliser, et * les fautes imputables non uniquement *, où une des parties multiples peut avoir causé la faute. Le cas classique d’une faille non attribuable de manière unique est mis hors ligne par opposition à la censure, également appelée «équivalence de faute du locuteur / auditeur».
Pénaliser des fautes uniquement attribuables (par exemple, les conditions de tranchage de Casper FFG) est facile. Pénaliser les fautes non imputables est difficile.
Que se passe-t-il si vous ne pouvez pas dire si les blocs ont cessé d’être finalisés parce qu’une minorité est déconnectée ou parce que la majorité censure la minorité?
Il existe essentiellement trois écoles de pensée sur cette question:
(i) Pénaliser un peu les deux côtés (ii) Pénaliser durement les deux côtés (préférence de Vlad) (iii) Diviser la chaîne en deux, pénaliser une partie sur chaque chaîne et laisser le marché décider quelle chaîne est la plus précieuse (ma préférence).
Ou, dans mes mots:
Le triangle des méfaits
En novembre 2017, les conditions tranchantes de Casper FFG et mes idées pour résoudre le problème du «1/3 hors ligne» grâce à un mécanisme de «fuite quadratique» sont devenues un document:
[1710.09437] Le gadget amical de finalité de Casper
Résumé: Nous présentons Casper, une preuve du système de finalité basé sur la mise qui recouvre une preuve de travail existante… arxiv.org
Bien sûr, je savais bien que faire appel à la couche sociale pour résoudre les attaques à 51% n'était pas une très bonne chose, alors j'ai commencé à chercher des moyens pour permettre aux clients en ligne de détecter automatiquement la chaîne légitime et quelle est l’attaque en temps réel.
Voici une de mes idées précédentes:
Rejet de censure par "scores de suspicion"
C'était quelque chose, mais toujours sous-optimal; À moins que la latence du réseau ne soit exactement égale à zéro, il n’y avait qu’une garantie que les scores de suspicion des clients différaient au maximum par delta, et non que les clients seraient entièrement d’accord.
Entre-temps, ma principale critique du modèle de Vlad concernait les «attaques de découragement», où les attaquants pouvaient menacer de manière crédible d’attaquer 51% de la population, entraînant ainsi les autres à abandonner, dominant ainsi la chaîne. Coût quasi nul. Vlad (avec Georgios Piliouras) a commencé à faire de la modélisation économique pour estimer le coût réel d'une telle attaque sous son modèle.
Il convient de noter que tous ces problèmes ne sont pas propres à la Preuve de l'Enjeu. En fait, dans la Preuve du Travail, les gens ont tendance à simplement abandonner et à supposer que prévenir les attaques à 51% est tout à fait impossible, et une attaque à 51% est une catastrophe qui doit être évitée à tout prix. Mais, tout comme la tradition Ethereum, Vlad et moi-même ne savions pas que le mot «ambitieux» pouvait être tout sauf un compliment et continuions à travailler sur nos différentes approches pour décourager, atténuer et récupérer des attaques à 51%.
Au début de 2018, le travail de Vlad sur CBC a commencé à progresser rapidement, avec de grands progrès en matière de preuves de sécurité. En ce qui concerne l'état d'avancement en mars 2018, voyez cette présentation épique de deux heures:
Entre-temps, Casper FFG faisait d’énormes progrès. La décision de l'implémenter en tant que contrat qui serait publié sur la blockchain Ethereum a facilité le développement. Le 31 décembre 2017 à 23h40, nous avons publié un testnet écrit en python:
Instructions du testnet Alpha Casper FFG - HackMD
Malheureusement, le développement de FFG a ralenti. La décision d'implémenter FFG en tant que contrat rendait certaines choses plus faciles, mais cela rendait les choses plus difficiles, et le passage éventuel de EVM à EWASM, et de Casper à chaîne unique à Casper, serait plus difficile. En outre, le travail de l’équipe était divisé entre «la chaîne principale Casper» et «la chaîne de distribution Casper» et il était clair qu’il y avait une duplication inutile des efforts entre les équipes de Casper et de Sharding.
En juin 2018, nous avons pris la décision fatale de supprimer «Hybrid Casper FFG en tant que contrat» et de poursuivre Casper en tant que chaîne indépendante, conçue de manière à faciliter l'intégration du sharding. Le passage à la Preuve de l'Enjeu complète m'a amené à réfléchir davantage sur les règles de choix des fourches dans la Preuve de l'Enjeu.
Casper FFG (et CBC) requièrent tous deux que l'ensemble de validateurs * entier * qui doivent voter à chaque “époque” pour finaliser les blocs, ce qui signifie qu'il y aurait des dizaines à des centaines de signatures à chaque seconde. L'agrégation de signatures BLS rend cela pratique en termes de temps de calcul, mais je voulais essayer de tirer parti de toutes ces signatures supplémentaires pour rendre la chaîne beaucoup plus «stable», en obtenant une sécurité de 100 confirmations en quelques secondes.
Voici mes premières tentatives:
Un comité d'attestation basé sur des chaînes PoS complètes
Cependant, toutes ces approches de la règle du choix des fourches présentaient un point faible: elles divisaient les validateurs en «attesteurs» et en «proposants», et les proposants, principaux moteurs de la production de blocs, avaient une taille hors normes. Cela n'était pas souhaitable, principalement parce que cela nous obligeait à disposer d'une source solide de génération de nombres aléatoires en chaîne pour sélectionner les candidats de manière équitable. Et le caractère aléatoire en chaîne est * difficile *, avec des approches simples comme RANDAO semblant de plus en plus problématiques.
Analyse d'exploitation de la balise RANDAO, tour 2
Justin Drake et moi-même sommes allés résoudre ce problème de deux manières, Justin en utilisant des fonctions de retard vérifiables qui ont une sortie déterministe et vérifiable, mais prennent beaucoup de temps séquentiel non paramétrable pour rendre la manipulation impossible à l'avance. et moi-même en faisant une concession majeure au Cult of Vlad ™, en utilisant des règles de choix de fourches basées sur GHOST pour réduire considérablement la dépendance aux proposants, permettant à la chaîne de croître sans interruption même si> 90% des proposants sont malveillants % d'attestateurs sont amicaux.
Ethereum
Vlad était très heureux, mais pas complètement: il préférait une version de GHOST basée sur les derniers messages des validateurs *, alors que je préférais une version basée sur * des messages immédiats *:
La proximité récursive de la justification comme règle de choix de fourche FFG
À cette époque, j'ai également réussi à trouver un moyen de «canaliser» Casper FFG, en réduisant le temps de finalité de 2,5 époques aux 2 époques théoriquement optimales:
Chaîne de balise Casper FFG RPJ mini-spec
J'étais très heureux que la règle de choix de fourche RPJ (que j'ai renommée depuis "GHOST immédiat") soit parfaitement compatible avec Casper FFG, contrairement à la plupart des autres, et qu'elle possède une propriété "stabilité" très importante: que le choix de la fourche est une bonne prédiction du futur choix de fourche. Cela semble évident, mais il est très facile de créer accidentellement des règles de choix de fourche qui n'ont pas cette propriété.
Le développement le plus récent de tous est le résultat que le dernier message généré par GHOST peut, en raison d’une technicité, ne donner que 25% de tolérance aux pannes en deux tours, mais que le message GHOST (avec FFG ou CBC) écriture encore). Le principal compromis entre FFG et CBC est que CBC semble avoir de meilleures propriétés théoriques, mais FFG semble être plus facile à mettre en œuvre.
Entre-temps, un lot de progrès sur les fonctions de retard vérifiables a été réalisé:
En outre, j’ai récemment décidé d’examiner l’ancien article de 1982 de Leslie Lamport, dans lequel il disposait d’un algorithme de consensus avec une tolérance aux pannes de 99% si l’on supposait que tous les nœuds, y compris les observateurs, étaient en ligne avec une faible latence:
Guide du consensus à 99% tolérant aux fautes
Les hypothèses de latence du réseau rendent sans doute cela inapproprié en tant qu’algorithme de consensus primaire. Cependant, il y a un cas d'utilisation où cela fonctionne vraiment bien: en remplacement des scores de suspicion pour la détection de la censure à 51%. Fondamentalement, si une coalition à 51% commence à censurer des blocs, d'autres validateurs et clients peuvent détecter que cela se produit et utiliser le consensus à 99% de tolérance aux fautes pour convenir que cela se produit et coordonner une fourchette minoritaire.
L’objectif à long terme de cette recherche est de réduire autant que possible la dépendance à la couche sociale et de maximiser le coût de la déstabilisation de la chaîne pour qu’il soit nécessaire de revenir à la couche sociale.
Que reste-t-il maintenant? Du côté des AFG, des preuves formelles, des améliorations à la spécification et des progrès continus sur la mise en œuvre (déjà lancés par> = 3 équipes!), Dans la perspective d’un déploiement sûr et rapide. Du côté de la CBC, la situation est la même. En avant et vers le haut!
Posted from my blog with SteemPress : https://www.blockchains-expert.com/casper-ethereum/
nice post,,,follow me
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Congratulations @blockchains-exp! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :
Click on the badge to view your Board of Honor.
If you no longer want to receive notifications, reply to this comment with the word
STOPDownvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit