1.X Files : L’arbre des technologies d’un Ethereum sans état

Article de Griffin Ichiba Hotchkiss sur blog.ethereum.org, traduit par Jean Zundel

Alors que les travaux se poursuivent sur ETH 2.0, la chaîne originelle continue de tourner en production. Elle doit être optimisée pour le proche avenir, et préparée pour la transition vers Casper et le sharding. C’est pourquoi Ethereum 1.X constitue l’un des projets les plus importants de l’écosystème ; c’est aussi l’un des moins connus et des moins bien compris. Cet article, premier d’une série, fait le point sur les enjeux et les axes de recherche, et présente les solutions actuellement envisagées… qui bien entendu évolueront rapidement.

J’avais commencé à écrire un article détaillant une « roadmap » pour la recherche sur Ethereum 1.x, et le chemin menant à un Stateless Ethereum, un Ethereum sans état, quand il m’est apparu qu’en fait il ne s’agit pas du tout d’une roadmap ; du moins pas dans le sens habituellement employé pour un produit ou une société. L’équipe 1.X, bien qu’elle travaille à un objectif commun, reste une association éclectique de développeurs et de chercheurs qui s’attaquent de manière indépendante à des sujets étroitement imbriqués. En conséquence, il n’existe pas de roadmap « officielle » à proprement parler. Ce n’est pas non plus le chaos total ! Il existe un « ordre des opérations » bien compris ; certaines choses doivent se produire avant d’autres, certaines solutions sont mutuellement exclusives, et d’autres travaux peuvent s’avérer bénéfiques sans être essentiels.

Quelle meilleure métaphore qu’une roadmap, donc, pour la manière d’arriver à un Ethereum sans état ? Il m’a fallu un certain temps, mais je pense que j’en tiens une préférable : Stateless Ethereum est le trophée de platine dans un arbre des technologies.

Certains lecteurs comprendront immédiatement cette analogie. Si c’est votre cas, vous pouvez sauter les quelques paragraphes qui suivent. Mais si vous n’êtes pas comme moi, si vous ne pensez pas le monde en termes de jeux vidéo, voici l’explication : un arbre des technologies est un mécanisme courant dans les jeux, permettant aux joueurs de débloquer et d’améliorer de nouveaux sorts, de nouvelles technologies et de nouvelles compétences, ordonnés selon une hiérarchie fluide, une structure arborescente.

On acquiert généralement de l’XP, des points d’expérience, sous une forme ou sous une autre, lesquels peuvent être « dépensés » pour acquérir des éléments dans l’arbre, qui à leur tour débloquent des éléments plus avancés. Il faut parfois acquérir deux éléments sans relation entre eux pour accéder à un troisième ; parfois, le déblocage d’une compétence de base ouvre plusieurs choix possibles pour l’amélioration suivante. Une grande partie de l’attrait d’un jeu réside dans les choix possibles dans l’arborescence, où il faut choisir ce qui correspond le mieux à ses capacités, à ses buts et à ses préférences (voulez-vous atteindre le maximum de capacités en tant que Guerrier, Brigand ou Mage ?).

C’est, de manière étonnamment exacte, ce que nous voyons dans le labo 1.X : une hiérarchie fluide de sujets techniques sur lesquels il faut travailler, avec des limites en temps et en expertise à investir en recherche, en mise en œuvre et en tests. Comme dans tout bon RPG, les points d’expérience sont finis : une poignée d’humains compétents et motivés ne peut accomplir qu’un certain nombre de tâches en une année ou deux. Selon les priorités, il peut être sage de geler des améliorations plus ambitieuses ou abstraites en faveur d’un chemin plus direct vers les spécifications finales. Tout le monde vise le même but, mais le chemin à prendre dépendra des solutions qui seront totalement étudiées et employées.

Je vais donc présenter un schéma approximatif de l’arbre, expliquer un peu la façon dont il est arrangé, puis exposer brièvement chaque amélioration et la manière dont elle est reliée à l’ensemble. On a « platiné » l’arbre des technologies en arrivant à un « Ethereum sans état ». Cela signifie un mainnet Ethereum totalement fonctionnel, qui supporte des nœuds à état complet, à état partiel et sans état ; qui transfère de manière efficiente et fiable les informations de signatures témoins et d’état ; et en principe prêt à continuer à croître jusqu’à ce que le pont vers Eth2.0 soit prêt à embarquer la chaîne d’origine.

N.B.: Comme je viens de le dire, ce n’est pas un plan de travail « officiel », mais un effort personnel de collecte et d’organisation des fonctionnalités, des étapes et des décisions principales que le groupe de travail 1x doit décider afin de faire de Stateless Ethereum une réalité. Les retours sont les bienvenus, et des versions mises à jour/révisées de ce plan seront inévitables tant que la recherche se poursuit.

Il faut lire ce diagramme de gauche à droite : les éléments en violet sur la gauche sont « fondamentaux » et demandent un développement ou une prise de décision avant de passer aux améliorations ultérieures plus à droite. Les éléments colorés en cyan indiquent que ce sont en quelque sorte des items de « bonus », souhaitables sans être nécessaires à la transition, et ils sont peut-être moins bien compris dans le cadre de la recherche. Les quatre étapes majeures doivent être « débloquées » avant de pouvoir déclencher une transition en masse vers Stateless Ethereum.

Le format des signatures témoins

On a beaucoup parlé des witnesses, des signatures témoins, dans le contexte d’un Ethereum sans état, et il ne devrait donc surprendre personne que la première étape que je mettrai en avant est un format de signature finalisé. Il faut donc décider une fois pour toute de la structure du trie d’état et des signatures témoins l’accompagnant. La création d’une spécification ou d’une implémentation de référence peut être vue comme le point à partir duquel la recherche sur ETH 1.X « passe un niveau » ; le consensus autour d’une nouvelle représentation de l’état aidera à définir où concentrer les travaux nécessaires pour accéder aux nouvelles étapes.

Trie binaire (ou « trie, trie again »)

Le basculement de l’état d’Ethereum en une structure de Trie Binaire est essentiel pour obtenir des tailles de signatures assez petites pour être diffusées dans le réseau sans rencontrer de problème de bande passante ou de latence. Comme cela a été souligné au cours du dernier research call, le passage au Trie Binaire demande de ne s’employer qu’à une stratégie parmi deux mutuellement exclusives :

• Progressive. Comme le bateau de Thésée, le trie d’état sénaire (hexary) actuel serait transformé petit à petit sur une longue période de temps. Toute transaction, toute exécution de l’EVM touchant une partie de l’état encoderait de ce fait automatiquement les changements d’état dans la nouvelle forme binaire. Cela implique l’adoption d’une structure de trie « hybride » laissant en dormance certaines parties de l’état dans leur représentation sénaire actuelle. Le processus ne serait dans les faits jamais terminé, et serait complexe à implémenter pour les développeurs des clients, mais isolerait pour la plus grande partie les utilisateurs et les développeurs des couches de haut niveau des changements affectant la couche 0.
• En masse. Peut-être plus en phase avec l’importance du changement du trie sous-jacent, une transition en masse définirait une chronologie de transition passant par plusieurs hard forks, en calculant une nouvelle représentation de l’arbre binaire à ce moment, puis en continuant sous forme binaire une fois le nouvel état calculé. Plus simple du point de vue de l’implémentation, un big bang requerrait la coordination de tous les opérateurs de nœuds, et engendrerait certainement une forme (limitée) de perturbation du réseau en affectant l’expérience utilisateur et celle des développeurs pendant cette transition. D’un autre côté, ce processus pourrait fournir des informations précieuses concernant la transition, plus lointaine, vers Eth2.

Quelle que soit la stratégie de transition choisie, un trie binaire devient la base de la structure des signatures témoins, c’est-à-dire l’ordre et la hiérarchie des hashes, des empreintes du trie d’état. Sans optimisation supplémentaire, un calcul approximatif (janvier 2020) baisse la taille des signatures témoins dans un intervalle de ~300 Ko à ~1400 Ko, en partant de ~800 Ko à ~3400 Ko avec la structure de trie sénaire.

Segmentation de code (merklisation)

L’un des principaux composants d’un witness, d’une signature, est le code qui l’accompagne. Sans segmentation, une transaction contenant un appel de contrat demanderait le bytecode complet de ce contrat afin de vérifier son codeHash, ce qui pourrait se monter à énormément de données, selon le contrat. La « merklisation » du code est une méthode de séparation du bytecode du contrat afin que seule la portion du code appelé soit requise pour générer et vérifier la signature de la transaction. Cette technique réduit énormément la taille moyenne de la signature. Il existe deux manières de séparer le code de contrat, et pour l’instant il n’est pas clair qu’elles soient mutuellement exclusives.

• Segmentation « statique ». Éclatement du code d’un contrat en morceaux de taille fixe, de l’ordre de 32 octets. Pour que le code merklisé tourne correctement, les segments statiques doivent également comprendre des méta-données.
• Segmentation « dynamique ». Éclatement du code d’un contrat selon le contenu du code lui-même, en coupant sur des instructions spécifiques (JUMPDEST) qu’il contient.

À première vue, l’approche « statique » de la segmentation du code semble préférable pour éviter des abstractions poreuses (leaky), c’est-à-dire pour empêcher le contenu du code merklisé d’affecter la segmentation de bas niveau, comme cela pourrait se produire dans le cas « dynamique ». Cela dit, les deux options doivent encore être testées de façon exhaustive et restent donc toutes les deux d’actualité.

Compression ZK des signatures

Une signature est constituée d’environ 70% d’empreintes cryptographiques. Il doit être possible d’utiliser une technique de probation par zk-STARK pour compresser et vérifier ces empreintes intermédiaires. Comme pour beaucoup de choses en rapport avec la divulgation nulle de connaissance de nos jours, la manière exacte dont cela fonctionnerait, ou même si cela fonctionnerait, ne connaît pas de définition exacte ni de réponse facile. Il s’agit donc d’une quête parallèle, d’une amélioration non essentielle de l’arbre principal des technologies du développement.

Sémantiques de l’EVM

Nous avons effleuré brièvement l’évitement des « abstractions poreuses », qui est un sujet important pour cette étape, et je vais donc faire un petit détour pour expliquer la raison de l’importance de ce concept. L’EVM est une composante abstraite du protocole d’Ethereum. En théorie, les détails sur le fonctionnement interne de l’EVM ne devraient avoir aucun effet sur le comportement macro du système, et des modifications au système hors de cette abstraction ne devraient avoir aucun effet sur quoi que ce soit à l’intérieur de celle-ci.

Dans les faits, certains aspects du protocole affectent bien directement ce qui se passe dans l’EVM. Ils se manifestent dans les coûts en gaz. Un smart contract (à l’intérieur de l’abstraction de l’EVM) y expose, entre autres, les coûts en gaz des diverses opérations sur la pile (hors de l’abstraction de l’EVM) par l’opcode GAS. Une modification de l’échelonnement du gaz peut directement affecter la performance de certains contrats, mais cela dépend du contexte et de la manière donc le contrat utilise l’information à laquelle il a accès.

En raison des « fuites » dues à la porosité de l’abstraction, les modifications de l’échelonnement du gaz et de l’exécution de l’EVM doivent être mises en œuvre prudemment, car elle peuvent avoir des effets inattendus sur les contrats autonomes. C’est une réalité avec laquelle il faut composer ; il est très difficile de concevoir des systèmes sans aucune fuite d’abstraction, et en tous cas les chercheurs de 1.X ne peuvent pas se permettre de tout recréer à partir de zéro. Il doivent travailler dans le cadre du protocole Ethereum actuel, qui est quand même un peu poreux dans la bonne vieille abstraction de la machine virtuelle à états.

Pour en revenir au sujet principal : l’introduction des signatures témoins exigera de revoir l’échelonnement du gaz. Elles doivent être générées et propagées à travers le réseau, et cette activité doit être prise en compte pendant les opérations de l’EVM. Les sujets liés à cette étape ont à voir avec la nature de ces coûts et de ces incitations, la manière de les estimer, et leur implémentation avec un impact minimal sur les couches hautes.

Indexation des signatures / décompte du gaz

Il est probable qu’il faille nuancer cette section, ce qui ne peut raisonnablement tenir en quelques phrases ; nous creuserons sans doute ce sujet plus à fond ultérieurement. Pour l’instant, comprenez que chaque transaction sera responsable d’une petite partie de la signature témoin du bloc complet. La génération d’un witness, d’une signature de bloc, implique une certaine quantité de calculs effectués par le mineur du bloc, et doit donc être associée à un certain coût en gaz, payé par l’émetteur de la transaction.

Comme plusieurs transactions peuvent toucher la même partie de l’état, il n’est pas facile d’estimer les coûts en gaz pour la production de la signature au point de diffusion de la transaction. Si les propriétaires de la transaction payent le coût total de la production de la signature, nous pouvons imaginer des situations dans laquelle la même partie de la signature d’un bloc serait payée plusieurs fois par des transactions qui « se recouvrent ». Ce n’est pas forcément une mauvaise chose, évidemment, mais cela implique des changements au niveau des coûts en gaz qui méritent d’être mieux compris.

Quels qu’en soient les coûts en gaz, les signatures témoins elles-mêmes devront devenir une partie du protocole Ethereum, et devront probablement être incorporées en standard à chaque bloc, peut-être en incluant quelque chose comme un witnessHash dans chaque en-tête de bloc.

UNGAS / Versionless Ethereum

Il s’agit d’une classe d’améliorations liée aux coûts en gaz dans l’EVM à peu près orthogonale à Stateless Ethereum, et qui corrige ces fuites d’abstraction dont j’ai parlé. UNGAS signifie « unobservable gas », gaz non observable, et effectue une modification qui interdit explicitement aux contrats d’utiliser l’opcode GAS, afin de prohiber toute hypothèse sur les coûts en gaz de la part de leurs développeurs. UNGAS fait partie de nombreuses suggestions du Ethereum core paper pour pallier certaines de ces fuites, en facilitant les changements d’implémentation de l’échelonnement du gaz, y compris et surtout les changements liés aux signatures témoins et à Stateless Ethereum.

Disponibilité de l’état

Stateless Ethereum ne se débarrassera pas totalement de l’état. Il le rendra optionnel, en autorisant un certain degré de liberté concernant l’état dont ils veulent conserver la trace ou calculer par eux-mêmes. L’état complet doit donc être disponible quelque part, afin que les nœuds cherchant à en télécharger une partie restent en mesure de le faire.

D’une certaine manière, les paradigmes existants comme fast sync fournissent déjà en partie cette fonctionnalité. Mais l’introduction des nœuds à zéro état et à état partiel complique les choses pour que les nouveaux nœuds puissent arriver à la vitesse de croisière. Actuellement, un nouveau nœud s’attend à pouvoir télécharger l’état de tout pair opérationnel auquel il se connecte, puisque tous les nœuds conservent une copie de l’état courant. Mais cette supposition part à la poubelle si certains des pairs peuvent être des nœuds à état zéro ou partiel.

Les prérequis de cette étape se rapportent aux façons dont les nœuds se signalent mutuellement de quels bouts de l’état ils disposent, et aux méthodes fiables de transfert de ces bouts d’état à travers un réseau pair à pair en perpétuelle mutation.

Règles de propagation sur le réseau

Le diagramme ci-dessous représente une topologie réseau hypothétique qui pourrait exister dans un Ethereum sans état. Dans ce réseau, les nœuds devront pouvoir se positionner selon les parties de l’état qu’ils veulent conserver, le cas échéant.

Les améliorations comme l’EIP #2465 entrent dans la catégorie générale des règles de propagation réseau : de nouveaux types de messages dans le protocole réseau qui fournissent plus d’informations sur l’information dont disposent les nœuds, et qui définissent la manière dont l’information est passée aux autres nœuds dans le cadre de topologies potentiellement bancales ou limitées.

Modèle de délivrance de données / routage DHT

Si des améliorations comme les types de message décrits plus haut sont acceptées et implémentées, les nœuds pourront facilement savoir quelles parties de l’état sont détenues par quels pairs auxquels ils sont connectés. Mais que se passe-t-il si aucun des pairs connectés ne possède une partie de l’état dont on a besoin ?

La délivrance de données est un problème ouvert avec de nombreuses solutions potentielles. Nous pourrions nous tourner vers des solutions « courantes », en mettant une partie ou la totalité de l’état à disposition par des requêtes HTTP sur un serveur dans le cloud. Une solution plus ambitieuse serait d’adopter des fonctionnalités provenant de systèmes pair à pair comparables de délivrance de données, permettant de requêter des parties d’état à travers des pairs connectés en tant que mandataires, en trouvant leurs destinations correctes grâce à une Distributed Hash Table. Les deux extrêmes ne sont pas intrinsèquement incompatibles… ¿Porque no los dos?

Mosaïque de l’état

Une approche possible pour améliorer la distribution de l’état consiste à casser l’état complet en parties plus gérables (des carreaux), stockés dans un cache réseau pouvant fournir cet état aux nœuds, allégeant ainsi la charge pesant sur les nœuds complets. L’idée est que même avec des carreaux de relativement grande taille, il est probable que certains d’entre eux resteront inchangés de bloc en bloc.

L’équipe de Geth a effectué quelques expérimentations qui suggèrent que la mosaïque de l’état est faisable et améliore la disponibilité des instantanés de l’état.

Élagage de la chaîne

On a déjà beaucoup parlé du chain pruning, de l’élagage de la chaîne, et une explication détaillée n’est pas nécessaire. Il reste néanmoins souhaitable que les nœuds complets puissent élaguer en toute sécurité les données historiques comme les reçus de transactions, les logs et les blocs historiques, à condition que les instantanés d’état historiques puissent être mis à disposition des nouveaux nœuds complets, grâce à quelque chose ressemblant à la mosaïque de l’état et/ou un système de routage DHT.

Spécification du protocole réseau

Enfin, un panorama complet de Stateless Ethereum peut se dégager plus clairement. Les trois étapes : Format des signatures témoins, Sémantiques de l’EVM et Disponibilité de l’état permettent une description complète d’une Spécification du protocole réseau : les améliorations bien définies qui doivent être codées dans chaque implémentation du client, et déployées au cours du hard fork suivant pour amener le réseau vers le paradigme du sans état.

Nous avons couvert un bout de terrain dans cet article, mais quelques petites choses dans le diagramme doivent encore être expliquées :

Spécification formelle du sans-état

Tout compte fait, il n’est pas obligatoire d’arriver à une définition formelle du protocole sans état complet. On peut raisonnablement envisager de coder une implémentation de référence à employer comme base que tous les autres clients réimplémenteraient. Mais les avantages d’une spécification formalisée pour les signatures et les clients sans état sont indéniables. Il s’agirait essentiellement d’une extension ou d’une annexe au Ethereum Yellow Paper, qui détaillerait très précisément le comportement d’une implémentation d’un client Ethereum sans état.

Beam Sync, Red Queen’s sync et autres optimisations de la synchronisation d’état

Les stratégies de synchronisation ne font pas partie du protocole réseau à proprement parler. Il s’agit plutôt de détails d’implémentation qui affectent la performance des nœuds quand ils mettent en œuvre le protocole. Beam sync et Red Queen’s sync sont des stratégies apparentées qui accumulent une copie locale de l’état à partir des signatures témoins. Il faudrait mobiliser des ressources pour améliorer ces stratégies et pour les adapter à la version « finale » du protocole réseau, quand celui-ci sera finalisé et implémenté.

Pour l’instant, elles sont laissées en tant que « bonus » dans l’arbre des technologies, car elles peuvent être développées indépendamment des autres sujets, et parce que les détails de leur implémentation dépendent de choix plus fondamentaux comme le format de signature. Il faut noter que ces sujets extra-protocolaires constituent, en vertu de leur indépendance par rapport aux changements de fond, un bon véhicule pour tester les améliorations fondamentales à gauche de l’arbre.

En résumé

On peut dire que le voyage a été long ! J’espère que les sujets et les étapes abordés ainsi que l’idée générale de l’« arbre des technologies » aideront à organiser le cadre de la recherche sur le « Stateless Ethereum ».

J’espère aussi mettre régulièrement à jour la structure de cet arbre au fur et à mesure des progrès. Comme je l’ai déjà dit, ce n’est pas un cadre de travail « officiel » ou « final », mais simplement le schéma le plus exact disponible à cet instant. Toute suggestion de votre part pour l’améliorer sera la bienvenue.

Comme d’habitude, si vous avez des questions, des demandes concernant de nouveaux sujets, ou si vous voulez participer à la recherche sur un Ethereum sans état, venez vous présenter sur ethresear.ch, et/ou joignez @gichiba ou @JHancock sur Twitter.