In der vergangenen Woche (2026/06/01 – 2026/06/07) wurden in verschiedenen Blockchain-Ökosystemen mehrere Angriffsvorfälle beobachtet. Der Bericht dieser Woche konzentriert sich auf die öffentliche Offenlegung einer kritischen Soundness-Schwachstelle in Zcashs Orchard-Shielded-Pool, die eine unentdeckte Fälschung von ZEC ermöglicht hätte. Eine On-Chain-Ausnutzung wurde nicht bestätigt, aber die Offenlegung löste ein Notfall-Netzwerk-Upgrade aus und ZEC verlor über 40 % seines Wertes.
| Datum | Vorfall | Typ | Geschätzter Verlust |
|---|---|---|---|
| 2026/06/04 | Zcash Orchard | ZK Soundness Bug | Keine Ausnutzung bestätigt |
Bester Sicherheitsprüfer für Web3
Design, Code und Geschäftslogik vor dem Launch validieren
Wochenhighlight: Zcash Orchard Soundness Bug
Dieser Vorfall wurde als Highlight der Woche ausgewählt, weil er eine der schwerwiegendsten ZK-Schwachstellen darstellt, die in einem Produktivsystem gefunden wurden. Eine fehlende Circuit-Einschränkung blieb trotz mehrerer Audits über vier Jahre lang unentdeckt und wurde schließlich durch eine KI-gestützte Sicherheitsüberprüfung gefunden. Die Schwachstellenklasse (unterbeschränkte Relationen in ZK-Circuits) könnte in jedem Protokoll existieren, das auf ZK-Circuits aufbaut.
Am 4. Juni 2026 legte Zcash öffentlich einen kritischen Soundness-Bug in seinem Orchard-Shielded-Pool-Circuit offen [1]. Eine fehlende Einschränkung im Zero-Knowledge-Proof-Circuit hob die kryptografische Bindung auf, die Double-Spending verhindert, und ermöglichte es potenziell, dieselbe geschützte Note mehrfach auszugeben, ohne dass dies entdeckt werden konnte. Die Schwachstelle existierte seit der Aktivierung von Orchard im Mai 2022 und wurde am 29. Mai 2026 vom Sicherheitsforscher Taylor Hornby durch ein KI-gestütztes Audit entdeckt. Ein Notfall-Netzwerk-Upgrade (NU6.2) behob den Circuit am 3. Juni 2026. Es wurden keine Hinweise auf eine Ausnutzung gefunden.
Hintergrund
Zcash ist eine datenschutzorientierte Layer-1-Blockchain, deren nativer Token ZEC ist. Anders als bei Bitcoin, wo alle Transaktionsdetails öffentlich sichtbar sind, unterstützt Zcash geschützte Transaktionen durch Zero-Knowledge-Beweise, die Absenderadressen, Empfängeradressen und Transaktionsbeträge verbergen. Zcash verfügt über mehrere Shielded Pools, die jeweils einer anderen Generation seines Datenschutzprotokolls entsprechen. Orchard ist die neueste Generation, aktiviert im Mai 2022 mit dem NU5-Netzwerk-Upgrade, und verwendet das halo2-Zero-Knowledge-Proof-System [2] zur Verifizierung von Transaktionen. Wenn ein Nutzer eine geschützte Transaktion durchführt, agiert er als Prover: Er erstellt einen Zero-Knowledge-Beweis mithilfe des Orchard-Circuits, der nachweist, dass die Transaktion gültig ist – er besitzt die Note, der Nullifier ist korrekt abgeleitet, und die Beträge stimmen überein – ohne private Details preiszugeben. Netzwerkknoten fungieren als Verifizierer und prüfen den Beweis, ohne die zugrunde liegenden Daten zu sehen. Der Orchard-Circuit definiert die Einschränkungen, die jeder gültige Beweis erfüllen muss. Die Schwachstelle liegt in dieser Circuit-Implementierung und betrifft vier zentrale Konzepte in Zcash: Schlüssel, Adressen, Notes und Nullifier.
Schlüssel. Zcashs Schlüsselhierarchie ist komplexer als bei den meisten Blockchains. Ein einziger Spending Key (das Wallet-Geheimnis) leitet mehrere Unterschlüssel ab: ask (Spend Authorizing Secret Key), nk (Nullifier Deriving Key) und rivk (ein Randomizer). Daraus berechnet das System ak (Authorizing Public Key) und ivk (Incoming Viewing Key, über ivk = Commit(ak, nk, rivk)). Der Schlüssel ivk wird verwendet, um eingehende Gelder zu identifizieren und zu empfangen.
Adressen. Um eine Orchard-Adresse zu erstellen, wählt der Nutzer einen Diversifier d (ein 11-Byte-Wert), der einen diversifizierten Basispunkt g_d = DiversifyHash(d) bestimmt. Die Adresse ist das Paar (d, pk_d), wobei der diversifizierte Übertragungsschlüssel pk_d als elliptische Kurven-Skalarmultiplikation berechnet wird: pk_d = [ivk] g_d. Das bedeutet, dass die Adresse kryptografisch an den Viewing Key des Nutzers gebunden ist.
Notes. Eine Note ist ein Asset-Datensatz, der empfangene Gelder repräsentiert. Zum Schutz der Privatsphäre wird On-Chain nicht die Note selbst, sondern ein Note-Commitment cm gespeichert (ein kryptografisches Commitment an den Inhalt der Note, einschließlich pk_d, Wert und weiterer Daten). Die Note ist an die Adresse des Empfängers gebunden.
Nullifier. Beim Ausgeben einer Note gibt der Spender einen Nullifier nf preis, der aus den Daten der Note und dem Nullifier-Schlüssel nk berechnet wird: nf = Extract_P([(F_nk(ρ) + ψ) mod p]G + cm). Die entscheidende Sicherheitseigenschaft ist, dass jede Note genau einen Nullifier erzeugen muss. Sobald ein Nullifier On-Chain erscheint, gilt die entsprechende Note als dauerhaft ausgegeben. Wenn dieselbe Note unterschiedliche Nullifier erzeugen könnte, ließe sie sich mehrfach ausgeben, ohne dass es jemandem auffiele.
Die Bindungskette. Diese Konzepte sind durch eine kryptografische Bindungskette verbunden:
Die rot hervorgehobenen Knoten (pk_d, nk) sind die Punkte, an denen die Schwachstelle die Bindungskette unterbricht: Der Circuit muss pk_d = [ivk] g_d erzwingen, was den Spender an den korrekten ivk und damit an den korrekten nk für diese Note bindet. Wenn diese Bindung gebrochen ist, kann der Spender einen gefälschten ivk erzeugen und somit für jede Ausgabe einen anderen nk verwenden. Unterschiedliche nk-Werte erzeugen unterschiedliche Nullifier für dieselbe Note und ermöglichen so Double-Spending.
Wie der Circuit diese Bindung erzwingt. Die Relation pk_d = [ivk] g_d ist eine elliptische Kurven-Skalarmultiplikation (Q = [k]P), implementiert mit dem Double-and-Add-Algorithmus. In einem Zero-Knowledge-Circuit führt der Verifizierer den Algorithmus nicht direkt aus; stattdessen schränkt der Circuit jeden Zwischenschritt ein. Ein korrekter Skalarmultiplikations-Circuit muss unter anderem erzwingen, dass der interne Schleifenbasispunkt dem vorgesehenen Eingangsbasispunkt entspricht (P_loop = P_input). Ohne diese Einschränkung kann der Circuit beweisen, dass eine gültige Skalarmultiplikation durchgeführt wurde, jedoch mit dem falschen Basispunkt, was die gesamte Bindungskette bedeutungslos macht.
Schwachstellenanalyse
Das anfällige ECC-Gadget wurde in der Skalarmultiplikations-Relation verwendet, die pk_d = [ivk] g_d erzwingt, wobei Q = pk_d, k = ivk und P = g_d. Der anfällige Code befindet sich in der variablen-basierten Skalarmultiplikationsimplementierung des halo2-Repositorys (incomplete.rs Z309-Z310):
// incomplete.rs (vollständige Quelle oben verlinkt)
298 for (row, k) in bits.iter().enumerate() {
299 // z_{i} = 2 * z_{i+1} + k_i
...
305 z = region.assign_advice(|| "z", self.z, row + offset, || z_val)?;
306 zs.push(Z(z.clone()));
307
308 // Assign `x_p`, `y_p`
309 region.assign_advice(|| "x_p", self.double_and_add.x_p, row + offset, || x_p)?; // BUG
310 region.assign_advice(|| "y_p", self.y_p, row + offset, || y_p)?; // BUG
311
312 // If the bit is set, use `y`; if the bit is not set, use `-y`
313 let y_p = y_p
314 .zip(k.as_ref())
315 .map(|(y_p, k)| if !k { -y_p } else { y_p });
316
317 // Compute and assign lambda1
318 let lambda1 = y_a.zip(y_p).zip(x_a.value()).zip(x_p)
.map(|(((y_a, y_p), x_a), x_p)| (y_a - y_p) * (x_a - x_p).invert());
...
}In einem Zero-Knowledge-Circuit füllt der Prover jeden Zellwert aus; der Circuit selbst kann keine Werte zwischen Zellen kopieren oder übertragen – er kann nur Einschränkungen definieren, die der Verifizierer prüft. Die beiden als BUG markierten Zeilen verwenden assign_advice(), um die Basispunktkoordinaten x_p und y_p (die privaten Circuit-Eingaben, bekannt als Witness-Werte) in die Advice-Spalten des Circuits (den privaten Eingabebereich des Provers) zu schreiben. Diese Funktion füllt einen Wert ein, ohne eine Einschränkung zu erzeugen, die ihn an den externen Basispunkt bindet. Eine separate Einschränkung stellt zwar sicher, dass die Basiswerte über alle Schleifeniterationen hinweg gleich sind – der Prover kann in jeder Iteration keinen anderen Basispunkt verwenden. Jedoch kann der Prover einen einzigen beliebigen Basispunkt über alle Iterationen hinweg einsetzen, und der Circuit wird ihn nicht ablehnen, da keine Einschränkung die Schleifenbasiswerte an den tatsächlich von außen übergebenen g_d ankert.
Die korrekte Funktion ist copy_advice(), die den Wert und eine Gleichheitseinschränkung (eine Copy-Constraint) hinzufügt, die erzwingt, dass er mit dem tatsächlichen Basispunkt g_d übereinstimmt. Da g_d je nach Adresse variiert (abgeleitet vom Diversifier jeder Adresse), kann der Circuit ihn nicht fest einprogrammieren – er muss den Schleifenbasispunkt einschränken, sodass er mit dem vorgelagert berechneten g_d übereinstimmt.
Infolgedessen erzwang der Circuit tatsächlich nicht pk_d = [ivk] g_d. Ein bösartiger Prover konnte innerhalb der Schleife einen beliebigen Basispunkt angeben (anstelle des korrekten g_d), und der Circuit akzeptierte den Beweis dennoch: Die interne Berechnung blieb algebraisch in sich konsistent, war aber nicht mehr am protokollspezifizierten diversifizierten Basispunkt verankert. Dieser zusätzliche Freiheitsgrad erlaubt es dem Prover, bei jeder Ausgabe einen anderen nk zu wählen, den entsprechenden ivk = Commit(ak, nk, rivk) zu berechnen und die nicht eingeschränkte Skalarmultiplikation zu nutzen, um den gefälschten ivk zu bestehen. Da der Nullifier von nk abhängt, ergibt jede Ausgabe einen anderen Nullifier:
selbe Note N + nk_1 → nf_1
selbe Note N + nk_2 → nf_2
wobei: nf_1 ≠ nf_2Der Konsens prüft nur, ob ein Nullifier bereits On-Chain erschienen ist. Da jede Ausgabe einen eindeutigen, legitim aussehenden Nullifier erzeugt, ist der Double-Spend für das Netzwerk unsichtbar.
Der Fix [3] fügt einen copy_advice()-Aufruf in der ersten Iteration der Schleife (row == 0) hinzu, der eine Copy-Constraint erstellt, die den Schleifenbasispunkt an den tatsächlich von außen übergebenen base ankert. Die verbleibenden Iterationen verwenden weiterhin assign_advice(), aber die bestehende Konsistenzeinschränkung zwischen Iterationen überträgt den Anker auf alle.
Auswirkungen und Reaktion
Ausnutzungsszenario. Ein bösartiger Prover könnte die Schwachstelle ausnutzen, um dieselbe Orchard-Note mehrfach auszugeben und dabei jedes Mal einen anderen Nullifier zu erzeugen. Da der Zero-Knowledge-Beweis private Circuit-Eingaben verbirgt, sind die betrügerischen Nullifier von legitimen nicht zu unterscheiden. Der Angriff hinterlässt keine eindeutigen kryptografischen On-Chain-Beweise, sodass es unmöglich ist, abschließend festzustellen, ob er jemals ausgenutzt wurde.
Die Schwachstelle existierte seit der Aktivierung von Orchard im Mai 2022 (NU5-Upgrade), was ein Gesamtexpositionsfenster von über vier Jahren ergibt. Zcashs Turnstile-Accounting begrenzt, wie viel gefälschter Wert den Orchard-Pool in transparente oder Sapling-Pools verlassen kann, und begrenzt damit die tatsächlichen Auswirkungen auf das breitere Angebot. Gefälschte Notes könnten jedoch unentdeckt innerhalb des Shielded Pools existieren, und seine Datenschutzeigenschaften machen es unmöglich, kryptografisch zu beweisen, ob die Schwachstelle jemals ausgenutzt wurde.
Hinweis: Der Turnstile greift nur, wenn die gesamten Abflüsse die gesamten Zuflüsse eines Pools übersteigen. Ein Angreifer könnte gefälschten Wert in kleinen Beträgen über Zeit abziehen, ohne dieses Limit zu überschreiten. Die Diskrepanz würde nur dann offensichtlich, wenn legitime Nutzer kollektiv versuchen würden, mehr abzuheben, als der Pool tatsächlich hält.
Entdeckung und Reaktion. Die Schwachstelle wurde am 29. Mai 2026 vom Sicherheitsforscher Taylor Hornby (beauftragt von Shielded Labs) entdeckt, der ein KI-gestütztes Audit-Framework mit Anthropics Opus 4.8 Modell verwendete, das am Vortag veröffentlicht worden war. Frühere Audits desselben Circuits mit älteren Modellen hatten den Bug nicht gefunden. Hornby meldete das Problem noch am selben Tag an ZODL. Ein Notfall-Soft-Fork am 2. Juni (UTC) deaktivierte vorübergehend Orchard-Transaktionen, und das NU6.2-Netzwerk-Upgrade am 3. Juni (UTC, Block 3.364.600) führte einen korrigierten Circuit ein und stellte die Orchard-Funktionalität wieder her [1]. Nach der öffentlichen Offenlegung am 4. Juni verlor ZEC über 40 % seines Wertes, wobei Liquidierungen 100 Millionen Dollar überstiegen [4].
Fazit
Die Zcash-Orchard-Schwachstelle wurde durch eine fehlende Gleichheitseinschränkung im Skalarmultiplikations-Circuit verursacht, die es dem Prover ermöglichte, die Basispunktbindung zu umgehen und Nullifier zu fälschen, um Double-Spending durchzuführen. Im Gegensatz zu traditionellen Smart-Contract-Bugs, die oft durch Code-Review oder Tests gefunden werden können, erfordert ein Soundness-Bug in einem ZK-Circuit ein Verständnis der Lücke zwischen dem, was der Circuit tatsächlich beweist, und dem, was er beweisen sollte – eine Feinheit, die über vier Jahre lang professionellen Audits erfahrener Kryptografen entging.
Die halo2-Bibliothek wird im gesamten ZKP-Ökosystem eingesetzt, und ähnlich unterbeschränkte Relationen könnten in anderen Projekten existieren, die auf diesen kryptografischen Bausteinen aufgebaut sind. Protokolle, die Zero-Knowledge-Beweise verwenden, sollten Bilanzintegritätsprüfungen implementieren (wie Turnstile-Accounting), um die potenziellen Auswirkungen unentdeckter Soundness-Bugs zu begrenzen: Ohne Zcashs Turnstile-Mechanismus hätte gefälschter Wert, der innerhalb des Shielded Pools erzeugt wurde, frei in das breitere Angebot fließen können. Shielded Labs hat angekündigt, den Orchard-Circuit mathematisch formal zu verifizieren.
Die Entdeckung ist ein typisches Beispiel für einen Human-in-the-Loop-Workflow: Ein erfahrener Sicherheitsforscher baute das Audit-Framework auf und leitete die Untersuchung, während die KI die Breite der Überprüfung einzelner Circuit-Einschränkungen übernahm. Keine der beiden Komponenten allein war ausreichend: Frühere KI-Läufe mit älteren Modellen fanden den Bug nicht, und jahrelange Überprüfung durch menschliche Experten ebenfalls nicht. Hornby ist selbst ein Zcash-Sicherheitsexperte – Domänenwissen war notwendig, um den richtigen Audit-Umfang für die KI zu gestalten. Wie auch aktuelle von BlockSec veröffentlichte Forschung gezeigt hat [5], machen KI-Modelle rasante Fortschritte in der Sicherheitsanalyse, aber Expertenwissen wird weiterhin benötigt, um die KI auf die richtigen Ziele zu lenken und ihre Ergebnisse zu validieren. Die interaktive Zusammenarbeit zwischen Experten und KI – anstatt sich allein auf KI zu verlassen – ist das effektivste Arbeitsmodell.
Referenzen
- The Orchard counterfeiting vulnerability and next steps, Zcash Community Forum, 4. Juni 2026. Link
- halo2: A zero-knowledge proof system, GitHub. Link
- Fix: anchor scalar multiplication base point via copy constraint, halo2 GitHub. Link
- Why ZEC fell 40% even after Zcash patched a shielded pool bug, CoinTelegraph, 5. Juni 2026. Link
- Re-Evaluating EVMBench: Are AI Agents Ready for Smart Contract Security?, arXiv, 2026. Link
Über BlockSec
BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchains und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zurückzuverfolgen und AML/CFT-Verpflichtungen zu erfüllen – über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg.
BlockSec hat mehrere Blockchain-Sicherheitspapiere auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert und dabei mehr als 20 Millionen Dollar gerettet sowie Milliarden von Kryptowährungen gesichert.
-
Offizielle Website: https://blocksec.com/
-
Offizieller Twitter-Account: https://twitter.com/BlockSecTeam
