Zero-Knowledge-Beweise: Anwendungen auf Solana

Einführung

Dies ist der zweite Artikel einer Einführungsreihe zu Zero-Knowledge-Beweisen. Ich empfehle dir dringend, zuerst Zero-Knowledge-Beweise: Eine Einführung in die Grundlagen zu lesen. Der Artikel liefert den nötigen Kontext zu Theorie, Mathematik und Kryptografie, auf denen die folgende Analyse beruht. Dieser Artikel setzt dieses Wissen voraus. Falls du mit Zero-Knowledge-Beweisen noch nicht vertraut bist, solltest du daher zuerst den vorherigen Artikel lesen. Dieser Artikel soll dir das nötige Wissen vermitteln, damit du dich an der Diskussion über Zero-Knowledge-Beweise auf Solana beteiligen und sogar neue, innovative Zero-Knowledge-Primitives entwickeln kannst.

Mit diesem neuen Wissen können wir endlich fragen: Was sind Zero-Knowledge-Beweise? Wie werden sie auf Solana eingesetzt?

Was sind Zero-Knowledge-Beweise?

Da wir jetzt die nötige Theorie, Mathematik und Kryptografie kennen, stellt sich die Frage: Was genau ist ein Zero-Knowledge-Beweis?

Ein Zero-Knowledge-Beweis ist ein kryptografischer Prozess, bei dem eine Partei einer anderen beweisen kann, dass eine bestimmte Aussage wahr ist, ohne neben der Tatsache ihrer Gültigkeit weitere Informationen offenzulegen. Diese Beweise müssen statistisch korrekt, vollständig und vor Informationslecks geschützt sein.

Es gibt zwei Arten von Aussagen, die man mit Zero-Knowledge beweisen möchte. Auf hoher Ebene sind das:

• Aussagen über Fakten (z. B. besitzt dieser konkrete Graph eine Dreifärbung)
• Aussagen über Wissen (z. B. kenne ich die Faktorisierung von N)

Die erste Aussage betrifft letztlich eine intrinsische Eigenschaft des Universums – etwas, das grundsätzlich wahr ist, etwa 1 + 1 = 2. Die zweite Aussage wird als Wissensbeweis bezeichnet. Sie geht über den bloßen Beweis einer Wahrheit hinaus und hängt davon ab, was der Beweiser weiß.

Wie bereits erwähnt, können unsere Beweise interaktiv oder nicht interaktiv sein. Bei einem interaktiven Zero-Knowledge-Beweis durchlaufen Beweiser und Prüfer mehrere Runden, bis der Prüfer ohne vernünftigen Zweifel überzeugt ist. Zcash nutzt nicht interaktive Zero-Knowledge-Beweise, damit Nutzer anonyme Transaktionen ausführen können. 

Bei nicht interaktiven Zero-Knowledge-Beweisen wird der Beweis dagegen offline und ohne direkte Kommunikation zwischen Beweiser und Prüfer übermittelt. Der Beweiser erzeugt einen Beweis, der alle nötigen Informationen enthält. Der Prüfer kann ihn anschließend unabhängig und ohne weitere Interaktion verifizieren. Filecoin nutzt nicht interaktive Zero-Knowledge-Beweise, um zu beweisen, dass Nutzer Daten gespeichert haben, ohne die Daten selbst offenzulegen. 

 zk-SNARKs und Schaltkreise

Ein zk-SNARK ist ein Succinct Non-interactive ARgument of Knowledge. Diese Zero-Knowledge-Beweise sind besonders effizient und kompakt, also prägnant. Ein Beweis gilt als prägnant, wenn sowohl seine Größe als auch die zur Verifizierung benötigte Zeit langsamer wachsen als die zu verifizierende Berechnung. Für einen prägnanten Beweis darf der Prüfer also nicht für jede Hashing-Runde Arbeit leisten, da die Verifizierungszeit sonst proportional zur Berechnung wäre. Prägnante Beweise werden durch Polynome und die Fiat-Shamir-Heuristik ermöglicht.

Unabhängig von der Komplexität der zu beweisenden Aussage halten zk-SNARKs die Beweisgröße klein und ermöglichen eine relativ schnelle Verifizierung. Das macht zk-SNARKs für Rollups so attraktiv: Mit ihnen lässt sich beweisen, dass alle Transaktionen einer bestimmten L2 gültig sind, während der Beweis klein genug bleibt, um auf der L1 verifiziert zu werden. Protokolle wie Mina gehen noch einen Schritt weiter und nutzen rekursive Beweise. Dadurch können sie die gesamte Historie der Chain mit einem Beweis konstanter Größe verifizieren. Pickles ist Minas neues Beweissystem samt zugehörigem Toolkit und der erste eingesetzte zk-SNARK, der rekursive Komposition ohne Trusted Setup ermöglicht. Mit rekursiver Komposition meinen wir hier Schaltkreise.

Schaltkreise beschreiben die Berechnung, die du beweisen möchtest. Sie bestehen aus einer Folge mathematischer Operationen, die Eingaben verarbeiten und Ausgaben erzeugen. In Zero-Knowledge-Beweisen stellen Schaltkreise korrekt ausgeführte Berechnungen dar, ohne deren Eingaben offenzulegen. Der allgemeine Ablauf sieht so aus:

• Schaltkreis schreiben und kompilieren — Wir müssen den Schaltkreis schreiben und kompilieren. Das kann so einfach sein wie ein arithmetischer Schaltkreis über einem durch die Primzahl p = 7 definierten endlichen Körper mit der Berechnung x * y = z. Grundsätzlich stellen wir eine zu beweisende Berechnung als Menge von Bedingungen zwischen Variablen dar, reduzieren diese Bedingungen auf Polynomgleichungen und schreiben Code, der alle Werte auf ein neues algebraisches Gebilde abbildet (also einen Homomorphismus). Bei der Kompilierung entstehen mehrere Artefakte, darunter die vom Schaltkreis definierten Bedingungen sowie ein Skript oder Binärprogramm für die folgenden Schritte
• Trusted-Setup-Zeremonie — Je nach Art des zk-SNARK kann eine Zeremonie nötig sein, um die Beweis- und Verifizierungsschlüssel zu erzeugen
• Schaltkreis ausführen — Ein Schaltkreis muss mit dem bei der Kompilierung erzeugten Skript oder Binärprogramm wie ein Programm ausgeführt werden. Der Nutzer gibt die öffentlichen und privaten Eingaben ein. Anschließend werden die Werte aller Zwischen- und Ausgabevariablen berechnet. Der Witness, auch Trace genannt, zeichnet sämtliche Berechnungsschritte auf
• Beweis erzeugen — Mit dem Beweisschlüssel aus dem zweiten und dem Witness aus dem dritten Schritt kann der Beweiser einen Zero-Knowledge-Beweis erzeugen. Dieser bestätigt, dass alle im Schaltkreis definierten Bedingungen erfüllt sind, legt aber nur den Ausgabewert offen. Der Beweis wird an den Prüfer gesendet
• Beweis verifizieren — Der Prüfer verifiziert anhand des eingereichten Beweises und des Verifizierungsschlüssels, dass der Beweis für seine öffentliche Ausgabe korrekt ist

Bestimmte Arten von zk-SNARKs wie Groth16 benötigen für jeden Schaltkreis ein Trusted Setup. Das kann hinderlich sein, weil du für jedes neue Programm eine neue Zeremonie durchführen musst. Andere zk-SNARKs wie PlonK benötigen nur ein universelles Trusted Setup und vereinfachen damit den gesamten Prozess. Wieder andere Arten von Zero-Knowledge-Beweisen wie zk-STARKs kommen ganz ohne Trusted Setup aus.

zk-STARKs

Ein zk-STARK ist ein Scalable Transparent ARgument of Knowledge. zk-STARKs wurden von StarkWare erfunden und erstmals in diesem Paper von 2018 als Alternative zu zk-SNARKs vorgeschlagen. Im Wesentlichen ermöglichen sie Blockchains, Berechnungen an einen einzelnen Off-Chain-STARK-Beweiser auszulagern und deren Integrität mit einem On-Chain-STARK-Prüfer zu verifizieren. 

zk-STARKs gelten als Zero-Knowledge, weil die Eingaben des Off-Chain-Beweisers nicht gegenüber der Blockchain offengelegt werden. So bleibt die Privatsphäre des Nutzers gewahrt. zk-STARKs sind skalierbar, weil das Auslagern von Berechnungen die Verifizierungskosten auf L1 deutlich reduziert. Ihre Beweise skalieren außerdem linear, während zk-SNARKs nur quasilinear skalieren. Darüber hinaus benötigen zk-STARKs keine aufwendigen Trusted-Setup-Zeremonien. Deren Befürworter argumentieren, solche Zeremonien seien anfällig für toxischen Abfall: ungültige Beweise, die Prüfer akzeptieren könnten, wenn die Zeremonie nicht korrekt durchgeführt wurde. Stattdessen verwenden zk-STARKs öffentlich verifizierbare Zufallswerte, um Interaktionen zwischen Beweisern und Prüfern einzurichten. Diese Beweise kann nur ein Off-Chain-Beweiser erzeugen, der die Berechnung tatsächlich ausgeführt hat und über die dafür nötigen Hilfseingaben verfügt.

zk-STARKs beheben die Einschränkungen von zk-SNARKs durch skalierbare, transparente Wissensargumente. Sie beruhen außerdem auf deutlich einfacheren kryptografischen Annahmen und vermeiden Elemente wie elliptische Kurven vollständig. Stattdessen basieren sie ausschließlich auf Hashes und Informationstheorie, wodurch sie quantenresistent sind. Die Beweise sind allerdings mehrere hundert Kilobyte groß. Das kann ihren Einsatz in Umgebungen mit begrenzter Bandbreite oder Speicherkapazität wie Blockchains erschweren. Einige komplexere Beweis-Setups und zkVMs kombinieren rekursiv bewiesene zk-STARKs mit einem zk-SNARK, der nur für den letzten Verifizierungsschritt verwendet wird.

ZK Compression

Das Problem des Zustandswachstums

Eines der drängendsten Probleme von Solana ist das Zustandswachstum. Zum Kontext: Der Zustand von Solana wird auf den Laufwerken vollständiger Nodes in der Accounts DB gespeichert. Dabei handelt es sich um einen Key-Value-Store, in dem jeder Datenbankeintrag als Account bezeichnet wird. Accounts haben jeweils 32 Byte lange Adressen und können zwischen 0 und 10 MB Daten speichern. Derzeit kostet das Speichern von 10 MB Daten etwa 70 SOL. Dabei spielt es keine Rolle, ob sie auf einen Account mit 10 MB oder tausend Accounts mit je 10 KB verteilt sind. Jeden Tag werden etwa eine Million neue Accounts zur Chain hinzugefügt. Laut Tolys Beitrag zum Zustandswachstum steigt die Gesamtzahl damit auf über 500 Millionen Accounts. Das Wachstum von Solana bringt mehrere Herausforderungen mit sich: unbegrenzte Snapshot-Größen, Einschränkungen der PCI-Bandbreite, Account-Indexierung sowie eine kostspielige Verwaltung von Arbeitsspeicher und Laufwerken. 

Der aktuelle vollständige Snapshot ist etwa 70 GB groß und mit heutiger Hardware handhabbar. Kontinuierliches Wachstum führt jedoch zwangsläufig zu einer ineffizienten Zustandsverwaltung und möglichen Engpässen. Mit zunehmender Snapshot-Größe dauert der Kaltstart eines neuen Systems nach einem Hardwareausfall deutlich länger. Bei einem Neustart des Netzwerks könnte das schädlich sein. 

Die Bandbreite von Peripheral Component Interconnect (PCI) bezeichnet die Datenübertragungsrate zwischen CPU und Peripheriegeräten wie Grafik-, Netzwerk- und Speichergeräten. PCI Express (PCIe) ist ein Hochgeschwindigkeits-Schnittstellenstandard, der den älteren PCI-Standard ersetzen und höhere Datenübertragungsraten ermöglichen soll. Die neueste PCI-Generation erreicht Geschwindigkeiten von 1 TB oder 128 GB/s. Das klingt viel, ist es im Kontext von Solana aber nicht. Wenn eine Transaktion 128 MB liest oder schreibt, würde eine PCI-Bandbreite von 128 GB/s Solana auf 1000 Transaktionen pro Sekunde (TPS) begrenzen. Die meisten Transaktionen greifen jedoch auf kürzlich verwendeten Speicher zu, der bereits in den RAM eines Validators geladen und dort zwischengespeichert wurde. Dennoch ist eine effiziente Zustandsverwaltung entscheidend, um beim Skalieren von Solana einen hohen Durchsatz aufrechtzuerhalten. Andernfalls kann diese Bandbreite schnell zum begrenzenden Faktor werden.

Jeder Validator muss einen Index aller vorhandenen Accounts führen. Das ist nötig, weil beim Erstellen eines neuen Accounts bewiesen werden muss, dass dieser noch nicht existiert. Bei einem Gesamtzustand von über 500 Millionen Accounts würde selbst ein minimaler Index – also ein 32-Byte-Schlüssel und ein 32-Byte-Datenhash pro Eintrag – rund 32 GB RAM benötigen. Diese Zustandsspeicherung ist teuer und muss sorgfältig verwaltet werden, um Leistungseinbußen zu verhindern. Mit dem weiteren Wachstum des Solana-Zustands wird die Unterscheidung zwischen schnellem, teurem Speicher wie RAM für bestimmte Vorgänge und langsamerem, günstigerem Speicher wie Laufwerken entscheidend.

Transaktionen und Zustandswachstum

Jede Solana-Transaktion muss alle Accounts angeben, die sie liest oder beschreibt. Transaktionen sind derzeit auf 1232 Byte begrenzt und müssen Folgendes enthalten:

• Header (3 Byte)
• Signaturen (je 64 Byte)
• Account-Adressen (je 32 Byte)
• Anweisungsdaten (beliebige Größe)
• Aktueller Blockhash (32 Byte)

Bei der Ausführung einer Transaktion geschieht Folgendes:

• Plausibilitätsprüfungen — Nur aktuelle Transaktionen sind gültig. Außerdem werden Deduplizierung, Struktur, Gebühren und Signaturen der Transaktion geprüft
• Programmladen — Der Programm-Bytecode wird anhand der Programmadresse geladen und die Solana Virtual Machine (SVM) wird instanziiert
• Account-Laden — Alle von der Transaktion referenzierten Accounts werden geprüft, aus dem Speicher in den Arbeitsspeicher geladen und an die SVM übergeben
• Ausführung — Der Programm-Bytecode wird ausgeführt
• Synchronisierung — Alle geänderten Accounts werden zurück in den Speicher synchronisiert

Dieser Lebenszyklus bringt mit wachsendem Zustand mehrere Herausforderungen mit sich. On-Chain-Zustand ist teuer und mehr auf Laufwerken gespeicherte Accounts führen zu größeren Snapshots und Indizes. Außerdem wird nicht auf alle Accounts häufig zugegriffen. Laufende Ressourcenkosten für sie sind daher ineffizient.

Zustandsverwaltung mit ZK Compression vereinfachen

Anstatt alle Accounts auf Laufwerken zu speichern und bei Bedarf zu lesen, kann eine Transaktion die Account-Daten als Teil ihrer Payload übergeben. Mit Merkle-Bäumen können wir sicherstellen, dass Nutzer beim Einreichen von Transaktionen den korrekten Zustand angeben. Merkle-Beweise ermöglichen eine verbindliche Festlegung auf bestimmte Daten. Die Beweise lassen sich anhand dieser Festlegung verifizieren. So kann geprüft werden, ob der richtige Zustand übergeben wurde und der Nutzer keine falschen Angaben macht. 

Diese Beweise sind zwar sicher, können aber ziemlich groß sein. Enthält ein Baum beispielsweise 100.000 Accounts, wäre der Beweis 544 Byte groß. Beweise für mehrere Accounts könnten das Transaktionslimit von 1232 Byte schnell überschreiten. Glücklicherweise lässt sich das mit effizienteren Beweissystemen umgehen. Festlegungen mit konstanter Beweisgröße wie KZG- oder Pedersen-Commitments würden den Beweis verkleinern. Damit ließen sich Beweise leichter innerhalb des Transaktionslimits unterbringen.

ZK Compression ist schlicht ein Mechanismus, der das Problem der Merkle-Beweisgröße löst. Mithilfe des Ledgers von Solana lässt sich beweisen, dass eine Berechnung korrekt ausgeführt wurde, ohne die damit verbundenen Kosten für On-Chain-Speicher zu tragen.

Was ist ZK Compression?

ZK Compression ist ein neues Primitive, mit dem Entwickler On-Chain-Zustand komprimieren können. Dadurch sinken die Zustandskosten um Größenordnungen, während Sicherheit, Leistung und Komponierbarkeit erhalten bleiben. Das Erstellen von 100 Token-Accounts würde derzeit beispielsweise ~0,2 SOL kosten. Mit ZK Compression sinken die Kosten um den Faktor 5000 auf ~0,00004. 

ZK Compression nutzt Zero-Knowledge-Beweise, um Zustandsübergänge zu validieren, ohne die zugrunde liegenden Daten offenzulegen. Dazu gruppiert es mehrere Accounts in einer einzigen verifizierbaren Merkle-Wurzel, die On-Chain gespeichert wird, während die zugrunde liegenden Daten im Ledger liegen. Gültigkeitsbeweise sind prägnante Zero-Knowledge-Beweise. Sie weisen die Existenz von n Accounts als Blätter in m Zustandsbäumen nach und behalten dabei eine konstante Beweisgröße von 128 Byte bei. Diese Beweise werden Off-Chain erzeugt und On-Chain verifiziert. Das reduziert die gesamte Rechenlast auf Solana. ZK Compression verwendet Groth16, einen bekannten paarungsbasierten zk-SNARK, als Beweissystem.

Diese Accounts sind jedoch keine regulären Solana-Accounts. Stattdessen handelt es sich um komprimierte Accounts.

Modell für komprimierte Accounts

Der mit ZK komprimierte Zustand wird in komprimierten Accounts gespeichert. Diese ähneln regulären Solana-Accounts, unterscheiden sich aber in mehreren wichtigen Punkten, die Effizienz und Skalierbarkeit erhöhen:

• Identifizierung per Hash — Jeder komprimierte Account lässt sich anhand seines Hashes identifizieren
• Hash-Änderung beim Schreiben — Jeder Schreibvorgang in einen komprimierten Account ändert dessen Hash
• Optionale Adresse — Optional kann eine Adresse als permanente eindeutige ID des komprimierten Accounts festgelegt werden. Das ist für bestimmte Anwendungsfälle wie NFTs nützlich. Das Feld ist optional, um Rechenaufwand zu vermeiden, da komprimierte Accounts über ihren Hash referenziert werden können
• Spärliche Zustandsbäume — Alle komprimierten Accounts werden in Merkle-Bäumen gespeichert. Nur die Zustandswurzel des Baums, also die Merkle-Wurzel, wird im On-Chain-Account-Bereich abgelegt. Genauer gesagt ist ein Zustandsbaum ein nebenläufiger, auf Poseidon-Hashes basierender Merkle-Baum

Komprimierte Program-Derived Addresses (PDAs) lassen sich anhand ihrer eindeutigen, dauerhaften Adresse identifizieren. Ihr Aufbau ähnelt regulären PDA-Accounts und enthält die Felder Data, Lamports, Owner und Address. Anders als bei regulären PDAs enthält das Feld Data jedoch die AccountData-Struktur mit den Feldern Discriminator, Data und DataHash.

Nodes

Verschiedene Arten von Nodes erfüllen wichtige Aufgaben bei der Unterstützung von ZK Compression. Jeder kann eine Photon RPC-Node, eine Beweiser-Node oder eine Light Forester-Node betreiben, um sich mit Devnet und Mainnet-Beta zu verbinden. Für die lokale Entwicklung startet der Befehl test-validator der ZK Compression CLI einen Solana-Cluster mit einer einzelnen Node. Er enthält alle relevanten Nodes, also Photon RPC und Beweiser, sowie Systemprogramme, Accounts und Laufzeitfunktionen.

Photon RPC-Nodes indexieren die Komprimierungsprogramme. Dadurch können Clients Transaktionen lesen und erstellen, die mit komprimiertem Zustand interagieren. Der kanonische Komprimierungsindexer heißt Photon und wird von Helius bereitgestellt. Dieser Node-Typ lässt sich mit minimalem Einrichtungsaufwand lokal betreiben und muss auf ein bestehendes RPC verweisen. 

Beweiser-Nodes erzeugen Gültigkeitsbeweise für die Aufnahme in den Zustand. Über den Endpunkt getValidityProof der ZK Compression RPC API-Spezifikation lassen sich Beweise abrufen. Beweiser-Nodes können eigenständig oder zusammen mit einem anderen RPC betrieben werden. Die kanonische Photon RPC-Implementierung enthält bereits eine Beweiser-Node.

Light Forester-Nodes verwalten die Erstellung, Rotation und Aktualisierung gemeinsam genutzter und programmeigener Zustandsbäume. Das richtet sich an Entwickler, die ihre programmeigenen Zustandsbäume von einem Netzwerk aus Light Forester-Nodes verwalten lassen möchten.

Vertrauensannahmen

Jeder kann eine der genannten Nodes betreiben, die zur Beweiserzeugung nötigen Rohdaten speichern und Transaktionen einreichen. Dadurch entsteht eine Vertrauensannahme, die die Verfügbarkeit des komprimierten Zustands betrifft. Gehen die Daten verloren oder treffen sie verspätet ein, können keine Transaktionen eingereicht werden, sofern man die Daten nicht selbst speichert. Da nur eine ehrliche Node die Daten bereitstellen muss und die Beweise eigenständig verifizierbar sind, betrifft das Problem eher Verfügbarkeit und mögliche Zensur als Sicherheit.

Eine weitere Vertrauensannahme entsteht dadurch, dass das Programm zur Verifizierung komprimierter Accounts derzeit aktualisierbar ist. So kann es geändert werden, um Probleme zu beheben oder neue Anforderungen zu erfüllen. Sobald es einen stabilen und sicheren Zustand erreicht, kann es künftig jedoch unveränderlich gemacht oder eingefroren werden.

Eine weitere Vertrauensannahme zur Verfügbarkeit betrifft Forester-Nodes. Diese Nodes sorgen für die Fortschreibung der Zustandswurzeln und verwalten Nullifier-Warteschlangen, indem sie diese leeren und die Zustandswurzeln asynchron fortschreiben. Dabei werden Account-Hashes durch Nullen ersetzt, um sie zu annullieren. Die Trennung von Fortschreibung und Annullierung ermöglicht sofortige Finalität für Übergänge des komprimierten Zustands, während die Transaktionen innerhalb der Größenbeschränkungen von Solana bleiben. Da Nullifier-Warteschlangen eine konstante Größe haben, sind Forester-Nodes für die Verfügbarkeit des Protokolls unverzichtbar. Eine volle Warteschlange würde einen Verfügbarkeitsausfall des zugehörigen Zustandsbaums verursachen. Forester-Nodes verhindern das, indem sie die Warteschlangen leeren. Allerdings müssen weiterhin Menschen diese Nodes betreiben, um Integrität und Verfügbarkeit des Protokolls zu sichern. Ohne diese Nodes könnte ZK Compression nur etwa zweitausend Accounts beziehungsweise Adressen unterstützen.

Einschränkungen 

Selbst wenn nichts verborgen werden muss, verwandeln Zero-Knowledge-Beweise Probleme mit mehreren Rechenschritten in ein Problem, bei dem nur ein einziger Beweis verifiziert werden muss, um die korrekte Ausführung der Berechnungen zu bestätigen. Diese Berechnungen müssen nicht nur prüfen, ob ein bestimmtes Blatt zu einem bestimmten Baum gehört. Es kann sich um beliebige Berechnungen handeln. Das hat jedoch seinen Preis.

Bevor du ZK Compression verwendest, solltest du Folgendes berücksichtigen:

• Größere Transaktionen — ZK Compression benötigt 128 Byte für den Gültigkeitsbeweis. Hinzu kommen die Daten, die zum Lesen oder Schreiben On-Chain gesendet werden
• Höherer Verbrauch von Compute Units — ZK Compression erhöht den Verbrauch von Compute Units (CU) deutlich. Die Verifizierung des Gültigkeitsbeweises benötigt ~100.000 CUs, das System ~100.000 CUs und jeder Lese- oder Schreibzugriff auf einen komprimierten Account ~6.000 CUs
• Zustandskosten pro Transaktion — Jeder Schreibvorgang verursacht geringe Netzwerkkosten, weil er den vorherigen Zustand des komprimierten Accounts annullieren und den neuen komprimierten Zustand an den Zustandsbaum anhängen muss. Daher können die Lebenszeitkosten eines einzelnen komprimierten Accounts die seines unkomprimierten Pendants übersteigen, wenn viele Zustandsaktualisierungen nötig sind

Ein regulärer Account kann besser geeignet sein, wenn:

• Der Account häufig aktualisiert wird
• Die Gesamtzahl der Schreibvorgänge während der Lebensdauer des Accounts hoch sein wird (also >1000x)
• Der Account große Datenmengen speichert, auf die in On-Chain-Transaktionen zugegriffen werden muss

Vorteile

ZK Compression ist ein skalierbares, sicheres, effizientes und flexibles Primitive. Es begegnet direkt dem Zustandswachstum von Solana und unterstützt viele Anwendungen und Anwendungsfälle. Der wohl auffälligste Vorteil ist die Senkung der Zustandskosten. Mit ZK Compression können Apps problemlos auf Millionen von Nutzern skalieren. Der Zustand wird sicher im günstigeren Ledger-Bereich gespeichert, während Zustands-Fingerprints den On-Chain-Speicherbedarf minimieren. Nehmen wir als Beispiel die Prägung von 10.000 Token-Accounts bei einem SOL-Preis von 130 US-Dollar. Das würde etwa 2.600 US-Dollar kosten. ZK Compression senkt die Kosten auf weniger als fünfzig Cent.

ZK Compression passt außerdem gut zu den aktuellen Solana-Spezifikationen. Die Struktur komprimierter Accounts ist beispielsweise nahezu identisch mit der regulärer Solana-Accounts. Auch Solana-spezifische Innovationen wie Parallelität werden unterstützt. Zwei Transaktionen unter demselben Zustandsbaum, also derselben Festlegung, können parallel ausgeführt werden, wenn sie auf unterschiedliche komprimierte Accounts zugreifen. Darüber hinaus stärkt ZK Compression die synchrone atomare Komponierbarkeit. Eine Transaktion, die n komprimierte und m reguläre Accounts aufführt, ist beispielsweise vollständig gültig. Eine Anweisung, die einen komprimierten Account referenziert, kann eine andere Anweisung oder ein anderes Programm aufrufen, das einen regulären Account referenziert. Das gilt auch dann, wenn die Accounts unter verschiedenen Zustandsbäumen komprimiert wurden. Schlägt eine Anweisung fehl, wird die gesamte Transaktion zurückgesetzt. Änderungen sind von einer Anweisung zur nächsten sichtbar. Das unterscheidet sich von ZK-Rollups, die einander nur dann synchron oder atomar aufrufen können, wenn sie Sperren verwenden. Daher liegt ein Vergleich zwischen ZK Compression und Rollups nahe.

ZK Compression ist kein Rollup

ZK Compression ist kein Rollup. Beide beruhen zwar auf derselben Technologie, ihre Implementierungen unterscheiden sich jedoch. Es gibt zwei Arten von Rollups:

• Optimistic Rollups — Alle Transaktionen gelten für einen bestimmten Zeitraum als gültig. Betrugsbeweise weisen innerhalb dieses Zeitraums falsche Transaktionen nach
• Zero-Knowledge-Rollups — Gültigkeitsbeweise weisen sofort nach, ob Transaktionen gültig oder ungültig sind

Der gesamte Zustand eines Zero-Knowledge-Rollups wird auf der Basisschicht, also Ethereum, als einzelne Wurzel dargestellt. Das hat zu zahlreichen Behauptungen geführt, ZK Compression sei tatsächlich ein Rollup. Es gibt jedoch mehrere entscheidende Unterschiede.

Betrachten wir ein Szenario mit 500 Transaktionen auf einem ZK-Rollup. Das gesamte Rollup wird dabei als ein einziger Schaltkreis behandelt. Alle 500 Transaktionen werden gemeinsam verifiziert. Daraus entsteht ein einziger Beweis, der bestätigt, dass sich die Zustandswurzel von A zu B geändert hat. Nach der Verifizierung dieses Beweises aktualisiert der Smart Contract, der die Interaktionen zwischen L1 und L2 verwaltet, die Zustandswurzel entsprechend. Bei ZK Compression hingegen erzeugt jede der 500 Transaktionen einen eigenen Beweis, der die Korrektheit der Account-Daten bestätigt. Die SVM selbst führt diese Transaktionen aus. Nach der Validierung jedes Beweises werden die Accounts wie „reguläre“ Accounts behandelt.

Würden wir ZK Compression als Rollup klassifizieren, könnte jede auf Solana gespeicherte Merkle-Wurzel als gültigkeitsbasiertes Rollup gelten. Betrachten wir alle derzeit auf Solana vorhandenen komprimierten cNFT-Wurzeln, gibt es etwa 4.000 bis 5.000 gültigkeitsbasierte Rollups – abhängig davon, ob wir Merkle-Bäume ohne Prägungen mitzählen.

Damit wird deutlich, dass ZK Compression eine einzigartige, auf die Architektur von Solana zugeschnittene Lösung ist. Es handelt sich um ein neuartiges Primitive, das sich von ZK-Rollups unterscheidet. Es erhöht Skalierbarkeit und Effizienz ohne die Komplexität und Abtrennung von Rollups.

Die Zukunft von ZK auf Solana und Interoperabilität

Der aktuelle Stand von ZK auf Solana

Eine meiner ersten Schreibaufgaben bei Helius war ein Artikel über Solanas Update v1.16. Die bessere Laufzeitunterstützung für Zero-Knowledge-Beweise hat mich sehr begeistert, weshalb ich sie im Artikel behandelte. Diese Verbesserungen wurden jedoch verschoben. Ich machte den Fehler, sie im Artikel zum Update v1.17 erneut und ausführlicher zu behandeln – nur damit sie wieder verschoben wurden. Im Artikel zum Update v1.18 erwähnte ich sie gar nicht mehr. Natürlich war ich enttäuscht, und andere äußerten ebenfalls ihren Frust. 

Trotz dieser Stimmung entsteht auf Solana eine noch kleine, aber wachsende Community von ZK-Entwicklern. Bevor sich Light Protocol auf ZK Compression konzentrierte, lag der Fokus zunächst auf der privaten Programmausführung in Form von PSPs (Private Solana Programs). Dark Protocol ist ebenfalls ein auf Solana aufbauendes futarchisches Datenschutzprotokoll. Es hat kein zentrales Team. Beiträge erfolgen über Vorschläge. Arcium, früher als Elusiv bekannt, nutzt Multiparty computation eXecution Environments (MXEs) für ein eigenes parallelisiertes Netzwerk für vertrauliche Berechnungen. Bonsol ist ein Zero-Knowledge-„Co-Prozessor“, mit dem Entwickler jedes risc0-Image ausführen und auf Solana verifizieren können, also verifizierbare Off-Chain-Berechnungen. Auch Tutorials und Listen mit Links zu Zero-Knowledge-Beweisen wurden verbreitet.

Besonders hervorzuheben ist das ZK Token Proof Program. Es verifiziert mehrere Zero-Knowledge-Beweise, die für die Zusammenarbeit mit Pedersen-Commitments und Twisted-ElGamal-Verschlüsselung über curve25519 optimiert sind. Es ermöglicht vertrauliche Übertragungen, die Zero-Knowledge-Beweise verwenden, um Guthaben und Transaktionsbeträge von SPL-Tokens zu verschlüsseln. Ziel ist Vertraulichkeit, nicht Anonymität. Mit homomorpher Verschlüsselung lassen sich Berechnungen auf verschlüsselten Daten ausführen, ohne sie zu entschlüsseln. Dazu nutzen vertrauliche Übertragungen die Twisted-ElGamal-Verschlüsselung für verborgene mathematische Operationen auf dem Geheimtext und Sigma-Protokolle, um die Übertragungen zu validieren, ohne sensible Informationen offenzulegen. Nur der Account-Inhaber mit dem Entschlüsselungsschlüssel kann sein verschlüsseltes Guthaben sehen. Das globale Prüfersystem ermöglicht jedoch über separate Entschlüsselungsschlüssel selektiven Lesezugriff für Compliance und Prüfungen. 

Das ZK Token Proof Program ist derzeit aufgrund der Annahme von SIMD-0153: ZK ElGamal Proof Program eine blockierte Funktion. Diese neue SIMD soll das bestehende, speziell für das SPL Token Program entwickelte ZK Token Proof Program ablösen. An seine Stelle soll ein allgemeineres Zero-Knowledge-Beweisprogramm treten, das von konkreten Anwendungen unabhängig ist. Die SIMD wurde mit Unterstützung von Anza und dem Firedancer-Team zusammengeführt.

Doch der Wind beginnt sich zu drehen. Solana entwickelt sich zu einem ZK-Schwergewicht, da diese Verbesserungen endlich Devnet und Mainnet-Beta erreichen. Auf Solana sind jetzt drei ZK-Systemaufrufe live.

Poseidon-Systemaufrufe

Poseidon ist eine speziell für Zero-Knowledge-Beweise entwickelte Familie von Hashfunktionen. Sie wird in Projekten wie Zcash, Mina und Light Protocol eingesetzt. Für Zero-Knowledge-Beweise ist Poseidon recheneffizienter als herkömmliche, allgemeine Hashfunktionen wie SHA-256. 

Poseidon-Hashfunktionen eignen sich gut für Zero-Knowledge, weil sie:

• Arithmetische Operationen effizient ausführen
• Aufgrund ihres für Arithmetik optimierten Designs, ihrer optimierten S-Box und der geringen Rundenzahl weniger Schritte zur Beweiserzeugung benötigen, also eine geringere Schaltkreiskomplexität haben
• Algorithmen verwenden, die Bitfolgen beliebiger Länge verarbeiten und dadurch äußerst vielseitig sind

Früher war es zu teuer, Poseidon-Hashes in einer einzigen Transaktion zu berechnen. Das ändert sich mit Epoche 644 und der Aktivierung des Poseidon-Systemaufrufs. Dieser Systemaufruf übernimmt als Eingabe einen zweidimensionalen Byte-Slice und berechnet daraus den entsprechenden Poseidon-Hash. Das ist spannend, weil ZK Compression für seine Zustandsbäume auf Poseidon-Hashing angewiesen ist.

Der Poseidon-Systemaufruf berechnet Hashes mithilfe der BN254-Kurve und den folgenden Parametern:

• S-Boxen — x5-Substitutionsboxen
• Eingaben — 1 ≤ n ≤ 12
• Breite — 2 ≤ t ≤ 13
• Runden — 8 vollständige Runden und von t abhängige Teilrunden: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Die Ausgabe ist das als 32 Byte in der angegebenen Byte-Reihenfolge codierte Poseidon-Hash-Ergebnis.

Die hier für den Systemaufruf verwendete Variante ist Poseidon mit einer x5-S-Box und auf die BN254-Kurve abgestimmten Parametern. Das Crate light-poseidon erleichtert die Berechnung dieser Hashes. Das Crate selbst wurde geprüft und ist mit Circom kompatibel.

alt_bn128-Systemaufrufe

alt_bn128 bezeichnet die Implementierung der elliptischen Barreto-Naehrig-Kurve (BN-128). Diese paarungsfreundliche Kurve ermöglicht effiziente zk-SNARK-Beweise und -Berechnungen. Sie ist für verschiedene Zero-Knowledge-Beweissysteme entscheidend, darunter Groth16, auf das ZK Compression zur Validierung von Zustandsübergängen setzt. Dieser Systemaufruf reduziert den benötigten Speicherplatz pro Beweis erheblich und optimiert damit Platz und Zeit für effiziente On-Chain-Beweise. 

Die sol_alt_bn128_group_op-Systemaufrufe berechnen Operationen auf der alt_bn128-Kurve. Dazu gehören Punktaddition in G1 – mit G1 meinen wir einfach eine Gruppe von Punkten auf einer bestimmten elliptischen Kurve –, Skalarmultiplikation in G1 und Paarung:

• Eingaben — Serialisierte Punkte und Skalare im Big-Endian-Format
• Operationen — Punktaddition in G1, Skalarmultiplikation in G1, Paarung (1 Punkt in G1 und 1 Punkt in G2)
• Ausgaben — Punkte in G1 oder als 256-Bit-Ganzzahl serialisierte Paarungsergebnisse

Die sol_alt_bn128_compression-Systemaufrufe komprimieren oder dekomprimieren Punkte in G1- oder G2-Gruppen auf der alt_bn128-Kurve und geben die Punkte im standardmäßigen Big-Endian-Format zurück.

Diese Systemaufrufe sind derzeit im Testnet live und werden offenbar im Devnet verfügbar, sobald die Fehler in der Neukompilierungsphase geladener Programme behoben sind. Das geschieht gemäß SIMD-0075: Secp256r1 Precompile. Der Vorschlag soll die Fehlercodes für alt_bn128-Systemaufrufe und den Poseidon-Systemaufruf vereinheitlichen. Das gewährleistet Konsistenz und senkt das Risiko von Konsensfehlern durch unterschiedliche Fehlercodes, die Validatoren zurückgeben.

Die alt_bn128-Systemaufrufe lassen sich für reguläre Vektor-Commitments mit konstanter Beweisgröße verwenden, etwa KZG-Commitments. Daher funktionieren sie mit jeder paarungsfreundlichen Kurve und benötigen keinen ZK-Beweiser-Schaltkreis. 

Interoperabilität

Solana ist eine ZK-Chain. Es ist eine leistungsstarke Layer-1-Blockchain mit niedrigen Gebühren und Laufzeitunterstützung für Operationen auf elliptischen Kurven. Die Implementierung und Unterstützung von Systemaufrufen für Zero-Knowledge-Beweise fördert Innovationen. So können neue Primitives und Anwendungen wie ZK Compression auf Solana entstehen.

Die Einführung der alt_bn128-Systemaufrufe verkleinert die Komponierbarkeitslücke zwischen Solana und Solidity-basierten Contracts. Diese nutzen vorkompilierte Contracts für Operationen auf elliptischen Kurven, die in EIP-196, EIP-197 und EIP-198 definiert sind. Diese Operationen ermöglichen die Verifizierung von zk-SNARK-Beweisen innerhalb der Gaslimits von Ethereum. Solidity-Contracts, die auf diesen Operationen auf elliptischen Kurven beruhen, können daher leichter zu Solana wechseln oder sogar mit Solana interagieren.

SIMD-0075 ist für Interoperabilitätslösungen entscheidend. Nach der vollständigen Implementierung können Projekte wie das kommende blobsream-solana, das DA von Celestia zu Solana streamt, Beweise Off-Chain erzeugen und On-Chain verifizieren, um Merkle-Commitments zu speichern. Ohne diese Systemaufrufe wäre eine Verifizierung der Groth16-Beweise auf Solana nicht möglich. Darüber hinaus verbessern diese Systemaufrufe vertrauensminimierte Bridges und die Interoperabilität. Andere Blockchains können dadurch nahtlos und sicher mit Solana interagieren.  

Toly hat recht: Mit all diesen Verbesserungen an der Solana-Laufzeit ist Solana eine Ethereum-L2. Bald hindert dich nichts mehr daran, alle Solana-Blöcke an einen datenvalidierenden Bridge-Contract auf Ethereum zu übermitteln. Umgekehrt hindert dich nichts daran, alle Ethereum-Blöcke an ein datenvalidierendes Bridge-Programm auf Solana zu übermitteln. Bidirektionale Interoperabilität, beschleunigt durch Zero-Knowledge-Beweise statt veralteter Bridges, eröffnet Solana eine vielversprechende Zukunft.

Fazit

Zero-Knowledge-Beweise gehören zweifellos zu den leistungsstärksten Primitives, die Kryptografen je entwickelt haben – wenn sie nicht sogar das leistungsstärkste sind. Das wird offensichtlich, wenn man wie im ersten Artikel von den Grundprinzipien ausgeht und die zugrunde liegende Theorie, Mathematik und Kryptografie untersucht. Die möglichen Anwendungen sind grenzenlos: von echtem Fog of War für On-Chain-Spiele bis zum Beweis, dass eine Reihe von Transaktionen auf einer L2 zu einem bestimmten Zustandsübergang geführt hat.

Diese zweiteilige Reihe hätte problemlos weitere fünfzig Seiten umfassen können. Wir hätten die Feinheiten homomorpher Verschlüsselung behandeln, Schaltkreise in Circom programmieren und verschiedene Commitment-Verfahren analysieren können. Ziel dieser Artikel ist jedoch, dir die Grundlagen von Zero-Knowledge-Beweisen zu vermitteln, damit du dein neues Wissen jetzt auf Solana anwenden kannst. 

Solana entwickelt sich zu einem ZK-Schwergewicht. Von der Veröffentlichung von ZK Compression bis zu den verschiedenen Systemaufrufen, die in naher Zukunft live gehen: Ihre Bedeutung lässt sich kaum überschätzen. Primitives wie ZK Compression abstrahieren zwar für durchschnittliche Entwickler die gesamte Komplexität von Zero-Knowledge-Beweisen. Ein Verständnis der Grundlagen ist jedoch unverzichtbar, um die Diskussion und Weiterentwicklung auf Solana voranzubringen. 

Wenn du bis hierher gelesen hast: Danke, Anon! Gib unten deine E-Mail-Adresse ein, damit du keine Neuigkeiten zu Solana verpasst. Möchtest du tiefer einsteigen? Entdecke die neuesten Artikel im Helius-Blog und setze deine Reise mit Solana noch heute fort.

Weitere Ressourcen

• Eine ungefähre Einführung in die Funktionsweise von zk-SNARKs von Vitalik
• POSEIDON: Eine neue Hashfunktion für Zero-Knowledge-Beweissysteme (aktualisierte Version)
• SIMD-0075: Secp256r1-Vorkompilierung
• Den Unterschied zwischen zk-SNARKs und zk-STARKs verstehen
• Dokumentation zu ZK Compression