Les développeurs d' Ethereum CORE débattent des avantages de hard forks plus fréquents

À quelle fréquence est-il trop fréquent de modifier le consensus ?

Un groupe de développeurs open source vétérans d'Ethereum a discuté du sujet lors d'une réunion bimensuelle vendredi, au cours de laquelle ils ont évoqué la possibilité que des mises à niveau à l'échelle du système, également appelées hard forks, du logiciel puissent être mises en œuvre aussi souvent que tous les trois mois.

Voulant « vérifier la température », le développeur posant la question a expliqué que certaines propositions d'amélioration Ethereum (EIP) à venir telles que loyers de l'Étatnécessiterait plusieurs mises à niveau espacées de manière séquentielle pour un effet complet.

Trois mois, cependant, aux yeux de Joseph Delong, ingénieur logiciel senior au studio de capital-risque Consensys, c'est « trop QUICK pour un retournement de situation ».

Péter Szilágyi, chef d'équipe de la Fondation Ethereum , est d'accord et explique :

En tant que développeur client [logiciel], si votre seule mission consiste à implémenter des hard forks et à les réaliser, trois mois suffisent, mais les clients nécessitent généralement beaucoup de maintenance. Par conséquent, si vous commencez à réaliser des hard forks sur trois mois, vous perdrez tout le temps consacré à la maintenance générale et à l'amélioration des performances.

Martin Hoste Swende, responsable de la sécurité de la Fondation Ethereum , tout en convenant qu'un hard fork tous les trois mois « serait une mauvaise chose », a noté que des cas particuliers avec des changements simples sur lesquels tout le monde s'accorde pourraient avoir des temps d'exécution plus courts.

« L'idée ne serait pas de planifier un hard fork tous les trois mois, mais de voir si la fonctionnalité X est terminée, si des cas de test existent et si elle est implémentée sur tous les clients. Si c'est le cas, nous pourrons alors effectuer un hard fork très prochainement », a expliqué Swende lors de la conférence téléphonique.

Mais encourageant les développeurs à mener leurs projets « étape par étape », Fredrik Harryson, directeur technique de Parity Technologies, a noté que même un délai de six mois pour un hard fork Ethereum prévu n'a jamais été atteint.

« Il y a probablement quelques éléments que nous devons automatiser pour réussir [les hard forks plus courts]. Une grande partie du temps consacré à un hard fork ne se limite pas à la création du code. Il s'agit de tout ce qui s'y rapporte », a déclaré Harryson.

En plus de cela, le conseiller de la Fondation Ethereum , Greg Colvin, a noté que la plupart des équipes qui créent des clients logiciels Ethereum n'ont pas actuellement « la bonne personne » pour gérer les tâches essentielles à la mise en œuvre du hard fork telles que « la mise en place de réseaux de test, l'exécution de cas de test, la réalisation de tests », entre autres responsabilités.

À cela, Harryson a répondu que le problème résidait dans le manque de moyens financiers pour intégrer ces membres de l'équipe. « Pour nous, c'est une question d'argent. Nous n'avons T assez d'argent pour cela », a plaisanté Harryson.

Mises à niveau en plusieurs étapes

Mais il ne s’agit pas seulement de savoir s’il faut ou non des hard forks plus fréquents.

Les développeurs ont également discuté lors de l'appel d'aujourd'hui de la nécessité de changements ambitieux et à plus long terme dans la blockchain Ethereum actuelle à la lumière d'un passage imminent à Ethereum 2.0 - un nouveau réseau Ethereum vers lequel, une fois entièrement activé, les utilisateurs migreraient depuis le réseau principal actuel.

Suggérant que des développeurs comme Alexey Akhunov et le fondateur Ethereum Vitalik Buterin ont mis en garde contre « les changements qui ne sont T pour la survie de la chaîne [actuelle Ethereum] », Harryson a demandé :

« Dans quelle mesure pouvons-nous nous écarter de cette approche, car [l’EIP 615] ouvre la voie à une longue série d’améliorations qui s’étendent sur plusieurs années avant que nous en constations les bénéfices considérables. »

L'EIP 615 est ONEune des cinq propositions envisagées pour le prochain hard fork Ethereum , Istanbul. Elle vise à améliorer le cœur même de la base de code Ethereum , la machine virtuelle Ethereum (EVM), responsable de l'exécution de toutes les lignes de code auto-déployables – également appelées contrats intelligents – sur la plateforme.

L'EVM est également une Technologies clé que d'autres initiatives de blockchain d'entreprise telles que Hyperledgeront été signalés dans le passé pour établir une interopérabilité avec.

La conception de l'EVM rend difficile une exécution performante et à faible coût de gaz. Nous proposons de proposer des solutions pour résoudre ces problèmes en renforçant les garanties de sécurité et en repoussant les limites de performance de l'EVM.écritles auteurs de l'EIP 615 Colvin, Brooklyn Zelenka, Pawel Bylic et Christina Reitwiessner.

Cependant, comme l'a noté Swende lors de l'appel d'aujourd'hui, l'EIP 615 tel que proposé nécessiterait au moins deux hard forks pour s'exécuter complètement et « un effet de vitesse positif » sur les calculs de code réels dans l'EVM ne serait pas perceptible jusqu'à ce que le dernier hard fork soit exécuté.

« C'est ma principale préoccupation concernant cet EIP. Cela représente beaucoup de travail, mais je ne pense T qu'il mènera à une meilleure EVM. Il pourrait être plus judicieux d'utiliser des outils externes, comme l'analyse inverse des propriétés de sécurité d'un contrat intelligent », a déclaré Swende.

Selon Zelenka, un tel outil est essentiel pour garantir une « compatibilité ascendante » continue avec les prochaines mises à niveau d'EVM comme eWASM et une expérience d'intégration fluide pour les développeurs de contrats intelligents à la lumière d'une « date de sortie indéterminée Ethereum 2.0 ».

« D'autres options s'offrent aux développeurs de contrats intelligents. Nous devons KEEP Ethereum 1.x en vie, ce qui implique de poursuivre notre progression », a expliqué Zelenka lors de la conférence téléphonique d'aujourd'hui.

Acceptant de poursuivre le débat et la discussion sur l'EIP dans les semaines à venir, Swende a conclu qu'à l'heure actuelle, il reste sceptique quant à « la mise en œuvre de changements aussi importants dans l'ancien moteur, qui nécessite essentiellement quelques hard forks avant de se stabiliser définitivement ».

Mais partageant le sentiment incertain concernant l'avenir d' Ethereum 2.0, Harryson, qui a soulevé la question initiale sur les mises à niveau ambitieuses et multi-hard forks, a déclaré :

« Nous ne devrions T ajuster notre feuille de route ou notre réflexion en fonction de ce que sera ou ne sera pas Ethereum 2.0. »

Image de la fourche via Shutterstock