Architektur

Rome Protocol bettet einen EVM-Bytecode-Interpreter in ein On-Chain-Programm auf Solana ein. Diese Seite erklärt, wie die Komponenten zusammenwirken.

Systemübersicht

┌─────────────────────────────────────────────────────────────────┐
│                        Benutzerschicht                          │
│   MetaMask / ethers.js / Hardhat / Foundry                      │
│   (Standard Ethereum JSON-RPC)                                  │
└──────────────────────┬──────────────────────────────────────────┘
                       │
            ┌──────────┴──────────┐
            ▼                     ▼
   ┌────────────────┐    ┌────────────────┐
   │  Rome-Proxy    │    │   OP-Geth      │
   │  (:9090)       │    │   (:8545)      │
   │  JSON-RPC      │    │   EVM-RPC      │
   └───────┬────────┘    └───────┬────────┘
           │                     │
           │              ┌──────┴──────┐
           │              │    Rhea     │  (leitet Geth-TXs an Solana weiter)
           │              └──────┬──────┘
           │                     │
           └──────────┬──────────┘
                      ▼
   ┌──────────────────────────────────────────────────────────────┐
   │                    Solana-Laufzeit                            │
   │                                                              │
   │   ┌──────────────────────────────────────────────────┐       │
   │   │              Rome EVM-Programm                   │       │
   │   │                                                   │       │
   │   │   EVM-Bytecode-Interpreter (SputnikVM-Fork)      │       │
   │   │   Adresszuordnung: H160 → Solana PDA             │       │
   │   │   Precompiles: ecrecover, BN254, SPL, CPI, usw.  │       │
   │   └───────────────────────┬───────────────────────────┘       │
   │                           │ CPI                               │
   │   ┌───────────┬───────────┼───────────┬───────────┐          │
   │   │SPL Token  │ Jupiter   │ Kamino    │ Meteora   │  ...     │
   │   └───────────┴───────────┴───────────┴───────────┘          │
   └──────────────────────────────────────────────────────────────┘
                      ▲
                      │ Indiziert Ereignisse
               ┌──────┴──────┐
               │  Hercules   │  (Block-Indexer → Engine API → OP-Geth)
               └─────────────┘

Komponenten

Rome EVM-Programm (On-Chain)

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

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

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

• Ordnet Ethereum-Adressen (H160) Solana PDAs zu

• Stellt Precompile-Schnittstellen für CPI, SPL Token, System Program bereit

• Verwaltet den EVM-Zustand (Contract-Speicher, Salden, Nonce) als Solana-Kontodaten

Rome-Proxy (JSON-RPC-Server)

Ein standardmäßiger Ethereum-JSON-RPC-Server auf Port 9090, der Ethereum-API-Aufrufe in Solana-Transaktionen übersetzt:

• eth_sendRawTransaction → EVM-TX serialisieren → Solana-Instruktion übermitteln

• eth_call → EVM-Ausführung off-chain emulieren (via Mollusk-SVM-Emulator)

• eth_estimateGas → Ausführung zur Gas-Schätzung simulieren

• eth_getBalance, eth_getCode, usw. → aus Solana-Kontodaten lesen

Rome-Erweiterungen: rome_emulateTx, rome_emulateRegRollup, rome_mintId, rome_buildInfo, rome_getResources.

OP-Geth (optionale EVM-RPC-Schicht)

Ein modifizierter Go-Ethereum-Client, der vollständige Ethereum-RPC-Kompatibilität bereitstellt. Im op-geth-Modus:

1. Benutzer senden Transaktionen an OP-Geth (:8545)

2. Rhea leitet Transaktionen an Rome Proxy → Solana weiter

3. Hercules indiziert Solana-Ereignisse und speist EVM-Blöcke über die Engine API (:8551) in OP-Geth ein

Im Single-State-Modus verbinden sich Benutzer direkt mit Rome Proxy (:9090) und umgehen OP-Geth vollständig.

Hercules (Indexer)

Überwacht das Rome EVM-Programm auf Solana und erzeugt EVM-kompatible Blockdaten:

• Beobachtet Ereignisse des Rome-Programms auf Solana

• Rekonstruiert EVM-Blöcke mit Transaktions-Receipts, Logs und Zustandsänderungen

• Speist Blöcke über die Engine API in OP-Geth ein, für Standard-Kompatibilität mit Block-Explorern

• Unterstützt durch PostgreSQL

Rhea (Mempool-Bridge)

Verbindet den OP-Geth-Mempool mit Solana:

• Liest ausstehende Transaktionen aus dem Mempool von OP-Geth

• Verpackt sie als Solana-Instruktionen, die auf das Rome EVM-Programm zielen

• Sendet sie zur Ausführung an Solana

Ausführungsmodi

Rome unterstützt zwei Ausführungsmodi für EVM-Transaktionen:

Atomare Ausführung (VmAt)

Eine einzelne Solana-Transaktion. Die gesamte EVM-Transaktion wird innerhalb des Compute-Budgets einer Solana-Transaktion ausgeführt (~1,4 Mio. Compute-Units). Wird für die meisten Vorgänge verwendet — Transfers, einfache Contract-Aufrufe, Swaps.

Iterative Ausführung (VmIt)

Für rechenintensive Vorgänge, die das Budget einer einzelnen Transaktion überschreiten. Die EVM-Ausführung wird auf mehrere Solana-Transaktionen aufgeteilt:

1. Jeder Schritt führt ~500 EVM-OpCodes aus

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

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

4. Wird für schwere Vorgänge wie BN254-Pairing (ZK-Proof-Verifikation) verwendet

Account-Zuordnung

Jede Ethereum-Adresse (20 Bytes) wird auf eine Solana PDA (32 Bytes) abgebildet, abgeleitet vom Rome EVM-Programm:

Ethereum-Adresse (H160) → PDA = findProgramAddress([address], ROME_EVM_PROGRAM)

Diese PDA besitzt die folgenden Kontodaten:

• ETH-/Token-Guthaben (als SPL-Token-Konten)

• Contract-Bytecode (gespeichert in Solana-Kontodaten)

• Contract-Speicher-Slots (gespeichert in Solana-Kontodaten)

• Nonce

Holder-Accounts

Solana-Transaktionen sind auf 1.232 Bytes begrenzt. EVM-Transaktionen (insbesondere Contract-Deployments) können viel größer sein. Rome löst dies mit Holder-Konten:

1. Große EVM-Transaktionen werden in Blöcke aufgeteilt

2. Die Blöcke werden sequenziell in ein Holder-Konto zwischengespeichert (max. 80 KB)

3. Sobald alle Blöcke geschrieben sind, wird die vollständige Transaktion zusammengesetzt und ausgeführt

4. Dies wird transparent vom Rome SDK verwaltet

Gas und Preisgestaltung

Jede Anwendung (Chain-ID) auf Rome hat ihren eigenen Gas-Token — irgendein SPL-Token. Die Gas-Preisgestaltung verwendet Meteora-DAMM-V1-Pools, um zwischen dem Gas-Token und SOL für die zugrunde liegenden Solana-Transaktionsgebühren zu konvertieren.

Bereitstellungsmodi

Modus	Datenfluss	Anwendungsfall
OP-Geth-Modus	Benutzer → OP-Geth → Rhea → Proxy → Solana; Hercules indiziert zurück	Vollständige Ethereum-RPC-Kompatibilität
Single-State-Modus	Benutzer → direkt Proxy → Solana	Einfachere Bereitstellung, geringere Latenz

Was kommt als Nächstes

• Quickstart — dein erstes Smart Contract bereitstellen

• Ausführungsmodell — Tiefgang in atomare vs. iterative Ausführung

• Compute-Budget — Verständnis von CU-Kosten und Optimierung