Nach dem Upgrade des Zilliqa-Netzwerks auf Version 9.3.0 am 3. Januar 2024 kam es auf der ZilBridge-Plattform zu einer längeren Unterbrechung, bei der mehrere Transaktionen unbestätigt blieben und Benutzer die Plattform nicht nutzen konnten.

Dieses Problem wurde am 27. März 2024 behoben, als die volle Funktionalität der Plattform wiederhergestellt wurde.

ZilBridge ist eine Ethereum-Zilliqa-Brücke, die von Carbon und Poly Network betrieben wird und die einfache Überbrückung von fungiblen ZRC-2-Token zwischen Zilliqa und Ethereum ermöglicht.

Das technische Team von Zilliqa hat eine Ursachenanalyse dieser Störung durchgeführt, die eine detaillierte Aufschlüsselung des Problems und seiner Lösung liefert.

Die Störung von ZilBridge, gekennzeichnet als PIR-219, wurde im Prinzip dadurch verursacht, dass die ZilBridge-Relay-Infrastruktur bei der Implementierung des v9.3.0-Netzwerk-Upgrades nicht heruntergefahren wurde, was dazu führte, dass sie falsche Blockheader über die Bridge-Infrastruktur weiterleitete.

Zu den Faktoren, die zu den Verzögerungen bei der Lösung dieses Problems beigetragen haben, gehören die Art und Weise, wie Zilliqa-Netzwerk-Upgrades eingeführt werden, die Merkmale, wie PolyNetwork Transaktionsblöcke validiert, die Entdeckung von Fehlern im Relayer-Programm und die Zeit, die zum Erstellen eines neuen Genesis-Blocks benötigt wird und synchronisieren Sie historische Transaktionen mit PolyNetwork.

Am 27. März wurden diese Hindernisse überwunden und die volle Funktionalität der Plattform wiederhergestellt. ZilBridge ist jetzt wieder online und alle zuvor feststeckenden Transaktionen wurden synchronisiert und bestätigt.

Ursachenanalyse – ZilBridge-Störung

ZilBridge verwendet (teilweise) ein Relayer-Programm, um geeignete Transaktionen und Blockheader an PolyNetwork weiterzuleiten, das dann die Weiterleitung der Anfragen an Carbon und dann zur Zustellung an andere Ketten übernimmt.

Wenn ein Mainnet-Upgrade im Zilliqa-Netzwerk implementiert wird, geschieht Folgendes:

  • Das alte Netzwerk wird unzugänglich gemacht

  • Aus der Persistenz des alten Netzwerks entsteht ein neues Netzwerk.

  • Das neue Netzwerk ersetzt das alte.

  • Das neue Netzwerk wird zugänglich gemacht.

Das Zilliqa-Team benachrichtigt Partner vor einem geplanten Netzwerk-Upgrade, damit sie ihre Infrastruktur anhalten können, während das alte Netzwerk nicht mehr zugänglich ist. Dieser unvollkommene Prozess wird mit der Einführung von Zilliqa 2.0 verbessert und dynamischer und flexibler gestaltet.

Im Fall des Zilliqa v9.3.0-Upgrades wurde die ZilBridge-Infrastruktur während dieses Prozesses nicht angehalten und sammelte weiterhin Header aus den leeren Blöcken, die jetzt vom alten Netzwerk produziert wurden, und leitete diese an PolyNetwork weiter.

Das bedeutete, dass PolyNetwork, als das Netzwerk mit Version 9.3.0 wieder hochgefahren wurde, eine abgespaltene Mitgliedschaft im DS-Komitee vorfand und sich weigerte, sich mit dem neuen Netzwerk zu synchronisieren.

PolyNetwork prüft, ob ein Transaktionsblock korrekt signiert ist, indem es das DS-Komitee (Directory Service) aus den von der Zilliqa-Blockchain gemeldeten DS-Blockheadern rekonstruiert. Nur das neueste DS-Komitee wird von PolyNetwork gespeichert und es ist nicht möglich, frühere DS-Komiteemitglieder für frühere DS-Blöcke zu berechnen.

Das bedeutete, dass wir den Genesis-Block für PolyNetwork neu generieren mussten – ein zeitintensiver Prozess, den wir zu einem Zeitpunkt vor dem aktuellen DS-Block beginnen mussten.

Da es nicht möglich ist, DS-Komitee-Mitgliedschaften für frühere Blöcke zu berechnen, hat das Zilliqa-Team ein Tool entwickelt, das gespeicherte Persistenz nutzt und vorwärts arbeitet, um einen Genesis-Block an jedem Punkt in der Kette zu rekonstruieren. Dies wurde dann direkt nach dem Netzwerk-Upgrade verwendet, um einen Block auf Blockhöhe zu generieren und zu signieren.

Es mussten mehrere Genesis-Synchronisierungen durchgeführt werden, um die Änderung der Schutzknoten zwischen den Netzwerkversionen zu berücksichtigen. Anschließend wurden Fehler im Relayer-Programm entdeckt, die dazu führten, dass Transaktionsblöcke nicht mit PolyNetwork synchronisiert wurden.

Diese Fehler wurden behoben und wir stießen dann auf ein Problem, das darauf zurückzuführen war, dass PolyNetwork die DS-Komiteemitgliedschaft für einen DS-Block, für den es bereits einen Hash gespeichert hatte, nicht speichern konnte.

Dies führte dazu, dass der Relayer nicht mehr funktionierte und die Erstellung eines Genesis-Blocks zwischen dem letzten DS-Block, den PolyNetwork gesehen hatte, und dem ersten DS-Block mit einer ausstehenden Bridge-Transaktion erforderlich machte.

Der Relayer wurde optimiert, um diese Synchronisierung zu beschleunigen, was nach Abschluss schließlich dazu führte, dass sich PolyNetwork an das Zilliqa-Netzwerk anpasste und die Funktionalität von ZilBridge am 27. März 2024 vollständig wiederhergestellt wurde.