Ethereum-ontwikkelaars hebben een voorstel gedaan dat on-chain code de mogelijkheid geeft te verifiëren wat een transactie daadwerkelijk heeft gewijzigd — en om de volledige transactie terug te draaien als de uitkomst regels schendt die een gebruiker vooraf heeft ingesteld. Het concept, bekend als native transaction-asserties, werd uitgelicht door de Ethereum Foundation in een blogpost die op 5 oktober 2026 werd gepubliceerd.

Het voorstel richt zich op een van de oudste en meest hardnekkige zwakke punten in de beveiliging van cryptocurrency: blind signing.

Het probleem van blind signing

Blind signing is in crypto het equivalent van akkoord gaan met algemene voorwaarden zonder ze te lezen. Een wallet toont een verzoek, de details zijn onleesbaar of onduidelijk, en de gebruiker keurt het toch goed. Meestal gaat er niets mis, maar wanneer dat wel zo is, zijn de gevolgen vaak kostbaar. De zwakte ligt geworteld in de opbouw van Ethereum-transacties: de ondertekende payload is machinale data in plaats van gewone taal, zodat wat op een wallet-scherm verschijnt een interpretatie van die data door de interface is.

De Ethereum Foundation positioneerde het nieuwe werk als een directe reactie op die risico's, die waren aangemerkt onder het Trillion Dollar Security-initiatief. Dat programma omvat al maatregelen zoals Clear Signing, dat zich richt op het leesbaar maken van transactieverzoeken voordat een gebruiker ze goedkeurt.

Native transaction-asserties werken in een andere fase van het proces. Clear Signing probeert gebruikers te helpen een transactie te begrijpen voordat deze wordt uitgevoerd. Asserties controleren of het resultaat aan de verwachtingen voldeed nadat de transactie heeft gedraaid.

In EIP-7906

De technische kern van het voorstel is EIP-7906, dat drie nieuwe opcodes introduceert in de Ethereum Virtual Machine: TXTRACE, TXDIFF en EVENTDATACOPY. Opcodes zijn de laagdrempelige instructies die de EVM begrijpt, dus het toevoegen van nieuwe breidt uit wat slimme contractcode kan zien en doen.

In dit geval geven de nieuwe instructies on-chain code een manier om de daadwerkelijke statuswijzigingen te inspecteren die een transactie heeft veroorzaakt. Dat verschuift de verificatie van wat een transactie beweert te zullen doen naar wat deze aantoonbaar heeft gedaan.

Hoe het aansluit op EIP-8141

EIP-7906 staat niet op zichzelf. Het is afhankelijk van het raamwerk dat in EIP-8141 is uiteengezet, bekend als het frame transaction-formaat. Transactieformaten zijn fundamentele infrastructuur: elke node, wallet en ontwikkelaarstool moet ze kunnen verwerken, waardoor veranderingen op dit niveau de hele stack bereiken.

Frame-transacties splitsen een enkele transactie op in afzonderlijke segmenten, of frames. EIP-7906 voegt een nieuw element toe aan die structuur: een POST_TX-frame.

Het POST_TX-frame werkt als een static call tijdens de uitvoering. Een static call is een read-only operatie, wat betekent dat het de status kan inspecteren maar niet kan wijzigen. Als aan de voorwaarden in dat frame niet wordt voldaan, kunnen de effecten van de transactie worden teruggedraaid.

Status en tijdlijn

Niets van het hier beschreven is al live. EIP-7906 verkeert nog in conceptstatus. Volgens het ontwikkelproces van Ethereum moet een concept de beoordeling doorstaan en worden geaccepteerd door de ontwikkelaars die een upgrade coördineren voordat de wijzigingen het netwerk bereiken. Het doel is om het op te nemen in de Hegotá-upgrade, waarvan de invoering in 2027 wordt verwacht.

Voorlopige demonstraties zijn al uitgevoerd op een development network, wat suggereert dat de mechanismen functioneren buiten een witboek. EIP-7906 hangt ook af van EIP-8141, dus het lot ervan is gekoppeld aan de vraag of het frame transaction-formaat ook doorgaat.

Waarom dit ertoe doet buiten de code

Native asserties zouden een deel van de last van signeringsrisico naar de basislaag verplaatsen. Als het protocol uitkomstcontroles direct kan afdwingen, worden gebruikers minder afhankelijk van het feit of één enkele wallet zijn weergavelogica perfect heeft.

Voor instellingen en bedrijven is de aantrekkingskracht eenvoudig te zien. Organisaties die grote bedragen verplaatsen willen doorgaans garanties, geen beste pogingen. Een mechanisme dat automatisch een transactie kan terugdraaien waarvan de resultaten buiten bepaalde parameters vallen, sluit naadloos aan bij het soort risicobeheersing dat deze partijen elders al gebruiken.

Er blijven open vragen. Ontwikkelaars zullen ook moeten uitzoeken hoe gewone gebruikers de regels definiëren waaraan hun transacties moeten voldoen, want een vangnet dat expertconfiguratie vereist, beschermt uiteindelijk mogelijk vooral experts. De bruikbaarheidslaag die bovenop EIP-7906 wordt gebouwd, zou net zo bepalend kunnen zijn als de opcodes zelf.

Er is ook een afweging. Elke nieuwe opcode vergroot het oppervlak dat moet worden geïmplementeerd en gecontroleerd over meerdere Ethereum-clients. Beveiligingsverbeteringen die nieuwe randgevallen introduceren, moeten die kosten rechtvaardigen.

Belangrijke aandachtspunten zijn of EIP-7906 uit de conceptfase komt, of EIP-8141 een plek in Hegotá krijgt, en of meer devnet-testen volgen op de eerste demonstraties.