ERC-4337 Account Abstraction: PoC-2 Sequence Diagram

by Alex Johnson 53 views

In the realm of blockchain technology, ERC-4337 has emerged as a groundbreaking standard for account abstraction. This article delves into the PoC-2 sequence diagram, providing a comprehensive overview of our current architecture's functionality and how it aligns with the ERC-4337 standard. We will explore the key components, processes, and considerations involved in this innovative approach to account management and transaction execution on the blockchain.

1. Core Functionalities and Their Locations

To understand the intricacies of our ERC-4337 implementation, it's crucial to identify where the four core functionalities occur, who executes them, and the underlying mechanisms involved. This section breaks down each function, providing clarity on its role within the architecture.

1.1. Asset Custody for Users

The primary function of our architecture is to safeguard user assets, and this responsibility falls upon the Smart Contract Wallet (SCW). The SCW acts as a secure vault, ensuring that assets like ETH, ISC, and other tokens are securely stored at the SCW contract address. However, it's essential to distinguish between custody and control. While the SCW holds the assets, the actual control lies with the user's private key, typically secured on their mobile device. The SCW, in this context, functions as a highly secure safe, protecting assets but requiring the user's key for any transactions.

1.2. On-Chain Evidence Provision

Another crucial aspect of our system is enabling users to provide evidence on the blockchain. This process occurs through the UserOperation, specifically within the CallData field. The evidence is encoded by the frontend and incorporated into the callData within the poc/register-parse/page.tsx component. The SCW then takes over, executing the on-chain action within its execute function. This mechanism ensures that verifiable data is securely recorded on the blockchain.

1.3. User Access Permission Verification

Verifying user access permissions is paramount for security, and this function is handled directly by the SCW contract. The validateUserOp function is responsible for this crucial step. It employs cryptographic verification, comparing the user's mobile phone public key (ownerPubKey) with the provided signature. This mathematical comparison ensures that only authorized users can initiate transactions or access their assets.

1.4. Multi-FIDO2 Key Management

Managing multiple FIDO2 keys for a single user adds a layer of flexibility and security. Currently, in PoC 3a, our system stores a single ownerPubKey. However, future iterations (PoC 4) will introduce a more robust mechanism using a mapping(key => bool) within the contract. This mapping will enable the recording and management of multiple keys, enhancing user control and security.

2. SCW and Asset Custody: A Deep Dive

One common question that arises is whether charging users through the SCW implies that the SCW is already safeguarding user assets. To answer this, we must differentiate between self-custody and platform custody. Our architecture employs self-custody, which grants users greater control over their assets.

The critical distinction lies in who has the authority to move the funds. Let's examine two scenarios:

2.1. Traditional Custodial Wallets (e.g., Exchanges)

  • Asset Location: Assets reside in the exchange's cold or hot wallets.
  • Control: The exchange's backend servers, possessing the private keys, have control over the assets.
  • Risk: The platform can unilaterally transfer user funds, leaving users with no recourse.

2.2. Our SCW Architecture (Non-Custodial)

  • Asset Location: Assets are held on-chain at the user's SCW contract address.
  • Control: Only the holder of the FIDO2 private key (typically on the user's mobile device) can authorize transactions.
  • Gas Fee Collection:
    • The platform (Bundler) cannot arbitrarily withdraw funds from the SCW.
    • The platform must present a UserOperation, which is a user-signed authorization, to the EntryPoint.
    • The EntryPoint verifies the signature, ensuring user consent, before instructing the SCW to transfer funds to the platform.

In conclusion, while the SCW holds the assets and the platform receives gas fees from it, this occurs solely based on user authorization. The platform lacks direct control over the SCW; it merely presents the user's signed