> 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/how-it-works.md). # So funktioniert es Verfolge einen EVM-Block durch das Posten von Daten auf Solana, ZisK-Beweisführung und die endgültige Abwicklung. Ihr Sequencer akzeptiert EVM-Transaktionen über JSON-RPC. Er prüft die Signatur, den Nonce, die Mittel und das Gas und führt dann akzeptierte Transaktionen in der Reihenfolge ihres Eingangs aus. Er schreibt signierte Teilblöcke und deren Transaktionen in ein dauerhaftes geordnetes Log, bevor er eine Vorbestätigung zurückgibt. Der Sequencer bettet reth ein, um die Blöcke der Chain zu erzeugen. Eine Vorbestätigung sagt Ihnen, was der Sequencer akzeptiert und geordnet hat. Sie ist keine endgültige Solana-Root. Der Rest des Pfads veröffentlicht die Daten und beweist, dass ihre Ausführung den behaupteten Zustand ergibt. ``` EVM-Transaktion -> Sequencer -> geordnetes Log -> Batcher -> Solana-Inbox Solana-Inbox -> derive -> reth-verifier -> Blöcke + Zeugen Blöcke + Zeugen -> Prover (ZisK batch guest) -> Beweis + Root Beweis + Root -> Solana-Settlement (PostRootProved) -> endgültige Root ``` ## Von Blöcken zu einem Inbox-Batch Der Batcher liest aufeinanderfolgende Blöcke aus dem geordneten Log. Das Beispiel `chain.toml` schließt einen Batch bei 60 Blöcken oder 60 Sekunden nach seinem ersten Block, je nachdem, was zuerst eintritt. Er komprimiert den Batch in Frames, postet die Frames als Inbox-Chunks auf Solana und finalisiert dann das Merkle-Commitment des Batches. Das Inbox-Commitment umfasst die Chain- und Batch-IDs, den Öffnungsslot, die Anzahl der Chunks, die Merkle-Root der Chunks und den Deposit-Bereich des Batches. Das Finalisieren eines Inbox-Batches bedeutet, dass seine Daten veröffentlicht wurden. Dadurch wird seine State-Root nicht final. Die Chain-Authority signiert die Batch-Finalisierung. Der Batcher kann keine Blocknummer überspringen. Das Settlement nimmt ebenfalls den nächsten Batch in der Reihenfolge. Deshalb blockiert ein steckengebliebener oder aufgegebener Batch spätere Roots. Der Batcher setzt einen teilweise geschriebenen Batch nach einem Neustart unter derselben Nummer fort, wenn er ihn rekonstruieren kann. ## Ableiten, verifizieren und beweisen `ableiten` liest finalisierte Inbox-Batches von Solana. Es rekonstruiert die Blöcke und steuert einen separaten `reth-verifier` Knoten, um sie erneut auszuführen. Dieser Knoten liefert die Ausführungszeugen, die der Batch-Prover benötigt, und die Zustandsbeweise, die der Exit-Prover benötigt. Er verwendet reths Test-API, daher muss er vom öffentlichen Netzwerk fernbleiben. Der Prover liest jeden finalisierten Inbox-Batch, erhält Blöcke und Zeugen vom Verifier-Knoten und führt den Batch-Guest der Chain in ZisK aus. Der Guest prüft, dass die Blöcke mit den Inbox-Daten übereinstimmen und korrekt ausgeführt werden. Er schreibt die öffentlichen Werte des Batches fest, einschließlich der resultierenden State-Root. Ihr Genesis und Ihr Gebührenempfänger werden in diesen Guest kompiliert, sodass jede Chain ihren eigenen Guest und `programVK`. Der Prover überprüft den Beweis lokal und sendet dann `PostRootProved`. Das Settlement-Programm prüft den für diese Chain registrierten aktiven Verifizierungsschlüssel und die von diesem Schlüssel benannte ZisK-Version. Es prüft außerdem die öffentlichen Werte des Beweises gegen die Chain-ID, den Blockbereich, den Vorgänger, das Inbox-Commitment und die behauptete Root. Veritas ist Rome's Verifier für ZisK-PLONK-Beweise. Das Settlement bindet seinen Verifier-Code ein und führt ihn innerhalb von `PostRootProved`; es ruft nicht das separat bereitgestellte Veritas-Programm auf. Ein gültiger Beweis schreibt eine `Final` Root und verschiebt den Finalitäts-Head in derselben Solana-Transaktion vor. Die Genesis-Root einer permissionless Chain ist für sich genommen nicht final. Ihre erste finale Root benötigt einen bewiesenen Batch. ## Mittel, die die Grenze überschreiten Eine Einzahlung beginnt auf Solana. Das Bridge-Programm verschiebt den eingezahlten Token vom Einzahler in das Vault dieser Chain und hängt einen nummerierten Einzahlungsdatensatz an. Der Sequencer liest finalisierte Solana-Einzahlungen und schreibt die genannte EVM-Adresse der Reihe nach gut. Der Batcher bindet den Einzahlungsbereich mit dem Batch ein. Das Guthaben erscheint auf der Chain, wenn ihr Block versiegelt wird, aber seine Gutschrift ist erst dann endgültig, wenn die Root dieses Batches auf Solana bewiesen wurde. Eine Auszahlung beginnt auf der Chain an ihrem Exit-Portal. Das Portal zeichnet eine Nachricht auf und verbrennt das native Asset. Der Exit-Prover wartet auf diese Nachricht und beschafft sich einen Ethereum-Storage-Beweis vom Verifier-Knoten gegen eine finale Root. Er überprüft diesen Beweis lokal und sendet dann `ProveExit` an das Solana-Settlement. Das Settlement prüft das Portal, die Nachricht, die finale Root und das Exit-Limit und verhindert, dass derselbe Exit zweimal bewiesen wird. Der Exit-Prover sendet dann die Freigabe-Transaktion der Bridge. Die Bridge verbraucht den bewiesenen Exit und zahlt den Empfänger aus dem Vault dieser Chain in einer atomaren Transaktion aus. Der Empfänger stammt aus dem bewiesenen Datensatz, daher kann die Person, die die Freigabe sendet, ihn nicht ändern. Lesen Sie die vollständige [v0.3.0-Architektur](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ARCHITECTURE.md) für Drahtformate, Komponentengrenzen und die Prüfungen jeder Anweisung. --- # 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/how-it-works.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.