Compute Budget

Jede Solana-Transaktion hat ein Compute-Budget, gemessen in Compute Units (CU). Das Verständnis der CU-Kosten hilft dir, 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 standardmäßig ein Budget von 200.000 CU, erweiterbar auf ~1,4 Mio. CU über Compute-Budget-Anweisungen (von der Rome SDK automatisch hinzugefügt).

CU-Kostenschätzungen

EVM-Operationen

Operation	Ungefähre CU	Hinweise
Signaturprüfung (ecrecover)	~5.000 CU	secp256k1 über Solana-Systemaufruf
Einfache Überweisung	~50.000-100.000 CU	Nur Kontostandsaktualisierungen
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
Grund-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

Soliditys Optimierer erzeugt vernünftigen Code, aber Yul (Inline-Assembly) kann die CU für kritische Operationen deutlich reduzieren:

// Vorher: ~600.000 CU
function createPairAccount(bytes32 token0, bytes32 token1) external {
    // Operationen auf Solidity-Ebene
}

// Nachher: ~150.000 CU (Yul-Optimierung)
function createPairAccount(bytes32 token0, bytes32 token1) external {
    assembly {
        // Direkte Speicherbearbeitung, ABI-Kodierungs-Overhead überspringen
    }
}

2. PDA-Ableitungen cachen

PDA-Ableitung über find_program_address ist teuer. Speichere abgeleitete PDAs im Vertragsstorage, 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 hart codieren

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

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

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

4. Anzahl der Konten minimieren

Jedes Konto in einer Solana-Transaktion verursacht CU-Overhead. Reduziere die Anzahl der Konten durch:

• Zusammenfassen von Operationen, die Konten gemeinsam nutzen

• Verwendung weniger Zwischenkonten

• Vermeidung redundanter ATA-Erstellungsprüfungen

5. Optimierer-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 Absenden zu messen:

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

Oder mit 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 Grenzen und Schranken

• Leitfaden zur CU-Optimierung — detailliertes Optimierungs-Kochbuch