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

Geeks, cet article est pour vous, tout comme L’arbre des technologies d’un Ethereum sans état auquel il succède dans la série des 1.X Files (dont la lecture préalable est très fortement recommandée). Il résume la recherche récente sur les évolutions nécessaires pour que la chaîne actuelle continue de fonctionner au mieux en attendant Ethereum 2.0, et sera très rapidement suivi du compte-rendu du Stateless Summit.

Cet article constitue un simple résumé ainsi qu’une mise à jour générale ; nous y récapitulerons les problèmes en cours de discussion, et nous préparerons le Stateless Ethereum call n° 4 ainsi que le sommet des chercheurs 1.X qui suivra EthCC.

Il suppose une bonne compréhension des concepts en jeu, car il y a beaucoup de sujets à rattraper. Si ce domaine est nouveau pour vous, je recommande de lire L’arbre des technologies d’un Ethereum sans état afin de vous imprégner du contexte.

Ce diagramme issu de l’article précité pourra vous être utile :

Le cadre général

Stateless Ethereum est un projet consistant à améliorer le protocole actuel d’Ethereum afin de permettre un paradigme de clients « sans état », dans lequel les nœuds n’ont pas tous besoin de conserver une copie à jour du trie d’état. Les clients sans état se fient alors à une signature témoin appelée « witness » produite par un nœud à état complet pour exécuter les nouveaux blocs.

Ces signatures constituent le concept central des discussions sur le sans état, et la plupart des recherches à ce sujet sont conduites sur deux fronts :

  • Format et implémentation des signatures
  • Disponibilité de l’état et des signatures

En premier, nous nous interrogeons sur la structure des signatures elles-mêmes, les modifications à apporter au format du trie d’état, les implémentations de la base de données des clients et les optimisations pour limiter la taille supposée des signatures.

Le second pose des questions moins bien cernées sur la topologie réseau, les protocoles de gossip de distribution de signatures et, d’un point de vue quantitatif, les incitations et les performances réseau.

Ce qu’on sait qu’on sait

Pour arriver à destination, certaines choses devront certainement se produire. Elles sont détaillées dans l’article de Vitalik, Protocol Changes to bound Witness Size :

  • Une transition vers un trie binaire par une stratégie soit « progressive », soit par une coupure nette. Un basculement progressif demande des arbres de Merkle épars, alors qu’une coupure nette provoquera probablement une perturbation temporaire de la chaîne ;
  • Les signatures seront produites par les mineurs qui conservent une copie de l’état complet, et devront être payées en gaz inclus dans la transaction. Cela devrait engendrer des augmentations de prix en gaz pour les opcodes EXTCODESIZE, BALANCE, CALL et SLOAD ;

À ces points généraux viennent s’ajouter des données fiables provenant d’expérimentations menées par Igor Mandrigen :

Les signatures dans une représentation en arbre binaire sont toujours plus optimisées en taille qu’en sénaire et pèsent dans les environs de 0.3-1.4 Mo selon la signature. source

Dans le cas de nœuds à état partiel, il est possible de substantiellement réduire les exigences de stockage en conservant des données partielles dans le cache et en construisant le cache de manière incrémentale à partir des signatures témoin. source

Enfin, une première ébauche a été soumise sur le repository des spécifications de Stateless Ethereum et se trouve actuellement en cours d’examen. Une spécification formelle de signature constitue une étape importante pour implémenter un prototype sans état.

Ce qu’on ne sait pas vraiment… mais on devrait pouvoir s’en sortir

Quelques points de recherche entrent dans la catégorie de « Nous savons que nous devons faire ceci, nous ne savons pas exactement comment nous allons nous y prendre, mais notre intuition nous laisse à penser qu’une solution est possible ».

La merklisation du code en offre un exemple. Afin d’éviter des signatures témoins trop grandes, la merklisation du code éclate le code du contrat pour que seule la portion du code appelé n’ait besoin d’être incluse dans la signature de la transaction. Il en existe actuellement un prototype qui utilise les instructions JUMPDEST présentes dans le code pour l’éclater en morceaux d’une taille plus facile à gérer, mais on considère cela comme une abstraction « poreuse » en exposant les tailles de signature aux sémantiques du code. Il vaudrait mieux employer des tailles de code fixes, ce qui est faisable au prix de quelques méta-données dans chaque signature (spécifiant les destinations des sauts valides), ou si le code est validé avec tous les sauts statiques imposés à la validation.

Un autre besoin manifeste est l’indexation des signatures, c’est-à-dire qu’un identifiant « canonique » pour tous les nœuds permettrait de savoir facilement qu’ils ont récupéré la signature témoin correcte pour un bloc donné avant de le valider en local. La manière la plus simple d’y arriver requiert un changement du protocole pour intégrer un witnessHash dans l’en-tête du bloc. Cela évite des vecteurs d’attaque potentiels et fait de la génération d’une signature une exigence explicite pour les mineurs produisant des blocs.

On trouve aussi dans cette catégorie une vaste palette d’éléments « méta » qui permettront à la recherche de continuer et d’accélérer. Cela comprend des outils de développement pour expérimenter et collecter des données utiles provenant de la chaîne historique, les sémantiques formelles de l’EVM, et une plateforme pour lancer des simulations de réseau.

Ce qu’on sait qu’on ne sait pas

Bien d’autres questions plus fondamentales concernant le réseau tombent dans la catégorie de l’« inconnu ». Ce sont des questions qui demandent d’autres investigations avant que nous puissions être confiants quant à la direction à prendre.

La découverte et la délivrance de données pour les nœuds en cours de synchronisation sont un problème majeur pour le Stateless Ethereum, car, au contraire du paradigme actuel de synchronisation, un nouveau nœud ne peut pas s’attendre à ce qu’un groupe aléatoire de pairs dispose de tous les bouts d’état dont il a besoin pour exécuter le bloc courant.

Comme le protocole Eth actuel ne fournit pas d’interface pour que les clients puissent demander quel est l’état dont disposent les pairs connectés, ce problème n’est pas trivial. Les nœuds ont au minimum besoin d’interroger leurs pairs pour plusieurs types de données, comme les en-têtes, les reçus, les transactions et des parties spécifiques de l’état. Les questions ouvertes abondent dans ce domaine concernant la manière dont les données sont délivrées aux nœuds ; celle dont les nœuds complets s’orienteront dans un réseau avec beaucoup de pairs sans état ; et comment le réseau empêchera les données d’état d’être à jamais perdues. Un exposé plus détaillé de ce sujet par Piper Mirriam a été posté sur le forum de ethresear.ch.

Le défi inhérent à ces questions plus lointaines tient à ce que la topologie du réseau d’un Ethereum sans état ne peut qu’être devinée en se fondant sur des suppositions de comportement rationnel et sur l’activité actuelle. Cependant, à l’inverse de la recherche sur Eth2, Stateless Ethereum est assez proche de la chaîne actuelle pour que les statistiques historiques de Eth1 s’avèrent pertinentes et utiles pour les tests. Il faudra néanmoins plus de données, et de meilleure qualité, pour avancer sur la topologie du réseau.

Une ligne parallèle d’investigations émergera une fois un groupe de nœuds beam-syncing prêt pour l’étude et l’attaque. Un nœud beam-syncing est essentiellement un prototype bricolé à la va-vite d’un nœud sans état, utilisant une primitive « naïve » (getNodeData) pour collecter (et conserver) des pièces manquantes de l’état. Nous pourrons en apprendre beaucoup sur les primitives réseau souhaitables en essayant de casser ce beam sync, puis en itérant sur ces leçons pour se rapprocher progressivement du paradigme de synchronisation sans état « réel ».

Les questions spécifiques à la transition finale vers Eth2 restent largement sans réponse, bien que le scénario de transition Eth1 <> Eth2 de Vitalik soit en ligne avec la réflexion actuelle dans le groupe 1.X.

À Paris !

Les chercheurs 1.x se rencontreront à Paris pour exposer les problèmes et travailler aux solutions en personne, le week-end après EthCC. Ce petit sommet fournira une belle opportunité de faire avancer les travaux et de collaborer sur les défis les plus obscurs et les moins bien compris de Stateless Ethereum. Allons-y !

NdT : Le sommet s’est tenu dans les locaux de l’ESGI dans le cadre du Unhackathon, en parallèle à d’autres rencontres. Compte-rendu à suivre…