# Einschränkungen Wichtige Grenzen und Beschränkungen beim Aufbau auf Rome EVM. Das Verständnis dieser Einschränkungen hilft Ihnen, Verträge zu entwerfen, die zuverlässig funktionieren. ## Solana-Transaktionslimits | Beschränkung | Wert | Auswirkung | | ------------------------ | ------------- | ------------------------------------------------------------------- | | Transaktionsgröße | 1.232 Bytes | Große EVM-TXs werden über Holder-Konten aufgeteilt (transparent) | | Compute Units pro TX | \~1,4 Mio. CU | Operationen, die dies überschreiten, verwenden den iterativen Modus | | Konten pro TX (ohne ALT) | 28 | Für mehr Address Lookup Tables verwenden | | 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ührungsgrenzen | Beschränkung | Wert | Hinweise | | ---------------------- | --------------------- | --------------------------------------------------------- | | Contract-Storage-Slots | 256 pro Storage-Konto | Pro Vertrag können mehrere Storage-Konten erstellt werden | | Opcodes pro Iteration | \~500 | Für den iterativen (VmIt-)Modus | | TTL der Konto-Sperre | 3–4 Sekunden | Während der iterativen Ausführung | | Treasury-Wallets | 64 | Fee-Pool-Wallets | | Vertragsgrößenlimit | 480 KB | Erhöht von Ethereums 24 KB (OP-Geth-Modus) | ## CPI-Beschränkungen | Beschränkung | Wert | Hinweise | | -------------------------- | ------------------------------------------- | --------------------------------------------------------------- | | CPI-Tiefe | maximal 4 Ebenen | Solanas CPI-Tiefenlimit | | Konten pro CPI-Aufruf | Begrenzt durch die Solana-Transaktionsgröß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 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 | Beschränkung | Auswirkung | | ----------------------------- | ----------------------------------------------------------------------------------------------------------- | | Ein Hook pro Mint | Meta-Hook Router löst dies (bis zu 8 Unter-Hooks) | | `transfer_checked` nur | Hooks werden bei einfachem `transfer`nicht ausgelöst. Die Rome-Bridge MUSS `transfer_checked` | | Mint/Burn nicht gehookt | Gesteuert über die Mint-Authority, nicht über Hooks | | Nur Single-State-Modus | OP-Geth von innerhalb einer Solana-TX aus nicht erreichbar | | Umgehung durch Token-Wrapping | Benutzer können Token wrappen, um Hooks zu umgehen. Abgemildert durch Wrapper-Blacklist + PermanentDelegate | ## Gas- und Preisbeschränkungen | Beschränkung | Hinweise | | -------------------------- | ------------------------------------------------------------------ | | Quelle der Gaspreisbildung | Meteora DAMM V1 Pool (SPL-Gas-Token) | | Gaspreis-Multiplikator | Pro Proxy konfigurierbar (`gas_price_mul`) | | Mindest-Gaspreis | Durch die Proxy-Konfiguration festgelegt | | Gas-Schätzung | Vor der Einreichung offline über den Mollusk-Emulator durchgeführt | ## Netzwerkspezifische Beschränkungen | Umgebung | Chain-ID | Programm-ID | | ----------------- | -------- | --------------------------------------------- | | Lokal | 1001 | Festgelegt in `rome-setup` config | | Devnet (montispl) | 200002 | `RD2Gg7Lcnv62XmRHAzxh6fQQfMRzHtN5LeKPVBhYU5S` | | Testnet (Martius) | 121214 | Bereitstellungskonfiguration prüfen | | Testnet (Caelian) | 121215 | Bereitstellungskonfiguration prüfen | ## Precompile-Beschränkungen | Precompile | Beschrä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 im Solana-Transaktionsvorschlag vorab deklariert werden | ## Oracle-Beschränkungen | Beschrä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()` führt bei SwitchboardV3 zu einem Revert | | 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 Verschachtelungen minimiert werden. Wenn Sie Jupiter aufrufen, das Raydium aufruft, das SPL Token aufruft, sind Sie bei 3 Ebenen — gefährlich nah am Limit. 2. **Bevorzugen Sie den atomaren Modus.** Entwerfen Sie Operationen so, dass sie in \~1,4 Mio. CU passen. Der iterative Modus bringt zusätzliche Latenz (3–4 Sekunden Sperren) und Komplexität mit sich. 3. **Konten im Voraus deklarieren.** Alle Solana-Konten, die per CPI angesprochen 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 etwas bauen, das Token-2022-Token berührt, verwenden Sie immer `transfer_checked` damit Hooks ausgelöst werden. 5. **CU-Verbrauch testen.** Verwenden Sie `eth_estimateGas` während der Entwicklung. Optimieren Sie Hot Paths mit Yul. Siehe [CU-Optimierung](https://github.com/rome-protocol/docs/blob/main/developer-guides/cu-optimization.md). ## Was kommt als Nächstes * [Compute-Budget](/de/grundlegende-konzepte/compute-budget.md) — detaillierte CU-Kosten pro Operation * [Token-Interop](/de/grundlegende-konzepte/token-interop.md) — ERC-20 ↔ SPL-Bridging-Modell * [Leitfaden zur CU-Optimierung](https://github.com/rome-protocol/docs/blob/main/developer-guides/cu-optimization.md) — praktische Optimierungstechniken --- # Agent Instructions: 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: ``` GET https://docs.rome.builders/de/grundlegende-konzepte/constraints.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.