Account Abstraction on Ethereum: Understanding Ethereum transaction types

There are two different types of accounts on Ethereum: Externally Owned Accounts (EOAs) and smart contracts. EOAs are user-controlled accounts, while smart contractsare programs stored on Ethereum.

Account abstraction on Ethereum evolves blockchain interaction by allowing smart contracts to replace traditional EOA enabling more flexible, secure, and user-friendly transaction experiences with programmable validation rules and simplified authentication methods.

An Ethereum transaction is an action initiated on the network by a user with an EOA. This could be transferring ETH from one account to another, or interacting with a smart contract by minting an NFT, for example. These transactions update the state of Ethereum.

Transaction Lifecycle

Once a transaction is created, it is signed (by a user’s private key), broadcasted to the network, added to the mempool (pending state), and eventually picked up by validators to be included in a new block.

For a transaction to be valid, it follows a certain structure which contains information about the transaction. As Ethereum has evolved, new transaction types have been added to modify or add new fields of data associated with a transaction.

Transaction Types

Ethereum currently has four different types of transactions:

• Type 0 (legacy)
• Type 1 (EIP-2930)
• Type 2 (EIP-1559)
• Type 3 (EIP-4844)

Type 4 transactions are set to go live in the upcoming Pectra Upgrade with EIP-7702.

The anatomy of an Ethereum transaction

Each and every transaction on Ethereum contains the following fields:

• nonce - sequential number representing the count of transactions sent from this address
• to - The recipient address (Another EOA, a smart contract, or left empty when deploying a new contract)
• value - Amount of ETH to transfer (denominated in wei)
• data - Input data for contract interactions or messages
• signature - Typically represented as v, r, s which are the components creating a valid signature)

It also includes a gas parameter, which indicates the cost for posting the transaction to the network (gas fee). 

Type 0 and Type 1 transactions

Legacy transactions (type 0) are the original type of transaction processed on Ethereum. In addition to the fundamental fields mentioned above, they also contain the fields gasPrice and gasLimit, which set the price a user was willing to pay for gas, and the gas limit for the computation itself.

Type 1 transactions were introduced with EIP-2930 and followed the exact same structure, with the addition of access lists. Access lists allowed users to pre-designate the smart contracts and storage slots the transaction would interact with, reducing the amount of gas required for more complex interactions with smart contracts.

Both type 0 and type 1 transactions still use gasPrice and gas Limit to indicate transaction cost, though. In times of network congestion, this pricing method creates an “auction” system where the transactions with the highest fees get included in the next block, potentially causing larger delays for other users. 

This problem was addressed with type 2 transactions.

Type 2 Transactions

Type 2 transactions were introduced alongside Ethereum’s London Hard Fork. The Ethereum Protocol began including a base fee to be paid based on the current network demand, doubled the maximum size of blocks to include more transactions, and implemented some other minor changes to help with congestion and the traditional pricing model for transaction fees.

Type 2 transactions include a maxPriorityFeePerGas field, which is a “tip” paid to validators to help prioritize their transaction, and maxFeePerGas which sets the maximum cost a user is willing to pay (the base fee + priority fee). These fields directly replace the gasPrice field from type 0 and 1 transactions.

Type 2 transactions are the most popular transactions in use on Ethereum currently, but with the Dencun fork in January 2024, Type 3 transactions were also introduced.

Type 3 Transactions and Use Cases

Type 3 transactions were introduced with EIP-4844, and are also referred to as “blob transactions”. Type 3 transactions are just like normal Ethereum transactions, but can contain “blob” data, a new kind of data structure optimized for Layer 2 scaling solutions.

Type 3 transactions contain all of the same fields as the previous transaction types, but with the addition of blobVersionedHashes and maxFeePerBlobGas, as well as the blob data itself. These additional fields enable efficient handling and verification of large data blobs included directly within Ethereum transactions.

blobVersionedHashes

This is an array of KZG commitment hashes that serve as cryptographic commitments to the blob data. These provide a cryptographic guarantee that the blob data attached to a transaction hasn't been altered after commitment. By using KZG commitments, validators and clients can efficiently verify the authenticity and integrity of large data blobs without needing to download or store the entire blob, thus enabling secure and scalable data handling on Ethereum.

• Each hash corresponds to one blob attached to the transaction
• The "versioned" part refers to a version byte prepended to each hash for future upgradability
• These hashes allow verification that the blob data matches what was committed without accessing the full data
• A single transaction can include multiple blobs (up to the block limit)
• Each hash is 32 bytes and verifiably binds the transaction to specific blob content

maxFeePerBlobGas

This is the maximum amount a user is willing to pay per unit of blob gas. It works similarly to the maxFeePerGas field introduced with type 2 transactions, but is specifically for blob data.

The price is determined by the current demand for blob space, and if the actual price exceeds the max price set the transaction will be rejected. Similar to how Type 2 transactions created a new fee model with its new gas parameters, maxFeePerGas creates a separate fee market optimized for storing blobs, rather than for smart contract computation.

The way blob pricing is set in the Ethereum protocol is designed to keep costs low for rollups, while ramping up in price in periods of high demand.

Use cases and benefits

Blobs and type 3 transactions are primarily designed for rollups (layer 2 scaling solutions) to post their "calldata": the compressed proofs and transaction data from the rollup to Ethereum. Before blobs, rollups had to use regular calldata which was much more expensive and contributed to network congestion.

The typical workflow is:

1. A rollup batches thousands of user transactions together
2. It compresses this data and generates cryptographic proofs
3. It submits this data as a blob attached to a Type 3 transaction
4. The Ethereum network verifies and temporarily stores this data
5. Other nodes can verify the data is available without downloading all of it

This dramatically reduces costs for rollups (an estimated 10-100x cheaper than previous methods), making Layer 2 solutions more economically viable while maintaining Ethereum's security and decentralization.

EIP-7702 and Type 4 Transactions

While EIP-4844 focused on upgrading rollups via Type 3 transactions, EIP-7702 is centered around account abstraction.

Account abstraction generally refers to the introduction of smart wallets: using smart contracts as accounts for users, while their end user account (an Externally Owned Address) acts as a signer for transactions. This was popularized with ERC-4337, and introduced the possibility for greater control over transactions, different authentication and recovery methods, and other major UX improvements.

EIP-7702 aims to take a different approach, where instead of having an EOA control a smart contract, they would be able to run and execute code on their own account. Type 4 transactions make this feasible.

The key new field introduced with type 4 transactions is authorization_list, which is a data structure containing:

• chain_id - The chain ID this authorization is valid for
• address - The address of the code to delegate to
• nonce - The current nonce of the authority
• y_parity, r, s - Signature components for the authorization

This structure allows EOAs to delegate execution to predefined smart contract code without deploying a separate contract wallet. Essentially, it enables account abstraction at the protocol level rather than as a secondary layer.

Use cases and benefits

EIP-7702 would provide many of the benefits associated with ERC-4337 accounts, but with a few distinct advantages:

1. Lower gas costs: By implementing account abstraction at the protocol level, Type 4 transactions eliminate the additional gas costs associated with ERC-4337's bundler infrastructure.
2. Native transaction batching: Users can execute multiple operations in a single transaction, reducing gas fees and improving UX.
3. Built-in gas sponsorship: Applications can pay for users' gas fees without complex infrastructure, removing a significant barrier to entry for new users.
4. Simplified architecture: Unlike ERC-4337 which requires additional infrastructure (bundlers, paymasters), Type 4 transactions work with existing Ethereum infrastructure.

EIP-7702 will be implemented in the Pectra upgrade, scheduled for May 7th, 2025.

The Future of Account Abstraction and UX Implications

The evolution of transaction types in Ethereum reflects its broader roadmap toward improved scalability, security, and usability. Each transaction type has addressed specific limitations:

• Type 0 to Type 1: Added access lists to improve gas efficiency for complex contract interactions.
• Type 1 to Type 2: Reformed gas markets to make pricing more predictable and efficient.
• Type 2 to Type 3: Optimized data storage for layer-2 solutions, dramatically reducing costs for rollups.
• Type 3 to Type 4: Bringing account abstraction to the protocol level, focusing on end-user experience.

Good UX is crucial for building successful crypto apps, and protocol-level support for account abstraction is a huge milestone for Ethereum.  

Since the first push for account abstraction with ERC-4337, the goal of many in the ecosystem has been to improve the user experience associated with using EOAs. These include some of the benefits mentioned above, such as gas sponsorship and lower transaction costs. 

An improved first time app experience might look like:

1. A user signs up for a crypto app for the first time
2. The user sets initial permitted operations, e.g. all token approvals, buying, and selling (one-time setup)
3. App executes pre-authorized operations without need for further approvals
4. The app sponsors any actions taken by a user (using Type 4 transactions)

This creates a much simpler experience for those newer to crypto, or using an app for the first time. 

Supporting the future of Ethereum transactions

As Ethereum advances with these new transaction types, infrastructure providers need to evolve alongside it. 

At Turnkey, we support all Ethereum transaction types, including Type 3 and Type 4 transactions. Crypto apps built using Turnkey can immediately leverage blob transactions for Layer 2 solutions or high-throughput apps, and Type 4 transactions are supported both now on Testnet and after Pectra goes live.

Turnkey provides secure, flexible, and scalable key management infrastructure for signing these transactions, as well as:

• Flexible authentication options: Users can sign up / log in to your app using passkeys, SMS, email, and more
• Session key support: Log your users in for limited sessions, which can be combined with Type 4 transactions for transaction batching
• Cross-chain compatibility: We offer multi-chain support at the cryptographic curve level, meaning hundreds of different chains have native support on Turnkey
• Developer-first tooling: We have multiple, high quality SDKs for different programming languages and frameworks

If you’re building a product and want to take advantage of Ethereum’s new transaction types, get started with our docs, or join our support channel if you have any questions. 

Happy building!