> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/de/rome-zk-evm/prover-host.md). # Prover-Host Dimensioniere und bereite den GPU-Host vor, der Rome ZK EVM-Batches mit ZisK 1.3.1-alpha beweist. Der Node kann Transaktionen sequenzieren und Batches ohne GPU posten. Er benötigt einen Prover, um jeden Root auf Solana zu finalisieren. In v0.3.0 läuft der Prover mit ZisK 1.3.1-alpha und dem Guest, der für den Genesis-Zustand Ihrer Chain gebaut wurde. Er beweist Inbox-Batches nacheinander, prüft jeden Beweis lokal und postet ihn dann an Settlement. Der [vollständige Prover-Host-Anleitung](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/PROVER-HOST.md) enthält die Einrichtungs- und Wiederherstellungsschritte. Verwenden Sie sie zusammen mit dem [Devnet-Runbook](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md). ## Dimensionieren Sie den Host Verwenden Sie x86-64 Ubuntu 22.04 oder neuer und eine NVIDIA-GPU mit mehr als 30 GB Speicher. Das Setup-Skript akzeptiert eine GPU mit etwa 32,2 GB oder mehr. Der letzte Beweisschritt benötigt etwa 30 GB, daher ist eine 24-GB-Karte zu klein. Der NVIDIA-Treiber muss mindestens Version 525.60.13 haben. Planen Sie mindestens **128 GB RAM** und **125 GB freien Speicherplatz** am ZisK-Installationsort ein. Das 1.3.1-alpha-Proving-Key-Archiv ist 5,1 GB groß und das PLONK-Key-Archiv 21,9 GB. Nachdem das Setup seine Konstantdateien erzeugt hatte, belegten die beiden Schlüsselverzeichnisse 21 GiB und 26 GiB. Der erste Beweis fügt Cache-Dateien hinzu. Ein CPU-Host belegte nach einem Beweis insgesamt 102,1 GB, und das Wachstum des GPU-Caches wurde nicht gemessen. Die 1.3.1-alpha-Beweisbibliothek meldete 24,7 GB für ihren Hauptarbeitsbuffer und 5,6 GB für die Rekursion bei einem Batch von etwa 3 Millionen Schritten. Der Spitzenwert des Gesamtprozesses wurde in dieser Version nicht aufgezeichnet. Der Devnet-GPU-Lauf verwendete einen Host mit 176 GB RAM; auch sein maximaler RAM-Verbrauch wurde nicht aufgezeichnet. Verwenden Sie 128 GB als Schätzwert für die Dimensionierung, nicht als gemessenen Spitzenwert. ## Was gemessen wurde Ein nahezu leerer Batch dauerte etwa **17 Sekunden**, einschließlich des PLONK-Wraps, auf einem Host mit einer **96 GB RTX PRO 6000**, 48 CPU-Kernen und 176 GB RAM. Etwa 95 GB GPU-Speicher wurden als belegt angezeigt. Das ist der Verbrauch dieses Laufs, nicht der minimale GPU-Speicher für jeden Batch. Größere Batches wurden auf einer GPU noch nicht gemessen. Rome hat auf dieser GPU 116 nahezu leere Devnet-Batches in etwa 35 Minuten abgearbeitet. Das ist wichtig, wenn eine Chain leere Blöcke erzeugt hat, während sie auf ihren Verifizierungsschlüssel wartet: Der Prover muss sie der Reihe nach abarbeiten, bevor er den neueren Zustand erreichen kann. ## Führen Sie das Setup-Skript aus Installieren Sie den NVIDIA-Treiber und starten Sie bei Bedarf neu. Führen Sie vom Repository-Stammverzeichnis aus das Skript der Release als root aus. Setzen Sie `ZISK_HOME` auf das Verzeichnis, in dem ZisK und seine Schlüssel abgelegt werden. Verwenden Sie denselben Wert in Ihrer Rollup-Konfiguration `.env`: ```sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh --check ``` Das Skript installiert den ZisK-GPU-Build, seine Beweis- und PLONK-Schlüssel, die benötigten Systembibliotheken und Dockers NVIDIA-Runtime. Es setzt das Limit für gesperrten Speicher auf unbegrenzt. Melden Sie sich ab und wieder an, damit dieses Limit für Ihre Shell gilt. Anschließend prüft es die GPU und den Treiber, installierte Binärdateien, Schlüssel, Speicherlimit und Container-Runtime. Bevor der Installer ausgeführt wird, prüft es die SHA-256 des Installers. Es prüft beide Schlüsselarchive, bevor eines von beiden entpackt wird, und prüft die installierten `cargo-zisk` und `cargo-zisk-dev` GPU-Binärdateien, bevor das Skript sie ausführt. Es erzeugt die Konstantdateien, die für Aggregation und PLONK-Beweisführung benötigt werden. Wenn ein Lauf fehlschlägt, führen Sie das Skript erneut aus. Der Schlüsseldownload wird übersprungen, wenn die installierten Schlüssel bereits mit dem festgelegten Manifest übereinstimmen. Das Skript prüft nicht jeden Teil der ZisK-Installation. Der Installer lädt ein Binärpaket herunter und führt dessen Toolchain-Installer aus, bevor das Skript die beiden installierten GPU-Binärdateien prüft. Andere ausführbare Dateien und Quelldateien in diesem Paket werden von diesem Skript nicht per Hash überprüft. Die vollständige Anleitung beschreibt diese Einschränkung und enthält die Befehle, um jeden Download separat zu prüfen. ## Verbinden Sie es mit Ihrer Chain Der Prover benötigt das passende Guest-ELF, seine Verifikationsmetadaten und dieselben 1.3.1-alpha-Beweisschlüssel. Setzen Sie `PROVER=on` und die Guest- und ZisK-Einstellungen in der Rollup-Konfiguration, dann ausführen `./rollup init` und `./rollup up`. Der erste Lauf baut das Prover-Image aus dem Quellcode von v0.3.0. Das Node-Image allein enthält den Prover nicht. Vor jedem Start prüft der Prover die installierten Beweisschlüssel gegen das festgelegte SHA-256-Manifest. Diese Prüfung umfasst Dateinamen und Inhalte. Erzeugte Konstantenbaum- und GPU-Konstantendateien sind ausgeschlossen, da sie je nach Host unterschiedlich sind. Eine Abweichung beendet den Prover mit `KeysShaMismatch`. Ändern Sie das Manifest nicht einfach, um eine abweichende Installation zum Starten zu bringen; installieren Sie die Release, die zum Guest der Chain und zum registrierten Schlüssel passt. Führe `./rollup check` nach dem Start. Es prüft den Prover-Dienst, den aktiven Verifizierungsschlüssel sowie die Verzögerung von Settlement und Prover. Die [Überwachungsanleitung](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/MONITORING.md) listet die lokalen Metriken und nützliche Alarmbedingungen auf. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rome.builders/de/rome-zk-evm/prover-host.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.