Alexander Neitzel · geprüft 25.10.2026 · aktualisiert 25.10.2026 · 7 Min. Lesezeit
In Kürze
Ein Zero-Knowledge Proof (Beweis ohne Preisgabe der Daten) beweist, dass eine Aussage wahr ist, ohne eine Information preiszugeben außer genau dieser Tatsache.
Ein Prover (Beweisender) überzeugt dabei einen Verifier (Prüfender), entweder im Wechsel aus Commitment, Challenge und Antwort oder ohne Wechsel, etwa wenn beim Schnorr-Verfahren eine Hash Function die Challenge erzeugt.
zk-STARKs erzeugen ihre öffentlichen Parameter aus öffentlich überprüfbarer Zufälligkeit statt mit einem Trusted Setup, ihre Beweise sind aber größer als die von zk-SNARKs.
Zcash sichert abgeschirmte Zahlungen mit zk-SNARKs, ZK-Rollups reichen Validity Proofs ein, und diese machen ihre Transaktionen nicht von selbst vertraulich.
NiveauTiefeStufe 3 von 3
Baut auf1Hash Function
Verbunden3Themen
Bei einem Zero-Knowledge Proof (Beweis ohne Preisgabe der Daten) will der Prover (Beweisender) eine Aussage beweisen, und der Verifier (Prüfender) prüft sie. Die Aussage selbst ist dabei öffentlich; über die privaten Eingaben verrät ein solcher Beweis nichts, was nicht aus der öffentlichen Aussage folgt. Dieser Artikel erklärt die Eigenschaften eines solchen Beweises, seinen Ablauf und wo Blockchains ihn einsetzen. Vorausgesetzt wird vor allem, was eine Hash Function (Hashfunktion) ist; weitere Begriffe sind verlinkt.
01Was leistet ein Zero-Knowledge Proof?
Die Ethereum-Dokumentation nennt diese Definition: Mit einem Zero-Knowledge-Protokoll kann der Prover dem Verifier beweisen, dass etwas wahr ist, ohne eine Information preiszugeben außer der Tatsache, dass genau diese Aussage wahr ist. Dieselbe Dokumentation beschreibt drei Eigenschaften:
Completeness (Vollständigkeit): Ist die Eingabe gültig, liefert das Zero-Knowledge-Protokoll immer „wahr“.
Soundness (Korrektheit): Ist die Eingabe ungültig, soll sich das Protokoll nicht so täuschen lassen, dass es „wahr“ liefert; ein Betrug ist damit äußerst unwahrscheinlich.
Zero-Knowledge (Null-Wissen): Der Verifier erfährt über eine Aussage nichts außer, ob sie gültig ist oder nicht; daher der Name.
Die Dokumentation zu Halo 2 nennt die privaten Eingaben zusammen mit Hilfswerten (advice values) den Witness, wörtlich „Zeuge“; gemeint ist also Information, keine Person. Den dritten Punkt fasst sie so: Ein Beweissystem ist zero knowledge, wenn ein Beweis über den Witness nichts verrät, außer dass es einen gibt und der Prover ihn kannte. Ein Beispiel von dort: Beim Beweis, zu einem Hashwert y ein Urbild x zu kennen, also eine passende Eingabe, ist das Urbild x die private Eingabe und der Hashwert y die öffentliche.
Grafik 1 · Die beiden Rollen, vereinfacht als Beweis in eine Richtung; im interaktiven Verfahren sendet auch der Verifier (Grafik 2). Der Prover kennt den Witness und beweist eine Aussage; der Verifier erfährt, dass sie wahr ist, und über den Witness nur, dass es ihn gibt und der Prover ihn kannte.Grafik 1 in Worten
Die Grafik zeigt zwei Parteien als Kreise. Im Querformat steht der Prover (Beweisender) links und der Verifier (Prüfender) rechts, im Hochformat steht der Prover oben und der Verifier unten. Im Kreis des Provers liegt ein heller Punkt in einem gestrichelten Ring (geheime Eingabe) mit der Marke „Witness“, darunter steht „kennt den Witness“. Im Kreis des Verifiers steht ein goldenes Häkchen (das Ergebnis) mit der Marke „wahr“, darunter „prüft die Aussage“. Vom Prover zum Verifier laufen drei Linien mit wandernden Punkten; sie tragen die Beschriftung „Beweis“. Zwischen den Parteien steht das Band „Überzeugung fließt – das Geheimnis bleibt“.
02Wie läuft ein interaktiver Beweis ab?
Ein Beispiel ist das Schnorr-Verfahren nach RFC 8235: Darin veröffentlicht der Prover vorab seinen Public Key (öffentlicher Schlüssel) A, berechnet aus seinem Private Key (privater Schlüssel) a, und der Beweis läuft im Wechsel zwischen Prover und Verifier. Wie ein solches Schlüsselpaar funktioniert, erklärt der Artikel über Public-Key Cryptography (Kryptografie mit öffentlichem Schlüssel).
Zuerst wählt der Prover zufällig eine Zahl v, berechnet daraus einen Wert V und schickt V an den Verifier. Diesen Wert des Provers nennt RFC 8235 ein Commitment (Festlegung). Dann wählt der Verifier zufällig eine Challenge (Herausforderung) c; ihre Länge in Bit heißt t. Der Prover berechnet aus v, seinem Private Key a und c die Antwort r und schickt sie an den Verifier. Am Ende führt der Verifier die im RFC festgelegten Prüfungen durch.
Grafik 2 · Der Ablauf nach RFC 8235: Commitment, Challenge, Antwort; a ist der Private Key des Provers. Am Protokollende führt der Verifier die Prüfung durch (④).Grafik 2 in Worten
Zwei Linien stehen für den Prover und den Verifier. Im Querformat verläuft die Linie des Provers oben und die des Verifiers unten, im Hochformat steht der Prover links und der Verifier rechts. Drei nummerierte Pfeile und ein Prüfschritt zeigen den Ablauf. ① Commitment (Festlegung) führt vom Prover zum Verifier, mit dem Text „V aus Zufallszahl v“. ② Challenge (Herausforderung) führt vom Verifier zum Prover, mit dem Text „zufällige Zahl c“. ③ Antwort führt vom Prover zum Verifier, mit dem Text „r aus v, a und c“. ④ Prüfung ist ein goldenes Feld mit Häkchen auf der Linie des Verifiers, mit dem Text „am Protokollende“; das Häkchen steht für das Ergebnis der Prüfung. Die Grafik zeigt einen einzigen Durchlauf, keine Wiederholung, keine Wahrscheinlichkeiten und nicht, was die Prüfung im Einzelnen verlangt.
Für interaktive Beweise im Allgemeinen schreibt die Ethereum-Dokumentation: Wird der Austausch viele Male wiederholt, sinkt die Möglichkeit deutlich, dass der Prover die Kenntnis des Witness nur vortäuscht, bis der Verifier zufrieden ist.
Für Fortgeschrittene: Wie sicher ist ein Durchlauf des Schnorr-Verfahrens?
Nach RFC 8235 ist für das Schnorr-Verfahren bewiesen, dass es die folgenden Eigenschaften erfüllt, unter der Annahme, dass der Verifier ehrlich ist und der diskrete Logarithmus nicht effizient berechnet werden kann. RFC 8235 nennt die Soundness des Schnorr-Verfahrens konkret: Wer den diskreten Logarithmus nicht kennt, hier den Private Key a, besteht die Prüfung nur mit vernachlässigbarer Wahrscheinlichkeit von 2^(-t) bei t Bit Challenge. Als dritte Eigenschaft nennt RFC 8235 Zero-Knowledge nur gegenüber einem ehrlichen Verifier (honest verifier zero-knowledge): Ihm gibt der Prover höchstens ein Bit Information preis, nämlich ob er den diskreten Logarithmus kennt.
03Wie wird aus dem Austausch ein einzelner Beweis?
RFC 8235 beschreibt auch eine nicht-interaktive Fassung: Der nicht-interaktive Schnorr-Beweis entsteht aus dem interaktiven Verfahren durch die Fiat-Shamir-Transformation (Fiat-Shamir-Umwandlung). Nach Darstellung von RFC 8235 erzeugt bei dieser Umwandlung eine sichere Hash Function die Challenge, statt dass der Verifier sie wählt. Weil die Hash Function öffentlich festgelegt ist, kann der Prover die Challenge selbst berechnen; dadurch wird das Verfahren nicht-interaktiv.
zk-SNARK ist die Abkürzung für Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. Succinct (knapp) heißt: Der Beweis ist kleiner als der Witness und lässt sich schnell prüfen.
Die Ethereum-Dokumentation beschreibt dazu öffentliche Parameter, auf die sich Prover und Verifier einigen, um mit ihnen Beweise zu erzeugen und zu prüfen. Gelangt die Zufallsinformation, mit der diese Parameter als Common Reference String (gemeinsame Referenzzeichenfolge) erzeugt werden, an einen unehrlichen Prover, kann er falsche Beweise berechnen. Einige ZK-Rollups versuchen, dieses Problem mit einer Zeremonie mehrerer Beteiligter zu lösen, einer Multi-Party Computation (Mehrparteienberechnung).
zk-STARK steht für Zero-Knowledge Scalable Transparent Argument of Knowledge. Transparent heißt hier: zk-STARK erzeugt die öffentlichen Parameter für Beweis und Prüfung aus öffentlich überprüfbarer Zufälligkeit statt mit einem Trusted Setup (vertrauenswürdige Einrichtungsphase). Allerdings erzeugen zk-STARKs größere Beweise als zk-SNARKs, was in der Regel einen höheren Aufwand bei der Prüfung bedeutet.
Nach Darstellung der Ethereum-Dokumentation gilt zk-STARK als widerstandsfähig gegen die Bedrohung durch Quantencomputer, weil es für seine Sicherheit nur auf kollisionsresistente Hash Functions setzt. Nach Darstellung von ethereum.org gilt die in zk-SNARKs genutzte Elliptic Curve Cryptography (Kryptografie auf elliptischen Kurven) dagegen weithin als anfällig für Angriffe mit Quantencomputern.
Für Fortgeschrittene: Welche Einrichtung brauchen einzelne Beweissysteme?
Die Fachveröffentlichung zu Groth16 beschreibt einen Pairing-basierten SNARK mit Vorverarbeitung (preprocessing) für die Erfüllbarkeit arithmetischer Circuits (Schaltkreise). Nach dem PLONK-Paper beseitigen zk-SNARK-Konstruktionen mit einem aktualisierbaren, universellen Structured Reference String (strukturierte Referenzzeichenfolge) eines der Haupthindernisse für den Einsatz von zk-SNARKs. Für Halo 2 erzeugt die halo2-Bibliothek die Parameter einer bestimmten Circuit-Implementierung bei Bedarf selbst; Parameterdateien braucht es dafür nicht. Das STARK-Paper verlangt Transparenz: ZK-Systeme sollen ohne Abhängigkeit von einer vertrauenswürdigen Partei eingerichtet sein und keine Hintertüren haben, die mächtige Parteien nutzen könnten, um, wie es dort heißt, „falsches Zeugnis“ abzulegen.
Nach Darstellung der Zcash-Spezifikation verbindet Zcash ein bestehendes transparentes Zahlungsschema mit einem abgeschirmten (shielded) Zahlungsschema, das durch zk-SNARKs gesichert ist. Nach der Aktivierung des Upgrades Sapling nutzt Zcash zk-SNARKs mit dem Beweissystem Groth16. Für Aktionen im Orchard-Pool nutzt Zcash zk-SNARKs mit dem Beweissystem Halo 2. Verschlüsselung ist dort ein eigener Mechanismus neben den Beweisen: Verschlüsselte Notes werden ihrem Empfänger übermittelt, und er kann sie entschlüsseln. Mehr zum Thema steht beim Narrativ Privacy.
ZK-Rollups bündeln Transaktionen zu Stapeln, die offchain ausgeführt werden, also nicht auf der Blockchain selbst. Um den Zustand des Rollups (gebündelte Transaktionsverarbeitung) zu aktualisieren, müssen seine Nodes einen Validity Proof (Gültigkeitsbeweis) zur Prüfung einreichen. Nach Darstellung der Ethereum-Dokumentation sichert dieser Beweis kryptografisch zu, dass die vorgeschlagene Zustandsänderung wirklich das Ergebnis der Ausführung des Stapels ist. Solche Beweise können die Form eines zk-SNARK oder eines zk-STARK haben. Nach der Ethereum-Dokumentation prüft ein eigener Onchain-Vertrag, der Verifier-Vertrag (Prüfvertrag), die eingereichten Beweise. Der Betreiber der Layer 2 (Zusatzschicht auf einer Basis-Blockchain) reicht den berechneten Validity Proof beim Verifier-Vertrag auf Layer 1 (Basisschicht eines Netzwerks) ein.
Der Zustand eines ZK-Rollups mit seinen Konten und Guthaben auf Layer 2 ist als Merkle Tree (Hashbaum) dargestellt; im Onchain-Vertrag liegt ein kryptografischer Hash seiner Wurzel, die Merkle Root.
Grafik 3 · Der Weg eines Stapels. Ausgeführt wird offchain; der Validity Proof wird beim Verifier-Vertrag onchain eingereicht und von diesem geprüft. Wie der Zustand danach fortgeschrieben wird, zeigt die Grafik nicht. Die Daten des Rollups werden zusätzlich veröffentlicht (nicht gezeigt); vertraulich macht der Validity Proof die Transaktionen nicht von selbst.Grafik 3 in Worten
Die Grafik zeigt drei Stationen. Im Querformat stehen sie von links nach rechts nebeneinander, im Hochformat von oben nach unten untereinander. Die erste Station heißt Transaktionen, Zweitzeile „(Stapel)“, Text „gebündelt, offchain ausgeführt“. Ein Pfeil mit der Beschriftung „belegt durch“ führt zur zweiten Station, dem Validity Proof (Gültigkeitsbeweis), Text „zk-SNARK oder zk-STARK“. Ein weiterer Pfeil mit der Beschriftung „eingereicht“ führt zur dritten Station, dem Verifier-Vertrag, Zweitzeile „(onchain)“, Text „prüft eingereichte Beweise“. Die Grafik zeigt nicht, wie der Zustand danach fortgeschrieben wird und welche Daten veröffentlicht werden.
06Machen ZK-Rollups Transaktionen privat?
Nicht von selbst: Nach Darstellung der Ethereum-Dokumentation werden die Daten eines Rollups auf der Blockchain veröffentlicht, sodass jeder seinen Zustand unabhängig nachrechnen kann. Diese Veröffentlichung macht eine Prüfung ohne Erlaubnis möglich; ein Datenschutzmechanismus ist sie nicht.
Ein Beweissystem kann zusätzlich Zero-Knowledge bieten: Seine Beweise verraten dann nichts über private Eingaben, was nicht aus der öffentlichen Aussage folgt. Das sind getrennte Eigenschaften: Wer Validity Proofs zur Skalierung nutzt, macht die Transaktionen eines Rollups dadurch allein nicht vertraulich.
Welche Narrative gerade breit besprochen werden, zeigt der Orbit.
07Häufige Missverständnisse
Verschlüsselt ein Zero-Knowledge Proof Daten?
Nein. Er beweist, dass eine Aussage gültig ist, und verrät dabei über den Witness nichts außer dass es ihn gibt und der Prover ihn kannte. Verschlüsselung ist ein eigener Mechanismus: In Zcash etwa werden Notes verschlüsselt an ihren Empfänger übermittelt, der sie entschlüsseln kann.
Erfährt der Verifier gar nichts?
Doch, genau eine Sache: ob die Aussage gültig ist oder nicht. Darüber hinaus gibt der Beweis keine Information preis.
Sind alle Beweissysteme gleich anfällig für Quantencomputer?
Nach der Ethereum-Dokumentation nicht. zk-STARK gilt dort als widerstandsfähig gegen die Bedrohung durch Quantencomputer, weil es für seine Sicherheit nur auf kollisionsresistente Hash Functions setzt. Die in zk-SNARKs genutzte Elliptic Curve Cryptography gilt dagegen weithin als anfällig für Angriffe mit Quantencomputern.
