[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-3-gas-verstehen-contract-kosten":3},{"article":4,"author":54},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":7,"meta_description":16,"focus_keyword":17,"og_image":18,"canonical_url":18,"robots_meta":19,"created_at":15,"updated_at":15,"tags":20,"category_name":34,"related_articles":35},"d7000000-0000-0000-0000-000000000103","a0000000-0000-0000-0000-000000000072","Deep EVM #3: Gas verstehen — Warum Ihr Contract kostet, was er kostet","deep-evm-3-gas-verstehen-contract-kosten","Eine praezise Aufschluesselung der EVM-Gaskosten: intrinsisches Gas, EIP-2929 kalt\u002Fwarm-Zugriff, Rueckerstattungsmechanismen und bewaehrte Optimierungsmuster, die echtes Geld sparen.","## Gas ist keine vage Metrik\n\nEntwickler behandeln Gas oft als vagen \"Kosten\"-Wert. In Wirklichkeit ist Gas ein praezise definiertes Ressourcenabrechnungssystem mit exakten Formeln. Jeder Opcode, jedes Byte Calldata, jeder Storage-Zugriff hat deterministische Gaskosten, die im Yellow Paper und nachfolgenden EIPs definiert sind.\n\n## Intrinsisches Gas\n\nBevor Ihr Contract-Code auch nur einen Opcode ausfuehrt, hat Ihre Transaktion bereits Gas verbraucht:\n\n- **Basis:** 21.000 Gas fuer jede Transaktion\n- **Calldata:** 16 Gas pro Nicht-Null-Byte, 4 Gas pro Null-Byte\n- **Contract-Erstellung:** Zusaetzlich 32.000 Gas fuer CREATE-Transaktionen\n- **Zugriffsliste:** 2.400 Gas pro Adresse, 1.900 Gas pro Storage-Schluessel\n\nEin einfacher ETH-Transfer (keine Calldata) kostet genau 21.000 Gas. Ein ERC-20-Transfer hat ~68 Bytes Calldata, was weitere ~1.088 Gas hinzufuegt, bevor die Contract-Ausfuehrung ueberhaupt beginnt.\n\n## Gaskosten der haeufigsten Operationen\n\n| Operation | Gas (kalt) | Gas (warm) | Hinweise |\n|-----------|------------|------------|----------|\n| ADD, SUB | 3 | 3 | Immer gleich |\n| MUL, DIV | 5 | 5 | Immer gleich |\n| SLOAD | 2.100 | 100 | 21x Unterschied! |\n| SSTORE (0->ungleich 0) | 22.100 | 20.000 | Teuerster Opcode |\n| SSTORE (ungleich 0->ungleich 0) | 5.000 | 2.900 | Aenderung |\n| CALL | 2.600 | 100 | Ohne Wertuebertragung |\n| MLOAD\u002FMSTORE | 3 | 3 | Plus Erweiterung |\n| LOG0 | 375 | 375 | Plus 8 Gas\u002FByte |\n\n## EIP-2929: Kalter vs. warmer Zugriff\n\nDas Berlin-Upgrade (April 2021) fuehrte das entscheidende Konzept der Zugriffslisten ein. Der erste Zugriff auf einen Slot oder eine Adresse in einer Transaktion ist \"kalt\" und teuer. Jeder nachfolgende Zugriff ist \"warm\" und guenstig.\n\nDiese Unterscheidung hat massive Auswirkungen auf die Gasoptimierung:\n\n```solidity\n\u002F\u002F Muster 1: Naive Implementierung (teuer)\nfunction naive() external {\n    \u002F\u002F Kalt: 2.100 Gas\n    if (balances[msg.sender] > 0) {\n        \u002F\u002F Warm: 100 Gas\n        uint256 bal = balances[msg.sender];\n        \u002F\u002F Kalt: 22.100 Gas (neuer Slot)\n        balances[recipient] += bal;\n        \u002F\u002F Warm: 2.900 Gas (Aenderung eines warmen Slots)\n        balances[msg.sender] = 0;\n    }\n}\n\n\u002F\u002F Muster 2: Optimiert (guenstiger)\nfunction optimized() external {\n    uint256 bal = balances[msg.sender]; \u002F\u002F Kalt: 2.100\n    if (bal > 0) {\n        balances[msg.sender] = 0;        \u002F\u002F Warm: 2.900\n        balances[recipient] += bal;       \u002F\u002F Kalt: 5.000\n    }\n}\n```\n\n## SSTORE-Gasmechanik im Detail\n\nSSTORE ist bei weitem der komplexeste Opcode in Bezug auf Gaskosten. Die Kosten haengen vom aktuellen Wert, dem neuen Wert und dem urspruenglichen Wert (zu Beginn der Transaktion) ab:\n\n- **Null auf ungleich Null:** 22.100 Gas (kalt) — Sie belegen neuen Speicherplatz\n- **Ungleich Null auf anderen ungleich Null:** 5.000 Gas (kalt) — Aenderung\n- **Ungleich Null auf Null:** 5.000 Gas + 4.800 Gas Rueckerstattung — Freigabe von Speicher\n- **Warme Variante:** Jeweils 2.900 Gas statt 5.000 fuer warme Slots\n\n## Rueckerstattungsmechanismen\n\nGas-Rueckerstattungen belohnen die Bereinigung von Zustand. Die wichtigste Rueckerstattung:\n\n- SSTORE: ungleich Null auf Null -> 4.800 Gas Rueckerstattung\n\nNach EIP-3529 ist die Gesamtrueckerstattung auf 20% des verbrauchten Gases begrenzt. Dies bedeutet: Wenn Ihre Transaktion 100.000 Gas verbraucht, koennen Sie maximal 20.000 Gas zurueckerstattet bekommen, unabhaengig davon, wie viele Slots Sie bereinigen.\n\n## Bewaehrte Optimierungsmuster\n\n### 1. Storage-Lesevorgaenge cachen\n```solidity\n\u002F\u002F Schlecht: Drei separate SLOAD-Operationen\nfunction bad() external view returns (uint256) {\n    return data[0] + data[1] + data[2]; \u002F\u002F 3x SLOAD\n}\n\n\u002F\u002F Gut: In lokalen Variablen cachen\nfunction good() external view returns (uint256) {\n    uint256 a = data[0]; \u002F\u002F SLOAD\n    uint256 b = data[1]; \u002F\u002F SLOAD\n    uint256 c = data[2]; \u002F\u002F SLOAD\n    return a + b + c;    \u002F\u002F Nur Stack-Operationen\n}\n```\n\n### 2. Variablen in Storage-Slots packen\n```solidity\n\u002F\u002F Schlecht: 3 Slots (3x SLOAD fuer vollstaendiges Lesen)\ncontract Bad {\n    uint256 a;\n    uint256 b;\n    bool c;\n}\n\n\u002F\u002F Gut: 2 Slots\ncontract Good {\n    uint128 a;\n    uint128 b;\n    bool c; \u002F\u002F Neuer Slot, aber weniger insgesamt\n}\n```\n\n### 3. Calldata statt Memory verwenden\n```solidity\n\u002F\u002F Schlecht: Kopiert Array in Memory\nfunction bad(uint256[] memory arr) external { ... }\n\n\u002F\u002F Gut: Liest direkt aus Calldata\nfunction good(uint256[] calldata arr) external { ... }\n```\n\n### 4. Short-Circuit-Auswertung\n```solidity\n\u002F\u002F Guenstige Pruefung zuerst\nrequire(amount > 0 && balances[msg.sender] >= amount);\n\u002F\u002F Wenn amount == 0, wird SLOAD nie ausgefuehrt\n```\n\n## Fazit\n\nGasoptimierung ist keine Schwarze Magie — es ist angewandte Physik der EVM. Jede Operation hat praezise, deterministische Kosten. Indem Sie diese Kosten verstehen und die richtigen Muster anwenden, koennen Sie die Gaskosten Ihrer Contracts erheblich reduzieren. Der Schluessel: Messen Sie mit EXPLAIN ANALYZE (fuer die EVM heisst das `forge test --gas-report`), optimieren Sie die teuersten Pfade, und vergessen Sie nie den Unterschied zwischen kaltem und warmem Zugriff.","\u003Ch2 id=\"gas-ist-keine-vage-metrik\">Gas ist keine vage Metrik\u003C\u002Fh2>\n\u003Cp>Entwickler behandeln Gas oft als vagen “Kosten”-Wert. In Wirklichkeit ist Gas ein praezise definiertes Ressourcenabrechnungssystem mit exakten Formeln. Jeder Opcode, jedes Byte Calldata, jeder Storage-Zugriff hat deterministische Gaskosten, die im Yellow Paper und nachfolgenden EIPs definiert sind.\u003C\u002Fp>\n\u003Ch2 id=\"intrinsisches-gas\">Intrinsisches Gas\u003C\u002Fh2>\n\u003Cp>Bevor Ihr Contract-Code auch nur einen Opcode ausfuehrt, hat Ihre Transaktion bereits Gas verbraucht:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Basis:\u003C\u002Fstrong> 21.000 Gas fuer jede Transaktion\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Calldata:\u003C\u002Fstrong> 16 Gas pro Nicht-Null-Byte, 4 Gas pro Null-Byte\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Contract-Erstellung:\u003C\u002Fstrong> Zusaetzlich 32.000 Gas fuer CREATE-Transaktionen\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Zugriffsliste:\u003C\u002Fstrong> 2.400 Gas pro Adresse, 1.900 Gas pro Storage-Schluessel\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Ein einfacher ETH-Transfer (keine Calldata) kostet genau 21.000 Gas. Ein ERC-20-Transfer hat ~68 Bytes Calldata, was weitere ~1.088 Gas hinzufuegt, bevor die Contract-Ausfuehrung ueberhaupt beginnt.\u003C\u002Fp>\n\u003Ch2 id=\"gaskosten-der-haeufigsten-operationen\">Gaskosten der haeufigsten Operationen\u003C\u002Fh2>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Operation\u003C\u002Fth>\u003Cth>Gas (kalt)\u003C\u002Fth>\u003Cth>Gas (warm)\u003C\u002Fth>\u003Cth>Hinweise\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>ADD, SUB\u003C\u002Ftd>\u003Ctd>3\u003C\u002Ftd>\u003Ctd>3\u003C\u002Ftd>\u003Ctd>Immer gleich\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>MUL, DIV\u003C\u002Ftd>\u003Ctd>5\u003C\u002Ftd>\u003Ctd>5\u003C\u002Ftd>\u003Ctd>Immer gleich\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>SLOAD\u003C\u002Ftd>\u003Ctd>2.100\u003C\u002Ftd>\u003Ctd>100\u003C\u002Ftd>\u003Ctd>21x Unterschied!\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>SSTORE (0->ungleich 0)\u003C\u002Ftd>\u003Ctd>22.100\u003C\u002Ftd>\u003Ctd>20.000\u003C\u002Ftd>\u003Ctd>Teuerster Opcode\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>SSTORE (ungleich 0->ungleich 0)\u003C\u002Ftd>\u003Ctd>5.000\u003C\u002Ftd>\u003Ctd>2.900\u003C\u002Ftd>\u003Ctd>Aenderung\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>CALL\u003C\u002Ftd>\u003Ctd>2.600\u003C\u002Ftd>\u003Ctd>100\u003C\u002Ftd>\u003Ctd>Ohne Wertuebertragung\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>MLOAD\u002FMSTORE\u003C\u002Ftd>\u003Ctd>3\u003C\u002Ftd>\u003Ctd>3\u003C\u002Ftd>\u003Ctd>Plus Erweiterung\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>LOG0\u003C\u002Ftd>\u003Ctd>375\u003C\u002Ftd>\u003Ctd>375\u003C\u002Ftd>\u003Ctd>Plus 8 Gas\u002FByte\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"eip-2929-kalter-vs-warmer-zugriff\">EIP-2929: Kalter vs. warmer Zugriff\u003C\u002Fh2>\n\u003Cp>Das Berlin-Upgrade (April 2021) fuehrte das entscheidende Konzept der Zugriffslisten ein. Der erste Zugriff auf einen Slot oder eine Adresse in einer Transaktion ist “kalt” und teuer. Jeder nachfolgende Zugriff ist “warm” und guenstig.\u003C\u002Fp>\n\u003Cp>Diese Unterscheidung hat massive Auswirkungen auf die Gasoptimierung:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Muster 1: Naive Implementierung (teuer)\nfunction naive() external {\n    \u002F\u002F Kalt: 2.100 Gas\n    if (balances[msg.sender] > 0) {\n        \u002F\u002F Warm: 100 Gas\n        uint256 bal = balances[msg.sender];\n        \u002F\u002F Kalt: 22.100 Gas (neuer Slot)\n        balances[recipient] += bal;\n        \u002F\u002F Warm: 2.900 Gas (Aenderung eines warmen Slots)\n        balances[msg.sender] = 0;\n    }\n}\n\n\u002F\u002F Muster 2: Optimiert (guenstiger)\nfunction optimized() external {\n    uint256 bal = balances[msg.sender]; \u002F\u002F Kalt: 2.100\n    if (bal > 0) {\n        balances[msg.sender] = 0;        \u002F\u002F Warm: 2.900\n        balances[recipient] += bal;       \u002F\u002F Kalt: 5.000\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"sstore-gasmechanik-im-detail\">SSTORE-Gasmechanik im Detail\u003C\u002Fh2>\n\u003Cp>SSTORE ist bei weitem der komplexeste Opcode in Bezug auf Gaskosten. Die Kosten haengen vom aktuellen Wert, dem neuen Wert und dem urspruenglichen Wert (zu Beginn der Transaktion) ab:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Null auf ungleich Null:\u003C\u002Fstrong> 22.100 Gas (kalt) — Sie belegen neuen Speicherplatz\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Ungleich Null auf anderen ungleich Null:\u003C\u002Fstrong> 5.000 Gas (kalt) — Aenderung\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Ungleich Null auf Null:\u003C\u002Fstrong> 5.000 Gas + 4.800 Gas Rueckerstattung — Freigabe von Speicher\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Warme Variante:\u003C\u002Fstrong> Jeweils 2.900 Gas statt 5.000 fuer warme Slots\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"rueckerstattungsmechanismen\">Rueckerstattungsmechanismen\u003C\u002Fh2>\n\u003Cp>Gas-Rueckerstattungen belohnen die Bereinigung von Zustand. Die wichtigste Rueckerstattung:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>SSTORE: ungleich Null auf Null -> 4.800 Gas Rueckerstattung\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Nach EIP-3529 ist die Gesamtrueckerstattung auf 20% des verbrauchten Gases begrenzt. Dies bedeutet: Wenn Ihre Transaktion 100.000 Gas verbraucht, koennen Sie maximal 20.000 Gas zurueckerstattet bekommen, unabhaengig davon, wie viele Slots Sie bereinigen.\u003C\u002Fp>\n\u003Ch2 id=\"bewaehrte-optimierungsmuster\">Bewaehrte Optimierungsmuster\u003C\u002Fh2>\n\u003Ch3>1. Storage-Lesevorgaenge cachen\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Schlecht: Drei separate SLOAD-Operationen\nfunction bad() external view returns (uint256) {\n    return data[0] + data[1] + data[2]; \u002F\u002F 3x SLOAD\n}\n\n\u002F\u002F Gut: In lokalen Variablen cachen\nfunction good() external view returns (uint256) {\n    uint256 a = data[0]; \u002F\u002F SLOAD\n    uint256 b = data[1]; \u002F\u002F SLOAD\n    uint256 c = data[2]; \u002F\u002F SLOAD\n    return a + b + c;    \u002F\u002F Nur Stack-Operationen\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>2. Variablen in Storage-Slots packen\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Schlecht: 3 Slots (3x SLOAD fuer vollstaendiges Lesen)\ncontract Bad {\n    uint256 a;\n    uint256 b;\n    bool c;\n}\n\n\u002F\u002F Gut: 2 Slots\ncontract Good {\n    uint128 a;\n    uint128 b;\n    bool c; \u002F\u002F Neuer Slot, aber weniger insgesamt\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>3. Calldata statt Memory verwenden\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Schlecht: Kopiert Array in Memory\nfunction bad(uint256[] memory arr) external { ... }\n\n\u002F\u002F Gut: Liest direkt aus Calldata\nfunction good(uint256[] calldata arr) external { ... }\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>4. Short-Circuit-Auswertung\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Guenstige Pruefung zuerst\nrequire(amount > 0 && balances[msg.sender] >= amount);\n\u002F\u002F Wenn amount == 0, wird SLOAD nie ausgefuehrt\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"fazit\">Fazit\u003C\u002Fh2>\n\u003Cp>Gasoptimierung ist keine Schwarze Magie — es ist angewandte Physik der EVM. Jede Operation hat praezise, deterministische Kosten. Indem Sie diese Kosten verstehen und die richtigen Muster anwenden, koennen Sie die Gaskosten Ihrer Contracts erheblich reduzieren. Der Schluessel: Messen Sie mit EXPLAIN ANALYZE (fuer die EVM heisst das \u003Ccode>forge test --gas-report\u003C\u002Fcode>), optimieren Sie die teuersten Pfade, und vergessen Sie nie den Unterschied zwischen kaltem und warmem Zugriff.\u003C\u002Fp>\n","de","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:29.913657Z","Praezise EVM-Gas-Aufschluesselung: intrinsisches Gas, EIP-2929 kalt\u002Fwarm-Zugriff, SSTORE-Kosten, Rueckerstattungsmechanismen und bewaehrte Optimierungsmuster.","EVM Gas-Optimierung",null,"index, follow",[21,26,30],{"id":22,"name":23,"slug":24,"created_at":25},"c0000000-0000-0000-0000-000000000016","EVM","evm","2026-03-28T10:44:21.513630Z",{"id":27,"name":28,"slug":29,"created_at":25},"c0000000-0000-0000-0000-000000000020","Gas Optimization","gas-optimization",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000014","Solidity","solidity","Blockchain",[36,42,48],{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":34,"published_at":41},"d0000000-0000-0000-0000-000000000611","Die Ethereum-Interoperabilitaetsschicht: Wie 55+ L2s zu einer Chain werden","ethereum-interoperabilitaetsschicht-55-l2s-eine-chain","Ethereum hat 55+ Layer-2-Rollups, die Liquiditaet und Nutzererfahrung fragmentieren. Die Ethereum-Interoperabilitaetsschicht — bestehend aus Cross-Rollup-Messaging, Shared Sequencern und Based Rollups — zielt darauf ab, sie zu einem einzigen komponierbaren Netzwerk zu vereinen.","2026-03-28T10:44:45.264352Z",{"id":43,"title":44,"slug":45,"excerpt":46,"locale":12,"category_name":34,"published_at":47},"d0000000-0000-0000-0000-000000000610","ZK-Beweise jenseits von Rollups: Verifizierbare KI-Inferenz auf Ethereum","zk-beweise-jenseits-von-rollups-verifizierbare-ki-inferenz-ethereum","Zero-Knowledge-Beweise sind nicht mehr nur ein Skalierungswerkzeug. Im Jahr 2026 ermoeglicht zkML verifizierbare KI-Inferenz on-chain, ZK-Coprozessoren verlagern schwere Berechnungen off-chain mit On-Chain-Verifizierung, und neue Beweissysteme wie SP1 und Jolt machen es praktikabel.","2026-03-28T10:44:45.257775Z",{"id":49,"title":50,"slug":51,"excerpt":52,"locale":12,"category_name":34,"published_at":53},"d0000000-0000-0000-0000-000000000587","EIP-7702 in der Praxis: Smart-Account-Flows nach Pectra erstellen","eip-7702-in-der-praxis-smart-account-flows-nach-pectra-erstellen","EIP-7702 ermoeglicht jedem Ethereum-EOA, innerhalb einer einzelnen Transaktion voruebergehend als Smart Contract zu agieren. So implementieren Sie Batch-Transaktionen, Gas-Sponsoring und Social Recovery mit dem neuen Account-Abstraction-Primitiv.","2026-03-28T10:44:43.781201Z",{"id":13,"name":55,"slug":56,"bio":57,"photo_url":18,"linkedin":18,"role":58,"created_at":59,"updated_at":59},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]