vendredi, 29 mars 2024

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

L’occasion de combiner sur le réseau Ethereum est la transition vers le modèle d’accord de preuve de participation à partir de la conception de preuve de travail actuellement utilisée. Cette fusion indique que le système de réseau principal Ethereum actuel et la toute nouvelle chaîne Beacon, souvent appelée Ethereum 2.0, fusionneront en une seule blockchain.

Pour vérifier la moissonneuse-batteuse, le réseau de test Kintsugi a été publié en décembre. La fonction 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 d’Ethereum chargé de l’équipe client Geth (Go-Ethereum).

« Le testnet a parfaitement fonctionné pendant un certain nombre de semaines. La semaine dernière, j’ai développé un fuzzer qui enverrait des blocs invalides. Un bloc se compose d’un grand nombre d’informations, comme les offres, le hachage du bloc précédent, la limite de gaz, et cetera », déclare Marius van der Wijden.

  • Certaines implémentations n’ont pas fonctionné et vérifié le blocage
  • Réseau divisé deux fois
  • L’incident apporte du bien
  • Et si cela se produit sur le réseau principal ?CryptoSlate Newsletter Certaines exécutions n’ont pas effectué et vérifié le bloc Un fuzzer est un type typique d’outil de test utilisé par les concepteurs pour générer des entrées aléatoires pour 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 imprévues et de surveiller ce qui arrive au système. Le fuzzer produit par van der Wijden produit un bloc valide et en modifie un aspect

    pour le rendre invalide. Une stratégie qu’il utilise consiste à changer un aspect en un autre. Dans ce cas, le fuzzer a modifié le hachage de bloc en hachage parent. « Les nœuds doivent refuser un tel bloc modifié.

    Néanmoins, étant donné que le hachage parent pointait vers un bloc légitime lui-même, certaines implémentations l’ont fait pas vraiment exécuter et valider le bloc, mais l’a plutôt recherché dans un cache. Étant donné que le bloc précédent était valide et dans le cache, ils ont supposé que le nouveau bloc était également légitime », décrit van der Wijden. Réseau divisé deux fois Le résultat a été que la moitié

    le réseau, les clients Geth

    , a refusé le blocage, tandis que l’autre moitié, les clients Nethermind-et Besu, l’ont accepté, déclenchant la division de la chaîne puisque nous avions maintenant deux points de vue différents sur l’état approprié. Pour aggraver les choses, il y avait une autre préoccupation en plus. Selon van der Wijden, les nœuds de la chaîne Geth,

    à leur tour, qui incluent 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 système de mise en cache qui a cessé de fonctionner », déclare van der Wijden. Considérant qu’un certain nombre de forks différents du réseau de test Kintsugi existent à la minute de la composition, et que chaque nœud

    pense qu’ils sont sur un fork correct, le réseau ne se finalise plus. « Nous trouverons quelque chose pour obtenir le réseau. Nous avons déjà mis à niveau 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’occurrence apporte quelque chose de formidable Selon van der Wijden, cette occurrence n’interdit ni ne retarde davantage de tests de la fusion Ethereum, ni

    elle ne reporte la fusion elle-même. En réalité, van der Wijden déclare que l’événement aide vraiment à vérifier les cas limites qui auraient été difficiles à tester si le réseau fonctionnait correctement. « Les périodes prolongées de non-finalisation sont un défi pour les nœuds et il est vraiment important pour nous de voir comment ils agissent en ce moment. Nous pensons que le testnet finira par se reconstituer

    , mais je ne pensez pas que nous essaierons de le réparer manuellement, car cela nous donne la possibilité d’évaluer des cas extrêmes intrigants. «  » Je ne pense pas que cela retardera la fusion, car la fusion n’est pas planifiée. le criblage essentiel est. Je pense que la moissonneuse-batteuse avance en fait bien. Nous avons besoin de

    quelques semaines supplémentaires pour obtenir l’application logicielle dans un état acceptable, puis nous avons besoin de quelques mois pour le tester « , van der États de Wijden. Et si cela se produisait sur le réseau principal ? Une question fascinante est de savoir ce qui se serait produit si un bogue comme celui-ci avait eu lieu sur la chaîne principale. « Nous avons commencé à évaluer assez tôt, nous nous attendions donc

    à quelques bogues 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 assez bons, de publier le code

    et après cela, faire comprendre à tous les joueurs qu’ils devraient mettre à niveau leurs nœuds. La fin est la partie la plus difficile à mon avis, étant donné que certains utilisateurs ne suivent pas le développement trop attentivement « , déclare van der Wijden. Pour plus d’informations, le lecteur intéressé est motivé à lire les tweets de Marius van der Wijden sur l’événement. Newsletter CryptoSlate Comprend un résumé des histoires quotidiennes les plus essentielles dans le monde sur la crypto, DeFi, NFT et plus encore.

    .

    Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici