> 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/sicherheit/known-limitations.md).

# Bekannte Einschränkungen

Aktuelle Rome-EVM-Einschränkungen und ihre Auswirkungen — nicht unterstützte Opcodes, Speicher-Account-Layout, CU-Grenzen, CPI-Tiefe und Oracle-Grenzen.

Ehrliche Dokumentation der aktuellen Einschränkungen des Rome-Protokolls und ihrer Auswirkungen.

## Ausführungseinschränkungen

**SELFDESTRUCT wird nicht unterstützt.** Der Opcode hat keinen Handler, daher bricht ein Vertrag, der ihn ausführt, die gesamte Transaktion ab (siehe unten); er führt nicht dazu, dass nur ein einzelner Frame zurückgesetzt wird.

**Ein von Rome nicht implementierter Opcode bricht die gesamte Transaktion ab.** Der Interpreter hat keinen Handler für das Byte, daher endet die Transaktion mit `IncompatibleVersionEVM(opcode)`, nichts von dem, was sie getan hat, wird übernommen, und der Fehler erreicht den Absender, statt von einem aufrufenden Vertrag geschluckt zu werden.

**Kein Gas-Schedule pro Opcode.** Der an `CALL`, `DELEGATECALL`, `STATICCALL` und `CREATE` übergebene Gaswert wird aus ABI-Kompatibilitätsgründen akzeptiert, aber nicht erzwungen – ein aufgerufener Vertrag läuft mit dem gesamten verbleibenden Budget des Aufrufers, und es gibt kein 2300-Gas-Stipendium. Stipendienbasierter Reentranzschutz (`transfer()` / `send()`) ist auf Rome wirkungslos; verwende explizite Reentranzschutzmechanismen und Checks-Effects-Interactions.

**Modexp (0x05) ist deaktiviert.** Ein Aufruf schlägt fehl mit `big_mod_exp-Aufruf ist deaktiviert` bis Solana den `big_mod_exp` Syscall.

**256 Speicher-Slots pro Speicherkonto.** Der Vertragsspeicher ist über Solana-Konten mit jeweils 256 Slots verteilt. Verträge mit großem Speicherbedarf verwenden mehrere Konten, was sich auf die CU-Kosten auswirkt.

**etwa 1,4 Mio. Recheneinheiten pro atomarer Transaktion.** Arbeit, die das Budget einer einzelnen Solana-Transaktion übersteigt, fällt auf iterative Ausführung zurück (auf mehrere Transaktionen aufgeteilt). Einige Operationen sind nur atomar möglich und können nicht iterativ ausgeführt werden — insbesondere Legacy-Track-CPI (`CpiProhibitedInIterativeTx`; Auswirkungen im Cached-Track werden gestaffelt und laufen tatsächlich iterativ).

**CPI-Tiefenlimit von 4.** Tief verschachtelte CPI-Aufrufe schlagen fehl. Entwerfen Sie Verträge mit flachen Aufrufbäumen.

## Orakel-Einschränkungen

**Keine historischen Rundendaten.** Oracle-Gateway-Adapter unterstützen nur `latestRoundData()`. Historische Preisabfragen über `getRoundData(roundId)` schlagen fehl.

**Parser-Offsets werden gegen aktuelle Layouts validiert.** Pyth- und Switchboard-Kontodaten werden anhand von Byte-Offsets geparst. Wenn Pyth oder Switchboard ihr Kontolayout ändern, liefern die Adapter falsche Daten, bis die Offsets erneut validiert wurden.

## Einschränkungen der Werkzeuge

**Kein Ethereum-ähnliches Transaktions-Tracing.** `debug_traceTransaction` und `trace_*` werden nicht unterstützt. Die einzige Trace-Methode ist `debug_traceRomeTransaction`, die eine Transaktion, die mehrere Aufrufe in einem Batch bündelt, in ihre Unteraufrufe und CPIs aufbricht. Normale Transaktionen geben `null`. Für alles andere verwende `eth_call` und die [Über den Explorer](/de/apps-auf-rome/via.md) (der die Solana-Instruktionen hinter einer Transaktion anzeigt), um Fehler zu debuggen. Siehe [JSON-RPC](/de/referenz/json-rpc.md).

**`eth_getLogs` ist auf einen Bereich begrenzt.** Öffentliche Chains lehnen zu breite Blockbereiche ab (Fehler `-32005`); begrenze deine Abfragen. Siehe [JSON-RPC](/de/referenz/json-rpc.md).

## Infrastruktureinschränkungen

**Einzelbetreiber-Modell.** Jede Rome-Bereitstellung wird von einer einzelnen Entität betrieben (dem Betreiber des Zahler-Pools). Es gibt keinen dezentralen Betreiberkreis.

**Sperrung des iterativen Modus.** Während der iterativen Ausführung werden Konten für einige Sekunden gesperrt, was bei stark genutzten Konten zu Konflikten führen kann.

## Wie es weitergeht

* [Verantwortungsvolle Offenlegung](/de/sicherheit/responsible-disclosure.md) — wie man Probleme meldet


---

# 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/sicherheit/known-limitations.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.
