Wichtige Konzepte

Wesentliche Solana- und Rome-EVM-Begriffe für Entwickler — Programme, Accounts, PDAs, CPI, SPL-Token und atomare vs. iterative Ausführung.

Wesentliche Begriffe und Konzepte für das Aufbauen auf dem Rome Protocol.

Solana-Konzepte

Programm — Solanas Gegenstück zu einem Smart Contract. 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 lebt in Konten. Jedes Konto hat einen Besitzer (Programm), ein Guthaben (Lamports) und Daten. Anders als bei Ethereum werden Code und Zustand in getrennten Konten gespeichert.

PDA (Program Derived Address) — Eine deterministische Adresse, abgeleitet aus Seeds und einer Programm-ID. PDAs erlauben es Programmen, Konten ohne privaten Schlüssel zu „besitzen“. Rome verwendet PDAs, um Ethereum-Adressen auf Solana-Konten abzubilden.

CPI (Cross-Program Invocation) — Wenn ein Solana-Programm ein anderes innerhalb derselben Transaktion aufruft. So interagieren Rome-EVM-Verträge mit Jupiter, Kamino, SPL Token und anderen Solana-Programmen.

SPL Token — Solanas Standard-Token-Programm. Das Gegenstück zu ERC-20 auf Ethereum. Alle fungiblen Token auf Solana (USDC, SOL usw.) sind SPL-Token.

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 jedem transfer_checked Aufruf ein Programm aufruft.

ATA (Associated Token Account) — Ein deterministisches Token-Konto für ein bestimmtes Wallet- und Mint-Paar. Jeder Benutzer hat ein ATA pro Token, den er hält.

Lamports — Die kleinste Einheit von SOL. 1 SOL = 1.000.000.000 Lamports (10^9).

Compute Units (CU) — Solanas Gegenstück zu Ethereum-Gas. Jede Transaktion hat ein Compute-Budget (standardmäßig ca. 200K CU, maximal ca. 1,4M CU). Operationen verbrauchen CU.

Rome-Konzepte

Rome-EVM-Programm — Das Solana-Programm, das den EVM-Bytecode-Interpreter enthält. Wird je nach Umgebung unter einer bestimmten Programm-ID bereitgestellt.

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 einzigen 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 wird, wobei jeder Schritt so viele Opcodes packt, wie in das Compute-Budget einer Solana-Transaktion passen (adaptiv, keine feste Anzahl). 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-Limit für Solana-Transaktionen überschreiten. Wird vom SDK transparent verwaltet.

StateHolder — Ein On-Chain-Konto, das serialisierten VM-Zustand zwischen Schritten der iterativen Ausführung speichert.

Rome Proxy — Der JSON-RPC-Server (Port 9090), der Ethereum-API-Aufrufe in Solana-Transaktionen übersetzt. Hier verbinden sich MetaMask und Hardhat.

Hercules — Der Block-Indexer, der die Rome-EVM-Events auf Solana überwacht und Ethereum-kompatible Blockdaten erzeugt.

Payer — Ein Solana-Keypair, das Solana-Transaktionen im Namen von EVM-Benutzern signiert und bezahlt. Wird vom Proxy über Payer-Pools verwaltet.

Token-Konzepte

SPL_ERC20 / SPL_ERC20_cached — ERC-20-Wrapper-Verträge, die ein SPL-Token innerhalb der Rome-EVM repräsentieren. Der Wrapper liest Guthaben direkt aus dem zugrunde liegenden SPL-Token-Konto — kein separater Zustand. Die Factory stellt heute die gecachte Variante bereit.

ERC20SPLFactory — Ein Factory-Vertrag, der Wrapper für beliebige SPL-Token bereitstellt.

Registry — Kanonische Wrapper, Gas-Token und Bridge-Verdrahtung werden off-chain in der rome-protocol/registry; es gibt keinen On-Chain-Token-Registry-Vertrag. Dadurch bleibt jedes Asset einer einzelnen kanonischen SPL-Mint zugeordnet.

Precompiles

Standard-Ethereum-Precompiles — ecrecover (0x01), SHA-256 (0x02), RIPEMD-160 (0x03), identity (0x04), modexp (0x05), BN254 ecAdd/ecMul/ecPairing (0x06-0x08), Blake2f (0x09).

System-Precompile (0xFF...07) — PDA-Ableitung und Base58-Konvertierung aus Solidity.

CpiProgram-Precompile (0xFF...08) — Cross-Program-Invocation (invoke / invoke_signed) sowie Abkürzungen für zustandsübergreifende Lesezugriffe.

HelperProgram-Precompile (0xFF...09) — ATA-/PDA-Erstellung, SPL-Übertragungen und Gas↔Lamports-Konvertierung; die primäre Schnittstelle für vom Benutzer-PDA-signierte SPL-Operationen.

Withdraw-Precompile (0x42...16) — SOL- oder SPL-Token aus der EVM zurück nach Solana abheben.

Eine gecachte Track-Familie (0xff…04/05/06/0b) spiegelt diese für CU-effiziente Lesezugriffe wider; ein Vertrag verwendet konsequent einen Track.

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 + native Solana-Anweisungen in einer atomaren Operation. Der mächtigste Typ — mische Solidity und Solana in einer einzigen Transaktion.

Wie geht es weiter

• Ausführungsmodell — tiefgehender Einblick, wie EVM-Transaktionen auf Solana ausgeführt werden

• Token-Interop — wie ERC-20- und SPL-Token interagieren

• Einschränkungen — wichtige Grenzen und Beschränkungen