> 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/verification-key.md). # Verifizierungsschlüssel Erstelle einen chainspezifischen Batch-Guest und beantrage die Registrierung seines ZisK-Verifizierungsschlüssels. Jede Chain hat ihren eigenen Batch-Guest. Der Guest enthält das Genesis und den Fee-Empfänger der Chain. Er prüft die Batch-Daten und die Ausführung und schreibt dann die öffentlichen Werte fest, die Solana Settlement überprüft. Des Guests `programVK` identifiziert das Programm, das bewiesen wird. Eine erlaubnisfreie Chain registriert sich mit einer leeren Registry für Verifikationsschlüssel. Sie kann keinen finalen Root posten, bis Rome einen Schlüssel für diese Chain hinzufügt. Die Chain-Authority kann keinen Schlüssel in ihre Registrierungs-Transaktion aufnehmen. Das ist der v0.3.0-Prozess auf dem Solana-Devnet. ## Baue den Guest Von `deploy/rollup` im v0.3.0-Checkout die Release-Einstellungen verwenden `ROME_ZK_TAG=v0.3.0`, `ROME_ZK_GUEST_TAG=v0.3.0` und `ZISK_RELEASE=1.3.1-alpha`. Ausführen `./rollup init` zuerst, damit das Genesis und die Chain-ID gerendert werden. Du musst die Chain registriert haben, bevor du die Anfrage sendest. Dann führe aus: ```sh ./rollup guest-build ``` Der Befehl baut ein Image mit der ZisK-Toolchain, klont die Rollup- und Guest-Quellen bei diesen Tags, baut den Guest aus deinem Genesis und prüft, dass er deine Chain-ID enthält. Er gibt den SHA-256 des Guest-ELF aus. Die erzeugten Metadaten speichern diesen Hash, den Genesis-Hash, die Chain-ID, die ZisK-Version und ihre Schemanummer. Für diese Version sind die letzten beiden Werte `1.3.1-alpha` und `2`. Um `programVK` lokal zu berechnen, benötigt der Build die passenden ZisK-Beweisschlüssel und etwa 36 GB RAM. Dieser Schritt dauert ungefähr 40 Sekunden. Wenn du diesen Schritt überspringst oder die Schlüssel nicht hast, meldet der Build `ProgramVkNotComputed`. Der Prover lehnt Metadaten ohne `programVK`ab; berechne sie mit den passenden Schlüsseln oder frage Rome danach, bevor du mit dem Beweisen beginnst. Zwei Maschinen, die mit diesen Tags dasselbe Genesis bauen, erhalten denselben ELF-Hash. Ein geändertes Genesis bedeutet einen anderen Guest, und das Genesis kann nach der Chain-Registrierung nicht mehr geändert werden. Der Build lehnt ein Genesis ab, dessen Chain-ID von der ID deiner Chain abweicht (`ChainIdMismatch`) und ein Genesis, das mehr als einem Konto ein Guthaben zuweist (`GenesisFundedAccountLimit`). ## Bitte Rome, es zu registrieren Verwende das [Antragsformular für Verifikationsschlüssel](https://github.com/rome-protocol/solana-zk-evm/issues/new?template=vkey-request.yml). Halte deine Chain-ID, den öffentlichen Schlüssel der Chain-Authority und die Signatur der Transaktion bereit, die die Chain registriert hat. Füge den Guest-Tag und die erzeugten Metadaten hinzu: ELF-Hash, Genesis-Hash, `programVK`, `zisk` und `Schema`. Hänge das gerenderte Genesis an oder füge es ein. Wenn Genesis ein abgesichertes Guthaben angibt, halte den passenden finanzierten Vault bereit. Füge ein `./rollup check` Ergebnis hinzu, das bis auf die auf den Schlüssel wartenden Einträge besteht. Rome baut den Guest anhand des Tags und des Genesis neu. Es prüft die Chain-ID, das Genesis, den ELF-Hash und `programVK` gegen deine Anfrage und registriert dann den Schlüssel unter der passenden ZisK-Version. Rome antwortet im Issue mit der Signatur der Transaktion zur Schlüsselregistrierung. Der Schlüssel wird ab dem erfassten Aktivierungs-Slot nutzbar; führe `./rollup check` danach aus. Mit aktiviertem Prover sollte die `Verifizierungsschlüssel` Prüfung bestehen. Auch die Prüfung des einzahlungsfähigen Schlüssels sollte bestehen. Rome registriert eine **vollständige Anfrage innerhalb von zwei Werktagen**. Wenn eine Anfrage unvollständig ist, antwortet Rome mit dem, was fehlt. Die zwei Werktage beginnen, sobald die Anfrage vollständig ist. Die zeitliche Abstimmung ist wichtig, weil das Rückforderungsfenster beginnt, wenn du die Chain registrierst, nicht wenn ihr Schlüssel aktiv wird. Das Devnet-Fenster v0.3.0 beträgt 6.480.000 Slots, etwa 30 Tage. Wenn am Ende dieses Fensters kein Root gepostet wurde, kann jeder die Chain zurückfordern und ihr 5-SOL-Deposit geht an die Treasury. Die Registry-Authority von Rome kann das globale Fenster ändern, vorbehaltlich eines Minimums von 216.000 Slots. Nach der Aktivierung gib dem Prover den passenden Guest, die Metadaten und die ZisK-Beweisschlüssel, schalte `PROVER=on`, dann führe `./rollup init`, `./rollup up` und `./rollup check`. Der Beweis muss einen für diese Chain registrierten aktiven Schlüssel verwenden. Ein späterer Wechsel zu einer anderen ZisK-Version erfordert einen weiteren Guest-Build und einen weiteren registrierten Eintrag; siehe [Versionen](/de/rome-zk-evm/releases.md). Die vollständigen Anfragefelder und Operator-Schritte sind in [Auf dem Devnet bei v0.3.0 ausführen](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.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/verification-key.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.