Dencun bei Ethereum: was sich an der EVM geändert hat und was das für Ihre Smart Contracts bedeutet

Dencun ist das Upgrade vonEthereum, das am 13. März 2024 um 13:55 UTC in Epoche 269568 aktiviert wurde. Der Name verbindet die Namen der beiden Hälften, die gleichzeitig aktualisiert wurden: Cancun, die Ausführungsschicht, in der die EVM und die Contracts laufen, und Deneb, die Konsensschicht, in der die Validatoren arbeiten. Laut derAnkündigung der Ethereum Foundationumfasste es neun Verbesserungsvorschläge. Der bekannteste, EIP-4844, führte die Blobs ein, mit denen Layer-2-Netzwerke ihre Daten veröffentlichen.

Für alle, die Smart Contracts schreiben, hat Dencun im Code jedoch etwas anderes hinterlassen: vier Änderungen an der EVM, die Compiler seit 2024 standardmäßig nutzen. Transienter Speicher, die Instruktion MCOPY, das neue Verhalten von SELFDESTRUCT und der Zugriff eines Contracts auf die Blob-Gebühr und den Root der Beacon Chain verändern, welche Muster funktionieren, und machen es nötig, die EVM-Version je nach Zielnetzwerk festzulegen. Den Weg der Blobs von 2024 bis Fusaka, mit ihrem Format und ihrem Preis, beschreibt unser Artikel überEIP-4844 und die Kosten der Blobs; hier konzentrieren wir uns darauf, was Dencun für einen Contract verändert hat.

Die neun Vorschläge von Dencun und wen sie jeweils betreffen

Die Ankündigung ordnet die Vorschläge keiner Schicht zu, daher sortiert die Tabelle sie nach ihrer praktischen Wirkung. Die ersten fünf zeigen sich im Code eines Contracts oder bei seiner Kompilierung; die übrigen betreffen Rollups oder den Betrieb der Validatoren.

Keiner dieser Vorschläge hat bereits deployte Contracts automatisch verändert: Der vorhandene Bytecode bleibt gleich und nutzt MCOPY oder transienten Speicher nur, wenn er neu kompiliert und erneut deployt wird. Für alle Contracts, ob deployt oder nicht, änderte sich dagegen das Verhalten von SELFDESTRUCT.

Transienter Speicher: Was TSTORE und TLOAD speichern

EIP-1153führte zwei Instruktionen ein, TSTORE (0x5d) und TLOAD (0x5c). Sie schreiben und lesen einen Speicher mit denselben Schlüsseln wie der persistente Storage, der jedoch am Ende der Transaktion gelöscht wird. Sie kosten jeweils 100 Gas, genauso viel wie ein warmer Storage-Zugriff, ohne die Kosten für das Schreiben in den State und ohne Erstattungslogik. Wird ein Aufruf zurückgesetzt (Revert), werden die seit seinem Beginn erfolgten transienten Schreibvorgänge rückgängig gemacht, wie beim persistenten Storage, und innerhalb eines STATICCALL löst TSTORE eine Exception aus.

Als Anwendungsfall nennt der Vorschlag selbst die Reentrancy-Sperre, die einen Zustand während der Transaktion speichern muss und nicht darüber hinaus. Die 5.x-Linie von OpenZeppelin Contracts enthältReentrancyGuardTransient, eine Variante von ReentrancyGuard, die die Sperre im transienten Speicher ablegt, und seitVersion 0.8.28unterstützt Solidity transiente Zustandsvariablen von Werttypen, ohne auf Assembly zurückgreifen zu müssen.

Der Unterschied zum Memory hat eine Folge, auf die die Spezifikation in ihren Sicherheitshinweisen eingeht. Memory wird am Ende jedes Aufrufs geleert; transienter Speicher bleibt für die gesamte Transaktion bestehen. Hinterlässt ein Contract einen Wert in einem Slot und liest ein späterer Aufruf in derselben Transaktion diesen Slot, findet er diesen Wert vor. Das ist relevant, wenn ein Contract mehrere verkettete Aufrufe in einer Transaktion erhält, etwa wenn Operationen aus einer Wallet gebündelt werden. Daraus folgt die Praxis, den Slot am Ende der Funktion zu leeren, es sei denn, der Wert soll tatsächlich an einen späteren Aufruf weitergegeben werden.

SELFDESTRUCT nach EIP-6780: Welches Muster nicht mehr funktioniert

Seit Dencun gilt lautEIP-6780, dass SELFDESTRUCT, wenn es in einer anderen Transaktion als der ausgeführt wird, in der der Contract erstellt wurde, die Ausführung beendet und das gesamte Ether-Guthaben an den Empfänger sendet, aber weder den Code noch den Storage noch das Konto löscht. Das frühere Verhalten bleibt nur erhalten, wenn der Contract in derselben Transaktion erstellt und zerstört wird.

Betroffen ist das Muster von Contracts, die durch erneutes Deployment an derselben Adresse aktualisiert wurden: Eine Factory erstellte den Contract mit CREATE2, zerstörte ihn mit SELFDESTRUCT und erzeugte an dieser Adresse neuen Code. Da der Code nicht mehr gelöscht wird, findet die zweite Erstellung die Adresse belegt vor und schlägt fehl. Die Spezifikation erklärt dieses Muster ausdrücklich für nicht unterstützt und verweist auf Proxy-Muster wieERC-2535oder einen Proxy mitEIP-1967. Ein Audit eines Contracts aus der Zeit vor 2024, der auf SELFDESTRUCT angewiesen ist, muss prüfen, was dieser Codepfad heute bewirkt, denn seine Wirkung im Mainnet ist nicht mehr die, die beim Schreiben getestet wurde.

MCOPY, BLOBBASEFEE und die Root der Beacon Chain

MCOPY aus EIP-5656 kopiert einen Speicherbereich mit einer einzigen Instruktion. Praktisch bedeutsam ist das vor allem im Compiler: DieSolidity-Version 0.8.25machte cancun zur Standard-EVM-Version und nutzt MCOPY seitdem im generierten Code zum Kopieren von Byte-Arrays statt Schleifen aus mload und mstore. Ein mit einer aktuellen Version neu kompilierter Contract kann MCOPY enthalten, auch wenn sein Autor die Instruktion nie selbst geschrieben hat.

BLOBBASEFEE(0x4a, 2 Gas) liefert die Blob-Basisgebühr im aktuellen Block, die sich von der Basisgebühr für Execution-Gas unterscheidet. Der Vorschlag sieht sie dafür vor, dass der Contract eines Rollups die Kosten seiner Daten on-chain prüfen kann, ohne von einem Dritten abhängig zu sein, sowie für Instrumente, mit denen sich diese Kosten über die Zeit absichern lassen. Solidity stellt sie als block.blobbasefee bereit, zusammen mit blobhash() zum Auslesen des versionierten Hashs eines Blobs.

EIP-4788speichert die Root des Elternblocks der Beacon Chain in einem System-Contract an der Adresse 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02, der über einen Zeitstempel abgefragt wird. Er hält die letzten 8.191 Einträge vor, das entspricht etwa einem Tag an Blöcken. Mit dieser Root und einem Merkle-Proof kann ein Smart Contract Daten der Konsensschicht verifizieren, etwa den Saldo eines Validators, ohne Oracle; der Vorschlag nennt als Anwendungsfälle Staking-Protokolle, Restaking und Bridges. Die Root belegt nur, was zur Konsensschicht gehört: Alle anderen externen Daten brauchen weiterhin einen eigenen Verifikationsmechanismus.

Derselbe Smart Contract auf zwei EVM-Netzwerken: ein Fehler, der erst nach dem Deployment auftritt

Nehmen wir als hypothetisches Beispiel ein Team, das mit Solidity 0.8.38, der im Oktober 2026 zuletzt veröffentlichten Version, einen Einzahlungs-Contract kompiliert, der seine Funktionen mit ReentrancyGuardTransient absichert. Es legt keine EVM-Version fest, also verwendet der Compiler die Standardversion, die seit derVersion 0.8.31vom Dezember 2025 osaka lautet. Das Team deployt denselben Bytecode auf Ethereum und auf einem EVM-Netzwerk, das die Cancun-Änderungen noch nicht übernommen hat.

Auf Ethereum funktioniert alles. Im zweiten Netzwerk kann das Deployment zwar durchlaufen, weil die EVM beim Deployment nicht prüft, welche Instruktionen der Code enthält, doch der erste Aufruf einer geschützten Funktion wird bei TSTORE revertiert, einer Instruktion, die dieses Netzwerk nicht kennt. Kopiert der Contract Byte-Arrays, löst MCOPY denselben Fehler auf einem anderen Pfad aus. Das Team bemerkt das Problem erst, wenn bereits Mittel oder Integrationen auf diese Adresse verweisen.

Die Korrektur besteht nicht nur darin, einen Parameter zu ändern. DieDokumentation des Compilerserlaubt es, evmVersion für jedes Kompilierungsziel festzulegen, und mit einer Version vor cancun akzeptiert der Compiler tstore und tload im Inline-Assembly nicht mehr. Der Contract müsste für dieses Netzwerk also auf ReentrancyGuard mit persistentem Storage zurückgreifen. Praktisch bedeutet das: einmal pro Zielnetzwerk kompilieren, mit der EVM-Version, die dieses Netzwerk aktiviert hat, und diese Konfiguration zusammen mit den deployten Adressen dokumentieren, genau wie die Compiler-Version. Hardhat und Foundry erlauben es, sie in der Konfiguration festzulegen; worin sich beide Umgebungen unterscheiden, erläutern wir in unserem VergleichHardhat und Foundry.

Dencun für Entwickler: Die dauerhafte Änderung liegt in der EVM, für die Sie kompilieren

Dencun ist vor allem für die günstigeren Daten der Layer-2-Netzwerke bekannt, und dieser Effekt ist real. Für ein Smart-Contract-Team liegt die nachhaltigere Wirkung jedoch woanders. Der transiente Speicher bot ein günstiges und korrektes Werkzeug für Zustände, die nur während einer Transaktion bestehen sollen, etwa eine Reentrancy-Sperre; EIP-6780 schloss ein Upgrade-Muster, mit dem sich der Code einer Adresse ändern ließ, ohne dass die Nutzer es bemerkten; und EIP-4788 ermöglichte es, Konsensdaten ohne Oracle zu verifizieren. Alle drei Änderungen gelten im November 2026 weiterhin.

Der Preis dafür ist eine weitere Abhängigkeit, die kontrolliert werden muss. Die Standard-EVM-Version rückt mit jedem Ethereum-Upgrade vor (cancun 2024, osaka seit Dezember 2025, und Solidity führt amsterdam für Glamsterdam bereits als experimentell), während jedes EVM-kompatible Netzwerk seinen eigenen Zeitplan festlegt. „EVM-kompatibel“ sagt nichts darüber, mit welcher Version, und diese Frage gehört zusammen mit der Compiler-Version zu jedem Deployment auf mehreren Netzwerken.

Wenn Sie denselben Code auf mehreren Netzwerken deployen wollen oder Contracts aus der Zeit vor 2024 betreuen, die SELFDESTRUCT verwenden: Bei Metlabs entwickeln und prüfen wirSmart Contractsfür Ethereum und EVM-kompatible Netzwerke:erzählen Sie uns davonwelche Netzwerke und welche Versionen Sie einsetzen, und wir klären gemeinsam mit Ihnen, welche Konfiguration jedes Deployment benötigt.