Ausführungsmodell

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

Lebenszyklus der 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 Konten
                    ↓
4. Proxy verpackt EVM-Tx als Solana-Instruction(s)
   → 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 Instruction(s) aus
   → Rome-EVM-Programm interpretiert EVM-Bytecode
   → CPI-Aufrufe an andere Solana-Programme (falls vorhanden)
                    ↓
6. Zustandsä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, 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 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 eine StateHolder Konto

3. Der nächste Schritt deserialisiert den Zustand und setzt die Ausführung fort

4. Beteiligte Konten werden per TTL gesperrt für 3-4 Sekunden während der mehrstufigen Ausführung

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

Kontosperrung:

• RoLock (gemeinsam, nur lesend) — Mehrere iterative Transaktionen können gleichzeitig gehalten werden

• 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-Pairing-Verifikation, 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 im Emulator-Code 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.

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, Saldo, 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-Konten

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

Aufteilungsmechanismus:

1. Das SDK teilt die RLP-kodierte Transaktion in Chunks auf

2. Jeder Chunk wird in ein TxHolder Konto geschrieben via TransmitTx Instructions

3. Sobald alle Chunks zwischengespeichert sind, DoTxHolder Instruction die vollständige Transaktion zusammenfügt 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 erneute Zusammensetzen automatisch.

Unterstützte Transaktionstypen

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

Journalierter Zustand

Rome EVM verwendet ein journaliertes Zustandsmodell zur Verwaltung von Zustandsä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ückgesetzt

• Bei Erfolg: Änderungen werden in Solana-Konten übernommen

• Nicht-EVM-CPI-Instructionen werden sofort ausgeführt (Solanas eigene Atomaritätsgarantien sichern die Korrektheit)

Was kommt als Nächstes

• Compute Budget — CU-Kosten und Optimierungsstrategien

• Einschränkungen — wichtige Limits und Grenzen

• Lebenszyklus der Transaktion — detaillierte Schritt-für-Schritt-Anleitung