> 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/trust-model.md). # Vertrauensmodell Wer eine Rome-ZK-EVM-Chain im Devnet ändern kann und wem Einzahler und Abheber vertrauen müssen. Die gemeinsamen v0.3.0-Programme auf dem Solana-Devnet sind upgradefähig. Eine bewiesene Root ist nach den Regeln, die diese Programme beim Posten durchsetzen, endgültig. Betreiber und Nutzer sollten außerdem berücksichtigen, wer diese Regeln ändern kann, wer jede Chain kontrolliert und wer die Veröffentlichung von Daten stoppen kann. Lesen Sie das [vollständige v0.3.0-Devnet-Vertrauensmodell](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/TRUST-MODEL.md) für die genauen Befugnisse jeder Instanz und die Prüfungen in den aktuellen Programmen. ## Romes Programm- und Registry-Autoritäten Rome hält die Upgrade-Autorität für die Programme Shared Inbox, Settlement, Veritas und Bridge. Auf dem Devnet ist dies eine Einzelsignatur-Autorität. Ein Upgrade kann ohne Ankündigungsfrist wirksam werden und jede aktuelle Programmregel ändern. Behandeln Sie dies als eine Vertrauensannahme des Devnets, wenn Sie Gelder einzahlen. Rome hält auch die Settlement-Registry-Autorität. Unter den aktuellen Programmen kann es die erlaubnisfreie Registrierung ein- oder ausschalten, Registrierungs-Einlagen für neue Chains ändern, Settlement-Gebühren auch für eine bestehende Chain ohne Protokollobergrenze ändern, die Treasury auswählen, die zulässige Zeitstempelabweichung ändern und das globale Rückforderungsfenster ändern. Das Rückforderungsfenster kann für registrierte Chains verkürzt werden, jedoch unter den aktuellen Programmen nicht unter 216.000 Slots. Die Registry-Autorität registriert, deaktiviert und ändert den Aktivierungsslot der Verifizierungsschlüssel einer Chain. Ein Beweis zählt nur gegen einen aktiven Schlüssel dieser Chain. Diese Autorität kann daher ändern, welche Beweise eines Gasts neue Roots finalisieren können, oder eine Chain ohne nutzbaren Schlüssel zurücklassen. Ein neuer Eintrag kann aktiv werden, sobald seine Registrierungs-Transaktion bestätigt wurde. Bereits finalisierte Roots bleiben final, wenn ein Schlüssel deaktiviert wird. Ohne die Programme zu upgraden können Romes Schlüssel keinen Vault für eine Chain erstellen, deren Autorität Rome nicht hält, das Mint dieses Vaults ändern, entscheiden, wohin dessen Auszahlungen gehen, oder daraus ohne einen bewiesenen Exit abheben. Die Upgrade-Autorität des Programms kann diese Regeln ändern, daher müssen Nutzer Rome vertrauen, dass es auf dem Devnet kein solches Upgrade vornimmt. ## Ihre Chain-Autorität Im `./rollup` Setup ist der Solana-Zahler auch die Chain-Autorität. Er unterzeichnet die Veröffentlichung und Finalisierung von Inbox-Batches, das Posten bewiesener Roots und die Chain-Konfiguration. Er kann geeignete Batch-, Chunk- und Pending-Root-Konten schließen, um deren Rent zurückzuerhalten. Es gibt keine Anweisung, diese Autorität zu rotieren; wenn sie verloren geht, werden diese signierten Aktionen gestoppt. Die Registrierung legt die ID der Chain, den Genesis, das Inbox-Programm und die Länge des Challenge-Fensters fest. Die Autorität kann den registrierten Genesis nicht bearbeiten. Sie wählt in diesem Genesis einen Gebührenempfänger aus. Eine neue Chain startet normalerweise mit null Salden; jedes angegebene Anfangsguthaben benötigt eine entsprechende Vault-Deckung, bevor Rome ihren Verifizierungsschlüssel registriert. Das Settlement prüft diese Deckung nicht selbst. Die Autorität kann ein anderes Exit-Portal, Bridge-Programm, Abhebungslimit und Poster-Bond vorschlagen. Ein Vorschlag wird frühestens ein Chain-Challenge-Fenster später aktiv. Danach kann ihn jeder ab diesem Slot aktivieren. Nutzer sollten vor dem Abheben die aktive Exit-Konfiguration prüfen. Nach dem ersten bewiesenen Batch kann die Autorität eine Einzahlungswarteschlange erstellen und deren Aufnahmefrist, Grenzwerte pro Batch und pro Block, Mindesteinzahlung, Gebühr und Gebührenempfänger festlegen. Änderungen haben ebenfalls einen verzögerten Aktivierungsslot. Das aktuelle Programm schränkt ein, welche wartenden Einzahlungen ein **finalisiert** Batch weglassen darf. Es zwingt den Betreiber nicht, diesen Batch zu erzeugen. ## Worauf sich ein Nutzer verlässt Ein Einzahler vertraut darauf, dass der Operator den Sequencer am Laufen hält, die in der Warteschlange stehende Gutschrift in einen Batch aufnimmt, den Batch postet und dessen Root beweist. Der Operator kann die Reihenfolge der EVM-Transaktionen wählen und Transaktionen ablehnen; es gibt keinen allgemeinen erzwingbaren Einschlusskanal für EVM-Transaktionen. Ein Einzahlungsbetrag kann in der Chain-RPC erscheinen, bevor seine Root auf Solana final ist. Ein Abhebender benötigt eine finale Root, die die Exit-Nachricht abdeckt, eine aktive Exit-Konfiguration und genügend Wrapped SOL im Chain-Vault. Der Operator kann diese Root verzögern, indem er Batches oder Beweise stoppt. Er kann Auszahlungen verzögern, indem er den Exit-Prover stoppt oder den Vault oder den Exit-Zahler ohne Mittel lässt. Jeder kann einen gültigen Exit-Beweis und eine Freigabe einreichen, sodass der Exit-Prover des Betreibers nicht der einzige Weg ist, sobald die Daten und die finale Root verfügbar sind. Unter den aktuellen Programmen bindet Settlement einen Exit-Beweis an das konfigurierte Portal und eine finale Root. Es begrenzt Exits pro Challenge-Fenster und verhindert Replays. Die Bridge liest den Empfänger aus dem bewiesenen Datensatz aus und prüft das zugehörige Token-Konto des Empfängers. Wer auch immer die Freigabe sendet, kann die Auszahlung nicht umleiten. Ein Vault ohne ausreichende Mittel kann nicht zahlen, selbst wenn der Exit-Beweis gültig ist. Die 5-SOL-Registrierungsanzahlung ist eine Sicherheitsleistung für die Chain-Registrierung, keine Deckung für die Salden der Nutzer. Sie wird der Chain-Autorität nach der ersten finalen Root oder zehn geposteten Roots erstattbar. Wenn vor Ablauf des Rückforderungsfensters keine Root gepostet wird, kann jeder die Chain zurückfordern, und ihre nicht erstattete Anzahlung geht an die Treasury. Das Devnet-Fenster in v0.3.0 beträgt 6.480.000 Slots, etwa 30 Tage, gemessen ab der Registrierung. --- # 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/trust-model.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.