Architektur

Wie die Komponenten von Rome zusammenpassen — EVM-Ausführung innerhalb eines Solana-Programms.

Rome bettet einen EVM-Bytecode-Interpreter in ein Solana-Programm auf der Kette ein. Benutzer kommunizieren mit dem Rome Proxy über das standardmäßige Ethereum-JSON-RPC, und der Proxy sendet ihre Transaktionen direkt an das Rome-EVM-Programm auf Solana. Es gibt keine separate Ausführungsschicht, die synchron gehalten werden muss — EVM-Status ist Solana-Zustand.

Systemübersicht

Komponenten

Rome EVM-Programm (on-chain)

Der Kern von Rome — ein Solana-BPF-Programm, das einen vollständigen EVM-Bytecode-Interpreter enthält (ein Fork von SputnikVM). Es:

• Empfängt serialisierte EVM-Transaktionen als Solana-Instruktionen

• Führt Solidity-Bytecode innerhalb der Solana-Runtime aus

• Ordnet jede Ethereum-Adresse (H160) einem Solana-PDA zu

• Stellt Precompiles für Aufrufe in Solana hinein bereit (CPI, System, Helper, Withdraw) neben den standardmäßigen Ethereum-Precompiles

• Speichert den EVM-Zustand (Kontostände, Nonce, Code, Speicher) als Solana-Kontodaten

Rome Proxy (JSON-RPC-Server)

Ein standardmäßiger Ethereum-JSON-RPC-Server auf Port 9090 — der Einstiegspunkt für die öffentlichen Chains. Er übersetzt Ethereum-API-Aufrufe in Solana-Aktivität:

• eth_sendRawTransaction → EVM-Tx serialisieren → eine Solana-Instruktion senden

• eth_call → Ausführung off-chain über den Mollusk-SVM-Emulator emulieren

• eth_estimateGas → zur Gas-Schätzung simulieren

• eth_getBalance, eth_getCode, eth_getBlockByNumber, Belege, Logs → werden aus dem indexierten Zustand bereitgestellt

Er stellt außerdem Rome-Erweiterungen bereit: rome_emulateTx, rome_emulateRegRollup, rome_mintId, rome_buildInfo, rome_getResources, und mehr.

Hercules (Indexer)

Überwacht das Rome-EVM-Programm auf Solana und rekonstruiert Ethereum-kompatible Blöcke — Transaktionen, Belege, Logs und Zustandsänderungen — gestützt auf PostgreSQL. Auf den öffentlichen Chains läuft es im slot-ausgerichteten Modus, sodass eine Blocknummer einem Solana-Slot entspricht und derselbe Slot auf jedem Indexer denselben Block ergibt. Der Proxy stellt diese Blöcke Wallets und Explorern bereit.

Precompiles

Rome implementiert die standardmäßigen Ethereum-Precompiles (ecrecover, SHA-256, RIPEMD-160, identity, modexp, die BN254-Kurvenoperationen, blake2f) mit Mainnet-äquivalenter Semantik, plus Nicht-EVM-Precompiles, die in Solana hineinreichen: CpiProgram (0xFF…08, beliebiges CPI), System (0xFF…07, PDA-Ableitung und Base58-Helfer), HelperProgram (0xFF…09, ATA-/PDA-Erstellung, SPL-Transfers, Gas↔Lamports), und Withdraw (0x42…16). Siehe die Vertragsadressen Referenz für die vollständige Tabelle.

Ausführungsmodi

Rome führt eine EVM-Transaktion auf eine von zwei Arten aus:

Atomar (VmAt)

Eine einzelne Solana-Transaktion. Die gesamte EVM-Transaktion wird innerhalb des Compute-Budgets einer einzelnen Solana-Transaktion ausgeführt (~1,4 Mio. Compute-Units). Wird für die meisten Operationen verwendet — Überweisungen, gewöhnliche Vertragsaufrufe, Swaps.

Iterativ (VmIt)

Für Arbeit, die das Budget einer einzelnen Transaktion überschreitet. Die Ausführung wird auf mehrere Solana-Transaktionen aufgeteilt:

1. Jeder Schritt (eine Solana-Transaktion) führt so viele EVM-OpCodes aus, wie in das Compute-Budget passen — die Schrittgröße ist adaptiv, nicht fest

2. Der VM-Zustand wird zwischen den Schritten Borsh-serialisiert in ein StateHolder Konto

3. Konten werden während der Ausführung für einige Sekunden per TTL gesperrt

4. Wird für schwere Operationen wie BN254-Pairing verwendet

Kontozuordnung

Jede Ethereum-Adresse wird deterministisch einem Solana-PDA zugeordnet, das von der Chain-ID und der Adresse unter dem Rome-EVM-Programm abgeleitet ist. Dieses PDA besitzt den Kontostand des Kontos (als SPL-Token-Konten), den Vertragscode, Speicher-Slots und die Nonce — alles als Solana-Kontodaten.

Holder-Konten

Solana-Transaktionen sind auf 1.232 Bytes begrenzt, aber EVM-Transaktionen (insbesondere Vertragsbereitstellungen) können viel größer sein. Rome lagert große Transaktionen in Holder-Konten: Die Transaktion wird in Chunks aufgeteilt, die sequenziell in einen Holder geschrieben werden (bis zu 80 KB), dann on-chain zusammengesetzt und ausgeführt. Das Rome SDK verwaltet dies transparent.

Gas und Preisgestaltung

Jede Chain hat ihr eigenes Gas-Token — beliebiges SPL-Token. Die Gas-Preisgestaltung liest einen Meteora-DAMM-Pool (v1 oder v2, konfigurierbar), um zwischen dem Gas-Token und SOL für die zugrunde liegenden Solana-Transaktionsgebühren zu konvertieren.

Was kommt als Nächstes

• Netzwerke — verbinde dich mit Martius oder Hadrian

• Schnellstart — stelle deinen ersten Vertrag bereit

• Ausführungsmodell — atomare vs. iterative Ausführung im Detail