Vor der vorläufig für August angesetzten Zusammenführung erlebte die Beacon Chain von Ethereum gestern eine Reorganisation (Reorg) von sieben Blöcken.
Laut Daten von Beacon Scan wurden am 25. Mai zwischen 08:55:23 und 08:56:35 Uhr UTC sieben Blöcke von Nummer 3.887.075 bis 3.887.081 aus der Beacon-Kette geschlagen.
Der Begriff Reorg bezieht sich auf ein Ereignis, bei dem ein Block, der Teil der kanonischen Kette war, wie z. B. die Beacon Chain, aus der Kette geworfen wird, weil ein konkurrierender Block ihn schlägt.
Dies kann das Ergebnis eines böswilligen Angriffs eines Miners mit hohen Ressourcen oder eines Fehlers sein. Bei solchen Vorfällen wird die Kette unbeabsichtigt gegabelt oder dupliziert.
Bei dieser Gelegenheit glauben die Entwickler, dass das Problem eher auf Umstände als auf etwas Ernstes wie ein Sicherheitsproblem oder einen grundlegenden Fehler zurückzuführen ist, wobei ein „Proposer Boost Fork“ besonders hervorgehoben wird. Dieser Begriff bezieht sich auf ein Verfahren, bei dem bestimmten Anbietern Priorität bei der Auswahl des nächsten Blocks in der Blockchain eingeräumt wird.
Der Core-Ethereum-Entwickler Preston Van Loon schlug vor, dass die Neuordnung auf eine „nicht triviale Segmentierung“ von neuer und alter Client-Knoten-Software zurückzuführen sei und nicht unbedingt etwas Bösartiges sei. Ethereum-Mitbegründer Vitalik Buterin Beschriftung die Theorie eine „gute Hypothese“.
Martin Köppelmann, der Mitbegründer der EVM-kompatiblen Gnosis-Kette, war einer der Ersten, der gestern Morgen über Twitter auf das Vorkommnis hinwies, und bemerkte, dass es „zeigt, dass die aktuelle Attestation-Strategie von Knoten überdacht werden sollte, um hoffentlich zu einer stabileren Kette zu führen! (Vorschläge liegen bereits vor).“
Als Antwort auf Köppelmann schrieb Van Loon die Neuorganisation vorläufig der Proposer-Boost-Gabel zu, die noch nicht vollständig implementiert worden war:
„Wir vermuten, dass dies darauf zurückzuführen ist, dass die Implementierung von Proposer Boost Fork Choice noch nicht vollständig im Netzwerk eingeführt wurde. Diese Neuorganisation ist kein Indikator für eine fehlerhafte Fork-Wahl, sondern eine nicht triviale Segmentierung von aktualisierter vs. veralteter Client-Software.“
„Alle Details werden veröffentlicht, sobald wir ein hohes Maß an Vertrauen in die Grundursache haben. Erwarten Sie ein Post-Mortem von der Client-Entwicklungs-Community!“ er fügte hinzu.
Wir vermuten, dass dies darauf zurückzuführen ist, dass die Implementierung von Proposer Boost Fork Choice noch nicht vollständig im Netzwerk eingeführt wurde. Diese Neuorganisation ist kein Indikator für eine fehlerhafte Fork-Wahl, sondern eine nicht triviale Segmentierung von aktualisierter vs. veralteter Client-Software.
— prestonvanloon.eth (@preston_vanloon) 25. Mai 2022
Heute früher, ein anderer Entwickler Terence Tsao hallte diese Hypothese an seine 11.900 Twitter-Follower weiter und merkte an, dass die Reorganisation anscheinend durch „geboostete vs. nicht geboostete Knoten im Netzwerk und das Timing eines wirklich spät ankommenden Blocks“ verursacht wurde.
„Angesichts der Tatsache, dass der Proposer-Boost eine nicht konsensbrechende Änderung ist. Aufgrund der Asynchronität des Client-Release-Zeitplans erfolgte die Einführung schrittweise. Nicht alle Knoten haben den Proposer-Boost gleichzeitig aktualisiert.“
Verwandt: Die Unterstützung von OpenEthereum endet mit dem nahenden Merge
Van Loon sprach letzte Woche auf der Permissionless-Konferenz und sagte, dass die Fusion und der Wechsel zu Proof-of-Stake (PoS) im August erfolgen könnten, „wenn alles nach Plan läuft“.
Während die Neuorganisation sicherlich Fragen zu diesem potenziellen Zeitplan aufwerfen wird, haben Van Loon und die anderen Entwickler noch nicht dargelegt, ob sie überhaupt Auswirkungen haben wird.