EIP-7702: EOA-codedelegatie en de risico’s

Een gewone EOA ondertekent met een privésleutel en heeft geen uitvoerbare code op het eigen adres. EIP-7702 laat de account verwijzen naar code die al elders is gedeployed en voert die code uit in de context van de account. Adres, saldo en opslagcontext zijn daardoor van de gedelegeerde account, ook al staat de code op een ander adres. Dit is geen verhuizing naar een contract of vervanging van de sleutel.

De EIP-7702-specificatie definieert een type-4-set-code-transactie met een autorisatielijst. De Pectra-gids van Ethereum.org beschrijft dezelfde pointer naar reeds gedeployde code. Een walletlabel als ‘smart account’ vertelt niet welke validatie, herstelmethode of code echt actief is. Controleer wie de code kan wijzigen en wat die met activa en accountopslag mag doen.

Type 4 heeft byte 0x04 en bevat een autorisatielijst. Elke tuple noemt chain-ID, doelcodeadres, nonce van de autoriserende account en een handtekening. De autoriteit tekent de autorisatie; de afzender tekent de buitenste transactie afzonderlijk. Dat kunnen verschillende accounts zijn.

Chain-ID beperkt de autorisatie normaal tot één chain. ID 0 staat een breder bereik toe op chains die EIP-7702 ondersteunen, maar garandeert geen succes: nonce en accountstatus moeten nog steeds kloppen. Omdat een afzender een autorisatie van iemand anders kan opnemen, vergelijk je netwerk, account en volledig doeladres in de ondertekenweergave met een betrouwbare blockexplorer. Een tuple kan worden overgeslagen als de nonce niet klopt.

De transactiedocumentatie van Ethereum.org noemt de autorisatielijst. De buitenste transactie heeft nog steeds gasvoorwaarden en een betaler. Type 4 is niet hetzelfde als ERC-4337-UserOperations of paymasters; zie de smart-accountgids.

De accountcode krijgt de markering 0xef0100 plus het doeladres. De client herkent deze en laadt doelcode bij een aanroep. Het accountadres en het codeadres zijn dus verschillend en moeten allebei worden gecontroleerd. Code wordt van de huidige chain opgehaald; hetzelfde adres kan per chain andere of geen code hebben.

De gedelegeerde code draait met de uitvoeringscontext en opslag van de account. Afhankelijk van de logica kan ze ETH of tokens sturen, externe contracten aanroepen en opslag wijzigen. EIP-7702 voegt geen automatische limiet toe als ‘alleen deze token’. Is het doel een proxy, controleer dan wie de implementatie kan wijzigen en welke upgradeprocedure geldt.

Een fout in de validatie kan transfers, tokenmachtigingen, externe aanroepen of opslagwijzigingen toelaten. De veiligheidsoverwegingen van de EIP waarschuwen dat replaybescherming, doel en calldata, ETH-waarde en gasvoorwaarden aan de handtekening moeten worden gebonden. Zonder die binding kan een sponsor een andere aanroep indienen of een transactie laten mislukken.

Controleer welke contracten de account kan aanroepen, hoe handtekeningen worden gevalideerd, wie nood- of upgradebevoegdheden heeft en of de gedeployde code overeenkomt met geverifieerde broncode. Een auditbadge bewijst niet dat het exacte adres in jouw verzoek is beoordeeld. Lees bij een gebundelde goedkeuring en swap beide oproepen en controleer of de tokenmachtiging tot het benodigde bedrag is beperkt.

EIP-7702 verwerkt autorisaties vóór de uitvoering van de buitenste transactie. De specificatie zegt dat al verwerkte delegatiemarkeringen niet worden teruggedraaid als de uitvoering later mislukt of revert. Een foutmelding betekent dus niet dat de account terug is in de begintoestand. Controleer het transactiebevestiging en de actuele accountcode afzonderlijk.

Bij een sponsortransactie of initialisatie kan autorisatie slagen terwijl een latere aanroep faalt. Dan kan de delegatie actief blijven terwijl de gewenste setup niet is afgerond. Een retry kan door een gewijzigde nonce de oude handtekening ongeldig maken. Controleer transactiehash, autoriserende account, nonce en huidige codepointer vóór je opnieuw verzendt.

Een nieuwe autorisatie kan naar andere code wijzen. Autoriseren van het null-adres wist de delegatiemarkering en laat de accountcode leeg. Dit wist niet automatisch accountopslag, allowances in ERC-20-contracten, voltooide transfers of wijzigingen aan externe contracten. Tokenmachtigingen moet je apart controleren en eventueel intrekken.

Nieuwe code kan dezelfde opslag gebruiken en oude waarden anders interpreteren. Controleer opslagindeling en migratie voordat je wisselt. Voor allowances, zie de gids over token approvals en allowances. Als de privésleutel of seed is blootgesteld, herstelt code wissen die sleutel niet; raadpleeg de wallet-herstelgids.

Bevestig in de officiële walletdocumentatie dat EIP-7702 op de gekozen chain wordt ondersteund. Controleer chain-ID, account, exact doeladres, geverifieerde code en proxybeheerder. Begrijp of ID 0 een bredere chain-scope geeft. Onderscheid de autorisatiehandtekening van de afzender en betaler van de buitenste transactie; sponsoring maakt code niet veilig.

Als de delegatie al actief is, controleer dan de huidige markering en het codeadres, niet alleen het succeslabel. Wijkt het af, pauzeer extra aanroepen en goedkeuringen. Voor gas en nonce, zie de Ethereum-gasprijsgids en de gids voor wachtende transacties.

EIP-7702 verbindt een EOA met gedeployde code. Bundeling, gesponsorde kosten, sessierechten en herstel zijn functies van specifieke code en diensten, geen garanties van het protocol. De Pectra-mainnetaankondiging van de Ethereum Foundation beschrijft het vervangen en intrekken van autorisaties. ERC-4337-UserOperations en paymasters zijn een ander mechanisme.

‘Smart account’ vertelt niet wie de sleutel bezit, code kan upgraden of herstel kan wijzigen. Controleer de echte implementatie en instellingen en verifieer walletondersteuning voordat je een account met activa wijzigt. Deze gids beveelt geen wallet of delegatie aan; bepaal eerst welke functie je nodig hebt en welk vertrouwen de code en service vereisen.