Zero-Knowledge-Beweise erklärt: SNARKs, STARKs und was sie tatsächlich beweisen

2026-08-12

Ein Zero-Knowledge-Beweis ist eine kryptografische Methode, mit der gezeigt werden kann, dass eine sorgfältig bestimmte Aussage gültig ist, ohne die privaten Informationen offenzulegen, die sie gültig machen. Der Name kann zu einer zu weiten Auslegung verleiten. Er bedeutet nicht, dass ein System überhaupt nichts preisgibt. Ein Beweis zeigt in der Regel, dass eine definierte Aussage definierte Verifikationsregeln erfüllt hat; eine Anwendung kann daneben öffentliche Eingaben, Zeitpunkte, Protokolle, Kennungen oder andere Metadaten außerhalb des Beweises sichtbar machen.

Die hilfreiche Frage ist daher konkret: Welche Aussage wird bewiesen, was ist privat, was ist öffentlich und was stellt eine erfolgreiche Verifikation fest? Dieser Artikel führt diese Begriffe ein und erklärt anschließend SNARK und STARK als breite Familien von Zero-Knowledge-Beweissystemen. Er ist eine Bildungsdarstellung, keine Empfehlung, ein bestimmtes Beweissystem zu verwenden, auszuwählen oder sich darauf zu verlassen.

Konzeptdiagramm eines Provers und Verifizierers

Aussagen, Zeugen und definierte Beziehungen

Jedes Beweissystem beginnt mit einer Beziehung, die es auswerten kann. Der öffentliche Teil heißt häufig Aussage. Eine Aussage kann besagen, dass ein Wert veröffentlichte Bedingungen erfüllt oder dass eine Berechnung nach einem deklarierten Regelwerk ein Ergebnis erzeugt hat. Die Information, die zeigt, warum die Aussage wahr ist, wird üblicherweise Zeuge genannt. Ein Zeuge kann ein geheimer Wert, eine Sammlung von Eingaben oder andere vom Beweissystem definierte private Information sein.

Die Grenze zwischen Aussage und Zeuge ist entscheidend. Ein Verifizierer kann nur die Beziehung prüfen, die kodiert wurde. Sagt eine Aussage, dass eine Eingabe eine bestimmte Bedingung erfüllt, stellt die Annahme diese Bedingung nach den Systemregeln fest. Sie belegt nicht automatisch, woher die Eingabe stammt, ob alle relevanten Tatsachen der realen Welt einbezogen wurden oder was eine Person nach der Verifikation tun will. Dafür sind eigene Nachweise, Definitionen und Governance nötig.

Viele Systeme beschreiben die Beziehung durch einen programmähnlichen Schaltkreis. Ein Schaltkreis ist hier eine Abstraktion für beschränkte Operationen, die das Beweissystem prüfen kann; er ist nicht einfach ein gewöhnliches Anwendungsprogramm. Wie eine Beziehung geschrieben wird, welche Felder sie verwendet und welche Einschränkungen sie durchsetzt, unterscheidet sich zwischen Konstruktionen. Ein Beweis betrifft folglich eine präzise Beziehung, keine vage Behauptung über die Wirklichkeit.

Diese Begriffe erklären auch, warum eine gut formulierte Aussage unerlässlich ist. Lässt eine Beziehung eine wichtige Bedingung aus, kann ein Beweis für die unvollständige Beziehung dennoch gültig sein. Kryptografie schützt die Integrität der definierten Beziehung; sie entscheidet nicht, welche Anforderungen der realen Welt darin enthalten sein sollten.

Was Zero Knowledge verbirgt und was nicht

Die Zero-Knowledge-Eigenschaft betrifft das, was ein Verifizierer durch den Empfang oder die Interaktion mit einem Beweis lernt. Informell soll er überzeugt werden, dass eine Aussage gültig ist, ohne den Zeugen über das hinaus zu erfahren, was die Aussage selbst offenlegt. Klassische Arbeiten zu interaktiven Beweissystemen formalisieren diese Intuition, indem sie die reale Sicht eines Verifizierers mit einer simulierten Sicht vergleichen, die den Zeugen nicht verwendet.

Diese Eigenschaft gehört zu einem Protokoll, nicht automatisch zu jeder Schicht einer umgebenden Anwendung. Ein System kann absichtlich eine Aussage oder öffentliche Eingaben veröffentlichen, Protokolle speichern, eine Kennung offenlegen oder über ein Netzwerk kommunizieren, das Metadaten transportiert. Ein Beweis kann die Offenlegung eines Zeugen begrenzen, während andere Systemteile andere Datenschutzrisiken schaffen. Die Datenschutzanalyse muss daher den vollständigen Informationsfluss betrachten, nicht nur das Vorhandensein eines Zero-Knowledge-Beweises.

Zero Knowledge macht den Verifizierer auch nicht passiv. Er erhält genügend Beweismaterial, um die vorgeschriebenen Prüfungen auszuführen. Das Protokoll ist so angelegt, dass dieses Material die Annahme der Aussage unterstützt, ohne den geheimen Zeugen in nutzbarer Form preiszugeben, vorbehaltlich der Annahmen und des definierten Geltungsbereichs der Konstruktion. Wer ein Beweisergebnis auslegt, muss wissen, was absichtlich offengelegt wird.

Prover und Verifizierer

Der Prover ist die Partei oder Komponente, die den Zeugen besitzt und einen Beweis erzeugt. Der Verifizierer erhält die öffentliche Aussage, die einschlägigen öffentlichen Parameter und die Beweisdaten und führt dann das Verifikationsverfahren aus. Das sind Rollen, keine festen Arten von Personen. Eine Anwendung kann sie als unabhängige Dienste, lokale Komponenten oder Teilnehmer einer verteilten Umgebung organisieren.

Beweiserzeugung und Verifikation verfolgen unterschiedliche Zwecke. Der Prover zeigt, dass er die Beziehung mit dem Zeugen erfüllen kann. Der Verifizierer prüft, ob der Beweis zur Beziehung und ihren Verifikationsregeln passt. Er muss die private Berechnung nicht reproduzieren, nur weil er einen Beweis erhalten hat. Arbeitsaufwand, Beweismaterial, Interaktion und öffentliche Einrichtung unterscheiden sich je nach Konstruktion.

Auch der Kontext ist relevant. Ein für eine Aussage gültiger Beweis ist nicht automatisch für eine andere Aussage sinnvoll. Versionen, öffentliche Eingaben, Beziehungsdefinitionen und Verifikationsmaterial können die Auslegung beeinflussen. Ein Beweissystem kann nicht bestimmen, ob ein technisches Ergebnis für eine rechtliche, wissenschaftliche, organisatorische oder soziale Entscheidung angemessen ist. Die Beziehung zu definieren und das Ergebnis auszulegen, bleibt Aufgabe der Anwendung.

Vollständigkeit, Soundness und Annahme

Zwei grundlegende Eigenschaften erklären, warum die Beweisverifikation nützlich ist. Vollständigkeit bedeutet grob, dass ein ehrlicher Prover mit einem gültigen Zeugen für eine wahre Aussage einen Beweis erzeugen können soll, den ein ehrlicher Verifizierer annimmt. Ohne Vollständigkeit könnte ein korrekter Teilnehmer abgelehnt werden, obwohl die Beziehung erfüllt ist.

Soundness betrifft die entgegengesetzte Richtung. Grob bedeutet sie, dass ein Prover einen Verifizierer nicht dazu bringen können soll, eine falsche Aussage anzunehmen, außer mit der begrenzten Wahrscheinlichkeit oder unter den Annahmen, die das System festlegt. Soundness ist keine universelle Eigenschaft zur Faktenprüfung. Sie gilt für eine formale Beziehung, ein Angreifermodell und eine Sicherheitsdefinition. Sie beweist nicht selbstständig, dass Eingaben richtig erhoben wurden oder eine nicht kodierte Behauptung der realen Welt wahr ist.

Manche Konstruktionen sprechen auch von Knowledge Soundness. Auf hoher Ebene verbindet der Begriff einen erfolgreichen Beweis mit der Idee, dass der Prover einen Zeugen der verlangten Art besitzt oder erzeugen kann. Seine genaue Definition ist technisch und konstruktionsspezifisch. Sie darf nicht als Behauptung wiedergegeben werden, der Prover kenne jede Kontexttatsache, die ein Leser mit der öffentlichen Aussage verbinden könnte.

Zusammen geben Vollständigkeit und Soundness der Annahme eine begrenzte Bedeutung: Korrekt geformte Belege für eine wahre Beziehung sollen akzeptiert werden, falsche Beziehungen nicht bloß deshalb, weil sie behauptet werden. Sie ersetzen nicht die Notwendigkeit, die richtige Beziehung zu formulieren, sie korrekt zu implementieren und das Ergebnis im Kontext zu bewerten.

Beweiserzeugung und Verifikation im Kontext

Auf begrifflicher Ebene beginnt die Beweiserzeugung mit einer öffentlichen Aussage, einem privaten Zeugen und einer Beziehung, die beide verbindet. Der Prover führt die vom System vorgeschriebenen Operationen aus und erzeugt Beweisdaten. Die Verifikation beginnt mit der öffentlichen Aussage, dem erforderlichen Verifikationsmaterial und diesen Beweisdaten. Der Verifizierer gibt nach dem Protokoll Annahme oder Ablehnung zurück.

Verschiedene Systeme treffen unterschiedliche Entscheidungen zu Interaktion, Zufälligkeit, öffentlichen Parametern, kryptografischen Annahmen und der Darstellung von Berechnungen. Manche enthalten eine Setup-Phase, die Parameter erzeugt; andere werden als transparent beschrieben, weil sie keinen geheimen Setup-Teilnehmer benötigen. Diese Designentscheidungen sind wichtig, doch die Etiketten allein stellen nicht fest, dass eine vollständige Implementierung die beabsichtigten Sicherheitseigenschaften hat.

Vier Fragen bleiben über Systeme hinweg hilfreich: Welche genaue Aussage ist öffentlich? Was ist der Zeuge? Welches Verifikationsmaterial wird angenommen oder vertraut? Was stellt die Annahme fest und was lässt sie offen? Diese Fragen gelten unabhängig davon, ob ein Beweis mit einem Ledger, einem Credential, einer Datenbank oder einem anderen Softwaresystem verbunden ist.

SNARK und STARK als Familien von Beweissystemen

SNARK wird üblicherweise als „Succinct Non-interactive Argument of Knowledge“ ausgeschrieben. SNARK-Konstruktionen wollen in groben Zügen ermöglichen, dass ein Prover einen kompakten Beweis erzeugt, den ein Verifizierer ohne interaktiven Austausch prüfen kann. „Argument“ hat eine technische Bedeutung: Die Sicherheit beruht auf rechnerischen Annahmen, nicht auf einer unbedingten mathematischen Garantie. Einzelne Konstruktionen können sich in Setup-Modell, Annahmen, Beweisdarstellung und den unterstützten Beziehungen unterscheiden.

Forschung wie die Pinocchio-Arbeit zeigt eine bekannte Struktur der verifizierbaren Berechnung: Öffentliches Material beschreibt eine Berechnung, ein Ausführender erzeugt einen Beweis für eine bestimmte Eingabe und ein Verifizierer prüft ihn. Dieses historische Beispiel ist keine Definition jedes später als SNARK bezeichneten Systems. Der Oberbegriff umfasst verwandte Ideen, keine einheitliche Implementierung.

STARK wird meist als „Scalable Transparent Argument of Knowledge“ ausgeschrieben. Der Begriff wird mit Konstruktionen verbunden, die Transparenz in ihrem Setup-Modell betonen und andere Beweistechniken als gängige pairing-basierte SNARK-Ansätze verwenden. Die ursprüngliche STARK-Forschung behandelt transparente Rechenintegrität und einen postquanten-sicheren Kontext. Diese Beschreibungen betreffen eine Konstruktion und ihre Annahmen; sie machen nicht jede Implementierung austauschbar und begründen kein universelles Ergebnis.

Der nützlichste Vergleich ist daher konkret. Er betrachtet die formalen Annahmen einer bestimmten Konstruktion, Setup-Anforderungen, Darstellung der Beziehung, Verifikationsumgebung, Implementierungsqualität und öffentliche Daten. SNARK und STARK sind Begriffslandkarten, keine automatischen Schlussfolgerungen über Sicherheit, Datenschutz oder Eignung eines Systems.

Geltungsbereich, Grenzen und umgebendes Vertrauen

Ein gültiger Beweis stellt nur die durch seine Beziehung dargestellte Aussage fest. Er zeigt nicht eigenständig, dass Ausgangsdaten fair erhoben wurden, eine Quelle befugt war, ein externes Ereignis stattgefunden hat oder die Aussage aktuell bleibt. Erhält eine Beziehung unvollständige oder irreführende Eingaben, kann die Verifikation für diese Eingaben dennoch korrekt sein. Der Beweis schützt eine definierte Berechnung, nicht jede mögliche Auslegung ihres Ergebnisses.

Zero Knowledge beseitigt auch nicht alle Datenschutzfragen. Öffentliche Eingaben können aufschlussreich sein, wiederholte Präsentationen können Verknüpfungen schaffen und Netzwerk-, Geräte-, Konto-, Schnittstellen- sowie Anwendungsmetadaten können außerhalb des Beweises bestehen. Ein Design muss diese Kanäle direkt prüfen, statt den Beweis als vollständige Datenschutzgrenze zu behandeln.

Praktische Sicherheit hängt außerdem von mathematischen Annahmen, gegebenenfalls Parameterbehandlung, korrekter Software und einem Verifizierer ab, der die beabsichtigte Aussage bewertet. Fehler auf jeder dieser Ebenen können das Ergebnis verändern. Deshalb sollten kurze Etiketten wie SNARK oder STARK ein Ausgangspunkt für sorgfältiges Lesen sein, nicht ein abschließendes Urteil.

Bei der Auslegung einer Beweisbehauptung sollten Aussage, Zeuge, öffentliche Eingaben, Prover, Verifizierer und Verifikationsmaterial benannt werden. Danach ist technische Annahme von weiterem Vertrauen zu trennen: Ein Verifizierer kann feststellen, dass ein Ergebnis Protokollregeln erfüllt, und dennoch Quellen, Definitionen, Kontext und eigene Regeln bewerten müssen. Diese disziplinierte Unterscheidung zeigt, was Zero-Knowledge-Beweise tatsächlich beweisen und wo ihre Grenzen bleiben.

Haftungsausschluss: Dieser Artikel ist Bildungsinhalt der Bitbase Academy, nur zu Informationszwecken. Er ist keine Anlage-, Handels-, Steuer- oder Finanzberatung. Krypto-Assets sind volatil — schätze dein Risiko selbst ein. Stand August 2026; maßgeblich sind die aktuellen offiziellen Informationen.