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

• Einschränkungen — wichtige Grenzen und Beschränkungen

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