Technische Analyse zu ZKBase: Ein leistungsstarkes ZK-Rollup für skalierbare und sichere ETH-Transaktionen

ZKBase ist ein hochleistungsfähiges ZK-Rollup, das auf ZK Stack und Multi-GPU-Prover basiert. Diese Lösung verbessert die Transaktionsverarbeitungskapazität und bietet ein kostengünstiges Netzwerkerlebnis. Sein Hauptvorteil liegt in der Einführung der Zero-Knowledge-Proof-Technologie (ZKP), mit der Off-Chain-Transaktionen schnell überprüft und bestätigt werden können, während die Transaktionsvertraulichkeit und Datenintegrität gewahrt bleiben. Da alle Gültigkeitsnachweise auf Ethereum überprüft werden, können Benutzer dieselben Sicherheitsgarantien wie in L1 genießen. ZKBase funktioniert ähnlich wie Ethereum, jedoch mit höherem Durchsatz und niedrigeren Gebühren. Smart Contracts werden in Solidity/Vyper geschrieben und können mit denselben Clients aufgerufen werden wie andere EVM-kompatible Ketten. Dieser Artikel stellt die Kernentwicklung und technische Implementierung von ZKBase vor.

1. Schlüsselkomponenten von ZKBase

Tree und TreeBackup : Diese Komponenten verwenden RocksDB, um lokale Kopien des L2-Speicherbaums zu verwalten. Die Datenbank bleibt mit dem neuesten State-Root-Hash synchronisiert und spiegelt kontinuierlich den aktuellen Systemstatus wider.

StateKeeper/VM : Führt Transaktionen aus und speichert die enthaltenen Blöcke sicher in der lokalen RocksDB-Datenbank, wodurch Datenintegrität und kontinuierliche Statusaktualisierungen gewährleistet werden.

Smart Contract : Diese Smart Contracts werden im Ethereum-Mainnet bereitgestellt und verifizieren die außerhalb der Kette übermittelten Zero-Knowledge-Proofs (ZKPs). Nach erfolgreicher Verifizierung aktualisieren diese Verträge die Kontostände im Ethereum-Netzwerk.

GPU Prover : Eine ZK-Rollup-Technologie, die eine sichere und effiziente Transaktionsüberprüfung durch Zero-Knowledge-Beweise gewährleistet. Wenn ein Stapel von Transaktionen außerhalb des Ethereum-Mainnets erfolgt, komprimiert das ZK-Aggregationssystem mehrere Transaktionen in einen einzigen vom Prover berechneten „Gültigkeitsnachweis“, der die Richtigkeit des Stapels nachweist. Dieser Nachweis wird dann an das Ethereum-Netzwerk übermittelt, wodurch die schnelle und sichere Bestätigung einer großen Anzahl von Transaktionen außerhalb der Kette ermöglicht wird.

Brücke : ZKBase bietet einen Überbrückungsmechanismus für die sichere Übertragung von Vermögenswerten zwischen ZKBase und dem Ethereum-Mainnet und gewährleistet so die Interoperabilität und Vermögensliquidität zwischen den beiden Plattformen.

2. ZKBase-Arbeitsablauf

Benutzer können L2-Anfragen entweder über eine Anwendungsprogrammierschnittstelle (API) oder über auf L1 bereitgestellte Verträge initiieren. Nach der Übermittlung gelangen diese Anfragen in einen Mempool und warten auf ihre Ausführung. Insbesondere Transaktionen, die von L1 stammen (z. B. Einzahlungen), werden in einer dedizierten L1-Prioritätswarteschlange gespeichert, um sicherzustellen, dass sie umgehend verarbeitet werden.

Die Mempool-Speicherstruktur ist ein Btreeset (ein von einem Btree implementiertes Set). Die Indexierungsstruktur ist wie folgt:

Dabei ist fee_data nicht an der eigentlichen Score-Berechnung beteiligt, sondern hilft dabei, Transaktionen herauszufiltern, die die Gebührenanforderungen nicht erfüllen. Der Score wird nach Zeitstempel sortiert, und wenn die Zeitstempel identisch sind, dann nach Adresse.

Transaktionen im Mempool werden von der Mempool-Fetcher-Komponente im State Keeper verwaltet. Mit Ausnahme abgelaufener Transaktionen werden Standardtransaktionen in der durch die B-Tree-Traversierung definierten Reihenfolge aus dem Mempool abgerufen und in der Datenbank aufgezeichnet. Sie werden dann vom State Keeper/VM verarbeitet, ausgeführt und zum Aktualisieren des Statusbaums verwendet.

Das Blocklayoutdiagramm zeigt die Organisation der Transaktionen innerhalb eines Blocks und die Anordnung der L2-Blöcke innerhalb eines L1-Batches.

Um jeden L1-Batch zu starten, muss der Bediener wichtige Details eingeben: den Zeitstempel des Batches, seine Position in der Sequenz und den Hashwert des vorherigen Batches.

Der Merkle-Tree-Root-Hash dient in diesem Prozess als grundlegender Root-Hash, um die Gültigkeit des Batches und die Authentizität der Transaktionen sicherzustellen. Gleichzeitig hat der State Keeper die Befugnis, zu entscheiden, wann ein bestimmter L2-Block oder L1-Batch abgeschlossen werden soll, und so seinen Status zu bestimmen. Diese Entscheidung wird durch eine Reihe vordefinierter Kriterien bestimmt, die vom Modul conditional_sealer verwaltet werden. Zu diesen Kriterien gehören Parameter wie Transaktionsanzahl, Größenbeschränkungen und Schwellenwerte für den Gasverbrauch. Nach der Verarbeitung einer Transaktion prüft der State Keeper, welche Versiegelungsbedingung erfüllt ist.

Der Conditional_Sealer verwaltet ein SealCriteria-Register, das Folgendes umfasst:

• Transaktionsanzahllimits,

• L2-Gasgrenzwerte,

• Unter anderem gibt es Obergrenzen für die Menge der veröffentlichten Daten.

Es gibt vier Entscheidungsszenarien: NoSeal, IncludeAndSeal, ExcludeAndSeal und Unexecutable. In den ersten beiden Fällen ist der Prozess derselbe, wobei der Status nach der Ausführung im State Keeper aktualisiert wird. ExcludeAndSeal verarbeitet Transaktionen, die die vordefinierten Batch-Grenzen überschreiten, indem die Transaktionsausführung zurückgesetzt und wieder in die Warteschlange gestellt wird, um in den nächsten L2-Block aufgenommen zu werden. Wenn eine Unexecutable-Situation auftritt, kann die Transaktion nicht ausgeführt werden und wird abgelehnt.

Am Ende jedes Batches generiert der Bootloader einen Platzhalter-L2-Block, um die Transaktionen abzuschließen und den nächsten Zyklus vorzubereiten. Obwohl dieser Block größtenteils leer ist, ist er für interne Vorgänge von entscheidender Bedeutung und enthält ein Übertragungsereignisprotokoll zur Aufzeichnung von Gebührenbewegungen zwischen dem Bootloader und dem Betreiber. Um die Zeitgenauigkeit zu gewährleisten, werden die Zeitstempel des Batches und des letzten Unterblocks mit dem erwarteten L1-Zeitrahmen abgeglichen, um die Widerstandsfähigkeit des Systems gegenüber zeitbezogenen Problemen zu verbessern.

Sobald ein Stapel abgeschlossen ist, generiert der Beweiser einen kryptografischen Beweis, um die Ausführung des Blocks zu verifizieren. In ZKBase besteht die Verantwortung des Beweisers darin, die korrekte Ausführung der ZKBase Ethereum Virtual Machine (EVM) zu beweisen. Dieser Beweis wird dann durch einen Smart Contract im Ethereum-Netzwerk verifiziert. Sobald der Beweis generiert ist, verpackt ihn der Beweiser in eine L1-Transaktion und sendet sie an den ETH_Sender. Der ETH_Sender leitet die Transaktion zur weiteren Verarbeitung an den im Ethereum-Mainnet bereitgestellten ZKBase-Vertrag weiter.

Das Ethereum-Mainnet überprüft die Richtigkeit des Beweises und aktualisiert den Status nach erfolgreicher Überprüfung entsprechend.

Während des gesamten Prozesses überwacht EthWatcher kontinuierlich bestimmte L1-Ereignisse wie Einzahlungen und System-Upgrades, um die Synchronisierung mit dem Ethereum-Mainnet sicherzustellen.

3. Mehrere GPU-Prover-Architektur

Die Architektur nutzt eine Postgres-Datenbank zum Teilen von Daten und ermöglicht parallele Berechnungen über mehrere GPU-Prover hinweg, um die Effizienz der Beweisgenerierung zu verbessern. Die wichtigsten Komponenten sind:

Operator : Der Server, der Layer-2-Dienste bereitstellt.

Prover-Gateway : Ein Kommunikationsmodul, das den Bediener mit dem Proving-Subsystem verbindet.

Zeugengenerator : Generiert Beweisberechnungsaufgaben und speichert Zwischenartefakte.

Vektorgenerator : Fasst alle Rechenaufgaben in einem für GPU-Berechnungen geeigneten Vektorformat zusammen und sendet sie an die Beweiser.

Beweisführer: Führt die eigentliche Berechnung und Überprüfung von Beweisen durch.

Kompressor: Komprimiert den endgültigen Proof in das SNARK-Format.

Workflow zur Proof-Generierung

Stapelgenerierung : Der Operator sammelt Transaktionen und generiert einen neuen Stapel.

Batch-Empfang : Das Prover-Gateway ruft den neuen Batch vom Operator ab und beginnt mit der Vorbereitung zur Generierung des Zero-Knowledge-Beweises.

Datenbankeinfügung : Das Prover Gateway fügt die Batch-Informationen in die Postgres-Datenbank ein. Die nachfolgende Datenverarbeitung interagiert direkt mit der Datenbank, ruft Daten aus den entsprechenden Eingabetabellen ab und fügt verarbeitete Daten in die entsprechenden Ausgabetabellen ein.

Zeugengenerierung : Diese erste Phase findet statt, wenn ein Benutzer eine Transaktion initiiert und einen Zeugen generiert. Der Zeuge beweist die Gültigkeit der Transaktion basierend auf den Konsensregeln des Netzwerks, ohne Transaktionsdetails preiszugeben. Neue Transaktionszeugen werden stapelweise gesammelt und verarbeitet. Jeder Stapel durchläuft die folgenden Prozesse:

• GrundlegendeSchaltkreiseZeugenGenerator

• Blattaggregationszeugengenerator

• Knotenaggregation

• Planer

Vektorgenerierung : Der Vektorgenerator konsolidiert Schaltkreise, um Zeugenvektoren zu erzeugen und so die Nutzung der GPU-Rechenleistung zu optimieren.

Beweisberechnung : Die Beweiser verwenden GPUs, um die Zero-Knowledge-Beweise zu berechnen und die Richtigkeit der Beweisberechnungen zu überprüfen.

Komprimierung : Das Kompressormodul komprimiert Beweise, um die Datengröße zu reduzieren, und wandelt sie in das SNARK-Format um.

4. Fazit

ZKBase, das auf ZK Stack und Multi-GPU Prover basiert, erreicht hochleistungsfähige Layer-2-Skalierbarkeit. Die Ethereum-Skalierungslösung ZK-Rollup steht jedoch noch vor zahlreichen technischen Herausforderungen. In Zukunft wird ZKBase weiterhin die Implementierung dezentraler Sequenzierung und eines dezentralen ZK-Rechenleistungsnetzwerks erforschen und untersuchen.