The first 3 courses take us back to the development of crypto wallets, and point out some challenges and concerns with several web3 wallet solutions, particularly in terms of EOA’s single point of failure, multi-sig and MPC wallet’s limitations on re-assigning delegators. In addition, web3 users require a developer-friendly environment that empowers developers to easily creat solutions to meet diverse demands of the rapidly evolving web3 landscape. Constrained by the transaction logic of EOA on Ethereum, developers found it difficult to extend its functionality and meet more complex requirements of DApps. This is where Account Abstraction comes in.Before we dive into Account Abstraction to understand why it is usually regarded as a pivotal stride in web3 mass adoption, we need to compare a typical lifecycle of a transaction with EOA and with AA improvements in Ethereum.

Ethereum Network only allows an EOA(Externally Owned Account) to initiate a transaction with ECDSA as signature, and this signed transaction is sent to the Mempool on every node in the network for processing. After information such as signature match, sufficient balance, enough gas and nonce confirmed by majority of nodes, EVM then starts executing the transaction.

From the chart above, we can see that five parts framed in red are hardcoded in Ethereum Network and cannot be altered at all. Consequently, developers should start from scratch if they introduce new functionalities, such as implementation of multi-sign using cryptographic methods. Is there a way to provide developers with a simple development environment without altering the mechanism of the Ethereum network? A group of developers made a proposal for EIP-4337, which is known as ERC-4337 now to make it happen. ERC-4337 brings new roles to Ethereum to make it more programmable, which we call Account Abstraction in Ethereum. (AA in short)

*EIP stands for Ethereum Improvement Proposal, which can be made by any members of the Ethereum community to change or improve the Ethereum Network, while ERC are standards for Ethereum Network, only community-adopted EIP can be called ERC.

The typical lifecycle of a transaction within ERC-4337 looks like this:

In the context of AA, we can simply see the bundler as taking on the role of the original EOA (indeed, the bundler is an EOA) to pack UserOperations into a Bundle, which corresponds to the original transactions in Mempool. The UO is customizable, enabling a wide range of types of signatures. Only verified Bundles at the consensus layer are sent to the EVM for specific validation of each UO by Entry Point and the execution of relevant contracts. After the Entry Point verification, the specific contract execution is initiated, which is divided into three modules:

• Factory Contract – Only involved during the initial contract creation.
• Account Contract – Utilized for implementing custom functionalities.
• Paymaster Contract – Responsible for handling customized payment for Gas.

Therefore, if we compare the steps of initiating transactions in the original way and those under AA, it is not difficult to observe that while maintaining the mechanism of the consensus layer, new modules like UserOperation, Bundler and EntryPoint have been introduced, increasing the possibility of implementing more functions.

source:https://www.erc4337.io/docs/understanding-ERC-4337/architecture_

Key Innovations in Account Abstraction Wallet

For developers, AA allows more flexibility when it comes to new functions introduction, and for users, operations that align with web2 products.

There are 5 key directions AA wallets are exploring：

• Social Recovery: Addressing concerns of permanent loss of private keys.
  In AA, developers can customize the signing method, which implies the utilization of common web2 methods via mobile, email, or biometric verification for signing or account recovery.

• Multi-signature: Applying to several participants controlling one account
  An account owner can establish a multisignature setup, requiring the approval of two or more users for transaction execution.

• Gas Improvements: Allowing anyone to pay for gas in any token, including stablecoins
  With Account Abstraction, users can utilize any token, including stablecoins, to pay for gas, further expanding the possibilities of third-party gas sponsorship. The new-added module in EVM, Paymaster, is designed to handle gas related execution. That means DApps developers can easily subsidize fees for their users as a means of acquiring users. Furthermore, it can also allow users to pay gas fees with credit cards or other means.

• Automatic Transactions: Instead of having to get approval each time we interact with DApp, AA wallets can be set to allow automatic execution under predetermined conditions. This feature allows traders to follow others’ strategies via decentralized exchange, or allows regular subscription payment in web3 world.
• Delegating calls: Wallet owners assign different roles for accounts.

Different users can be granted specific access privileges. For example, Account A is authorized to manage the wallet, with a maximum monthly limit of $100 for usage.

The scarcity of AA wallets offering multi-signature functionality is not due to technological limitations. Rather, it stems from Safe having dominated most of the market share in this realm. Consequently, other wallet providers are redirecting their efforts towards capturing the individual wallet market.

*Wallets might add more functions later on. Last update on 3rd,Nov,2023

source:https://www.alchemy.com/best/smart-contract-wallets