Solana Builders: ZK Compression

Eigenschaften

Bevor wir sie im Kontext von ZK Compression bewerten, sehen wir uns einige Eigenschaften von Solana an, die uns interessieren:

1. Synchrone atomare Komponierbarkeit
2. Nebenläufigkeit
3. Sicherheit
4. Verfügbarkeit
5. Zensurresistenz

Anfängliche Vertrauensannahmen

Wir verwenden den Begriff „vertrauensfrei“ für die Sicherheitsannahmen eines Full Nodes. Diese Definition dient als Ausgangspunkt. Alles, was ein Full Node nicht allein erledigen kann, erfordert zusätzliche Vertrauensannahmen.

Einige Grundlagen

Ich versuche, dir mit kurzen Stichpunkten knapp die nötigen Grundlagen zu Solana zu vermitteln, damit du ZK Compression verstehen kannst. 

• Der Solana-Zustand wird auf den Festplatten von Full Nodes in der „AccountsDB“ gespeichert
• Die Speichereinheit heißt „Account“
• Accounts haben Adressen (jeweils 32 Byte)
• Die Datenmenge, die ein Account speichern kann, variiert zwischen 0 und maximal 10 MB
• Das Speichern von 10 MB auf Solana kostet ungefähr 70 SOL, die der Ersteller des Accounts bezahlt. Diese Kosten hängen vom Speicherplatz ab, nicht von der Anzahl der Accounts — es können 1x 10 MB oder 1000x 10 KB große Accounts sein.
• Alle Accounts auf Solana sind derzeit zusammen 76 GB groß (komprimiert)
• Jede Solana-Transaktion muss alle Accounts angeben, aus denen sie liest und in die sie schreibt
• Solana-Transaktionen sind derzeit auf 1232 Byte begrenzt (es gibt einen Vorschlag, dieses Limit zu erhöhen)
• Jede Solana-Transaktion muss bestimmte Daten angeben
  • Signaturen (jeweils 64 Byte)
  • Accounts (jeweils 32 Byte)
  • Anweisungsdaten (beliebige Länge)
  • Aktueller Blockhash (32 Byte)
  • Programmadressen (jeweils 32 Byte) (CPI: programmübergreifende Aufrufe)
• Solana-Transaktionen enthalten einen 32 Byte großen „aktuellen Blockhash“, der innerhalb der neuesten 150 Blöcke aufgenommen werden muss. Andernfalls gilt die Transaktion als ungültig und muss erneut signiert und eingereicht werden

Lebenszyklus einer normalen Transaktion

Eine typische Transaktion durchläuft folgenden Lebenszyklus:

1. Zuerst werden das Alter geprüft (nur aktuelle Transaktionen sind gültig), Duplikate entfernt, die Struktur verifiziert, Gebühren (Gas) berechnet und Signaturen geprüft
2. Der Programm-Bytecode wird anhand der Programmadresse geladen und die Solana Virtual Machine (SVM) instanziiert
3. Alle von der Transaktion referenzierten Accounts werden geprüft, aus dem Speicher in den Arbeitsspeicher geladen und an die SVM übergeben
4. Der Programm-Bytecode wird ausgeführt
5. Alle geänderten Accounts werden mit ihrem aktualisierten Zustand zurück in den Speicher synchronisiert

Die wichtigsten Gründe für ZK Compression sind:

• On-Chain-Zustand ist teuer. Tausend Accounts kosten beispielsweise 70 SOL. Produkte wie Drip Haus werden daher schnell teuer
• Auch ohne vollständige Merkleisierung des Zustands führen mehr auf der Festplatte gespeicherte Accounts zu größeren Snapshots, größeren Indizes und so weiter
• Nicht auf alle Accounts wird häufig zugegriffen. Daher sind fortlaufende Ressourcenkosten unnötig

Wie lässt sich Komprimierung also am einfachsten erreichen?

Statt Accounts auf der Festplatte zu speichern und bei Bedarf zu lesen (Schritt 3 im Lebenszyklus der Transaktionsausführung), kann eine Transaktion die Account-Daten als Teil ihrer Nutzlast übergeben. So entfallen die Kosten für die On-Chain-Speicherung. Das wirft jedoch ein neues Problem auf: Wie lässt sich sicherstellen, dass Nutzer beim Zustand nicht lügen?

Nehmen wir beispielsweise an, der Off-Chain-Wert eines Accounts, der ein Token-Guthaben speichert, beträgt 1200 und sein Besitzerfeld enthält „BYixJwV32DjeuyRww72PwZMyKcaedN533GBrv7CDh4n9“.

Wenn du eine Transaktion mit diesen Daten an die Chain sendest, woher weiß sie dann, dass du bei der Anzahl der Token der Adresse „BYixJwV32DjeuyRww72PwZMyKcaedN533GBrv7CDh4n9“ nicht gelogen hast?

Schließlich hat der Full Node, der die Transaktion verarbeitet, keinen Zugriff auf die Off-Chain-Daten — er erwartet, dass du die Daten zusammen mit der Transaktion bereitstellst.

Dafür kannst du Merkle-Proofs verwenden. Ohne näher auf sie einzugehen: Mit Merkle-Proofs kannst du dich auf überprüfbare Weise auf bestimmte Daten festlegen und benötigst dafür nur wenig On-Chain-Speicher. Alle mit der Chain synchronisierten Full Nodes speichern diese kleine „Verpflichtung“. Wenn jemand Daten in einer Transaktion bereitstellt, kann diese Person in derselben Transaktion auch einen „Proof“ liefern, der anhand der Verpflichtung verifiziert wird. Dieser Proof ist kryptografisch sicher.

Gibt es dabei Probleme?

Das Problem ist, dass Merkle-Proofs groß sein können. Enthält ein Baum 100.000 Accounts, beträgt der Proof für einen dieser Accounts 17 * 32 = 544 Byte. Wenn du Proofs für mehrere Accounts bereitstellen möchtest, wird die Proof-Größe im schlimmsten Fall multipliziert. Bei zehn Accounts wären das 10 * 544 = 5440 Byte. Dieses Platzproblem betrifft speziell Solana, da eine Solana-Transaktion derzeit auf 1232 Byte begrenzt ist, während andere Chains meist weniger restriktiv sind. Sieh dir den obigen Abschnitt an, in dem wir die Größe der einzelnen Komponenten auflisten — Programme, Signaturen, aktueller Blockhash und so weiter. Selbst im besten Fall verbrauchst du also allein für den Merkle-Proof die Hälfte der Transaktionsgröße. 

Daraus ergeben sich einige Fragen.

Wie überträgst du bei einer Transaktionsgröße von 1232 Byte sämtliche Daten als Teil der Transaktion?

Das ist eine ausgezeichnete Frage. ZK Compression eignet sich für eine sehr große Anzahl von Accounts, wenn diese nur kleine Datenmengen enthalten. Token-Guthaben (8 Byte pro Token), kleine Mengen an NFT-Metadaten und Ähnliches — 100 Byte Daten passen problemlos in eine Transaktion. 1000 Byte sind schwierig, da noch andere Inhalte hinzukommen. Wenn deine Accounts größere Datenmengen speichern müssen, funktioniert diese Methode (und ZK Compression) nicht.

Dabei gibt es eine Feinheit: Dieselbe Logik wie bei ZK Compression lässt sich auf Teile des Account-Zustands anwenden. Auch wenn die vollständigen Daten eines Accounts nicht in eine einzige Transaktionsnutzlast passen, gibt es also Auswege — insbesondere die Festlegung auf Teildaten und das Bereitstellen eines Proofs dafür.

Sind Merkle-Proofs die einzige Möglichkeit dafür?

Nein. Ein Merkle-Proof ist nur eine Art von Vektor-Commitment. Die Commitment-Größe beträgt 32 Byte und die Proof-Größe Log2(N) * 32 Byte, wobei N der Größe des Vektors entspricht, auf den du dich festlegst. Daher stammt die 17, denn Log2(100000) ist 17. Es gibt jedoch auch Commitments mit konstanter Proof-Größe (KZG, Pedersen). ZK Compression verwendet tatsächlich eine solche Methode! 

Du sagst, dass die normalerweise als Teil des Zustands auf einem Full Node gespeicherten Account-Daten zusammen mit der Transaktion bereitgestellt werden müssen. Wo werden diese Daten gespeichert?

Sehr gute Frage. Sie wirkt sich auf unsere Vertrauensannahmen und Eigenschaften aus. Die Antwort lautet: überall! Spezialisierte RPC-Server können diese Daten speichern. Sie können Teil von Filecoin oder IPFS sein. Oder der Nutzer speichert sie sogar auf dem eigenen Rechner. Entscheidend ist: Solange alle Elemente des Vektors irgendwo gespeichert sind, lassen sich die Proofs bei Bedarf berechnen. Welche Folgen der Speicherort hat, behandeln wir im Abschnitt zu den Eigenschaften. 

Können andere Chains das ebenfalls?

ZK Compression setzt ausdrücklich voraus, dass die Verifizierung von zk-SNARKs günstig ist. Das funktioniert auf Solana gut, weil Rechenleistung günstiger als Speicher ist. Das allgemeine Konzept, Vektor-Commitments und Proofs für die mit jeder Transaktion bereitgestellten Daten zu verwenden, ist auch auf anderen Chains möglich. Teure Rechenleistung macht den Vorteil dort jedoch weniger deutlich als auf Solana. Tatsächlich sind dauerhafte Gas-Kosten für die Verifizierung im Vergleich zu einem einmaligen SSTORE auf EVM-basierten Chains letztlich sogar höher.

Was ist ZK Compression?

• Wenn du nicht weißt, was ZK Compression ist, erklärt es dieser Abschnitt
• Wenn du nur eine vage Vorstellung davon hast, solltest du diesen Abschnitt trotzdem lesen, da es einige verbreitete Missverständnisse gibt
• Wenn du genau weißt, was es ist, lies ihn bitte ebenfalls, damit du mich korrigieren kannst, falls ich etwas falsch verstanden habe :) 

Wenn du den vorherigen Abschnitt verstanden hast, hast du bereits 90 % von ZK Compression verstanden. Das Hauptproblem war die Größe des Merkle-Proofs. ZK Compression ist also im Grunde nur ein Verfahren, mit dem sich eine Berechnung beweisen lässt.

Wenn du nicht weißt, was ZK ist, spielt das keine große Rolle. Du musst nur wissen, dass du damit beweisen kannst, eine Berechnung „korrekt“ ausgeführt zu haben. Ein einfaches Beispiel: Du möchtest beweisen, dass du zwei Zahlen multipliziert hast, um eine dritte Zahl zu erhalten, also 4*3 = 12

Um dies auf die „ZK-Art“ zu beweisen, verwendest du folgende Funktion:

f(x,y) = x*y

Wenn du für den obigen Code einen Circuit erzeugst, erstellt der Prover einen Beweis für die korrekte Berechnung. Der Circuit selbst ist das Commitment. Daher weiß jeder, welche „Berechnung“ du ausführst. Das Schöne daran: Niemand muss die Eingaben kennen. Wenn du f(3,4) ausführst, gibt die Funktion 12 und den „Proof“ zurück. Nun kann jeder 12, „Proof“ nehmen und verifizieren, dass du IRGENDWELCHE zwei Zahlen multipliziert hast, um 12 zu erhalten. Niemand weiß, ob du 4,3, 6,2 oder sogar 12,1 verwendet hast. Dass du diese Zahlen verbergen kannst und jemand das Ergebnis trotzdem verifizieren kann, ist der „Zero-Knowledge“-Teil.

Warum erkläre ich das?

Dieses allgemeine Konzept ist extrem leistungsfähig, um zu beweisen, dass du eine bestimmte Berechnung ausgeführt und ein bestimmtes Ergebnis erhalten hast. Sobald jemand das Ergebnis und den Proof hat, kann diese Person verifizieren, ob du die Berechnung korrekt ausgeführt hast, ohne sie tatsächlich selbst auszuführen. Das gilt für JEDE beliebige Berechnung. Ich habe nur zwei Zahlen multipliziert. Du kannst damit aber auch sagen: „Ich habe diese zehn Signaturen geprüft und sie sind alle gültig.“ Das ist der zweite Vorteil und einer der wichtigsten Gründe, warum Zero-Knowledge-Proofs auch dann verwendet werden, wenn du nichts „verbergen“ musst. Du verwandelst ein Problem, das 1000 Rechenschritte (oder sogar eine Million) erfordert, in eines, bei dem nur ein Proof verifiziert werden muss, um zu wissen, dass die Berechnung korrekt ausgeführt wurde. Die Einschränkung: Das Erzeugen des Proofs benötigt etwas Zeit.

ZK Compression nutzt dieselbe Technologie, um die eigentliche Logik zur Prüfung der Zugehörigkeit zum Merkle-Baum auszuführen. Es besitzt also einen Circuit, der Account-Daten und einen Proof (128 Byte) entgegennimmt und verifiziert, dass die Daten tatsächlich Teil des „Commitments“ auf der Chain sind. (Der eigentliche Proof ist 256 Byte groß. Bei elliptischen Kurven und Punkten ist es jedoch praktisch, dass ein Punkt genügt, um den zweiten Punkt zu bestimmen, wenn die Kurve bekannt ist.)

Dies geschieht hauptsächlich, um die Proof-Größe auf konstante 128 Byte zu reduzieren. Dadurch bleibt noch relativ viel Platz für die Daten kleiner Accounts. Während die Größe eines normalen Merkle-Proofs Log2(N) beträgt, bleibt sie bei ZK Compression immer konstant. So kann ein einziges Commitment eine sehr große Anzahl von Accounts umfassen. (Zum Vergleich: Ein Merkle-Proof für 100.000 Accounts wäre ungefähr 550 Byte groß und würde damit die Hälfte der Transaktionsnutzlast belegen.) 

Dieser Proof kann off-chain erzeugt werden. Seine Verifizierung muss jedoch on-chain erfolgen, da ein Programm wissen muss, ob du die richtigen Daten für einen Account bereitgestellt hast, bevor es die Ausführung fortsetzen darf. Dafür muss der grundlegende Mechanismus zur Verifizierung von ZK-Proofs vorhanden sein. Das von ZK Compression verwendete Prover-System heißt Groth16. Es stützt sich wiederum auf den alt_bn128-Systemaufruf, der im Mainnet derzeit hinter einem Feature-Flag liegt und getestet wird.

Das Spannende ist, dass sich der von ZK Compression verwendete Mechanismus zur Verifizierung beliebiger Berechnungen einsetzen lässt — nicht nur für die Frage: „Gehört dieses Blatt zu einem Baum mit dieser Wurzel?“

Ein zentraler Vorteil von ZK Compression ist, dass es die gesamte Infrastruktur bereitstellt, sodass sich Entwickler überhaupt nicht mit dem „ZK“-Teil befassen müssen. Aus Entwicklersicht wird ein komprimierter Account wie jeder andere Account mit denselben Feldern und so weiter behandelt. Innerhalb des Programms kann er daher als normaler Account gelten. Es ist wertvoll, den Großteil der „ZK-Magie“ zu abstrahieren, damit sich Entwickler nicht damit auseinandersetzen müssen.

ZK-Rollups

Ohne zu sehr ins Detail zu gehen: ZK-Rollups verwenden größtenteils dieselben Konzepte wie ZK Compression. Die wichtigste Gemeinsamkeit ist, dass der gesamte Rollup-Zustand auf der Basisschicht (Ethereum) als eine einzige Wurzel dargestellt wird. Deshalb wird teilweise behauptet, ZK Compression sei ein Rollup. Es gibt jedoch entscheidende Unterschiede.

Betrachten wir 100 Rollup-Transaktionen.

Das gesamte ZK-Rollup wird als Circuit behandelt, ähnlich wie das Multiplikationsprogramm aus unserem Beispiel. Alle 100 Transaktionen werden verifiziert — Signaturen, Vertragslogik, Duplikatsprüfung und so weiter — und ein einziger Proof wird erzeugt für

„Nach der Anwendung von 100 Transaktionen ändert sich die Zustandswurzel von A zu B“. Sobald der Proof verifiziert wurde, aktualisiert der Smart Contract die Zustandswurzel von A auf B.

Bei ZK Compression enthält dagegen jede der 100 Transaktionen einen Proof, der lediglich bestätigt, dass die Account-Daten korrekt sind. Die von den Transaktionen erzeugten Zustandsübergänge werden jedoch tatsächlich on-chain als Teil der SVM selbst ausgeführt. Sobald der Proof validiert ist, wird der Account wie ein normaler Account behandelt. Das ist für die Eigenschaft der Komponierbarkeit entscheidend, die wir als Nächstes besprechen.

Eigenschaften erneut betrachtet

Jetzt kommen wir zum interessanten Teil. Welche Eigenschaften von Solana bleiben bei ZK Compression erhalten?

Synchrone atomare Komponierbarkeit

Wenn eine Transaktion zwei mit ZK Compression komprimierte Accounts und zehn „normale“ Accounts referenziert, bleibt die Komponierbarkeit erhalten. Eine Anweisung, die einen komprimierten Account referenziert, kann eine andere Anweisung oder ein anderes Programm aufrufen, die beziehungsweise das einen „normalen“, unkomprimierten Account referenziert. Diese Eigenschaft bleibt vollständig erhalten, selbst wenn zwei Accounts unter verschiedenen Bäumen komprimiert sind. Schlägt eine Anweisung fehl, wird die gesamte Transaktion zurückgesetzt (atomar). Änderungen durch eine in Zeile 1 aufgerufene Anweisung sind in Zeile 2 sichtbar (synchron).

Bei Rollups gilt das nicht, da ZK-Rollups einander weder synchron noch atomar aufrufen können — es sei denn, sie verwenden globale Sperren und erlauben Rollbacks über mehrere Rollups hinweg.

Parallelität

Diese Funktion beeinflusst die Parallelität. Jeder Fall sollte einzeln betrachtet werden:

Schreibvorgänge in mehrere komprimierte Accounts unter demselben Baum

Jeder Baum ist für sich nebenläufig. Wenn Nutzer also aus zwei komprimierten Accounts unter derselben Zustandswurzel lesen oder in sie schreiben, können diese Vorgänge nebenläufig ausgeführt und die Zustandswurzel nebenläufig aktualisiert werden. Die Logik entspricht derjenigen, die Solana für nebenläufige Aktualisierungen von Merkle-Bäumen bei cNFTs verwendet.

Schreibvorgänge in denselben komprimierten Account

Ein einzelner komprimierter Account ist nicht nebenläufig. Wenn zwei Nutzer versuchen, in denselben komprimierten Account zu schreiben, schlägt unabhängig von der Reihenfolge eine der Transaktionen fehl. Bei der normalen Ausführung stehen Schreibvorgänge einer vorherigen Anweisung für die nächste Anweisung zur Verfügung. Bei mit ZK Compression komprimierten Accounts wäre der Proof der Account-Daten jedoch ungültig, da er den vorherigen Zustand beweist.

Außerdem senkt der hohe Verbrauch an Compute Units (CU) durch die Komprimierung die maximale Nebenläufigkeit pro Baum. Aufgrund des CU-Limits pro Account kann jeder Account pro Block nur 12 Millionen Compute Units verbrauchen.

Vertrauensannahmen

Jeder kann sämtliche Rohdaten speichern, die zum Erzeugen der Proofs und zum Einreichen von Transaktionen erforderlich sind. Dies ist jedoch eine zusätzliche Vertrauensannahme, die die Verfügbarkeit des komprimierten Zustands beeinflusst. Wenn die Daten aus irgendeinem Grund „verloren gehen“ oder sich verzögern, kannst du keine Transaktion einreichen, sofern du die Daten nicht selbst gespeichert hast. Glücklicherweise handelt es sich dabei um ein f+1-Problem und nicht um ein 3f+1-Problem, das byzantinische Fehlertoleranz erfordert. Bei einem f+1-Problem genügt ein ehrlicher Node, der die Daten bereitstellt. Da Proofs „selbstverifizierbar“ sind, gibt es kein „Sicherheitsproblem“. Es geht hauptsächlich um die „Verfügbarkeit“ und einen Zensurvektor.

Sowohl reguläre Rollups als auch ZK Compression benötigen einen Gültigkeitsnachweis. Rollups codieren jedoch die vollständige Zustandsübergangsfunktion im Gültigkeitsnachweis, während ZK Compression nur die Frage „Sind die Account-Daten korrekt?“ codiert. Die Vertrauensannahmen unterscheiden sich hier also geringfügig. Bei der Komprimierung betreffen sie hauptsächlich den Zugriff auf den Zustand, während der Zustandsübergang vollständig ausgeführt wird. Bei einem Rollup betreffen sie aus Sicht der Basisschicht die vollständige Zustandsübergangsfunktion. Die Sicherheitsannahmen bezüglich der Anzahl der Bits oder der Schwierigkeit beziehungsweise Unlösbarkeit des zugrunde liegenden Problems sind identisch (Bilineare-Diffie-Hellman-Annahme). Der Unterschied liegt darin, wofür du diesem Sicherheitsmodell vertraust: Zustandszugriff oder Ausführung. Ich erwähne das nur, weil es wichtig ist zu wissen, wo zusätzliche Vertrauensannahmen hinzukommen und wo nicht.

Das Programm, das die mit ZK Compression komprimierten Accounts verifiziert, ist derzeit aktualisierbar. Es kann künftig jedoch unveränderlich gemacht oder eingefroren werden, da es nur einen sehr spezifischen Vorgang ausführt — das Öffnen von Merkle-Proofs — und daher keine ständigen Aktualisierungen benötigt.

Zusätzlich lässt sich die Zustandskomprimierung auf zwei weitere Arten erreichen.

1. Ein Vorschlag zur Erhöhung der Transaktionsgröße (Kanal proj-3x-tx im Solana-Discord) wird derzeit entwickelt. Sobald er live ist, kannst du reguläre Merkle-Proofs verwenden, sofern ihre Größe praktikabel ist
2. Sobald der alt_bn128-Systemaufruf live ist, kann er auch für ein reguläres Vektor-Commitment mit konstanter Proof-Größe verwendet werden (KZG funktioniert mit jeder pairing-freundlichen Kurve, einschließlich alt_bn128). Dafür ist kein ZK-Prover-Circuit erforderlich

Wie nennen wir das?

Leider werden Begriffe wie Rollup, L2 und Validium so locker verwendet, dass manche Rollups nicht einmal Rollups sind. Sie übernehmen weder die Verfügbarkeit noch die Sicherheit oder Zensurresistenz der Basisschicht. Helius wurde zwar vorgeworfen, einen „Marketingbegriff“ zu verwenden. Dieselben Personen haben den Begriff „Rollup“ jedoch aus demselben Grund sehr locker für Projekte verwendet, in die sie investiert haben — Marketing. Tatsächlich werden Nicht-Rollups in verschiedene Phasen eingeteilt, nur damit sie sich weiterhin Rollups nennen können.

Nicht alle machen sich dessen schuldig. Einige haben sich kompromisslos für präzise Terminologie eingesetzt und monatelang mit Menschen diskutiert, die ungenaue Begriffe verwenden, um Nutzer in die Irre zu führen. Grüße an Toghrul, der konsequent präzise Terminologie von allen fordert.

Da ZK Compression einige Eigenschaften und Vertrauensannahmen besitzt, die sich von denen eines Rollups unterscheiden, könnte die Bezeichnung als Rollup Nutzer verwirren. Auch Validium ist zu weit gefasst. Der Begriff ignoriert, dass weder die synchrone atomare Komponierbarkeit noch die Parallelität beeinträchtigt werden, die Datenverfügbarkeit (DA) on-chain liegt und außerdem die Zustandsübergangsfunktion selbst vertrauensfrei ist. Schließlich führen Full Nodes die tatsächlichen Programme vollständig aus, statt lediglich einen Gültigkeitsnachweis für die Ausführung selbst zu verifizieren. Manche könnten argumentieren, dass ZK-Proofs vertrauensfrei sind. Das stimmt jedoch schlicht nicht. Sie minimieren den nötigen Vertrauensumfang zwar erheblich, doch mathematisch sind die Sicherheitsannahmen nicht identisch. Für 99 % der Anwendungsfälle mögen sie ausreichen, aber gegenüber einem Full Node führen sie eine zusätzliche Vertrauensannahme ein — etwa die Bilineare-Diffie-Hellman-Annahme bei einem auf Pairing-Kurven basierenden zk-SNARK. Da ZK Compression den SNARK jedoch verwendet, um die Gültigkeit des Accounts selbst zu prüfen, kann man durchaus sagen, dass ZK Compression nicht vertrauensfrei ist. Für mit ZK Compression komprimierte Accounts gelten Vertrauensannahmen, die für „normale“ Accounts nicht bestehen. Es liegt also irgendwo zwischen Vertrauensfreiheit und einem vollständigen ZK-Rollup.

Wenn wir aus Namen Eigenschaften ableiten, würde ich behaupten, dass die Bezeichnung „Rollup“ diese Eigenschaften oder Vertrauensannahmen nicht vermittelt. Vielleicht brauchen wir einen neuen Namen? ZK Compression klingt völlig passend, solange die Vertrauensannahmen klar sind.