L'avenir des mises à niveau d'Ethereum, après la fusion [Partie 2]

La plus grande mise à jour d'Ethereum - le passage à un mécanisme de consensus de preuve de participation - est imminente. Mais alors que la fusion devrait ajouter de la sécurité et de la durabilité, elle n'inclut pas le sharding, la méthode attendue depuis longtemps pour faire évoluer le réseau. 

In Partie I de notre conversation avec le chercheur de la Fondation Ethereum (EF), Danny Ryan, qui a aidé à coordonner le processus de mise à niveau, nous avons discuté de ce que la fusion est conçue pour apporter en termes de sécurité et de stabilité.

Dans la partie II, Ryan parle des mises à niveau auxquelles les utilisateurs peuvent s'attendre à l'avenir, y compris le danksharding, l'Ethereum sans état et les mises à jour de sécurité qui luttent contre l'augmentation de la valeur extractible des mineurs (MEV). Il explique également comment cet effort de plusieurs années a abouti à de nouvelles méthodes de recherche et de test des futures mises à niveau.

---

Coordination sur un réseau décentralisé

AVENIR : Vous avez fait allusion à la possibilité que les mineurs bifurquent et continuent d'essayer d'utiliser l'ancienne chaîne. Mais pour la plupart, ce processus a permis à tout le monde d'embarquer. Quel est votre rôle là-dedans en tant que chercheur de la Fondation Ethereum ? Comment un mouvement aussi massif est-il coordonné ?

DANNY RYAN : J'ai commencé à m'impliquer dans des trucs de preuve de participation vers 2017, et même alors, c'était comme une fatalité. C'était il y a cinq ans. Et la communauté Ethereum a été très disposée à ne pas stagner et à bien faire les choses, et à construire un protocole qui ne fonctionne pas seulement aujourd'hui, mais qui fonctionne, espérons-le, pendant 100 ans ou plus. 

Ainsi, au début de sa philosophie, quand il y avait une intuition que la preuve de l'enjeu pouvait être faite en toute sécurité et mieux que la preuve du travail, les gens étaient très enthousiastes à ce sujet. Et au moment où 2016, 2017 arrivent, les gens sont non seulement excités à ce sujet, mais ils sont anxieux pour que cela se produise. Il semble que ce soit très profond dans l'éthique de la communauté Ethereum que cela se produise.

Il y a des sujets plus sensibles. Il y a moins de conclusions anticipées où l'EF, l'équipe de recherche et les clients qui sont en dehors de l'EF essaient tous de trouver des solutions aux problèmes et de faire avancer les choses. Parfois, les solutions se trouvent un peu plus dans une zone grise - est-ce la bonne solution ? Le faisons-nous maintenant ? Est-ce qu'on le fait plus tard ? Cela finit par être difficile, et l'EF tente d'aider à coordonner ces méthodes, d'aider à faire de la R&D pour aider à examiner les solutions, d'aider à faciliter les conversations pour décider des délais, des priorités et des commandes. 

Mais en fin de compte, sur la plupart des points, l'agenda EF est d'aider à rendre le protocole plus durable, sécurisé et évolutif tout en étant décentralisé - et non d'expédier une fonctionnalité particulière sur l'autre. Donc, une grande partie de ce sur quoi nous nous concentrons en matière de travail technique et de coordination sociale consiste à faciliter une bonne information, une bonne recherche et un bon dialogue afin que les nombreux participants impliqués dans la R&D, l'ingénierie et la communauté puissent continuer les choses bougent et arrivent à des décisions.

Au cours des cinq dernières années, beaucoup plus de voix se sont ajoutées à la communauté, et après la fusion, cela va théoriquement devenir plus décentralisé. Que pensez-vous du futur processus de mise à niveau ? Est-il possible que nous envisagions une sorte de DAO de couche un pour coordonner les mises à niveau ?

Si je comprends bien, la communauté Ethereum n'est pas dans le vote en chaîne - ou toute sorte de vote ploutocratique et de mises à niveau - et que le protocole est celui que les utilisateurs décident d'exécuter. Généralement, il y a un large consensus. Parfois, il y a des schismes - par exemple, Ethereum contre Ethereum classique. Mais en fin de compte, c'est votre droit et celui de la communauté et des droits des utilisateurs de déterminer quel logiciel ils veulent exécuter. En général, nous sommes d'accord parce que les gens essaient d'améliorer Ethereum, et il n'y a pas beaucoup de conflits dans certains des éléments de base. 

Je ne m'attends donc pas à un mécanisme technique formel. Je m'attends à ce que le processus continue de croître, de changer et d'évoluer dans ce type de gouvernance lâche, où il y a des chercheurs, il y a des développeurs, il y a des membres de la communauté, il y a des dapps, et des choses comme ça. 

Je dirais que — et je pense que vous y avez fait allusion — il y a de plus en plus de monde autour de la table, et il devient de plus en plus difficile de prendre des décisions et d'expédier des choses. Je crois personnellement que c'est une caractéristique. Je pense que tant du point de vue de la fiabilité des applications et des utilisateurs que de l'évitement de la capture à long terme, il est probablement important qu'une grande partie du protocole Ethereum s'ossifie. Donc, même s'il est de plus en plus difficile d'être dans le tourbillon de la gouvernance et d'essayer d'expédier, et parfois j'ai l'impression d'essayer de courir avec un gilet lesté et des poids sur mes chevilles et maintenant j'ai des poids sur mes poignets, je pense que nous avons des choses essentielles à faire au cours des prochaines années. Mais je pense que ça va être de plus en plus difficile de faire avancer les choses. Et je pense que c'est une bonne chose.

Vitalik l'appelle "vitesse de fuite fonctionnelle.” Amenons Ethereum à un endroit où il a une échelle et des fonctionnalités suffisantes pour qu'il puisse être étendu et utilisé d'une multitude de façons infinies dans la couche suivante de la pile. Faites en sorte que l'EVM ait un minimum de fonctionnalités suffisantes, qu'il y ait suffisamment de données disponibles pour gérer des quantités massives d'échelle, puis les applications peuvent l'étendre dans des contrats intelligents. Les couches deux peuvent expérimenter de nouvelles machines virtuelles à l'intérieur de leurs constructions de couche deux ; vous pouvez faire évoluer Ethereum et ainsi de suite.

Je pense que ça va être de plus en plus difficile de faire avancer les choses. Et je pense que c'est une bonne chose.

Fourches d'ombre

L'une des choses qui est ressortie de ce processus de test spécifique était les fourches fantômes, le processus de copie de données Ethereum réelles sur un réseau de test pour simuler un environnement de test de réseau principal. Était-ce toujours dans le plan? Et comment pensez-vous que cela pourrait changer le processus de R&D pour les futures mises à niveau ?

Nous aurions dû faire des shadow forks depuis quatre ans. Ils sont super; ils sont vraiment cool. Je prends essentiellement un certain nombre de nœuds que nous contrôlons - appelez-le comme 10, 20, 30 - et ils pensent qu'un fork arrive, donc ils sont sur le réseau principal ou l'un de ces réseaux de test, puis à une certaine condition de fork, comme la hauteur du bloc, ils vont tous, "D'accord, nous sommes sur le nouveau réseau." Et ils bifurquent et traînent ensuite dans leur propre réalité, mais ils ont l'état de la taille du réseau principal.

Et pendant un certain temps, vous pouvez diriger les transactions du réseau principal vers cette réalité fourchue pour obtenir une quantité raisonnable de ce qui ressemble à une activité organique des utilisateurs, ce qui est vraiment bien. Cela nous permet de tester ce qui s'est avéré être des processus hautement organiques difficiles à simuler. Et c'était super. Par [Jayanthi] et d'autres qui travaillent dans l'équipe DevOps d'EF les ont orchestrés, et nous avons beaucoup appris d'eux. Je pense que si vous demandez à quelqu'un, il vous dira : "Eh bien, oui, cela aurait été formidable si nous faisions cela il y a trois ans, il y a quatre ans à chaque mise à niveau."

Mais je dirai autre chose. Je le dis [depuis] il y a un an et maintenant nous sommes dans la longue traîne en matière de sécurité et de test : c'est vraiment marteler cette chose, s'assurer que tous les cas extrêmes sont corrects, s'assurer que quand ça arrive, ça arrive - nous prenons un coup dessus et ça marche. Et il s'avère que la façon dont le logiciel est construit avec des clients de couche d'exécution consensuelle, il y a juste beaucoup à construire en termes de test. Les fourches de l'ombre en font partie. En utilisant d'autres environnements de simulation qui peuvent tester ces deux choses ensemble, comme Kurtosis, AntithèseEt autres. 

Il y a d'autres choses que nous devons faire, comme le recâblage Ruche, qui est notre infrastructure de test d'intégration nocturne, afin qu'il puisse gérer ces deux types de clients et que vous puissiez écrire des tests où différentes complexités se produisent des deux côtés de l'allée. Tout cela devait arriver. Premièrement, les cadres devaient être développés ou modifiés. Ensuite, beaucoup de tests ont dû être écrits. Donc, la bonne chose avec la fusion est que nous avons vraiment amélioré les outils de notre ceinture d'outils pour pouvoir tester les mises à niveau de telle sorte que la prochaine mise à niveau consistera beaucoup plus à écrire les tests plutôt qu'à réfléchir à la façon même de le tester et écrire les frameworks pour le tester. 

Qu'y a-t-il après la preuve de mise ?

Comme cela dure depuis longtemps, le partage devait initialement passer en premier. Mais les développements de l'écosystème signifiaient que vous pouviez d'abord passer à la preuve d'enjeu. Y a-t-il eu d'autres développements de l'écosystème qui sont apparus au cours de ce processus et qui pourraient faire évoluer votre approche vers de futures mises à niveau ?

Tout d'abord, il y a probablement un certain nombre de raisons pour lesquelles le changement de preuve de participation a été priorisé. L'une était d'arrêter de payer trop cher pour la sécurité avec une preuve de travail. Et l'autre était que l'échelle commençait à apparaître à travers ces constructions à deux niveaux. Donc, peut-être que si vous avez une échelle de 10 à 100x à partir de cela, vous pouvez vous concentrer sur cette autre chose et terminer le travail et unifier ces deux systèmes disparates : la chaîne de balises et le réseau principal actuel. 

Il y a d'autres choses qui ont influé sur notre façon de penser les échéanciers et les priorités. J'ai mentionné plus tôt que l'ensemble du monde MEV a jeté une clé dans certaines choses. Il y a la centralisation et d'autres problèmes de sécurité qui émergent lorsque vous commencez à penser à où MEV pourrait aller. Et il y a eu beaucoup de recherches au cours des 12 derniers mois et plus sur la façon d'atténuer certaines de ces préoccupations avec des modifications de couche un. En fonction de l'analyse des menaces provenant du monde MEV, cela pourrait donner la priorité à certaines fonctionnalités de sécurité et à des ajouts de sécurité à L1 par rapport à quelque chose d'autre qui devait peut-être être la priorité. 

Je pense que quelque chose d'intéressant est la feuille de route du sharding et la construction actuelle attendue, appelée danksharding, du nom Dankrad [Feist], notre chercheur à l'EF. Toute la construction est en fait simplifiée lorsque vous supposez que ces acteurs MEV hautement incités existent. Non seulement certains de ces acteurs externes ont modifié notre façon de penser la sécurité, mais ils modifient également la façon dont nous pouvons penser la construction de ces protocoles. Si vous supposez que le MEV existe, si vous supposez que ces acteurs hautement incités sont prêts à faire certaines choses à cause du MEV, alors tout d'un coup, vous avez ce participant tiers dans le consensus sur lequel vous pouvez peut-être décharger des choses, ce qui à bien des égards peut être simplifiant. Il n'y a donc pas que de mauvaises choses qui arrivent, mais il y a aussi de nouveaux types de conceptions qui s'ouvrent.

Nous avons vraiment amélioré les outils de notre boîte à outils pour pouvoir tester les mises à niveau de telle sorte que la prochaine mise à jour consistera beaucoup plus à écrire les tests plutôt qu'à réfléchir à la façon de les tester.

L'Ethereum sans état fait-il toujours l'objet de discussions et de recherches actives ? 

Oui. L'état - tous les comptes et contrats et soldes et tout - c'est l'état d'Ethereum. Étant donné où vous vous trouvez dans la blockchain, il y a un état de réalité. Cette chose grandit avec le temps, grandit linéairement. Et si vous augmentez la limite de gaz, elle augmente encore plus vite. C'est donc une préoccupation. S'il croît plus rapidement que la mémoire et l'espace disque dur des machines grand public, vous rencontrez des problèmes pour pouvoir exécuter des nœuds sur des ordinateurs personnels et du matériel grand public, ce qui pose des problèmes de sécurité et de centralisation. Aussi, si vous parlez à certains des GETH membres de l'équipe [client], le fait que l'état continue de croître signifie qu'ils doivent continuer à optimiser les choses. Alors c'est dur.

Stateless Ethereum et les choses dans cette direction de recherche sont une voie de solution potentielle pour cela, où pour exécuter un bloc, je n'ai pas réellement besoin de l'état entier ; il y a une sorte de cette entrée cachée lors de l'exécution de la fonction d'un bloc. J'ai besoin du pré-état, j'ai besoin du bloc, puis j'obtiens le post-état pour savoir si le bloc est valide. Alors qu'avec Ethereum sans état, les conditions d'état - les comptes et autres éléments dont vous avez besoin pour exécuter ce bloc particulier - sont intégrées dans le bloc et prouvent qu'il s'agit du bon état. Maintenant, exécuter un bloc et vérifier la validité d'Ethereum devient simplement [avoir] pour avoir le bloc, ce qui est vraiment bien. Maintenant, nous pouvons avoir des nœuds complets qui n'ont pas nécessairement un état complet. Cela ouvre tout un éventail sur la façon de construire des nœuds. Donc, je peux avoir un nœud qui valide complètement et qui n'a pas l'état, je peux avoir un nœud qui garde juste l'état pertinent pour moi, ou je peux avoir des nœuds très complets qui ont tout l'état et ce genre de choses.

Ceci est activement travaillé. Il y a en fait, je crois, actuellement un testnet avec toutes les autres choses amusantes qui doivent arriver pour que cela se produise. Mon évaluation actuelle est que la demande de partitionnement et d'échelle L1 est supérieure à la menace imminente de croissance de l'État. Il est donc très probable, comme l'un sera prioritaire sur l'autre, que l'échelle sera prioritaire. 

Cela dit, c'est difficile à dire. Il y a "proto-danksharding", ce qui est un peu comme une manière progressive d'obtenir un peu plus d'échelle. Peut-être que cela se produit, puis l'apatridie se produit, puis le partage complet se produit, en fonction des besoins et de l'évaluation de ce qui se passe et des menaces impliquées. Je pense que l'opinion générale sur la croissance de l'État est que nous devons avoir un chemin et nous devons le réparer, mais [que] les incendies imminents ont été éteints et que ce n'est pas une chose qui paralysera Ethereum au cours des deux prochaines années. Mais c'est une chose qui doit être corrigée.

Expliquez-moi les améliorations que nous do savoir après la fusion. Y aura-t-il une mise à niveau de nettoyage ? Est-ce distinct de la mise à niveau de Shanghai ? Et quand le sharding est-il introduit ?

Shanghai sera probablement le nom de la bifurcation après la fusion. Pour retirer réellement vos fonds que vous jalonnez depuis près de deux ans maintenant - [cela n'est] pas activé lors de la fusion. Au départ, on s'attendait à ce qu'elles soient faites, mais étant donné la complexité de la fusion, au fil du temps, il a été décidé de vraiment la supprimer et de simplement faire la fusion et de ne pas ajouter la fonctionnalité supplémentaire des retraits. Je m'attendrais très, très, très bien à ce que les retraits soient activés à Shanghai - donc, la première mise à niveau après la fusion. Cela a été promis à de nombreuses personnes qui ont beaucoup de capital en jeu et je ne m'attends pas à un problème avec cela. Ceux-ci sont généralement spécifiés, il y a des tests écrits, et ce genre de choses. 

Il y a un certain nombre d'autres améliorations EVM [Ethereum Virtual Machine] qui, je pense, pourraient être intégrées à ce système - différentes opérations mathématiques, certaines choses d'extensibilité différentes, une version un peu meilleure dans l'EVM et d'autres fonctionnalités. C'est un peu une soupape de décharge de pression sur les améliorations EVM, qui ont été mises de côté depuis plusieurs années maintenant pour faire la fusion et d'autres mises à niveau. Et les gens veulent vraiment voir une sorte de mise à niveau mineure de l'évolutivité ici. Il pourrait donc s'agir soit de proto-danksharding, qui jette les bases d'un partage complet et gagne un peu plus d'échelle, soit potentiellement de réductions du prix de l'essence calldata, qui sont très faciles mais ne sont pas vraiment une solution durable. C'est donc ce à quoi nous nous attendons, espérons-le, à Shanghai : des retraits et un peu d'échelle.

Alors la question est : Qu'est-ce qu'il y a après ça ? Et c'est difficile à dire. Si nous obtenons un peu d'échelle là-bas, et que cela complète très bien les L2 et que les choses vont plutôt bien, alors peut-être qu'il y a une demande pour faire des apatrides à ce stade. Ou si les L2 ont un besoin insatiable de plus d'échelle, alors peut-être que cela prépare le terrain pour le danksharding complet.

Cette interview a été éditée et condensée. 

Publié le 27 juillet 2022