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 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 — CU-Kosten und Optimierungsstrategien

• Einschränkungen — wichtige Limits und Grenzen