Was sind zk-SNARKs und wie ermöglichen sie Privatsphäre auf Blockchains?

Was sind zk-SNARKs?

zk-SNARKs sind kryptografische Beweise, mit denen du zeigen kannst, dass bestimmte Informationen oder eine Berechnung korrekt sind, ohne datenschutzrelevante Informationen offenzulegen. Dadurch kann eine Blockchain zum Beispiel prüfen, dass eine Zahlung gültig ist, während Daten wie der Betrag oder der Empfänger verborgen bleiben. Eine der bekanntesten Blockchains, die diese Technologie nutzt, ist Zcash. Dort werden zk-SNARKs verwendet, um Transaktionen zu verifizieren, während Daten wie der Betrag oder der Empfänger verborgen bleiben können.

Der Name zk-SNARK ist eine Abkürzung für zero-knowledge succinct non-interactive argument of knowledge. Das klingt kompliziert, aber du kannst die Bestandteile einfach aufteilen:

• Zero-knowledge: Der Beweis zeigt, dass eine Aussage stimmt, zum Beispiel dass eine Transaktion gültig ist, ohne datenschutzrelevante Informationen wie Absenderadresse, Empfängeradresse oder Transaktionsbetrag preiszugeben.
• Succinct: Der Beweis ist kurz. Ein Node oder Smart Contract kann ihn also relativ effizient prüfen.
• Non-interactive: Nachdem der Beweis erstellt wurde, muss der Ersteller nicht mehr hin und her mit der prüfenden Partei kommunizieren. Der Beweis kann einmal erstellt und anschließend geprüft werden.
• Argument of knowledge: Der Ersteller zeigt, dass er über die Informationen verfügt, die nötig sind, um die festgelegten Regeln einzuhalten, zum Beispiel die Daten, mit denen eine gültige Transaktion erstellt werden kann. Die Sicherheit beruht dabei auf kryptografischen Annahmen: Ein Angreifer mit begrenzter Rechenleistung kann in der Praxis keinen falschen Beweis erzeugen, der als gültig akzeptiert wird. Die Informationen, mit denen der Beweis erstellt wird, werden oft als Witness bezeichnet. Stell dir vor, du willst beweisen, dass du genug Guthaben für eine Zahlung hast. Der Witness enthält dann zum Beispiel die Daten, mit denen du zeigen kannst, dass du über ausreichend Geld verfügst und es ausgeben darfst. Die Blockchain muss diese Daten nicht selbst sehen, kann aber trotzdem prüfen, dass der dazugehörige Beweis gültig ist.

Neben dem privaten Witness kann ein zk-SNARK auch öffentliche Eingaben enthalten. Das sind Daten, die sichtbar sein dürfen und die der Verifier zusammen mit dem Beweis nutzt, um zu prüfen, ob die Aussage stimmt.

Wichtig zu wissen: Ein zk-SNARK ist nicht ein festes Protokoll, sondern ein Sammelbegriff für verschiedene Arten von Beweissystemen mit diesen Eigenschaften. Die genaue Funktionsweise kann sich je nach System unterscheiden. Manche Systeme brauchen zum Beispiel ein Trusted Setup, während andere ohne ein solches Setup auskommen.

Wichtigste Erkenntnisse

• zk-SNARKs beweisen, dass etwas stimmt, ohne datenschutzrelevante Informationen preiszugeben.
• Die privaten Daten hinter einem Beweis werden oft als Witness bezeichnet.
• Die Beweise sind kurz und können relativ effizient geprüft werden.
• Ein veröffentlichter Beweis kann ohne zusätzlichen Kontakt mit dem Ersteller verifiziert werden.
• zk-SNARKs sind eine Kategorie von Beweissystemen, kein einzelnes festes Protokoll.

Wie funktionieren zk-SNARKs?

Bei einem zk-SNARK werden die Regeln, die eine Transaktion oder Berechnung erfüllen muss, zuerst in Prüfungen übersetzt, die ein Computer ausführen kann. Diese Sammlung von Prüfungen wird als Circuit oder Constraint-System bezeichnet. Darin steht genau, welche Bedingungen erfüllt sein müssen, bevor etwas als gültig gilt.

Nimm eine private Zahlung als Beispiel. Der Circuit kann zum Beispiel prüfen, ob jemand über genügend Guthaben verfügt, dieses Guthaben noch nicht zuvor ausgegeben hat und berechtigt ist, es zu verwenden. Die datenschutzrelevanten Daten, die für diese Prüfungen nötig sind, wie das Guthaben oder die Daten, mit denen es ausgegeben werden darf, bleiben für die prüfende Partei verborgen.

Im Großen und Ganzen gibt es drei Schritte:

1. Setup Bei vielen klassischen zk-SNARKs werden zuerst öffentliche Parameter erstellt. Diese Daten werden benötigt, um Beweise zu erzeugen und zu prüfen.

2. Proof generation Der Prover, also die Partei, die etwas beweisen will, nutzt den Witness und die Regeln des Circuits, um einen kryptografischen Beweis zu erstellen.

3. Verifikation Der Verifier, zum Beispiel ein Node oder Smart Contract, prüft den Beweis zusammen mit den öffentlichen Eingaben. Der Verifier sieht den privaten Witness nicht und muss die vollständige Berechnung nicht selbst noch einmal ausführen.

Ein gutes zk-SNARK-System versucht, drei wichtige Eigenschaften zu garantieren. Erstens Vollständigkeit: Wenn die Aussage stimmt und der Beweis korrekt erstellt wurde, wird der Beweis akzeptiert. Zweitens Soundness: Ein Angreifer kann in der Praxis keinen gültigen Beweis für eine Aussage erstellen, die nicht stimmt. Und drittens Zero-Knowledge: Der Beweis gibt keine datenschutzrelevanten Informationen preis, außer der Tatsache, dass die bewiesene Aussage stimmt.

Beispiel: Stell dir vor, du musst beweisen, dass du älter als 18 bist, ohne dein Geburtsdatum zu teilen. Ein zk-SNARK kann theoretisch beweisen, dass du diese Bedingung erfüllst, ohne dass der Prüfer dein Geburtsdatum oder dein genaues Alter sieht.

Es gibt aber eine wichtige Grenze. Ein zk-SNARK prüft nur die Regeln, die im Circuit festgelegt sind. Wenn in diesen Regeln ein Fehler steckt, kann ein Beweis technisch gültig sein, obwohl das System trotzdem etwas erlaubt, was eigentlich nicht beabsichtigt war. Die Kryptografie kann einen falsch entworfenen Circuit also nicht automatisch korrigieren.

Wofür werden zk-SNARKs verwendet?

zk-SNARKs werden eingesetzt, wenn jemand zeigen will, dass eine Berechnung korrekt ausgeführt wurde, ohne alle Eingaben oder Zwischenschritte offenzulegen. Das macht die Technik interessant für Privatsphäre, aber auch für Anwendungen, bei denen die prüfende Partei die vollständige Berechnung nicht noch einmal ausführen muss.

Ein paar bekannte Anwendungen sind:

• private Zahlungen;
• Anwendungen, bei denen Eingaben oder Teile der Berechnung privat bleiben;
• Identitäts- und Credential-Beweise, bei denen du eine Eigenschaft nachweist, ohne alle personenbezogenen Daten zu teilen;
• Proof-of-Reserves, bei denen eine Partei nachweisen kann, dass bestimmte Reserven vorhanden sind, ohne alle zugrunde liegenden Daten offenzulegen;
• Validity Rollups, die viele Transaktionen außerhalb von Ethereum verarbeiten und anschließend einen Beweis für die korrekte Verarbeitung auf Ethereum hinterlegen.

Aleo nutzt zum Beispiel ein Modell, bei dem ein Programm lokal ausgeführt wird. Danach wird ein Zero-Knowledge-Beweis erstellt, mit dem gezeigt werden kann, dass die Ausführung korrekt war. Validatoren müssen dann nicht alle privaten Eingaben und Zwischenschritte erhalten, sondern können den Beweis prüfen.

Privatsphäre kommt nicht automatisch dazu, nur weil irgendwo „ZK“ verwendet wird. Welche Daten privat bleiben, hängt vom Protokoll und davon ab, was im Circuit als privat oder öffentlich festgelegt ist. Wenn bestimmte Transaktionsdaten bewusst öffentlich gemacht werden, kann ein zk-SNARK diese Daten nicht nachträglich verbergen.

Wie unterstützen zk-SNARKs Privatsphäre?

zk-SNARKs unterstützen Privatsphäre, weil du beweisen kannst, dass eine Transaktion gültig ist, ohne die datenschutzrelevanten Details offenzulegen. Bei einer privaten Zahlung kann jemand zum Beispiel beweisen, dass er über gültige Mittel verfügt, berechtigt ist, diese auszugeben, und kein Geld doppelt ausgibt. Absender, Empfänger und Betrag müssen dabei nicht öffentlich sein.

Zcash zeigt gut, wie so ein Design funktioniert. Dort wird eine Note verwendet, um eine bestimmte Menge ZEC privat festzuhalten. Auf der Blockchain steht nicht der vollständige Inhalt dieser Note, sondern ein Commitment: eine kryptografische Festlegung davon. Du kannst es dir wie einen geschlossenen, versiegelten Umschlag vorstellen. Jeder kann sehen, dass der Umschlag existiert, aber nicht, was darin steckt.

Die Informationen über die Note werden für den Empfänger verschlüsselt. Wenn eine Note ausgegeben wird, erscheint ein eindeutiger Nullifier auf der Blockchain. Dieser Nullifier zeigt nicht direkt, welche Note ausgegeben wurde, aber Nodes können prüfen, ob derselbe Nullifier schon zuvor verwendet wurde. So kann das Netzwerk Double Spending verhindern, ohne die zugrunde liegenden privaten Daten offenzulegen.

Privatsphäre bedeutet hier also nicht, dass auf der Blockchain überhaupt keine Spur bleibt. Commitments und Nullifiers bleiben sichtbar. Auch Daten wie IP-Adressen, Timing, Netzwerkmetadaten und Informationen, die ein Nutzer selbst öffentlich macht, werden durch einen zk-SNARK nicht automatisch verborgen.

Wie werden zk-SNARKs für Skalierbarkeit genutzt?

Für Skalierbarkeit können zk-SNARKs genutzt werden, um eine große Menge Rechenarbeit in einem einzigen kompakten Beweis zusammenzufassen. Das sieht man zum Beispiel bei Validity Rollups: Transaktionen werden außerhalb von Ethereum verarbeitet, in Batches gebündelt und anschließend wird ein Beweis erstellt, dass die Verarbeitung korrekt abgelaufen ist.

Der Operator eines solchen Rollups verarbeitet die Transaktionen und erstellt einen Validity Proof, mit dem gezeigt wird, dass der neue Zustand nach den Regeln des Rollups berechnet wurde. Ein Verifier-Contract auf Ethereum akzeptiert diesen neuen Zustand nur, wenn der Beweis gültig ist. Ethereum muss dadurch nicht alle Berechnungen jeder einzelnen Transaktion noch einmal ausführen.

Mit Rekursion lässt sich das noch weiter zusammenfassen. Dabei kann ein neuer Beweis zeigen, dass mehrere frühere Beweise gültig sind. So können am Ende viele einzelne Berechnungen oder Beweise durch einen einzigen kompakten Beweis dargestellt werden.

Scroll nutzt zk-Beweise, um die korrekte Ausführung von Transaktionsbatches nachzuweisen, woraufhin der Beweis auf Ethereum geprüft werden kann.

Mina nutzt rekursive zk-SNARKs auf eine andere Weise. Statt dass ein Teilnehmer die gesamte Blockchain-Historie von Anfang an prüfen muss, kann die Gültigkeit des aktuellen Blockchain-States mit einem kompakten kryptografischen Beweis nachgewiesen werden.

Schnelle Verifikation bedeutet nicht, dass der gesamte Prozess günstig ist. Das Erstellen eines Beweises kann im Gegenteil viel Rechenleistung und Speicher erfordern. Außerdem löst ein Validity Proof nicht automatisch andere Probleme wie Datenverfügbarkeit, Zensur durch einen Operator oder Risiken rund um Bridges zwischen Blockchains.

Welche Blockchains und Kryptowährungen nutzen zk-SNARKs?

Verschiedene Krypto-Projekte nutzen zk-SNARKs, aber oft für unterschiedliche Zwecke. Die Technik wird also nicht nur für private Transaktionen eingesetzt.

• Zcash nutzt zk-SNARKs für shielded Transaktionen. Innerhalb des Orchard-Protokolls wird Halo 2 verwendet, um solche Transaktionen kryptografisch zu beweisen.
• Aleo nutzt zk-SNARKs für private und programmierbare Anwendungen. Programme können lokal ausgeführt werden, danach prüfen Validatoren den Beweis der korrekten Ausführung, ohne die privaten Eingaben oder Zwischenschritte sehen zu müssen.
• Mina nutzt rekursive zk-SNARKs, um die Gültigkeit des Blockchain-States kompakt zu beweisen. Das Hauptziel ist hier die kompakte Verifikation und nicht automatisch Transaktionsprivatsphäre.
• Scroll nutzt zk-SNARKs innerhalb seiner zkEVM, um die korrekte Verarbeitung von Transaktionsbatches zu beweisen. Diese Beweise können anschließend auf Ethereum geprüft werden.
• Ethereum unterstützt die Verifikation bestimmter pairing-basierter zk-SNARKs über Precompiles. Dadurch können Smart Contracts zk-SNARK-Beweise prüfen. Ethereum nutzt zk-SNARKs selbst nicht als allgemeines Konsensmechanismus.

Achte auf den Unterschied zwischen einem zk-SNARK und einem zk-STARK. Beide sind kryptografische Beweissysteme, die Zero-Knowledge unterstützen können, funktionieren technisch aber anders. zk-STARKs brauchen in der Regel kein Trusted Setup, liefern aber oft größere Beweise als zk-SNARKs. Ein ZK-Rollup muss deshalb nicht zwingend einen zk-SNARK verwenden.

Was ist ein Trusted Setup bei zk-SNARKs?

Ein Trusted Setup ist ein einmaliger Prozess, bei dem für einige zk-SNARKs öffentliche Parameter erstellt werden, die zum Erzeugen und Prüfen von Beweisen nötig sind. Diese Parameter werden oft als structured reference string (SRS) oder common reference string (CRS) bezeichnet.

Der sensible Teil ist die geheime zufällige Information, die während eines solchen Setups verwendet wird. Sie wird auch toxic waste genannt. Wenn jemand diese Information behält oder später rekonstruieren kann, kann das bei bestimmten Systemen, etwa Groth16, theoretisch missbraucht werden, um falsche Beweise zu erzeugen, die trotzdem als gültig akzeptiert werden.

Deshalb nutzen Projekte manchmal eine Multi-Party-Computation-Zeremonie. Dabei fügen mehrere Teilnehmer jeweils ihre eigene geheime Zufälligkeit hinzu. Solange mindestens ein Teilnehmer ehrlich handelt und seinen geheimen Beitrag tatsächlich vernichtet, kann die gesamte geheime Setup-Information nicht rekonstruiert werden.

Das senkt das Risiko deutlich, bedeutet aber immer noch, dass du darauf vertraust, dass mindestens ein Teilnehmer nicht kompromittiert wurde und seinen geheimen Beitrag wirklich gelöscht hat.

Nicht jeder zk-SNARK braucht ein Trusted Setup. Zcash verwendete für ältere Sprout- und Sapling-Circuits Groth16, wofür ein solches Trusted Setup nötig war. Das spätere Orchard-Protokoll nutzt Halo 2 und braucht kein Trusted Setup mit toxic waste.

Was sind die Vorteile von zk-SNARKs?

Der große Vorteil von zk-SNARKs ist, dass Privatsphäre und Prüfbarkeit zusammengehen können. Du kannst beweisen, dass du bestimmte Regeln einhältst, ohne die datenschutzrelevanten Daten hinter diesem Beweis offenzulegen.

Die wichtigsten Vorteile im Überblick:

• Privatsphäre mit Kontrolle: Sensible Daten können verborgen bleiben, während Nodes trotzdem prüfen können, ob eine Transaktion oder Berechnung gültig ist.
• Kurze Beweise: Die Beweise sind kompakt im Vergleich zu der Berechnung, die sie darstellen.
• Schnelle Verifikation: Ein Node oder Smart Contract muss die vollständige Berechnung nicht noch einmal ausführen.
• Öffentliche Kontrolle: Ein Beweis kann veröffentlicht und anschließend unabhängig geprüft werden.
• Viele Berechnungen zusammenfassen: Mit rekursiven Beweisen können mehrere Transaktionen, Batches oder frühere Beweise am Ende in einem kompakten neuen Beweis zusammengefasst werden.

Auf Ethereum können bestimmte pairing-basierte zk-SNARKs auch in Smart Contracts geprüft werden. Dadurch können Anwendungen zum Beispiel Beweise für Offchain-Berechnungen oder datenschutzorientierte Kontrollen auf Ethereum verifizieren lassen.

Wichtig ist aber: „kurz“ und „effizient“ sagen vor allem etwas über die Größe des Beweises und seine Verifikation aus. Für den Prover kann das Erstellen eines solchen Beweises im Gegenteil viel Rechenleistung und Speicher erfordern.

Was sind die Grenzen und Risiken von zk-SNARKs?

zk-SNARKs sind leistungsstark, aber keine Lösung für jedes Privatsphäre- oder Skalierbarkeitsproblem. Die Sicherheit hängt von der verwendeten Kryptografie, dem Circuit und der Art ab, wie das System in eine Blockchain oder Anwendung eingebunden ist.

Ein wichtiges Risiko bei Systemen, die von einem Trusted Setup abhängen, ist die geheime Setup-Information. Wenn die toxic waste aus einem Groth16-Setup etwa in falsche Hände gerät, können Angreifer möglicherweise falsche Beweise erzeugen, die trotzdem als gültig akzeptiert werden. Bei einem privaten Zahlungsmodell kann das im schlimmsten Fall dazu führen, dass Guthaben entsteht, das nach den normalen Regeln gar nicht hätte existieren dürfen.

Außerdem beweist ein zk-SNARK nur, dass die Regeln des Circuits eingehalten wurden. Fehler im Circuit, im Prover-Code, im Verifier-Code, in den verwendeten Parametern oder in der Anbindung an eine Blockchain können daher schwerwiegende Folgen haben. Ein kryptografisch korrekter Beweis hilft nicht, wenn die zugrunde liegenden Regeln falsch entworfen wurden.

Auch Privatsphäre hat Grenzen. Bei shielded Zcash-Transaktionen bleiben zum Beispiel Commitments und Nullifiers auf der Blockchain sichtbar, während die Informationen über die Notes verschlüsselt bleiben. Außerdem können öffentliche Daten, Timing, IP-Adressen und andere Netzwerkmetadaten manchmal trotzdem Informationen preisgeben oder Zusammenhänge sichtbar machen.

Bei zk-Rollups gibt es wiederum ein anderes Problem. Ein Validity Proof kann zeigen, dass ein Batch korrekt verarbeitet wurde, verhindert aber nicht automatisch, dass ein Operator Transaktionen verzögert oder Nutzer zensiert. Auch Risiken rund um Bridges und Datenverfügbarkeit bleiben bestehen.

Schließlich bedeutet Zero-Knowledge nicht automatisch, dass ein System gegen zukünftige Quantenangriffe resistent ist. Das hängt von der konkreten kryptografischen Konstruktion ab. Klassische pairing-basierte zk-SNARKs nutzen andere kryptografische Annahmen als zum Beispiel transparente STARK-Systeme.

Fazit

zk-SNARKs machen es möglich zu beweisen, dass eine Transaktion oder Berechnung korrekt ist, ohne die datenschutzrelevanten Daten dahinter preiszugeben. Dadurch sind sie interessant für private Zahlungen, datenschutzorientierte Anwendungen und Skalierbarkeit über Validity Rollups. Zcash ist eines der bekanntesten Beispiele für eine Blockchain, die zk-SNARKs nutzt, um shielded Transaktionen zu ermöglichen.

Der Kern ist relativ einfach: Eine Blockchain oder ein anderer Verifier muss nicht alle zugrunde liegenden Daten sehen oder die vollständige Berechnung noch einmal ausführen, solange er einen gültigen kryptografischen Beweis prüfen kann. Wie viel Privatsphäre und Sicherheit das am Ende bringt, hängt allerdings vom Design des Systems ab. Ein zk-SNARK ist letztlich nur so zuverlässig wie der Circuit, die verwendete Kryptografie und die Integration darum herum.