# Ausführungsmodell

Rome EVM führt Solidity-Bytecode innerhalb eines On-Chain-Programms auf Solana aus. Diese Seite erklärt, wie EVM-Transaktionen verarbeitet werden.

## Lebenszyklus einer Transaktion

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

## Atomare Ausführung (VmAt)

Der Standardmodus. Die gesamte EVM-Transaktion wird innerhalb einer einzigen 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 in 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 auf mehrere Solana-Transaktionen aufgeteilt.

**So funktioniert es:**

1. Jeder Schritt führt ungefähr aus **500 EVM-OpCodes**
2. Nach jedem Schritt wird der VM-Zustand serialisiert (Borsh-Format) in ein `StateHolder` Konto
3. Der nächste Schritt deserialisiert den Zustand und setzt die Ausführung fort
4. Die beteiligten Accounts werden TTL-gesperrt für **3–4 Sekunden** während der mehrstufigen Ausführung

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

**Account-Sperrung:**

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

**Wann verwendet:** BN254-Pairing-Verifikation, große Vertragsbereitstellungen, tiefe Call-Stacks, jede Operation, die \~1,4 Mio. CU überschreitet.

## Emulation

Bevor eine Transaktion an Solana übermittelt 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 erforderlich ist
3. Identifiziert alle Solana-Accounts, die die Transaktion berühren wird
4. Validiert, dass die Transaktion On-Chain nicht fehlschlägt

Der Emulator führt dieselbe EVM-Logik aus wie das On-Chain-Programm — das `entrypoint!` -Makro sorgt für identische Dispatch-Tabellen sowohl im Programm als auch im Emulator-Codebase.

**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 behandeln.

## Account-Zuordnung

Jede Ethereum-Adresse wird einem 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)
```

**On-Chain gespeicherte Kontotypen:**

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

## Holder-Accounts

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-kodierte Transaktion in Blöcke auf
2. Jeder Block wird in ein `TxHolder` Konto geschrieben über `TransmitTx` Instruktionen
3. Sobald alle Blöcke zwischengespeichert sind, assemblieren und führen eine `DoTxHolder` Instruktion die vollständige Transaktion aus
4. Maximale Holder-Größe: **80 KB** pro TxHolder

Das ist für den Entwickler völlig transparent — das Rome SDK übernimmt das Aufteilen und Zusammenführen automatisch.

## Unterstützte Transaktionstypen

| Typ         | EIP      | Beschreibung                                       |
| ----------- | -------- | -------------------------------------------------- |
| Legacy      | —        | Traditionelle Ethereum-Transaktionen               |
| Access List | EIP-2930 | Optimierte Zugriffsmuster auf den Zustand          |
| Dynamic Fee | EIP-1559 | Basisgebühr + Prioritätsgebühr                     |
| Deposit     | Typ 0x7E | L2-Deposit-Transaktionen (vom Sequencer initiiert) |

## Journaled State

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

* Alle Änderungen (Nonce, Kontostand, Storage, Code) werden in einem `Journal`
* Verschachtelte CALL/CREATE-Operationen erzeugen Snapshot-Frames
* Bei Revert: Journaleinträge werden auf den Snapshot zurückgesetzt
* Bei Erfolg: Änderungen werden in Solana-Accounts übernommen
* Nicht-EVM-CPI-Instruktionen werden sofort ausgeführt (die eigene Atomaritätsgarantie von Solana sorgt für Korrektheit)

## Was kommt als Nächstes

* [Compute-Budget](/de/grundlegende-konzepte/compute-budget.md) — CU-Kosten und Optimierungsstrategien
* [Einschränkungen](/de/grundlegende-konzepte/constraints.md) — wichtige Grenzen und Beschränkungen
* [Lebenszyklus einer Transaktion](https://github.com/rome-protocol/docs/blob/main/core-concepts/transaction-lifecycle.md) — detaillierte Schritt-für-Schritt-Anleitung


---

# Agent Instructions: 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:

```
GET https://docs.rome.builders/de/grundlegende-konzepte/execution-model.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.