> 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 Wichtige Grenzen und Beschränkungen beim Erstellen 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 | 1.232 Bytes | Große EVM-Transaktionen werden auf Holder-Konten aufgeteilt (transparent) | | Compute Units pro Tx | \~1,4 Mio. CU | Operationen, die diesen Wert überschreiten, verwenden den iterativen Modus | | Konten pro Tx (ohne ALT) | 28 | Verwenden Sie Address Lookup Tables für mehr | | Konten pro Tx (mit ALT) | 64+ | ALT wird automatisch verwendet, wenn > 28 Konten vorhanden sind | | Maximale Holder-Größe | 80 KB | Maximale RLP-Größe für eine einzelne EVM-Transaktion | ## EVM-Ausführungslimits | Einschränkung | Wert | Hinweise | | --------------------------- | --------------------- | --------------------------------------------------------- | | Speicher-Slots des Vertrags | 256 pro Storage-Konto | Pro Vertrag können mehrere Storage-Konten erstellt werden | | Opcodes pro Iteration | Adaptiv | An das CU-Budget jeder Solana-Tx angepasst (VmIt) | | TTL der Kontensperre | 3–4 Sekunden | Während der iterativen Ausführung | | Treasury-Wallets | 64 | Gebührenpool-Wallets | | Vertragsgrößenlimit | 24 KB | Wie bei Ethereum (EIP-170, 24.576 Bytes) | ## CPI-Einschränkungen | Einschränkung | Wert | Hinweise | | -------------------------- | ---------------------------------- | --------------------------------------------------------------- | | CPI-Tiefe | Maximal 4 Ebenen | Solanas CPI-Tiefenlimit | | Konten pro CPI-Aufruf | Begrenzt durch die Solana-Tx-Größe | Praktisch \~20 Konten pro CPI | | CPI- + Transfer-Hook-Tiefe | Verwendet CPI-Ebenen | Transfer-Hooks innerhalb von CPI können die Tiefe überschreiten | **Die CPI-Tiefe ist die kritischste Einschränkung.** Rome EVM verbraucht eine CPI-Ebene, wenn Solana das Rome-Programm aufruft. Wenn Ihr Solidity-Vertrag dann über CPI ein weiteres Solana-Programm aufruft, ist das Ebene 2. Wenn dieses Programm ein weiteres aufruft, ist das Ebene 3. Sie haben insgesamt höchstens 4 Ebenen. ``` Ebene 0: Solana Runtime → Rome EVM-Programm Ebene 1: Rome EVM-Programm → Ihr CPI-Ziel (z. B. Jupiter) Ebene 2: Jupiter → ein weiteres Programm (z. B. Raydium) Ebene 3: Raydium → SPL Token (maximale Tiefe) ``` ## Token-2022-Transfer-Hook-Einschränkungen | Einschränkung | Auswirkung | | ---------------------------------- | ------------------------------------------------------------------------------------------- | | Ein Hook pro Mint | Ein Token-2022-Mint hat einen einzelnen Transfer-Hook-Slot | | `transfer_checked` nur | Hooks werden bei einfachem `Transfer`. Rome-Bridge-Operationen verwenden `transfer_checked` | | Mint/Burn nicht mit Hooks versehen | Wird über die Mint-Authority gesteuert, nicht über Hooks | ## Gas- und Preis-Einschränkungen | Einschränkung | Hinweise | | ---------------------- | --------------------------------------------------------------------- | | Gas-Preisquelle | Meteora-DAMM-Pool, v1 oder v2 (SPL-Gas-Token) | | Gaspreis-Multiplikator | Konfigurierbar pro Proxy (`gas_price_mul`) | | Mindest-Gaspreis | Wird durch die Proxy-Konfiguration festgelegt | | Gas-Schätzung | Vor der Übermittlung off-chain über den Mollusk-Emulator durchgeführt | ## Netzwerkspezifische Einschränkungen | Umgebung | Chain-ID | rome-evm-Programm-ID | | ----------------- | -------- | --------------------------------------------- | | Lokal | 1001 | Lokaler Entwicklungs-Stack | | Hadrian (Devnet) | 200010 | `RPTWwELXAY4KC9ZPHhaxp7Sq1hHtU3HNEgLbSegCcWf` | | Martius (Testnet) | 121214 | `RomeTaTNPJNBxtB3Wong9geVTtkEFJfUqgktQVq3iSX` | ## Precompile-Einschränkungen | Precompile | Einschränkung | | -------------------------- | -------------------------------------------------------------------------- | | Modexp (0x05) | **Deaktiviert** — kann über ein Feature-Flag aktiviert werden | | BN254 ecPairing (0x08) | Hohe CU-Kosten — erfordert typischerweise den iterativen Modus (\~200K CU) | | CPI-Precompile (0xFF...08) | Konten müssen in der Solana-Transaktion im Voraus deklariert werden | ## Oracle-Einschränkungen | Einschränkung | Wert | | --------------------------------- | ------------------------------------------------------------------------- | | Standardmäßige maximale Veraltung | 60 Sekunden | | Historische Rundendaten | Nicht unterstützt — `getRoundData(roundId)` führt zu einem Revert | | Switchboard-EMA | Nicht unterstützt — `latestEMAData()` revertiert bei SwitchboardV3 | | Parser-Offsets | Empirisch validiert — vor einer erneuten Bereitstellung erneut validieren | ## Design-Empfehlungen 1. **Halten Sie die CPI-Tiefe flach.** Entwerfen Sie Verträge so, dass die Verschachtelung minimiert wird. Wenn Sie Jupiter aufrufen, das Raydium aufruft, das wiederum SPL Token aufruft, sind Sie auf 3 Ebenen — gefährlich nah am Limit. 2. **Bevorzugen Sie den atomaren Modus.** Entwerfen Sie Operationen so, dass sie innerhalb von \~1,4 Mio. CU liegen. Der iterative Modus erhöht die Latenz (3–4 Sekunden Sperren) und die Komplexität. 3. **Konten im Voraus deklarieren.** Alle Solana-Konten, die durch CPI berührt werden, müssen zum Zeitpunkt der Transaktionserstellung bekannt sein. Eine dynamische Kontoerkennung innerhalb eines CPI-Aufrufs ist nicht möglich. 4. **Verwenden Sie `transfer_checked`.** Wenn Sie irgendetwas bauen, das Token-2022-Token berührt, verwenden Sie immer `transfer_checked` um sicherzustellen, dass Hooks ausgelöst werden. 5. **Testen Sie den CU-Verbrauch.** Messen Sie die tatsächlichen Solana-Compute-Units aus der Transaktionsquittung (`computeUnitsConsumed`) — EVM `gasUsed` ist kein zuverlässiger Proxy für Solana-CU. Optimieren Sie Hot Paths mit Yul. ## Was kommt als Nächstes * [Compute-Budget](/de/kernkonzepte/compute-budget.md) — detaillierte CU-Kosten pro Operation * [Token-Interop](/de/kernkonzepte/token-interop.md) — ERC-20 ↔ SPL-Bridging-Modell --- # 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/kernkonzepte/constraints.md?ask=&goal= ``` `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.