> 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/trust-model.md).

# Vertrauensmodell und Grenzen

Die Checks, Zuständigkeiten, Verwahrungsannahmen und Grenzen der frühen Ostia-Version.

Ostia ist eine frühe Veröffentlichung auf einem lokalen Testnetzwerk. Es hat einen Builder, einen Operator und einen Confirmer. Der Code und ZisK 1.3.1-alpha wurden nicht geprüft. tROME ist eine Testmünze ohne Wert. Verwenden Sie diese Veröffentlichung nicht für etwas von Wert.

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) und [Sicherheitsrichtlinie](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/SECURITY.md).

## Wer was prüft

| Teil                   | Prüfung oder Befugnis                                                                                                                                                                                            |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Gast                   | Validiert den EVM-Block und lehnt eine andere Chain-Konfiguration als die kompilierten Regeln von Ostia ab.                                                                                                      |
| Sidecar `verifizieren` | Prüft den Beweis, den angehefteten Programmschlüssel und rootC, den bewiesenen Block-Hash, den Header und die Transaktionsliste.                                                                                 |
| Sidecar `Teile`        | Prüft die Konto- und Storage-Beweise des Gateways und vergleicht die geordnet angehängten Teile mit dem bewiesenen Gateway-Hash.                                                                                 |
| Daml `Vorschuss`       | Prüft die Antworten des Sidecars, den Vorgänger, die nächste Blocknummer, das Gas-Limit und die von den Teilen verwendeten Verträge. Es begleicht die Teile und erstellt den nächsten Kopf und den Blockeintrag. |
| Canton                 | Ordnet Blöcke durch den Verbrauch des einen Zustandsvertrags der Chain und schreibt die Änderungen der Transaktion gemeinsam fest. Es lehnt abweichende Antworten des externen Aufrufs ab.                       |
| Builder                | Wählt Transaktionen aus, prüft die Canton-Verträge, die es sehen kann, holt einen Beweis ein und reicht den Block ein. Es kann einen Block nicht selbst finalisieren.                                            |

Zu jedem bestätigenden Teilnehmer, einschließlich des Teilnehmers des Operators, läuft ein Sidecar daneben. Jedes Sidecar berechnet seine Antworten ausschließlich aus den in dem externen Aufruf gesendeten Eingaben. Daml vergleicht ihre Antworten; es führt die kryptografische Beweisprüfung nicht selbst durch. Die [Sidecar-README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md) und [Daml-README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) geben die Prüfungen und Autoritätsanforderungen an.

## Was der Beweis festlegt

Der angeheftete Programmschlüssel identifiziert den Gast und seine Chain-Regeln. Der Beweis bindet sich an einen Block-Hash. Die Prüfung seines Headers bindet die State-Root und die Transaktions-Root. Konto- und Storage-Beweise binden dann den aufgezeichneten Leg-Hash des Gateways an diese State-Root.

Die angehängten Teile müssen dieselben Felder und dieselbe Reihenfolge haben wie die, die das Gateway aufgezeichnet hat. Das Entfernen eines Teils, das Hinzufügen eines oder das Ändern eines Empfängers, Betrags, Tokens oder IDs lässt den Hash-Vergleich scheitern. Ein Block ohne Teile muss auch diese Abwesenheit beweisen. Der Teilevergleich beruht außerdem auf der Kollisionsresistenz von Keccak-256.

Die Genesis-State-Root des Chain-Eintrags legt den Gateway-Code fest. Der Gateway-Vertrag hat keinen Eigentümer, keinen Admin-Schlüssel, kein Upgrade und keine Pause. Die Canton-Partei behält dennoch die Verwahrungsbefugnis über die von ihr gehaltenen Token.

## Befugnis von Operator, Confirmer und Gateway

Der Operator und das Gateway schlagen die Genesis der Chain, die Pins, das Gas-Limit und den Builder vor. Der Confirmer nimmt den Vorschlag an. Es wird erwartet, dass er die Pins und den Genesis-Gateway-Code mit seinem eigenen Build vergleicht. Die bereitgestellten lokalen Skripte schlagen übereinstimmende Werte vor und akzeptieren den Vorschlag sofort im Namen des Confirmer.

Der Operator, der Confirmer und das Gateway unterschreiben `ZkChain`. Sie sind die Vertrauenswurzel der Chain. Entscheidungen zur Abwicklung von Ein- und Auszahlungen erfordern alle drei. Die Zahlungsabwicklung erfordert den Operator und den Confirmer. `Vorschuss` stellt ihre gemeinsame Befugnis im Rahmen des Daml-Designs bereit. Der Builder allein kann die Abwicklungsentscheidungen nicht ausüben.

Die Gateway-Partei hält die Canton-Token, die die auf der EVM verpackten Token decken. Sie wird auf dem Teilnehmer des Operators gehostet. Wer auch immer diesen Teilnehmer betreibt, kann die gesperrten Token außerhalb der Auszahlungsregeln bewegen. Das Fehlen eines Admin-Schlüssels beim Gateway-Vertrag schränkt die Fähigkeit dieser Canton-Partei nicht ein, über ihren Teilnehmer zu handeln.

Die Token-Registrierung ist eine weitere Vertrauensentscheidung. Der Operator und das Gateway schlagen die Zuordnung von einem Canton-Instrument zu einem EVM-Wrapped-Token vor, und der Confirmer akzeptiert sie. Das Gateway führt den Daml-Transfercode des registrierten Tokens mit seiner eigenen Befugnis aus. Der [Netzwerk-README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/network/README.md#the-canton-network) beschreibt das Hosting des Teilnehmers und die Registrierungsprüfungen.

## Was einen Block stoppen kann

Um einen Teil einzuschließen, benötigt der Builder Lesezugriff auf dessen Anfragen, Bedingungen, Zustimmungen, Zuteilungen, Token-Registrierungen und Gateway-Bestände. Er lässt eine Transaktion weg, deren Canton-Verträge er nicht sehen kann.

Eine Zuteilung kann zurückgenommen werden, nachdem der Builder sie geprüft hat oder nachdem der Nachweis erbracht wurde. Ein Token-Register kann die Abwicklung auch nach seinen eigenen Regeln verweigern. Canton verweigert dann den Block und nichts wird festgeschrieben. Für eine vom Builder nicht vorhersehbare Verweigerung des Registers benötigt der nächste Lauf `--exclude`; der Builder merkt sich diese Verweigerung nicht über Läufe hinweg.

Jeder Builder-Lauf verarbeitet einen Block; er läuft nicht über aufeinanderfolgende Blöcke. Der Builder begrenzt die Ausführungsschritte vor dem Beweisen nicht. Wenn der Prover einen Block nicht fertigstellen kann, endet der Builder-Lauf. Der [Builder-README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#not-here) zeichnet diese Grenzen auf.

## Was diese Veröffentlichung nicht bietet

Das lokale Netzwerk behält zwischen den Läufen keinen Zustand. Es hat keine Ledger-API-Authentifizierung oder TLS und ist für einen einzelnen Rechner gedacht. Das Netzwerk verwendet angeheftete Canton-3.6-Snapshots und einen Snapshot-Daml-Compiler für den externen Aufruf. Ihre Versionen und Hashes stehen in [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS).

Mehrere Builder, erzwungene Aufnahme, öffentliche Canton-Bereitstellung, Datenschutz und Verwahrung, die mehr als den Teilnehmer des Operators erfordern, liegen außerhalb dieser Veröffentlichung. Es gibt keine Zielvorgaben für Durchsatz oder Blockzeit. Die aufgezeichnete Demo verwendete auf beiden bestätigenden Teilnehmern dieselbe Sidecar-Implementierung, auf demselben Rechner wie Canton.

Der Leser kann Blockbeweise erneut prüfen, aber `BlockRecord` enthält nicht die beglichenen Teile. Die Schaltfläche „Verify“ des Browsers prüft den Beweis, den Header und die Transaktionen; sie wiederholt nicht die Canton-Prüfungen zur Abwicklung der Teile.

## Melden Sie ein Sicherheitsproblem

Verwenden Sie GitHubs private Schwachstellenmeldung für `canton-zk-evm`: Öffnen Sie den Security-Tab des Repositories und wählen Sie **Eine Schwachstelle melden**. Öffnen Sie für ein Sicherheitsproblem kein öffentliches Issue.

Fügen Sie die betroffene Komponente, den Commit, die Schritte zur Reproduktion und das beobachtete Ergebnis hinzu. Hängen Sie den Beweis oder Block an, wenn er Teil des Befunds ist. Die [Sicherheitsrichtlinie](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/SECURITY.md) definiert den Umfang. Es gibt keine Bug-Bounty.


---

# 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/trust-model.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.
