> 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/run-it-locally.md).

# Lokal ausführen

Führe die Checks, die Probe ohne GPU und die lokale Ostia-Demo auf einer GPU aus.

Die bereitgestellten Skripte führen ein lokales Testnetz aus. Canton speichert seinen Zustand im Speicher, daher verwirft jeder Neustart diesen Zustand und erstellt ein neues Netzwerk. Die GPU-Demo beweist Blöcke. Die Probe verwendet einen Platzhalter-Beweis und benötigt keine GPU.

Auf dieser Seite wird der Commit beschrieben `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Lesen Sie das vollständige [Netzwerkleitfaden](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/network/README.md) und [Demo-Leitfaden](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md). Führen Sie die folgenden Befehle vom `canton-zk-evm` Repository-Stammverzeichnis aus.

## Was Sie benötigen

| Arbeit                   | Anforderungen                                                                                                                    |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- |
| Repository-Prüfungen     | Docker, `bash`, `curl`, `jq`, `openssl` und Python 3. Rust-Tests verwenden `rust-toolchain.toml`.                                |
| Canton-Integrationstests | Linux x86-64, Java 21 und Netzwerkzugang.                                                                                        |
| Demo-Probe               | Linux x86-64, Docker, Java 21, Rust und Python 3.12 oder neuer.                                                                  |
| Explorer-Tests           | Node 22.18 oder neuer.                                                                                                           |
| GPU-Netzwerk und Demo    | Linux x86-64, eine NVIDIA-GPU mit installiertem Treiber, Docker, Rust, Python 3.12 oder neuer, `jq`, `curl`, `openssl` und ZisK. |

Der [README des Repositorys](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/README.md#running-the-tests) listet die Testvoraussetzungen auf. Das GPU-Installationsprogramm verwendet `sudo` und `apt` unter Debian oder Ubuntu und benötigt etwa 100 GB freien Speicherplatz. Es installiert Systempakete und ändert die Speicher-Lock-Limits. Der Tool-Fetcher des Netzwerks installiert Java 21, falls es fehlt. Siehe [Prover-Host](/de/canton-zk-evm/prover-host.md) für die getestete Hardware; die minimale GPU-Speichergröße wurde noch nicht festgelegt.

## Führen Sie die Tests aus

Beginnen Sie mit den Schnellprüfungen aus [CONTRIBUTING.md](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/CONTRIBUTING.md#building-and-testing):

```sh
tests/static.sh                  # Pins, Genesis und Lizenzzeilen stimmen überein
tests/refuses_missing_flag.sh    # das reth-Startskript verweigert ein fehlendes oder falsches Flag
tests/fixtures.sh                # der aufgezeichnete Beweis ist konsistent
gateway/build.sh --check         # der eingecheckte Gateway-Code ist das, was Gateway.sol kompiliert (Docker)
```

Die README-Datei des Repositorys gibt diese Prüfungen ebenfalls an. Sie benötigen keine GPU:

```sh
tests/udp_control.sh             # die UDP-Prüfung schlägt in einem Container mit einem UDP-Listener fehl (kein reth)
tests/discovery.sh               # startet das gepinnte reth, prüft, dass es keine Peers hat, und stoppt es
tests/network_static.sh          # reth nur über launch.sh, die Canton-Konfiguration, das aufgezeichnete Smoke-Ergebnis
tests/network_checks.sh          # die Prüfung des Compiler-Pins, die ID des DAR, der Stopp auf ein anderes ProgrammVK (keine GPU)
tests/canton_network.sh          # das gepinnte Canton, das echte Daml-Paket und ein Advance (Linux x86-64, Java 21, Python 3; keine GPU)
gateway/tests/run.sh             # das Gateway auf einem echten reth, gestartet mit deaktivierter Peer-Erkennung (Docker, curl, jq, Python 3 mit den Paketen aus demo/requirements.txt)
tests/guest-repro.sh             # der Gast-Build läuft in einem fest vorgegebenen Ordner, sodass der Quellordner das ELF nicht verändert (Platzhalter für die ZisK-Tools; die gleiche Prüfung auf echtem ZisK wurde am 2026-10-04 bestanden, siehe guest/README.md)
tests/demo_static.sh             # die Pins der Demo, der Tamper-Schalter und die Genesis-Überschreibung sowie ihre aufgezeichneten Ergebnisse (keine GPU)
tests/demo_explorer_static.sh    # die Images des Explorers sind gepinnt, und was seinem Container übergeben wird (kein Docker)
(cd explorer && npm ci && npm test)  # die Tests des Explorers gegen Fakes (Node 22.18+; CI verwendet EXPLORER_NODE_IMAGE in PINS)
(cd guest/rules && cargo test)   # die Chain-Regeln und ihr Hash (benötigt Rust)
```

## Ohne GPU probeweise ausführen

```sh
tests/demo_rehearsal.sh          # die Demo und der Explorer mit einem Platzhalter-Beweis (Linux x86-64, Docker, Java 21, Rust, Python 3.12+; keine GPU)
```

Dies führt das echte reth, Canton, das Daml-Paket, den Token-Standard und den Builder aus. Das Sidecar prüft die Beine des Gateways anhand von Speicherbeweisen, während ein Platzhalter die `verifizieren` Aufruf beantwortet. Die Probe beweist weder einen Block noch verifiziert sie einen echten Zero-Knowledge-Beweis.

Es prüft auch den Explorer und den Faucet. Die Verify-Prüfung des Explorers muss den Platzhalter-Beweis zurückweisen. Die [README der Demo](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#the-rehearsal) beschreibt den Umfang der Probe.

## Das lokale Netzwerk auf einer GPU starten

Installieren Sie ZisK mit `prover/install.sh` vor dem Start des Netzwerks. Starten Sie reth immer über den bereitgestellten Starter; `network/up.sh` verwendet es.

```sh
network/up.sh       # Tools, Gast-Build, reth, Sidecars, Prover, Canton, die Chain
CZE_SOURCE_COMMIT=$(git rev-parse HEAD) network/smoke.sh    # ein leerer Block, bewiesen und bestätigt
network/down.sh
```

`up.sh` baut den Gast und verweigert einen Programmschlüssel, einen ZisK-Root oder einen Regel-Hash, der von den aufgezeichneten Werten abweicht. Das Netzwerk hat einen Synchronizer und drei Teilnehmer. Die Operator- und Confirmer-Teilnehmer betreiben jeweils ein Sidecar. Der Teilnehmer namens users beherbergt die Testparteien und den Reader.

Der Smoke-Test bestätigt einen leeren Block, prüft die Spitze der Chain und den Blockeintrag des Readers und prüft, dass reth ihn als endgültig markiert hat. Zustand und Protokolle werden gespeichert unter `state/`oder `CZE_STATE_DIR` wenn gesetzt.

## Führen Sie die fünf Demo-Fälle auf einer GPU aus

Verwenden Sie für die Demo ein neues lokales Netzwerk:

```sh
demo/prepare.sh
CZE_GENESIS_FILE=$PWD/state/demo/genesis.json network/up.sh
CZE_SOURCE_COMMIT=$(git rev-parse HEAD) network/smoke.sh      # optional: zuerst ein leerer Block
CZE_SOURCE_COMMIT=$(git rev-parse HEAD) demo/run.sh
network/down.sh
```

Das Vorbereitungsskript erstellt Testschlüssel und eine mit Mitteln ausgestattete Genesis für den Lauf. Die Demo führt ihren Setup-Block, die Einzahlung, die Zahlung, die Auszahlung, die Zuteilungsverweigerung und die Verweigerung eines manipulierten Beweises aus. Das Skript bricht ab, wenn eine Prüfung fehlschlägt, und schreibt seine Ergebnisse nach `demo/results/`.

Für einen Quell-Export ohne `.git`, setzen Sie `CZE_SOURCE_COMMIT` auf den vollständigen Hash des für den Export verwendeten Commits. Um den Faucet einzuschließen, muss seine mit Mitteln ausgestattete Genesis vor dem Start des Netzwerks vorbereitet werden; siehe [Explorer](/de/canton-zk-evm/explorer.md) und den vollständigen Demo-Leitfaden.


---

# 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/run-it-locally.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.