> 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/releases.md). # Versionen Was v0.3.0 hinzufügt und wie eine Chain zwischen unterstützten ZisK-Beweisversionen wechselt. Dieser Abschnitt dokumentiert **Rome ZK EVM v0.3.0**. Verwenden Sie die passende v0.3.0-Quelle, das Node-Image und den Batch-Guest. Der Guest verwendet ZisK 1.3.1-alpha. Das Release-Tag benennt den Quellbaum, der für das Image verwendet wurde. Der `main` Branch kann sich seit dem Release geändert haben. Der [vollständiges v0.3.0-Changelog](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/CHANGELOG.md#v030) zeichnet die Befehle, Korrekturen und Einschränkungen hinter dem Release auf. Die [ZisK-Release-Richtlinie](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ZISK-RELEASES.md) beschreibt die On-Chain-Registry und den Migrationsprozess. ## In v0.3.0 Devnet-Ketten können jetzt Einzahlungen annehmen und Auszahlungen aus ihren eigenen Wrapped-SOL-Vaults zahlen. Die Kettenautorität kann eine Deposit-Queue öffnen, ihre Grenzen und Gebühren festlegen und sie nach einer verzögerten Aktivierung ändern. Der Sequencer schreibt finalisierte Solana-Einzahlungen in EVM-Blöcke gut; der Batcher schreibt ihren geordneten Bereich in den Inbox-Batch. Das Node-Image enthält einen Exit-Prover. Mit `EXITS=on`, überwacht er das Exit-Portal der Kette, beweist Auszahlungen gegen finale Solana-Roots und sendet die Vault-Freigabe selbst. Er verwendet seinen eigenen Payer. Eine kleine Auszahlung an einen Empfänger ohne Wrapped-SOL-Token-Konto wartet standardmäßig auf manuelle Freigabe. `./rollup check` meldet Exit-Konfiguration, Dienstzustand, hängende Exits und den Exit-Payer-Saldo. Beweise verwenden ZisK 1.3.1-alpha. Settlement und Veritas speichern nun pro ZisK-Release einen Verifizierungsschlüssel und eine fest verankerte Rekursionswurzel. Das Prover-Host-Setup lädt die Schlüsselarchive dieses Releases herunter und prüft sie, überprüft die GPU-Binaries und bereitet die von der Aggregation verwendeten Konstantendateien vor. Das Release fügt außerdem die Issue-Formulare für Verifizierungsschlüssel-Anfragen und Fehlerberichte hinzu. Der Devnet-Leitfaden verlinkt die Explorer-Transaktionen aus Roms eigenem Lauf, von der Registrierung bis zur Auszahlung. Dieses Release lässt alte Inbox-Batch- und Chunk-Konten weiterhin offen. Pending-Root-Konten bleiben standardmäßig offen; ihre Miete akkumuliert sich. Rome hat noch nicht entschieden, wie lange alte Batch-Daten auf Solana bleiben müssen. ## ZisK-Releases gehören zum Schlüssel jeder Kette Jede Kette hat ein Verifizierungsschlüssel-Register. Ein Eintrag enthält `programVK`, ein Public-Values-Layout, einen Aktivierungsslot und eine Scheme-Nummer. Diese Nummer benennt das ZisK-Release, das zum Bauen von Guest und Schlüssel verwendet wurde; der Beweis wählt sein Release nicht. Das Register hat vier Eintragsplätze. | Schema | ZisK-Release | Status von v0.3.0 | | ------ | ------------- | --------------------------------------------------- | | `1` | `1.2.0-alpha` | Zurückgezogen; seine Beweise werden abgelehnt. | | `2` | `1.3.1-alpha` | Offen; neue Einträge und Beweise werden akzeptiert. | Settlement sucht den aktiven Eintrag, der zu einem Beweis passt `programVK`. Der Eintrag wählt den Veritas-Schlüssel und die fest verankerte Rekursionswurzel dieses Releases aus. Ein Beweis mit der falschen Wurzel wird vor den Public-Values- und Paarungsprüfungen abgelehnt. Ein zurückgezogenes Release hat im Produktions-Build keinen Verifizierungsschlüssel. ## Eine Kette auf ein neues Release migrieren Installieren Sie die neue ZisK-Toolchain und die Proving-Keys, während die alte Installation verfügbar bleibt. Setzen Sie das Rollup-Source-Tag, das Guest-Tag und das ZisK-Release gemeinsam, und führen Sie dann `./rollup guest-build` um einen neuen Guest zu bauen und `programVK` für dieselbe Genesis. Der Prover benötigt die passende ZisK-Installation, den Guest und die Verifizierungsmetadaten. Senden Sie Rome die Genesis der Kette, das Guest-Tag, den ELF-Hash und `programVK`. Rome baut den Guest neu und prüft ihn und registriert den neuen Schlüssel mit einem zukünftigen Aktivierungsslot. Wenn die Kette bereits eine Wurzel gepostet hat, benötigt Rome auch den vorherigen Guest und das vorherige Release. Prüfen Sie den neuen On-Chain-Eintrag und den Aktivierungsslot und schalten Sie dann den Prover um, wenn dieser Slot erreicht wird. Rome zieht den alten Eintrag nach dem Umschalten zurück. Ein zukünftiger Eintrag kann nicht vorzeitig verifizieren. Roms Support-Richtlinie hält höchstens zwei ZisK-Releases gleichzeitig offen. Ein schließendes Release akzeptiert keine neuen Einträge, aber bestehende Einträge können weiter verifizieren, während Ketten migrieren. Wenn Rome ankündigt, dass ein Release geschlossen wird, haben Ketten auf Devnet und Testnet 30 Tage Zeit zum Migrieren. Dieses Zeitfenster ist Roms Support-Richtlinie, kein On-Chain-Timer. Rome kann Einträge aus Sicherheitsgründen sofort zurückziehen. Ein zurückgezogenes Release akzeptiert weder neue Einträge noch Beweise, daher braucht eine Kette, die noch auf 1.2.0-alpha ist, einen aktiven 1.3.1-alpha-Eintrag, bevor sie eine weitere Wurzel posten kann. --- # 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/releases.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.