> 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/canton-zk-evm/prover-host.md).

# Prover-Host

Die Host-Anforderungen des Provers, der persistente Worker und der fest verdrahtete Guest-Build.

Der Prover führt ZisK mit einem GPU-Worker aus. Der Coordinator und der Worker bleiben zwischen Anfragen aktiv, wobei der PLONK-Schlüssel bereits geladen ist. Für jeden Block sendet der Builder Eingaben und erhält einen umhüllten Beweis.

Auf dieser Seite wird der Commit beschrieben `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Lesen Sie das vollständige [Prover-README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/prover/README.md) und [Messungen](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md).

## Host-Anforderungen

Das Installationsprogramm zielt auf Linux x86-64 mit `apt`, `sudo`, einem installierten NVIDIA-Treiber und etwa 100 GB freiem Speicherplatz ab. Es installiert Systempakete und ändert Limits für die Speicherverriegelung.

Der Benchmark vom 2026-10-03 verwendete eine NVIDIA RTX PRO 6000 Blackwell Server Edition mit 96 GB GPU-Speicher, 48 vCPUs auf einem AMD EPYC 9B45 und 176 GiB Host-RAM. Er lief auf Ubuntu 22.04.5 mit Treiber 580.178.04. Diese Spezifikationen beschreiben die getestete Maschine; sie legen nicht die minimale Hardware fest, die zum Ausführen des Provers erforderlich ist.

Der Benchmark erfasste 22,9 GiB gemeinsam genutzten Emulator-Speicher. Allein der PLONK-Wrap meldete einen GPU-Bedarf von 30.054.767.337 Bytes, also etwa 28,0 GiB. Die maximale GPU-Speichernutzung betrug 93,2 GiB, aber der Prover reserviert einen großen Puffer auf der Karte. Dieser Spitzenwert spiegelt die Pufferzuweisung wider und zeigt nicht, wie viel GPU-Speicher der gesamte Prover mindestens benötigt. Siehe [Messungen](/de/canton-zk-evm/measurements.md) für den Geltungsbereich jeder Zahl.

## Erstellen und ausführen

Die Skripte verwenden die Versionen in [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). Der Prover verwendet ZisK 1.3.1-alpha, Node 20.20.2 und snarkjs 0.7.6. Die Node-Version des Explorers ist separat.

| Skript                  | Was es macht                                                                                                                                           |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `prover/install.sh`     | Prüfen Sie die fest verdrahtete Prüfsumme des Installationsprogramms und installieren Sie dann den GPU-Build, den Beweisschlüssel und das PLONK-Setup. |
| `prover/build-guest.sh` | Erstellt das Guest-ELF und gibt seinen SHA-256, programVK, rootC und den Regeln-Hash aus.                                                              |
| `prover/start.sh`       | Startet den Coordinator und einen GPU-Worker mit geladenem PLONK-Schlüssel.                                                                            |
| `prover/make-input.sh`  | Wandelt einen gespeicherten Block, einen Ausführungsbeweis und Genesis in Prover-Eingaben um.                                                          |
| `prover/prove-one.sh`   | Beweist eine Eingabe, prüft den Beweis mit `cargo-zisk`und schreibt den umhüllten Beweis als Hex.                                                      |

`ZISK_COORDINATOR_URL` wählt den Coordinator aus. Standardmäßig ist das der Coordinator auf demselben Rechner. `network/up.sh` erstellt das Guest und startet den Prover als Teil des lokalen Netzwerks; folgen Sie [Lokal ausführen](/de/canton-zk-evm/run-it-locally.md) für diese Abfolge.

Der Builder verwendet standardmäßig `prover/prove-one.sh` durch `CZE_PROVE_CMD`. Dieser Befehl erhält eine Eingabedatei und einen Ausgabeordner und muss `wrapped-proof.hex`. Seine lokale `cargo-zisk` Prüfung erzwingt nicht das fest verdrahtete programVK und rootC der Kette. Die Sidecars der Confirmer erzwingen diese Vorgaben. Siehe die [Builder-Einstellungen](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#settings).

## Den Guest-Schlüssel reproduzieren

Das Build-Skript verwendet einen festen Build-Ordner und lehnt ein ELF ab, das noch einen Build-Pfad enthält. Führen Sie jeweils nur einen Guest-Build aus, da jeder Build diesen gemeinsamen Ordner leert.

Am 2026-10-04 erzeugten zwei frische Checkouts, die von einem Benutzer auf einem Rechner nacheinander gebaut wurden, dasselbe ELF und dasselbe programVK. Die Builds dauerten 133 s und 126 s. Um den Build als anderer Benutzer oder auf einem anderen Rechner zu reproduzieren, prüfen Sie, ob das resultierende programVK mit dem aufgezeichneten Wert übereinstimmt. `network/up.sh` bricht ab, wenn die Pins des Builds abweichen. Das [Guest-README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md#building) beschreibt den Build und seine Grenzen.

## Beweisausgabe

Das Wire-Format umfasst 1.344 Bytes: 768 Bytes PLONK-Beweis, 32 Bytes programVK, 32 Bytes rootC und 512 Bytes öffentliche Werte. `prove-one.sh` schreibt die Hex-Darstellung und das JSON, das von `cargo-zisk-dev export-solidity-calldata`.


---

# 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/canton-zk-evm/prover-host.md?ask=<question>&goal=<user_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.