> 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/how-it-works.md). # So funktioniert es Verfolge einen Ostia-Block von reth über das Proving bis zu seinem Canton-Commit. Jeder Builder-Lauf erstellt, beweist und übermittelt einen Block. Canton entscheidet, ob dieser Block der nächste Head der Chain wird. Ein EVM-Block und die von Canton protokollierten Legs werden in derselben Transaktion festgeschrieben. Auf dieser Seite wird der Commit beschrieben `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Lesen Sie das vollständige [Design](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md). ```mermaid flowchart TD W["EVM-Transaktionen"] --> R["reth baut auf Anfrage"] R --> B["Builder liest Gateway-Legs und findet deren Canton-Verträge"] B -->|"Ein Leg kann nicht abgewickelt werden: lass seine Transaktion weg und baue neu"| R B -->|"Jedes Leg kann abgewickelt werden"| P["ZisK beweist den Block"] P --> A["Fortfahren: Block, Beweis und Legs in einer Canton-Transaktion"] A --> S["Externer Aufruf: Sidecars prüfen den Beweis und den Gateway-Zustand"] S --> D["Daml prüft den Head und wickelt die Legs ab"] D --> C["Canton schreibt den Block und seine Legs gemeinsam fest"] C --> F["reth markiert den Block als final"] ``` ## Auf Cantons Head bauen Wallets senden EVM-Transaktionen an reth. Der bereitgestellte Launcher hält Peer-Discovery deaktiviert. reth erstellt einen Block, wenn der Builder einen anfordert. Der Builder liest zuerst den aktiven `ZkChain` Vertrag auf Canton. Er verschiebt reths Head, Safe-Block und finalisierten Block auf diesen festgeschriebenen Head. Er wählt ausstehende Transaktionen nach Preis aus, behält für jeden Sender die Nonce-Reihenfolge bei und bleibt innerhalb der Gasobergrenze. Er fordert reth auf, mit dieser expliziten Transaktionsliste zu bauen. Eine EVM-Transaktion, die eine Canton-Aktion erfordert, ruft das Gateway auf. Das Gateway protokolliert ein Leg und faltet es in einen laufenden Hash für den Block ein. Der Builder liest die Ereignisse des Gateways in Protokollreihenfolge und findet die Canton-Verträge, die jedes Leg benötigt. Wenn eine Zuweisung weg ist, ein Empfänger Abhebungen nicht akzeptiert hat oder ein anderer erforderlicher Vertrag fehlt, lässt der Builder die Transaktion und die späteren Transaktionen dieses Senders weg. Er setzt reth auf Cantons Head zurück und baut erneut. Diese Prüfungen erfolgen vor dem Beweisen. Der [Builder-README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md) listet die Prüfungen für jedes Leg auf. ## Block beweisen Der Builder speichert den Block und reths Ausführungszeugnis. Das Eingabetool kombiniert Block, Zeugnis und Genesis zu den Prover-Eingaben. ZisK führt den Gast aus, der den Block nach den festen Regeln der Chain validiert. Der Prover liefert einen 1.344-Byte-wrapped Beweis zurück, der sich auf den Block-Hash festlegt. Der Builder übermittelt `Vorschuss` mit dem Header, den Transaktionen, dem Beweis, den Legs und den Konto- und Speicherbeweisen des Gateways an der Zustandswurzel des Blocks. ## Prüfen und abwickeln in einer Transaktion Jeder bestätigende Teilnehmer betreibt einen Sidecar. Cantons externer Aufruf sendet den Block an den Sidecar dieses Teilnehmers zur `verifizieren`. Sie prüft den Beweis, den festgepinnten Programmschlüssel und die ZisK-Version, den Hash des Headers und die Wurzel der Transaktionsliste. Daml prüft die Antwort gegen `ZkChain`: Der Parent muss der aktuelle Head sein, die Nummer muss die nächste sein, und das Gaslimit und das verbrauchte Gas müssen innerhalb der Obergrenze liegen. Daml vergleicht die Antworten des Sidecars; es verifiziert den Zero-Knowledge-Beweis selbst nicht. Daml schreibt dann für jedes Leg einen Eintrag aus den Canton-Verträgen, die es nennt. Die ID, der Burner und der Betrag einer Auszahlung stammen vom Builder; der bewiesene Hash bindet sie an das, was der Block aufgezeichnet hat. Die `Teile` Funktion prüft die Konto- und Speicherbeweise des Gateways, hasht diese Zeilen in Reihenfolge und vergleicht das Ergebnis mit dem Wert des Gateways im bewiesenen Zustand. Ein Block ohne Legs muss dieselbe Prüfung mit einer leeren Liste bestehen. Daml wickelt die Legs der Reihe nach ab und erstellt die `BlockRecord` und den nächsten `ZkChain`. Canton schreibt diese Änderungen gemeinsam fest. Wenn eine Prüfung oder Abwicklung fehlschlägt, wird nichts festgeschrieben. Der Verbrauch des einen State Contracts der Chain macht Canton zur Autorität über die Blockreihenfolge. Siehe die vollständigen [Daml-Schnittstelle](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) und [Sidecar-Prüfungen](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md). ## Wenn Canton ablehnt Nachdem Canton den Block festgeschrieben hat, markiert der Builder ihn in reth als final. Wenn Canton ihn ablehnt, setzt der Builder reth auf Cantons zuletzt festgeschriebenen Block zurück und sendet die Transaktionen des abgelehnten Blocks zurück in den Pool. Der nächste Lauf prüft deren Legs erneut. Eine Zahlung, deren Zuweisung zurückgenommen wurde, wird ausgelassen. Wenn der Builder die Antwort auf die Übermittlung verliert, liest er Cantons Head erneut, um festzustellen, ob der Block festgeschrieben wurde. Wenn auch dieser Lesevorgang fehlschlägt, meldet er ein unbekanntes Ergebnis und lässt reth, wo es ist. Der nächste Lauf startet von Cantons Head. Diese Wiederherstellungsregeln sind in der [Builder-README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#what-one-run-does). --- # 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/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.