De Ethereum Foundation onderzoekt transactieasserties waarmee gebruikers afdwingbare voorwaarden kunnen koppelen aan de uiteindelijke uitkomst van een transactie, in plaats van alleen te vertrouwen op goedkeuring van de aangevraagde handeling. Het onderzoek maakt deel uit van het initiatief Trillion Dollar Security en richt zich op een lacune in de transactiebeveiliging: een geldige handtekening garandeert niet dat de resulterende saldi, machtigingen of accountbeheer overeenkomen met wat de ondertekenaar bedoelde.
Belangrijkste punten
- De voorgestelde controles zouden tijdens de uitvoering de transactie-uitkomsten evalueren en handelingen terugdraaien die een ondertekende regel schenden.
- De bescherming is afhankelijk van regels die onafhankelijk worden goedgekeurd van een mogelijk gecompromitteerde transactieopbouwer.
- Het onderzoek zou ondersteuning kunnen bieden voor veiligheidsbeleid van wallets, gedelegeerde agents en solver-workflows, maar er is geen implementatie aangekondigd.
Inhoudsopgave
- Waarom het goedkeuren van een transactie toch tot verlies kan leiden
- Hoe transactieasserties de uitkomst zouden controleren
- Welke informatie de voorgestelde implementatie beschikbaar zou maken
- Waar wallets en protocollen aanpassingen zouden moeten doorvoeren
- Wat agents en solver-workflows eraan zouden kunnen hebben
- Conclusie
Waarom het goedkeuren van een transactie toch tot verlies kan leiden
Ethereum voert het verzoek uit dat een gebruiker autoriseert, op basis van de code en toestand die beschikbaar zijn op het moment van uitvoering. Die omstandigheden kunnen afwijken van wat de gebruiker heeft gecontroleerd. Zo kan een proxy-implementatie vóór de uitvoering veranderen, terwijl de volgorde van transacties van invloed kan zijn op de prijs waartegen een swap wordt uitgevoerd.
De foundation maakt onderscheid tussen misleidende verzoeken en ongewenste uitkomsten. Bij de aanvallen op Bybit en BadgerDAO toonden gecompromitteerde frontends ondertekeningsverzoeken die afweken van wat gebruikers dachten goed te keuren. Een correct weergegeven verzoek kan daarentegen nog steeds een economisch schadelijke uitkomst toestaan.
Het voorbeeld betreft een onderpandruil via Aave en CoW, met ongeveer $50.4 miljoen aan aEthUSDT. De geringe liquiditeit van AAVE en de gaslimiet van CoW resulteerden in een geverifieerde quote van ongeveer 329 aEthAAVE. Ondanks een weergegeven waarschuwing voor een prijsimpact van 99.9 procent en de bevestiging dat de volledige waarde verloren kon gaan, ondertekende de gebruiker de transactie en ontving tokens ter waarde van ongeveer $36,000.
Dat onderscheid verklaart waarom betere transactiebeschrijvingen niet de volledige oplossing zijn. Clear Signing helpt gebruikers de aangevraagde handeling te begrijpen. Simulatie schat de effecten in op basis van een geselecteerde toestand van de blockchain. Geen van beide legt op zichzelf een onafhankelijke voorwaarde op aan de uitkomst die daadwerkelijk optreedt.
| Item | Details |
|---|---|
| TXTRACE | Brengt de netto toestandswijzigingen en uitgezonden events van de transactie in kaart. |
| TXDIFF | Haalt begin- en eindwaarden op voor opgegeven adressen en opslaglocaties. |
| EVENTDATACOPY | Kopieert de gegevens van een event naar het geheugen voor inspectie. |
| Implementatiegegevens | De voorgestelde gegevens over toestandswijzigingen omvatten nieuw geïmplementeerde contracten en hun codehashes. |
Hoe transactieasserties de uitkomst zouden controleren
Een assertie zou na uitvoering van de handelingen met behulp van alleen-lezenlogica de begin- en eindtoestand van een transactie vergelijken. De voorwaarde zou in de transactie worden opgenomen en samen met de handelingen worden ondertekend. Als niet aan de voorwaarde wordt voldaan, zouden die handelingen worden teruggedraaid.
Mogelijke regels zijn onder meer een minimumhoeveelheid die moet worden ontvangen, een bestedingslimiet, beperkingen op nieuwe tokengoedkeuringen of het behoud van de controlelogica van een account. De voorgestelde inspectiemogelijkheden reiken verder dan saldi en omvatten opslag, code, nieuw geïmplementeerde contracten en uitgezonden events.
Bestaande contractcontroles beschermen nu al bepaalde uitkomsten. Uniswap kan swaps afwijzen die minder dan een opgegeven minimumopbrengst opleveren, en een Safe-guard kan na uitvoering de accounttoestand inspecteren. De beperking is de zichtbaarheid: zulke controles moeten vooraf bepalen wat ze moeten onderzoeken en zijn doorgaans afhankelijk van de interfaces die andere contracten beschikbaar stellen. Een proxy hoeft bijvoorbeeld geen functie aan te bieden die het implementatieadres bekendmaakt.
Native asserties zouden de volledige netto-effecten van de transactie beschikbaar maken voor controle, waaronder wijzigingen waarop een gewone guard mogelijk niet bedacht is. Maar bredere zichtbaarheid is alleen nuttig als de regel betrouwbaar is. Een kwaadwillende frontend zou een voorwaarde kunnen aanleveren die haar eigen aanval toestaat. Het beleid moet daarom voortkomen uit onafhankelijk goedgekeurde intenties, accountbeleid of beschermde protocollogica.
Welke informatie de voorgestelde implementatie beschikbaar zou maken
In de aankondiging van native transactieasserties beschrijft de foundation EIP-7906 als een mogelijke implementatie, niet als een definitief ontwerp. Het bouwt voort op de frametransacties in EIP-8141, die validatie- en uitvoeringsstappen in een geordende reeks plaatsen. EIP-8141 staat gepland voor Hegotá; EIP-7906 heeft de status Considered for Inclusion bereikt, maar is niet bevestigd voor die upgrade.
Bij deze aanpak zou een alleen-lezen POST_TX-frame de resultaten aan het einde van de uitvoering inspecteren. De voorgestelde instructies voor gegevenstoegang zouden alleen binnen dat frame werken, en niet in de volledige EVM.
De informatie zou netto-effecten beschrijven, geen geschiedenis van elke tussentijdse schrijfactie. Een opslaglocatie die herhaaldelijk is gewijzigd, zou met de begin- en eindwaarde worden weergegeven; een locatie die naar de oorspronkelijke waarde is teruggezet, zou niet worden vermeld. Daarom is het belangrijk onderscheid te maken tussen handhaving op basis van de eindtoestand en het monitoren van elke uitvoeringsstap.
Als een controle faalt, zou het uitvoeringsgedeelte worden teruggedraaid, maar de transactie zou als mislukt in het blok blijven staan. De gasbetaler zou nog steeds betalen voor het verbruikte gas, zodat opzettelijk falende transacties bouwers niet met gratis uitvoeringswerk opzadelen.
Waar wallets en protocollen aanpassingen zouden moeten doorvoeren
Het voorstel biedt een controlemogelijkheid, maar verplicht niet automatisch tot het gebruik ervan. Voor transacties van een gebruiker zou de wallet het veiligheidsbeleid onderdeel moeten maken van de transactieopbouw, in plaats van de bouwer vrij te laten om het weg te laten. Dat beleid zou kunnen voortkomen uit de eigen simulatie van de wallet of als permanente accountregel kunnen gelden.
Bij protocollen zou bescherming moeten worden ingebouwd in de voorwaarden voor toegang tot een beschermde functie. Alleen een transactie aanbieden die asserties ondersteunt, zou niet volstaan: de aanroep zou de specifieke controle moeten bevatten die het protocol vereist. Dit zou de integratievereisten voor aanroepers veranderen, terwijl reeds geïmplementeerde onveranderlijke contracten die toegangscontrole niet achteraf zouden kunnen toevoegen.
Deze afhankelijkheden maken duidelijk dat een potentieel krachtige EVM-mogelijkheid niet hetzelfde is als een garantie voor gebruikers. Effectieve bescherming vereist zowel een deugdelijke voorwaarde als software die ervoor zorgt dat die voorwaarde consequent niet kan worden omzeild.
Wat agents en solver-workflows eraan zouden kunnen hebben
Gedelegeerde agents zouden niet alleen door machtigingen, maar ook door uitkomsten kunnen worden beperkt. Limieten op de contracten die een agent mag gebruiken of het bedrag dat hij mag uitgeven, zouden kunnen worden aangevuld met vereisten voor de toestand die na elke transactie overblijft.
Bij uitvoering via solvers zou een protocol een aanvaardbare uitkomst kunnen vastleggen en de solver tegelijk de route laten kiezen. De garantie zou beperkt blijven tot een transactie op één netwerk en zou niet gelden voor een route die meerdere chains overspant.
Asserties zouden ook kunnen controleren of een workflow correct wordt afgerond, bijvoorbeeld door ongebruikte tokens terug te geven en resterende goedkeuringen in te trekken. De foundation vraagt wallet- en protocolteams om input terwijl het ontwerp verder wordt ontwikkeld. Deze mogelijke toepassingen zijn dan ook onderzoekrichtingen en geen aangekondigde productfuncties.
Conclusie
Native transactieasserties zouden een deel van de Ethereum-transactiebeveiliging verschuiven van het interpreteren van een verzoek naar het afdwingen van de uitkomst ervan. Hun praktische waarde zou afhangen van betrouwbaar beleid en adoptie door de wallets en protocollen die verantwoordelijk zijn voor de toepassing ervan.
Meer nieuws lezen
Disclaimer
Dit artikel van FinanceVelix verstrekt algemene informatie en is geen persoonlijk financieel, beleggings-, juridisch of fiscaal advies. Cryptoprijzen kunnen snel veranderen en u kunt uw volledige belegde bedrag verliezen. De feiten zijn gebaseerd op het beschikbare materiaal op het moment van publicatie en kunnen veranderen. Controleer belangrijke informatie zelfstandig en raadpleeg zo nodig een gekwalificeerde professional. Het vermelden van een activum, bedrijf of dienst houdt geen aanbeveling in.
