Smart Account
Last updated
Last updated
Before explaining account abstraction, let’s briefly learn about the accounts currently used in Ethereum. Ethereum uses two accounts: externally owned account (EOA) and contract account (CA), and each account has a different role. First, an externally owned account is an account that we create by obtaining a private key to trade Ethereum. Externally owned accounts are top-level accounts that have private keys and addresses and the authority to issue and sign transactions. A contract account is created when a contract is issued, and unlike externally owned accounts, it has code and storage and can execute code at a specific point in time. However, since there is no authority to issue transactions and contracts, an externally owned account must be used to issue new contracts or transactions in the contract.
Account abstraction refers to allowing the two Ethereum accounts described above to be combined into one account. Currently, in Ethereum, each account has a different role. In particular, there are many limitations when implementing functions with contracts because the contract account does not have the authority to issue or sign transactions. When issuing a transaction or requiring a signature, the transaction must be issued through an externally owned account, so the basic fee of 21000 gas required for transaction issuance must be used, and account management is also cumbersome. Account abstraction makes it possible to sign and issue transactions in a contract account without using two types of accounts, allowing the functions of an externally owned account and a contract account to be used with a single account. If it is possible to execute contracts and issue transactions in one account, you can implement various functions that are currently not possible with contract accounts, such as managing accounts at once using a contract wallet or paying fees on behalf of a specific account.
In Ethereum, account abstraction uses the function of the transaction mempool without the need to modify the consensus layer as presented in ERC-4337, and account abstraction was implemented without adding a new transaction using user operation.
User operation is a structure implemented as a smart contract, not a transaction. If you look at the fields that user operation has, they are similar to the fields that a transaction has. And when verifying a transaction, the signature, nonce value, gas cost to be paid, etc. are checked. The user operation object also verifies the signature, nonce value, and gas cost to be paid through the contract and executes the code. The actual verification process is different from a transaction, but if a transaction is issued by an externally owned account, it can be understood that user operation plays a similar role to a transaction in a contract account through account abstraction.
When a user sends a user operation object, it is registered in the mempool. When selecting a user operation object, Bundler uses the same mechanism that selects high-fee transactions from an existing mempool. Among the user operation objects registered in mempool, objects that pay a high fee to the bundler are collected to create a “bundle transaction” and stored in a block. The picture above graphically shows the process in which the user operation object is processed.
bundler: A node that collects user operation objects from the user operation mempool, verifies and executes them, and creates a “bundle transaction”
In Chain API, an account created through account abstraction is used under the name "smart account". In other words, the user creates a smart account using the address of the server wallet, and it is the smart account address that actually owns the token. Smart account has only an address without a private key, and in order to use this address, the signature of the owner's server wallet address is required.
