Ethereum-Entwickler haben einen Vorschlag vorgelegt, der On-Chain-Code in die Lage versetzen soll zu überprüfen, was eine Transaktion tatsächlich geändert hat – und die gesamte Transaktion zurückzusetzen, falls das Ergebnis vorab vom Nutzer festgelegte Regeln verletzt. Das Konzept, bekannt als native Transaktions-Assertions, wurde von der Ethereum Foundation in einem am 5. Oktober 2026 veröffentlichten Blogbeitrag vorgestellt.

Der Vorschlag richtet sich gegen eine der ältesten und hartnäckigsten Schwachstellen der Kryptosicherheit: das Blind Signing.

Das Problem des Blind Signing

Blind Signing ist im Kryptobereich das Äquivalent dazu, Allgemeine Geschäftsbedingungen zu akzeptieren, ohne sie zu lesen. Eine Wallet präsentiert eine Anfrage, die Details sind unleserlich oder unklar, und der Nutzer genehmigt sie trotzdem. Meistens geht nichts schief – aber wenn doch, sind die Folgen in der Regel teuer. Die Schwachstelle liegt in der Konstruktion von Ethereum-Transaktionen begründet: Die signierte Nutzlast ist maschinenformatierte Daten statt Klartext, sodass auf dem Wallet-Bildschirm nur die Interpretation dieser Daten durch eine Benutzeroberfläche erscheint.

Die Ethereum Foundation rahmte die neue Arbeit als direkte Reaktion auf diese Risiken ein, die im Rahmen ihrer Trillion Dollar Security Initiative identifiziert wurden. Dieses Programm umfasst bereits Maßnahmen wie Clear Signing, das darauf abzielt, Transaktionsanfragen verständlich zu machen, bevor ein Nutzer sie genehmigt.

Native Transaktions-Assertions greifen an einer anderen Stelle des Prozesses an. Clear Signing soll Nutzern helfen, eine Transaktion vor ihrer Ausführung zu verstehen. Assertions prüfen, ob das Ergebnis nach der Ausführung den Erwartungen entsprochen hat.

Im Inneren von EIP-7906

Der technische Kern des Vorschlags ist EIP-7906, das drei neue Opcodes für die Ethereum Virtual Machine einführt: TXTRACE, TXDIFF und EVENTDATACOPY. Opcodes sind die Low-Level-Befehle, die die EVM versteht; neue Opcodes erweitern also, was Smart-Contract-Code sehen und tun kann.

In diesem Fall geben die neuen Befehle dem On-Chain-Code eine Möglichkeit, die tatsächlichen Zustandsänderungen zu inspizieren, die eine Transaktion erzeugt hat. Das verlagert die Verifizierung von dem, was eine Transaktion zu tun behauptet, auf das, was sie nachweislich getan hat.

Wie er in EIP-8141 integriert wird

IP-7906 steht nicht allein. Es stützt sich auf den in EIP-8141 beschriebenen Rahmen, das sogenannte Frame-Transaktionsformat. Transaktionsformate sind grundlegende Infrastruktur: Jeder Node, jede Wallet und jedes Entwicklerwerkzeug muss sie verarbeiten können – an dieser Schicht reicht eine Änderung also über den gesamten Stack.

Frame-Transaktionen zerlegen eine einzelne Transaktion in getrennte Segmente, sogenannte Frames. EIP-7906 fügt dieser Struktur ein neues Element hinzu: einen POST_TX-Frame.

Der POST_TX-Frame arbeitet während der Ausführung als statischer Call. Ein statischer Call ist eine Read-Only-Operation: Er kann den Zustand prüfen, aber nicht verändern. Sind die in diesem Frame definierten Bedingungen nicht erfüllt, können die Auswirkungen der Transaktion zurückgesetzt werden.

Status und Zeitplan

Nichts davon ist bisher live. EIP-7906 befindet sich noch im Entwurfsstatus. Nach Ethereums Entwicklungsprozess muss ein Entwurf die Review durchlaufen und die Zustimmung der Entwickler gewinnen, die ein Upgrade koordinieren, bevor seine Änderungen das Netzwerk erreichen. Das Ziel ist die Aufnahme in das Hegotá-Upgrade, dessen Einführung für 2027 erwartet wird.

Erste Demonstrationen wurden bereits in einem Entwicklungsnetzwerk durchgeführt, was darauf hindeutet, dass die Mechanik auch jenseits des Whitepapers funktioniert. EIP-7906 hängt zudem von EIP-8141 ab, sodass sein Schicksal davon abhängt, ob auch das Frame-Transaktionsformat den Sprung schafft.

Warum es über den Code hinaus wichtig ist

Native Assertions würden einen Teil der Last des Signierrisikos in die Basisebene verlagern. Kann das Protokoll Ergebnisprüfungen direkt durchsetzen, sind Nutzer weniger davon abhängig, dass eine einzelne Wallet ihre Anzeigelogik perfekt umsetzt.

Für Institutionen und Unternehmen ist der Nutzen naheliegend. Organisationen, die große Summen bewegen, wollen in der Regel Garantien statt Bestrebungen. Ein Mechanismus, der eine Transaktion automatisch zurücksetzen kann, deren Ergebnisse außerhalb definierter Parameter liegen, fügt sich nahtlos in die Risiko­kontrollen ein, die diese Akteure bereits andernorts einsetzen.

Offene Fragen bleiben dennoch. Entwickler müssen außerdem klären, wie normale Nutzer die Regeln definieren, die ihre Transaktionen erfüllen müssen – ein Sicherheitsnetz, das expertenkonfiguriert werden muss, schützt am Ende womöglich vor allem Experten. Die auf EIP-7906 aufbauende Bedienbarkeit könnte ebenso entscheidend sein wie die Opcodes selbst.

Es gibt auch einen Trade-off abzuwägen. Jeder neue Opcode vergrößert die Fläche, die über mehrere Ethereum-Clients hinweg implementiert und auditiert werden muss. Sicherheitsverbesserungen, die neue Randfälle einführen, müssen diesen Aufwand rechtfertigen.

Zentrale Markierungen, die zu beobachten sind: ob EIP-7906 den Entwurfsstatus verlässt, ob EIP-8141 einen Platz in Hegotá erhält und ob weitere Devnet-Tests auf die frühen Demonstrationen folgen.