The Risks of Smart Wallets: Navigating Account Abstraction in Web3

ERC-4337 is exciting, but the downside to using it can be severe

Account abstraction in Web3 introduces programmable smart contract wallets, aiming to bridge the gap between non-custodial and custodial wallets. While ERC-4337 offers exciting possibilities, it's crucial to understand its potential drawbacks.

Understanding Wallet Types

Non-custodial Wallets (EOAs):

·????? Full user control and ownership

·????? Technically demanding to manage

·????? Also known as Externally Owned Accounts (EOAs)

Custodial Wallets:

·????? Managed by third parties

·????? More convenient but less user control

·????? Ownership regulated by user agreements?

The current situation is binary: your wallet is either a pain in the neck to use or you lose control of your crypto. Neither situation is optimal. Among the attempts to bridge this divide is account abstraction. Currently, the most consequential use of account abstraction are the smart wallets described in ERC-4337.

ERC-4337 and Account Abstraction

ERC-4337 introduces smart wallets as a middle ground, offering programmability while maintaining user control. However, this innovation comes with its own set of challenges.

Key Risks and Limitations

Security Concerns

1.??????? Increased DoS Vulnerability: The complex verification process in ERC-4337 may expose systems to denial-of-service attacks.

2.??????? Account Takeover Potential: Researchers have identified vulnerabilities allowing full account takeovers in some ERC-4337 compatible wallets.

?

Technical Constraints

1.??????? Partial Implementation: ERC-4337 provides an off-chain transaction management system rather than full protocol-level account abstraction.

2.??????? Transaction Limitations: ERC-4337 accounts can only send one transaction to the mempool at a time, potentially restricting throughput.

?

Implementation Challenges

1.??????? Increased Complexity: ERC-4337 introduces new components like Bundlers, EntryPoints, and UserOperations, potentially creating more points of failure.

2.??????? Compatibility Issues: The parallel account and transaction processing system may face challenges integrating with existing Ethereum infrastructure.

?

Trust and Adoption Hurdles

1.??????? EntryPoint Contract Reliance: ERC-4337-compliant accounts must fully trust the EntryPoint contract, introducing a potential security risk.

2.??????? Infrastructure Requirements: Implementing account abstraction without ERC-4337 may require resource-intensive infrastructure like relayers.

3.??????? User Education: The transition to smart contract wallets may necessitate significant user adaptation.

?

Ecosystem Impact

1.??????? The coexistence of different account abstraction implementations could lead to ecosystem fragmentation, potentially complicating interoperability and user experience.

?

Economic Implications

1.??????? Higher Gas Costs: ERC-4337 transactions may incur significantly higher gas fees compared to standard EOA transactions.

Code Comparison: Standard vs. ERC-4337 Transfer

// Standard EOA Transfer
function standardTransfer(address token, address to, uint256 amount) external {
    IERC20(token).transfer(to, amount);
}

// ERC-4337 UserOperation for Transfer
function erc4337Transfer(address token, address to, uint256 amount) external {
    UserOperation memory userOp = UserOperation({
        sender: address(this),
        nonce: nonce++,
        initCode: "",
        callData: abi.encodeWithSelector(
            IERC20(token).transfer.selector,
            to,
            amount
        ),
        callGasLimit: 100000,
        verificationGasLimit: 100000,
        preVerificationGas: 21000,
        maxFeePerGas: 1 gwei,
        maxPriorityFeePerGas: 1 gwei,
        paymasterAndData: "",
        signature: ""
    });
    
    entryPoint.handleOps([userOp], beneficiary);
}        

Gas Cost Comparison

EOA Transfer: 21,000 gas

ERC-4337 Transfer: 92,901 gas

This increased gas consumption in ERC-4337 is due to several factors:

1. Additional Overhead: The ERC-4337 approach requires creating and processing a UserOperation structure, which includes extra fields like nonce, initCode, callGasLimit, verificationGasLimit, and preVerificationGas.
2. Validation Step: ERC-4337 introduces a separate validation phase, which consumes additional gas.
3. Entry Point Interaction: The handleOps function call to the Entry Point contract adds another layer of complexity and gas usage.
4. Bundler Compensation: The preVerificationGas field is used to compensate the bundler for their services, adding to the overall gas cost.

?

While ERC-4337 and account abstraction offer promising advancements in Web3 wallet technology, careful consideration of these risks and limitations is crucial for developers, investors, and users alike.