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

# Ausführungsmodell

Rome EVM führt Solidity-Bytecode in einem Solana-On-Chain-Programm aus. Diese Seite erklärt, wie EVM-Transaktionen verarbeitet werden.

## Transaktionslebenszyklus

```
1. Benutzer signiert EVM-Transaktion (MetaMask / ethers.js)
                    ↓
2. Rome Proxy empfängt über eth_sendRawTransaction
                    ↓
3. Der Proxy emuliert die Transaktion Off-Chain (Mollusk-SVM-Emulator)
   → Schätzt Gas, prüft Atomarität, identifiziert erforderliche Konten
                    ↓
4. Proxy verpackt EVM-TX als Solana-Instruktion(en)
   → Wenn die Tx in eine Solana-Transaktion passt → Atomar (VmAt)
   → Wenn die Tx das CU-Budget überschreitet → Iterativ (VmIt)
                    ↓
5. Der Solana-Validator führt die Instruktion(en) aus
   → Das Rome-EVM-Programm interpretiert den EVM-Bytecode
   → CPI-Aufrufe zu anderen Solana-Programmen (falls vorhanden)
                    ↓
6. Zustandsänderungen werden in Solana-Konten übernommen
                    ↓
7. Hercules indiziert das Ereignis → erzeugt einen EVM-Block
```

## Atomare Ausführung (VmAt)

Der Standardmodus. Die gesamte EVM-Transaktion wird innerhalb einer einzelnen Solana-Transaktion ausgeführt.

**Zustandsmaschine:** `Lock → Init → Execute → Commit → GasTransfer → Exit`

**Eigenschaften:**

* Alles-oder-nichts-Ausführung — wenn ein Schritt fehlschlägt, wird die gesamte Transaktion zurückgesetzt
* \~1,4 Mio. Compute Units pro Solana-Transaktion verfügbar
* Geeignet für Überweisungen, einfache Vertragsaufrufe, Swaps und die meisten DeFi-Operationen
* Finalität unter einer Sekunde (Solana-Blockzeit)

**Wann verwendet:** Wird automatisch ausgewählt, wenn der Emulator feststellt, dass die Transaktion in das Compute-Budget einer einzelnen Solana-Transaktion passt.

## Iterative Ausführung (VmIt)

Für rechenintensive Operationen, die das Budget einer einzelnen Transaktion überschreiten. Die EVM-Ausführung wird über mehrere Solana-Transaktionen aufgeteilt.

**So funktioniert es:**

1. Jeder Schritt (eine Solana-Transaktion) führt aus **so viele EVM-OpCodes, wie in sein Compute-Budget passen** — eine adaptive Schrittgröße, keine feste Anzahl
2. Nach jedem Schritt wird der VM-Zustand (Borsh-Format) in einen `StateHolder` Konto
3. Der nächste Schritt deserialisiert den Zustand und setzt die Ausführung fort
4. Die beteiligten Konten werden für **3-4 Sekunden** während der mehrstufigen Ausführung

**Zustandsmaschine:** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed`

**Kontensperrung:**

* **RoLock (gemeinsam, nur lesbar)** — Mehrere iterative Transaktionen können ihn gleichzeitig halten
* **RwLock (exklusives Schreiben)** — Nur eine Transaktion kann ein Konto gleichzeitig ändern
* **TTL:** 3 Sekunden (Standard), 4 Sekunden (bei Verwendung von Address Lookup Tables)

**Wann verwendet:** BN254-Paarungsprüfung, große Vertragsbereitstellungen, tiefe Aufrufstapel, jede Operation, die \~1,4 Mio. CU überschreitet.

## Emulation

Bevor eine Transaktion an Solana gesendet wird, emuliert der Proxy sie Off-Chain mit dem **Mollusk-SVM-Emulator**. Dies:

1. Schätzt den Gasverbrauch
2. Bestimmt, ob der atomare oder iterative Modus benötigt wird
3. Identifiziert alle Solana-Konten, die die Transaktion berühren wird
4. Validiert, dass die Transaktion On-Chain nicht fehlschlagen wird

Der Emulator führt dieselbe EVM-Logik aus wie das On-Chain-Programm — das `entrypoint!` Makro stellt identische Dispatch-Tabellen sowohl im Programm als auch in den Emulator-Codebasen sicher.

**Mollusk SVM** kann während der Emulation auch beliebige Solana-BPF-Programme ausführen, was bedeutet, dass `eth_call` und `eth_estimateGas` CPI-Aufrufe an SPL Token, Jupiter, Kamino usw. korrekt handhaben kann.

## Kontenabbildung

Jede Ethereum-Adresse wird einer Solana-PDA zugeordnet:

```
Ethereum-Adresse (H160, 20 Byte)
    ↓
PDA = findProgramAddress(
    [chain_id, "ACCOUN_SEED", H160, bump],
    ROME_EVM_PROGRAM_ID
)
    ↓
Solana-Konto (Pubkey, 32 Byte)
```

**Auf der Chain gespeicherte Kontotypen:**

| Typ         | Seeds                                        | Zweck                                              |
| ----------- | -------------------------------------------- | -------------------------------------------------- |
| Guthaben    | `[chain, "ACCOUN_SEED", H160, bump]`         | Nonce, Guthaben, Vertragscode                      |
| Speicher    | `[chain, "STORAGE", H160, slot_index, bump]` | Vertrags-Speicher (256 Slots pro Konto)            |
| TxHolder    | `[signer, "TX_HOLDER_SEED", index, bump]`    | Bereitgestellte Transaktionsdaten (max. 80 KB)     |
| StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | Serialisierter VM-Zustand zwischen den Iterationen |

## Holder-Konten

Solana-Transaktionen sind auf 1.232 Byte begrenzt. EVM-Transaktionen — insbesondere Vertragsbereitstellungen — können deutlich größer sein.

**Aufteilungsmechanismus:**

1. Das SDK teilt die RLP-codierte Transaktion in Chunks auf
2. Jeder Chunk wird in ein `TxHolder` Konto über `TransmitTx` Instruktionen
3. Sobald alle Chunks bereitgestellt sind, eine `DoTxHolder` Instruktion setzt die vollständige Transaktion zusammen und führt sie aus
4. Maximale Holder-Größe: **80 KB** pro TxHolder

Das ist für den Entwickler völlig transparent — das Rome SDK übernimmt Aufteilung und Wiederzusammenfügen automatisch.

## Unterstützte Transaktionstypen

| Typ               | EIP      | Beschreibung                                              |
| ----------------- | -------- | --------------------------------------------------------- |
| Legacy            | —        | Traditionelle Ethereum-Transaktionen                      |
| Access List       | EIP-2930 | Optimierte State-Zugriffsmuster                           |
| Dynamische Gebühr | EIP-1559 | Basisgebühr + Prioritätsgebühr                            |
| Deposit           | Typ 0x7E | Deposit-Transaktionen, z. B. eingehende Bridge-Abwicklung |

## Journalierter Zustand

Rome EVM verwendet ein journaliertes Zustandsmodell zur Verwaltung von Zustandsänderungen während der Ausführung:

* Alle Änderungen (Nonce, Guthaben, Speicher, Code) werden in einem `Journal`
* Verschachtelte CALL/CREATE-Operationen legen Snapshot-Frames ab
* Bei Revert: Journaleinträge werden auf den Snapshot zurückgesetzt
* Bei Erfolg: Änderungen werden in Solana-Konten übernommen
* Nicht-EVM-CPI-Instruktionen werden sofort ausgeführt (Solanas eigene Atomarität gewährleistet die Korrektheit)

## Was kommt als Nächstes

* [Compute-Budget](/de/kernkonzepte/compute-budget.md) — CU-Kosten und Optimierungsstrategien
* [Einschränkungen](/de/kernkonzepte/constraints.md) — wichtige Limits und Grenzen


---

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