Ethereum wil transacties terugdraaien als de uitkomst niet klopt
Een geldige handtekening is voor Ethereum straks mogelijk niet meer genoeg. Onderzoekers werken aan een beveiligingslaag die een transactie kan terugdraaien wanneer de uiteindelijke financiële uitkomst buiten vooraf ingestelde grenzen valt.
Het concept heet native transaction assertions. Daarmee kan een gebruiker niet alleen vastleggen wat Ethereum moet uitvoeren, maar ook wat na uitvoering minimaal waar moet zijn.
Klopt de eindtoestand niet? Dan worden de uitgevoerde wijzigingen teruggedraaid.
Handtekening bewijst toestemming, niet de gewenste uitkomst
Een digitale handtekening vertelt Ethereum welke instructie een gebruiker heeft goedgekeurd.
Dat garandeert niet dat het economische resultaat hetzelfde is als wat die gebruiker verwachtte.
Tussen ondertekening en uitvoering kan bijvoorbeeld de toestand van een liquiditeitspool veranderen. Een proxycontract kan andere code gebruiken of de volgorde van transacties kan een prijs verschuiven.
Ook kan een gebruiker technisch precies ondertekenen wat op het scherm staat, terwijl de toegestane uitkomst financieel desastreus blijkt.
De Ethereum Foundation noemt dat een outcome mismatch: de gevraagde handeling klopt, maar het eindresultaat niet.
$50,4 miljoen werd ongeveer $36.000
Daarvoor gebruikt de Foundation een extreem praktijkvoorbeeld.
Een gebruiker wilde eerder dit jaar ongeveer $50,4 miljoen aan aEthUSDT omwisselen naar aEthAAVE.
De beschikbare liquiditeit voor zo'n enorme ruil was veel te klein. Complexere offertes vielen bovendien af tijdens de verificatie, waarna uiteindelijk een extreem ongunstige route overbleef.
De interface waarschuwde voor ongeveer 99,9% price impact. De gebruiker bevestigde de transactie alsnog.
Het resultaat: ongeveer 329 aEthAAVE, op dat moment slechts rond $36.000 waard.
De blockchain maakte technisch geen fout.
Hij voerde uit wat geldig was ondertekend.
Dat is precies het probleem dat transaction assertions moeten aanpakken.
Gebruiker kan minimumresultaat vastleggen
Met een assertion krijgt de transactie een extra voorwaarde.
Een tokenruil kan bijvoorbeeld bepalen dat minimaal 10.000 tokens moeten worden ontvangen. Komt er uiteindelijk maar 9.500 binnen, dan faalt de volledige uitvoering.
Andere regels kunnen eisen dat:
- maximaal een vooraf bepaald bedrag wordt uitgegeven;
- geen onverwachte tokenapprovals ontstaan;
- de controle over een account ongewijzigd blijft.
Zo kan een gebruiker niet alleen toestemming geven voor een actie, maar ook grenzen stellen aan wat die actie uiteindelijk met zijn vermogen mag doen.
EIP-7906 laat Ethereum na afloop controleren
Een mogelijke technische uitvoering staat in EIP-7906.
Het voorstel voegt een controlefase toe nadat de normale acties van een transactie zijn uitgevoerd.
Daar kan read-only code bekijken welke nettoveranderingen daadwerkelijk zijn ontstaan.
Dat betreft onder meer ETH-balansen, contractstorage, nieuwe contractcode en uitgezonden events.
EIP-7906 stelt daarvoor drie nieuwe EVM-instructies voor: TXTRACE, TXDIFF en EVENTDATACOPY.
TXTRACE kan de veranderingen doorlopen. TXDIFF kan specifieke begin- en eindwaarden opvragen. EVENTDATACOPY maakt gegevens uit events beschikbaar voor de controle.
Transactie faalt, maar gas blijft betaald
Voldoet het resultaat niet aan de assertion, dan wordt de uitvoering teruggedraaid.
De transactie verdwijnt daarmee niet uit het blok.
Ze krijgt een mislukte status en de gasbetaler betaalt voor de rekenkracht die al is gebruikt.
Dat is een bewuste ontwerpkeuze.
Zonder gaskosten zouden aanvallers complexe transacties kunnen laten uitvoeren en deze vervolgens bewust op het laatste moment laten mislukken. Validators en builders zouden dan wel het rekenwerk doen zonder dat daar kosten tegenover staan.
De gebruiker kan dus zijn vermogen beschermen tegen een ongewenste state change, maar niet kosteloos blijven proberen.
Wallet moet de veiligheidsregel onafhankelijk bepalen
Assertions hebben zelf ook een zwakke plek.
Stel dat een gehackte website zowel de transactie als de bijbehorende veiligheidsregel opstelt.
De aanvaller kan dan simpelweg een assertion toevoegen die zijn eigen kwaadaardige uitkomst toestaat.
De regel moet daarom uit een bron komen die onafhankelijk is van het onderdeel dat de transactie samenstelt.
Een wallet kan bijvoorbeeld een permanent beleid gebruiken. Een aparte simulatie kan een minimale verwachte opbrengst berekenen. Ook een protocol kan eisen dat bepaalde functies alleen mogen worden gebruikt wanneer een specifieke assertion aanwezig is.
Een veiligheidsregel helpt alleen wanneer de partij die wordt gecontroleerd die regel niet zelf ongemerkt kan versoepelen.
Daar verschuift een deel van het veiligheidsprobleem dus naar wallets en accountbeleid.
AI-agent krijgt vrijheid binnen een harde eindgrens
De Ethereum Foundation noemt AI-agenten expliciet als mogelijke toepassing.
Nu kan een gebruiker een agent bijvoorbeeld toestemming geven om alleen bepaalde smart contracts te gebruiken, maximaal een bepaald bedrag uit te geven of slechts tijdelijk te handelen.
Assertions voegen daar iets anders aan toe: voorwaarden voor het resultaat.
Een handelsagent kan bijvoorbeeld zelf bepalen via welke route hij tokens wisselt, zolang de gebruiker minimaal 9.800 USDC terugkrijgt.
De agent behoudt vrijheid over de uitvoering.
Ethereum bewaakt de grens waarbinnen het eindresultaat moet vallen.
Dat kan belangrijk worden wanneer software steeds vaker zelfstandig transacties voorbereidt en uitvoert.
Ook bestaande beveiliging heeft grenzen
Ethereum kent nu al verschillende beschermingslagen.
Een DEX kan een minimumoutput afdwingen. Wallets kunnen transacties simuleren voordat gebruikers ondertekenen. Safe heeft guards waarmee bepaalde veranderingen achteraf kunnen worden gecontroleerd.
Die systemen weten alleen vooraf welke specifieke gegevens ze moeten bekijken.
Native assertions moeten een bredere blik mogelijk maken op de nettoveranderingen die één transactie heeft veroorzaakt.
Dat kan bijvoorbeeld zichtbaar maken dat onverwacht contractstorage is gewijzigd of dat een nieuwe approval is ontstaan.
Het doel is niet iedere transactie ingewikkelder maken.
Het doel is wallets en protocollen een extra middel geven wanneer de uiteindelijke toestand belangrijker is dan alleen de oorspronkelijke instructie.
EIP-7906 is nog niet goedgekeurd
De functie draait nog niet op Ethereum-mainnet.
EIP-7906 heeft de status Draft. Binnen de voorbereiding van Hegotá is het voorstel wel doorgeschoven naar Considered for Inclusion, maar dat betekent nog niet dat het daadwerkelijk onderdeel van die upgrade wordt.
Het ontwerp bouwt bovendien voort op frame transactions uit EIP-8141.
Daarmee kan één transactie uit verschillende uitvoeringsfasen bestaan. EIP-7906 voegt daar een POST_TX-fase aan toe waarin de controle aan het einde plaatsvindt.
De exacte vorm kan dus nog veranderen voordat de techniek eventueel Ethereum bereikt.
Ethereum probeert intentie beter af te dwingen
Daarmee verschuift een fundamentele veiligheidsvraag.
Tot nu toe draait blockchainbeveiliging sterk om autorisatie: bezit iemand de juiste sleutel en heeft diegene deze transactie geldig ondertekend?
Transaction assertions voegen daar uitkomst aan toe.
Een geldige handtekening zegt immers niets over hoeveel een gebruiker uiteindelijk ontvangt, welke onverwachte wijzigingen elders ontstaan of wat een autonome agent onderweg besluit.
Dat onderscheid wordt belangrijker naarmate transacties ingewikkelder worden.
Ethereum probeert daarom niet te raden wat een gebruiker bedoelde.
Het onderzoekt iets concreters: gebruikers vooraf laten vastleggen welke einduitkomst zij absoluut niet willen accepteren.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
