Wurde Zcash jemals gefälscht? Die Schwachstellen von 2019 und 2026 erklärt

Zcash hat zwei öffentlich dokumentierte Fehler, die falsche ZEC hätten erlauben können. Der erste steckte im Beweissystem des ursprünglichen Sprout-Pools, wurde 2018 gefunden, im Februar 2019 veröffentlicht und durch das Sapling-Upgrade beseitigt. Der zweite war ein Fehler im Orchard-Schaltkreis, gemeldet am 29. Mai 2026 und durch NU6.2 behoben. Der Beitrag von 2019 gibt an, keine Fälschung gefunden zu haben; der 2026er Text, den wir gelesen haben, äußert sich dazu nicht.

Die beiden Vorfälle im Überblick

2019: der Sprout-Fehler

Der Beitrag der Electric Coin Company „Zcash counterfeiting vulnerability successfully remediated“ beschreibt „a subtle cryptographic flaw“ im BCTV14-Papier hinter Sprout: Zusätzliche Elemente im Setup des Beweissystems konnten einen betrügenden Beweiser einen scheinbar gültigen Beweis für eine andere Aussage erzeugen lassen, und wer das Transkript der Setup-Zeremonie besaß, hätte sie im Prinzip nutzen können, um geschützte Mittel zu fälschen. Das Unternehmen gibt an, keine Hinweise gefunden zu haben, dass jemand anderes den Fehler entdeckte oder dass Fälschung stattfand, und dass es die Blockchain auf Spuren einer Ausnutzung untersucht hat. Die Zusammenfassung der Absicherung: „As long as the value in the shielded pools are greater than zero, no counterfeiting has been detected.“ Der Fehler wurde erst nach der Behebung bekanntgegeben: Das Sapling-Upgrade, das das Beweissystem von Sprout ersetzte, wurde am 28. Oktober 2018 aktiviert, die Veröffentlichung folgte am 5. Februar 2019. Sapling im Zusammenhang siehe unsere Geschichte von Zcash.

2026: der Orchard-Soundness-Fehler

ZIP 257, „Deployment of the Orchard Temporary Vulnerability Mitigation and NU6.2 Network Upgrade“, hält fest, dass der Sicherheitsforscher Taylor Hornby am 29. Mai 2026, beauftragt mit einem KI-gestützten Audit des Orchard-Protokolls, eine Soundness-Schwachstelle in der Implementierung des Orchard-Action-Schaltkreises meldete. Der Fehler „could have allowed balance violation and theft of funds“; für Details verweist die ZIP auf ein GitHub-Sicherheitsbulletin und Hornbys Arbeitsprotokoll. Die Korrektur im Schaltkreis ergänzte fehlende Copy-Constraints und änderte den Orchard-Verifikationsschlüssel; der korrigierte Code erschien in halo2_gadgets v0.5.0 und orchard v0.14.0.

Die Reaktion hatte zwei Schritte:

1. Vorübergehende Abmilderung. Ab Block 3.363.426 im Mainnet verbot eine Konsensregel jede Orchard-Action in Transaktionen, als Notfall-Hotfix in zcashd v6.12.5 und Zebra v4.5.3. Laut ZIP wurde eine frühere Aktivierungshöhe 60 Blöcke zuvor erneut versucht, weil einige Mining-Pools nicht rechtzeitig aktualisiert hatten.
2. NU6.2. Bei Block 3.364.600, rund 1.174 Blöcke später (ungefähr ein Tag bei 75 Sekunden Ziel, unsere Rechnung), wurde der korrigierte Schaltkreis aktiviert und Orchard-Transaktionen wurden wieder akzeptiert, unter dem neuen Verifikationsschlüssel und einer Regel zur kanonischen Beweislänge.

ZIP 257 nennt den Grund, den Schaltkreis nicht in einem Schritt zu tauschen: den anfälligen Schaltkreis abzuschalten und den neuen gleichzeitig zu aktivieren „was ruled out due to the risk of revealing the vulnerability before it had been mitigated“.

Das Sicherheitsnetz: Pool-Salden und das Turnstile

Jeder geschützte Pool hat eine öffentliche laufende Summe, seinen Wertpool-Saldo. ZIP 209 (Final) verbietet Blöcke, die einen geschützten Pool-Saldo negativ machen oder das Gesamtangebot über MAX_MONEY, 21 Millionen ZEC, heben würden; ihre Begründung: Knoten können den in jeden Pool hinein- und herausgeschützten Wert überwachen, und ein Pool, der mehr auszahlt als er aufnahm, zeigt eine Bilanzverletzung an. Nach unserer Lesart ist ein Fehler in einem Pool daher durch die Größe dieses Pools begrenzt. Deshalb verfolgen wir die Pools offen bei Shielded Supply. Wie sich das Gesamtangebot zusammensetzt, steht in wie viele Zcash es gibt.

ZIP 318, die Orchard-zu-Ironwood-Migration, nennt das Anschlussmotiv: Der mit NU6.3 eingeführte Ironwood-Pool „enables verification of the Zcash shielded supply after NU6.2 mitigated a soundness flaw in the Orchard circuit“, und Wallets müssen die Migration von Orchard-Guthaben anbieten. Was wir zu diesem Upgrade geprüft haben, steht im Ironwood-Statusartikel, die App-Schritte in so nutzt du Zodl.

Was diese Dokumente nicht sagen

• Ob der Fehler von 2026 genutzt wurde. ZIP 257 sagt weder, dass es geschah, noch dass es nicht geschah. Auf Beweise in der Chain haben wir nicht gesucht.
• Ob es weitere Fehler gibt. Nichts hier ist ein Audit-Ergebnis für Zcash insgesamt. Zcash hat seine Beweissysteme im Lauf der Zeit gewechselt, den nächsten Vorschlag zeigt Project Tachyon.
• Anlage- oder Sicherheitsschlüsse. Wir ziehen keine.

So verfolgst du künftige Veröffentlichungen

1. Netzwerk-Upgrades und ihre Begründung stehen als ZIPs im Repository zcash/zips; unser Upgrade-Tracker und die Zeitleiste fassen zusammen, was live ist.
2. Korrekturen an Knoten und Bibliotheken erscheinen als Releases von Zebra, zcashd und dem orchard-Crate, mit GitHub-Sicherheitsbulletins.
3. Was ein Block-Explorer bei einer Transaktion anzeigen kann und was nicht, steht in geschützte Transaktion oder Guthaben prüfen.
4. Was private Transaktionen verbergen und preisgeben, steht in kann Zcash zurückverfolgt werden? und im Privatsphäre-Zentrum.

Quellen und Methode

• Electric Coin Company, „Zcash counterfeiting vulnerability successfully remediated“, 5. Februar 2019 (heute bei zodl.com gehostet); gelesen am 14. Oktober 2026.
• ZIP 257, „Deployment of the Orchard Temporary Vulnerability Mitigation and NU6.2 Network Upgrade“ (Final), Repository zcash/zips; gelesen am 14. Oktober 2026.
• ZIP 209, „Prohibit Out-of-Range Chain Value Pool Balances“ (Final); ZIP 318, „Orchard to Ironwood Migration“ (Entwurf), Motivationstext; gelesen am 14. Oktober 2026.
• Das Intervall von 1.174 Blöcken ist unsere Rechnung aus den zwei Höhen in ZIP 257.

Neue Anleitungen erscheinen zuerst im ZecZcash-Telegram-Kanal.