> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/de/erste-schritte/key-concepts.md).

# Wichtige Konzepte

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](https://github.com/rome-protocol/rome-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](/de/kernkonzepte/execution-model.md) — tiefgehender Einblick, wie EVM-Transaktionen auf Solana ausgeführt werden
* [Token-Interop](/de/kernkonzepte/token-interop.md) — wie ERC-20- und SPL-Token interagieren
* [Einschränkungen](/de/kernkonzepte/constraints.md) — wichtige Grenzen und Beschränkungen


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/de/erste-schritte/key-concepts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.