> 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 Wie Rome EVM Ethereum-Transaktionen auf Solana verarbeitet — Proxy-Emulation, atomare (VmAt) vs. iterative (VmIt) Modi und der vollständige Transaktionslebenszyklus. Rome EVM führt Solidity-Bytecode innerhalb eines On-Chain-Programms auf Solana aus. Diese Seite erklärt, wie EVM-Transaktionen verarbeitet werden. ## Transaktionslebenszyklus ``` 1. Nutzer signiert EVM-Transaktion (MetaMask / ethers.js) ↓ 2. Rome Proxy empfängt sie über eth_sendRawTransaction ↓ 3. Proxy emuliert die Transaktion Off-Chain (Mollusk-SVM-Emulator) → Schätzt Gas, prüft Atomarität, identifiziert erforderliche Konten ↓ 4. Proxy verpackt die 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 → Das Rome-EVM-Programm interpretiert EVM-Bytecode → CPI-Aufrufe an andere Solana-Programme (falls vorhanden) ↓ 6. Zustandsänderungen werden in Solana-Konten committed ↓ 7. Hercules indexiert 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 irgendein Schritt fehlschlägt, wird die gesamte Transaktion zurückgesetzt * ≈1,4 Mio. Compute Units pro Solana-Transaktion verfügbar * Geeignet für Transfers, einfache Vertragsaufrufe, Swaps, die meisten DeFi-Operationen * Finalität im Subsekundenbereich (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. **Wie es funktioniert:** 1. Jeder Schritt (eine Solana-Transaktion) führt **so viele EVM-OpCodes aus, wie in sein Compute-Budget passen** — eine adaptive Schrittlänge, keine feste Anzahl 2. Nach jedem Schritt wird der VM-Zustand serialisiert (Borsh-Format) in eine `StateHolder` Account 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 per TTL gesperrt; eine Sitzung ist begrenzt auf **160 Schritte**; danach gibt der nächste Schritt die Sperren der Sitzung frei und beendet sie, ohne etwas zu committen **Zustandsmaschine:** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed` **Kontosperrung:** * Eine **exklusive Sperre** pro verwaltetem Konto (Saldo- und Speicher-Konten) — nur eine iterative Sitzung kann zu einem Zeitpunkt ein Konto halten; eine atomare Transaktion, die in ein gesperrtes Konto schreibt, wird abgelehnt mit `AccountLocked` bis die Sperre abläuft, und der Client sendet erneut * **TTL:** 3 Sekunden, bei jedem Schritt erneuert (4 Sekunden, wenn die Sitzung mehr als 28 Konten berührt) * **Legacy-Track-CPIs werden abgelehnt** innerhalb einer iterativen Transaktion (`CpiProhibitedInIterativeTx`); Effekte des Cached-Tracks werden zwischengespeichert und am Ende committed **Wann verwendet:** BN254-Pairing-Verifikation, große Vertragsbereitstellungen, tiefe Aufrufstapel, 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**. Das: 1. schätzt den Gasverbrauch 2. bestimmt, ob atomarer oder iterativer 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 in den Codebasen von Programm und Emulator sicher. **Mollusk SVM** kann während der Emulation auch beliebige Solana-BPF-Programme ausführen, was bedeutet `eth_call` und `eth_estimateGas` CPI-Aufrufe an SPL Token, Jupiter, Kamino usw. korrekt handhaben kann. ## Kontozuordnung Jede Ethereum-Adresse wird auf eine Solana-PDA abgebildet: ``` Ethereum-Adresse (H160, 20 Bytes) ↓ PDA = findProgramAddress( [chain_id, "ACCOUN_SEED", H160, bump], ROME_EVM_PROGRAM_ID ) ↓ Solana-Konto (Pubkey, 32 Bytes) ``` **On-Chain gespeicherte Kontotypen:** | Typ | Seeds | Zweck | | ----------- | -------------------------------------------- | --------------------------------------------------- | | Saldo | `[chain, "ACCOUN_SEED", H160, bump]` | Nonce, Guthaben, Vertragscode | | Speicher | `[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-Konten Rome sendet Solana **v1-Transaktionen**, die auf 4 KB (4.096 Bytes) und 64 Adressen begrenzt sind. EVM-Transaktionen — insbesondere Vertragsbereitstellungen — können viel größer sein. **Aufteilungsmechanismus:** 1. Das SDK teilt die RLP-kodierte Transaktion in Chunks auf 2. Jeder Chunk wird in ein `TxHolder` Konto über `TransmitTx` Instruktionen 3. Sobald alle Chunks zwischengespeichert sind, setzt eine `DoTxHolder` Instruktion 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 das Aufteilen und Wiederzusammensetzen automatisch. ## Unterstützte Transaktionstypen | Typ | EIP | Beschreibung | | ------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Legacy | — | Traditionelle Ethereum-Transaktionen | | Access List | EIP-2930 | Optimierte Muster für den Zustandszugriff | | Dynamic Fee | EIP-1559 | Basisgebühr + Prioritätsgebühr | | Nicht signiertes EIP-1559 | — | Ein `0x02`-typisierter Body ohne secp256k1-Signatur, stattdessen autorisiert durch die Ed25519-Signatur einer Solana-Wallet (der Solana-Lane; siehe [EVM von Solana aus aufrufen](/de/entwicklerleitfaden/call-evm-from-solana.md)) | | Einzahlung | 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 schieben Snapshot-Frames * Bei Revert: Journal-Einträge werden auf den Snapshot zurückgesetzt * Bei Erfolg: Änderungen werden in Solana-Konten committed * Nicht-EVM-CPI-Instruktionen werden sofort ausgeführt (Solanas eigene Atomaritätsgarantie 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 Grenzen und Beschränkungen --- # 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/kernkonzepte/execution-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.