Taiko Unzen Upgrade: ZK-Beweis wird Pflicht

Das Taiko Unzen Upgrade ist seit dem 6. August 2026 im Mainnet aktiv und verlangt für jeden Block mindestens einen Zero-Knowledge-Beweis. Damit kann die hardwaregestützte SGX-/TEE-Schiene einen Block nicht mehr allein finalisieren. Der Hardfork schließt genau den Ausweichpfad, den ein Angreifer im Juni für gefälschte Proofs und Abflüsse von rund 1,75 Millionen US-Dollar missbraucht hatte.

Das offizielle Taiko-Geth-Release v2.6.0 setzte die Aktivierung auf den 6. August um 13:00 Uhr UTC, also 15:00 Uhr MESZ. Ein aktueller RPC-Abruf zeigte am 7. August weiterhin neue Mainnet-Blöcke nach diesem Zeitpunkt. Eine unabhängige Meldung von PANews bestätigt die ausgeführte Umstellung. Für Nutzer ist das Upgrade vor allem eine Sicherheitsänderung: Es ersetzt keine Bridge-Prüfung, beseitigt aber einen konkreten Einzelpfad zur Finalisierung gefälschter Zustände.

Taiko Unzen Upgrade: die wichtigsten Änderungen

Taiko finalisiert Blöcke weiterhin mit mehreren Beweisen. Neu ist nicht die Existenz von ZK-Proofs, sondern ihre harte Mindestanforderung: Mindestens einer der beteiligten Beweise muss kryptografisch als Zero-Knowledge-Proof erzeugt werden. Vor Unzen war ZK nur eine weiche Anforderung. In Ausnahmefällen konnten zwei SGX-Beweise ausreichen, damit das Netzwerk trotz eines Problems bei der ZK-Erzeugung weiter finalisiert.

Diese Verfügbarkeitsreserve wurde im Angriff zum Sicherheitsrisiko. Unzen gewichtet die Abwägung nun anders: Wenn kein gültiger ZK-Beweis entsteht, darf der betroffene Block nicht allein über den SGX-Pfad final werden. Das kann in einem Fehlerfall die Finalisierung verzögern, verhindert aber, dass ein kompromittiertes hardwaregestütztes System den Zustand der Layer-2-Blockchain eigenständig bestätigt.

Warum der Hardfork nach dem Angriff nötig wurde

Taikos ausführliches Post-Mortem zum Angriff vom 21. Juni nennt zwei zusammenwirkende Ursachen. Erstens lag der private RSA-Schlüssel zur Signierung einer SGX-Enklave in einem öffentlichen Repository. Zweitens prüfte die Attestierung bei der Registrierung nicht, ob eine Enklave im unsicheren Debug-Modus lief. Dadurch konnte der Angreifer eine eigene, manipulierbare Enklave als zulässigen Prover ausgeben.

Die Prover-Whitelist allein stoppte den Angriff nicht. Taikos Protokoll erlaubte bislang eine Ausnahme: War ein Vorschlag scheinbar länger als fünf Tage ohne Beweis, durfte jede Partei ihn beweisen. Der Angreifer fälschte den Zeitwert innerhalb des bereits kompromittierten Proof-Pfads, ließ neue Vorschläge älter erscheinen und öffnete so die eigentlich für Ausfallsicherheit gedachte Berechtigung.

Auf dieser Grundlage finalisierte der Angreifer einen falschen Layer-2-Zustand und legte daraus Bridge-Auszahlungen vor. Nach Taikos Rekonstruktion wurden 39 gefälschte Auszahlungsnachrichten eingereicht, von denen 36 auszahlten. Rund 1,748 Millionen Dollar flossen ab. Tägliche Auszahlungslimits und eine Notfallpause begrenzten den Schaden; mehr als 11 Millionen Dollar in Bridge und Vault blieben unangetastet.

Der Vorfall ähnelt damit weniger einem Fehler der eigentlichen ZK-Kryptografie als einem Versagen der angrenzenden Sicherheitsinfrastruktur. Unser Bericht zum Ostium Exploit durch manipulierte Offchain-Preisdaten zeigt eine verwandte Lehre: Auch wenn zentrale Smart-Contract-Logik oder Kryptografie intakt bleiben, können kompromittierte Systeme außerhalb dieses Kerns dennoch gültig wirkende Zustände und finanzielle Folgen erzeugen.

Was die ZK-Pflicht technisch verändert

Ein Zero-Knowledge-Beweis bestätigt, dass die Zustandsübergänge eines Blocks nach den vorgegebenen Regeln berechnet wurden, ohne dass Ethereum jede einzelne Layer-2-Operation erneut ausführen muss. Entscheidend ist bei Unzen die Unabhängigkeit der Sicherheitsannahmen: Ein gestohlener Enklaven-Schlüssel und eine fehlerhafte SGX-Attestierung reichen nicht mehr aus, solange kein gültiger ZK-Beweis für denselben Block vorliegt.

Damit jeder Block praktisch beweisbar bleibt, führt Taiko „zk gas“ ein. Diese separate Recheneinheit misst die für den Proof benötigten Zyklen ähnlich wie normales Gas den Ausführungsaufwand einer Transaktion begrenzt. Das Release gleicht dafür unter anderem Fehlerpfade, Systemaufrufe und Ausführungszeugen zwischen Taiko-Geth und der Reth-basierten Implementierung an. Solche Konsensdetails sind wichtig: Unterschiedliche Ergebnisse zweier Clients könnten sonst selbst neue Fork- oder Finalitätsrisiken erzeugen.

Unzen nutzt laut Taiko außerdem zwei unabhängige ZK-virtuelle Maschinen, SP1 und RISC Zero. Diese Vielfalt soll das Risiko reduzieren, dass eine einzelne unvollständige Implementierung bestimmte gültige Blöcke nicht beweisen kann. Sie beseitigt allerdings nicht automatisch Fehler in gemeinsam genutzter Logik, Konfiguration oder Governance.

Was Nutzer und Betreiber jetzt beachten müssen

• Normale Nutzer: Taiko erklärte die Bridge bereits vor dem Hardfork wieder vollständig 1:1 gedeckt. Für bestehende Guthaben nannte das Projekt keine zusätzliche Migrationshandlung.
• Node-Betreiber: Konsensrelevante Ausführungsclients mussten vor der Aktivierung auf kompatible Versionen aktualisiert werden. Alte Software kann neue Blöcke ablehnen oder vom kanonischen Netzwerk abweichen.
• Bridge-Nutzer: Die ZK-Pflicht stärkt die Zustandsfinalisierung, ersetzt aber keine Prüfung von Auszahlungslimits, Smart Contracts, Relayern und Notfallprozessen.
• Anwendungsentwickler: Prague-Funktionen und die wieder aktivierte Forced Inclusion können das Verhalten an technischen Randfällen verändern; Integrationen sollten die aktuellen Client- und Protokollspezifikationen verwenden.

Ein Hardfork als Sicherheitsmaßnahme ist kein ungewöhnliches Muster. Der Polygon Ithaca Hardfork mit automatischer Ausfallsicherung zeigt einen anderen Ansatz: Dort reagiert das Protokoll auf blockierte Produzenten und begrenzte Störungen der Blockproduktion. Taiko adressiert dagegen die Vertrauensstruktur der Proof-Finalisierung nach einem bereits ausgenutzten Angriffsweg.

Welche Risiken trotz Unzen bleiben

Die neue Pflicht schließt einen konkret dokumentierten Pfad, macht Taiko aber nicht risikofrei. ZK-Prover, Client-Implementierungen, Bridge-Verträge, Governance und betriebliche Schlüssel bleiben eigenständige Angriffsflächen. Die zusätzliche kryptografische Prüfung kann außerdem die Verfügbarkeit berühren, falls beide ZK-Systeme einen bestimmten Block nicht beweisen können oder die notwendige Infrastruktur ausfällt.

Auch die Vermögensrückgewinnung aus dem Juni-Angriff ist nicht abgeschlossen. Taiko zufolge wurden 17 ETH zurückgeführt, während weitere gestohlene Mittel unter anderem über Tornado Cash bewegt wurden. Die Stiftung deckte die Lücke unabhängig davon aus eigenen Mitteln. Unzen verhindert daher nicht rückwirkend den Schaden, sondern verschärft die Regeln für künftige Finalisierungen.

Fazit zum Taiko Unzen Upgrade

Das Taiko Unzen Upgrade ist eine substanzielle Sicherheitsänderung, weil es eine ausgenutzte Annahme direkt aus dem Finalisierungsmodell entfernt. Ein SGX-/TEE-Proof kann seit dem 6. August nicht mehr ohne mindestens einen ZK-Beweis genügen. Damit reicht die Kombination aus kompromittiertem Enklaven-Schlüssel und fehlerhafter Hardware-Attestierung nicht mehr für denselben Angriffspfad aus.

Der Preis für diese stärkere Integrität ist eine härtere Abhängigkeit von funktionierender ZK-Infrastruktur. Für Nutzer ist deshalb weder pauschale Entwarnung noch akuter Handlungsdruck angebracht. Entscheidend wird, ob Taiko die neue Beweispflicht stabil betreibt, Client-Abweichungen vermeidet und die übrigen Bridge- und Governance-Risiken weiter reduziert. Stand der Recherche ist der 7. August 2026, 19:10 Uhr MESZ.

Quellen

• Taiko Geth v2.6.0: Unzen Mainnet activation, Aktivierung am 6. August 2026 (Primärquelle).
• Taiko Labs: Taiko Security Incident – A Postmortem and Next Steps, technische Ursachen, Schäden und Unzen-Maßnahmen (Primärquelle).
• PANews: Zusammenfassung des Taiko-Sicherheitsvorfalls und des ausgeführten Unzen-Upgrades, abgerufen am 7. August 2026 (unabhängige Sekundärquelle).