Abstract: Typically, when a transaction is signed on-chain, a user’s signature goes directly to the blockchain node. 

Through an elliptical mathematical calculation, an address linked to the private key is obtained before state changes are made to the blockchain, and validation such as double spending is before a transaction is recorded.

Through this transactional overflow, gas fees are spent and this plays a crucial role in the experience of developers and everyday users using the blockchain system.

To improve the user experience, Hela intends to support account abstraction to improve the experience of its users.

Account Abstraction

The concept of Account Abstraction introduces the combination of an externally owned account (EOA) and smart contracts to give users a better experience of having to utilize both features of a smart contract and an EOA.

Initially , transactions consist of various fields similar to that of main transactions like call data, and signer but with a limiting factor of having to meet with the EVM which one of the rules includes having to spend gas from a user’s account balance and this user will be required to have a substantial amount which must remain as a balance.

Smart contracts, self-executing codes, adhere to all the codes that can be written by an account sender but with its limiting factor of not being able to initiate transactions. 
With the concept of account abstraction, two things can either be made possible:

• Smart contracts can initiate transactions with a private-public pair.
• EOAs can be upgraded to smart contract accounts.

The possibility of any of the listed methods of introducing account abstraction requires a concatenation of the properties of EOAs – which can initiate transactions and smart contracts that can self execute leaving a smart contract wallet with the features of being able to initiate transactions yet with customizability.

Components of a smart contract wallet

A smart contract wallet consists of five main components to keep the sender from spending gas for each transaction. 

1. The User
2. The Bundler
3. Entry point
4. Paymaster
5. Smart contract

The Sender

 In every transaction, the sender remains the account contract which initiates a transaction and sends a user operation which is then relayed to the bundler. The UserOps sent to the bundler remains in the form of a meta transaction and not fully a transaction. As initially stated, the fields include “sender”, “calldata“, “maxFeePerGas“ and a “signature“.

These UserOperation objects are sent directly to a different “alt” mempool where the bundler picks up these objects for relaying to the entry point. 

Some data fields and types present in a UserOperation sent to the bundler:

The Bundler

The Bundler remains an off-chain component just like the sender. When once a sender authenticates a transaction, the bundler receives and packages it in batches.

The bundler picks specific and multiple UserOps, creates a transaction, and submits on-chain which the entry points receive for verification and execution. 

 In this transactional phase, gas is spent but can be recovered from the code written by a paymaster or the smart contract – an endpoint to the combination of the EOA and smart contract as initially described.

Selected objects by bundlers must meet all these conditions: 

• UserOps that access any other sender address of another UserOps in the same batch are excluded. All UserOps packages belong to one sender address.
• When bundling, each paymaster used in a transaction batch must have sufficient gas to pay UserOps that uses. 
• Bundlers must sort UserOps by aggregator to create the lists of UserOps-per-aggregator.

Entry Point

This is part of the on-chain component of the process. An entry point is a written contract that designates bundled UserOps to paymasters and the Smart Contract account.

Bundled UserOps whitelist a supported entry point that directs the UserOps either to a paymaster or smart contract account.
Entry point methods are separated into two: “handleOps and “handleAggregatedOps“.

handleOps method in an operation handles the userOps of accounts that don’t require any signature aggregator while the handleAggregatedOps handles batches that contain userOps of multiple aggregators.

Before executing transactions, during the verification phase, the account must verify the signature of the operation and pay the fees if it considers it valid. If in the process, the “validateUserOp“  call fails for a signature, the “handleOps“ method skips the execution of the operation.

If the execution of all operations is validated, gas spent is returned to the address of the bundler after spending it during the bundling phase. 

The Paymaster

 A paymaster is a contract written to handle the gas fees of a bundled UserOps. In the structure, gas fees can decide to be paid by the smart contract account or a paymaster. In most cases, the paymaster pays the gas on behalf of the smart contract account. 
For a transaction to be paid by the paymaster, there is a confirmation of native gas fees deposited to the entry point which automatically deducts the gas fees while running the operation.
In a case where a paymaster isn’t deployed to carry out gas on behalf of the smart contract account, the deposit is made directly to the entry point from the smart contract, and gas fees are deducted during the operation.

Account Abstraction and its use cases

Account abstraction helps to reduce the cost of users spending gas on transactions. Other use cases include:

• • Multi-Sig authorization: In a smart contract account, the sender of a transaction has full control over the limit of authorization. In a multi-sig authorization, access for certain transactions to be carried out is dependent on the large fraction of address added to the code to sign a transaction. Through account abstraction, these addresses are coded into the validation loop such that when once the condition of a definite threshold of the signers isn’t reached then the transaction cannot be made possible
    

• Privacy and security: in terms of cases of wallet hacks or unauthorized access to one’s private key, a cycle can initially be created where the user can only send a sum of money to a whitelisted address before interacting with the other components.
  In the case of a wallet hack, a user remains safe as only whitelisted addresses can receive money from the exact address.
  

Conclusion

Through this component and a new introduction to scale user experience, Hela intends to integrate this into its system, with other infrastructural tools to help developers build and customize paymasters and bundlers.
In the future, there might be an implementation of running Hela’s account abstraction with its logic written into its protocol rather than the use of an entry point.