> 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/compute-budget.md). # Compute-Budget Solana-Compute-Unit-(CU)-Kosten für Rome-EVM-Operationen — atomare vs. iterative Budgets und wie man CU-effiziente Solidity-Contracts entwirft. Jede Solana-Transaktion hat ein Rechenbudget, gemessen in Compute Units (CU). Das Verständnis der CU-Kosten hilft Ihnen, effiziente Rome-Verträge zu entwerfen. ## Budgetübersicht | Modus | Max. CU | Hinweise | | --------------- | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | | Atomar (VmAt) | \~1.400.000 CU | Einzelne Solana-Transaktion | | Iterativ (VmIt) | Bis zu \~1.400.000 CU pro Schritt; höchstens 160 Iterationen pro Sitzung | Jeder Schritt ist eine eigene Solana-Transaktion; adaptive Opcodes/Schritt — passend zum CU-Budget jeder Transaktion gepackt | Jede Solana-Transaktion hat ein Standardbudget von 200.000 CU, erweiterbar auf ca. 1,4 Mio. CU über Compute-Budget-Anweisungen (vom Rome SDK automatisch hinzugefügt). Die iterative Ausführung ist nicht unbegrenzt. Eine Sitzung endet nach 160 Iterationen, und der iterative Composer des Rust-Rome-SDK plant höchstens 128 Schritte. Ein Plan, den die Wallet selbst signiert, läuft durch `rome_submitSignedV1Plan`, das pro Aufruf höchstens 64 Transaktionen akzeptiert. Die meisten Aufrufe brauchen weit weniger. Legacy-Track-CPIs werden innerhalb einer iterativen Sitzung abgelehnt, daher muss ein Aufruf, der sie ausführt, ins atomare Budget passen. Siehe [Weitergeleitete Aufrufe und lange Aufrufe](/de/entwicklerleitfaden/call-evm-from-solana.md#relayed-calls-and-long-calls) und [Einschränkungen](/de/kernkonzepte/constraints.md). ## CU-Kostenschätzungen ### EVM-Operationen | Operation | Ca. CU | Hinweise | | --------------------------------------------------- | -------------------- | ----------------------------------------------------------------------------------------- | | Überprüfung der Transaktionssignatur (EVM-Key-Pfad) | \~25.000 CU | Der `secp256k1_recover` syscall, dieselben Kosten wie die `ecrecover` folgende Precompile | | Einfache Übertragung | \~50.000-100.000 CU | Nur Kontostandsaktualisierungen | | ERC-20-Übertragung | \~100.000-150.000 CU | Enthält den Aufruf der SPL-Precompile | | Bereitstellung des Vertrags (klein) | \~200.000-400.000 CU | Hängt von der Bytecode-Größe ab | | Speicherschreibvorgang (SSTORE) | \~5.000-20.000 CU | Kalter vs. warmer Zugriff | ### Precompile-Operationen | Precompile | Ca. CU | Hinweise | | --------------- | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ecrecover | \~25.700 CU | | | SHA-256 | \~257 CU pro gemessenem 32-Byte-Wort | Plus eine kleine feste Gebühr. Das Programm bepreist SHA-256, RIPEMD-160 und die Identity-Precompile mit einem gemeinsamen Pro-Wort-Wert von etwa 2.200 CU, ausgelegt auf RIPEMD-160, das teuerste der drei, sodass ein SHA-256-Aufruf mit mehr berechnet wird, als er verbraucht | | BN254 ecAdd | Nahezu 0 CU | Günstiger als das Kopieren von 32 Bytes | | BN254 ecMul | \~4.200 CU | | | BN254 ecPairing | \~22.000 CU plus \~12.800 CU pro Paar | Eine Prüfung mit vier Paaren liegt bei etwa 73.000 CU und damit deutlich innerhalb einer atomaren Transaktion | Diese Werte stammen aus der eigenen Kalibrierung des Programms, bei der auf einer Testnet-Bereitstellung Compute Units von einem Solana-Node ausgelesen wurden. Sie wurden für diese Seite nicht erneut gemessen; messen Sie Ihren eigenen Aufruf mit `computeUnitsConsumed`. ## Optimierungstechniken ### 1. Yul für Hot Paths verwenden Der Optimierer von Solidity erzeugt brauchbaren Code, aber Yul (Inline-Assembly) kann CU für kritische Operationen deutlich reduzieren: ```solidity // Vorher: ~600K CU function createPairAccount(bytes32 token0, bytes32 token1) external { // Operationen auf Solidity-Ebene } // Danach: ~150K CU (Yul-Optimierung) function createPairAccount(bytes32 token0, bytes32 token1) external { assembly { // Direkte Speicher-Manipulation, ABI-Kodierungs-Overhead überspringen } } ``` ### 2. PDA-Ableitungen cachen PDA-Ableitung über `find_program_address` ist teuer. Speichern Sie abgeleitete PDAs im Vertrags-Storage, statt sie bei jedem Aufruf neu zu berechnen: ```solidity mapping(address => bytes32) private cachedPdas; function getPda(address user) internal returns (bytes32) { bytes32 cached = cachedPdas[user]; if (cached != bytes32(0)) return cached; bytes32 pda = RomeEVMAccount.pda(user); cachedPdas[user] = pda; return pda; } ``` ### 3. Bekannte Programm-IDs fest kodieren Laden Sie Programm-IDs nicht aus dem Storage — verwenden Sie Konstanten: ```solidity // Teuer: liest aus dem Storage bytes32 splTokenProgram = storage_program_id; // Günstig: Compile-Time-Konstante bytes32 constant SPL_TOKEN_PROGRAM = 0x06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9; ``` ### 4. Anzahl der Accounts minimieren Jeder Account in einer Solana-Transaktion verursacht zusätzlichen CU-Overhead. Verringern Sie die Anzahl der Accounts durch: * Batching von Operationen, die Accounts gemeinsam nutzen * Weniger Zwischen-Accounts verwenden * Redundante Prüfungen zur ATA-Erstellung vermeiden ### 5. Optimizer-Einstellungen verwenden ```typescript // hardhat.config.ts — aktivieren Sie den Optimizer in einem Build-Profil solidity: { profiles: { default: { version: "0.8.28" }, production: { version: "0.8.28", settings: { optimizer: { enabled: true, runs: 200 } }, }, }, } ``` Bauen mit `npx hardhat compile --build-profile production`. ## CU-Verbrauch messen Verwenden Sie `eth_estimateGas` um CU vor dem Einreichen zu messen: ```bash cast estimate --rpc-url https://hadrian.testnet.romeprotocol.xyz/ \\ 0xCONTRACT "myFunction(uint256)" 42 ``` Oder über ethers.js: ```javascript const gas = await contract.myFunction.estimateGas(42); console.log("Geschätztes Gas:", gas.toString()); ``` ## Wie es weitergeht * [Einschränkungen](/de/kernkonzepte/constraints.md) — vollständige Liste der Limits und Grenzen --- # 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/compute-budget.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.