Ethereum fusionne le testnet Kintsugi divisé par bug, voici pourquoi

L’événement de fusion sur le réseau Ethereum est la transition vers le modèle de consensus de preuve de participation à partir du modèle de preuve de travail actuellement utilisé. Cette fusion signifie que le système de réseau principal Ethereum actuel et la nouvelle chaîne Beacon, souvent appelée Ethereum 2.0, fusionneront en une seule blockchain.

Pour tester la fusion, le testnet Kintsugi a été déployé en décembre. Le but du testnet est d’exécuter différents cas limites et d’observer le comportement du système. L’un des développeurs impliqués dans l’exécution des tests sur Kintsugi est Marius van der Wijden, développeur principal Ethereum travaillant avec l’équipe client Geth (Go-Ethereum).

« Le testnet a fonctionné sans problème pendant quelques semaines. La semaine dernière, j’ai créé un fuzzer qui enverrait des blocs invalides. Un bloc contient beaucoup d’informations, comme les transactions, le hachage du bloc précédent, la limite de gaz, et cetera », explique Marius van der Wijden.

Certaines implémentations ne se sont pas exécutées et n’ont pas vérifié le bloc

Un fuzzer est un type courant d’outil de test utilisé par les développeurs pour générer des entrées aléatoires vers des fonctions ou d’autres morceaux de code, et essayer de les faire casser d’une manière ou d’une autre. Il s’agit de générer des entrées mal formées et inattendues et de surveiller ce qui arrive au système.

Le fuzzer créé par van der Wijden produit un bloc valide et en modifie un élément pour le rendre invalide. Une technique qu’il utilise consiste à changer un élément en un autre. Dans ce cas, le fuzzer a changé le blockhash en hachage parent.

« Les nœuds devraient rejeter un tel bloc modifié. Cependant, étant donné que le hachage parent pointait lui-même sur un bloc valide, certaines implémentations n’exécutaient et ne vérifiaient pas réellement le bloc, mais le cherchaient dans un cache à la place. Étant donné que le bloc précédent était valide et dans le cache, ils ont supposé que le nouveau bloc était également valide », explique van der Wijden.

Réseau divisé deux fois

Le résultat a été que la moitié du réseau, les clients Geth, a rejeté le bloc, tandis que l’autre moitié, les clients Nethermind et Besu, l’ont accepté, provoquant la scission de la chaîne puisque nous avions maintenant deux vues différentes de l’état correct. Pour aggraver les choses, il y avait un autre problème en plus.

Selon van der Wijden, les nœuds de la chaîne Geth, à leur tour, qui se composent de Lighthouse-Geth, Prysm-Geth, Lodestar-Geth, Nimbus-Geth et Teku-Geth, se sont également divisés entre eux.

« Cette division est toujours à l’étude, mais il semble que Teku pourrait également avoir un mécanisme de mise en cache qui a échoué », a déclaré van der Wijden.

Étant donné que plusieurs forks différents du réseau de test Kintsugi existent au moment de la rédaction, et que chaque nœud pense qu’ils sont sur un fork correct, le réseau n’est plus en train de se finaliser.

« Nous trouverons quelque chose pour rétablir le réseau. Nous avons déjà mis à jour le client Nethermind et ces nœuds sont maintenant sur la bonne chaîne. Nous avons toujours besoin du correctif pour Teku, car plus de 33 % des nœuds sont Teku, sinon la chaîne ne sera pas finalisée », déclare van der Wijden.

L’incident apporte du bien

Selon van der Wijden, cet incident n’interdit ni ne retarde de nouveaux tests de la fusion Ethereum, ni ne retarde la fusion elle-même. En fait, van der Wijden dit que l’incident aide en fait à tester des cas extrêmes qui auraient été difficiles à tester si le réseau fonctionnait correctement.

« Les longues périodes de non-finalisation sont difficiles pour les nœuds et il est très important pour nous de voir comment ils se comportent en ce moment. Nous pensons que le testnet finira par se remettre en place, mais je ne pense pas que nous essaierons de le réparer manuellement, car cela nous donne l’opportunité de tester des cas limites intéressants.

« Je ne pense pas que cela retardera la fusion, puisque la fusion n’est pas encore programmée. Mais cela montre à quel point les tests sont importants. Je pense que la fusion avance très bien. Nous avons besoin de quelques semaines supplémentaires pour obtenir le logiciel dans un état acceptable, puis nous avons besoin de quelques mois pour le tester », a déclaré van der Wijden.

Et si cela se produisait sur le réseau principal ?

Une question intéressante est de savoir ce qui se serait passé si un bogue comme celui-ci s’était produit sur la chaîne principale.

« Nous avons commencé les tests assez tôt, nous nous attendions donc à quelques bugs comme celui-ci. Un tel bogue sur le réseau principal serait cependant assez désagréable, car nous aurions besoin de trouver et de corriger le bogue, ce pour quoi nous sommes plutôt bons, de publier le code, puis de faire savoir à tous les acteurs qu’ils doivent mettre à jour leurs nœuds. La dernière partie est la partie la plus difficile à mon avis, car certains utilisateurs ne suivent pas le développement de trop près », déclare van der Wijden.

Pour plus de détails, le lecteur intéressé est invité à lire l’ouvrage de Marius van der Wijden tweets sur l’incident.