Ethereum-Netzwerk kämpft mit verpassten Slots, bloXroute und Lighthouse in der Debatte

Anfang dieser Woche erlebte das Ethereum-Netzwerk einen erheblichen Anstieg der verpassten Slots, die hauptsächlich auf Blöcke zurückzuführen waren, die von bloXroute-Relays weitergeleitet wurden. Untersuchungen ergaben, dass die bloXroute-Relays zwar effektiv veröffentlichte Blöcke und Blobs weiterleiten, die schnelle Verbreitung von Blöcken über das BloXroute Distributed Network (BDN) jedoch im Gegensatz zur langsameren Verbreitung von Blobs über Peer-to-Peer-Kanäle (P2P) steht. Diese Diskrepanz verdeutlichte ein spezifisches Verhalten des Clients (CL), das zur Ablehnung von Blöcken durch den Client und anschließend zu verpassten Slots führte.

Behebung verpasster Ethereum-Slots mit bloXroute

Uri Klarman, CEO von BloXroute Labs, erklärte in einem ausführlichen Thread auf Github, was sich zu den verpassten Slots in Ethereum herausstellte.

In der aktuellen Lighthouse-Version erwarten Knoten, dass derselbe Peer, der den Block bereitstellt, auch die Blobs bereitstellt. Da der BDN jedoch keine Blobs weiterleitet, ignorieren Konsensknoten, die mit dem BDN verbunden sind, zunächst von ihm empfangene Blöcke. Eine aktuelle BDN-Version zielte darauf ab, die Blockverbreitung ohne Blobs zu beschleunigen und stützte sich dabei auf das P2P-Netzwerk, um Blobs nach Bedarf zu verbreiten. Diese Änderung führte unbeabsichtigt zu einem erheblichen Anstieg der verpassten Slots.

Klarman erklärte, dass das BDN stark auf Lighthouse angewiesen sei, das die Mehrheit der Beacon-Knoten bei bloXroute ausmacht. Erste Beobachtungen nach der Veröffentlichung deuteten auf eine erfolgreiche Blockausbreitung über das BDN hin, die aufgrund ihrer engen Integration mit dem BDN vor allem bloXroute-Relays betraf.

Um das Problem zu beheben, wurde eine Reihe von Tests durchgeführt, bei denen das Problem auf das Verhalten von Lighthouse beschränkt wurde, wenn zuerst über das BDN auf Blöcke gestoßen wurde. Es wurden Maßnahmen ergriffen, um Relays schrittweise von der Nutzung des BDN für die Blockveröffentlichung abzuwenden und anschließend die Blockweitergabe des BDN mit Blobs zu deaktivieren.

Während dieser Zeit stellten bloXroute-Relays weiterhin Blöcke mit Blobs für Validatoren bereit und veröffentlichten Blöcke mit Blobs für das BDN und das Netzwerk der Beacon-Knoten. Diese Veröffentlichungsanfragen gaben jedoch eine 202-Antwort zurück, da die Beacon-Knoten den Block bereits vom BDN erhalten hatten.

Leuchtturmchef reagiert auf die Vorwürfe

Michael Sproul, der Chef von Lighthouse, hat Klarmans Einstellung zu den verpassten Slots kritisiert und behauptet, sie stelle ein Problem mit dem P2P-Bug von Lighthouse falsch dar, der seiner Meinung nach durch eine ungetestete Interaktion zwischen Bloxroutes zentralisiertem „Block Distribution Network“ (BDN) und verursacht wurde Die HTTP-API von Lighthouse.

Diese Obduktion stellt das Problem fälschlicherweise als Lighthouse-P2P-Fehler dar, obwohl es tatsächlich durch eine ungetestete Interaktion zwischen dem zentralen „Block Distribution Network“ (BDN) von Bloxroute und der HTTP-API von Lighthouse verursacht wurde

Hier ist ein Konto aus meiner Sicht: https://t.co/T2i9dbI2zQ

— Michael Sproul (@sproulM_) 29. März 2024

Sproul behauptet, Bloxroute sei während des Vorfalls unkooperativ gewesen und habe sich geweigert, Protokolle zur Untermauerung seiner Behauptungen weiterzugeben. Er argumentiert, dass die vorzeitige Obduktion durchgeführt wurde, bevor die notwendigen Informationen von Bloxroute eingeholt werden konnten.

Laut Sproul entstand das Problem dadurch, dass Bloxroute Blöcke ohne Blobs im P2P-Netzwerk über das BDN veröffentlichte und dann versuchte, die Blobs zu füllen, indem es sie als Teil einer HTTP-Anfrage an Lighthouse postete. Die HTTP-APIs von Lighthouse und Prysm gingen jedoch davon aus, dass Blöcke vollständig mit Blobs auf P2P gesendet wurden. Sproul behauptet, dass diese Annahme nicht gültig sei, wenn ein „Blockverteilungsnetzwerk“ vorhanden sei, das den normalen Fluss für die Veröffentlichung von Blöcken umgehe.

Um das Problem anzugehen, schlägt Sproul kurzfristige Lösungen wie das Abschalten des BDN vor, wenn Blobs beteiligt sind, und langfristige Lösungen wie die Umstrukturierung des PBS-Ökosystems, um ähnliche Ausfälle zu verhindern. Er bringt auch seine persönliche Meinung zum Ausdruck, dass BDN eine Technologie ist, die aufgrund ihres zentralisierten Charakters und potenzieller Risiken für die Dezentralisierung von Ethereum veraltet sein sollte.

✓ Teilen:

Bhushan ist ein FinTech-Enthusiast und hat ein gutes Gespür für das Verständnis der Finanzmärkte. Sein Interesse an Wirtschaft und Finanzen lenkt seine Aufmerksamkeit auf die neuen aufstrebenden Märkte für Blockchain-Technologie und Kryptowährung. Er ist ständig in einem Lernprozess und hält sich durch die Weitergabe seines erworbenen Wissens motiviert. In seiner Freizeit liest er Krimi-Romane und erforscht manchmal seine Kochkünste.

Der präsentierte Inhalt kann die persönliche Meinung des Autors enthalten und unterliegt den Marktbedingungen. Machen Sie Ihre Marktforschung, bevor Sie in Kryptowährungen investieren. Der Autor oder die Veröffentlichung übernimmt keine Verantwortung für Ihren persönlichen finanziellen Verlust.