> 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

Jede Solana-Transaktion hat ein Compute-Budget, gemessen in Compute Units (CU). Das Verständnis der CU-Kosten hilft dir, effiziente Rome-Verträge zu entwerfen.

## Budgetübersicht

| Modus           | Max. CU               | Hinweise                                                               |
| --------------- | --------------------- | ---------------------------------------------------------------------- |
| Atomar (VmAt)   | \~1.400.000 CU        | Eine einzelne Solana-Transaktion                                       |
| Iterativ (VmIt) | Unbegrenzt (Multi-Tx) | Adaptive Opcodes/Schritt — jeweils an das CU-Budget jeder Tx angepasst |

Jede Solana-Transaktion hat ein Standardbudget von 200.000 CU, erweiterbar auf \~1,4 Mio. CU über Compute-Budget-Instruktionen (werden vom Rome SDK automatisch hinzugefügt).

## Schätzungen der CU-Kosten

### EVM-Operationen

| Operation                             | Ungefähre CU         | Hinweise                               |
| ------------------------------------- | -------------------- | -------------------------------------- |
| Signaturverifikation (ecrecover)      | \~5.000 CU           | secp256k1 über Solana-Syscall          |
| Einfache Überweisung                  | \~50.000-100.000 CU  | Nur Kontostandsaktualisierungen        |
| ERC-20-Übertragung                    | \~100.000-150.000 CU | Enthält den Aufruf des SPL-Precompiles |
| Bereitstellung eines Vertrags (klein) | \~200.000-400.000 CU | Hängt von der Bytecode-Größe ab        |
| Speicherschreibzugriff (SSTORE)       | \~5.000-20.000 CU    | Kalter vs. warmer Zugriff              |

### Precompile-Operationen

| Precompile      | Ungefähre CU     |
| --------------- | ---------------- |
| ecrecover       | \~3.000-5.000 CU |
| SHA-256         | \~1.000 CU       |
| BN254 ecAdd     | \~10.000 CU      |
| BN254 ecMul     | \~40.000 CU      |
| BN254 ecPairing | \~200.000+ CU    |

## Optimierungstechniken

### 1. Yul für Hot Paths verwenden

Der Optimierer von Solidity erzeugt brauchbaren Code, aber Yul (Inline-Assembly) kann die CU für kritische Operationen erheblich 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, den Overhead der ABI-Kodierung überspringen
    }
}
```

### 2. PDA-Ableitungen cachen

PDA-Ableitung über `find_program_address` ist teuer. Speichere abgeleitete PDAs im Vertrags-Speicher, 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 hart kodieren

Lade Programm-IDs nicht aus dem Speicher — verwende Konstanten:

```solidity
// Teuer: liest aus dem Speicher
bytes32 splTokenProgram = storage_program_id;

// Günstig: Compile-Time-Konstante
bytes32 constant SPL_TOKEN_PROGRAM = 0x06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9;
```

### 4. Kontozahl minimieren

Jedes Konto in einer Solana-Transaktion erhöht den CU-Overhead. Verringere die Anzahl der Konten durch:

* Bündeln von Operationen, die Konten gemeinsam nutzen
* Verwendung weniger Zwischenkonten
* Vermeidung redundanter ATA-Erstellungsprüfungen

### 5. Optimierer-Einstellungen verwenden

```typescript
// hardhat.config.ts — den Optimierer in einem Build-Profil aktivieren
solidity: {
  profiles: {
    default: { version: "0.8.28" },
    production: {
      version: "0.8.28",
      settings: { optimizer: { enabled: true, runs: 200 } },
    },
  },
}
```

Erstellen mit `npx hardhat compile --build-profile production`.

## CU-Verbrauch messen

Verwende `eth_estimateGas` um CU vor dem Absenden zu messen:

```bash
cast estimate --rpc-url http://localhost:9090 \\
  0xCONTRACT "myFunction(uint256)" 42
```

Oder über ethers.js:

```javascript
const gas = await contract.myFunction.estimateGas(42);
console.log("Estimated gas:", gas.toString());
```

## Wie geht es weiter

* [Grenzen](/de/kernkonzepte/constraints.md) — vollständige Liste der Limits und Begrenzungen


---

# 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/compute-budget.md?ask=<question>&goal=<endgoal>
```

`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.