> 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/run-a-rollup.md).

# Ein Rollup ausführen

Registriere und betreibe deine eigene Rome-ZK-EVM-Chain auf dem Solana-Devnet mit dem Rollup-Runner v0.3.0.

Der `./rollup` Der Runner startet eine Chain gegen Roms gemeinsame Solana-Devnet-Programme. Du betreibst seinen Knoten und zahlst seine Solana-Kosten. Du stellst die Settlement-Programme nicht selbst bereit. Die Registrierung ist permissionless, aber bewiesene Roots benötigen einen ketten­spezifischen Verifizierungsschlüssel, der von Rome registriert wurde.

Diese Seite verwendet **v0.3.0**. Die [vollständige Devnet-Anleitung](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) deckt jede Einstellung sowie jeden Fehler- und Wiederherstellungsschritt ab.

## Bevor du beginnst

Verwende einen x86-64-Linux-Rechner mit bash 4 oder neuer, Git, Docker Engine 28 oder neuer mit Compose, curl, jq, openssl, der Solana CLI und Python 3.11 oder neuer. Du benötigst einen Solana-Devnet-RPC-Endpunkt, ein aufgeladenes Solana-Payer-Keypair, das zugleich deine Chain-Autorität ist, und einen Signaturschlüssel für den Sequencer. Halte beide Dateien privat und für den Container-Benutzer 999 lesbar. Die Anleitung erklärt, wie du sie erstellst.

Plane etwa **7 SOL im Devnet** für den Zahler. Die Registrierung bindet 5 SOL; `./rollup check` es werden mindestens 1 SOL für das Posten und die Miete erwartet. Die Einzahlung wird nach dem ersten finalen Root oder zehn geposteten Roots erstattbar. Wenn die Chain vorher zurückgefordert wird, geht die Einzahlung an die Schatzkammer. Die Chain benötigt außerdem eine EVM-Fee-Recipient-Adresse, die du kontrollierst.

Um Roots zu finalisieren, brauchst du einen Prover-Host mit einer NVIDIA-GPU mit mehr als 30 GB Speicher. Eine 24-GB-Karte ist für den finalen Beweisschritt zu klein. [Prover-Host](/de/rome-zk-evm/prover-host.md) gibt das RAM- und Festplattenbudget vor. Der Knoten kann vor der Bereitschaft des Provers laufen und Batches veröffentlichen, aber keiner seiner Roots wird final sein.

## Starte den Knoten

Klone das Release und arbeite aus seinem Rollup-Verzeichnis:

```sh
git clone --branch v0.3.0 https://github.com/rome-protocol/solana-zk-evm.git
cd solana-zk-evm/deploy/rollup
cp .env.example .env
cp chain.toml.example chain.toml
```

Setze den Solana-RPC, die Speicherorte der Signierer und `ROME_ZK_TAG=v0.3.0` in `.env`. Behalte `PROGRAMS_JSON=programs.devnet.json`. Setze `ROME_ZK_GUEST_TAG=v0.3.0` und `ZISK_RELEASE=1.3.1-alpha` für den späteren Guest-Build. Halte den RPC für einen lokalen ersten Lauf an Loopback gebunden. Lass `PROVER` nicht gesetzt, bis der Guest und sein Schlüssel bereit sind.

Setze `genesis.fee_recipient` in `chain.toml` zu deiner EVM-Adresse. Wähle keine Chain-ID. Das Settlement leitet eine aus dem Zahler und seiner Registrierungsanzahl ab; `init` liest sie, bevor irgendetwas gesendet wird. Etwa die Hälfte aller IDs ist für MetaMask zu groß. Wenn deine dazugehört, `init` bricht ab mit `ChainIdNotWalletSafe`; erstelle einen neuen Payer-Schlüssel, verweise `PAYER_KEYPAIR_PATH` darauf und führe `init` erneut aus.

Eine neue Chain startet mit Nullguthaben. Wenn du ein gedecktes Guthaben deklarierst, um vor dem Öffnen der Einzahlungen Gas zu erhalten, sperre denselben Betrag an Wrapped SOL im Vault der Chain, bevor du den Verifizierungsschlüssel anforderst.

```sh
./rollup init
./rollup register --dry-run
./rollup register --confirm
./rollup up
./rollup check
```

`init` rendert die Genesis- und Service-Konfiguration. `register --confirm` bindet die 5-SOL-Einzahlung und erstellt den Batch-Cursor. `up` startet den Sequencer-, Batcher-, Derive- und Verifier-Knoten. `check` benennt jeden fehlenden Dienst und vergleicht dann die Chain-ID, die Heads, den Fortschritt des Batchers, die Inbox und die Roots. Führe es nach etwas Zeit zum Schließen der Batches erneut aus; seine erste Prüfung des Batch-Fortschritts erfasst nur eine Stichprobe.

Ohne einen Prover stellt der Sequencer RPC bereit, der Batcher sendet Transaktionsdaten an die Inbox, und Derive rekonstruiert die Chain. Ein Inbox-Batch ist kein finaler Settlement-Root. Selbst der Genesis-Root wartet auf einen Beweis.

## Wechsle von Batches zu finalen Roots

Baue den Guest für die Genesis deiner Chain:

```sh
./rollup guest-build
```

Der Build verwendet den Guest v0.3.0 und ZisK 1.3.1-alpha. Er erzeugt das Guest-Programm der Chain und die Metadaten des Verifizierungsschlüssels. Das Berechnen `programVK` erfordert die ZisK-Beweisschlüssel und etwa 36 GB RAM. Die Registrierung der Chain registriert keinen Verifizierungsschlüssel. Sende die [Verifizierungsschlüssel-Anfrage](/de/rome-zk-evm/verification-key.md) nach dem Build. Rome prüft deine Genesis und deinen Guest und registriert dann den Schlüssel mit einem Aktivierungsslot.

Setze auf dem Prover-Host `PROVER=on` sowie den Guest, die Verifizierungsmetadaten und die im vollständigen Runbook beschriebenen ZisK-Einstellungen. Nachdem der Schlüssel aktiv ist:

```sh
./rollup init
./rollup up
./rollup check
```

Prüfe, dass der `Dienst Prover` und `Verifizierungsschlüssel` Punkte bestehen. Der Prover arbeitet die Inbox-Batches der Reihe nach ab. Jeder gültige Beweis veröffentlicht einen Root, der sofort final ist, sobald seine Solana-Transaktion landet.

## Erzeuge den ersten Block

Ohne gedecktes Genesis-Guthaben hat die Chain kein Gas für eine Transaktion, bis Einzahlungen geöffnet werden. Einzahlungen benötigen einen ersten bewiesenen Root. Der Standard `empty_block_interval_secs = 0` lässt eine inaktive Chain ohne Blöcke, also setze es auf `60` unter `[profile]` in `chain.toml` nachdem der Schlüssel aktiv ist und der Prover läuft. Rendere und starte neu:

```sh
./rollup init
./rollup up
./rollup check
```

Sobald der erste Root final ist, setze das Intervall wieder auf `0` und führe erneut aus `init` und `up` es sei denn, du willst regelmäßige leere Blöcke. Wenn du sie einschaltest, während du darauf wartest, dass Rome den Schlüssel registriert, entsteht ein Rückstau. Jeder Batch muss der Reihe nach bewiesen werden.

Bei einem 60-Sekunden-Intervall für leere Blöcke und einem 60-Sekunden-Batch-Abschluss erzeugt die Chain etwa einen Batch pro Minute, also ungefähr 1.440 pro Tag. Im Devnet kostete ein bewiesener Root den Zahler etwa **0,003 SOL**: etwa 0,002 SOL für ausstehende Konten-Miete, die 0,001 SOL Settlement-Gebühr und zusätzlich eine Transaktionsgebühr. Bei diesem Rhythmus sind das vor Inbox-Postenkosten etwa 4,4 SOL pro Tag. Die Miete für ausstehende Konten bleibt mit den Standardeinstellungen gesperrt. Mit ausgeschalteten leeren Blöcken versiegelt eine inaktive Chain keine Batches und zahlt keine Postenkosten.

Um Einzahlungen anzunehmen, erstelle als Nächstes den Vault, aktiviere die Exit-Konfiguration nach ihrer Verzögerung und öffne eine Einzahlungswarteschlange. Diese Befehle und die Prüfungen findest du in [Einzahlungen und Auszahlungen](/de/rome-zk-evm/deposits-and-withdrawals.md).


---

# 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/run-a-rollup.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.