> 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. 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 Atomizität, identifiziert erforderliche Konten ↓ 4. Proxy verpackt EVM-Tx als Solana-Instruction(s) → Wenn die Tx in eine einzige Solana-Tx passt → Atomar (VmAt) → Wenn die Tx das CU-Budget überschreitet → Iterativ (VmIt) ↓ 5. Der Solana-Validator führt die Instruction(s) aus → Das Rome-EVM-Programm interpretiert EVM-Bytecode → CPI-Aufrufe an andere Solana-Programme (falls vorhanden) ↓ 6. Statusänderungen werden in Solana-Konten übernommen ↓ 7. Hercules indiziert 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 innerhalb des Compute-Budgets einer einzelnen Solana-Transaktion liegt. ## 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 (eine Solana-Transaktion) führt aus **so viele EVM-OpCodes, wie in das Compute-Budget passen** — eine adaptive Schrittgröße, keine feste Anzahl 2. Nach jedem Schritt wird der VM-Zustand serialisiert (Borsh-Format) in eine `StateHolder` Konto 3. Der nächste Schritt deserialisiert den Zustand und setzt die Ausführung fort 4. Beteiligte Konten werden für **3–4 Sekunden** während der mehrstufigen Ausführung mit TTL gesperrt; eine Sitzung ist auf **160 Schritte**begrenzt; danach gibt der nächste Schritt die Sperren der Sitzung frei und beendet sie, ohne etwas zu übernehmen **Zustandsmaschine:** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed` **Kontosperrung:** * Eine **exklusive Sperre** pro verwaltetem Konto (Saldo- und Speicherkonten) — nur eine iterative Sitzung kann gleichzeitig 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) * **CPIs des Legacy-Pfads werden abgelehnt** innerhalb einer iterativen Transaktion (`CpiProhibitedInIterativeTx`); Effekte des Cache-Pfads werden zwischengespeichert und am Ende übernommen **Wann verwendet:** große Contract-Deployments, tiefe Aufrufstapel, jede Operation, die \~1,4 Mio. CU überschreitet. Ein BN254-Pairing-Check benötigt dies für sich genommen nicht; siehe [Compute Budget](/de/kernkonzepte/compute-budget.md). ## 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 atomarer oder iterativer Modus erforderlich ist 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 sicher, dass in den Codebasen von Programm und Emulator identische Dispatch-Tabellen vorhanden sind. **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 verarbeitet werden ## Kontozuordnung Jede Ethereum-Adresse wird auf ein 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, Saldo, Contract-Code | | Speicher | `[chain, "STORAGE", H160, slot_index, bump]` | Contract-Speicher (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 Contract-Deployments — 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` Instructionen 3. Sobald alle Blöcke zwischengespeichert sind, `DoTxHolder` Instruction die vollständige Transaktion zusammensetzt und ausführt 4. Maximale Holder-Größe: **80 KB** pro TxHolder Dies 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 Zugriffs­muster auf den Zustand | | Dynamische Gebühr | EIP-1559 | Basisgebühr + Prioritätsgebühr | | Nicht signiertes EIP-1559 | — | Eine `0x02`-typisierter Body ohne secp256k1-Signatur, stattdessen autorisiert durch die Ed25519-Signatur einer Solana-Wallet (die Solana-Spur; siehe [EVM aus Solana aufrufen](/de/entwicklerleitfaden/call-evm-from-solana.md)) | | Einzahlung | Typ 0x7E | Einzahlungs-Transaktionen, z. B. Bridge-Inbound-Abwicklung | ## Journaled State Rome EVM verwendet ein journalbasiertes Zustandsmodell zur Verwaltung von Statusänderungen während der Ausführung: * Alle Änderungen (Nonce, Saldo, Speicher, Code) werden in einem `Journal` * Verschachtelte CALL/CREATE-Operationen legen Snapshot-Frames an * Bei Revert: Journal-Einträge werden auf den Snapshot zurückgerollt * Bei Erfolg: Änderungen werden in Solana-Konten übernommen * Nicht-EVM-CPI-Instruktionen werden sofort ausgeführt (die eigene Atomizität von Solana gewährleistet Korrektheit) ## Wie es weitergeht * [Compute Budget](/de/kernkonzepte/compute-budget.md) — CU-Kosten und Optimierungsstrategien * [Beschrä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.