Zero-Knowledge Proofs: Wie Zcash & Altcoins vollständige Privatsphäre sichern

Zero-Knowledge Proofs (ZKPs) haben sich zu einer der transformativsten kryptografischen Primitive in modernen Blockchain-Systemen entwickelt. Anders als hochrangige Artikel, die die technische Essenz verwässern, zerlegt dieser Text die echten Mechanismen, die echte Mathematik und die tatsächlichen Einschränkungen hinter ZK-basierten Datenschutzsystemen, die in Altcoins wie Zcash, Aleo und Firo verwendet werden – ohne Abstraktionen oder Marketing-Schnickschnack.

1. Was ein Zero-Knowledge Proof tatsächlich ist (Mathematisch)

Ein ZKP ist ein interaktives oder nicht-interaktives Protokoll, das es einem Beweiser P erlaubt, einen Prüfer V davon zu überzeugen, dass eine Aussage wahr ist, ohne dabei irgendeine Information preiszugeben, außer der Wahrheit der Aussage.

Formal muss ein ZKP folgende Eigenschaften erfüllen:

1. Vollständigkeit: Wenn die Aussage wahr ist, akzeptiert ein ehrlicher Prüfer.
2. Korrektheit: Ein böswilliger Beweiser kann den Prüfer nicht von einer falschen Aussage überzeugen.
3. Zero-Knowledge: Der Prüfer lernt nichts außer der Gültigkeit.
   Zero-Knowledge wird unter Verwendung eines Simulators S definiert:
   Wenn S ein ununterscheidbares Transkript erzeugen kann, ohne den Zeugen zu kennen, ist das Protokoll Zero-Knowledge.

Für die Blockchain-Nutzung sieht die Aussage meist so aus:

„Ich kenne ein Geheimnis (Zeuge), das auf diesen öffentlichen Wert gehasht wird.“
oder
„Ich besitze Coins, die zu Verpflichtungen gehören, ohne zu offenbaren, welche.“

2. Commitment-Schemata — Die Grundlage von ZK-Datenschutzcoins

Die meisten Datenschutz-Coins verwenden Commitments, um Transaktionswerte und Eigentum zu verbergen.

Ein Commitment wird definiert als:
C = Commit(value, randomness)

Eigenschaften:

• Verbergen: Der Wert kann nicht aus C extrahiert werden.
• Binden: Der Beweiser kann den Wert später nicht ändern.

Übliche Schemata:

• Pedersen-Commitments:
  C = v·G + r·H in elliptischen Kurven-Gruppen (verwendet in Firo Lelantus / MimbleWimble).
• SHA-256-basierte Commitments: in einigen zk-SNARK-Schaltungen für Effizienz.

Pedersen-Commitments erlauben:

• Additive Homomorphie: C1 + C2 = Commit(v1 + v2, r1 + r2).
  → So erhalten vertrauliche Transaktionen die Gesamtsumme.

3. zk-SNARKs und zk-STARKs — Warum Datenschutzcoins das eine oder andere nutzen

3.1 zk-SNARKs (Succinct Non-Interactive Argument of Knowledge)

Verwendet in:

• Zcash (Sapling)
• Horizen
• Firo Lelantus Spark

Eigenschaften:

• Sehr kleine Beweise (~192 Bytes in Sapling).
• Sehr schnelle Verifikation (~10 ms).
• Erfordern eine Trusted Setup (toxic waste Problem).
• Nutzung von elliptischen Kurvenpaarungen (hauptsächlich BLS12-381).

Technisches Detail, das oft weggelassen wird:
Zcash nutzte ursprünglich BN254 (Jubjub), wechselte aber zu BLS12-381 aufgrund von Sicherheitsproblemen in Untergruppen und Bedenken bezüglich 128-Bit-Sicherheitsmargen.

3.2 zk-STARKs (Scalable Transparent ARguments of Knowledge)

Verwendet in:

• Aleo
• StarkNet (keine Coin, aber relevant)

Eigenschaften:

• Kein Trusted Setup.
• Post-quantensicher (basierend auf Hash-Funktionen, nicht auf Paarungen).
• Beweise sind groß (~100–500 KB).
• Verifikation ist schnell und skalierbar.

Wenig bekannter Fakt:
Frühe Aleo-Testnet-Beweise waren so groß, dass die Netzwerkbandbreite zum Engpass wurde; Optimierungen reduzierten die Beweisgröße vor Mainnet um ~80%.

4. Wo Zero-Knowledge innerhalb einer Datenschutztransaktion auftritt

Ein datenschutzfokussierter Altcoin nutzt ZKPs typischerweise für eines oder mehrere der folgenden:

4.1 Verbergen des Senders

Mechanismen:

• Ring-Signaturen (Monero — nicht ZK, aber verwandt).
• Zero-Knowledge-Mitgliedschaftsbeweise (Zcash, Lelantus).

Beispiel (vereinfacht):
Der Beweiser zeigt, dass er einen geheimen Schlüssel für ein Element in einer Commitment-Menge kennt, ohne zu verraten, welches.

4.2 Verbergen des Empfängers

Nutzung von Stealth-Adressen oder diversifizierten Adressen.
Zcash verwendet Payment Addresses und Incoming Viewing Keys, um selektive Transparenz zu ermöglichen.

4.3 Verbergen des Betrags

Pedersen-Commitments + ein ZKP, der sicherstellt:

• Commitments summieren korrekt,
• Beträge sind nicht negativ (Range Proofs),
• keine Inflation wird eingeführt.

Ältere Range Proofs (Confidential Transactions, Bitcoin-Vorschläge):
~2–3 KB pro Output.

Bulletproofs:
~700 Bytes pro Output (Monero nutzt diese).

zk-SNARKs:
Zcash verbirgt Beträge mit Beweisen, die insgesamt nur 192 Bytes groß sind.

5. Ein konkretes Transaktionsbeispiel: Zcash Sapling

Eine Zcash Sapling Shielded-Transaktion beweist:

1. Der Ausgeber besitzt eine Note (versteckte Coin).
2. Die Note wurde vorher nicht ausgegeben (Nullifier-ZKP).
3. Der gesamte Ausgangswert entspricht dem gesamten Eingabewert (Balance-ZKP).
4. Ausgangsnoten sind korrekt gebildete Commitments.

Was tatsächlich bewiesen wird?

Der Beweiser baut eine Schaltung auf, die umfasst:

• Hashes (BLAKE2s) von Note-Commitments
• Pedersen-Hashes
• Merkle-Baum-Pfad-Authentifizierung
• Nullifier-Berechnung
• Gleichungen zur Wertkonservierung

Die gesamte Schaltungs-Komplexität beträgt ~2 Millionen Constraints.
Die Beweiserstellung nutzt Groth16, erfordert:

• FFT-Berechnungen
• Multi-Scalar-Multiplikationen
• EC-Paarungen

Auf einem Laptop dauert die Erstellung eines Beweises ~1–2 Sekunden (optimiert mit Pallas/Vesta-Kurven in Orchard).

Selten erwähnter Fakt:
Die Sapling-Schaltung verwendet Bit-Dekompositionen für Range Constraints, was die Anzahl der Constraints stark erhöht; Orchard ersetzte dies durch Halo 2’s PLONKish-Arithmetisierung und reduzierte die Komplexität erheblich.

6. Lelantus Spark (Firo) — Ein unterschätztes ZK-System

Firos „Spark“-System ist eines der technisch fortschrittlichsten, aber weniger öffentlich bekannten.

Wichtige Innovationen:

• Rein Zero-Knowledge (keine Ring-Signaturen).
• Verwendet One-of-Many Proofs:
  Der Beweiser zeigt, dass er eine Note von N besitzt, wobei die Beweisgröße logarithmisch in N ist.
• Kein Trusted Setup erforderlich.
• Beträge werden über Pedersen-Commitments verborgen.
• Spark-Adressen sind nicht verknüpfbar, selbst für Nodes, die Chain-Analysen durchführen.

Spark beinhaltet außerdem:

• Adress-Neuausgabe:
  Besitzer können Adressen aktualisieren und behalten dabei die Kontrolle, wodurch Metadaten-Lecks reduziert werden.
• Universelle Bindung:
  Verhindert böswillige Inflation durch mehrfache kryptografische Bindungen an dasselbe Commitment.

Wenig bekannter Fakt:
Sparks Design reduziert die Angriffsfläche durch „teilweise Ausgabebeweise“, die zuvor einige Datenschutzprotokolle unter bestimmten Heuristiken verknüpfbar machten.

7. Aleo — ZK-Ausführung, nicht nur ZK-Transaktionen

Aleo ist nicht nur eine private Coin — es ist eine L1-Blockchain mit vollständig privaten Smart Contracts.

Funktionsweise:

• Programme werden in Leo geschrieben, einer Rust-ähnlichen DSL, die zu R1CS kompiliert.
• Die Ausführung erfolgt off-chain.
• Ein zk-STARK-Beweis wird generiert, der die gesamte Ausführungsspur darstellt.
• Miner/Validatoren prüfen den Beweis und aktualisieren den Zustand.

Effektiv ist dies:

Eine globale, überprüfbare, verschlüsselte virtuelle Maschine.

Wenig bekannter Fakt:
Aleo verwendet ein hybrides Beweissystem:

• STARKs für Transparenz
• SNARK-Recursion (Kimchi/Halo-Stil) zur Reduzierung der Beweisgröße

Dieser hybride Ansatz ist selten und technisch komplex.

8. Warum ZKPs schwer auf Altcoin-Skala zu implementieren sind

8.1 Beweiskosten

Die Generierung eines zk-SNARK-Beweises erfordert:

• Millionen arithmetischer Constraints
• FFTs über großen endlichen Feldern
• Multi-Scalar-EC-Multiplikationen

Selbst mit Optimierungen:

• Kann die Beweiserstellung CPU-gebunden sein.
• Hoher Speicherverbrauch (mehrere hundert MB auf älteren Systemen).

8.2 Probleme mit Trusted Setup

Coins, die Groth16 nutzen, benötigen ein Trusted Setup.
Wenn der „toxic waste“ nicht zerstört wird, kann ein Angreifer:
→ unbegrenzt gefälschte Coins erstellen
ohne entdeckt zu werden.

Zcash verwendete tatsächlich eine Multi-Party-Zeremonie; der finale „toxic waste“ wurde (angeblich) durch physikalische Entropieextraktion und strenge OPSEC zerstört…
Aber ein einzelner unehrlicher Teilnehmer hätte ausgereicht, um das System zu kompromittieren.

8.3 Circuit-Bugs können eine Coin zerstören

Wenn der Circuit eines Datenschutzsystems einen unentdeckten Fehler hat, der Inflation ermöglicht, können Nodes gefälschte Coins nicht erkennen.
Dies geschah in den frühen Zcash-Versionen (vor Ausnutzung behoben).

Ein subtiler Fehler in arithmetischen Constraints kann ein gesamtes Ökosystem ruinieren.

9. Die Zukunft der ZK-Coins

Technisch wahrscheinliche Trends:

• Recursive Proofs, die gebündelte Transaktionsverifikation erlauben.
• Hybride STARK–SNARK-Systeme, wie bei Aleo, zur Reduzierung der Beweisgröße.
• Hardware-Beschleunigung über GPUs und ASICs für die Beweiserstellung.
• Programmierbarer Datenschutz, der selektive Offenlegung erlaubt.
• Mobile-freundliche ZK-Circuits (aktuelle Circuits sind viel zu schwer).

Einige Forschungsexperimente:

• ZK-verschlüsselte Mempools
• ZK-basierte P2P-Matching-Engines
• ZK-basierte DEXs ohne Offenlegung der Orderbücher

Diese werden bereits in Projekten wie Penumbra und Mina prototypisch umgesetzt.

10. Realwelt-Angriffe und Schwachstellen in ZK-basierten Privacy-Coins

Auch wenn ZK-Systeme darauf abzielen, Privatsphäre und Korrektheit zu garantieren, zeigt die Geschichte, dass kryptografische Komplexität oft neue Angriffsflächen schafft.

Unten sind die wichtigsten realen, dokumentierten und oft wenig diskutierten Probleme aufgeführt.

10.1 Zcash Fälschungsanfälligkeit (2018)

Eine schwerwiegende Schwachstelle wurde im Zcash-Sapling-Circuit entdeckt:

• Ein Parameter im zk-SNARK-Circuit war falsch eingeschränkt.
• Dies erlaubte einem Angreifer, gefälschte Shielded-Coins zu erstellen.
• Diese Coins wären nicht erkennbar, da alle Shielded-Werte verborgen sind.

Wichtige Fakten:

• Entdeckt von dem Kryptographen Ariel Gabizon.
• Vor der öffentlichen Ausnutzung in Sapling behoben.
• Zcash gab nie bekannt, wie viele (falls überhaupt) gefälschte Coins im Sprout-Pool erstellt wurden, da dies mathematisch nicht überprüfbar ist.

Dieser Vorfall ist das stärkste reale Beispiel für:

ZK-Systemfehler = katastrophale, nicht erkennbare Inflation.

Er motivierte außerdem Protokolländerungen hin zu:

• Neueren Circuits (Sapling, Orchard)
• Modulareren Constraint-Systemen
• Mehr Peer-Review vor dem Deployment

10.2 Akademischer Angriff auf MimbleWimble (2019)

MimbleWimble (verwendet von Grin/Beam) nutzt keine zk-SNARKs, sondern Pedersen-Commitments + Cut-Through + keine Adressen.

Ein Forscher (Ivan Bogatyy) zeigte:

• Durch Echtzeitüberwachung des Netzwerks mit ~200 Nodes,
• konnte er 96% der Grin-Transaktionen den Sendern und Empfängern zuordnen.

Dies war kein Fehler in der ZK-Mathematik selbst, sondern ein Fehler in:

• Dem Transaktionsaggregationsmodell
• Dem Fehlen von „Decoy“-Inputs
• Netzwerkbezogenen Metadaten-Lecks

Wichtige Lektion:

Privatsphäre liegt nicht nur in Beweisen – Netzwerk-Topologie-Leaks können selbst perfekte ZK-Mathematik deanonymisieren.

10.3 Timing-Leaks in Prover-Implementierungen

Einige ZKP-Implementierungen (insbesondere ältere SNARK-Circuits) geben Timing-Muster preis:

Beispiel:

• Beim Beweisen einer Transaktion mit vielen Inputs erzeugen CPUs oder GPUs erkennbare Timing-Änderungen.
• Ein Beobachter mit Node-Level-Zugang kann die Anzahl der ausgegebenen Notes abschätzen, wodurch die Privacy-Sets reduziert werden.

Dies wurde teilweise in frühen Zcash-Clients vor Optimierung beobachtet.

Grund:
SNARK-Prover verwenden oft FFTs und Multi-Scalar-Multiplikationen, bei denen die inputabhängige Struktur die Laufzeit beeinflusst.

10.4 Multi-Curve-Risiken in Hybridsystemen

Projekte wie Aleo verwenden:

• STARKs → anschließend Kompression mit SNARK-Recursion (Kimchi/Halo/KZG-Polynomial-Commitments).

Ein selten diskutiertes Risiko:
Wenn irgendeine Kurve oder ein Polynomial-Commitment-Schema im Rekursionsstapel bricht,
wird das gesamte System verwundbar.

Diese „Multi-Curve-Schwäche“ wird in Marketingmaterialien fast nie erwähnt.

11. Entwurf eines Privacy-Coin-ZK-Circuits (Allgemeines Blueprint)

Hier ist eine reale technische Aufschlüsselung, wie Entwickler tatsächlich ein ZK-Privacy-Protokoll bauen.

Schritt 1: Arithmetisches Modell auswählen

• R1CS (Zcash Sapling)
• PLONKish (Halo 2, Orchard)
• AIR/FRI (STARKs)

Jedes hat Vor- und Nachteile:

• R1CS → leicht verständlich, viele Constraints.
• PLONK → flexibel, unterstützt benutzerdefinierte Gates.
• STARK → kein Trusted Setup, aber größere Beweise.

Schritt 2: Endliches Feld wählen

Beispiele:

• BLS12-381 Skalarfeld (255-Bit) für SNARKs.
• Goldilocks-Feld (64-Bit-freundlich) für STARKs (verwendet in Polygon Miden, RISC Zero).

Die Feldwahl beeinflusst direkt:

• Circuit-Größe
• Hardware-Beschleunigung
• Beweisgeschwindigkeit

Schritt 3: Kryptografische Commitments bauen

Ein typischer Altcoin verwendet:

• Pedersen-Commitments für Werte
• SHA-basierte Commitments für Merkle-Pfade
• Poseidon/Rescue-Hashes innerhalb von Circuits (FFT-freundlich)

Wenig bekannter Fakt:
Zcash entfernte SHA-256 aus Circuits, da SHA-256 extrem viele Constraints benötigt – über 25.000 pro Hash.
Poseidon reduziert dies auf ~150 Constraints.

Schritt 4: Besitznachweis (Spend Authorization) implementieren

Dies umfasst normalerweise:

• Überprüfung von Key-Derivations
• Nachweis des Wissens des Private Keys
• Verhinderung von Replay-Angriffen

Zcash verwendet RedJubjub, ein SNARK-freundliches Signaturschema (EdDSA-Stil, aber für SNARKs optimiert).

Schritt 5: Nullifier-Logik implementieren

Nullifier = ein deterministisches eindeutiges Tag für eine ausgegebene Note.

Der ZK-Circuit muss garantieren:

• Jede Note erzeugt genau einen Nullifier.
• Nullifier darf die Identität der Note nicht offenbaren.
• Nullifier darf keine mehrfachen Ausgaben erlauben.

Dieser Teil ist extrem fehleranfällig — und die Ursache für Zcashs größten Bug.

Schritt 6: Bilanzgleichung erstellen

Nachweisen:
inputs_commitments_sum = outputs_commitments_sum

Plus Range Proofs:

• Werte ≥ 0
• Werte < 2⁶⁴

In modernen Systemen werden Range Constraints verwendet:

• PLONK Lookup Arguments
• Bulletproofs innerhalb von Circuits
• Benutzerdefinierte Gates

Schritt 7: Finale Aggregation & Beweiserstellung

SNARK-Beispiel:

• Circuit kompilieren → QAP-Polynom
• FFT für Polynom-Auswertungen durchführen
• Multi-Scalar-Multiplikationen durchführen
• Beweis ausgeben
• On-Chain / Verifier-Nodes prüfen in Millisekunden

STARK-Beispiel:

• Ausführungsspuren aufbauen
• FRI-Commitments anwenden
• Großer, aber transparenter Beweis ausgeben
• Überprüfung mit Hash-Operationen

12. ZK-Hardware-Beschleunigung (Ein Game Changer)

Die meisten Nutzer wissen nicht, dass ZKP-Beweiserstellung langsam zu einem Hardware-Wettrüsten wird:

GPU-Beweise

• FFT- und MSM-Operationen lassen sich extrem gut auf GPUs abbilden.
• Im Aleo-Testnetz wurden >50% des Beweis-Durchsatzes auf Consumer-GPUs (RTX-Serie) durchgeführt.

ASIC-Beweise

Mehrere Firmen (Ingonyama, Cysic) entwickeln ZKP-orientierte ASICs für:

• MSM-Einheiten
• Polynomauswertungen
• Merkle-Pfad-Berechnungen

Statistisch relevantes Detail:

• Ein spezialisierter ASIC-Prover kann SNARK-Beweise 20–50× schneller als eine CPU erzeugen.

Das bedeutet, dass die Zukunft von Privacy-Coins stark auf spezialisierten Hardware-Ökosystemen basieren könnte, ähnlich wie beim Bitcoin-Mining.

13. Das Problem transparenter Audits bei ZK-Coins

Privacy-Coins stehen vor einem Paradoxon:

1. Nutzer wollen Privatsphäre.
2. Entwickler müssen sicherstellen, dass keine Inflation oder versteckte Schwachstellen existieren.
3. ZK verbirgt alles.

Mehrere Techniken versuchen, dieses Problem zu lösen:

13.1 Viewing Keys (Zcash, Aztec)

Erlauben Prüfern, bestimmte Konten einzusehen, ohne andere offenzulegen.

13.2 Supply-Audits

• Zcash kann die transparente Poolversorgung prüfen.
• Die Shielded-Pool-Versorgung kann nicht direkt auditiert werden.
• Entwickler verlassen sich auf die Korrektheit der Circuits, um keine Inflation zu garantieren.

Deshalb sind ZK-Protokoll-Bugs existenzielle Bedrohungen.

14. Ungewöhnliche, aber wichtige kryptografische Fakten

14.1 Die ursprünglichen ZKP-Papers nutzten interaktive Protokolle

Moderne SNARKs sind nicht-interaktiv (via Fiat–Shamir-Heuristik).
Aber die frühesten ZKPs erforderten viele Kommunikationsrunden.

14.2 Fiat–Shamir ist nicht beweisbar sicher

Wenn die Hash-Funktion in Fiat–Shamir gebrochen oder manipulierbar ist,
kann die Soundness zusammenbrechen.

Dies betrifft jeden SNARK-basierten Privacy-Coin.

14.3 STARKs basieren ausschließlich auf Hash-Funktionen

Das bedeutet:

• Sie gelten als post-quantensicher.
• Ihre Sicherheit hängt nur von der Kollisionsresistenz des Hashes ab (z. B. Rescue, Poseidon).

14.4 Rekursive Beweise reduzieren die Blockchain-Last

Halo 2 (verwendet in Zcash Orchard) ermöglicht:

• Beweise, die andere Beweise verifizieren
• Unendliche Rekursion
• Kein Trusted Setup

Dies beseitigt viele frühere Einschränkungen von SNARK-Systemen.

15. Vergleichstabelle: ZK-Systeme in großen Privacy-Altcoins

Monero ist nur zum Vergleich enthalten — es verwendet keine Zero-Knowledge-Beweise, was viele Anfänger überrascht.

16. Die wirklichen Vor- und Nachteile der Nutzung von ZKPs in Privacy-Coins

Vorteile

• Maximale Privatsphäre mit mathematischen Garantien.
• Fähigkeit, Sender, Empfänger und Betrag gleichzeitig zu verbergen.
• Beweise sind für jeden überprüfbar.

Nachteile

• Hoher Rechenaufwand.
• Risiken durch Circuit-Bugs (Inflation).
• Größere Transaktionen (außer bei Groth16).
• Schwieriger in leichte Wallets zu integrieren.
• Komplexere Kryptografie → weniger Experten verstehen sie → langsameres Audit.

Ein selten erwähnter Aspekt:

ZK-Systeme erhöhen Determinismus-Leaks von Wallets:
Beweismuster können Hardware, CPU/GPU-Typ oder sogar das Betriebssystem einer Wallet aufdecken und damit Metadaten für Kettenüberwachungsbehörden liefern.

17. Wohin sich ZK-basierte Privatsphäre in den nächsten 5 Jahren entwickeln wird

Wahrscheinlichste Entwicklungen:

17.1 Universelle Datenschutzeebenen

Anstatt Privatsphäre direkt in L1 einzubauen:

• Netzwerke wie Aztec, Penumbra und RAILGUN zielen darauf ab, Privatsphäre für bestehende Chains bereitzustellen.
• Dies vermeidet Fragmentierung über Altcoins hinweg.

17.2 ZK-Coprozessoren

Sidecar-Geräte, die alle SNARK-/STARK-Berechnungen für Wallets oder Nodes übernehmen.

17.3 Adaptive Privatsphäre (vom Nutzer auswählbar)

Nutzer können selektiv offenlegen:

• Beträge
• Sender
• Empfänger
• Memo-Felder

Nur wenn es gesetzlich oder geschäftlich erforderlich ist.

17.4 Vollständig private Smart-Contract-Ökosysteme

Aleo, Aztec 3 und Penumbra sind aktiv Pioniere in diese Richtung.

17.5 SNARK-freundliche Token-Standards

Z. B. ZK-ERC20 mit:

• Verschlüsselte Kontostände
• ZK-Transferbeweise
• Kompatibilität mit Ethereum-Tooling

Dies wird vermutlich die erste wirklich breite ZK-Adoption sein.

18. Abschließende Gedanken

Zero-Knowledge-Beweise definieren grundlegend, was „Privatsphäre“ in Blockchain-Ökosystemen bedeutet.
Sie sind kein Zauber und bringen technische Risiken, kryptografische Komplexität und operative Gefahren mit sich.
Aber sie ermöglichen etwas, das kein anderes System leisten kann:

mathematisch beweisbare Privatsphäre kombiniert mit mathematisch beweisbarer Korrektheit.

Für Privacy-orientierte Altcoins sind ZKPs sowohl der ultimative Schutzschild als auch die größte Schwachstelle bei schlechter Implementierung.
Das Verständnis der genauen kryptografischen Mechanismen — Commitments, Circuits, Arithmetisierung, Beweissysteme — ist entscheidend, um Privacy-Coins jenseits von Marketing-Narrativen richtig zu bewerten.