# 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](/de/erste-schritte/quickstart.md) — dein erstes Smart Contract bereitstellen * [Ausführungsmodell](/de/grundlegende-konzepte/execution-model.md) — Tiefgang in atomare vs. iterative Ausführung * [Compute-Budget](/de/grundlegende-konzepte/compute-budget.md) — Verständnis von CU-Kosten und Optimierung --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.rome.builders/de/erste-schritte/architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.