Solidity-Gas-Optimierungsmuster, die 2025 noch funktionieren

Nach dem Audit und Rewrite von über 20 Smart Contracts sehen wir immer wieder dieselben Gas-Verschwendungsmuster. Hier sind die wichtigsten, wie man sie misst und die Storage- und Calldata-Tricks für 40–60 % Kosteneinsparung.

Gaskosten sind kein EVM-Artefakt, das ignoriert werden kann. Auf Ethereum Mainnet kann ein schlecht optimierter Vertrag Nutzern 3–5× mehr pro Transaktion kosten als ein gut optimierter. Auf L2s wie Arbitrum und Optimism ist Execution-Gas günstig, aber Calldata kostet weiterhin. Nach dem Audit und Rewrite von über 20 Smart Contracts sehen wir immer wieder dieselben Gas-Verschwendungsmuster. Hier sind die wichtigsten und wie man sie behebt.

Was Gas wirklich kostet

Vor blinder Optimierung sollte verstanden werden, woher Gas kommt. Die zwei größten Kategorien sind Storage und Computation. SSTORE (Schreiben in den Speicher) kostet 20.000 Gas für einen kalten Slot und 2.900 für einen warmen. SLOAD (Lesen aus dem Speicher) kostet 2.100 für kalt und 100 für warm. Im Vergleich dazu kosten arithmetische Operationen 3–5 Gas. Das bedeutet: Ein einziger unnötiger Storage-Write kann mehr Gas kosten als Tausende arithmetischer Operationen.

Muster 1: Storage-Variablen packen

Solidity speichert Variablen in 32-Byte-Slots. Wenn ein Struct ein uint256, ein bool und ein uint256 hat, sind das drei separate Storage-Slots. Wenn sie zu uint256, uint256, bool umgeordnet werden — teilt sich das bool einen Slot mit einer anderen Variable und spart 20.000 Gas beim ersten Schreiben.

// ❌ Three storage slots
struct Bad {
    uint256 amount;   // slot 0
    bool active;      // slot 1 (wastes 31 bytes)
    uint256 expiry;   // slot 2
}

// ✅ Two storage slots — bool shares slot with expiry
struct Good {
    uint256 amount;   // slot 0
    uint128 expiry;   // slot 1 (first 16 bytes)
    bool active;      // slot 1 (byte 17, packed)
}

Muster 2: calldata statt memory verwenden

Bei externen Funktionsparametern, die nur gelesen (niemals modifiziert) werden, sollten sie als calldata statt memory deklariert werden. calldata ist schreibgeschützt und vermeidet das Kopieren der Daten in den Speicher, was Gas proportional zur Datengröße kostet. Für Arrays und Structs, die an view- oder pure-Funktionen übergeben werden, ist das ein einfacher Gewinn.

// ❌ memory — copies array into EVM memory
function processItems(uint256[] memory items) external {
    for (uint i = 0; i < items.length; i++) { /* read only */ }
}

// ✅ calldata — reads directly, no copy
function processItems(uint256[] calldata items) external {
    for (uint i = 0; i < items.length; i++) { /* read only */ }
}

Muster 3: Events statt Storage für History

Wenn Daten nur von Off-Chain-Anwendungen (Indexer, Frontends, Analytics) gelesen werden müssen, in Events statt Storage-Variablen speichern. Eine Event-Emission kostet ~375 Gas plus 8 Gas pro Byte Daten. Das Schreiben in einen neuen Storage-Slot kostet 20.000 Gas. Wenn historische Datensätze gespeichert werden, die niemals von anderen On-Chain-Contracts gelesen werden, auf Events umstellen und erheblich sparen.

Muster 4: Storage-Reads in Memory cachen

Denselben Storage-Slot zweimal in einer Funktion zu lesen kostet 2.100 + 100 Gas. Einmal lesen, in einer lokalen Variable cachen (3–5 Gas pro Zugriff) und die lokale Variable für alle nachfolgenden Lesevorgänge nutzen. Das ist eine der am leichtesten zu übersehenden Optimierungen und eine der günstigsten zu beheben.

// ❌ Two SLOAD operations
function bad() external {
    if (config.maxAmount > 0) {
        require(amount <= config.maxAmount, "too much");
    }
}

// ✅ One SLOAD, one MLOAD
function good() external {
    uint256 max = config.maxAmount; // cache
    if (max > 0) {
        require(amount <= max, "too much");
    }
}

Muster 5: Der Minimal Proxy (EIP-1167)

Wenn viele Instanzen desselben Contracts deployed werden (z. B. per-User-Vaults, per-Campaign-Contracts), den Minimal-Proxy-Muster (EIP-1167) statt der vollständigen Bytecode-Deployment verwenden. Ein Minimal Proxy sind 45 Bytes Bytecode, die alle Calls an eine einzelne Implementierungsadresse delegieren. Deployment-Kosten sinken von ~1–3M Gas auf ~150k Gas pro Instanz.

Messen, was vorhanden ist

Nicht blind optimieren. Erst messen, die Hotpaths optimieren, dann wieder messen. Die Tools, die bei jedem Engagement eingesetzt werden:

• •Hardhat Gas Reporter — zeigt Gas pro Funktionsaufruf in der Testausgabe
• •Foundry forge test --gas-report — schnell und detailliert, integriert in CI
• •eth-gas-reporter — Truffle-Äquivalent
• •Tenderly — Transaktionen simulieren und detaillierte Opcode-Level-Gas-Aufschlüsselung erhalten