Logo Zéphyrnet

Un guide du Bitcoiner sur la preuve de participation

Date :

Ceci est un éditorial d'opinion de Scott Sullivan.

Normalement, les Bitcoiners ne se soucient pas trop de ce qui se passe au pays du Shitcoin, mais maintenant qu'Ethereum a fusionné avec preuve de mise (PoS), il y a eu beaucoup de buzz sur Bitcoin Twitter. Bien sûr, le réseau Bitcoin lui-même ne sera pas affecté, mais je pense que cette « mise à niveau » mérite toujours d’y prêter attention. Maintenant qu’Ethereum s’est débarrassé des externalités « sales » et « inutiles » associées à la preuve de travail (PoW), nous pouvons nous attendre à ce que les gants se détachent dans la guerre narrative, et je pense que les Bitcoiners devraient être prêts à riposter. .

Apprendre comment fonctionne PoS est un très bon moyen d'internaliser les différences et les compromis entre PoW et PoS. Même si j'avais déjà vu tous les arguments de haut niveau contre le PoS - que le PoS est plus autorisé, centralisateur et oligarchique - j'admettrai que sans regarder dans les détails, tout semblait un peu vague. En plongeant réellement dans l'algorithme PoS, nous pouvons commencer à voir comment toutes ces propriétés émergent naturellement des premiers principes. Donc, si vous êtes curieux de savoir comment fonctionne l'algorithme PoS et pourquoi il conduit à ce type de propriétés, alors lisez la suite !

Résoudre le problème de la double dépense

Commençons par un bref récapitulatif du problème que nous essayons de résoudre. Supposons que nous ayons un grand groupe de participants dans un réseau de crypto-monnaie essayant de maintenir un registre décentralisé. Voici le problème : comment de nouvelles transactions peuvent-elles être ajoutées au grand livre de chacun, de sorte que tout le monde s'accorde sur les nouvelles transactions qui sont « correctes » ? PoW résout ce problème de manière assez élégante : les transactions sont regroupées en blocs, chaque bloc nécessitant une grande quantité de travail de calcul pour être produit. La quantité de travail requise peut augmenter ou diminuer pour s'assurer que les blocs sont produits toutes les dix minutes en moyenne, ce qui donne à chaque nouveau bloc suffisamment de temps pour se propager à travers le réseau avant que le suivant ne soit créé. Toute ambiguïté est résolue en sélectionnant la chaîne avec le plus de travail, et les doubles dépenses sont évitées car elles nécessitent au moins 51 % de la puissance de hachage globale pour qu'un bloc à double dépenses rattrape son retard.

Mais supposons maintenant que nous voulions jeter la perspicacité clé de Satoshi Nakamoto qui a rendu tout cela possible en premier lieu. Après tout, ces satanés ASIC sont bruyants et ennuyeux, et ils consomment plus d'énergie que tous les jets privés de George Soros, Bill Gates et Hillary Clinton réunis. Existe-t-il un moyen de nous mettre d'accord sans ambiguïté sur les transactions qui sont vraies simplement en en parlant ?

La preuve de participation d'Ethereum propose de résoudre ce problème en utilisant deux ingrédients clés. La première consiste à créer de temps en temps des «blocs de points de contrôle» spéciaux, dont le but est de donner à chacun dans le réseau l'assurance de la «vérité» du système à différents moments. La création d'un point de contrôle nécessite un vote à la majorité des deux tiers par pieu, il y a donc une certaine assurance que la majorité des validateurs étaient d'accord sur ce qu'était réellement la vérité à ce moment-là. Le deuxième ingrédient consiste à punir les utilisateurs pour avoir ajouté de l'ambiguïté au réseau, un processus connu sous le nom de "slashing". Par exemple, si un validateur créait un fork ou votait sur une ancienne sidechain (similaire à une attaque à 51%), alors sa mise serait réduite. Les validateurs peuvent également être réduits pour inactivité, mais pas autant.

Cela nous amène à notre premier principe derrière le PoS, à savoir que le PoS est basé sur un système d'incitation négatif (basé sur des pénalités).

Cela contraste fortement avec Bitcoin et la preuve de travail, qui est un système d'incitation positif (basé sur la récompense). Dans Bitcoin, les mineurs peuvent tenter d’enfreindre les règles – blocs mal formatés, transactions invalides, etc. – mais ces blocs seront simplement ignorés par les nœuds complets. Le pire des cas est un peu de gaspillage d’énergie. Les mineurs sont également libres de construire sur des blocs plus anciens, mais sans 51 % de puissance de hachage, ces chaînes ne rattraperont jamais leur retard, gaspillant encore une fois de l'énergie. Tout mineur qui participe à ces actions, intentionnellement ou non, n'a pas à craindre de perdre ses bitcoins ou ses machines de minage accumulés, mais il n'obtiendra pas de nouvelles récompenses. Plutôt que de vivre dans la peur, les mineurs de Bitcoin peuvent privilégier l’action et le risque.

Le monde est un endroit très différent pour les validateurs vivant dans Ethereum-land. Au lieu de travailler dur et d'être récompensés pour avoir ajouté de la sécurité au réseau, les validateurs ne font aucun travail réel, mais doivent veiller à ce que leur nœud ne se comporte jamais mal, de peur qu'ils ne voient leurs économies s'envoler. Si des modifications proposées étaient apportées au réseau, le premier réflexe d'un validateur serait de se conformer à ce que tout le monde faisait, sinon il risquerait d'être coupé. Être un validateur, c'est comme marcher sur des coquilles d'œufs tous les jours.

Soit dit en passant, vivre sous un système d'incitations négatives est l'un des "avantages" de la preuve de participation, selon le co-fondateur du réseau Ethereum, Vitalik Buterin. QFP:

Alors, comment le slash fonctionnerait-il réellement sur le plan technique ? Ne devrions-nous pas d'abord créer une liste de tous les validateurs, afin d'avoir quelque chose à couper en premier lieu ? La réponse est oui. Pour devenir un validateur dans Ethereum, il faut d'abord déplacer ETH dans une adresse spéciale de « jalonnement ». Non seulement cette liste est nécessaire pour réduire, mais aussi pour voter puisqu'un vote à la majorité des deux tiers est nécessaire pour les blocs de points de contrôle.

Il y a des implications intéressantes à maintenir une liste de tous les validateurs à tout moment. Est-ce difficile de rejoindre? Est-ce difficile de partir ? Les validateurs peuvent-ils voter sur le statut des autres validateurs ?

Cela nous amène à notre deuxième principe derrière PoS, à savoir que PoS est un système autorisé.

La première étape pour devenir validateur consiste à déposer de l’ETH dans une adresse de jalonnement spéciale. Combien d’ETH ? Le minimum requis est de 32 ETH, soit environ 50,000 9 $ au moment d'écrire ces lignes. Pour le contexte, une plate-forme minière Bitcoin décente coûte généralement des milliers de dollars à un chiffre, et un mineur à domicile peut commencer avec un seul SXNUMX pour quelques centaines de dollars. Pour être honnête, les frais d'entrée élevés de l'ETH ont un justification technique, car une mise plus élevée signifie moins de validateurs, ce qui réduit la bande passante.

Les frais de dépôt sont donc élevés, mais au moins quiconque possède 32 ETH est libre de rejoindre ou de quitter à tout moment, n'est-ce pas ? Pas assez. Il y a risques de sécurité si de grandes coalitions de validateurs devaient toutes entrer ou sortir en même temps. Par exemple, si la majorité du réseau partait en même temps, ils pourraient alors dépenser deux fois un bloc finalisé en rejouant un fork dans lequel ils ne sont jamais partis, sans se faire couper sur l'une ou l'autre des chaînes. Pour atténuer ce risque, les bretelles d'accès et de sortie ont une limite de débit intégrée. Actuellement ce limite est défini sur max(4,|V|/65536) validateurs par époque (toutes les 6.4 minutes), et est le même pour l'entrée et la sortie. Cela se traduit approximativement par un ensemble complet de validateurs tous les dix mois.

Soit dit en passant, même s'il est actuellement possible pour les validateurs de publier une transaction de "sortie" et d'arrêter la validation, le code pour retirer des fonds n'a même pas encore été écrit. Cela ressemble un peu à « Hotel California »…

Il y a un dernier point sur les incitations derrière l'approbation de nouveaux validateurs. Supposons que vous soyez actionnaire d'une grande entreprise stable versant des dividendes réguliers chaque trimestre. Serait-il judicieux de donner gratuitement de nouvelles actions ? Bien sûr que non, car cela diluerait les dividendes de tous les actionnaires existants. Une structure d'incitation similaire existe dans le PoS, puisque chaque nouveau validateur dilue les revenus de tous les validateurs existants.

En théorie, les validateurs pourraient simplement censurer chaque transaction qui ajoute un nouveau validateur ; cependant, dans la pratique, je pense qu'une telle approche brutale serait peu probable. Cela serait très perceptible et détruirait l'image de « décentralisation » d'Ethereum du jour au lendemain, faisant potentiellement chuter le prix. Je pense qu'une approche plus subtile serait utilisée à la place. Par exemple, les règles pourraient changer lentement au fil du temps, ce qui rendrait plus difficile de devenir un validateur, avec des excuses telles que la « sécurité » ou « l'efficacité ». Toute politique qui enrichit les validateurs existants au détriment des nouveaux validateurs aurait des vents favorables financiers, qu'ils soient prononcés à haute voix ou non. Nous pouvons commencer à voir pourquoi le PoS tendrait vers l'oligarchie.

Présentation de l'algorithme de Casper

Maintenant que nous connaissons la stratégie de haut niveau derrière le PoS, comment l'algorithme fonctionne-t-il réellement ? Les idées principales derrière les points de contrôle et le slashing ont été avancées dans un algorithme appelé Casper, nous allons donc commencer par là. Casper lui-même ne précise rien sur la façon de produire des blocs, mais fournit plutôt un cadre sur la façon de superposer une stratégie de point de contrôle/coupe au-dessus d'un arbre de blockchain déjà existant.

Tout d'abord, une constante arbitraire (C) est choisie pour être le nombre "d'espacement des points de contrôle", qui détermine le nombre de blocs qui se produisent entre les points de contrôle ; par exemple, si C = 100, les points de contrôle se produiraient aux blocs 0, 100, 200, etc. Ensuite, les nœuds votent tous sur le bloc de point de contrôle qui devrait être le prochain point de contrôle "justifié". Plutôt que de voter sur des blocs isolés, les validateurs votent en fait sur des paires de points de contrôle (s, t), qui relient certaines sources de points de contrôle précédemment justifiées "s" à un nouveau point de contrôle cible "t". Une fois qu'un lien de point de contrôle (s, t) obtient un vote à la majorité des deux tiers par enjeu, alors "t" devient un nouveau point de contrôle justifié. Le schéma ci-dessous montre un exemple d'arborescence de points de contrôle :

Dans ce diagramme, la fonction h(b) fait référence à la "hauteur du point de contrôle", par exemple, le multiple de 100 du bloc. Vous avez peut-être remarqué que chaque centième bloc n'est pas nécessairement justifié, ce qui peut arriver si le vote a échoué à un certain la taille. Par exemple, supposons qu'à la hauteur 200, deux points de contrôle distincts reçoivent chacun 50 % des voix. Étant donné que voter deux fois est une infraction slashable, le système resterait "bloqué" à moins que certains validateurs ne réduisent volontairement leur propre participation pour obtenir un vote aux deux tiers. La solution serait que tout le monde « saute » le point de contrôle 200 et « réessaye » au bloc 300.

Ce n'est pas parce qu'un point de contrôle est justifié qu'il est finalisé. Pour qu'un point de contrôle soit considéré comme finalisé, il doit être immédiatement suivi d'un autre point de contrôle justifié à la prochaine hauteur possible. Par exemple, si les points de contrôle 0, 200, 400, 500 et 700 étaient tous justifiés et reliés entre eux, seul le point de contrôle 400 compterait comme « finalisé », puisqu'il est le seul immédiatement suivi d'un autre point de contrôle justifié.

Parce que la terminologie est très précise, récapitulons nos trois catégories. Un "point de contrôle" est tout bloc qui se produit à la hauteur C*n, donc si C=100, chaque bloc avec une hauteur de 0, 100, 200, 300, etc. serait tous des points de contrôle. Même si plusieurs blocs étaient créés à la hauteur 200, ils seraient tous les deux des "points de contrôle". Un point de contrôle est alors "justifié" s'il s'agit soit du bloc racine à hauteur 0, soit si les deux tiers des validateurs ont voté pour créer un lien entre un point de contrôle précédemment justifié et le point de contrôle courant. Un point de contrôle justifié est alors "finalisé" s'il est ensuite lié à un autre point de contrôle justifié à la prochaine hauteur possible. Tous les points de contrôle ne deviennent pas nécessairement justifiés et tous les points de contrôle justifiés ne sont pas nécessairement finalisés, même dans la chaîne finale.

Règles de coupe de Casper

Les règles de slashing dans Casper sont conçues de telle sorte qu'il est impossible que deux points de contrôle finalisés existent dans deux forks distincts, à moins qu'au moins un tiers des validateurs n'aient enfreint les règles de slashing.

En d'autres termes, seuls les points de contrôle finalisés devraient être comptés comme des blocs de « vérité » sans ambiguïté. Il est même possible que deux points de contrôle justifiés se produisent des deux côtés d'une fourche, mais pas deux points de contrôle finalisés. Il n'y a également aucune garantie quant au moment ou à l'endroit où le prochain point de contrôle finalisé se produira, juste que si une scission de chaîne devait se produire, alors vous devriez vous asseoir et attendre qu'un bloc finalisé apparaisse quelque part, et une fois que c'est le cas, vous savez que c'est le " chaîne correcte ».

Il existe deux règles de slashing dans Casper qui appliquent cette propriété :

La première règle interdit à quiconque de voter deux fois sur des points de contrôle avec la même hauteur cible, donc si un validateur votait pour deux blocs de points de contrôle différents avec une hauteur cible de 200, ce serait une infraction slashable. Le but de cette règle est d'empêcher la chaîne de se scinder en deux points de contrôle justifiés différents avec la même hauteur, car cela nécessiterait 2/3 + 2/3 = 4/3 du total des votes du validateur, ce qui implique qu'au moins un tiers des validateurs ont enfreint les règles de slashing. Cependant, comme nous l'avons vu précédemment, il est possible que des points de contrôle justifiés « sautent » certaines hauteurs de bloc. Qu'est-ce qui empêche une chaîne de se diviser en différentes hauteurs cibles ? Par exemple, le point de contrôle 200 ne pourrait-il pas bifurquer vers des points de contrôle justifiés à 300 et 400 sans que personne ne soit sabré ?

C'est là qu'intervient la deuxième règle, qui empêche essentiellement les validateurs de « prendre en sandwich » les votes dans d'autres votes. Par exemple, si un validateur votait à la fois pour 300→500 et 200→700, ce serait une infraction slashable. Dans le cas d'une scission de chaîne, une fois qu'une branche voit un point de contrôle finalisé, il devient impossible pour l'autre branche de voir un point de contrôle justifié par la suite à moins qu'au moins un tiers des validateurs n'aient enfreint la règle n°2.

Pour comprendre pourquoi, supposons que la blockchain soit divisée en points de contrôle justifiés 500 → 800 et 500 → 900, puis à un moment donné, la première chaîne a vu un point de contrôle finalisé avec le lien 1700 → 1800. Étant donné que 1700 et 1800 ne peuvent être justifiés que sur la fourche n°1 (en supposant que personne n'a enfreint la première règle de coupe), la seule façon pour la fourche n°2 de voir un point de contrôle justifié après 1800 est s'il y avait un lien voté entre les hauteurs H1800. Mais puisque ce vote « prendrait en sandwich » le lien 1700→1800 et nécessiterait un vote des deux tiers, et que le 1700→1800 déjà adopté avec un vote des deux tiers, alors au moins un tiers des validateurs devraient enfreindre la règle # 2. L'article de Casper contient un joli diagramme démontrant cette propriété :

Et c'est tout, il suffit de suivre les règles de Casper et c'est bon !

Cela semble assez simple, non ? Je suis sûr que PoS n'utiliserait jamais le slash qu'en dernier recours absolu pour maintenir le consensus, et non comme un mécanisme d'extorsion pour faire pression sur les validateurs pour qu'ils se comportent d'une certaine manière… n'est-ce pas ?

Cela nous amène à notre troisième principe derrière le PoS : il n'y a pas de règles. Les "règles" sont ce que tout le monde dit qu'elles sont.

Un jour, votre nœud pourrait techniquement suivre à la lettre tous les commandements de Casper, et le lendemain, vos économies pourraient être réduites parce que vous faisiez quelque chose que tout le monde n'aimait pas. Approuvé une transaction « équipe rouge » cette fois-là ? Demain, la majorité « équipe bleue » pourrait vous réduire à néant. Ou peut-être avez-vous fait le contraire et omis trop de transactions « équipe rouge » ? Demain, la majorité de «l'équipe rouge» pourrait vous frapper pour censure. La capacité de réduire va bien au-delà de la portée limitée de la censure de l'OFAC (Office of Foreign Assets Control). PoS est comme une impasse mexicaine sans escale, où la menace implicite de sabrer est omniprésente à tout moment.

Je ne serais pas surpris si, dans un hard fork litigieux, les deux parties codaient en dur les règles de validation de l'autre fork, juste au cas où elles voudraient punir quiconque a rejoint le «mauvais» côté. Bien sûr, ce serait une option nucléaire, et comme pour les armes nucléaires, chaque camp pourrait choisir de frapper uniquement en représailles. Je suppose que la plupart des validateurs individuels sont neutres en ce sens qu'ils donneraient la priorité à l'auto-préservation financière par rapport à l'abnégation politique, mais pourraient extérieurement prendre parti s'ils sentaient que c'était la bonne décision pour éviter d'être sabré.

Quelle heure est-il?

Maintenant que nous connaissons les bases des points de contrôle et des coupures, nous pouvons passer à l'algorithme réel utilisé dans Ethereum, appelé Gasper. Il s'agit d'un portemanteau de Casper, que nous avons déjà couvert, et de GHOST, une stratégie pour sélectionner la "meilleure" chaîne de blocs entre les points de contrôle.

La première chose à comprendre à propos de Gasper est que le temps lui-même est la principale variable indépendante. Le temps réel est divisé en unités de douze secondes appelées « tranches », où chaque tranche contient au plus un bloc. Ces créneaux forment alors des groupes plus importants appelés « époques », où chaque époque fait référence à un point de contrôle. Chaque époque contient 32 emplacements, ce qui leur donne une durée de 6.4 minutes.

Il convient de noter que ce paradigme inverse la relation causale entre le temps et la production de blocs par rapport au PoW. Dans PoW, les blocs sont produits parce qu'un hachage valide a été trouvé, et non parce que suffisamment de temps s'est écoulé. Mais dans Gasper, les blocs sont produits parce que suffisamment de temps réel s'est écoulé pour passer au créneau suivant. Je ne peux qu'imaginer les bogues de synchronisation délicats qu'un tel système peut rencontrer, en particulier lorsqu'il ne s'agit pas d'un seul programme exécuté sur un ordinateur, mais de dizaines de milliers d'ordinateurs essayant de fonctionner de manière synchronisée dans le monde entier. Espérons que les développeurs d'Ethereum connaissent le mensonges que les programmeurs croient à propos du temps.

Supposons maintenant que vous démarriez un nœud de validation et que vous synchronisiez la blockchain pour la première fois. Juste parce que vous avez observé que certains blocs faisaient référence à certains horodatages, comment pourriez-vous être sûr que ces blocs ont vraiment été produits à ces moments ? Étant donné que la production de blocs ne nécessite aucun travail, un groupe de validateurs malveillants ne pourrait-il pas simuler une blockchain entièrement fausse dès le premier jour ? Et si vous voyiez deux blockchains concurrentes, comment sauriez-vous laquelle est vraie ?

Cela nous amène à notre quatrième principe derrière le PoS, à savoir que le PoS repose sur la vérité subjective.

Il n’existe tout simplement aucun moyen objectif de choisir entre deux blockchains concurrentes, et tout nouveau nœud du réseau doit en fin de compte faire confiance à une source de vérité existante pour résoudre toute ambiguïté. Cela contraste considérablement avec Bitcoin, où la « vraie » chaîne est toujours celle qui demande le plus de travail. Peu importe si un millier de nœuds vous indiquent la chaîne X, si un seul nœud diffuse la chaîne Y et qu'il contient plus de travail, alors Y est la bonne blockchain. L'en-tête d'un bloc peut prouver sa propre valeur, éliminant complètement le besoin de confiance.

En s'appuyant sur la vérité subjective, le PoS réintroduit le besoin de confiance. Maintenant, j'admets que je suis peut-être un peu partial, donc si vous voulez lire l'autre côté, Buterin a écrit un essai contenant son point de vue ici. J'admets qu'en pratique, une scission de chaîne ne semble pas très probable étant donné les règles de Casper, mais quoi qu'il en soit, j'ai une certaine tranquillité d'esprit en sachant que ce n'est même pas une possibilité dans Bitcoin.

Bloquer la production et le vote

Maintenant que nous connaissons les créneaux horaires et les époques, comment les blocs individuels sont-ils produits et votés ? Au début de chaque époque, l'ensemble complet de validateurs est divisé "au hasard" en 32 groupes, un pour chaque emplacement. Au cours de chaque créneau, un validateur est choisi "au hasard" pour être le producteur du bloc, tandis que les autres sont choisis pour être les votants (ou "attestateurs"). Je mets "au hasard" entre guillemets parce que le processus doit être déterministe, puisque tout le monde doit être d'accord sans ambiguïté sur les mêmes ensembles de validateurs. Cependant, ce processus doit également être non exploitable, car être le producteur de blocs est une position hautement privilégiée en raison des récompenses supplémentaires disponibles à partir de la valeur extractible du mineur (MEV), ou comme il est renommé, "valeur extractible maximale". "Ethereum est une forêt sombre” est une excellente lecture à ce sujet.

Une fois qu'un bloc est produit, comment les autres validateurs votent-ils ou « l'attestent-ils » ? La proposition de bloc est censée se produire dans la première moitié (six secondes) d'un créneau et attester dans la seconde moitié, donc en théorie, il devrait y avoir suffisamment de temps pour que les attestateurs votent sur le bloc de leur créneau. Mais que se passe-t-il si le proposant du bloc est hors ligne ou ne parvient pas à communiquer ou s'appuie sur un mauvais bloc ? Le travail d'un attestateur n'est pas nécessairement de voter sur le bloc de cet emplacement, mais plutôt sur le bloc qui « semble le mieux » de son point de vue à ce moment-là. Dans des conditions normales, il s'agira généralement du bloc de cet emplacement, mais il peut également s'agir d'un bloc plus ancien en cas de problème. Mais que signifie « avoir l'air la meilleure » techniquement ? C'est là qu'intervient l'algorithme GHOST.

GHOST signifie "Greediest Heaviest Observed SubTree" et est un algorithme récursif gourmand pour trouver le bloc avec la plus "activité récente". Fondamentalement, cet algorithme examine tous les blocs récents sous la forme d'un arbre et parcourt l'arbre en sélectionnant avidement la branche avec les attestations les plus cumulatives sur l'ensemble de cette sous-branche. Seule l'attestation la plus récente de chaque validateur compte dans cette somme, et finalement ce processus atterrit sur un bloc feuille.

Les attestations ne sont pas seulement des votes pour le meilleur bloc actuel, mais aussi pour le point de contrôle le plus récent qui mène à ce bloc. Il convient de noter à Gasper que les points de contrôle sont basés sur des époques plutôt que sur des hauteurs de bloc. Chaque époque fait référence à exactement un bloc de point de contrôle, qui est soit le bloc du premier emplacement de cette époque, soit, si cet emplacement a été ignoré, le bloc le plus récent avant cet emplacement. Le même bloc peut théoriquement être un point de contrôle à deux époques différentes si une époque a en quelque sorte ignoré chaque emplacement, de sorte que les points de contrôle sont représentés à l'aide de paires (époque, bloc). Dans le diagramme ci-dessous, EBB signifie "bloc de frontière d'époque" et représente le point de contrôle pour une époque spécifique, tandis que "LEBB" signifie "bloc de frontière de dernière époque" et représente le point de contrôle le plus récent dans l'ensemble.

Semblable à Casper, un point de contrôle devient justifié une fois que le nombre total d'attestations dépasse le seuil des deux tiers, et finalisé s'il a été immédiatement suivi d'un autre point de contrôle justifié à l'époque suivante. Un exemple du fonctionnement de ce vote est illustré ci-dessous :

Il existe deux conditions de coupure à Gasper, qui sont analogues aux règles de coupure de Casper :

  1. Pas de vote deux fois à la même époque.
  2. Aucun vote ne peut contenir des points de contrôle d'époque qui « prennent en sandwich » les points de contrôle d'époque d'un autre vote.

Bien qu'elles soient basées sur des époques plutôt que sur des hauteurs de bloc, les règles de Casper garantissent toujours qu'aucun point de contrôle finalisé ne peut se produire sur des chaînes différentes à moins qu'un tiers des validateurs ne puisse être réduit.

Il convient également de noter que les attestations sont incluses dans les blocs eux-mêmes. Semblable à la façon dont un bloc dans PoW se justifie en utilisant son hachage, un point de contrôle finalisé dans PoS se justifie en utilisant toutes ses attestations passées. Quand quelqu'un enfreint les règles de slashing, ces mauvaises attestations sont incluses dans un bloc qui prouve la violation. Il y a aussi une petite récompense pour le producteur de blocs qui a inclus la violation, afin d'inciter à punir les contrevenants.

Forks

Il est intéressant de penser à ce qui se passerait dans le cas d'un fork. Pour récapituler rapidement, un fork fait référence à un changement dans les règles de consensus, et ils se déclinent en deux variétés : hard forks et soft forks. Dans un hard fork, les nouvelles règles ne sont pas rétrocompatibles, ce qui peut entraîner deux blockchains concurrentes si tout le monde ne bascule pas. Dans un soft fork, les nouvelles règles sont plus restrictives que les anciennes règles, tout en les gardant rétrocompatibles. Une fois que plus de 50 % des mineurs ou des validateurs commencent à appliquer les nouvelles règles, le mécanisme de consensus bascule sans diviser la chaîne. Les soft forks sont généralement associés à des mises à niveau et à de nouveaux types de transactions, mais ils incluent également techniquement tout type de censure appliquée par une majorité de 51 %. PoS a également un troisième type de "fork" qui n'est pas présent dans PoW : une chaîne scindée sans aucune modification des règles. Mais puisque nous avons déjà couvert cela, nous nous concentrerons sur les fourches dures et souples.

Commençons par le cas le plus simple : un hard fork contentieux autonome. Par controversé, j’entends un changement de règle qui divise politiquement les utilisateurs. Une correction de bug ou une modification technique mineure ne serait probablement pas controversée, mais quelque chose comme la modification de la récompense de validation le serait probablement. Si un hard fork était suffisamment controversé, il pourrait entraîner une scission de la chaîne et serait résolu économiquement par les utilisateurs vendant une chaîne et achetant l'autre. Cela serait similaire à la scission de Bitcoin Cash en 2017, qui semble avoir un gagnant clair :

Supposons maintenant que les validateurs soient assis un jour et décident qu'ils ne sont pas assez payés, et décident qu'ils devraient augmenter leurs récompenses de 5% par an à 10% par an. Ce serait un compromis clair en faveur des validateurs au détriment des non-validateurs qui seraient désormais de plus en plus dilués. En cas de scission de la chaîne, quelle chaîne gagnerait ?

Cela nous amène à notre cinquième principe de PoS, à savoir que l'argent, c'est le pouvoir.

Sur les 120 millions d'ETH existants, plus de 10 % sont actuellement jalonnés, comme le montre le tableau ci-dessous :

Étant donné un hard fork controversé entre les validateurs et les non-validateurs, en supposant que tous les non-validateurs ont vendu la nouvelle chaîne et tous les validateurs ont vendu l'ancienne chaîne, alors en théorie l'ancienne chaîne gagnerait, puisque la majorité des L'ETH serait toujours détenue par les non-validateurs (90% contre 10%). Mais il y a quelques autres choses à considérer. Premièrement, après toute scission de la chaîne, les validateurs seraient toujours « aux commandes » des deux chaînes de blocs. Si les validateurs étaient capables d'influencer l'autre chaîne, ils pourraient être incités à la faire échouer. Deuxièmement, il y a aussi l'option nucléaire discutée plus tôt, selon laquelle la nouvelle chaîne pourrait réduire à néant toute personne validant encore l'ancienne chaîne pour la forcer à la rejoindre. Enfin, les validateurs exerceraient probablement une influence sociale et politique significative sur tous les autres membres du réseau. Si Buterin, la Fondation Ethereum et les échanges ont tous décidé à l'unisson d'augmenter la récompense de mise, j'ai du mal à croire que les utilisateurs et les validateurs réguliers d'Ethereum pourraient maintenir l'ancienne fourche tout en la rendant plus précieuse grâce à la pression d'achat.

Passons aux soft forks, que se passerait-il dans un soft fork controversé, comme la censure de l'OFAC ? Les validateurs sont assez centralisés, comme on peut le voir dans le tableau ci-dessous :

Contrairement au PoW où les mineurs peuvent changer de pool en appuyant sur un bouton, les validateurs d'Ethereum sont verrouillés dans une adresse de jalonnement jusqu'à ce qu'ils traitent une transaction de sortie. Si Lido et les principaux échanges étaient amenés à censurer certaines transactions, ils pourraient facilement passer la majorité des deux tiers nécessaire pour décider des points de contrôle. Plus tôt, nous avons vu comment Buterin et les autres validateurs de l'ETH pouvaient essayer de contrer un soft fork de censure avec leur propre hard fork de contre-censure, tout en réduisant les censeurs dans le processus. Même s'ils réussissaient à créer un fork, beaucoup de valeur serait détruite dans le processus, à la fois par le slash et par une perte de confiance.

Réflexions de clôture

Dans cet essai, nous avons examiné comment PoS résout le problème de la double dépense avec Gasper, une combinaison de règles de point de contrôle/coupure appelée Casper et une règle de vote du « meilleur bloc » appelée GHOST. Pour récapituler, Gasper divise le temps en unités appelées créneaux, où chaque créneau peut avoir au plus un bloc, et les créneaux sont regroupés en époques, où chaque époque fait référence à un point de contrôle. Si une majorité des deux tiers vote sur un point de contrôle, il devient justifié, et si deux points de contrôle justifiés se produisent à la suite, le premier de ces deux points de contrôle devient finalisé. Une fois qu'un point de contrôle est finalisé, il devient impossible pour une chaîne parallèle d'être finalisée, à moins qu'un tiers des validateurs ne soit amputé.

Dans ce processus, nous avons découvert cinq principes de PoS :

  1. PoS utilise une structure d'incitation négative (basée sur des pénalités).
  2. PoS est un système autorisé.
  3. PoS n'a pas de règles.
  4. PoS repose sur une vérité subjective.
  5. Dans PoS, l’argent, c’est le pouvoir.

Chacun de ces principes a un comportement opposé dans PoW :

  1. PoW utilise un système d'incitation positif (basé sur les récompenses).
  2. PoW est un système sans autorisation (n'importe qui peut démarrer ou arrêter le minage à tout moment).
  3. Dans PoW, les forks qui modifient les règles sont ignorés.
  4. PoW repose sur une vérité objective.
  5. Dans PoW, les mineurs sont au service des utilisateurs et ont eux-mêmes peu de pouvoir.

Je crois que tout le monde devrait s'efforcer de créer le genre de monde dans lequel il veut vivre. Si, comme moi, vous voulez vivre dans un monde sans permission où vous pouvez avoir le contrôle de votre argent, où le travail acharné est récompensé et où la propriété passive est un responsabilité et où votre argent conservera sa valeur longtemps dans le futur sans changer sur un coup de tête, alors vous voudrez peut-être réfléchir attentivement aux compromis entre PoW et PoS, et vous battre en faveur des principes selon lesquels vous voulez vivre.

Ceci est un article invité de Scott Sullivan. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc. ou de Bitcoin Magazine.

spot_img

Dernières informations

spot_img

Discutez avec nous

Salut! Comment puis-je t'aider?