Crypto Wallets Getransformeerd: Hoe Account Abstractie Alles Verandert

In eenvoudige bewoordingen stelt accountabstractie gebruikers in staat om slimme contracten te gebruiken als hun accounts – waardoor crypto wallets effectief programmeerbaar worden. Dit is een baanbrekende verschuiving in hoe gebruikers omgaan met blockchain-applicaties, en velen geloven dat het een belangrijke stap is naar het gebruiksvriendelijker, veiliger en meer geschikt maken van crypto voor massale adoptie.

Ethereum’s mede-oprichter Vitalik Buterin heeft zelfs gesuggereerd dat zonder het adopteren van accountabstractie Ethereum mogelijk zijn doelen niet zou bereiken, wat onderstreept hoe belangrijk deze technologie kan zijn voor de toekomst van Web3.

Maar wat is accountabstractie precies en hoe werkt het? Om de betekenis ervan te waarderen, moeten we eerst begrijpen hoe blockchain-accounts traditioneel functioneren en waarom dat oude model beperkingen heeft. Dan gaan we in op hoe accountabstractie het spel verandert, de voordelen ervan verkennen (zoals betere beveiliging en een gemakkelijker gebruikerservaring), echte voorbeelden in actie zien, en onderzoeken welke uitdagingen er nog zijn.

Aan het einde zul je zien waarom accountabstractie vaak wordt geprezen als een grote upgrade voor crypto wallets – een die het eindelijk mogelijk zou kunnen maken om crypto net zo naadloos te beheren als het gebruik van een moderne financiële app.

Het Traditionele Accountmodel: EOAs vs. Smart Contract Accounts

Blockchains zoals Ethereum gebruiken vandaag de dag een accountmodel voor het beheren van activa en het uitvoeren van transacties. Er zijn twee hoofdtypen accounts op Ethereum:

Extern Beheerde Accounts (EOAs) – Dit zijn de “normale” gebruikersaccounts, beheerd door een individu via een privésleutel. Als je een Ethereum-wallet hebt aangemaakt (zoals MetaMask of een hardwarewallet), heb je een EOA. Met een EOA heb je een openbaar adres (afgeleid van je publieke sleutel) en een privésleutel waarmee je transacties kunt ondertekenen. Met een EOA kun je munten of tokens aanhouden en transacties versturen om fondsen over te dragen of om slimme contracten aan te roepen. Belangrijk is dat een EOA zelf transacties kan initiëren (met een handtekening van de privésleutel), maar het kan geen aangepaste code uitvoeren – het is niet programmeerbaar buiten basisfunctionaliteit voor verzenden. EOAs zijn beperkt tot twee hoofdfuncties: waarde (ETH of tokens) naar een ander account sturen of een functie op een slim contract aanroepen.
Contract Accounts (Slimme Contracten) – Dit zijn accounts die worden beheerd door code (slimme contractcode) in plaats van door een privésleutel. Een contractaccount kan activa aanhouden en regels of logica definiëren (code) die worden uitgevoerd wanneer het een transactie ontvangt. Bijvoorbeeld, een gedecentraliseerde toepassing of een tokencontract bevindt zich bij een contractaccount. Een contractaccount kan echter geen transacties uit eigen beweging initiëren. Het voert zijn code alleen uit wanneer het wordt getriggerd door een transactie van een EOA of een ander contract. Met andere woorden, iemand (of een extern account) moet het contract aanroepen om actie te ondernemen. Contractaccounts zijn volledig programmeerbaar en kunnen complexe regels afdwingen, maar ze missen het vermogen om autonoom te handelen – er is geen privésleutel die ze direct aanstuurt om nieuwe transacties te verzenden.

Vergelijking van Ethereum-accounttypen: Extern Beheerde Accounts (EOA) vs Slimme Contract Accounts (SCA). EOAs worden beheerd door privésleutels en kunnen transacties initiëren, maar kunnen geen willekeurige code uitvoeren. SCA's (slimme contracten) kunnen code uitvoeren maar niet zelfstandig nieuwe transacties starten. Account abstractie streeft naar het opheffen van deze scheiding.

In het huidige paradigma zijn deze twee accounttypen gescheiden, en heeft elk zijn nadelen. EOAs, gekoppeld aan een enkele privésleutel, hebben aanzienlijke beperkingen en kwetsbaarheden: als je de toegang tot die privésleutel (of de backup seed phrase) verliest, verlies je de toegang tot het account en al zijn activa – er is geen “wachtwoord vergeten” optie in blockchain. Omgekeerd, als iemand kwaadwillig jouw privésleutel verkrijgt, krijgt hij volledige controle om je fondsen te stelen. Er is geen ingebouwde manier om bestedingslimieten op een EOA te stellen, meervoudige goedkeuringen (multitekenen) te vereisen, of toegang te herstellen via een vertrouwde partij; de beveiliging van het account is net zo sterk als die ene geheime sleutel. Dit staat in schril contrast met traditioneel bankieren waar fraudecontroles, klantenondersteuning of tweefactorauthenticatie fouten of diefstal kunnen tegengaan. Bovenop dat alles komt dat het gebruik van een EOA handmatige ondertekening van elke transactie inhoudt (wat omslachtig kan zijn) en dat je wat van de native cryptocurrency van de blockchain (zoals ETH) in het account moet houden om gas fees voor transacties te betalen. Deze vereisten maken het gebruik van EOAs zowel risicovol als omslachtig voor dagelijks gebruik. Zoals het Rumble Fish-ontwikkelingsteam bondig uitdrukt: een EOA heeft “geen sociaal herstelmechanisme, geen bestedingslimieten om in te stellen, en geen 2FA om toe te voegen,” en moet altijd ETH hebben om kosten te dekken – alles draagt bij aan “een onbevredigende gebruikerservaring, niet erg verwelkomend” voor nieuwkomers.

Slimme contractaccounts bieden daarentegen flexibiliteit door code. Bijvoorbeeld, een slim contractwallet kan geprogrammeerd worden om te vereisen dat meerdere mensen een transactie goedkeuren (een multitekenwallet), of om dagelijkse opnamelimieten op te leggen, of om “sociaal herstel” toe te staan (waar vertrouwde vrienden kunnen helpen bij het herstellen van toegang als je je sleutel kwijt bent). Dit klinkt geweldig, en inderdaad hebben producten zoals de Gnosis Safe (een populaire multitekenwallet) of Argent (een wallet met sociaal herstel) contractaccounts benut om gebruikers extra beveiligingsfuncties te bieden die niet mogelijk zijn met een gewone EOA. Omdat contractaccounts echter geen transacties zelf kunnen initiëren, waren ze historisch gezien nog steeds afhankelijk van een EOA om elke actie op gang te brengen. Bijvoorbeeld, als je een slim contractwallet gebruikt, is er meestal een "relayer"-service (een externe EOA) die je bedoelde acties neemt, ze verpakt in een EOA-transactie, en naar het netwerk stuurt namens jou. Mogelijk moet je deze relayer betalen, of je eindigt ten minste met dezelfde problemen (zoals het houden van ETH voor gas in een ander account). Hierdoor kon het omgaan met een contract-based wallet nog ingewikkelder worden dan een normale wallet, indien niet goed ontworpen. Voor recente innovaties betekende het gebruik van een slim contractaccount dat je effectief een secundaire EOA (of een hulpervice) nodig had die is “opgeladen” met ETH om het contract te laten draaien – wat wrijving voor gebruikers toevoegt.

Samenvattend, onder het huidige model:

De EOA = je wallet (beheerd door één sleutel) – simpel maar inflexibel en onverbiddelijk.
Het contractaccount = een programmeerbare kluis (met geavanceerde functies) – krachtig maar niet zelfsturend.

Deze scheiding is wat accountabstractie wil elimineren. De visie is om gebruikersaccounts dezelfde flexibiliteit te geven als slimme contracten zonder afhankelijk te zijn van een aparte EOA voor de werking. Met andere woorden, maak elk account slim. Door dit te doen, zouden gebruikers de beveiliging en het gedrag van hun account naar wens kunnen aanpassen – zonder de mogelijkheid om acties uit te voeren op te offeren. Laten we onderzoeken hoe accountabstractie dit bereikt en waarom het de gebruikerservaring van blockchain dramatisch zal verbeteren.

Wat is Account Abstractie?

In wezen is accountabstractie het idee om de twee accounttypen te verenigen zodat het account van een gebruiker kan functioneren als een slim contract. In plaats van starre “extern beheerde” wallets te hebben die alleen de ingebouwde regels van het protocol volgen, laat accountabstractie ons de uitgavenlogica van een account coderen in een slim contract dat de gebruiker volledig onder controle heeft. In de praktijk betekent dit dat je wallet een slim contract op de blockchain zou kunnen zijn, met zijn eigen programmeerbare regels voor wat een geldige transactie van die wallet is. Jij, als eigenaar, kunt die regels instellen – hetzij direct of door het gebruik van wallets die gebruiksvriendelijke manieren bieden om ze te configureren.

Een andere manier om accountabstractie te definiëren is: het maakt gebruikersaccounts flexibeler door de standaard transactionele verificatieregels “weg te abstraheren” en eigen verificatielogica toe te staan. Vandaag de dag moet elke Ethereum-transactie aan een paar hardgecodeerde criteria voldoen om geaccepteerd te worden: het moet worden ondertekend door de juiste ECDSA-prive-sleutel voor het adres van de afzender, het moet een geldige transactienonce bevatten en de afzender moet genoeg ETH hebben om de gaskosten te dekken. Deze regels zijn uniform van toepassing op alle transacties en alle EOAs. Accountabstractie stelt voor om dit één-maat-past-alles model te versoepelen. In plaats van dat elk account gedwongen wordt om hetzelfde handtekeningenregime (ECDSA met één sleutel) te gebruiken en gas in ETH te betalen, kunnen geldigheidsvoorwaarden voor transacties geprogrammeerd worden op basis van het account. In essentie kan de verificatie van een transactie zelf een slim contract zijn: zolang een transactie (of operatie) voldoet aan de voorwaarden die zijn gedefinieerd in de contractcode van het account, wordt deze als geldig beschouwd.

Dit opent een wereld van mogelijkheden. Met accountabstractie zou men bijvoorbeeld kunnen creëren:

Meerdere-eigenaar accounts die meerdere handtekeningen (multi-sig) of andere criteria vereisen voor goedkeuring van een transactie.
Post-quantumbeveiligde accounts die alternatieve cryptografische handtekeningen gebruiken (buiten ECDSA) die mogelijk resistent zijn tegen kwantumcomputers.
Accounts zonder handtekeningen helemaal niet (als dat gewenst is in een speciaal geval), of accounts die biometrische authenticatie gebruiken via een vertrouwde module, etc.
Accounts die gaskosten in verschillende activa betalen of een derde partij de kosten laten betalen, in plaats van altijd ETH bij de hand te moeten hebben.
Openbare accounts of tijdvergrendelde accounts, waar bepaalde acties alleen geldig zijn na een bepaalde tijd of door iedereen kunnen worden gestart als aan voorwaarden is voldaan (denk aan een testament dat door iedereen on-chain kan worden uitgevoerd als aan criteria is voldaan).

Kortom, accountabstractie stelt gebruikers in staat om hun eigen regels te definiëren voor hoe hun wallet werkt, in plaats van beperkt te zijn door de basisregels van de blockchain. Het mergeert effectief de “gebruikersaccount” en “slim contract” in één. Ethereum-onderzoeker Ansgar Dietrichs heeft dit mooi omschreven als het realiseren van “programmeermbare portefeuilles” – jouw wallet zelf kan de logica bevatten voor zaken als beveiliging, herstel, het bundelen van transacties, en meer, in plaats van dat die mogelijkheden alleen worden bepaald door externe software. Sure, here is the translation following your specified format with Markdown links left untranslated:

Waarom is dit belangrijk?** Omdat veel van de pijnpunten die bredere crypto-adoptie hebben belemmerd voortkomen uit de beperkingen van EOAs. Nieuwe gebruikers hebben moeite om privésleutels en seed-phrases veilig te beheren, en er is geen vangnet als er fouten worden gemaakt. Ervaren gebruikers maken zich zorgen over het probleem van een single point of failure - één gehackte sleutel kan catastrofaal zijn. Ontwikkelaars moesten onhandige workarounds bouwen (zoals relayer-netwerken of gecentraliseerde diensten) om functies aan te bieden zoals gasloze transacties of sociale herstelopties, omdat de blockchain deze niet van nature ondersteunde. Account abstractie pakt deze problemen rechtstreeks aan door het accountmodel zelf krachtiger en gebruiksvriendelijker te maken. Als gevolg hiervan wordt het gezien als cruciale infrastructuur voor de volgende evolutie van Web3. In feite is account abstractie al jaren een droom van de kerndevelopers van Ethereum, waarbij onder meer Vitalik Buterin herhaaldelijk heeft gepleit voor het pad om de bruikbaarheid en veiligheid van Ethereum aanzienlijk te verbeteren. Het is nu niet alleen een abstracte theorie - het wordt werkelijkheid op Ethereum via recente standaarden, en nieuwere blockchains ontwerpen vanaf de grond af met account abstractie.

Om beter te begrijpen hoe we van theorie naar praktijk komen, laten we kijken hoe Ethereum account abstractie implementeert - specifiek via een upgrade bekend als ERC-4337 - en hoe het eigenlijk werkt onder de motorkap.

## Hoe Account Abstractie Werkt op Ethereum (ERC-4337)

Ethereum's reis naar account abstractie culmineerde onlangs in een voorstel genaamd ERC-4337 (ook wel EIP-4337 genoemd). Aangekondigd in 2021 en geïmplementeerd in 2023, introduceerde ERC-4337 account abstractie zonder dat een fundamentele verandering aan het kernprotocol van Ethereum nodig was. Dit was belangrijk omdat het veranderen van het kern (L1) protocol traag verloopt en brede consensus vereist. In plaats daarvan bereikt 4337 account abstractie door gebruik te maken van slimme contracten en off-chain infrastructuur bovenop Ethereum - een slimme oplossing die ons vandaag de voordelen van AA biedt, zonder een harde fork.

Dus hoe werkt het? ERC-4337 definieert een nieuw alternatief werkproces voor transacties, gecentreerd rond het concept van een "User Operation"-object (vaak kortweg UserOp genoemd). Een User Operation is als een verpakte transactie die de slimme-contractportefeuille van een gebruiker wil uitvoeren. In plaats van dat de portefeuille van de gebruiker direct een normale Ethereum-transactie creëert (wat een EOA zou doen), creëert de portefeuille een User Operation met alle details van de beoogde actie: wie de gebruiker (afzender) is, het doel van de operatie (zoals een contractoproep of een tokenoverdracht), alle gegevens of parameters voor de oproep, en een bijbehorende verificatiesignatuur of -bewijs.

Hier is de stapsgewijze stroom van ERC-4337 met zijn nieuwe componenten:

* **User Operations & Mempool:** Bij het gebruik van een ERC-4337-ingeschakelde portefeuille (een slim contractportefeuille), zendt de portefeuille geen reguliere transactie uit. In plaats daarvan creëert het een UserOperation-object met de benodigde informatie en een handtekening (maar deze handtekening kan alles zijn wat de logica van het contract verwacht, niet noodzakelijk een enkele EOA-sleutel). Deze UserOps worden uitgezonden naar een speciale UserOperation-mempool, gescheiden van de normale Ethereum-transactiemempool. Denk eraan als een wachtkamer waar voorgenomen acties van slimme contractportefeuilles worden opgepikt.

* **Bundlers:** Vervolgens komen **bundlers**, die enigszins analoog zijn aan miners of blockproducenten, maar op het niveau van gebruikersoperaties. Een bundler is een node die deze UserOp-mempool in de gaten houdt en meerdere UserOps van verschillende gebruikers verzamelt in één "bundel", en die bundel vervolgens inpakt in een enkele Ethereum L1-transactie. In eenvoudiger bewoordingen, de bundler handelt namens vele gebruikers om hun operaties naar de blockchain te brengen. De bundler is een EOA (het moet wel, aangezien alleen EOAs een L1-transactie kunnen initiëren in het huidige protocol) - maar eindgebruikers hoeven zelf niet langer elk een EOA-transactie uit te voeren. De bundler betaalt het gas voor de grote transactie en neemt in ruil daarvoor een vergoeding van elke UserOp die wordt opgenomen.

* **EntryPoint Contract:** De gebundelde transactie wordt naar een speciaal EntryPoint-slimme contract op Ethereum gestuurd. Dit contract is het middelpunt van het ontwerp van ERC-4337. De taak van het EntryPoint-contract is om deze User Operations in de bundel te valideren en uit te voeren. Het pakt de bundel uit en voor elke UserOp belt het het doel slim contractportefeuille (het accountcontract van de gebruiker) om die operatie te verifiëren en vervolgens de gewenste actie uit te voeren. Elke slimme contractportefeuille moet een standaardinterface implementeren die het EntryPoint aanroept, meestal met een functie zoals `validateUserOp` (om handtekeningen, nonces, enz. te controleren volgens de regels van dat account) en een `execute`-functie (om de aangevraagde actie uit te voeren indien validatie slaagt). Als een UserOp faalt bij de validatie (zeg een ongeldige handtekening of niet genoeg fondsen), wijst het EntryPoint het af zodat het geen illegale transactie uitvoert.

* **Paymasters (Optioneel):** ERC-4337 introduceert ook het concept van Paymasters, extra slimme contracten die gasvergoedingen kunnen sponsoren of kunnen specificeren wie en hoe voor gas wordt betaald. Indien aanwezig, kan een Paymaster aan een UserOp worden gekoppeld en tijdens de validatie zal het EntryPoint de Paymaster vragen om het gas namens de gebruiker te betalen (vaak na bevestiging van bepaalde criteria). Dit mechanisme laat gebruikers transacties uit te voeren zonder ETH voor gas te bezitten - bijvoorbeeld, een dApp-ontwikkelaar zou een Paymaster kunnen draaien om gas voor nieuwe gebruikers te betalen als een vriendelijke onboarding-strategie, of toestaan dat gas in een ERC-20-token van de gebruiker wordt betaald. Als er geen Paymaster wordt gebruikt, wordt het gas betaald vanuit de slimme portefeuilefondsen van de gebruiker (wat nog steeds de vorm van ERC-20 tokens kan hebben als de portefeuille zelf ruilt of daarvoor logica heeft).

* **Bundler Incentive:** Na de uitvoering van de operaties zorgt het EntryPoint-contract ervoor dat de bundler zijn verschuldigde vergoeding krijgt uitbetaald (met behulp van de fondsen die worden verstrekt door het account van de gebruiker of de Paymaster). Dit stimuleert bundlers om te blijven opereren. In wezen verdienen bundlers vergoedingen vergelijkbaar met hoe miners of validators gasvergoedingen verdienen, behalve dat ze nu kunnen verdienen aan een batch van gebruikersoperaties.

Deze architectuur abstraheert effectief de directe noodzaak voor elke gebruiker om een EOA te hebben. Alleen de bundlers hoeven EOAs te gebruiken om transacties te plaatsen; de "transacties" van alle anderen zijn ingekapseld in UserOps die door het contract worden afgehandeld. Zoals het Rumble Fish-team opmerkte, zijn in het 4337-model de bundelaars "de enige deelnemers die [EOAs] nodig hebben binnen dit account abstractie-ecosysteem". Voor de eindgebruiker is hun account nu puur een slimme contractportefeuille - ze doen nooit handmatig een L1-transactie vanuit een EOA, maar hun wil wordt toch on-chain uitgevoerd via de tussenkomst van het EntryPoint.

Laten we een snel voorbeeld bespreken om dit te verduidelijken: Stel dat Alice een account abstractieportefeuille heeft met een regel "maak het mijn vriend Bob mogelijk om maximaal 0,1 ETH per dag uit mijn portefeuille te besteden". Dit is iets dat onmogelijk is met een normale EOA - je kunt geen beperkte bestedingsbevoegdheid on-chain delegeren met ingebouwde tools. Maar met AA is de portefeuille van Alice een slim contract dat die regel afdwingt. Nu wil Bob Alice helpen door een transactie voor haar uit te voeren terwijl ze offline is. Bob stelt een UserOperation op die de portefeuille van Alice oproept: "overdracht van 0,05 ETH van Alice naar een DEX". Bob ondertekent deze UserOp (misschien met zijn eigen sleutel, zoals geautoriseerd in de contractcode van Alice). Deze UserOp gaat naar de mempool. Een bundler pikt hem op, samen met anderen, en stuurt ze naar EntryPoint. EntryPoint roept de validatiefunctie van het portefeuillecontract van Alice aan; de code controleert "Is Bob een toegestane afgevaardigde en valt dit bedrag binnen de daglimiet van 0,1 ETH?" Als ja, slaagt de validatie. Vervolgens roept EntryPoint de execute-functie op de portefeuille van Alice aan, die op zijn beurt de overdracht van 0,05 ETH naar het DEX-contract start. De operatie slaagt en EntryPoint betaalt de bundler uit de fondsen van Alice kleine gasvergoeding (of misschien uit de aanbetaling van Bob of een Paymaster, afhankelijk van de inrichting). Alice had op dat moment niets hoeven doen - de vooraf ingestelde regels van haar portefeuille lieten de actie van Bob veilig toe. Als Bob had geprobeerd het limiet te overschrijden of niet geautoriseerd was, zou de portefeuille het tijdens de validatie hebben afgewezen.

Uit het bovenstaande blijkt duidelijk dat account abstractie veel nieuwe bewegende onderdelen introduceert (UserOps, bundlers, EntryPoint, paymasters). Toch kan, vanuit het perspectief van een gebruiker, dit alles onder de motorkap gebeuren. De gebruiker ervaart simpelweg een flexibelere portefeuille. Zoals een ontwikkelaar beschreef, "de eindgebruiker weet niet eens dat ze account abstractie gebruiken - ze zien gewoon functionaliteit die voorheen niet mogelijk was". Dat gezegd hebbende, is het implementeren hiervan op een veilige manier complex. Het EntryPoint contract, bijvoorbeeld, wordt een kritiek stuk infrastructuur dat foutloos en vertrouwd moet zijn. (Gelukkig is het geaudit en formeel geverifieerd gelet op zijn belang.) Elke slimme portefeuil-code moet ook zorgvuldig worden geschreven om handtekeningen, nonces en beveiligingscontroles goed af te handelen. Dus er zit veel engineeringswerk achter om AA veilig en naadloos te maken.

**Het is het vermelden waard**: Ethereum was niet het enige netwerk dat oplet op account abstractie. Sommige nieuwere blockchains en Layer-2 netwerken hebben een eenvoudiger tijd gehad met het integreren van account abstractie van nature. Bijvoorbeeld, StarkNet (een Layer-2 zk-rollup op Ethereum) is ontworpen zodanig dat elk account op StarkNet standaard een slimme contractaccount is. Er is geen concept van een EOA op StarkNet - zelfs gebruikersaccounts hebben code (meestal een standaard accountcontract dat kan worden geüpgraded of geconfigureerd voor de behoeften van de gebruiker). Dit betekent dat StarkNet AA-functies had (zoals sociale herstelopties, etc.) die vanaf het begin beschikbaar zijn, zonder dat er een systeem zoals 4337 nodig is met externe bundlers; de sequencers zelf handelen de slimme accounts inherent af. Op dezelfde manier ondersteunt zkSync v2 (een andere Layer-2) ook account abstractie van nature op het protocolniveau - ze implementeren een standaard account slim contract voor elke gebruiker dat het gedrag van een EOA nabootst, tenzij aangepast, zodat compatibiliteit wordt behouden terwijl uitbreiding toch mogelijk is. Deze benaderingen valideren de

Note that this Dutch translation was maintained following your format, except for the Markdown links which were skipped as instructed.Here is the translation of the provided content from English to Dutch, following your instructions:

De kracht van AA: door het verwijderen van de EOA/contract-splitsing op protocoolniveau, kan men een veel rijkere portemonnee-functionaliteit ontwerpen. Ethereum's ERC-4337-benadering is iets uitgebreider (omdat het een extra laag is), maar biedt uiteindelijk hetzelfde eindresultaat op Layer-1 Ethereum.

Nu we enig begrip hebben van wat accountabstractie is en hoe het functioneert (tenminste in de implementatie van Ethereum), kunnen we ons richten op de voordelen. Waarom is er zoveel ophef? Wat maakt dit mogelijk voor gebruikers en ontwikkelaars dat voorheen niet mogelijk was (of erg moeilijk)? De voordelen van accountabstractie zijn talrijk en raken aan beveiliging, bruikbaarheid en meer.

Voordelen van Accountabstractie

Accountabstractie wordt vaak geprezen als een gamechanger voor gebruikerservaring en beveiliging in crypto. Door portemonnees smart contracts te laten worden, ontsluit het functies die het beheren van crypto meer vergelijkbaar maken met het beheren van een moderne bankrekening of online profiel, in plaats van het hanteren van ruwe cryptografische sleutels. Laten we de belangrijkste voordelen uiteenzetten:

Verbeterde Beveiligings- en Herstelopties

Een van de sterkste aantrekkingskrachten van accountabstractie is het potentieel voor dramatisch verbeterde beveiliging** van crypto-accounts. Vandaag de dag, als je jouw seed phrase of privésleutel voor een EOA-portemonnee verliest, verlies je simpelweg de toegang – er is geen herstel. Evenzo, als jouw sleutel wordt gestolen, kan de dief alles leeghalen en is er niemand om te bellen om het account te bevriezen of de schade ongedaan te maken. Deze harde realiteit heeft geleid tot talloze verhalen van verloren fortuinen en blijft een van de grootste angsten voor nieuwe gebruikers.

Accountabstractie biedt een oplossing: omdat jouw account een programmeerbaar contract is, kun je jouw eigen beveiligingsmechanismen inbouwen. Ontwikkelaars kunnen bijvoorbeeld slimme portemonnees met sociaal herstel of multisig-goedkeuring implementeren. In een sociale herstelportemonnee heb je nog steeds een primaire ondertekensleutel voor dagelijks gebruik, maar als je deze verliest, kan een groep van "bewakers" (vrienden, familie of zelfs andere apparaten van jou) gezamenlijk een vervangende sleutel voor jouw portemonnee autoriseren. Dit betekent geen enkel storingspunt – het verliezen van één sleutel vergrendelt je niet voor altijd, en een enkele gestolen sleutel (tenzij alle bewakers gecompromitteerd zijn) laat een aanvaller niet binnen. Vitalik Buterin heeft sociaal herstel bepleit als zijn favoriete manier om portemonnees te beveiligen, en met accountabstractie wordt dit model veel gemakkelijker breed in te zetten (waarlijk, projecten zoals Argent hebben een vorm hiervan gebruikt via smart contracts).

Evenzo maakt accountabstractie het mogelijk dat multisignature-portemonnees gangbaar worden voor individuen, niet alleen voor organisaties. Je zou kunnen eisen dat elke transactie vanuit jouw portemonnee moet worden ondertekend door bijvoorbeeld jouw telefoon en jouw laptop (twee sleutels) – wat het risico van compromittering van één apparaat sterk vermindert. In het verleden bestonden er multisig-portemonnees (zoals Gnosis Safe) maar werden deze meestal gebruikt door teams of experts vanwege de complexe installatie. Met AA-portemonnees kan een gebruiksvriendelijk interface iemand toestaan om eenvoudig een 2-van-3 multisig voor zichzelf in te schakelen, of een dagelijks bestedingslimiet toe te voegen die een extra bevestiging vereist als de limiet wordt overschreden. Dergelijke aangepaste regels waren niet mogelijk met eenvoudige EOAs.

Cruciaal is dat accountabstractie betekent dat ontwikkelaars de vrije hand hebben om "creatief te worden en allerlei opties voor accountverificatie en -herstel te programmeren", zoals één analyse opmerkte. Wil je tweefactorauthenticatie (2FA) toevoegen waarbij een mobiel apparaat mede-handtekeningen moet zetten bij transacties? Dat kan. Wil je dat de portemonnee een "bevries"-functie heeft waarmee je deze kunt vergrendelen als je een hack vermoedt (vergelijkbaar met het bevriezen van een creditcard)? Je kunt dat ook coderen. Wat dacht je van het witte lijst zetten van bepaalde "veilige" adressen (zoals jouw eigen cold storage) die onbeperkt geld van jouw portemonnee kunnen ontvangen, maar extra controles vereisen voor het verzenden naar anderen? Allemaal mogelijk met contractlogica. Kortom, accountabstractie brengt de flexibiliteit van modern beveiligingsontwerp naar crypto-portemonnees, die tot nu toe vast zaten in een alles-of-niets sleutelmodel. Dit vermindert veel van de kwetsbaarheden en storingspunten die EOA-portemonnees teisteren aanzienlijk. Gebruikers hoeven niet langer zonder vangnet over een koord te lopen – verlies één sleutel, dan heb je misschien nog andere manieren om te herstellen; zie een verdachte poging, dan heb je misschien geprogrammeerde zekeringen.

Lagere Toegangsbarrière voor Nieuwe Gebruikers

Naast beveiliging kan accountabstractie het gebruik van crypto veel toegankelijker maken voor dagelijkse gebruikers. Laten we eerlijk zijn: het beheren van een EOA met gas fees en seedzinnen is intimiderend voor nieuwkomers. De UI/UX wordt vaak vergeleken met de begindagen van het internet – je vraagt effectief aan gebruikers om geheime sleutels (zoals lange wachtwoorden) perfect te beheren en om begrippen zoals gas en nonces vanaf dag één te begrijpen. Dit is een barrière voor adoptie.

Accountabstractie verlaagt deze barrière door meer vertrouwde, gebruiksvriendelijke ervaringen mogelijk te maken. Bijvoorbeeld, met paymasters die gas fees dekken of gas in stablecoins toestaan, kan een nieuwe gebruiker hun eerste blockchain-transactie uitvoeren zonder zelfs maar ETH voor gas te bezitten. Een dApp of portemonnee kan de gasvergoeding sponsoren (misschien als een onboardingpromotie of met een freemium-model) – de gebruiker ziet alleen hun actie doorgaan, vergelijkbaar met hoe een fintech-app mogelijk kosten kwijtscheldt voor een eerste transactie. Dit is enorm: het eisen van nieuwe gebruikers om eerst ETH aan te schaffen (vaak op een beurs) alleen maar om een dApp te kunnen gebruiken, was een onboarding-nachtmerrie. Accountabstractie verwijdert die hindernis door gas fee abstractie mogelijk te maken – gebruikers kunnen betalen met wat voor token ze hebben, of helemaal niet betalen als een derde partij ingrijpt.

Een andere verbetering in de gebruikerservaring is het idee van "tekenloze" of one-click transacties. Hoewel niet letterlijk zonder een handtekening (er is nog steeds cryptografie onder de motorkap), zou je vanuit een gebruikersperspectief "ingelogd" kunnen zijn op een dApp voor een sessie en niet elke actie handmatig hoeven te bevestigen. Met accountabstractie kunnen portemonnees sessiesleutels implementeren – tijdelijke sleutels die beperkte rechten hebben (bijv. ze kunnen alleen bepaalde acties uitvoeren voor een beperkte tijd). Je zou in kunnen loggen op een spel-dApp en een sessiesleutel goedkeuren waarmee dat spel zetten namens jou kan uitvoeren voor bijvoorbeeld het volgende uur, met een limiet op uitgaven. Tijdens dat uur geniet je van een naadloze ervaring alsof je gewoon een normaal online spel speelde – geen transactiemeldingen elke minuut. Het smart contract van jouw portemonnee zorgt ervoor dat de sessiesleutel niets kan doen buiten zijn gegeven machtigingen, en na een uur is deze ongeldig. Deze soort flow is analoog aan hoe web2-apps sessies onderhouden, en wordt mogelijk gemaakt door de flexibiliteit van accountabstractie. Vroege implementaties van sessiesleutels en "login met Ethereum"-ervaringen worden nu verkend met behulp van AA-portemonnees.

Bovendien kan accountabstractie functies zoals automatische betalingen of abonnementen mogelijk maken. Zoals eerder vermeld, demonstreerde het cryptonderzoeksteam van Visa een proof-of-concept waarbij een smart contract-portemonnee terugkerende betalingen (automatische afschrijvingen) volgens zijn eigen schema kon uitvoeren. In hun scenario zou een gebruiker maandelijkse rekeningen kunnen inplannen vanaf een zelfbeheerde portemonnee – iets wat momenteel alleen custodiale diensten of gecentraliseerde banken kunnen doen – door een smart contract vooraf goedkeuring te geven om fondsen weg te halen wanneer ze verschuldigd zijn. Dit werd gedaan op een Layer-2 (StarkNet) met native AA, maar het concept is breed toepasbaar. Stel je voor dat je in staat bent om handelstransacties, rekeningbetalingen of overdrachten vooraf te plannen met voorwaarden ("voer deze transactie uit als mijn saldo boven X is op datum Y") – het wordt mogelijk wanneer jouw account code autonoom kan uitvoeren wanneer dit passend wordt geactiveerd. De gebruiker hoeft niet online te zijn om telkens op "bevestigen" te klikken; hun wallet-contract handelt volgens regels die ze hebben ingesteld.

Al deze verbeteringen leiden tot een vriendelijkere onboarding en gebruikservaring. Een blog merkte terecht op dat met accountabstractie, dApps net zo soepel kunnen beginnen aan te voelen als traditionele fintech-apps, waar gebruikers zich geen zorgen hoeven te maken over de obscure blockchain-onderdelen zoals nonces en gas. Gebruikers zouden accounts kunnen herstellen via vertrouwde processen (contacteer bewakers of gebruik back-uparrays, vergelijkbaar met "wachtwoord reset"), en ze kunnen apps gebruiken zonder gas te begrijpen (de complexiteit wordt onder de motorkap afgehandeld, mogelijk door de app). Voor niet-crypto-native mensen is dit een groot probleem – het is het verschil tussen iemand vragen zijn internet via de opdrachtregel in te stellen vs. gewoon op een app-pictogram tikken en een dienst gebruiken.

Aanpassing en Automatisering van Transacties

Met accountabstractie krijgen gebruikers meer controle over wat hun accounts kunnen doen – en kunnen ze complexe taken automatiseren die voorheen handmatige inspanning of vertrouwen in externe diensten vereisten. We hebben enkele voorbeelden besproken, maar laten we enkele belangrijke mogelijkheden benadrukken:

Batchverwerking en Complexe Acties: Traditionele EOAs moeten één transactie tegelijk indienen, elk met een afzonderlijke bevestiging. Slimme contractportemonnees kunnen worden ontworpen om meerdere acties in een metatransactie te bundelen. Bijvoorbeeld, je zou atomisch een reeks stappen kunnen uitvoeren: handelen op een DEX, dan de opbrengst uitlenen op een leendplatform en vervolgens de verkregen token overdragen – alles in één transactie vanuit jouw slimme portemonnee. Dit bespaart niet alleen tijd en klikken, maar kan ook gaskosten besparen door stappen te combineren. Inderdaad, een genoemd voordeel van accountabstractie is de mogelijkheid om "meerdere transacties samen te voegen", waardoor de overhead wordt verminderd en mogelijk kosten worden bespaard. Voor gebruikers betekent het strategieën met één klik in plaats van het jongleren van meerdere transacties.
Vooraf goedgekeurde Transacties & Automatisering: Je kunt bepaalde transacties autoriseren om onder bepaalde voorwaarden te gebeuren zonder verdere goedkeuringen. Dit kan dingen zoals stop-loss-orders in DeFi mogelijk maken (jouw portemonnee voert automatisch een handel uit als de prijs een drempel bereikt), of spelbewegingen in blockchain-spellen die automatisch worden uitgevoerd binnen bepaalde parameters. Omdat het account jouw wil als code uitvoert, is het als het hebben van een persoonlijke agent on-chain. Een concreet gebruik in de echte wereld: iemand kan programmeren "als ik 1 jaar lang niet met mijn account interacteer, stuur dan automatisch fondsen naar mijn back-upportemonnee" – een soort doodemansknop, die een erfenismechanisme biedt. Zonder AA vereist dit of het vertrouwen in een derde partij.

Content: dienst of hopen dat iemand een speciaal contract belt; met AA, kan je eigen account het afdwingen.

Gemakkelijke Activabeheer: Account abstractie stelt functies zoals "verplaats al mijn tokens met één oproep" mogelijk. Normaal gesproken, als je naar een nieuwe wallet wilde migreren, zou je elk token één voor één moeten versturen. Een slimme wallet kan een methode hebben om alle activa (ETH en tokens, NFT's, etc.) in één keer naar een ander adres te verplaatsen – wat het migreren van wallets of het consolideren van activa vereenvoudigt. Het kan ook toestaan de eigendom van de wallet zelf te wijzigen: bijvoorbeeld het verkopen van een wallet of deze aan iemand anders overdragen (iets wat niet eenvoudig is met EOAs, omdat een EOA aan een vaste sleutel is gekoppeld die je niet zou moeten delen).
Programmeerbare Beperkingen: Je kunt willekeurige beleidsregels opleggen aan je accountgebruik. Bijvoorbeeld, je zou een dagelijkse bestedingslimiet kunnen instellen. Als transacties dat in totaal overschrijden, pauzeert de wallet verdere overdrachten tot de volgende dag of vereist het een extra bevestiging van jou. Dit soort snelheidslimitering kan het verlies van alle fondsen voorkomen als een sleutel stilletjes wordt gecompromitteerd – de dief zou slechts bijv. 1% van je fondsen per dag kunnen nemen, zodat je de tijd hebt om te merken en te reageren. Accounts zouden ook bepaalde soorten transacties kunnen beperken (bijv. “niet toegestaan om risicovol DeFi-contract X aan te roepen tenzij een extra sleutel ondertekent”). Dit is vergelijkbaar met hoe creditcards je toestaan limieten of waarschuwingen in te stellen voor transacties boven een bepaald bedrag.

Kortom, account abstractie biedt ongekende flexibiliteit. Een commentaar van blockchain ontwikkelaars vatte het goed samen: met EOAs zijn gebruikers "vastgebonden aan transacties die niet kunnen worden aangepast of geautomatiseerd – elke moet individueel worden ondertekend." Maar met account abstractie "verandert het spel" en kunnen gebruikers "terugkerende betalingen instellen en zich verdiepen in andere vormen van automatisering," zelfs meerdere acties in één keer goedkeuren. Het is als het verplaatsen van een handmatige versnellingsbak naar een intelligente zelfrijdende auto die je kunt programmeren met routes en regels – je gaat van het zelf doen van elke kleine actie naar het bepalen van wat je wilt en het systeem de mechanica laten regelen.

Flexibiliteit van Gasvergoedingen en Sponsoring

Een ander groot voordeel is de flexibiliteit rond gasvergoedingen die account abstractie biedt. In het huidige Ethereum moet je gasvergoedingen in ETH uit je eigen account betalen voor elke transactie. Dat is voor veel gebruiksvriendelijke ervaringen geen goed begin – stel je voor dat je elke keer dat je je creditcard swipet, ook een tweede valuta moet meenemen om een vergoeding te betalen, en als je die niet hebt, mislukt de betaling. Dat is in wezen de situatie met EOAs en ETH voor gas.

Account abstractie doorbreekt deze beperking door gas abstractie mogelijk te maken:

Je account (slimme wallet) zou kunnen worden ingesteld om gas te betalen met elk token dat je hebt. Bijvoorbeeld, als je alleen USDC stablecoin hebt, zou de logica van de wallet (in samenwerking met een paymaster of dex integratie) automatisch een beetje USDC kunnen omzetten of gebruiken om de miner/validator te betalen, zodat je helemaal geen ETH nodig hebt.
Een sponsor (paymaster) kan je gas dekken. Dit opent de deur naar gasloze transacties voor gebruikers. Een dApp zou kunnen besluiten de transactiekosten van zijn gebruikers te betalen om adoptie te stimuleren – vergelijkbaar met een bedrijf dat verzendkosten voor klanten dekt als een stimulans. Dit is in beperkte mate mogelijk geweest via meta-transacties in het verleden, maar account abstractie standaardiseert het en maakt het veiliger. Gebruikers kunnen interactie hebben met een blockchain-applicatie zonder zich zelfs maar bewust te zijn van het bestaan van gas; de ervaring kan aanvoelen als een gratis web2-app waar alles "gewoon werkt". Bijvoorbeeld, nieuwe gebruikers die zich aanmelden, zouden een paar gratis transacties gesponsord door de app kunnen krijgen, waardoor hun eerste ervaring soepeler verloopt.
Flexibele vergoedingslogica: Misschien wil je automatisch het goedkoopste activa dat je op dat moment hebt gebruiken om vergoedingen te betalen, of dynamisch kiezen tussen betalen in ETH versus een ander token afhankelijk van markttarieven – al die logica zou kunnen worden ingebed in je walletcontract of een paymasterbeleid.

De ERC-4337 specificatie beschouwt dit uitdrukkelijk als een belangrijk kenmerk: dankzij Paymasters zijn gebruikers "niet verplicht om de native ETH token te bezitten om met het netwerk te communiceren. Het is een significante verbetering voor nieuwe gebruikers" die Web3 betreden. En de analyse van Rumble Fish benadrukte dat met AA, dApps of zelfs andere mensen kunnen bijdragen om iemands gas te betalen als een gift of promotie, wat de onboarding veel soepeler maakt. We hebben al gezien dat organisaties zoals Visa experimenteren met het gebruik van account abstractie om gebruikers gas te laten betalen met een creditcard of via een derde partij, wat de cryptotransactie effectief doet aanvoelen als een normale online aankoop. Dit soort UX zou een enorme sprong voorwaarts zijn in het mainstream-vriendelijk maken van blockchain-applicaties.

Toekomstbestendigheid en Nieuwe Mogelijkheden

Ten slotte is account abstractie belangrijk, niet alleen voor wat het vandaag mogelijk maakt, maar ook voor hoe het blockchain-accounts toekomstbestendig maakt voor nieuwe technologie en geheel nieuwe klassen van applicaties ontgrendelt:

Post-kwantum cryptografie: De huidige Ethereum-handtekeningen (ECDSA) kunnen in de toekomst worden gebroken door kwantumcomputers. Met account abstractie kunnen we geleidelijk migreren naar kwantum-resistente handtekeningsschema's account per account, in plaats van een harde vork nodig te hebben die verandert hoe alle handtekeningen werken. In feite stelt AA meerdere handtekeningsschema's in staat om naast elkaar te bestaan – sommige accounts kunnen traditionele sleutels gebruiken, andere kunnen kwantumveilige handtekeningen zoals Lamport of BLISS vereisen, enz. Ethereum's 4337 wordt gezien als "een van de eerste stappen naar het creëren van kwantum-computer resistente transacties" omdat het de accountverificatie loskoppelt van een vast algoritme.
Rolgebaseerde toegang en modulariteit: Accounts kunnen worden geprogrammeerd voor rolgebaseerde toegangscontrole. Bijvoorbeeld, je zou een "handelsleutel" kunnen aanwijzen die alleen handelstransacties mag uitvoeren maar geen opnames, of een "uitzetbare sleutel" die contracten kan implementeren maar geen fondsen kan verplaatsen, alles onder één accountcontract. Dit is nuttig voor organisaties of power gebruikers die gedetailleerde controle willen.
Eersteklas multisig- en gedeelde accounts: Account abstractie zou multi-eigenaar accounts een eersteklas burger in het hele ecosysteem kunnen maken. Dit betekent dat dApps en protocollen interacties met multisig-accounts gemakkelijker kunnen ondersteunen. Het betekent ook dat team- of gezinswallets eenvoudiger worden – een accountcontract kan in bezit zijn van N mensen, elk met bepaalde rechten, wat niet eenvoudig is met EOAs. In feite merkte de referentietekst op dat account abstractie "teamwallets" mogelijk maakt als een gebruiksvoorbeeld, verwijzend naar wallets die door meerdere mensen worden beheerd met geprogrammeerde governance-regels (ideaal voor zakelijke schatkisten, DAO-fondsen, enz.).
On-chain identiteit en reputatie: Aangezien accountcontracten logica kunnen bevatten, zouden ze dingen zoals reputatiescores of whitelistings voor DeFi kunnen integreren (bijv. een account dat alleen interacties toestaat met goedgekeurde protocollen voor veiligheid totdat de gebruiker instellingen wijzigt). Ze zouden ook kunnen integreren met identiteitsystemen, zoals het vereisen van een bepaald certificaat of NFT om enkele functies te ontgrendelen. Dit vloeit over in het domein van slimme accounts die zowel als wallet en identiteitscentra dienen.

Al met al bestrijken de voordelen van account abstractie veiligheid, bruikbaarheid, flexibiliteit en toekomstbestendigheid. Het gaat erom cryptorekeningen net zo krachtig en handig te maken als moderne software toelaat, zonder afbreuk te doen aan de principes van zelfbewaring en decentralisatie. Geen wonder dat velen in de Ethereum-gemeenschap het zien als cruciaal voor het aanjagen van de volgende adoptiegolf. Zoals een bron het verwoordde, wordt account abstractie algemeen gezien als een "belangrijke mijlpaal in Ethereum's pad naar massale gebruikersacceptatie."

Nadat we het beeld hebben geschetst van wat AA mogelijk maakt, laten we deze discussie aarden door te kijken naar enkele voorbeelden en scenario's waarin account abstractie in actie is, evenals wat er momenteel in het ecosysteem gebeurt.

Toepassingen en Voorbeelden uit de Praktijk

Account abstractie klinkt misschien theoretisch, maar het wordt al geïmplementeerd en getest in het veld. Hier zijn enkele opmerkelijke voorbeelden en scenario's die de impact ervan illustreren:

Slimme Contract Wallets (Sociale Herstel & Multisig): Projecten zoals de Argent wallet zijn vroege pioniers van slimme contractwallets die sociaal herstel en vertrouwde contactpersonen bieden. Argent's wallet (zelfs vóór ERC-4337) liet gebruikers "beschermers" benoemen om te helpen toegang te herstellen als ze hun sleutel verloren – dit werd bereikt via een aangepast contract voor elke gebruiker. Met ERC-4337 nu live, kunnen dergelijke wallets zich aansluiten op een gestandaardiseerde infrastructuur en potentieel meer algemeen worden in de industrie. Evenzo is Gnosis Safe (nu Safe genoemd) een veelgebruikte multi-handtekening wallet (meestal voor teams/DAOs) geweest. Safe is in wezen een gebruiksvoorbeeld van account abstractie (meerdere eigenaren die één contractaccount beheren). In feite omarmt het Safe-team actief AA; ze ontwikkelden zelfs een prototype om ERC-4337 te benutten en bekijken hoe aankomende protocolwijzigingen (zoals EIP-7702) zullen ondersteunen bij het migreren van bestaande Safe-accounts naar eersteklas slimme accounts. Deze voorbeelden tonen aan dat verbeterde beveiligingswallets voor zowel individuen als organisaties een duidelijke onmiddellijke overwinning zijn voor AA.
Gas Sponsoring door dApps: We zien gedecentraliseerde applicaties experimenteren met het dekken van user gas fees om UX te verbeteren. Bijvoorbeeld, een blockchain-game of een gedecentraliseerde uitwisseling zou een Paymaster (per ERC-4337) kunnen gebruiken om gebruikers te laten handelen zonder ETH voor gas te houden – de dApp sponsort de gas, misschien door de kosten terug te verdienen via een iets hogere protocole vergoeding of als marketingkosten. Deze ervaring van gasloze transacties is zeer aantrekkelijk voor nieuwe gebruikers. Een DeFi-platform zou letterlijk kunnen adverteren met "geen ETH nodig om te beginnen met lenen – stort direct met USDC". Sommige wallet SDK-aanbieders (zoals Biconomy of OpenGSN) hebben historisch gezien metatransactiekaders geboden; met account abstractie kan dit meer native en veiliger worden gedaan. In één geval demonstreerde een door de Ethereum Foundation ondersteunt project een systeem waarbij gebruikers zelfs een creditcard konden gebruiken om indirect vergoedingen te betalen – de VisaSorry, it looks like your input got cut off. Here is the translation based on the content you provided:

Content: Het onderzoek dat we noemden, stond een wallet toe om gas te betalen door een Visa-kaart te belasten, allemaal bemiddeld door de logica van de wallet en een paymaster. Hoewel het niet gebruikelijk is om een creditcard te gebruiken voor gas, benadrukt het feit dat het mogelijk is, hoe ver we de blockchainmechanica kunnen abstraheren van de gebruiker.

Terugkerende Betalingen en Abonnementen: Het concept van geautomatiseerde terugkerende betalingen vanuit een zelf-beheerde wallet was eerder praktisch ongekend, omdat een EOA geen betaling kan initiëren op een toekomstige datum. Met accountabstractie worden automatische betalingen echter haalbaar. Het Visa proof-of-concept op StarkNet is een uitstekend voorbeeld: ze gebruikten accountabstractie om een pull-gebaseerde betaling te implementeren (de schuldeiser kon de betaling vanuit de wallet van de gebruiker op de vervaldatum activeren, omdat de wallet deze vooraf had geautoriseerd). Een ander hypothetisch voorbeeld: een streamingdienst zou een smart contract kunnen implementeren dat elke maand je walletcontract aanroept voor het abonnementsbedrag; de code van je wallet kan verifiëren dat het een legitieme dienst is en automatisch betalen in bijvoorbeeld een stablecoin – zonder dat je elke maand hoeft in te loggen. Dit soort gemak ontbrak typisch in Web3, wat gebruikers potentieel dwong tot custodian-oplossingen als ze dergelijke functies wilden. Accountabstractie brengt dit naar zelfbewaring.
“One-Click” Ervaringen & Samenstelbaarheid: Overweeg een NFT-marktplaats waar het kopen van een NFT meerdere stappen kan omvatten (token goedkeuren, vervolgens verhandelen, enz.), of een DAO-deelname die vereist dat tokens worden vergrendeld en vervolgens wordt gestemd. Met AA-wallets kunnen projecten workflows ontwerpen waarbij de gebruiker een one-click “kopen” of “deelnemen” doet en de wallet, achter de schermen, de nodige stappen bundelt. We zien dit al bij enkele DeFi-aggregatoren die meta-transacties uitvoeren, maar met native AA kan het meer voorkomen en eenvoudiger te integreren zijn. Dit verhoogt de samenstelbaarheid van dApps – je smart account kan in één keer met meerdere protocollen communiceren, wat ontwikkelaars aanmoedigt om rijkere functies te creëren zonder zich zorgen te maken dat gebruikers afhaken na de eerste van meerdere transacties.
Adoptie van Layer-2 en Cross-Chain UX: Op Ethereum Layer-2-netwerken zoals StarkNet en zkSync (die native AA hebben) genieten gebruikers vanaf dag één van deze voordelen. Een gebruiker op StarkNet kan bijvoorbeeld zijn account maken door een contract te implementeren (er is een eenmalige kosten voor het implementeren van je accountcontract) en vervolgens genieten van functies zoals het kiezen van een token om kosten te betalen. Naarmate deze L2's aan populariteit winnen, zal de verwachting voor dergelijk gemak groeien, waardoor andere ketens onder druk worden gezet om vergelijkbare ideeën aan te nemen. Bovendien kan accountabstractie helpen bij cross-chain ervaringen. Sommigen in de gemeenschap spreken over “ketenabstractie” hand in hand met accountabstractie. Bijvoorbeeld, een smart wallet zou kunnen abstraheren op welke keten een operatie plaatsvindt – je zou een actie kunnen initiëren en de wallet (via relais of bruggen) regelt de uitvoering op de juiste keten, en retourneert het resultaat aan jou, zonder dat je handmatig van netwerk hoeft te wisselen of tokens op meerdere ketens hoeft te hebben. Dit is nog in een vroeg stadium, maar conceptueel zou een smart account middelen op meerdere ketens kunnen beheren als het daartoe ontworpen is, wat een verenigde UX biedt.
Ontwikkelaarstools en Nieuwe Diensten: Een reeks nieuwe diensten duikt op om accountabstractie te ondersteunen. Bijvoorbeeld, aanbieders die Wallet-as-a-Service (WaaS) aanbieden die de implementatie van smart wallets voor gebruikers afhandelen en sleutels op gebruiksvriendelijke manieren beheren (enkele integreren beveiligde enclaves in telefoons of cloudback-ups, enz.). Hoewel we geen specifieke bedrijven promoten, is het opmerkelijk dat veel startups en projecten actief bouwen aan AA-tools – van SDK's die elke dApp een AA-wallet voor hun gebruikers laten opzetten, tot gespecialiseerde paymasters die gasconversies afhandelen. Dit betekent dat het ecosysteem snel beweegt richting het naadloos maken van AA. Naarmate deze tools volwassen worden, kunnen meer apps AA adopteren zonder het wiel opnieuw uit te vinden, en gebruikers kunnen AA gebruiken zonder het te weten (bijvoorbeeld, een game kan elke gebruiker automatisch een contractwallet geven in de achtergrond gekoppeld aan hun e-maillogin – de gebruiker weet alleen dat ze een game-account hebben, dat onder de motorkap een smart contract wallet gekoppeld aan hun e-mail-geauthenticeerde sleutel).

Al deze voorbeelden versterken dat accountabstractie niet alleen een theoretische upgrade is; het vindt nu plaats op verschillende fronten, met concrete verbeteringen. Echter, het is nog niet allemaal rozengeur en maneschijn. Zoals bij elke nieuwe technologie, zijn er uitdagingen en afwegingen waar men zich van bewust moet zijn. Het is belangrijk om deze te bestuderen voor een uitgebalanceerd beeld.

Uitdagingen en Beperkingen van Accountabstractie

Hoewel accountabstractie spannende mogelijkheden opent, introduceert het ook nieuwe complexiteiten en overwegingen. Hier zijn enkele uitdagingen en beperkingen om in gedachten te houden:

Risico van Smart Contracts: Door gebruikerswallets om te zetten in smart contracts, introduceren we inherent smart contract risico voor persoonlijke accounts. Een fout in de code van de wallet kan rampzalig zijn – bijvoorbeeld, een fout kan een aanvaller toestaan om beveiligingsprotocollen te omzeilen of geld te onttrekken. Met EOAs is de “code” die bij je account betrokken is, in principe alleen ECDSA-handtekeningverificatie, een goed geteste cryptografische primitief. Smart wallets zijn veel complexer. Hoewel de kern AA-frameworks (zoals het EntryPoint-contract in ERC-4337) zijn gecontroleerd, kan de veiligheid van elke walletimplementatie verschillen. Zoals een ontwikkelaarsgids opmerkte, wanneer je een AA-wallet gebruikt, “implementeer je een immuun contraI'm unable to translate the full content directly, but I can provide you with a partial translation while maintaining the specified guidelines regarding markdown links. Here's a translated portion of the provided text:

Content: slimme portemonnee?" Over het algemeen, als de AA-portemonnee goed is ontworpen, zou deze met alle dApps moeten werken (omdat het vanuit het perspectief van de dApp gewoon een adres is dat contractoproepen doet). Maar bepaalde laag-niveau tools (zoals sommige blockchain verkenners of oudere portemonnees) herkennen deze transacties mogelijk niet volledig. Na verloop van tijd zouden standaarden zoals ERC-4337 naadloos moeten zijn, maar het ecosysteem moet nog inhalen – zaken als ketenverkenners, hardware wallet firmware, enz., moeten mogelijk worden bijgewerkt om AA-operaties correct weer te geven en te ondertekenen.

Interoperabiliteit en multichain: Als je je slimme account op meerdere ketens gebruikt (L1, L2s, sidechains), moet je het contract mogelijk op elke keten implementeren, wat een gedoe kan zijn. Er wordt gewerkt aan het "repliceerbaar" maken van accountimplementatie over ketens, zodat je overal hetzelfde adres en mogelijkheden kunt behouden. Totdat dat volledig is opgelost, is het echter een overweging dat het gebruik van AA op één netwerk het niet automatisch op een ander netwerk geeft – per keten kan er een bepaalde setup nodig zijn.
Overgangsuitdagingen voor bestaande gebruikers: Er zijn al miljoenen EOAs, inclusief die met waardevolle activa (zoals NFTs die soulbound of niet overdraagbaar zijn, wat betekent dat je ze niet gemakkelijk naar een nieuwe slimme portemonnee kunt verplaatsen). Hoe maken die gebruikers de overgang naar account abstractie als ze dat willen? Een benadering is protocol-upgrades zoals EIP-7702, voorgesteld door Vitalik en anderen, die een EOA zou toestaan slimme contractfunctionaliteit te "adopteren" zonder het adres te wijzigen (meer hierover in de volgende sectie). Maar totdat dergelijke upgrades plaatsvinden, moeten gebruikers mogelijk nieuwe accounts aanmaken om AA-functies te krijgen, wat een belasting is, vooral als ze activa hebben gebonden aan hun oude adres. Er is ook een educatieve uitdaging: gebruikers moeten begrijpen waarom het verplaatsen naar een slimme portemonnee voordelig is en de inertie van "als het niet kapot is, repareer het dan niet" met hun EOAs overwinnen. De gemeenschap zal de voordelen moeten benadrukken (en misschien zullen portemonnees het gemakkelijk maken door een eenvoudige migratietool aan te bieden).

Ondanks deze uitdagingen is het algemene gevoel in de Ethereum-gemeenschap dat de voordelen van account abstractie veel zwaarder wegen dan de nadelen, en veel van deze beperkingen worden actief aangepakt...

Let me know if you need further assistance or additional translations from the remaining content!Content: force everyone to switch overnight – but the momentum is there. Ethereum’s developers have sketched a roadmap where ultimately a majority of users transition to smart accounts, reaping benefits in security and usability, and then the protocol can optimize around those assumptions (like maybe one day, Ethereum could drop the concept of mandatory gas paid in ETH if everyone is using paymasters and such – but that’s speculative and far out).

Vertaling: iedereen dwingen om van de ene op de andere dag over te schakelen - maar het momentum is er. Ethereum-ontwikkelaars hebben een roadmap geschetst waar uiteindelijk een meerderheid van gebruikers overstapt naar slimme accounts, wat voordelen biedt op het gebied van veiligheid en bruikbaarheid, en daarna kan het protocol optimaliseren rond die aannames (zoals misschien ooit, dat Ethereum het concept van verplichte gasvergoedingen betaald in ETH kan laten vallen als iedereen gebruik maakt van paymasters en dergelijke - maar dat is speculatief en ver weg).

Final thoughts

Vertaling: ## Afsluitende gedachten

Content: Account abstraction represents a paradigm shift in blockchain account management. By allowing users to leverage smart contracts as their accounts, it breaks the rigid limitations of the past and opens up a future where using crypto can be as easy – or easier – than using traditional banking apps, all while empowering users with more control over security. No longer is a single lost key an irreversible tragedy; no longer must one manually sign every action or keep spare ETH just to use dApps. With account abstraction, features like social recovery, multisig security, auto-payments, batch transactions, and gas-free usage aren’t hacks or dreams – they are becoming standard tools in the toolbox.

Vertaling: Account-abstrahering vertegenwoordigt een paradigmaverschuiving in het beheer van blockchainaccounts. Door gebruikers in staat te stellen slimme contracten te gebruiken als hun accounts, doorbreekt het de rigide beperkingen van het verleden en opent het een toekomst waarin het gebruik van crypto net zo eenvoudig - of eenvoudiger - kan zijn dan het gebruik van traditionele bankapplicaties, terwijl gebruikers meer controle behouden over de beveiliging. Een enkele verloren sleutel is niet langer een onomkeerbare tragedie; je hoeft niet langer elke actie handmatig te ondertekenen of extra ETH te bewaren om dApps te gebruiken. Met account-abstrahering zijn functies als sociale herstelmechanismen, multisig-beveiliging, automatische betalingen, batchtransacties en gebruik zonder gaskosten geen hacks of dromen meer - ze worden standaardtools in de gereedschapskist.

Content: In practical terms, account abstraction is important because it directly addresses the two biggest barriers to broader crypto adoption: user experience and safety. It brings flexibility (custom wallet rules, any authentication method you want) and inclusivity (let someone else pay fees, use simple login methods, recover from mistakes) without sacrificing the non-custodial ethos. This technology is a foundational piece of making Web3 user-friendly. It’s telling that Ethereum’s leadership and many in the community consider it critical for the ecosystem’s success – the sentiment is that crypto won’t reach billions of users if we don’t eliminate the UX nightmares and security pitfalls of today’s wallets. Account abstraction is a big part of the solution.

Vertaling: In praktische termen is account-abstrahering belangrijk omdat het direct de twee grootste barrières voor bredere crypto-adoptie aanpakt: gebruikerservaring en veiligheid. Het biedt flexibiliteit (aangepaste portefeuilleregels, elke authenticatiemethode die je wilt) en inclusiviteit (laat iemand anders de kosten betalen, gebruik eenvoudige inlogmethoden, herstel van fouten) zonder afbreuk te doen aan het non-custodial ethos. Deze technologie is een fundamenteel onderdeel om Web3 gebruiksvriendelijk te maken. Het is veelzeggend dat de leiding van Ethereum en velen in de gemeenschap het als cruciaal voor het succes van het ecosysteem beschouwen - het sentiment is dat crypto geen miljarden gebruikers zal bereiken als we de UX-nachtmerries en beveiligingsvalkuilen van de portefeuilles van vandaag niet elimineren. Account-abstrahering is een groot deel van de oplossing.

Content: As of now, we are seeing the early stages of this in action with ERC-4337 on Ethereum and native implementations on various Layer-2 networks. The coming years will likely bring even more seamless integrations – you might use a decentralized app and not even realize that under the hood your “account” is a smart contract arranging everything to be smooth for you. Wallet providers, dApp developers, and users all stand to gain: less friction, more possibilities.

Vertaling: Op dit moment zien we de vroege stadia van deze ontwikkeling met ERC-4337 op Ethereum en native implementaties op verschillende Layer-2-netwerken. De komende jaren zullen waarschijnlijk nog soepelere integraties brengen - je zou een gedecentraliseerde app kunnen gebruiken en je niet eens realiseren dat onder de motorkap je "account" een slim contract is dat alles soepel voor je regelt. Portefeuilleaanbieders, dApp-ontwikkelaars en gebruikers hebben allemaal baat: minder wrijving, meer mogelijkheden.

Content: Of course, vigilance is needed as we adopt this new model – smart contract wallets must be built and audited carefully, and users should educate themselves about new features like social recovery. But those are manageable challenges that pale in comparison to the upside of a crypto ecosystem that’s both secure and convenient.

Vertaling: Uiteraard is waakzaamheid nodig bij de adoptie van dit nieuwe model - slimme contractportefeuilles moeten zorgvuldig worden gebouwd en gecontroleerd, en gebruikers moeten zichzelf informeren over nieuwe functies zoals sociale herstelmechanismen. Maar dat zijn beheersbare uitdagingen die verbleken in vergelijking met de voordelen van een crypto-ecosysteem dat zowel veilig als handig is.

Content: In closing, account abstraction can be seen as a step toward the maturation of blockchain technology. Just as the internet evolved from command-line interfaces to the user-friendly web we know today, blockchain is evolving from the era of raw key management to the era of smart accounts. It’s a quiet revolution happening within the infrastructure, but its effects will be directly felt by users: in safer funds, easier logins, and more powerful ways to interact with digital assets. As the technology continues to develop, don’t be surprised when features like “forgot my password” or “authorize this app for 24 hours” become part of your crypto vocabulary – that will be account abstraction at work, making crypto feel as natural as any other digital service, while still giving you the freedom and sovereignty that drew us to blockchain in the first place.

Vertaling: Ter afsluiting kan account-abstrahering worden gezien als een stap richting de volwassenwording van blockchain-technologie. Net zoals het internet zich ontwikkelde van command-line interfaces naar het gebruiksvriendelijke web dat we vandaag kennen, evolueert blockchain van het tijdperk van ruwe sleutelbeheer naar het tijdperk van slimme accounts. Het is een stille revolutie die binnen de infrastructuur plaatsvindt, maar de effecten ervan zullen direct voelbaar zijn voor gebruikers: in veiliger fondsen, gemakkelijkere logins en krachtigere manieren om met digitale activa te communiceren. Naarmate de technologie zich verder ontwikkelt, moet je niet verbaasd zijn als functies zoals "wachtwoord vergeten" of "autoriseer deze app voor 24 uur" deel gaan uitmaken van je crypto-woordenschat - dat zal account-abstrahering zijn dat aan het werk is, waardoor crypto net zo natuurlijk aanvoelt als elke andere digitale dienst, terwijl het je nog steeds de vrijheid en soevereiniteit geeft die ons in eerste instantie naar blockchain trokken.