Rejoignez-Nous sur

Ethereum 2.0 Testnet se divise en 4 fourchettes – Trustnodes

ethereum 2.0 testnet standing chain after forks aug 2020

News

Ethereum 2.0 Testnet se divise en 4 fourchettes – Trustnodes

Il y a actuellement quatre ou cinq fourchettes principales sur le réseau de test ethereum 2.0 (photo) suite à un bogue qui fait tomber les nœuds Prysm et l'ensemble du réseau.

«Nous devons amener tous les clients à s'entendre sur la tête actuelle. Cela cause également des ravages de synchronisation avec des pairs qui se joignent et revendiquent des vues différentes de la chaîne. Il existe une gamme de cas extrêmes et de correctifs que nous déploierons tout au long de la semaine pour résoudre tous ces problèmes », déclare Age Manning de Lighthouse.

"Il saute de haut en bas partout … c'est comme s'il ne pouvait pas décider", dit quelqu'un qui exécute le client prysm avec Nishant Das, un développeur prysm, déclarant: "Oui, beaucoup de réorganisations."

«Il existe de nombreuses fourchettes différentes en ce moment et certains nœuds sont coincés très loin derrière, vous obtenez donc toutes ces demandes de blocage parent pour essayer de le résoudre, mais la principale est actuellement affichée sur eth2stats qui a un consensus entre phare et prysm », déclare Raul Jordan, un autre développeur prysm.

En raison de toutes ces fourches, les besoins en RAM ont monté en flèche vers minuit aujourd'hui, heure de Londres, atteignant 70 ou 80 gigaoctets.

«Les techniques de compression de base de données les plus efficaces surviennent après la finalité», explique Paul Hauner de Lighthouse. "Nous avons également constaté des problèmes avec la base de données qui empêchent l'élagage, mais je ne suis pas sûr que cela joue un rôle ici."

La situation semble maintenant s'être améliorée de manière significative depuis environ 12 heures, avec plus d'atteindre la tête de bout de chaîne.

Les coureurs de nœuds sont invités à le laisser s'exécuter s'ils le peuvent, au lieu de redémarrer car cela perd simplement toute la synchronisation jusqu'à ce point. Aussi:

«J'utilise –block-batch-limit = 512 et –p2p-max-peers = 200 semble être en train de marcher», déclare un coureur de nœuds.

Le paramètre d'homologue max ne fait pas partie de la recommandation des développeurs, mais la limite du lot de blocs est, avec Das indiquant:

"Ainsi, lorsque vous êtes bloqué, vous passez en revue vos pairs pour essayer de vous en débarrasser. L'utilisation de lots de plus grande taille fera passer ces pairs plus rapidement."

Un certain nombre d'individus déclarent avoir obtenu une erreur concernant le blocage du parent de requête. Il leur est demandé de simplement l'ignorer car le nœud traverse toutes les fourches avec Preston Van Loon publiant une arborescence du réseau.

Apparemment, vous pouvez obtenir cet arbre en allant à localhost:8080/tree, quel type de vous permet de voir comment la chaîne fonctionne.

Comme vous vous en doutez, cela montre au départ qu'une chaîne fonctionne bien, puis nous en avons deux, et elles ont leur propre chaîne, qui finissent toutes par tomber avec une chaîne en marche à nouveau.

Ethereum 2.0 Testnet Standing Chain, août 2020
Ethereum 2.0 Testnet Standing Chain, août 2020

Les nouveaux nœuds ont apparemment juste besoin de passer par la synchronisation, et ils doivent prendre conscience de ces fourches, puis ils déposent ces fourchettes avec le nœud, puis sautent à la pointe valide.

Apparemment, cela doit atteindre un taux de participation de 66%, ceux qui ont chuté étant coupés jusque-là:

eth2 testnet slashed earnings aug 2020
Le coureur de nœud testnet Ethereum 2.0 est coupé.

Cet éthéré gagnait bien un peu d'argent en ne faisant effectivement rien après avoir activé la configuration du nœud.

De plus, même après la réduction, il est toujours bénéficiaire, mais vous pouvez voir que la montée était beaucoup plus lente que la descente. Il gagnait à la journée, il perd maintenant à l’heure.

Cela signifie qu'il a de très grandes incitations à se synchroniser car plus tôt lui et d'autres peuvent atteindre le bout de la chaîne, plus vite il revient à gagner plutôt que de perdre de l'argent.

Les développeurs font de leur mieux pour l'aider sur le chemin, essayant différentes astuces et solutions tout en aidant tous ceux qui ont besoin d'aide sur leur discorde.

Quelques-uns ont fièrement annoncé qu'ils avaient atteint la pointe, avec ce qui était un effet domino en descendant potentiellement un effet domino à la montée car plus il y avait de nœuds à la pointe, plus de nœuds pouvaient se synchroniser.

«Medalla est loin d'être morte, elle peut être réparée», dit Loon et elle doit être réparée car cela pourrait également se produire en direct.

Bitcoin, par exemple, a eu des fourches fractionnées en chaîne deux fois ou plus sur le réseau principal après qu'un bogue lors d'une mise à niveau ait amené les mineurs à être sur des versions différentes.

Le réseau Bitcoin continue cependant de fonctionner pendant cette période, ce qui conduit à des annonces sur les réseaux sociaux invitant les gens à attendre 100 confirmations ou plus.

Alors qu'ici, si 34% sont assommés, le réseau s'arrête jusqu'à ce qu'ils se comportent.

C'est une histoire en développement, donc comment ils se comportent exactement reste à voir car aucun nouvel emplacement / bloc n'a été trouvé car la chaîne n'est pas en train de se finaliser.

Faire de tout cela un exercice de ce qui pourrait potentiellement se produire en direct lorsque des bogues surviennent malgré le plus grand soin apporté aux leçons apprises, comme avoir une méthode pour exporter rapidement les clés vers d'autres clients. Un développeur prysm dit:

«L'intérêt d'avoir plusieurs clients est que vous pouvez passer à une alternative si quelque chose ne fonctionne pas correctement dans votre client principal.

Lorsque nous avons eu des problèmes de temps libre hier, cela aurait pu être une bonne idée de passer à un autre client pour éviter une pénalité de vivacité. "

Le temps était donc un moyen prétendument décentralisé de synchroniser le temps qui s'est avéré pas très décentralisé car six sources de temps différentes pour une raison quelconque ont fait avancer les nœuds prysm de quatre heures, donnant une erreur et donc le panne réseau. Das dit:

«Le bloc qui arrive a également un numéro de slot à travers lequel nous déterminons s'il est valide ou non. Fondamentalement, genesis_time + slot_Num * slot_time.

Si un nœud pense qu'il est dans 4 heures dans le futur, il rejette ce bloc car il semble qu'il vient du passé.

Cela perturbe également la proposition de blocage des validateurs de prysm, car l’horloge locale selon le validateur a 4 heures d’avance. »

Le correctif pour cela était quelque peu simple de ne pas passer par défaut à roughtime, ce qui a conduit aux développements intéressants qui se déroulent maintenant sur testnet qui est avec un faux eth donc rien n'est perdu et beaucoup est gagné.

De plus, si le réseau reprend vie grâce aux mécanismes codés qui entrent en jeu, cela ne devrait pas retarder le lancement en direct, car tout se serait passé comme il est censé se produire, le bogue lui-même étant très minuscule en supposant qu'il n'y en a pas. complications liées au code avec les mécanismes qui se sont déclenchés.



Traduction de l’article de Trustnodes : Article Original

BlockBlog

Le Meilleur de l'Actualité Blockchain Francophone & Internationale | News, Guides, Avis & Tutoriels pour s'informer et démarrer facilement avec Bitcoin, les Crypto-Monnaies et le Blockchain. En Savoir Plus sur L'Équipe BlockBlog

Commenter cet Article

Commenter cet Article

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Plus dans News

Les Plus Populaires

Acheter des Bitcoin

Acheter des Alt-Coins

Sécuriser vos Cryptos

Vêtements et Produits Dérivés

Top