Compute-Budget

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

Budget-Übersicht

Modus	Max. CU	Hinweise
Atomar (VmAt)	~1.400.000 CU	Einzelne Solana-Transaktion
Iterativ (VmIt)	Unbegrenzt (Multi-Tx)	~500 Opcodes pro Iterationsschritt

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

CU-Kostenschätzungen

EVM-Operationen

Operation	Ungefähre CU	Hinweise
Signaturüberprüfung (ecrecover)	~5.000 CU	secp256k1 über Solana-Syscall
Einfache Übertragung	~50.000-100.000 CU	Nur Saldoaktualisierungen
ERC-20-Übertragung	~100.000-150.000 CU	Enthält SPL-Precompile-Aufruf
Vertragsbereitstellung (klein)	~200.000-400.000 CU	Hängt von der Bytecode-Größe ab
Speicherschreiben (SSTORE)	~5.000-20.000 CU	Kalter vs. warmer Zugriff

CPI-Operationen

Operation	Ungefähre CU	Hinweise
Basis-Overhead des Transfer-Hooks	100.000 CU	Pro Übertragung
Nativer Unter-Hook	50.000 CU	Pro nativem Solana-Hook
EVM-Unter-Hook	200.000 CU	Pro EVM-Hook
Empfohlene EVM-Übertragung mit Hooks	800.000 CU	Sicheres Budget für Übertragungen mit Hooks

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 Optimizer von Solidity erzeugt vernünftigen Code, aber Yul (Inline-Assembly) kann CU für kritische Operationen erheblich reduzieren:

// 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-Encoding-Overhead überspringen
    }
}

2. PDA-Ableitungen zwischenspeichern

PDA-Ableitung über find_program_address ist teuer. Speichern Sie abgeleitete PDAs im Contract-Speicher, statt sie bei jedem Aufruf neu zu berechnen:

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 eincodieren

Laden Sie Programm-IDs nicht aus dem Speicher — verwenden Sie Konstanten:

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

// Günstig: Kompilierzeit-Konstante
bytes32 constant SPL_TOKEN_PROGRAM = 0x06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9;

4. Anzahl der Accounts minimieren

Jeder Account in einer Solana-Transaktion erhöht den CU-Overhead. Reduzieren Sie die Anzahl der Accounts durch:

• Bündeln von Operationen, die Accounts gemeinsam nutzen

• Verwendung weniger Zwischen-Accounts

• Vermeidung redundanter ATA-Erstellungsprüfungen

5. Optimizer-Einstellungen verwenden

// hardhat.config.js
solidity: {
  version: "0.8.28",
  settings: {
    optimizer: { enabled: true, runs: 200 },
  },
}

CU-Verbrauch messen

Verwenden Sie eth_estimateGas um CU vor dem Senden zu messen:

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

Oder über ethers.js:

const gas = await contract.myFunction.estimateGas(42);
console.log("Geschätztes Gas:", gas.toString());

Was kommt als Nächstes

• Einschränkungen — vollständige Liste der Limits und Grenzen

• Leitfaden zur CU-Optimierung — ausführliches Optimierungs-Kochbuch