> 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).

# Schlüsselkonzepte

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

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

## Solana-Konzepte

**Programm** — Das Solana-Äquivalent eines Smart Contracts. 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 Eigentümer (Programm), ein Guthaben (Lamports) und Daten. Anders als bei 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-Verträge mit Jupiter, Kamino, SPL Token und anderen Solana-Programmen.

**SPL Token** — Das Standard-Token-Programm von Solana. Das Äquivalent 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-Mint-Paar. Jeder Nutzer hat ein ATA pro gehaltenem Token.

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

**Compute Units (CU)** — Das Solana-Äquivalent 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 Program** — Das Solana-Programm, das den EVM-Bytecode-Interpreter enthält. Wird pro 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. 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 Account** — Ein On-Chain-Puffer, der große EVM-Transaktionen (bis zu 80 KB) speichert, die das 4-KB-Grenzlimit für Solana-(v1)-Transaktionen ü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 umwandelt. Ihr MetaMask und Hardhat verbinden sich hier.

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

**Payer** — Ein Solana-Keypair, das Solana-Transaktionen im Namen von EVM-Nutzern 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 des Rome EVM repräsentieren. Bei einem Wallet liest der Wrapper den Kontostand direkt aus dem zugrunde liegenden SPL-Token-Konto. Von einem Vertrag gehaltene Token liegen im eigenen Escrow-Token-Konto des Wrappers und werden im Speicher des Wrappers nachverfolgt (siehe [Integrieren Sie ein Solana-Programm](/de/entwicklerleitfaden/integrate-solana-program.md)). Die Factory stellt heute die gecachte Variante bereit.

**ERC20SPLFactory** — Ein Factory-Vertrag, der Wrapper für jedes 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)kuratiert; es gibt keinen On-Chain-Token-Registry-Vertrag. Dadurch wird jedes Asset einer einzelnen kanonischen SPL-Mint-Adresse 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-Umwandlung aus Solidity.

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

**HelperProgram-Precompile** (`0xFF...09`) — ATA/PDA-Erstellung, SPL-Überweisungen und Umrechnung von Gas in Lamports und zurück; die primäre Oberfläche für vom Nutzer-PDA-signierte SPL-Operationen.

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

Eine Familie von Cached-Tracks (`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ückgerollt.

**RomulusTx** — Kombinierte EVM-Transaktionen plus native Solana-Instruktionen in einer atomaren Operation. Der leistungsstärkste Typ — mischt Solidity und Solana in einer einzigen Transaktion.

## Wie es weitergeht

* [Ausführungsmodell](/de/kernkonzepte/execution-model.md) — Vertiefung dazu, wie EVM-Transaktionen auf Solana ausgeführt werden
* [Token-Interop](/de/kernkonzepte/token-interop.md) — wie ERC-20- und SPL-Token miteinander interagieren
* [Beschrä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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.