Hors-série : Ethereum 2.0

Où en est-on ?

Améliorez vos compétences en finance décentralisée toutes les semaines. Inscrivez-vous au programme Bankless ci-dessous.


Chers Crypto-Natifs,

Nous espérons que vous passez une excellente journée.

Aujourd’hui, en guise de hors-série, nous vous communiquons un article de Danny Ryan qui fait le point sur Ethereum 2.0. Il vous sera utile de comprendre les enjeux de cette mise à jour tant attendue.

Comme d’habitude, à la fin, nous vous proposons quelques actions à réaliser.

- Jon & Brice de Bankless


HORS-SERIE RECHERCHE ET DEVELOPPEMENT

L’état d’Ethereum 2.0

Auteur : Danny Ryan

Un grand merci pour la contribution et les commentaires de qualité de Sacha Saint-Leger, Joseph Schweitzer, Josh Stark et protolambda.

J’attache une grande importance et je passe vraiment beaucoup de temps à expliquer et à répondre à des questions sur Eth2, principalement sur un plan technique et approfondi, et, j'aide à diffuser les recherches et les spécifications aux contributeurs techniques. Mais depuis peu, je réponds aux questions de la communauté sur les progrès d’Eth2 : son orientation, ses motivations, les décisions de conception, les retards, etc. Il se trouve que j'aime beaucoup ces conversations et je suis très enthousiaste lorsque j'explique Eth2, soit quand je trouve de nouvelles façons de décrire ses différentes composantes, soit lorsque je trouve les bonnes analogies en fonction du public pour faire comprendre mon propos.

Mais cette méthode dynamique, sous forme de conversation, bien que précieuse, laisse une bonne partie de la communauté dans l’ignorance. On me pose sans cesse les mêmes questions, et, encore plus alarmant, on me pose ces mêmes questions 6 mois plus tard ! Il est clair qu'il y a un problème au niveau de la diffusion de l'information. Ces informations existent, mais elles sont dispersées sur le web : articles de recherche, spécifications, explications de spécifications, appels publics, channels publics, reddit, articles de blog. Ma première tentative, après la Devcon V, pour combler ce manque de partage de l’information entre ceux qui sont au cœur d'Eth2 et le reste de la communauté, s'est manifestée par une nouvelle série de blogs, "Eth2 quick update". Ce sont des petits textes qui aident à suivre l’état d’Ethereum, mais je me rends compte qu'ils ne donnent pas vraiment une vue d'ensemble. Celle-ci est diffusée et débattue par le biais de podcasts, d'AMA (Ask Me Anything - Demandez-moi n’importe quoi) et de conférences, cependant une forme écrite pourrait contribuer aux efforts déjà fournis.

Voilà où nous en sommes. Cet article à l’attention de la communauté, a pour but de donner un aperçu complet de ce qu'est Eth2 aujourd'hui : où il va, ce qu'il pourrait devenir, et ce qu'il signifie pour la communauté Ethereum. Je vais tenter d’illustrer la raison du projet, sa vision, son état actuel et le travail à venir, sans trop m’enliser dans les mathématiques ou dans un jargon trop complexe et en utilisant juste ce qu'il faut comme termes techniques.

Ce texte pourrait également être utile aux techniciens d'Ethereum qui se sont jusqu'à présent tenus à distance d'Eth2. Pas d’inquiétudes, c'est compréhensible ce projet est tellement vaste, compliqué, et a toujours semblé suffisamment éloigné dans le futur que vous vous avez pu l'ignorer afin de vous concentrer sur la résolution des problèmes urgents qui se présentaient. J'espère que cet article vous aidera à mieux comprendre les choses à venir.

Quant à ceux qui travaillent déjà sur Eth2, vous pourriez aussi tirer quelque chose de cet article : un meilleur aperçu de la situation actuelle ainsi que la façon dont je perçois les choses à venir.

Avertissement : c'est ainsi que moi, Danny Ryan, je vois les choses aujourd'hui. De nombreuses voix et opinions animent Eth2, qui ne cessent de croître et d'évoluer. Ceci n'est qu'un aperçu de mon interprétation personnelle.

Eth2, wtf

"Eth2 est une infrastructure extensible basée sur la preuve d'enjeu (PoS)"

Si vous m'avez suivi au cours des six derniers mois, vous m'avez entendu en parler à maintes reprises. Eth2 est construit pour le mainnet Ethereum et est, à terme, Ethereum. Il a pour objectif d’offrir un environnement plus sûr et plus extensible pour le mainnet Ethereum actuel, sans perturber ou très peu la façon dont il fonctionne aujourd'hui. En même temps, il fournit un environnement amélioré dans lequel nous pouvons, nous, faire évoluer toutes les technologies destinées à Ethereum.

Avant même le lancement d'Ethereum, on savait qu'un simple modèle de blockchain ne pourrait pas offrir une bande passante suffisante pour servir d'épine dorsale à un nouvel internet décentralisé. La recherche liée au PoS et au Sharding sur Ethereum remonte à 2014 déjà. Elle vise à répondre à la question suivante : “Compte tenu d'un certain capital investi dans un système crypto-économique, pouvons-nous améliorer la sécurité et le débit tout en permettant au matériel des utilisateurs de participer au consensus et d'interagir avec la blockchain ?” Sans rentrer dans le détail de l’histoire, ces recherches ont pris des années et ont été marquées par de nombreux faux départs. En fin de compte, la réponse à cette question est un oui retentissant, et elle s'est manifestée sous la forme du projet Eth2.

Eth2 est un projet ambitieux qui s’étend sur plusieurs années, et qui sera déployé par phases. Il est très documenté et fait beaucoup débat, cependant, je vais vous donner un aperçu rapide et pas trop technique de ce qu'il implique.

Phase 0

La phase 0, la Beacon Chain, est au cœur du nouveau mécanisme de consensus. C'est là que se déroulent l'activité système d'orchestration de la blockchain. La phase 0 consiste à parvenir à un consensus avec des centaines de milliers d'entités de consensus, qu’on appelle Validateurs, réparties sur des milliers de nœuds dans le monde entier.

En raison des exigences techniques liées à la distribution de sous-ensembles de Validateurs sur des Shards en phase 1+, nous devons être en mesure de gérer une quantité énorme de Validateurs. Une grande partie de la complexité technique découle de cette exigence. D'autres mécanismes de PoS sans Shards ont des centaines, voire des milliers de Validateurs, mais Eth2 est conçu pour avoir un minimum d'environ 16 000 Validateurs, avec l'espoir que ce chiffre atteindra des centaines de milliers d'ici quelques années.

Phase 1

La phase 0 consiste à parvenir à un consensus, tandis que la phase 1 consiste à parvenir à un consensus à propos de nombreuses choses. Ces "choses" se présentent sous la forme de nombreux Shards. On peut considérer un Shard comme une sous blockchain avec approximativement la même complexité qu'Ethereum aujourd'hui, mais fonctionnant sous le consensus Eth2 (c'est-à-dire s’exécutant sur et construit/contrôlé par la Beacon Chain). Les Validateurs de la Beacon Chain reçoivent des missions aléatoires à court terme pour construire et valider les Shardchains, en prenant des engagements crypto-économiques sur l'état, la disponibilité et la validité de chaque chaîne qui fonctionne sur le système central.

Aujourd'hui, nous prévoyons qu'il y aura 64 Shards au départ, et que le total des données disponibles pour le système sera compris entre 1 et 4 Mo/s (OUI, ça représente beaucoup de données).

Phase 1.5

La phase 1.5 est l'intégration du réseau principal Ethereum dans le nouveau mécanisme de consensus Eth2 en tant que Shard (existant comme l'un des nombreux Shards créés dans la phase 1). Le réseau Ethereum que nous connaissons et apprécions, construit aujourd'hui par un algorithme de preuve de travail (PoW), sera alors construit par les Validateurs d'Eth2. Pour les applications et les utilisateurs existants, ce "hot swap" du mécanisme de consensus sera en grande partie transparent. Les applications continueront de fonctionner, mais les développeurs disposeront désormais d'un système beaucoup plus puissant (meilleures propriétés au niveau de la sécurité, finalité économique appropriée, plus de données L1 pour les Rollups et autres fonctionnalités intéressantes).

Phase 2

La phase 2 consiste à ajouter l'état et l'exécution sur plus de Shards que le seul Shard Ethereum original. Cela peut prendre de nombreuses formes. La détermination de cette forme et des détails qui la sous-tendent est aujourd'hui un sujet de recherche et de prototypage. J'en parlerai un peu plus dans les sections suivantes.

Les avantages d'Eth2 pour la communauté au fil du temps

D’accord, nous avons donc toutes ces phases à venir et la phase 0 semble bientôt commencer. Mais cette feuille de route est tout de même un peu longue. Que dois-je attendre d'Eth2 pendant les phases de la mise à jour ?

Excellente question ! En général, il faut s'attendre à une vague de mises à jour qui touchent de plus en plus Ethereum et la communauté à chaque étape. En tant qu'utilisateur, vous pouvez soit vous impliquer très tôt dans la mise en place de la phase 0, soit simplement attendre qu'Ethereum migre complètement vers Eth2 à la phase 1.5 (une transition qui devrait être transparente du point de vue des développeurs et des utilisateurs de dapps). Quel que soit le degré d'engagement que vous choisissez et la phase à laquelle vous vous engagez, il existe des étapes importantes et des opportunités qui méritent d'être connues au moment où tout commence à se mettre en place.

La première : je sais que beaucoup d'entre vous sont des hardcores holders d'ETH, impatients de faire du Staking. Pour tous les Validateurs potentiels, en particulier les amateurs, la phase 0 vous est destinée. La phase 0 comporte ses propres risques et horizons temporels qui la rendront peu attrayante pour certains participants, c'est pourquoi j'espère personnellement que cette phase sera une aubaine tant pour les amateurs que pour les partisans d'Ethereum à long terme. C'est une chance unique d'entrer sur le terrain, de contribuer à influencer le milieu au fil du temps et une chance de recevoir une récompense plus élevée en ETH pour avoir été un early adopter.

Qu'en est-il de la phase 1 ? Y a-t-il quelque chose d'utile que nous puissions faire avec toutes ces données avant l'intégration d'Ethereum dans Eth2 ? Oui, je suis ravi que vous posiez la question !

Les données L1 sont incroyablement utiles, même sans calcul natif. En fait, les solutions de scalabilité L2 les plus prometteuses au cours des 12 derniers mois sont ces technologies dites "Rollup" (à la fois optimistic et ZK) qui évoluent avec la disponibilité des données de la L1. La couche de données d'Eth2 devrait fournir une disponibilité des données sur Ethereum comprise entre 1 et 4 Mo/s, ce qui se traduit par des gains massifs en extensibilité lorsqu'elle est associée à la technologie de Rollup. Mais en raison, dès le départ, de la dissociation initiale d'Ethereum et du nouveau système en Shards, il est difficile de faire des affirmations à propos de la disponibilité des données en Shard sur Eth2. C'est l'une des raisons pour lesquelles l'EIP 2537 est si importante pour le mainnet d'Ethereum. Grâce à une précompilation native du BLS (nouvel algorithme de signature d'Eth2), nous pouvons développer un client léger Eth2 efficace sous la forme d'un smart contract Solidity, ce qui permet aux dapps Ethereum d'avoir accès aux données d'Eth2 avant l'intégration de la phase 1.5.

Comme nous l'avons vu plus haut, la phase 1.5 est titanesque. Eth2 est construit pour Ethereum et à ce stade, Eth2 devient Ethereum. Toutes les applications que nous connaissons sont intégrées dans le mécanisme de consensus Eth2 amélioré, conservant l'ensemble des fonctionnalités auxquelles nous sommes habitués tout en ouvrant simultanément le vaste et nouvel horizon d'un consensus sécurisé de preuve d'enjeu avec un accès natif à une couche de données hautement extensible. C'est là, à mon avis, le cœur du processus. Il nous faudra fêter ce moment car nous ferons basculer Ethereum dans une nouvelle réalité.

Au-delà de cela, des gains supplémentaires d’extensibilité seront probablement réalisés au fil du temps en permettant l'état/exécution sur des Shards supplémentaires. Cela peut prendre la forme de l'EVM ou d'une nouvelle VM appelée eWASM. Quel que soit le choix de la VM, le Shard EVM Ethereum existant et les autres Shards seront capables d'interagir et de communiquer nativement via la Beacon Chain, complétant ainsi la vision multi-exécution et multi-Shards.

Vous voyez ? C'est tout un programme, tout au long duquel nous pourrons percevoir les bénéfices techniques.



Les difficultés de cette approche, et pourquoi elle en vaut la peine

Beaucoup de Validateurs

Un élément clé du Sharding repose sur l'échantillonnage aléatoire des participants au consensus (Validateurs), réunis en comités pour valider une sous-section du protocole (par exemple un Shard). Avec un nombre suffisant de Validateurs dans le protocole, et un attaquant d'une taille maximale supposée (contrôlant 1/3 des Validateurs, par exemple), il devient mathématiquement improbable (à vue de nez, pensez à une probabilité de l'ordre de 1/2^40) que l'attaquant prenne le contrôle d’un comité et corrompe le système. Cela nous permet de concevoir le système de telle sorte que toute personne possédant une machine grand public (par exemple un ordinateur portable ou peut-être même un vieux téléphone) puisse devenir un Validateur (puisque les Validateurs sont affectés à des sous-sections du système, et que la validation de n'importe quelle sous-section peut être effectuée avec les ressources en calcul d'une seule machine).

C'est ce qui rend le Sharding incroyable et, en même temps, difficile. D'une part, nous devons avoir suffisamment de Validateurs pour rendre sûr cet échantillonnage aléatoire : il est attendu qu’Eth2 aura certainement beaucoup plus de Validateurs que la plupart des autres protocoles à preuve d'enjeu. Personnellement, je pense que ce sera beaucoup plus que tout autre protocole en PoS. Cela introduit des défis à chaque niveau du processus - de la recherche, à la spécification du mécanisme de consensus, à la mise en réseau, à la consommation de ressources et à l'optimisation des clients. Chaque Validateur supplémentaire induit une charge sur le système qui doit être prise en compte à chaque étape du processus. Les équipes de dev des clients Eth2 ont accompli la tâche herculéenne de gérer le consensus de centaines de milliers de Validateurs afin que nous puissions intégrer de nombreux Shards de manière sûre et efficace lors de la phase 1.

Beaucoup de Shards

Une autre décision de conception fondamentale qui rend notre tâche si difficile est qu'au sein d'Ethereum, nous cherchons la scalabilité sans faire de compromis sur la décentralisation.

Il n'est pas difficile d'adapter une blockchain à des dizaines de milliers de transactions par seconde, si nous ne nous soucions pas que les utilisateurs puissent réellement valider la chaîne par eux-mêmes, ou de garantir que les données sont effectivement disponibles sur le réseau. La complexité d'un mécanisme de consensus en Shard est nécessaire pour que le système puisse être décomposé en de très petites sections validables. La spécification et la mise en œuvre d'un tel mécanisme de consensus est tout simplement une tâche difficile.

Beaucoup de clients

L'un des principes fondamentaux d'Ethereum est qu'Ethereum est d'abord et avant tout un protocole. Ethereum est un ensemble abstrait de règles qui constitue le protocole plutôt qu'une implémentation spécifique de cet ensemble de règles. Pour cela, la communauté Ethereum a toujours encouragé l'implémentation de nombreux clients Ethereum. Sur le mainnet Ethereum, cela se présente aujourd'hui sous la forme de besu, ethereumJS, geth, nethermind, nimbus, open-ethereum, trinity et turbo-geth. Et du côté d’Eth2, cela se manifeste sous la forme de cortex, lighthouse, lodestar, nimbus, prysm, teku et trinity.

Le paradigme multi-clients présente de nombreux avantages significatifs :

  • Le fait d'avoir plusieurs clients permet une exploration plus large des idées, des algorithmes et des architectures (chaque client apporte sa propre approche et son propre point de vue). Il y a une émulation saine dans ce processus, car nous construisons tous des systèmes plus robustes.

  • Les clients ont souvent des objectifs de conception différents. Cela conduit à un ensemble plus diversifié d'utilisateurs et d'applications au fur et à mesure que le temps passe. Les clients peuvent être plus ou moins axés sur l'un des éléments suivants : performance, sécurité, scaling horizontal, interface utilisateur/expérience utilisateur, clients légers, navigateurs, terminaux à ressources limitées, etc.

  • Avec de nombreuses implémentations de clients sur le mainnet, une attaque importante qui peut faire tomber n'importe quel client (par exemple, une attaque DoS) est contrée par la résilience des autres clients. C'est ce que l'on a pu constater très tôt dans l'histoire d'Ethereum, lors des "attaques par déni de service de Shanghai", une série d'attaques par déni de service qui a pu faire tomber geth et parity, mais jamais les deux en même temps.

  • Chaque client sert de passerelle vers une communauté formée autour d'un langage de programmation. La fondation d'un client dans un langage particulier ouvre et invite à l'expérimentation et à l'innovation dans ce langage. Les outils de base autour du client font souvent boule de neige et forment un solide écosystème d'outils et de contributeurs dans ce langage. Le paradigme multi-client renforce le puit gravitationnel qu'est Ethereum.

Ces différents avantages s'accompagnent de certaines difficultés :

  • Les spécifications et les tests doivent être irréprochables afin d'éviter tout fork accidentel sur le réseau principal. S'il n'y a qu'une seule implémentation du protocole, alors cette implémentation devient le protocole. Dans le cas d'un client unique, s'il y avait une sorte de "bug" consensuel sur le mainnet, alors il serait intégré dans la réalité du protocole. Ce n'est pas optimum du point de vue de la simplicité, mais cela élimine tout risque de fork inopiné. Pour pallier cette difficulté, si nous avons une bonne répartition des clients sur le mainnet (par exemple, aucun client n'a plus d'un tiers du nombre total de nœuds/Validateurs), le réseau peut rester actif même si un seul client a un problème de consensus.

  • La coordination de N clients entraîne au mieux une surcharge linéaire par rapport à un seul client, mais dans certains cas, elle peut induire une surcharge quadratique (N^2). Il existe des techniques que nous employons pour réduire cette surcharge - par exemple les suites logicielles de tests de consensus (et bientôt de réseau) - mais cette surcharge sera toujours présente à un certain degré.

État des clients et des réseaux de test d’Eth2

Les clients Eth2 de la phase 0 sont devenus des logiciels très sophistiqués au cours des deux dernières années, capables de gérer le consensus distribué de centaines de milliers de Validateurs sur des milliers de nœuds. Nous sommes actuellement en phase de testnet et nous nous rapprochons chaque jour un peu plus du lancement. Je m'attendais à ce que le dernier kilomètre soit long. Il s'avère que c'est le cas.

Je vous demande, pendant cette période précédant le lancement, de sortir de votre zone de confort et d'essayer plusieurs clients. Il y a de nombreux compromis à faire entre eux et vous allez devoir vous salir les mains pour trouver celui qui vous convient le mieux. Comme nous l'avons vu plus haut, Ethereum fonctionne dans un paradigme multi-clients. Pour tirer profit de ce paradigme, nous avons besoin que les utilisateurs gèrent un ensemble diversifié de clients (afin de créer une répartition saine entre tous les types de clients).

Au-delà de cela, le protocole intègre des mesures d'incitation à la lutte contre la corrélation. Dans les situations extrêmes où un client important amène accidentellement les Validateurs à se déconnecter ou à commettre un délit, si le comportement de votre Validateur est corrélé avec ce client, vous serez beaucoup plus pénalisé que si vous avez fait quelque chose de mal sans corrélation avec les autres. En d'autres termes, dans ces situations, il est préférable de gérer un client minoritaire plutôt qu'un client représentant une grande partie du réseau.

Pour être tout à fait clair - s'il y a plus d'un client viable et sûr, il est de votre devoir d’utiliser un client minoritaire, afin de promouvoir une distribution saine des logiciels clients sur le réseau.

Ne soyez pas timide. Si vous rencontrez des problèmes avec la documentation, faites-le savoir à quelqu'un. Si vous constatez une erreur de frappe, faites-le savoir. Si quelque chose plante ou si un bug apparaît, SVP, veuillez le signaler sur le github ou le Discord du client. Vous êtes les bêta-testeurs et, avec votre aide, nous pouvons améliorer la situation pour tout le monde.

Testnets

Nous avons mis en place, en ce moment, de petits devnets, que nous relançons environ toutes les une à deux semaines. Je dis "devnets" parce qu'ils sont avant tout destinés aux équipes de développeurs pour qu'ils puissent résoudre les bugs, les optimisations, etc. Ils sont publics et vous y êtes les bienvenus, mais sachez qu'ils n'ont pas encore une longue durée de vie comme Goerli ou Rinkeby. Le lancement le plus récent, dirigé par Afri Schoedon, est le testnet Witti qui utilise la spécification v0.11 (consultez le README ici si vous voulez tester le fonctionnement de certains nœuds). NDT : le testnet Onyx, de Prysmatic Lab, a été lancé hier en version v1.12.1.

Les équipes de développement des clients sont en train de passer à la spécification v0.12 qui intègre la dernière version du standard BLS de l'IETF. À partir de là, nous ferons passer les devnets à la v0.12 à mesure que nous continuerons à augmenter la taille des réseaux, ce qui entraînera une charge de plus en plus importante pour les clients. Lorsque nous aurons 2 ou 3 clients qui auront lancé avec succès les réseaux v0.12 et qui fonctionneront à haute charge, nous ferons un testnet plus public où vous ferez fonctionner la plupart des nœuds et des Validateurs. L'objectif est de créer un réseau, durable, de test multi-clients qui imite autant que possible le réseau principal (où les utilisateurs peuvent s'entraîner à exécuter les nœuds et à tester tout ce qu'ils veulent). L'idéal est de faire tourner ce réseau une seule fois et de faire le tri des pannes éventuelles tout en maintenant le réseau. Mais en fonction de la présence et de la gravité des pannes, nous pourrions avoir besoin de quelques essais avant d'y arriver.

En plus des réseaux de test normaux, nous proposerons également un "réseau d'attaque" où les équipes de développement des clients exploiteront un réseau de test stable, et où nous vous inviterons à essayer de le briser de différentes manières, avec des récompenses à la clé. Pour les attaques réussies, l'EF fournira des récompenses en ETH. Plus d'informations à ce sujet bientôt - alors restez à l'écoute !

Point sur les différents outils d’Eth2

Bien que les outils liés à Eth2 soient assez récents, leur développement est passionnant et très vivant. Comme mentionné ci-dessus, les outils proviennent souvent d'un code base de client Eth2 et des efforts de l'équipe du client, ceci étant, de plus en plus de personnes s’impliquent chaque jour. Pour mieux interagir avec Eth2, le comprendre, le sécuriser et l'améliorer, nous devons, en tant que communauté, construire et développer les outils de base d'Eth2.

Je tiens à remercier chaleureusement les équipes et les personnes qui ont déjà apporté une valeur immense avec leurs suites d’outils destinés à Eth2. De plus j’invite tout le monde à construire de nouveaux outils, à les compléter, et à les améliorer.

Se lancer dans la création d'outils pour Eth2 est une nouvelle opportunité. C'est une chance incroyable de se lancer, d'apporter une réelle valeur ajoutée et de pouvoir laisser sa marque.

Voici un échantillon des travaux en cours, mais il reste encore beaucoup à faire !

Et voici un échantillon de quelques idées d’outils qui pourraient être utiles :

  • Alertes de Validateurs Eth2 : fournir un service qui alerte les opérateurs de nœuds lorsque leurs Validateurs ne fonctionnent pas de manière optimale.

  • Tracking des dépôts de valideurs : aide à faire le lien entre les explorateurs actuels d'Ethereum et d'Eth2 en suivant le processus de dépôt lié aux Validateurs.

  • Protection des Validateurs via proxys : utilisez un proxy pour tracker les messages des Validateurs afin de vous assurer que votre client ne peut pas envoyer de messages dangereux.

Et bien plus encore - c'est le type de contribution qui n'est pas limité à une spécification. La créativité est importante. Si vous souhaitez apporter votre contribution, parlez aux équipes de dev des clients Eth2 pour commencer.

État des intégrations Eth1+Eth2

Pour un client Ethereum actuel (par exemple, geth, etc.), la quasi-totalité de sa complexité réside dans la gestion de l'activité au niveau utilisateur - pool de transactions, création de blocs, calcul liés à la machine virtuelle et stockage/recherche d'états. Le consensus de base actuel - le PoW - est plutôt simple comme protocole. La majeure partie de la complexité est traitée par du matériel sophistiqué en dehors du protocole de base.

D'autre part, un client Eth2 est le consensus à part entière. Pour la preuve d'enjeu et le Sharding, beaucoup de complexité est apportée dans le protocole, afin d'atteindre les objectifs d'un consensus extensible.

Cette différenciation des besoins permet d'obtenir une belle association entre les clients Eth1 et Eth2.

Les membres des équipes geth (EF) et TXRX (ConsenSys) travaillent actuellement à la fusion des deux. Le travail consiste à (1) définir un protocole de communication entre les clients Eth1 et Eth2, (2) ajouter un moteur de consensus aux clients Eth1 qui peut être contrôlé via le protocole de communication, et (3) prototyper et simuler le comportement de la phase 1 d'Eth2 pour tester le couplage du tout. Nous espérons voir des résultats concrets sur ces points cet été.

Vous pouvez en lire plus sur la relation haut niveau entre les clients Eth1 et Eth2 ici, et sur la portée technique de la fusion ici.

État de l’exécution et de la communication à travers les Shards

Comme mentionné, la voie exacte pour permettre l'exécution à travers de nombreux Shards est un domaine qui fait l'objet de recherches et de débats passionnés. Il y a de nombreuses questions auxquelles il faut répondre. Par exemple :

  • Combien de Shards auront l'exécution active ?

  • Pour les Shards supplémentaires, utilisons-nous l'EVM ou l'eWASM pour la machine virtuelle ?

  • Comment structurer et traiter efficacement les transactions entre Shards ?

  • Quelles modifications devons-nous apporter à l'EVM existante pour prendre en charge les transactions inter-Shards ?

  • Les structures d'exécution et de compte peuvent-elles/doivent-elles être généralement extensibles ?

Les équipes eWASM (EF) et Quilt (ConsenSys) ont mené de nombreuses recherches dans ces domaines au cours des 12 derniers mois. Il s'avère que les solutions sont nombreuses, et bien que nous ayons maintenant une bonne idée de leur étendue, l'accent a été mis récemment sur la recherche de solutions simples et tangibles afin de pouvoir tester, prototyper et pouvoir discuter de choses réelles. C'est ainsi qu'est née l'initiative Eth1x64 d'eWASM (lire la présentation haut-niveau du projet et consulter les spécifications récentes en cours de discussion).

Des progrès rapides ont été réalisés, les idées abstraites, à propos des communications entre Shards, ont été transformées en spécifications concrètes afin de de pouvoir en débattre et, finalement, pour pouvoir passer au prototypage. Tenez-vous au courant des progrès qui se feront, surtout si vous êtes un développeur dapp. Nous avons l'intention de proposer quelque chose que vous pouvez comprendre, avec lequel vous pourrez jouer et sur lequel vous pourrez donner votre avis dans les mois à venir.

Stateless Ethereum et Eth2

Un autre effort majeur de R&D se déroule parallèlement à Eth2, appelé "Stateless Ethereum". Stateless Ethereum est un effort visant à résoudre le problème de la croissance de la taille de l'état d'Ethereum. Il permet aux participants de valider des blocs sans avoir à stocker localement la totalité de l'état. Actuellement, la fonction de transition d'état Ethereum comporte un élément implicite : la totalité de l'état. Avec Stateless Ethereum, des preuves (witness) de l'état requis seront fournies à l'intérieur des blocs. Cela permet de valider un bloc en tant que fonction pure du bloc.

Pour les utilisateurs, cela se traduit par un monde dans lequel vous pouvez suivre la chaîne, et même suivre des parties de l'état qui vous intéressent, sans avoir à stocker tout l'état. Certains participants au réseau stockeront probablement la totalité de l'état (producteurs de blocs, explorateurs de blocs, fournisseurs d'état à titre onéreux), mais la grande majorité des participants n'auront plus ou moins pas d'état.

Pour Eth2, il s'agit d'un mécanisme technique important afin de garantir que les nœuds et les Validateurs puissent valider et sécuriser le protocole sans avoir à stocker l'état utilisateur complet de chaque Shard. Au lieu de cela, les Validateurs choisiront probablement d'être des producteurs de blocs pour un certain ensemble de Shards, tandis que le Validateur de base ne pourra valider que les blocs sans états. Stateless Ethereum est un ajout incroyablement précieux vis à vis de la vision Eth2, en maintenant la base du protocole de Sharding très légère. Bien que nous prévoyions qu'Eth2 fonctionne en mode stateless, nous avons déjà quelques options au cas où la voie stateless ne s'avérerait pas viable en fin de compte (bien que je sois moi-même assez confiant vis à vis du mode Stateless 😄).

Je ne m'étendrai pas davantage sur Stateless Ethereum pour cet article. Sachez simplement qu'il s'agit d'une voie parallèle de R&D passionnante pour assurer la viabilité d'Ethereum à long terme. Si vous avez envie d'en savoir plus, consultez The 1.x Files de Griffin.

tl;dr

Eth2 est une vaste entreprise visant à fournir à Ethereum un consensus décentralisé, modernisé, de nouvelle génération, hautement extensible et sûr. Des dizaines d'équipes et des centaines d'individus travaillent chaque jour pour faire de ce projet une réalité. La voie que nous avons choisie est difficile, mais d'immenses progrès ont été réalisés et continuent de l'être.

Nous sommes presque arrivés à finaliser le cœur de ce mécanisme.

Si vous êtes un aspirant Validateur, c'est le moment de vous y mettre. Soutenez le paradigme de la multiplicité des clients en testant plusieurs clients, et contribuez à instiller une base solide de divers clients dès la genèse d'Eth2.

Si vous êtes un utilisateur ou un développeur d'applications, continuez à travailler sur Ethereum aujourd'hui pendant que nous continuons à vous préparer cet environnement plus sûr et plus scalable. Le moment venu, le passage à Eth2 sera aussi transparent que possible.

Merci aux équipes et aux personnes incroyables qui font vivre Ethereum aujourd'hui ; merci à tous ceux qui préparent l'avenir d'Ethereum dans Eth2 ; et merci à tous les utilisateurs et développeurs qui rendent Ethereum aussi génial 🚀 !


Bio

Danny Ryan fait partie de l’équipe de recherche de la Fondation Ethereum. Il travaille sur le coeur du protocole, sur les spécifications, et sur la coordination client du projet Eth2.


Récapitulatif

  • Restez informé, les canaux de discussion classiques ne sont pas toujours efficaces.

  • Pour pallier au manque d’information ou à ce que vous estimez être une mauvaise organisation dans sa diffusion, n’hésitez pas à y participer en prenant des initiatives à ce niveau.

  • Si vous comptez faire du Staking au lancement de la phase 0, préparez-vous et testez différents Validateurs.



Compléter le Skill Cube

Nous avons vu quelles options se présentaient à nous, en tant qu’éventuels early adopters, dès la première phase d’Eth2, avec la possibilité de nous impliquer directement, via le Staking en tant que Validateur. Cet article touche à la couche Protocoles, le protocole d’Ethereum. Il touche aussi, bien sûr, à la couche Monnaie, l’ETH va gagner un nouvel usage : celui d’assurer la sécurité d’Ethereum au sein du mécanisme de PoS.


Cet article est une traduction d’un article original de Danny Ryan publié le le 2 juin 2020 sur Ethereum.org. Nous tenons à remercier Patrick, Renaud, Sidonie et Sigri pour leurs contributions.

- Jon & Brice


Cette newsletter ne fait pas guise de conseil financier ou fiscal. Elle est strictement éducative, il ne s’agit pas de conseils d’investissement ou de propositions d’achat ou tout autre type de décisions financières. Cette newsletter ne comporte pas de conseils juridiques. Parlez en à votre comptable. Faites vos propres recherches.