ZK Compression Keynote: Breakpoint 2024

ZK Compression: Send it to Zero

Bei der Entwicklung auf Solana fällt schnell auf: Rechenleistung ist relativ günstig, Datenspeicherung dagegen teuer. Bei einem SOL-Preis von 150 US-Dollar kostet das Erstellen von 1.000 Token-Accounts beispielsweise rund 300 US-Dollar. Eine Million Accounts würde 300.000 US-Dollar kosten. Dadurch wird die Skalierung von Anwendungen auf eine große Nutzerbasis finanziell untragbar, da diese Kosten mit dem SOL-Preis steigen. Zudem stellt das State-Wachstum alle zustandsbehafteten Blockchains vor Herausforderungen. Beim Erstellen neuer Accounts fallen Rent-Gebühren für deren Erhalt an, was teuer ist. Solana hat derzeit mehr als 500 Millionen Accounts. Täglich kommen etwa eine Million neue Accounts hinzu.

ZK Compression löst diese Probleme durch:

• Tausendmal günstigere Accounts
• Eine Lösung für das State-Wachstum
• Eine Grundlage für ZK-Berechnungen auf Solana

State Compression + ZK

Um ZK Compression zu verstehen, betrachten wir zuerst State Compression. Sie umfasst fünf zentrale Phasen:

1. Millionen Accounts → „Fingerabdruck“
2. Fingerabdruck on-chain speichern
3. Account-Verlauf im Solana-Ledger speichern
4. Aktuellen Account-State mit einem Indexer zwischenspeichern
5. Komprimierten Account-State über den On-Chain-„Fingerabdruck“ verifizieren

Zunächst komprimieren wir Millionen von Solana-Accounts und hashen sie zu einem kompakten „Fingerabdruck“. Dieser Fingerabdruck wird in einem On-Chain-Account gespeichert, während die vollständigen zugrunde liegenden Account-Daten weiterhin im Solana-Ledger verfügbar sind. Um die Gültigkeit dieser Off-Chain-Accounts sicherzustellen, verwenden wir einen Prover-Mechanismus, der ihre Integrität anhand des On-Chain-Fingerabdrucks verifiziert. Im letzten Schritt kommen Zero-Knowledge-SNARKs zum Einsatz. Sie bilden die Grundlage des Proof-Systems, das die Integrität dieser Accounts verifiziert.

Warum ZK Compression?

Mehrere zentrale Eigenschaften machen ZK Compression zur idealen Lösung für State Compression. Komprimierte Accounts verhalten sich beispielsweise ähnlich wie normale Solana-Accounts. Entwickler können daher ihre vorhandenen Kenntnisse und Entwicklungsmethoden mit geringem Lernaufwand weiterverwenden. Das senkt die Einstiegshürde und erleichtert Entwicklern die Einführung von ZK Compression.

‍Die vom Indexer bereitgestellte API entspricht weitgehend den bestehenden RPC-Aufrufen. Die Methode getAccountInfo wird beispielsweise direkt auf getCompressedAccount abgebildet. Diese Eins-zu-eins-Zuordnung gilt für die gesamte RPC API. Dadurch lässt sich ZK Compression einfacher in bestehende Solana-Tools und Workflows integrieren.

Komprimierte PDAs

Eine zentrale Funktion dieses Systems ist die Unterstützung komprimierter program-derived addresses (PDAs). PDAs sind deterministische Account-Adressen, die sich anhand einer bestimmten Programmadresse und eines Seeds konsistent ableiten lassen. Komprimierte PDAs verhindern Probleme wie Race Conditions, Adresskollisionen oder das versehentliche Erstellen mehrerer Accounts für dieselbe Kombination aus Programmadresse und Seed. Diese Verbesserung ist ein wichtiger Grund für den Wechsel vom bestehenden SPL-System zur Account-Komprimierung zu ZK Compression.

‍Die vollständige Unterstützung für ZK Compression kann Solana erheblich verändern. Mit PDAs und der Möglichkeit, Programme miteinander zu kombinieren, lassen sich komplexere Architekturen aus mehreren Programmen und unterschiedlichen PDAs erstellen. Die Entwicklung ähnelt dabei dem vertrauten Erstellen traditioneller Anwendungen. Das ist zu einem Bruchteil der Kosten möglich und senkt die Account-Kosten um bis zu das Tausendfache. Diese drastische Kostensenkung erschließt neue Anwendungsfälle, die bisher zu teuer waren.

Verbesserte Komponierbarkeit

Alles läuft direkt auf Solana – es handelt sich weder um ein L2 noch um ein Validium. Das Solana-Ledger stellt die Datenverfügbarkeit automatisch sicher. Dadurch ist die Ausführung verifizierbar und vollständig komponierbar.

‍Zero-Knowledge-Proofs reduzieren die Proof-Größe auf konstante 128 Byte. Dadurch bleibt in jeder Transaktion mehr Platz für andere Operationen, was die Komponierbarkeit vereinfacht und zusätzliche Aktivitäten flexibler macht. Die Proof-Größe bleibt gleich – unabhängig davon, wie viele Accounts in einer einzelnen Transaktion aktualisiert, gelesen oder geschrieben werden und wie viele Ein- oder Ausschlüsse nachgewiesen werden müssen. Das ist entscheidend, da Solana-Transaktionen grundsätzlich klein sind (1,2 Kilobyte). Für schnelle Beweiszeiten war eine andere Hash-Funktion für State-Merkle-Bäume erforderlich. Deshalb konnten wir das ursprüngliche SPL-Programm zur Account-Komprimierung nicht verwenden.

Dekomprimierung

Eine weitere wichtige Funktion ist die Dekomprimierung. Sie verhindert Lock-in und ermöglicht nahtlose Interoperabilität zwischen „normalen“ und komprimierten Accounts. Jeder Solana-Account kann komprimiert werden, sodass du die Rent-Kosten zurückerhältst. Du kannst einen komprimierten Account außerdem jederzeit dekomprimieren und problemlos zwischen beiden Formen wechseln. Wenn du beispielsweise einen komprimierten Token swappen möchtest, kannst du ihn einfach dekomprimieren und den Swap über Jupiter ausführen.

Die Dekomprimierung ermöglicht nahtlose Übergänge zwischen Hot State und Cold State. Wenn du beispielsweise ein Spiel mit verschiedenen komprimierten Karten und Gegenständen entwickelst, kannst du sie während eines Kampfes dekomprimieren, um schnelle State-Änderungen zu ermöglichen. Anschließend komprimierst du sie erneut und speicherst das Endergebnis, etwa Änderungen an den Trefferpunkten. Für die Parallelität innerhalb eines einzelnen Baums während eines Slots gelten einige Einschränkungen. Vermeide Komprimierung, wenn du denselben Account innerhalb eines Blocks mehrfach aktualisieren musst. In solchen Fällen solltest du den jeweiligen Account dauerhaft dekomprimieren, damit er als normaler On-Chain-Account funktioniert. Ein AMM-Pool-Account eignet sich beispielsweise besser dafür, da sein State regelmäßig aktualisiert werden muss. Das System ist flexibel genug, um innerhalb derselben Transaktion mit komprimierten und dekomprimierten Accounts zu interagieren.

Diese vollständig generalisierte Lösung ist nicht auf ein einzelnes Programm, eine Geschäftslogik oder eine Anwendung beschränkt. Solana-Accounts lassen sich kostengünstig und mit integrierter Indexierungsunterstützung komprimieren. Die Lösung ist vollständig quelloffen, produktionsbereit und an verschiedene Anwendungsfälle anpassbar.

Komprimierte Token

Komprimierte Token sind ohne entsprechende Unterstützung nicht direkt mit Börsen und DeFi-Plattformen kompatibel. Dieses Problem lässt sich jedoch einfach lösen, indem du den komprimierten Token in einen standardmäßigen SPL-Token dekomprimierst. Danach kannst du ihn wie jeden normalen Token in DeFi und auf Börsen verwenden. Diese Flexibilität verhindert Lock-in. Nutzer können nach Bedarf zwischen komprimierten und normalen Token wechseln. Komprimierte Token eignen sich ideal für Cold-Anwendungen mit selteneren Interaktionen. Normale Token-Accounts eignen sich besser für Hot State oder häufig verwendete Assets. Einer der größten Vorteile dieses Systems besteht darin, das Problem des State-Wachstums zu lösen: Cold-State-Daten werden in einen komprimierten Speicher verschoben. So bleiben alle Vorteile erhalten, während sich der State effizienter verwalten lässt.‍

‍In unserer ersten Version haben wir komprimierte Token eingeführt. Sie basieren auf denselben Tools, die du auch für jede andere Anwendung mit Komprimierungsunterstützung verwenden würdest. Das Programm für komprimierte Token entspricht dem Solana-Token-Programm. Es bietet dieselbe Nutzererfahrung bei tausendfach niedrigeren Kosten. Token-Erweiterungen sollen Anfang 2025 live gehen.

Mit Funktionen wie der Dekomprimierung kannst du große Mengen an Token per Airdrop verteilen und sie bei Bedarf schnell für DeFi-Aktivitäten dekomprimieren. Zero-Knowledge-Proofs (ZK-Proofs) gelten oft als der Heilige Gral rechenintensiver Prozesse. Wir haben den Ablauf jedoch so optimiert, dass Transfers standardmäßigen SPL-Token-Transfers ähneln und Beweiszeiten im Millisekundenbereich erreichen. Damit rückt produktionsreifes ZK für Endnutzer in den Vordergrund und die Verwaltungskosten für Token-Accounts sinken erheblich.

Wie funktioniert ZK Compression?

Das Gesamtsystem besteht aus fünf Hauptkomponenten: 

• Ein Wald aus State-Bäumen
• Light System Program
• Compressed Token Program
• Forester-Nodes
• Indexer (Photon)

Ein Wald aus State-Bäumen

Zunächst gibt es State-Merkle-Bäume, die wir als „Wald aus State-Merkle-Bäumen“ bezeichnen. Diese Struktur erzeugt einen eindeutigen kryptografischen Fingerabdruck einer Gruppe von Accounts, den wir on-chain speichern können. Vier Accounts lassen sich beispielsweise rekursiv zu einer Merkle-Baumstruktur hashen.

Der abschließende 32-Byte-Hash an der Spitze garantiert kryptografisch die Integrität der zugrunde liegenden Daten aller Accounts. Dadurch lässt sich der State jedes Accounts als Teil des Merkle-Baums einfach verifizieren, indem er mit der State-Root verglichen wird. Wir verwenden hier den Begriff „Wald“, weil mehrere Merkle-Bäume mit jeweils eigener Root vorhanden sind.

Vergleich mit der bestehenden SPL-Account-Komprimierung

Eine wesentliche Verbesserung von ZK Compression gegenüber dem bestehenden SPL-Programm zur Account-Komprimierung ist der Nachweis, dass ein State-Element Teil eines bestimmten Merkle-Baums ist. Dadurch lassen sich Proofs innerhalb der Größenbeschränkungen von Solana-Transaktionen effizient erzeugen. Außerdem können wir die Eindeutigkeit einer bestimmten Adresse nachweisen, indem wir einen Adressbaum verwalten. Er ähnelt einem State-Merkle-Baum, bietet jedoch eine zusätzliche Funktion: Der Nachweis der Aufnahme in ein Blatt belegt zugleich den Ausschluss eines bestimmten Zahlenbereichs. So lässt sich ein 248-Bit-Adressraum mit wesentlich kleineren Merkle-Bäumen verwalten und die Eindeutigkeit der Adressen sicherstellen.

M Accounts können für N Bäume nachgewiesen werden, während die Proof-Größe konstant 128 Byte beträgt und damit gut innerhalb der Größenbeschränkung von 1,2 KB für Solana-Transaktionen liegt. Die Off-Chain-Erzeugung von Proofs ist teurer als beim bestehenden SPL-Programm zur Account-Komprimierung. Die On-Chain-Verifizierung von Proofs bleibt jedoch konstant und ist in den meisten Fällen günstiger als beim bestehenden Komprimierungsprogramm.

Light System & Compressed Token Programs

Das Protokoll umfasst zwei zentrale Programme. Das Light System Program ist ein On-Chain-Contract, der das Solana System Program abbildet. Es interagiert mit dem Merkle-Baum, setzt das standardmäßige Solana-Account-Modell durch und verifiziert die Eindeutigkeit von PDAs. Das Compressed Token Program bildet das SPL-Token-Programm nach und setzt das SPL-Datenlayout innerhalb des komprimierten Account-Modells durch.

Forester-Nodes

Forester-Nodes verwalten diesen Light-Wald. Wenn du einen komprimierten Account aktualisierst, wird dem Baum ein neuer Account-State hinzugefügt. Der alte State wird auf null gesetzt oder ungültig gemacht.

Dieser Ansatz hat zwei zentrale Auswirkungen. Erstens verändert jede State-Aktualisierung die Root, da sich Änderungen im invertierten Merkle-Baum bis zur Spitze ausbreiten. Zweitens füllen sich die Bäume allmählich und erreichen schließlich ihre Kapazitätsgrenze. Hier kommt der Wald aus Light-Bäumen ins Spiel.

Forester-Nodes pflegen die State-Root. Sie aktualisieren sie asynchron und übernehmen den Rollover voller State-Bäume. Du kannst ohne Genehmigung einen Forester-Node für deine eigenen State-Bäume betreiben. Das funktioniert ähnlich wie der Betrieb eines RPC und ermöglicht jedem, seine eigenen State-Aktualisierungen zu verwalten. Als App-Entwickler hast du ein direktes Interesse daran, deinen komprimierten State zu pflegen. Dadurch entsteht ein natürlicher Anreiz, deine State-Bäume korrekt zu verwalten. Du kannst entweder einen eigenen Node selbst hosten oder einen Anbieter dafür bezahlen.

Photon

Der Photon-Indexer ist eine quelloffene Lösung zum Erfassen und Verwalten von Aktualisierungen, Erstellungen, Änderungen und anderen Ereignissen im Zusammenhang mit komprimierten Accounts auf der Blockchain. Er überwacht On-Chain-Aktivitäten und speichert den aktuellen State dieser Accounts zwischen. Zusätzlich erzeugt er kryptografische Proofs, die zur Verifizierung oder Datenänderung verwendet werden können.

‍Der produktionsreife Photon-Indexer enthält wesentliche Verbesserungen, die auf Erkenntnissen aus früheren Komprimierungsversionen basieren. Er soll benutzerfreundlich und zugänglich sein – egal, ob du als einzelner Entwickler, Unternehmen oder RPC-Anbieter arbeitest.

Die lokale Entwicklung ist jetzt deutlich einfacher. Ein Ein-Klick-CLI-Tool integriert sich nahtlos in dein lokales Setup. Außerdem steht ein entwicklerorientierter Explorer zur Verfügung. Seine visuelle Oberfläche zeigt komprimierte Accounts und ihre Änderungen und ermöglicht dir, den Transaktionsverlauf zu prüfen.

Photon erstellt täglich Snapshots und beschleunigt damit Entwicklung und Deployment. Statt ab dem Genesis-Block neu zu indexieren, können Entwickler mit einem Snapshot beginnen. Dadurch sinken Boot- und Startzeiten auf höchstens 15 Minuten. Diese Snapshots verbessern auch die Replikation. Sollte ein RPC-Anbieter die Unterstützung für Komprimierung einstellen, kannst du problemlos einen Snapshot abrufen und den Indexer unabhängig betreiben. Snapshots minimieren das Risiko von Datenverlusten und können in dezentralen Lösungen wie FileCoin gespeichert werden.

Mit Photon kannst du flexibel nur einen Teil der Daten indexieren. Das senkt die Hardwareanforderungen erheblich und verkleinert die Datenbank. Mit SQLite reicht dafür ein einziger CLI-Befehl. Als RPC-Anbieter kannst du alternativ den gesamten Datensatz indexieren. Photon ist in jedem Helius-Tarif verfügbar. Du kannst es außerdem unabhängig betreiben oder einen anderen Anbieter mit der Bereitstellung beauftragen.

Von Entwicklern, für Entwickler

Wir konzentrieren uns vollständig auf Entwickler und arbeiten aktiv an drei wichtigen Verbesserungen, die speziell die Entwicklererfahrung optimieren.

Web3.js für Komprimierung

Das SDK funktioniert ähnlich wie Solana web3.js, unterstützt aber die Komprimierung vollständig. Für einen Transfer komprimierter Token rufst du zunächst deine komprimierten Token-Accounts ab. Mit diesen Accounts erhältst du anschließend einen Gültigkeits-Proof von deinem RPC oder einem dedizierten Prover-Node. Danach erstellst du die Instructions wie beim SPL-Token-Programm. Du gibst an, was du senden möchtest, welche Menge, welchen Mint und welchen Empfänger – und erstellst so eine reguläre Solana-Transaktion.

‍Vollständiges lokales Entwicklungs-Setup

Wir bieten einen Test-Validator, der mit allem vorkonfiguriert ist, was du für die lokale Entwicklung benötigst. Dazu gehören alle erforderlichen Programme, der Photon-Indexer und ein lokaler Prover-Node. Das vereinfacht den Einrichtungsprozess für Entwickler.

Anchor-Makros

Wenn du mit der Entwicklung von Solana-Programmen über Anchor vertraut bist, soll sich die Arbeit mit komprimierten Accounts genauso nahtlos anfühlen wie mit normalen Accounts. Wenn du bereits ein Anchor-Programm geschrieben hast, wirst du die vertraute Entwicklererfahrung sofort wiedererkennen. Die Anchor-Makros befinden sich derzeit noch in Entwicklung.

Airship

Mit Airship können Entwickler ZK Compression schon heute über ein einfaches und kostengünstiges Tool für Massen-Airdrops von Token nutzen. Es bietet sowohl eine Benutzeroberfläche als auch eine CLI. Da es vollständig quelloffen ist, können Entwickler es forken und an ihre Anforderungen anpassen. Wenn mehr Entwickler komprimierte Token per Airdrop verteilen, wird das Ökosystem sie in verschiedenen Anwendungen übernehmen. Falls eine sofortige Umwandlung gewünscht ist, können Entwickler die Token jedoch direkt dekomprimieren. Dadurch ist Airship schon heute ein einsatzbereites Airdrop-Tool für normale Token.

‍Das Tool unterstützt automatisch Airdrops an Besitzer von Solana Mobile, bestimmter Token oder NFT-Sammlungen. Wenn du bereits eine Empfängerliste erstellt hast, kannst du auch eine CSV-Datei importieren und Token sowie Airdrop-Menge angeben. Sowohl die CLI als auch die Benutzeroberfläche ermöglichen dir, deinen Airdrop beim zuletzt gespeicherten Zustand fortzusetzen, falls Probleme wie der Verlust der Internetverbindung auftreten. Das ist besonders bei größeren Airdrops nützlich, deren Verteilung an eine lange Adressliste 30 bis 45 Minuten dauern kann.

Ein neuer Designraum für Apps

ZK Compression löst das Problem des State-Wachstums, indem nur der abschließende Root-Hash aller Accounts im Speicher des aktiven Validators abgelegt wird. Dieser Ansatz verringert Probleme durch State-Wachstum wirksam. Darüber hinaus eröffnet ZK Compression neue Designmöglichkeiten für Anwendungen. Hier sind einige mögliche Anwendungsfälle:

• Kompressoren für SPL-Token
• Eine Milliarde Meme-Coins
• Prognosemärkte für Twitter-Posts
• Identifikator-PDAs für Nodes in DePin-Netzwerken
• Verifizierbare Berechnung und Verteilung von Belohnungen
• Brücken mit minimierten Vertrauensannahmen
• ZK-Identitätsprotokolle

Die Dokumentation enthält weitere Ideen.

ZK Compression ist bereits heute im Mainnet und Devnet live! Lies zum Einstieg unsere Dokumentation und arbeite die Beispiele durch. Zusätzlich veranstalten wir einen Hackathon mit Preisen im Wert von bis zu 45.000 US-Dollar.

Wenn du tiefer in ZK einsteigen möchtest, findest du in unseren früheren Helius-Blogbeiträgen ausführliche Informationen zu den Grundlagen von Zero-Knowledge-Proofs und ihren Anwendungen auf Solana.

‍