Le réseau Ethereum se bat avec les créneaux horaires manqués, bloXroute et Lighthouse en débat

Plus tôt cette semaine, le réseau Ethereum a connu une augmentation significative du nombre de créneaux manqués, provenant principalement de blocs relayés par les relais bloXroute. Les enquêtes ont révélé que même si bloXroute relaie efficacement les blocs et les blobs publiés, la propagation rapide des blocs à travers le réseau distribué (BDN) de BloXroute contrastait avec la propagation plus lente des blobs via les canaux peer-to-peer (p2p). Cette divergence a mis en évidence un comportement spécifique du client (CL), conduisant au rejet de blocs par le client et à des emplacements manqués ultérieurs.

Résoudre les emplacements manqués d'Ethereum avec bloXroute

Le PDG de BloXroute Labs, Uri Klarman, a expliqué dans un fil de discussion détaillé sur Github ce qui s'est passé concernant les emplacements manqués dans Ethereum.

Dans la version actuelle de Lighthouse, les nœuds s'attendent à ce que le même homologue fournissant le bloc fournisse également les blobs. Cependant, comme le BDN ne propage pas les blobs, les nœuds de consensus connectés au BDN ignorent les blocs initialement reçus de celui-ci. Une version récente de BDN visait à accélérer la propagation des blocs sans blobs, en s'appuyant sur le réseau p2p pour diffuser les blobs si nécessaire. Ce changement a entraîné par inadvertance une augmentation significative du nombre de créneaux manqués.

Klarman a expliqué que le BDN s'appuie fortement sur Lighthouse, qui constitue la majorité des nœuds balises de bloXroute. Les premières observations post-version ont indiqué une propagation réussie des blocs à travers le BDN, affectant principalement les relais bloXroute en raison de leur intégration étroite avec le BDN.

Pour résoudre ce problème, une série de tests ont été effectués, isolant le problème du comportement de Lighthouse lorsqu'il rencontre d'abord des blocs via le BDN. Des mesures ont été prises pour abandonner progressivement l'utilisation du BDN par les relais pour la publication de blocs, puis pour désactiver la propagation des blocs du BDN contenant des blobs.

Tout au long de cette période, les relais bloXroute ont continué à fournir des blocs avec des blobs aux validateurs et à publier des blocs avec des blobs au BDN et au réseau de nœuds balises. Cependant, ces demandes de publication ont renvoyé une réponse 202 car les nœuds balises avaient déjà reçu le bloc du BDN.

Le chef du phare répond aux allégations

Michael Sproul, qui est le chef de Lighthouse, a critiqué le point de vue de Klarman sur les créneaux manqués, affirmant qu'il dénature un problème avec le bug p2p de Lighthouse, qui, selon lui, était causé par une interaction non testée entre le « réseau de distribution de blocs » (BDN) centralisé de Bloxroute et API HTTP de Lighthouse.

Cette autopsie présente le problème à tort comme un bug p2p de Lighthouse, alors qu'en fait il a été causé par une interaction non testée entre le « réseau de distribution de blocs » (BDN) centralisé de Bloxroute et l'API HTTP de Lighthouse.

Voici un compte de mon point de vue https://t.co/T2i9dbI2zQ

– Michael Sproul (@sproulM_) 29 mars 2024

Sproul allègue que Bloxroute n'a pas coopéré lors de l'incident, refusant de partager les journaux pour étayer ses affirmations. Il fait valoir que l'autopsie prématurée a été réalisée avant que les informations nécessaires puissent être obtenues auprès de Bloxroute.

Selon Sproul, le problème provenait du fait que Bloxroute publiait des blocs sans blobs sur le réseau p2p via le BDN, puis tentait de remplir les blobs en les publiant sur Lighthouse dans le cadre d'une requête HTTP. Les API HTTP de Lighthouse et Prysm supposaient cependant que les blocs étaient envoyés en p2p avec des blobs dans leur intégralité. Sproul soutient que cette hypothèse n'était pas valable en présence d'un « réseau de distribution de blocs » qui contourne le flux normal de publication des blocs.

Pour résoudre ce problème, Sproul suggère des solutions à court terme telles que la désactivation du BDN lorsque des blobs sont impliqués, et des solutions à long terme comme la restructuration de l'écosystème PBS pour éviter des pannes similaires. Il exprime également son opinion personnelle selon laquelle le BDN est une technologie qui devrait être obsolète en raison de sa nature centralisée et des risques potentiels pour la décentralisation d'Ethereum.

✓ Partager:

Bhushan est un passionné de FinTech et possède une bonne aptitude à comprendre les marchés financiers. Son intérêt pour l'économie et la finance attire son attention sur les nouveaux marchés émergents de la technologie Blockchain et des cryptomonnaies. Il est continuellement en apprentissage et reste motivé par le partage des connaissances acquises. Pendant son temps libre, il lit des romans policiers et explore parfois ses talents culinaires.

Le contenu présenté peut inclure l'opinion personnelle de l'auteur et est soumis aux conditions du marché. Faites votre étude de marché avant d'investir dans les cryptomonnaies. L'auteur ou la publication n'est en aucun cas responsable de votre perte financière personnelle.