> 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/erste-schritte/architecture.md).
# Architektur
Wie Roms Komponenten zusammenspielen — EVM-Ausführung in einem Solana-Programm.
Rome bindet einen EVM-Bytecode-Interpreter in ein Solana-On-Chain-Programm ein. Im EVM-Key-Lane senden Nutzer signierte EVM-Transaktionen über standardmäßiges Ethereum-JSON-RPC an den Rome Proxy. Der Proxy leitet sie an das Rome-EVM-Programm auf Solana weiter. Eine EVM-Transaktion kann mehrere Solana-Transaktionen erfordern, um Chunks in Holder-Konten zu schreiben oder iterative Ausführung auszuführen. Im v1-Solana-Key-Lane komponiert der Proxy die Transaktion. Die Solana-Wallet signiert sie und sendet sie direkt an Solana RPC. Es gibt keine separate Ausführungsschicht, die synchron gehalten werden muss — EVM-Zustand *ist* Solana-Zustand.
## Systemübersicht
## Komponenten
### Rome EVM-Programm (On-Chain)
Der Kern von Rome — ein Solana-BPF-Programm mit einem vollständigen EVM-Bytecode-Interpreter (ein Fork von SputnikVM). Es:
* Empfängt signierte EVM-Transaktionen und unsignierte EIP-1559-Nutzlasten als Solana-Anweisungen. Ein Solana-Schlüssel autorisiert eine unsignierte Nutzlast über die Signatur des Solana-Gebührenzahlers oder eine Ed25519-Verifier-Anweisung
* Führt Solidity-Bytecode innerhalb der Solana-Laufzeitumgebung aus
* Ordnet jede Ethereum-Adresse (H160) einer Balance-PDA pro Chain zu, die ihre Nonce, ihr natives Guthaben und ihren Code enthält. Separate Storage-PDAs sind mit der Balance-PDA verknüpft. Jede Adresse hat außerdem eine programmgenerierte Adresse für die Autorität über Solana-Aufrufe, genannt ihre **PDA mit externer Autorität**. Diese PDA wird von jeder Chain im Programm gemeinsam genutzt. Sie besitzt die SPL-Token-Konten der Adresse und signiert ihre Cross-Program-Invocations (CPIs)
* Stellt Precompiles für Aufrufe in Solana bereit (CPI, System, Helper, Withdraw) neben Ethereum-Precompiles. Die gecachte Familie ergänzt SystemCached (`0xff…04`), SplCached (`0xff…05`), ASplCached (`0xff…06`) und WithdrawCached (`0xff…0b`). Die Factory setzt Wrapper auf diesem gecachten Pfad ein
* Speichert den EVM-Zustand (Kontostände, Nonce, Code, Storage) als Solana-Account-Daten
* Ein Rome-EVM-Programm hostet viele Chain-IDs. Die Chain-ID ist Teil der Balance- und Storage-PDA-Adressen, nicht der PDA der externen Autorität
### Rome Proxy (JSON-RPC-Server)
Der Rome Proxy ist ein standardmäßiger Ethereum-JSON-RPC-Server. Nutzer verbinden sich mit `https://hadrian.testnet.romeprotocol.xyz/` für Hadrian (Testnetz) und `https://rubicon.mainnet.romeprotocol.xyz/` für Rubicon (Mainnet). Er übersetzt Ethereum-API-Aufrufe in Solana-Aktivitäten:
* `eth_sendRawTransaction` → eine oder mehrere Solana-v1-Transaktionen senden: atomar `DoTx`, Holder-Chunks (`TransmitTx`) plus `DoTxHolder`, oder iterative Legs. Ein gepoolter Zahler signiert und bezahlt SOL. Ein gepoolter Gebührenerfänger zieht das Gas des Nutzers ein
* `eth_call` → den EVM-Interpreter nativ im Emulator auf Live-Solana-Konten ausführen, die über RPC gelesen werden. Mollusk führt die Solana-Programme aus, die über CPI erreicht werden. Es führt auch das Rome-EVM-Programm aus, wenn der Proxy Compute Units misst
* `eth_estimateGas` → für die Gas-Schätzung simulieren. Eine Gaseinheit ist ein Lamport Solana-Kosten. Die Schätzung liegt nie unter 21.000
* `eth_getBalance`, `eth_getCode`, `eth_getTransactionCount`, `eth_getStorageAt` → Live-Solana-Konten über den Emulator lesen. `eth_getBlockByNumber`, Receipts und Logs stammen von Hercules
Es stellt außerdem Rome-Erweiterungen bereit: `rome_emulateTx`, `rome_emulateRegRollup`, `rome_mintId`, `rome_buildInfo` und `rome_getResources`. Zu den Solana-Wallet-Methoden gehören `rome_emulateCallAccounts`, `rome_composeUnsignedAtomicV1`, `rome_composeUnsignedIterativeV1`, `rome_submitSignedV1Plan`, `rome_relayUnsignedV1`, `rome_composeExternalDepositV1` und `rome_sendUnsignedTransaction`. Der Proxy stellt außerdem bereit `rome_solanaTxForEvmTx`.
### Hercules (Indexer)
Hercules überwacht das Rome-EVM-Programm auf Solana und rekonstruiert Ethereum-kompatible Blöcke in PostgreSQL. Diese enthalten Transaktionen, Receipts, Logs und Zustandsänderungen. Auf den öffentlichen Chains läuft es im slot-angepassten Modus, sodass eine Blocknummer einem Solana-Slot entspricht und derselbe Slot bei jedem Indexer denselben Block ergibt. Der Proxy stellt diese Blöcke Wallets und Explorern bereit.
Hercules indexiert bestätigte Blöcke. Es überprüft jeden Block bei Finalisierung erneut und lädt ihn neu, wenn sich der Blockhash geändert hat. Der [Über den Explorer](/de/apps-auf-rome/via.md) liest die Hercules-Daten.
### Precompiles
Rome implementiert ecrecover, SHA-256, RIPEMD-160, identity, die BN254-Kurvenoperationen und blake2f mit Ethereum-Semantik, außer bei Fehlerdaten von BN254 und blake2f. Ein fehlgeschlagener BN254- oder blake2f-Aufruf gibt Romans `Error(string)` Revert-Daten statt eines leeren Puffers zurück. Modexp (`0x05`) ist deaktiviert und schlägt fehl mit `"big_mod_exp call is disabled"`. blake2f lehnt mehr als 1.000.000 Runden ab, was Ethereum erlaubt.
Nicht-EVM-Precompiles greifen auf Solana zu: **CpiProgram** (`0xFF…08`, beliebige CPI), **System** (`0xFF…07`, PDA-Ableitung und Base58-Hilfsfunktionen), **HelperProgram** (`0xFF…09`, ATA/PDA-Erstellung, SPL-Transfers, Gas↔Lamports) und **Abheben** (`0x42…16`). Die gecachte Familie ist **SystemCached** (`0xff…04`), **SplCached** (`0xff…05`), **ASplCached** (`0xff…06`) und **WithdrawCached** (`0xff…0b`). Legacy-CPIs laufen sofort und nur in atomaren Transaktionen. Gecachte CPIs werden während der Ausführung aufgezeichnet und beim Commit gesendet. Sie revertieren mit dem EVM. Sie können in iterativen Transaktionen ausgeführt werden. Siehe die [Contract Addresses](/de/referenz/contract-addresses.md) Referenz für die vollständige Tabelle.
## Ausführungsmodi
Rome führt eine EVM-Transaktion auf eine von zwei Arten aus:
### Atomar (VmAt)
Eine einzelne Solana-Transaktion. Die gesamte EVM-Transaktion wird innerhalb des Compute-Budgets einer Solana-Transaktion ausgeführt (\~1,4 Mio. Compute Units). Wird für die meisten Operationen verwendet — Überweisungen, gewöhnliche Vertragsaufrufe, Swaps.
### Iterativ (VmIt)
Für Arbeit, die das Budget einer einzelnen Transaktion überschreitet. Die Ausführung wird auf mehrere Solana-Transaktionen aufgeteilt:
1. Jeder Schritt (eine Solana-Transaktion) führt so viele EVM-OpCodes aus, wie in sein Compute-Budget passen — die Schrittgröße ist adaptiv, nicht fest
2. Der VM-Zustand wird per Borsh in ein `StateHolder` Konto zwischen den Schritten serialisiert
3. Konten sind während der Ausführung für einige Sekunden per TTL gesperrt
Der Proxy weicht auf iterative Ausführung aus, wenn Compute Units, Heap oder Anweisungsanzahl nicht in eine einzige Solana-Transaktion passen. Eine Sitzung ist auf 160 Iterationen begrenzt. Eine CPI auf dem Legacy-Pfad wird in einer iterativen Transaktion abgelehnt, da sie nicht über mehrere Legs aufgeteilt werden kann. CPIs auf dem gecachten Pfad sind erlaubt.
## Kontenzuordnung
Jede Ethereum-Adresse wird deterministisch einer Solana-Balance-PDA zugeordnet, die aus der Chain-ID und der Adresse unter dem Rome-EVM-Programm abgeleitet wird. Ihr natives Gas-Guthaben ist ein Feld in dieser PDA, zusammen mit der Nonce und dem Vertragscode. Storage-Slots liegen in separaten Storage-PDAs. SPL-Guthaben liegen in Token-Konten, die von der separaten PDA der externen Autorität gehalten werden. Diese Autorität wird für jede Chain auf demselben Programm gemeinsam genutzt.
## Zwei Zugangswege
* **EVM-Key-Lane:** Eine Wallet sendet eine secp256k1-signierte EVM-Transaktion an den Rome Proxy. Der Proxy reicht die Solana-Transaktionen ein.
* **Solana-Key-Lane:** Eine Wallet autorisiert eine unsignierte EIP-1559-Nutzlast mit ihrem Solana-Schlüssel. Für den direkten v1-Pfad komponiert der Proxy die Solana-Transaktion. Die Wallet signiert sie und reicht sie direkt an Solana RPC ein. Der Relay-Pfad nutzt stattdessen den Proxy zur Einreichung. Der ältere Legacy-Pfad lässt die Wallet eine `DoTxUnsigned` Solana-Transaktion erstellen, signieren und bezahlen, und das Programm leitet den Absender aus dem Solana-Signer ab.
Ein Solana-Public-Key wird der synthetischen Adresse zugeordnet `keccak256(pubkey)[12:]`, die letzten 20 Bytes des Hashs. Siehe [Wie Solana und die EVM sich auf Rome treffen](/de/kernkonzepte/how-solana-and-evm-meet.md).
## Wer einen Aufruf in Solana signiert
Das Rome-EVM-Programm signiert eine CPI mit der PDA der externen Autorität des unmittelbaren Aufrufers des Precompiles. Ein Vertrag signiert als er selbst. Um die SPL-Token eines Nutzers auszugeben, benötigt der Vertrag eine SPL-Delegation dieses Nutzers. Der Nutzer erteilt sie mit `HelperProgram.approve_spl(spender, amount, mint)`. Ein direkter Aufruf von der EVM- oder synthetischen Adresse des Nutzers an das Precompile verwendet die PDA der externen Autorität des Nutzers.
## Holder-Konten
Solana-(v1)-Transaktionen sind auf 4 KB begrenzt, aber EVM-Transaktionen (insbesondere Vertragsbereitstellungen) können viel größer sein. Rome teilt große Transaktionen in 3.600-Byte-Chunks auf und schreibt sie nacheinander in **Holder-Konten** (bis zu 80 KB). Anschließend setzt es jede Transaktion zusammen und führt sie On-Chain aus. Das Rome SDK verwaltet dies transparent. Die Signaturgebühr jedes Chunks wird dem Gas des Absenders belastet.
## Gas und Preisgestaltung
Jede Chain hat ihren eigenen Gas-Token: SOL oder ein SPL-Token. Die Preisquelle ist die Hermes-API, ein Meteora-DAMM-v1-Pool, ein Meteora-DAMM-v2-Pool oder ein Festpreis. Sie liefert die Umrechnung zwischen dem Gas-Token und SOL für die zugrunde liegenden Solana-Transaktionsgebühren.
* Eine Gaseinheit entspricht einem Lamport Solana-Kosten
* `eth_gasPrice` ist Gas-Token-WEI pro Lamport
* Der Absender bezahlt den Gebührenerfänger aus seinem nativen Gas-Guthaben. Der Proxy-Zahler bezahlt SOL
* Ohne Gebührenerfänger, wie im atomaren Solana-Wallet-Lane, wird kein EVM-Gas berechnet. Die Wallet bezahlt SOL direkt
* Das native Guthaben hat 18 Dezimalstellen. Es wird durch Gas-Token-SPL gedeckt, die in einer chain-spezifischen Programm-Wallet gehalten werden
## Finalität
Rome nutzt die Finalität von Solana. Das SDK wartet auf `bestätigt`. Hercules überprüft jeden indexierten Block bei `finalisiert` und lädt ihn neu, wenn sich der Blockhash geändert hat.
## Was als Nächstes kommt
* [Netzwerke](/de/netzwerke/networks.md) — Verbindung zu Hadrian (Testnetz) und Rubicon (Mainnet)
* [Schnellstart](/de/erste-schritte/quickstart.md) — stelle deinen ersten Vertrag bereit
* [Ausführungsmodell](/de/kernkonzepte/execution-model.md) — atomare vs. iterative Ausführung im Detail
* [Token-Interop](/de/kernkonzepte/token-interop.md)
* [Beschränkungen](/de/kernkonzepte/constraints.md)
* [Solana aus EVM aufrufen](/de/entwicklerleitfaden/call-solana-from-evm.md)
* [EVM aus Solana aufrufen](/de/entwicklerleitfaden/call-evm-from-solana.md)
* [Precompile-Referenz](/de/referenz/precompiles.md)
* [Wie Solana und die EVM sich auf Rome treffen](/de/kernkonzepte/how-solana-and-evm-meet.md)
---
# 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/erste-schritte/architecture.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.
