Architecting Account Abstraction: EOA vs. ERC-4337 vs. zkSync Native AA

The default Ethereum account model is fundamentally flawed for mass adoption. If you want to interact with a decentralized system, you are forced into a rigid cryptographic box: the Externally Owned Account (EOA).

As we move toward protocol-level scaling, Account Abstraction (AA) has become the standard solution. But "Account Abstraction" is an umbrella term. The way it is architected on a standard EVM rollup like Arbitrum (via ERC-4337) is drastically different from how it is implemented on a ZK-rollup like zkSync Era (Native AA).

Here is a technical breakdown of the architectural leap from EOAs to Smart Accounts, and why protocol-level enshrinement matters.

1. The Legacy Architecture: EOAs

An Externally Owned Account (EOA) is simple, but structurally limited.

• The Key is the Account: An EOA is strictly bound to a single ECDSA secp256k1 public-private key pair.
• Execution: EOAs cannot contain code. They are passive entities that can only initiate transactions.
• Gas: EOAs must hold the native network token (e.g., ETH) to pay for gas.

The Flow:
When an EOA sends a transaction, the protocol natively checks the ECDSA signature, verifies the nonce, deducts the gas fee from the balance, and executes the call. The logic is hardcoded into the EVM consensus layer. If you lose your private key, you lose the account. There is no programmability.

2. The Application-Layer Hack: ERC-4337 (EVM / Arbitrum)

Because changing the Ethereum base layer is notoriously difficult, the community rallied behind ERC-4337. This standard brings Account Abstraction to EVM-compatible chains (like Mainnet, Arbitrum, or Optimism) without altering the consensus protocol.

Instead of changing the EVM, ERC-4337 shifts the abstraction to a higher-level smart contract infrastructure.

The ERC-4337 Architecture

In this model, your account is a Smart Contract, not an EOA. But since smart contracts cannot initiate their own transactions, the architecture introduces several new off-chain and on-chain actors:

1. UserOperations (UserOps): Instead of standard transactions, users sign UserOperations—structs containing the execution instructions, signatures, and custom logic.
2. Alternative Mempool: UserOps do not go into the standard Ethereum mempool. They sit in a separate, specialized UserOp mempool.
3. Bundlers: Specialized nodes (Bundlers) listen to this mempool, pack multiple UserOps into a single standard Ethereum transaction, and submit them on-chain. The Bundler pays the ETH gas fee upfront.
4. The EntryPoint Contract: The Bundler sends the batch to a singleton EntryPoint smart contract. The EntryPoint is the global orchestrator; it verifies signatures, charges the Smart Accounts for the gas (refunding the Bundler), and routes the execution calls to the respective Smart Account contracts.
5. Paymasters (Optional): Third-party contracts that can sponsor gas fees for users or allow users to pay in ERC-20 tokens.

The Trade-off: ERC-4337 is highly flexible, but because it is an application-layer standard, it relies on a parallel mempool and introduces significant gas overhead due to the massive EntryPoint contract routing.

3. Protocol-Level Enshrinement: zkSync Native AA

Unlike Arbitrum or Ethereum Mainnet, zkSync Era was built with Native Account Abstraction enshrined directly into the protocol layer.

In zkSync, there is no distinction between an EOA and a Smart Contract at the architectural level. All accounts are treated as smart contracts.

The zkSync Architecture

Because AA is natively supported, zkSync eliminates the need for the clunky off-chain infrastructure required by ERC-4337.

1. Unified Mempool: There is no separate UserOp mempool. Smart contract transactions and traditional EOA transactions live in the exact same mempool.
2. No Bundlers: Because the protocol natively understands smart contract initiated transactions, there is no need for third-party Bundlers to wrap and submit them.
3. The Bootloader (The System EntryPoint): Instead of an application-layer EntryPoint contract, zkSync uses the Bootloader. The Bootloader is a system-level smart contract that handles block construction, transaction validation, and fee processing natively.
4. Enshrined Paymasters: Paymaster logic is built directly into the transaction processing flow, making gas sponsorship native and highly efficient.

When an EOA is used on zkSync, the protocol under the hood maps it to a default smart contract implementation that validates ECDSA signatures. If you upgrade to a custom Smart Account, the protocol simply points to your custom validation logic.

Architectural Comparison: ERC-4337 vs. zkSync Native AA

Building at the Protocol Level

Understanding the difference between application-layer workarounds (ERC-4337) and protocol-layer enshrinement (zkSync) is critical when designing low-level blockchain infrastructure. Native AA offers a glimpse into what the future of Ethereum must look like to achieve true mainstream viability without sacrificing decentralization or UX.

As I continue to dive deeper into protocol engineering and ZKP implementations, analyzing these architectural trade-offs is step one. I’ll be sharing more code-level deep dives into building custom validators and Paymasters soon.