Validé : introduction à la preuve d’enjeu sur eth2

Alors que le lancement de Beacon Chain se rapproche et que celui d’eth2 est de plus en plus imminent, le temps est venu de mettre à niveau rapidement la communauté sur les dernières informations concernant le fonctionnement de eth2 et sur les responsabilités, les incitations et l’expérience d’un validateur. 

Cet article fournit une vue d’ensemble de haut niveau d’eth2 et constituera la base d’une série d’articles sur tous les aspects pertinents d’eth2 pour les validateurs. Il est une traduction intégrale de cet article initialement publié sur le site de la Fondation par Carl Beekhuizen, réalisé par Simon Polrot et Jérôme de Tychey 

eth2 est en préparation depuis longtemps et s’est considérablement amélioré au fil des ans. Ce qui était à l’origine deux initiatives distinctes avec la preuve d’enjeu (proof of stake), d’une part, et la fragmentation (sharding) gérés au moyen de contrats autonomes (smart-contracts), d’autre part, s’est métamorphosé en une construction hautement interconnectée qui permet d’améliorer considérablement l’efficacité, l’évolutivité et la sécurité de l’ensemble.

Les phases

Alors que certaines parties sont devenues de plus en plus interconnectées, d’autres parties ont été séparées en phases afin de permettre un meilleur traitement en parallèle des différents aspects de eth2. Au moment de la rédaction de cet article, la phase 0 est sur le point de démarrer, les développeurs apportent en ce moment la touche finale au logiciel client. En parallèle, les spécifications de la phase 1 sont en cours d’achèvement et la phase 2 est en pleine phase de recherche et développement.

• La phase 0 est le lancement de la chaîne-balise (Beacon Chain), le noyau d’eth2, qui gère les validateurs et la coordination des fragments (shards). La beacon chain est la source de vérité à partir de laquelle tous les autres aspects de eth2 sont créés.
• La phase 1 s’appuie sur la phase 0 en permettant aux données de la chaîne d’être structurée en fragments. La complexité de mise en œuvre de cette phase sera beaucoup plus faible que les autres, car l’essentiel du travail préparatoire de la fragmentation est effectué dans la phase 0.
• La phase 2 ajoute le moteur d’exécution à eth2 en permettant à eth2 de passer d’une base de données robuste à une véritable plate-forme d’exécution entièrement décentralisée.

En quoi consiste exactement la phase 0 ?

La chaîne-balise va suivre et vérifier l’état de l’ensemble des validateurs et des fragments. En pratique, cela signifie que si vous suivez (périodiquement) ce qui se passe sur cette chaîne, vous en saurez assez pour vérifier tout ce qui se passe dans eth2. Comme le dit la maxime « don’t trust, but verify » (ne faites pas confiance, vérifiez).

Comme déjà établi dans la FAQ, pour qu’un système de preuve d’enjeu fonctionne, il faut un consensus sur l’identité des validateurs et sur leurs mises en gage respectives afin de connaître la valeur de leurs votes et de les récompenser et/ou les punir de manière appropriée pour leur comportement. La beacon chain gère également une partie des aspects techniques de la fragmentation de eth2 en attribuant des tâches de validation aux fragments ainsi qu’en suivant et vérifiant en temps quasi-réel l’état de chaque fragment.

Une partie de ce qui différencie eth2 des autres systèmes de preuve d’enjeu est le grand nombre de validateurs pouvant participer au protocole. Contrairement aux 10, 100 et 1000 participants possibles dans d’autres systèmes, eth2 peut atteindre des centaines de milliers, voire des millions de validateurs. Ce niveau de décentralisation n’est possible que grâce aux niveaux de consensus intermédiaires atteints par des groupes de validateurs appelés comités. La chaîne-balise utilise une « random beacon » (balise aléatoire) au plus profond du protocole pour assigner des valideurs aux comités chargés d’évaluer ce qui doit ou non être ajouté à la beacon chain et aux fragments. Les votes d’un comité sont ensuite agrégés cryptographiquement en une attestation. Cela signifie que la vérification des votes d’un comité entier ne représente qu’un effort légèrement plus important que la vérification d’un seul vote. Par conséquent, pour vérifier la validité de la chaîne-balise, seules quelques signatures agrégées doivent être récupérées pour évaluer les votes de nombreux validateurs.

La chaîne-balise suit également la chaîne eth1 et les dépôts réalisés sur celle-ci, afin que les nouveaux validateurs puissent rejoindre eth2 en envoyant 32 Ethers au contrat de dépôt sur eth1. Puisque, pour ce faire, la chaîne-balise vote sur l’état de la chaîne eth1, il est prévu qu’eth2 renforcera, à terme, la sécurité de eth1 en offrant une garantie économique que les blocs faisant partie de la chaîne eth1 sont canoniques (et ne pourront plus être modifiés).

Noeuds vs. Clients

Eth2 fait la distinction entre les noeuds de la chaîne-balise (un noeud-balise) et les clients du validateur. Les validateurs auront besoin des deux pour s’acquitter de leurs tâches. Un noeud-balise (ou juste un nœud) doit conserver une vue de la chaîne-balise ainsi que des fragments dont un utilisateur ou un validateur pourrait avoir besoin.

Un client-validateur (ou plus simplement « un client ») ne peut gérer la logique que d’un seul validateur. Il réalise cette opération en communiquant avec le noeud pour récupérer l’état actuel de la chaîne, en attestant, en proposant des blocs, le cas échéant, et en demandant au nœud de transmettre ces informations à ses pairs.

Si vous n’exécutez pas de validateur, un nœud contient toutes les informations dont vous avez besoin pour interagir avec eth2 de façon « trustless », sans faire confiance à un tiers, un peu comme un nœud complet dans eth1.

Voici quelques-uns des nombreux arguments en faveur de cette séparation entre noeud et validateur :

• Chaque validateur doit être initialisé avec un dépôt d’exactement 32 ETH. Par conséquent, les personnes qui souhaitent mettre en jeu davantage d’ETH devront instancier plusieurs validateurs. La séparation nœud-client permet à ces utilisateurs de n’exécuter qu’un seul nœud-balise auquel plusieurs validateurs sont connectés, réduisant ainsi les besoins en calcul, en mémoire et en stockage.
• Si les nœuds de validation sont des modules distincts, ils seront probablement plus sûrs, car il est plus facile d’écrire, de comprendre et d’auditer des morceaux de code plus petits.
• Pour les utilisateurs particulièrement préoccupés par la redondance, plusieurs nœuds peuvent être exécutés en parallèle, ce qui réduit les chances qu’un validateur soit déconnecté.
• Les clients validateurs ne pouvant interagir avec le reste du réseau eth2 que via un nœud-balise, et même dans ce cas via une API restreinte, la surface d’attaque d’un validateur est considérablement réduite.
• Les utilisateurs qui souhaitent interagir avec eth2, mais ne veulent pas être un validateur devront uniquement disposer d’un nœud-balise qui leur donnera accès à la beacon chain et à tous les fragments dont ils ont besoin.

Philosophie de conception

La philosophie de conception de eth2 donne des éléments de contexte utiles sur toutes les décisions prises et, dans de nombreux cas, met en lumière les différences entre eth2 et les autres protocoles.

• Protocol über alles : en admettant qu’il faille faire des compromis, la sécurité et la vivacité (« liveness ») du protocole doivent primer sur les autres besoins dans la conception.
• Espérer le meilleur, mais s’attendre au pire : eth2 part du principe  que les validateurs seront paresseux, prendront des pots-de-vin et tenteront d’attaquer le système à moins qu’ils ne soient incités à ne pas le faire. De plus, le réseau est supposé ne pas être entièrement fiable et des événements catastrophiques pourraient forcer un grand nombre de validateurs à passer hors ligne. Pour ces raisons, eth2 devrait être capable de survivre à la troisième guerre mondiale.
• Minimum Viable Complexity (complexité minimum en restant viable) : eth2 a été simplifié dans la mesure du possible, car la simplicité permet de raisonner, d’expliquer et d’auditer plus facilement mais aussi d’écrire des clients exempts de bogues et d’éviter généralement les problèmes non-prévus.
• Décentralisation maximale : les protocoles de preuve d’enjeu font généralement des compromis sur le nombre de validateurs pouvant participer. Eth2 est conçu pour s’adapter à des millions de validateurs tout en encourageant ces validateurs à travailler indépendamment les uns des autres.
• S’attendre à l’inattendu : tous les composants de eth2 sont résistants aux ordinateurs quantiques ou peuvent être changés pour ceux qui le sont dans le cas d’une apocalypse quantique.
• Par le peuple pour le peuple : eth2 doit pouvoir fonctionner sur un ordinateur portable grand public. Plus la barrière à l’entrée est basse, plus le nombre de personnes pouvant participer est important, ce qui se traduit par un degré de décentralisation accru.

Conclusion

Maintenant que vous comprenez les bases de eth2, les prochains articles de cette série traiteront des détails de ce qui fait que eth2 marche.