Zero-Knowledge auf Bitcoin: Beweise und abgeschirmte Transfers

Neugier

1. Wie kann sich verschlüsselter Wert auf einer öffentlichen Blockchain bewegen, ohne die Konsensregeln zu ändern?
2. Was verrät ein Nullifier über eine ausgegebene Note – und was verbirgt er?
3. Warum sollte sich ein Protokoll zur Validierung seines Kernzustands auf einen Indexer statt auf Full Nodes verlassen?

Erkunden

Teil IShielded Bitcoin: private Überweisungen ohne Soft Fork

1. Clara Shikhelman, Mikhail Komarov und Aleksei Moskvin veröffentlichten am 24. September 2026 „Shielded Bitcoin“. Das 56-seitige Paper schlägt ein Design vor, das die Architektur der Sapling- und Orchard-Pools von Zcash für Bitcoin übernimmt. Werte werden als verschlüsselte Notes statt als gewöhnliche UTXOs gehalten. Beim Ausgeben einer Note wird ein Nullifier offengelegt, um Double Spending zu verhindern, doch diese Kennung lässt sich nicht auf die konkrete Note oder ihre ursprüngliche Herkunft zurückführen.
2. Jeder Transfer besteht aus einer gewöhnlichen Bitcoin-Transaktion mit einem OP_RETURN-Output. Dieser Output enthält einen Envelope mit einem Groth16-Zero-Knowledge-Proof von etwa 192 Bytes. Der Proof belegt, dass der Transfer gültig und ausgeglichen ist, ohne die zugrunde liegenden Daten offenzulegen. Ein typischer Envelope mit zwei Inputs und zwei Outputs belegt etwa 610 Bytes, der OP_RETURN-Output etwa 625 vB. Die Konsensregeln von Bitcoin ignorieren diese Daten vollständig; sie gelten als nicht ausgebbare Nutzlast.
3. Da Full Nodes den OP_RETURN-Inhalt nicht validieren, müssen Indexer diese Envelopes in Blockreihenfolge nachspielen, um den Note-Tree, das Nullifier-Set und die Merkle-Roots zu rekonstruieren. Taucht ein ungültiger Transfer in einem Block auf, ignorieren die Indexer ihn einfach, statt den Block abzulehnen. Damit verlagert sich die Verifizierung von Full Nodes auf Indexer-Software. Ein unehrlicher Indexer kann veralteten oder unvollständigen Zustand ausliefern, aber keine Gelder entwenden – und jeder kann seinen eigenen betreiben.
4. Das Design verbirgt Beträge, Sender, Empfänger und Positionen im Transaktionsgraphen vor der Chain-Analyse. Timing, Gebühren, die Struktur des Datenträgers und die Anzahl der Inputs/Outputs bleiben jedoch on-chain sichtbar. Das Relay dieser Transaktionen hängt vom höheren Standard-Data-Carrier-Limit von Bitcoin Core v30 ab – einer Policy-Änderung, nicht einem Konsens-Upgrade. Würden viele Betreiber strengere Limits setzen, ließen sich solche Transaktionen schwerer weiterleiten, auch wenn Miner, die sie akzeptieren, sie weiterhin aufnehmen könnten.
5. Das Paper klammert Peg-in- und Peg-out-Mechanismen für dieses erste Design ausdrücklich aus. Die Autoren wollen diese Komponenten auf Bitcoin PIPEs v2 aufbauen und dabei Witness Encryption nutzen, um Private Keys hinter kryptografischen Aussagen zu verschließen. Dieser Ansatz ermöglicht Programmierbarkeit über bestehende Schnorr-Signaturen statt über neue Opcodes. Derzeit hat das Projekt weder eine Implementierung noch Nutzer noch im Umlauf befindliche Gelder; es bleibt eine theoretische Spezifikation.
6. Das Design hat bekannte Grenzen. Groth16 benötigt ein einmaliges Trusted Setup, das sicher ist, sofern mindestens ein Teilnehmer der Zeremonie ehrlich war. Ein neuer Pool startet mit einem Anonymity Set von null, sodass frühe Nutzer leichter zu unterscheiden sind. Ein Transfer wird mit etwa 700 vB angegeben, ein Mehrfaches einer gewöhnlichen Zahlung. Die Proofs beruhen auf elliptischen Kurven, die ein großer Quantencomputer brechen könnte. Und solange Indexer ihren Zustand nicht kostengünstig beweisen können, müssen Light Wallets dem Indexer vertrauen, den sie abfragen, auch wenn dieser ihre Gelder nicht entwenden kann.

Teil IIZero-Knowledge-Proofs auf Bitcoin heute

7. Bitcoin Script wurde auf Einfachheit und Sicherheit ausgelegt, was seine Fähigkeit einschränkt, beliebigen Code auszuführen. Ein typischer Zero-Knowledge-Proof wie ein Groth16-SNARK erfordert pairing-basierte Arithmetik auf elliptischen Kurven, die Bitcoins aktueller Opcode-Satz nicht zu vertretbaren Kosten ausführen kann. Diese rechnerische Lücke bedeutet, dass das Netzwerk selbst diese Proofs ohne Soft Fork oder erheblichen Ressourcenaufwand pro Transaktion nicht nativ verifizieren kann.
8. Protokolle im Stil von BitVM lösen dies durch optimistische Verifizierung. Statt jeden Proof sofort zu prüfen, gehen sie von der Korrektheit aus und lösen die aufwendige Verifizierung nur bei einem Streitfall aus. Fechtet niemand den Zustandsübergang innerhalb einer festgelegten Frist an, gilt er als gültig. Die Sicherheit beruht auf Anreizen: Betreiber hinterlegen Sicherheiten, die sie verlieren, wenn sie betrügen, und jeder Beobachter kann Einspruch erheben.
9. Citreas Clementine-Bridge ging im Januar 2026 mit dieser BitVM2-Architektur im Mainnet live. Ihr Streitverfahren verifiziert einen Groth16-Proof mit einem Script-Verifier von etwa 1 GB (nach frühen Schätzungen von fast 3 GB), aufgeteilt in Teilstücke, die nur ausgeführt werden, wenn eine Anfechtung eingereicht wird. Dieses Design ermöglicht es, komplexe Zustandsübergänge unter der Annahme einer einzigen ehrlichen Partei durch Bitcoin abzusichern, ohne dass jeder Full Node bei routinemäßigen Transaktionen die aufwendigen kryptografischen Prüfungen ausführen muss.
10. Alpens Glock-Projekt demonstrierte einen alternativen Ansatz mit Garbled Circuits und erreichte im Juli 2026 ein Signet-Testnetz. Glock nutzt Garbled Circuits, um die Verifizierung eines Proofs im Streitfall on-chain deutlich günstiger zu machen. Der Ansatz bleibt streitbasiert, hat aber einen weitaus kleineren On-Chain-Fußabdruck, und beide Ansätze räumen ein, dass die native Verifizierung fortgeschrittener Kryptografie in Script für den allgemeinen Einsatz weiterhin unerschwinglich teuer ist.
11. Client-Side Validation bietet einen weiteren Weg, bei dem Proofs von Nutzern oder Indexern statt von der Basisschicht geprüft werden. Protokolle wie RGB und Taproot Assets setzen darauf, dass Teilnehmer Eigentumsnachweise lokal verifizieren. Ebenso sehen Designs von Shielded Bitcoin vor, dass Indexer Transaktions-Envelopes nachspielen, um Note-Trees neu aufzubauen; ungültige Transfers werden vom Konsens ignoriert, lassen sich aber durch Überwachungssoftware erkennen, die die vollständige Verifizierungslogik außerhalb des Nodes ausführt.
12. Diese Systeme bringen spezifische Zielkonflikte mit sich. Groth16 erfordert ein Trusted Setup, bei dem eine Zeremonie sicherstellen muss, dass niemand toxische Geheimnisse zurückbehält, mit denen sich Proofs entwerten ließen. Streittransaktionen in optimistischen Systemen sind groß und komplex, was Probleme beim Relay verursacht. Zudem sind die pairing-freundlichen Kurven hinter Groth16, wie auch Bitcoins eigene secp256k1, anfällig für einen großen Quantencomputer; ein solcher könnte daher Proofs fälschen und die ECDH-basierte Verschlüsselung der Notes brechen, auch wenn Groth16-Proofs selbst keine Geheimnisse preisgeben.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• Shikhelman, Komarov & Moskvin, 'Shielded Bitcoin' ([alloc] init, September 24, 2026)
• D. Hopwood et al., Zcash Protocol Specification (Sapling and Orchard)
• Bitcoin Core v30 release notes
• news.bitcoin.com coverage of Shielded Bitcoin (2026)
• R. Linus et al., 'BitVM2: Bridging Bitcoin to Second Layers' (2024)
• Citrea documentation and mainnet announcement (2026)
• Alpen, 'Glock is here' (July 2026)