Account abstraction is widely regarded as a revolutionary concept in the crypto world due to its potential to greatly enhance the user experience. Let’s break it down step by step.

​

Types of Ethereum Accounts

Ethereum currently supports 2 types of accounts:

​

1. Externally Owned Accounts (EOAs)

These are the common hot wallets used to make onchain transactions.

• Controlled by: Private keys.

• Functionality:

  • Can send messages by creating and signing transactions.
  • Initiate onchain transactions directly.

• Examples:

  • Rabby Wallet
  • Metamask
  • Coinbase Wallet

​

2. Contract Accounts

These accounts are governed by smart contracts and offer programmable logic.

• Functionality:

  • Can execute complex, custom-coded logic.
  • Can only create and send messages after receiving an initial message.

​

The Ideal Solution

The optimal account type would combine the flexibility of Contract Accounts with the direct usability of EOAs. Enter Account Abstraction.

​

What is Account Abstraction?

The introduction of EIP-4337 brought account abstraction to the Ethereum ecosystem.

​

EIP-4337: A Major Leap

• Introduced smart contract accounts that:

  • Can initiate and send transactions like EOAs.
  • Incorporate arbitrary logic for more complex actions through a single account.

• Enabled features such as:

  • Custom signature schemes.
  • Native multi-signature capabilities.
  • Application-specific restrictions.

​

Sophon’s Approach to Account Abstraction

Sophon leverages native account abstraction (AA) built into ZKsync, offering significant advantages over Ethereum’s EIP-4337. While both approaches aim to improve account flexibility and user experience, the native AA of ZKsync—and by extension Sophon—provides a seamless, efficient, and unified solution.

​

Native AA vs. EIP-4337

​

1. Implementation Level

Sophon (ZKsync Native AA): Integrated directly at the protocol level, enabling a foundational, seamless experience.

EIP-4337: Operates outside the protocol as an overlay, avoiding protocol-level changes but introducing complexity.

​

2. Account Types

Sophon (ZKsync Native AA):

• All accounts, including EOAs, behave like smart contract accounts under the hood.
• Paymasters are supported natively for all account types.
• Smart contract accounts and paymasters are treated as first-class citizens, enabling uniform functionality.

EIP-4337:

• Introduces smart contract accounts but retains EOAs as separate entities.
• Paymasters are limited to smart contract accounts, excluding EOAs from benefitting.

​

3. Transaction Processing

Sophon (ZKsync Native AA):

• Features a unified transaction flow with a single mempool for both EOAs and smart contract accounts.
• The Operator bundles transactions (regardless of account type) and sends them to the Bootloader, which processes them seamlessly.

EIP-4337:

• Introduces a separate transaction flow for smart contract accounts.
• Relies on a separate user operations mempool and specialized nodes called Bundlers to group user operations.
• Requires 2 distinct flows for processing transactions:
  • Traditional flow for EOAs.
  • New flow for smart contract accounts via the EntryPoint contract.

​

4. Paymasters Support

Sophon (ZKsync Native AA):

• Supports paymasters for both EOAs and smart contract accounts due to its unified transaction flow.
• Enables seamless gas abstraction, allowing users to pay transaction fees in tokens rather than ETH.

EIP-4337:

• Paymasters are limited to the new transaction flow for smart contract accounts.
• EOAs are excluded from using paymasters, resulting in limited functionality.

​

Why Sophon’s Native AA Matters

By utilizing native account abstraction instead of relying on EIP-4337, Sophon simplifies the user experience while enhancing the flexibility and functionality of accounts:

​

Advantages of Native AA on Sophon

• Unified User Experience: No separate flows or complex infrastructure; all accounts behave consistently.
• Gas Abstraction for All: Both EOAs and smart contract accounts benefit from paymasters, making gas payments more user-friendly.
• Streamlined Transactions: A single mempool ensures faster and more efficient processing.
• Protocol-Level Security: Native integration eliminates reliance on external overlays, enhancing robustness and reducing vulnerabilities.

​

Enhancing Sophon Accounts with Paymasters

Paymasters further elevate the functionality of Sophon accounts by:

• Abstracting transaction fees: Allowing applications to subsidize or manage gas fees on behalf of users.
• Improving user experience: Enabling gasless transactions and simplified interactions.

​

Conclusion

Account abstraction is no longer just a theoretical leap. With Sophon’s native implementation, users and developers can harness the best of both EOAs and Contract Accounts, unlocking new possibilities for innovation and usability.