The EVM-based blockchain account model is based on the concept of Externally Owned Accounts(EOAs) and Contract Accounts. The former is controlled by a private key and is responsible for initiating transactions while the latter represents smart contracts that execute code on the blockchain. Currently, contract accounts depend on EOAs for executing transactions, creating a security vulnerability. The account abstraction proposal completely avoids the need for consensus-layer protocol changes. Instead of adding new protocol features and changing the bottom-layer transaction type, this proposal instead introduces a higher-layer pseudo-transaction object called a UserOperation. Users send UserOperation objects into a separate mempool. A special class of actors called bundlers (either block builders, or users that can send transactions to block builders through a bundle marketplace) packages up a set of these objects into a transaction, making a handleOps call to a special contract (EntryPoint), and that transaction then gets included in a block.
Motivation
Account abstraction aims to abstract as many of the account properties as possible, including authentication, authorization, replay protection, gas payment, batching & atomicity, etc. All of these aspects are controlled by the EVM code rather than rigid consensus rules.
This proposal takes a different approach, avoiding any adjustments to the consensus layer. It seeks to achieve the following goals:
Achieve the key goal of account abstraction
allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs
Decentralization
Allow any bundler (think: block builder) to participate in the process of including account-abstracted user operations
Work with all activity happening over a public mempool; users do not need to know the direct communication addresses (eg. IP, onion) of any specific actors
Avoid trust assumptions on bundlers
Do not require any consensus changes
Consensus layer changes are harder to implement, require more comprehensive testing, and bear higher risk of deploying. Hence, to increase the chance of faster adoption, this proposal avoids consensus layer changes.
Try to support other use cases
Privacy-preserving applications
Atomic multi-operations
Pay tx fees with XRC20 tokens, allow developers to pay fees for their users, and sponsored transaction use cases more generally
Support aggregated signature (e.g. BLS, Secp256r1)
Please read this proposal carefully and offer your comments and suggestions, should you have any. We think this will be a significant improvement when it’s in place.
The essence of this proposal orSowhat?
When implemented, builders will be able to create dApps that offer a much simpler and safer user experience.
In brief, a better experience.
That, in turn, means a platform that can more easily onboard people who are later adopters. The result will be broader adoption of the IoTeX chain.
Think: driving a car with an automatic transmission vs. stick shifting and using the clutch pedal. Some people swear by the control and feel of a stick shift. The rest of us… “I just want to start the car, point it in the right direction, and go.” Most people fall into the two majority segments above.
For the lay person, that would be me, I like to have a high level understanding of the changes/benefits described. Account abstraction is clearly an important feature. It’s worth exploring this topic. What is Account Abstraction? | Stackup Docs
Some of the supported use cases for these changes are:
Privacy-preserving applications
Atomic multi-operations - That is, changing multi-step operations into a single step for people to perform. Simplification!
Pay tx fees with XRC20 tokens, allow developers to pay fees for their users, and sponsored transaction use cases more generally. When we see more developers taking care of the fees for transactions, people will appreciate how much less trouble it is to use a dApp. Amazon discovered this when they introduced free shipping in 2002.
Support aggregated signature (e.g. BLS, Secp256r1) - Signature aggregation is a process that joins two or more digital signatures into a new and unique signature. This new aggregate signature can be used to validate multiple inputs on the blockchain.
I’m all in for account abstraction (esp as it relates to W3bstream)
Paymaster: I’ve often wondered how to handle situations where a w3bstream account runs out of gas and is unable to continue interacting with dapps, while the developer remains unaware of this situation. Having your dapps pay for the gas fees in with such interaction could eliminate this concern altogether.
Signature: Supporting new signature schemes for blockchain transactions would enable a broad range of Internet-connected devices (such as Arduino) to execute valid IoTeX transactions, Hence broadening the IoT device ecosystem
A system allowing the recovery of lost accounts could benefit both users and machines that adopt the IoTeX network.
If you are interested in DePIN you can learn more about the latest developments in the sector and compare projects by visiting DePINscan. DePINscan powered by W3bstream and IoTeX is designed to empower intelligent investors in the DePIN sector.
I’ll have to ask the developers about this specifically but it looks like it would. It might full under this part of the proposal:
“Support aggregated signature (e.g. BLS, Secp256r1)”
What I found on Account Abstraction describes this as one of the functions that would be enabled. In particular, Social Recovery. This is where you would assign multi-signature permissions to a few trusted people (don’t piss them off) to help you recover a password. See this link What is Account Abstraction? | Stackup Docs - the bullet point Account Security. Moving this discussion to the Community Forum so everyone can benefit from what we learn and any thoughts, concerns, suggestions people have on this proposal.
Great question - that’s one we all want to know the answer to. @leo_io can you address this question on password recovery?
Voting begins on April 2nd and continues through April 9th. This promises to deliver truly impactful benefits for a broad range of users, from crypto-sophisticates (my term) to the newbies. We’re making it more broadly accessible and that’s a good thing. You’ll be able to vote at gov.iotex.io.
