Introduction to Account Abstraction?

Account Abstraction is a concept in blockchain technology that aims to provide solutions and improve user experience/operations through smart contracts while interacting or trying to make transactions. Users with externally owned accounts(EOAs) created on wallets such as Metamask, Trust, Coinbase and Gnosis are faced with limitations such as:

• Having to sign lots of transactions before funds can be sent

• Difficulties in gas management and also,

• Open risk of losing funds without having to trust a third-party wallet.

For a total understanding of the next section of this article, check this out on smart contracts

Differences between smart contracts wallets and externally owned accounts(EOA's).

From the table, smart contract wallets are highly customizable making users able to determine the prerequisites and codes for each wallet setup which might be for cases such as security, token support and user preferences.

Some of these prerequisites based on any of the cases stated earlier may include:

• Only the owner can withdraw funds.

• Anyone can send funds to the wallet.

• The setting of gas limit for any transaction.

• Selecting an exact chain to interact with through the wallet.

• The setting of daily withdrawal limits. For example; a wallet can be limited to only making 5 daily transactions.

Using Remix to build a smart contract wallet here's a typical code interface that can prompt 'only owner of accounts to send out funds'.

pragma solidity ^0.8.0;

contract UserWallet {
    address owner;

    constructor() {
        owner = msg.sender;
    }

    function sendFunds(address payable recipient, uint256 amount) public {
        require(msg.sender == owner, "Only the owner can send funds");
        recipient.transfer(amount);
    }
}

In this code interface:

The owner variable is an 'address variable' that stores the address of the owner of the wallet or whoever deploys the contract.

The recipient variable is an address payable variable that represents the recipient address for a transaction. It is declared as payable to allow it to receive Ether during the transaction

Amount is a uint256 variable that represents the amount of Ether to send in a transaction.

Let's dive into something less boring.

Account Abstraction on Ethereum.

You might be wondering, what makes account abstraction on other chains different from the Ethereum chain?

The Ethereum ecosystem primarily was not designed for the compatibility of externally owned accounts, hence making it difficult for Dapps to have limitless security and user experience.

Different improvement proposals on account abstraction like EIP-86 and EIP-2938 were made for the Ethereum blockchain but are still in draft format/category.

This means that the adoption of these improvement proposals is not up and running in the Ethereum ecosystem due to some inactivities.

Most importantly, these proposals are left in the draft category because of their requirement for a change in the consensus protocol of the Ethereum Virtual Machine(EVM).

The Ethereum Chain recently transitioned from the proof-of-work consensus to the proof-of-stake consensus thereby making it difficult and impossible for the consensus to be changed anytime soon. This stands to be the main reason the improvement proposals listed earlier cannot be agreed upon.

EIP-4337 remains the only proposal in the draft category that aims to implement account abstraction without a change in the consensus protocol.

In the next section of this article, let's see how EIP-4337 can improve user operations through account abstraction in Ethereum.

Account Abstraction in Ethereum through EIP-4337.

EIP-4337 as an account abstraction proposal that introduces a higher level of pseudo-transaction objects called user operations without making a direct change to the consensus protocol but instead, adding new features to the consensus and changing bottom-layer transactions.

These user operations work with a structure that describes the transaction to be sent by the smart contract on behalf of the users.

While making these transactions, user operations are sent to a special set of actors or block builders to a separate mempool through the use of the bottom layer of the consensus for packaging and hence including the transactions in a block.

In order not to cause a change to the consensus, new user operations are not included; meaning that smart contracts wallets follow a set of user operations as presented below:

For more references on user operations, see this article.

Advantages of Smart Contracts Wallets.

1. Multi-sig Authorisation: Traditionally, if you are sending funds to another wallet, as the owner you can sign transactions and the funds can be sent out. This is not extremely safe because, when once a third party has access to your seed phrases, your funds can be sent out directly to another wallet without your consent.

With the use of multi-sig authorization, more than half of the connected wallets have to grant access to the wallet before funds can be sent out.

Let's say you authorize 10 wallets to sign a transaction before funds can be sent out. These funds can only be sent out if 5 of the wallets get to sign the transaction.

1. Privacy Authorisation: Users with smart contracts can attain a full height of privacy through the use of whitelists. With whitelists, certain addresses can be included and programmed to only receive funds from a wallet.

   Through this concept, losing seed phrases won't be a big deal as the fraudsters would be unable to send funds to a non-whitelisted wallet, therefore, making access to the seed phrases null.

2. Gas Management: This makes user accounts to be free by making sure users don't have to leave a balance of their Ethereum whenever transactions are made.

   Most of the time, whenever we make transactions on the Ethereum network, gas fees would be required and yet a balance must remain. To make users more creative with their gas fees users can decide to pay these funds in another token. Such as USDT or USDC.

Possible setbacks of smart contracts wallets.

One core issue with the adoption of smart contract wallets is the mass adoption of technology. The majority of blockchain users don't have a strong will to understand the intricacies of how a wallet should be operated and even how to set it up using smart contracts as this requires a skill in programming.

Conclusion.

In conclusion, the introduction of smart contracts wallets is a new technological innovation that has the potential to improve user operations causing users to enable self-executing contracts that operate autonomously and transparently.

As the use cases for smart contracts continue to expand, we can expect to see more widespread adoption and innovation in the years to come.