# Wichtige Konzepte Wesentliche Terminologie und Konzepte für das Bauen auf dem Rome-Protokoll. ## Solana-Konzepte **Programm** — Das Äquivalent eines Smart Contracts bei Solana. Programme sind zustandslose ausführbare Programme, die On-Chain bereitgestellt werden. Das Rome EVM selbst ist ein Solana-Programm. **Konto** — Der gesamte Zustand auf Solana befindet sich in Konten. Jedes Konto hat einen Eigentümer (Programm), einen Saldo (Lamports) und Daten. Im Gegensatz zu Ethereum werden Code und Zustand in separaten Konten gespeichert. **PDA (Program Derived Address)** — Eine deterministische Adresse, die aus Seeds und einer Programm-ID abgeleitet wird. PDAs ermöglichen es Programmen, Konten ohne privaten Schlüssel zu „besitzen“. Rome verwendet PDAs, um Ethereum-Adressen Solana-Konten zuzuordnen. **CPI (Cross-Program Invocation)** — Wenn ein Solana-Programm ein anderes innerhalb derselben Transaktion aufruft. So interagieren Rome-EVM-Contracts mit Jupiter, Kamino, SPL Token und anderen Solana-Programmen. **SPL Token** — Das Standard-Token-Programm von Solana. Das Pendant zu ERC-20 auf Ethereum. Alle fungiblen Tokens auf Solana (USDC, SOL usw.) sind SPL-Tokens. **Token-2022** — Das SPL-Token-Programm der nächsten Generation mit Erweiterungen wie Transfer Hooks, Confidential Transfers und Permanent Delegates. **Transfer Hook** — Eine Token-2022-Erweiterung, die bei jeder Token-Übertragung ein Programm aufruft. Rome ermöglicht es EVM-Smart-Contracts, als Transfer Hooks zu fungieren. **ATA (Associated Token Account)** — Ein deterministisches Token-Konto für ein bestimmtes Wallet- und Mint-Paar. Jeder Benutzer hat pro Token, den er hält, ein ATA. **Lamports** — Die kleinste Einheit von SOL. 1 SOL = 1.000.000.000 Lamports (10^9). **Compute Units (CU)** — Das Äquivalent von Ethereum-Gas bei Solana. Jede Transaktion hat ein Compute-Budget (standardmäßig \~200K CU, maximal \~1,4M CU). Operationen verbrauchen CU. ## Rome-Konzepte **Rome EVM-Programm** — Das Solana-Programm, das den EVM-Bytecode-Interpreter enthält. Bereitgestellt unter einer bestimmten Programm-ID pro Umgebung. **Chain-ID** — Jede Anwendung auf Rome erhält ihre eigene EVM-Chain-ID. Dadurch entstehen isolierte EVM-Umgebungen, die denselben zugrunde liegenden Solana-Zustand teilen. **Atomare Ausführung (VmAt)** — Eine EVM-Transaktion, die vollständig innerhalb einer einzelnen Solana-Transaktion ausgeführt wird. Wird für die meisten Operationen verwendet. **Iterative Ausführung (VmIt)** — Eine EVM-Transaktion, die über mehrere Solana-Transaktionen aufgeteilt ist und pro Schritt etwa 500 Opcodes ausführt. Wird für rechenintensive Operationen wie BN254 Pairing verwendet. **Holder-Konto** — Ein On-Chain-Puffer, der große EVM-Transaktionen (bis zu 80 KB) speichert, die das 1.232-Byte-Transaktionslimit von Solana überschreiten. Wird vom SDK transparent verwaltet. **StateHolder** — Ein On-Chain-Konto, das serialisierten VM-Zustand zwischen iterativen Ausführungsschritten speichert. **Rome Proxy** — Der JSON-RPC-Server (Port 9090), der Ethereum-API-Aufrufe in Solana-Transaktionen übersetzt. Hier verbinden sich Ihr MetaMask und Hardhat. **Hercules** — Der Block-Indexer, der Rome-EVM-Ereignisse auf Solana überwacht und Ethereum-kompatible Blockdaten erzeugt. **Rhea** — Die Mempool-Brücke, die Transaktionen von OP-Geth an Solana weiterleitet (wird nur im OP-Geth-Modus verwendet). **Zahler** — Ein Solana-Keypair, das Solana-Transaktionen im Namen von EVM-Benutzern signiert und bezahlt. Wird vom Proxy über Zahler-Pools verwaltet. ## Token-Konzepte **ERC20SPL** — Ein ERC-20-Wrapper-Contract, der einen SPL-Token innerhalb des Rome EVM repräsentiert. Der Wrapper liest Salden direkt aus dem zugrunde liegenden SPL-Token-Konto — kein separater Zustand. **ERC20SPLFactory** — Ein Factory-Contract, der bei der ersten Bridge ERC20SPL-Wrapper für beliebige SPL-Tokens bereitstellt. **Kanonische Token-Registrierung** — Ordnet jedem Asset einen einzigen kanonischen SPL-Mint zu, um fragmentierte Repräsentationen zu verhindern (z. B. wird USDC immer dem nativen SPL-Mint von Circle zugeordnet). ## Precompiles **Standard-Ethereum-Precompiles** — ecrecover (0x01), SHA-256 (0x02), RIPEMD-160 (0x03), identity (0x04), BN254 ecAdd/ecMul/ecPairing (0x06-0x08), Blake2f (0x09). **Systemprogramm-Precompile** (`0xFF...07` ) — PDA-Ableitung, Base58-Konvertierung, Kontoerstellung aus Solidity. **CPI-Precompile** (`0xFF...08` ) — Cross-Program Invocation aus Solidity. Rufe jedes Solana-Programm mit `invoke()` oder `invoke_signed()`. **Withdraw-Precompile** (`0x42...16` ) — SOL oder SPL-Tokens von EVM zurück nach Solana abheben. ## Transaktionstypen **RheaTx** — Eine einzelne EVM-Transaktion auf einem Rollup. Der häufigste Typ. **RemusTx** — Mehrere EVM-Transaktionen über verschiedene Rollups hinweg, atomar ausgeführt. Wenn eine Transaktion fehlschlägt, werden alle zurückgesetzt. **RomulusTx** — Kombinierte EVM-Transaktionen und native Solana-Anweisungen in einer einzigen atomaren Operation. Der leistungsstärkste Typ — mische Solidity und Solana in einer einzigen Transaktion. ## Bereitstellungsmodi **Single-State-Modus** — Benutzer verbinden sich direkt mit dem Rome Proxy. Einfacheres Setup, geringere Latenz. EVM-Blöcke werden von Hercules erzeugt und in PostgreSQL gespeichert. **OP-Geth-Modus** — Benutzer verbinden sich mit OP-Geth für volle Ethereum-RPC-Kompatibilität. Rhea überbrückt den Mempool zu Solana. Hercules speist Blöcke über die Engine API in OP-Geth ein. ## Was kommt als Nächstes * [Ausführungsmodell](/de/grundlegende-konzepte/execution-model.md) — Ein tiefer Einblick, wie EVM-Transaktionen auf Solana ausgeführt werden * [Token-Interop](/de/grundlegende-konzepte/token-interop.md) — wie ERC-20- und SPL-Tokens miteinander interagieren * [Einschränkungen](/de/grundlegende-konzepte/constraints.md) — wichtige Grenzen und Beschränkungen --- # 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/key-concepts.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.