Eth2 Dev parle des défis et des leçons apprises avant le lancement du réseau principal

Malgré certaines «conséquences imprévues», les réseaux de test ont joué un rôle déterminant dans les tests de résistance d’Eth2.

Après des années de retards et de changements dans les plans, Ethereum 2.0 approche enfin de sa sortie le 1er décembre.

Ethereum 2.0 Phase 0 introduit le mécanisme de jalonnement tant attendu sur la plate-forme de contrat intelligent, en plus de lancer le squelette d’une future blockchain Eth2, la Beacon Chain.

Les progrès en 2020 se sont régulièrement accélérés à mesure que de plus en plus de réseaux de test ont été introduits et réitérés . Bien qu’ils aient réussi globalement, ils n’étaient pas exempts de problèmes liés à la synchronisation et à la production de blocs .

Une partie de ces problèmes venait du défi de garder le même rythme entre sept clients différents, ou le logiciel de nœud Ethereum 2.0, fonctionnant avec différents langages de programmation et piles technologiques.

Interview avec Zahary Karadjov, développeur de recherche chez Nimbus – l’un de ces clients – pour en savoir plus sur la route qu’Ethereum 2.0 a parcourue jusqu’à présent et sur les prochaines étapes du voyage.

L’interview a été légèrement modifiée pour la longueur et le contexte.

Nimbus semble avoir eu quelques problèmes supplémentaires pour rattraper les spécifications partagées d’Ethereum 2.0. Pourquoi pensez-vous que c’est?

Zahary Karadjov: Nous étions très occupés à préparer Nimbus pour le réseau principal. Il est juste de dire que cela a été un peu plus difficile pour nous, car il nous a fallu un certain temps pour développer certains des composants que les autres équipes avaient déjà disponibles – plus précisément, la couche réseau Libp2p.

C’est quelque chose que nous avons dû construire à partir de zéro, et il nous a fallu beaucoup de temps pour le stabiliser. Il y a eu quelques mois où nous avons eu du mal avec la performance. Ce n’est que récemment que nous avons publié notre première version stable. Mais pour le moment, nous sommes confiants pour mainnet: nous travaillons sur le dernier des petits problèmes, et notre audit est également terminé.

Prysm et Lighthouse – qui, similaires aux clients Ethereum 1.0 existants ont été construits respectivement dans Go et Rust – semblent avoir été en avance sur les autres jusqu’à présent. Est-ce parce qu’ils ont pu s’appuyer sur le travail effectué pour Ethereum 1.0?

ZK: Mon explication sera une simplification, car de nombreux facteurs sont impliqués. Mais je dirais que le développement de Libp2p a été la source la plus importante de retards pour nous. Et la logique est facile à voir ici: Teku, qui est développé en Java, n’avait pas non plus d’implémentation Libp2p, et il est également devenu prêt à un stade un peu plus tard.

L’équipe Prysm a eu le luxe de faire développer Libp2p il y a très longtemps, comme il était initialement développé en Go, tandis que Lighthouse a pu profiter de l’implémentation créée, encore une fois, il y a assez longtemps par l’équipe Parity pour son travail sur À pois.

Libp2p est la couche réseau d’Ethereum 2.0 – vous pouvez dire que c’est une technologie complètement différente de celle utilisée dans Ethereum 1.0. En termes très pratiques, il s’agit d’une technologie de publication-abonnement appelée Gossipsub, qui est un moyen optimisé de diffuser des informations sur le réseau.

Parlons du testnet Medalla. Quelles leçons Nimbus et la communauté Eth2 ont-elles apprises, en particulier compte tenu des périodes où la blockchain ne fournissait pas de garanties de finalité de bloc?

ZK: Eh bien, les luttes avec la finalité ont commencé par un problème technique. Il y a le célèbre incident Cloudflare Roughtime, qui a démontré exactement ce dont nous parlions dans notre conversation précédente . Si tout le monde sur le réseau utilise le même client, un problème technique dans ce client particulier pourrait mettre de nombreux validateurs hors ligne, ce qui peut immédiatement rendre le réseau dans un état de non-finalisation.

Nous avons eu ce problème avec le client Prysm, et il a également enseigné une leçon importante sur l’importance de la communication. L’équipe Prysm a été en mesure de résoudre ce problème en très peu de temps – quelques heures seulement. Mais il a fallu un certain temps à la communauté pour réaliser qu’il y avait un problème et déployer le correctif.

C’était l’incident initial qui a créé une longue période de non-finalisation pour Medalla. Mais cela a en fait été très utile pour les clients car lorsque le réseau n’est pas en train de se finaliser, les clients doivent envisager de nombreuses fourchettes possibles et des historiques alternatifs, ce qui met beaucoup de stress sur les clients. Ainsi, ces longues périodes de non-finalisation nous ont permis de voir et d’optimiser les clients pour ces moments stressants dans le réseau où tout ne fonctionne pas comme prévu.

Pendant le testnet et la période de non-finalité, certains utilisateurs se sont plaints que leur mise était réduite même s’ils étaient en ligne. Est-ce un bogue ou une fonctionnalité du système?

ZK: Vous pourriez le décrire comme une conséquence imprévue. En gros, le problème est que le client est récompensé pour les attestations diffusées sur le réseau. Mais ces attestations sont censées être incluses dans des blocs. S’il n’y a personne pour produire des blocs, vos attestations ne finissent pas dans la chaîne. Donc, il semble que vous n’êtes pas actif.

Je pense que cette question est bien reconnue et reconnue par l’équipe de mise en œuvre et l’équipe de recherche. Il devrait être abordé dans le futur d’Ethereum – dans la phase 1, voire la phase 0.5, l’une des toutes premières mises à niveau du réseau. Mais nous ne devons pas oublier qu’il serait tout à fait inattendu de constater de faibles taux de participation sur le réseau principal, car lorsqu’il y a un réel enjeu, les motivations pour les validateurs à être en ligne sont beaucoup plus fortes.

Pensez-vous que ces complexités et l’exigence d’être constamment en ligne pourraient dissuader les gens de jouer avec leurs propres appareils?

ZK: Eh bien, c’est une idée fausse très courante selon laquelle je pense que nous devrions faire un bien meilleur travail de communication. En fait, les risques de ne pas être en ligne tout le temps ne sont pas si grands. Vous ferez un profit si vous êtes en ligne plus de 50% du temps. Pensez-y: vous pouvez être hors ligne pendant la moitié de l’année, et vous serez toujours à zéro. Vous ne gagnerez pas d’argent, mais vous ne perdrez pas non plus d’argent. Le protocole est assez indulgent à cet égard.

Que se passe-t-il après le lancement de la phase 0 sur le réseau principal? Le sharding est-il la prochaine mise à jour de la liste ou prévoyez-vous plus de travail pour cette première chaîne de balises?

ZK: Il y aura certainement des mises à niveau à venir avec l’intégration de la phase 1, et cela nécessiterait des changements de rupture – ou appelons-le simplement un hard fork – où les équipes clientes publieront de nouveaux logiciels à mesure que de nouvelles fonctionnalités seront mises en ligne. Nous prévoyons le déploiement du gadget de finalité à un moment donné, qui finalisera la chaîne Ethereum 1.0 via le mécanisme de consensus d’Ethereum 2.0. Toutes ces versions en cours vont se produire en parallèle. Ils sont un peu indépendants les uns des autres et font partie de la feuille de route Ethereum pour les prochaines années.

Laisser un commentaire