Let’s start with the first term; Account.
A door serves as a point of access to a building, and a key is used to access doors. Users enter buildings through doors, using keys.
Blockchain users have accounts, and sign transactions using a pair of keys. Users interact with their accounts (send, receive and store tokens) using wallets.
Account abstraction is a new standard for development in the ethereum blockchain where assets are held by smart contracts exclusively.
This presents a shift in how accounts function, which could transform user experience of decentralised applications. In other words, if doors are changed, then the way users unlock doors will also change. They may only need to swipe the doors or press a button, for example.
In the early days of the internet, few people knew about it. Interest and demand grew gradually then suddenly.
There is an anecdote from an early member of the google engineering team that narrates spikes in website traffic on tuesday afternoons, and the race to grow server capacity exponentially as site visits surged.
What does account abstraction have to do with all this ?
Security & Scale
Products built on decentralized systems and protocols have mostly been a technology-led design, with an assumption that users will always follow the intended path. Passwords and private keys as means of user authentication are examples of this.
This system has been ineffective in its primary goals of granting users access to their accounts, or securing assets from bad actors, as billions of dollars in hacks and unrecoverable accounts have proven.
This has also been a crucial point of friction in widepsread adoption of products built on this technology.
There have been discussions on the best way to implement this on the Ethereum network, EIP 4337 being the latest.
What is different this time ? This implementation does not require a consensus layer update.
Why does it matter ?
Build it and users would come.
Improved user experience drives widespread adoption.
Users are not looking for new technology to scratch an itch.
In essence, EIP 4337 will simplify the experience of users by abstracting smart contracts and account interactions. This will preclude key pair signing, thereby enabling safe custody of assets by users.
If system design is built around user and developer interactions, then solutions can be better built for purpose and be inherently more secure.
+ +
Account abstraction enables smart contract functions to have pre-signature requirements, enhancing user experience and opening up additional possibilities, such as ;
signless transactions
whitelist smart contracts
co-owned wallets
bundle sign
Components
UserOperations are pseudo-transaction objects that are used to execute transactions with contract accounts. These are created by your app. These are initiated by the user, such as executing smart contracts or sending transactions.
Contract Accounts are smart contract accounts owned by a user.
Bundler
The bundler collects user operations from the mempool and bundles them into a single transaction.
Standard L1 Transaction: The bundler sends the transaction to the entry point contract as a standard L1 transaction.
Entry Point Contract
This contract receives the transaction , handles the verification, and executes the user operations.
With account abstraction, every account has its own logic and can initiate transactions and pay the fee (required to operate contract accounts), which opens up new possibilities for creating secure and user-friendly wallets.
Top comments (0)