> 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

Rome bettet einen EVM-Bytecode-Interpreter in ein Solana-Programm auf der Kette ein. Benutzer kommunizieren mit dem Rome Proxy über das standardmäßige Ethereum-JSON-RPC, und der Proxy sendet ihre Transaktionen direkt an das Rome-EVM-Programm auf Solana. Es gibt keine separate Ausführungsschicht, die synchron gehalten werden muss — EVM-Status *ist* Solana-Zustand.

## Systemübersicht

<figure><img src="/files/f253da0ab7c43ce80840344a23014b9adb8c601a" alt="User to Rome Proxy to the Rome EVM program on Solana, with Hercules indexing back"><figcaption></figcaption></figure>

## Komponenten

### Rome EVM-Programm (on-chain)

Der Kern von Rome — ein Solana-BPF-Programm, das einen vollständigen EVM-Bytecode-Interpreter enthält (ein Fork von SputnikVM). Es:

* Empfängt serialisierte EVM-Transaktionen als Solana-Instruktionen
* Führt Solidity-Bytecode innerhalb der Solana-Runtime aus
* Ordnet jede Ethereum-Adresse (H160) einem Solana-PDA zu
* Stellt Precompiles für Aufrufe in Solana hinein bereit (CPI, System, Helper, Withdraw) neben den standardmäßigen Ethereum-Precompiles
* Speichert den EVM-Zustand (Kontostände, Nonce, Code, Speicher) als Solana-Kontodaten

### Rome Proxy (JSON-RPC-Server)

Ein standardmäßiger Ethereum-JSON-RPC-Server auf Port 9090 — der Einstiegspunkt für die öffentlichen Chains. Er übersetzt Ethereum-API-Aufrufe in Solana-Aktivität:

* `eth_sendRawTransaction` → EVM-Tx serialisieren → eine Solana-Instruktion senden
* `eth_call` → Ausführung off-chain über den Mollusk-SVM-Emulator emulieren
* `eth_estimateGas` → zur Gas-Schätzung simulieren
* `eth_getBalance`, `eth_getCode`, `eth_getBlockByNumber`, Belege, Logs → werden aus dem indexierten Zustand bereitgestellt

Er stellt außerdem Rome-Erweiterungen bereit: `rome_emulateTx`, `rome_emulateRegRollup`, `rome_mintId`, `rome_buildInfo`, `rome_getResources`, und mehr.

### Hercules (Indexer)

Überwacht das Rome-EVM-Programm auf Solana und rekonstruiert Ethereum-kompatible Blöcke — Transaktionen, Belege, Logs und Zustandsänderungen — gestützt auf PostgreSQL. Auf den öffentlichen Chains läuft es im slot-ausgerichteten Modus, sodass eine Blocknummer einem Solana-Slot entspricht und derselbe Slot auf jedem Indexer denselben Block ergibt. Der Proxy stellt diese Blöcke Wallets und Explorern bereit.

### Precompiles

Rome implementiert die standardmäßigen Ethereum-Precompiles (ecrecover, SHA-256, RIPEMD-160, identity, modexp, die BN254-Kurvenoperationen, blake2f) mit Mainnet-äquivalenter Semantik, plus Nicht-EVM-Precompiles, die in Solana hineinreichen: **CpiProgram** (`0xFF…08`, beliebiges CPI), **System** (`0xFF…07`, PDA-Ableitung und Base58-Helfer), **HelperProgram** (`0xFF…09`, ATA-/PDA-Erstellung, SPL-Transfers, Gas↔Lamports), und **Withdraw** (`0x42…16`). Siehe die [Vertragsadressen](/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 einzelnen 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 das Compute-Budget passen — die Schrittgröße ist adaptiv, nicht fest
2. Der VM-Zustand wird zwischen den Schritten Borsh-serialisiert in ein `StateHolder` Konto
3. Konten werden während der Ausführung für einige Sekunden per TTL gesperrt
4. Wird für schwere Operationen wie BN254-Pairing verwendet

## Kontozuordnung

Jede Ethereum-Adresse wird deterministisch einem Solana-PDA zugeordnet, das von der Chain-ID und der Adresse unter dem Rome-EVM-Programm abgeleitet ist. Dieses PDA besitzt den Kontostand des Kontos (als SPL-Token-Konten), den Vertragscode, Speicher-Slots und die Nonce — alles als Solana-Kontodaten.

## Holder-Konten

Solana-Transaktionen sind auf 1.232 Bytes begrenzt, aber EVM-Transaktionen (insbesondere Vertragsbereitstellungen) können viel größer sein. Rome lagert große Transaktionen in **Holder-Konten**: Die Transaktion wird in Chunks aufgeteilt, die sequenziell in einen Holder geschrieben werden (bis zu 80 KB), dann on-chain zusammengesetzt und ausgeführt. Das Rome SDK verwaltet dies transparent.

## Gas und Preisgestaltung

Jede Chain hat ihr eigenes Gas-Token — beliebiges SPL-Token. Die Gas-Preisgestaltung liest einen Meteora-DAMM-Pool (v1 oder v2, konfigurierbar), um zwischen dem Gas-Token und SOL für die zugrunde liegenden Solana-Transaktionsgebühren zu konvertieren.

## Was kommt als Nächstes

* [Netzwerke](/de/netzwerke/networks.md) — verbinde dich mit Martius oder Hadrian
* [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


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/de/erste-schritte/architecture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
