> 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/kernkonzepte/constraints.md). # Einschränkungen Grenzen beim Entwickeln auf Rome EVM — Solana-Transaktionsgröße, Budget von \~1,4 Mio. CU, Account-Grenzen, Speicher-Layout und wie Rome jede davon umgeht. Wichtige Grenzen und Beschränkungen beim Bauen auf Rome EVM. Das Verständnis dieser Einschränkungen hilft Ihnen, Verträge zu entwerfen, die zuverlässig funktionieren. ## Solana-Transaktionslimits | Einschränkung | Wert | Auswirkung | | --------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Transaktionsgröße | 4 KB (4.096 Byte) | Rome sendet Solana-v1-Transaktionen; größere EVM-TXs werden in Holder-Konten zwischengelagert (transparent) | | Compute-Units pro TX | \~1,4 Mio. CU | Operationen, die dies überschreiten, verwenden den iterativen Modus, der seine eigenen Limits hat (unten) | | Konten pro TX | 64 Adressen | Das v1-Transaktionslimit; alles, was die EVM-TX und ihre CPIs berühren, einschließlich der eigenen Konten von Rome, zählt mit | | Maximale Holder-Größe | 80 KB | Maximale RLP-Größe für eine einzelne EVM-Transaktion | ## EVM-Ausführungslimits | Einschränkung | Wert | Hinweise | | ------------------------------------------------ | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Contract-Storage-Slots | 256 pro Storage-Konto | Pro Contract können mehrere Storage-Konten erstellt werden | | Opcodes pro Iteration | Adaptiv | An das CU-Budget jeder Solana-TX angepasst (VmIt) | | TTL für Kontensperren | 3 s (4 s, wenn die Sitzung mehr als 28 Konten berührt) | Während der iterativen Ausführung; bei jedem Schritt erneuert | | Länge der iterativen Sitzung | 160 Schritte | Jenseits des Limits gibt der nächste Schritt die Sperren der Sitzung frei und beendet sie, ohne etwas zu committen | | Legs, geplant vom Rust-Rome-SDK | 128 | Die Obergrenze des iterativen Composers; reale Aufrufe landen weit darunter | | Transaktionen pro von der Wallet signiertem Plan | 64 | Das Maximum `rome_submitSignedV1Plan` in einem Aufruf akzeptiert; siehe [Weitergeleitete Aufrufe und lange Aufrufe](/de/entwicklerleitfaden/call-evm-from-solana.md#relayed-calls-and-long-calls) | | Treasury-Wallets | 64 | Gebührenpool-Wallets | | Contract-Größenlimit | 24 KB | Dasselbe wie bei Ethereum (EIP-170, 24.576 Byte) | ## CPI-Beschränkungen | Einschränkung | Wert | Hinweise | | ------------------------------ | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | CPI-Tiefe | max. 4 Ebenen | Solanas CPI-Tiefenlimit | | Konten pro CPI-Aufruf | Innerhalb des Transaktionslimits von 64 Adressen | Wird mit jedem anderen Konto geteilt, das die Transaktion berührt | | CPI- + Transfer-Hook-Tiefe | Verwendet CPI-Ebenen | Transfer-Hooks innerhalb von CPI können die Tiefe überschreiten | | Ein Pfad pro Contract | Legacy (`0xff…07/08/09`, `0x42…16`) **oder** gecached (`0xff…04/05/06/0b`) | Das Mischen verändernder Aufrufe aus beiden in einer Transaktion wird abgelehnt | | Legacy-CPI im iterativen Modus | Nicht erlaubt | Eine Legacy-Pfad-CPI in einer iterativen Transaktion schlägt fehl mit `CpiProhibitedInIterativeTx`; Effekte des Cache-Pfads sind erlaubt | **Die CPI-Tiefe ist die kritischste Beschränkung.** Rome EVM verbraucht eine CPI-Ebene, wenn Solana das Rome-Programm aufruft. Wenn Ihr Solidity-Contract dann über CPI ein weiteres Solana-Programm aufruft, ist das Ebene 2. Wenn dieses Programm ein weiteres aufruft, ist das Ebene 3. Insgesamt haben Sie höchstens 4 Ebenen. ``` Ebene 0: Solana Runtime → Rome EVM Program Ebene 1: Rome EVM Program → Ihr CPI-Ziel (z. B. Jupiter) Ebene 2: Jupiter → ein anderes Programm (z. B. Raydium) Ebene 3: Raydium → SPL Token (maximale Tiefe) ``` ## Beschränkungen für Token-2022-Transfer-Hooks | Einschränkung | Auswirkung | | ------------------------ | ------------------------------------------------------------------------------------------------ | | Ein Hook pro Mint | Ein Token-2022-Mint hat einen einzelnen Transfer-Hook-Slot | | `transfer_checked` nur | Hooks werden bei einem normalen `transfer`. Rome-Bridge-Operationen verwenden `transfer_checked` | | Mint/Burn nicht per Hook | Wird über die Mint-Authority gesteuert, nicht über Hooks | ## Gas- und Preisbeschränkungen | Einschränkung | Hinweise | | -------------------------- | ------------------------------------------------------------------ | | Quelle der Gaspreisbildung | Meteora-DAMM-Pool, v1 oder v2 (SPL-Gas-Token) | | Gaspreis-Multiplikator | Konfigurierbar pro Proxy (`gas_price_mul`) | | Mindestgaspreis | Durch die Proxy-Konfiguration festgelegt | | Gasabschätzung | Wird vor dem Senden offline über den Mollusk-Emulator durchgeführt | ## Netzwerkspezifische Beschränkungen | Umgebung | Chain-ID | rome-evm-Programm-ID | | ----------------- | -------- | --------------------------------------------- | | Hadrian (Testnet) | 200010 | `RPTWwELXAY4KC9ZPHhaxp7Sq1hHtU3HNEgLbSegCcWf` | | Rubicon (Mainnet) | 7531 | `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX` | ## Beschränkungen für Precompiles | Precompile | Einschränkung | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Modexp (0x05) | **Deaktiviert** — ein Aufruf revertiert mit `big_mod_exp-Aufruf ist deaktiviert` bis Solana den `big_mod_exp` Syscall | | BN254 ecPairing (0x08) | Etwa 22K CU plus 12,8K pro Paar gemäß der Preisgestaltung des Programms; eine Prüfung mit vier Paaren passt in eine atomare Transaktion | | CPI-Precompile (0xFF...08) | Konten müssen in der Solana-Transaktion im Voraus deklariert werden | ## Transaktionsvalidierung | Regel | Auswirkung | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Signatur-Malleabilität (EIP-2) | Eine signierte Transaktion, deren `s` oberhalb der Hälfte der Kurvenordnung liegt, wird abgelehnt | | RLP-Form | Eine Transaktion, deren RLP-Liste nach ihrem letzten Eintrag noch nachgestellte Bytes enthält, wird abgelehnt | | Nicht implementierter Opcode | Bricht die gesamte Transaktion ab (`IncompatibleVersionEVM(opcode)`); nichts wird committet und ein aufrufender Contract kann ihn nicht abfangen | | Gas-Metering | Rome hat keinen Gasplan pro Opcode: Das an `CALL`/`CREATE` weitergegebene Gas wird nicht durchgesetzt, und es gibt kein 2300-Gas-Stipendium — verlassen Sie sich nicht auf stipendienbasierte Reentrancy-Schutzmechanismen | ## Oracle-Beschränkungen | Einschränkung | Wert | | ----------------------------------- | ---------------------------------------------------------------------- | | Standardmäßige maximale Veralterung | 60 Sekunden | | Historische Rundendaten | Nicht unterstützt — `getRoundData(roundId)` revertiert | | Switchboard EMA | Nicht unterstützt — `latestEMAData()` revertiert bei SwitchboardV3 | | Parser-Offsets | Empirisch validiert — vor einer erneuten Bereitstellung neu validieren | ## Designempfehlungen 1. **Halten Sie die CPI-Tiefe flach.** Entwerfen Sie Contracts so, dass Verschachtelungen minimiert werden. Wenn Sie Jupiter aufrufen, das Raydium aufruft, das wiederum SPL Token aufruft, sind Sie bei 3 Ebenen — gefährlich nahe am Limit. 2. **Bevorzugen Sie den atomaren Modus.** Entwerfen Sie Operationen so, dass sie in \~1,4 Mio. CU passen. Der iterative Modus fügt Latenz hinzu (3-4 Sekunden Sperren), ein Limit von 160 Iterationen pro Sitzung und eine Wallet-Abfrage pro Leg auf der Solana-Schiene, wenn die Wallet die Legs selbst signiert. Ein Aufruf, der Legacy-Pfad-CPIs ausführt, kann überhaupt nicht iterativ laufen. 3. **Deklarieren Sie Konten im Voraus.** Alle Solana-Konten, die per CPI berührt werden, müssen zum Zeitpunkt der Transaktionserstellung bekannt sein (die Emulation des Proxys entdeckt sie). Eine dynamische Kontenerkennung innerhalb eines CPI-Aufrufs ist nicht möglich, und die Gesamtsumme muss in das Limit von 64 Adressen passen. 4. **Wählen Sie pro Contract einen Precompile-Pfad.** Das Aufrufen eines benutzerdefinierten Solana-Programms (`invoke_signed`) ist Legacy-Pfad und nur atomar; siehe [Integrieren Sie ein Solana-Programm](/de/entwicklerleitfaden/integrate-solana-program.md). 5. **Verwenden Sie `transfer_checked`.** Wenn Sie etwas bauen, das Token-2022-Token berührt, verwenden Sie immer `transfer_checked` um sicherzustellen, dass Hooks ausgelöst werden. 6. **Testen Sie den CU-Verbrauch.** Messen Sie die tatsächlichen Solana-Compute-Units aus dem Transaktionsbeleg (`computeUnitsConsumed`) — EVM `gasUsed` ist kein zuverlässiger Stellvertreter für Solana CU. Optimieren Sie Hot Paths mit Yul. ## Wie es weitergeht * [Compute Budget](/de/kernkonzepte/compute-budget.md) — detaillierte CU-Kosten pro Operation * [Token-Interop](/de/kernkonzepte/token-interop.md) — ERC-20 ↔ SPL-Bridging-Modell * [Precompile-Referenz](/de/referenz/precompiles.md) — jeder Selektor und seine Dispatch-Klasse --- # 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/kernkonzepte/constraints.md?ask=&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.