#Zano $ZANO Wenn eine Kette, um eine anomale Überemission zu bereinigen, etwa einen Monat zurückgehen muss: Ab wann zählt der Erfolg der Reparatur eigentlich? Die Wiederherstellung der Versorgung ist nur der erste Schritt; Zahlungen, Transaktionen und Cross-Chain-Abrechnungen, die in jenem Zeitraum bereits erfolgt sind, können nicht einfach dadurch wieder automatisch aufgehen, dass die neue Kette wieder Blöcke produziert. Das ist das zentrale Widerspruchspaar, auf das ich in dieser Runde am stärksten achten würde.

Zuerst die Zeitleiste auseinandernehmen. Der offizielle Monatsbericht von Zano bestätigt: Am 26. August wurde Hard Fork 6 bei Block 3.833.000 aktiviert. Die Gateway Address ist die neue Art des Zugangs, die für Börsen, Bridges und Zahlungsdienste konzipiert ist. Danach hat das Team offengelegt, dass es bei solchen Adressen eine Schwachstelle gibt, die die Emission von Vermögenswerten beeinflusst: Nicht autorisiertes ZANO sowie der Privacy-Stablecoin fUSD gelangten in den Umlauf. Gleichzeitig behauptet das Team, dass keine Kompromittierung bei normaler Transaktions-Privatsphäre und bei Wallet-Ausgabeschlüsseln festgestellt wurde; diese beiden Aussagen dürfen nicht gegeneinander ausgespielt werden: Dass ein Schlüssel nicht verloren ging, bedeutet nicht, dass die Vermögensversorgung nicht verzerrt wurde.

Die neueste Wiederherstellungs-Erklärung beschreibt den Umgang nun noch konkreter: Die Kette wurde ab Block 3.833.000, also vor Hard Fork 6, neu gestartet – mit Auswirkungen auf etwa die historische Zeitspanne von einem Monat. Transaktionen, die die alte Kette in diesem Zeitraum bestätigt hat, gehören nicht zur Wiederherstellungskette. Knoten, Miner, Validatoren und Dienste müssen alle aktualisieren; das Team arbeitet dabei daran, seine Mobile-Wallet-Knoten und den Dienst für verpackte Vermögenswerte nach und nach wiederherzustellen, während Drittanbieter-Wallets und Börsen jeweils eigene Migrationen durchführen müssen. Es wird außerdem ausdrücklich darauf hingewiesen, dass bereits auf einer anderen Kette abgerechnete Zahlungen wie USDT, DAI usw. durch das Zurückrollen von Zano nicht verschwinden.

Meine Einschätzung ist: Bei diesem Vorfall wird nicht wirklich geprüft, ob „ein Rollback möglich ist“, sondern ob die Reparatur der in-chain-Versorgung und der Abgleich der in-off-chain bestehenden Forderungen gleichzeitig zuverlässig abgeschlossen werden können. Für ein Projekt, das die Gateway Address als externe Einstiegsschnittstelle betrachtet, müssen – nachdem die alten Kettenaufzeichnungen entfernt wurden – überprüfbare Entsprechungen dafür vorliegen, wie Börsenbuchungen, Bridge-Mint/Burn-Vorgänge, die Auszahlung von fUSD und die echten Trades zwischen Nutzern nachweisbar gehandhabt werden. Das Team sagt, es werde die Verluste mit den Betroffenen abrechnen und Schadensersatz-, Kompensations- sowie technische Lessons-Learned veröffentlichen; derzeit sind diese Ergebnisse noch nicht veröffentlicht. Deshalb ist es jetzt noch zu früh, von „vollständiger Kompensation der Nutzer“ oder von „feststehenden Verlusten“ zu sprechen.

Als Nächstes werde ich drei verifizierbare Punkte prüfen: Erstens, ob jeder Dienst eindeutig bestätigt, auf die Wiederherstellungskette umgeschaltet zu haben; zweitens, ob das Team eine Abgleichs- bzw. Prüfnorm für gültige Transaktionen auf der alten Kette liefern kann; drittens, ob der Entschädigungsprozess den Umfang, die Belege und den Zeitplan transparent darlegt. Wenn diese Schritte transparent sind und reibungslos umgesetzt werden, wird sich meine Einschätzung zur Wiederherstellungsfähigkeit verbessern. Wenn die Kette erst einmal weiterläuft, der Abgleich aber langfristig in der Schwebe bleibt, ist die Versorgung zwar wiederhergestellt – aber das Vertrauen der Nutzer in die Endgültigkeit bleibt dennoch aus. Was denkst du: Soll der Abnahmestandard für ein Notfall-Rollback primär an der On-Chain-Versorgung festgemacht werden, oder primär daran, ob die betroffenen Nutzer den Abgleich abschließen können?