ERC-4337 | Account Abstraction Block Explorer

Abstract

EIP-4337 is a significant development in the Ethereum ecosystem, introducing the concept of account abstraction. This allows users to create custom account contracts that manage their own state and logic. This flexibility improves security, privacy, and usability for smart contracts and end-users alike. However, current block explorers are not designed to support account abstraction and cannot provide a clear representation of these new account types.

In this project, we aim to build a block explorer specifically designed to support the ERC-4337 standard, providing users with an intuitive and user-friendly interface to interact with and explore the blockchain. Our block explorer will enable users to easily navigate through the blockchain, view detailed information about individual transactions, and track the movement of funds across different accounts. Additionally, we will implement advanced analytics and visualization tools to provide users with insights into the behavior and activity of the blockchain, including transaction volume, gas usage, and more. By building a block explorer that is tailored to the needs of ERC-4337 users, we aim to make it easier for users and developers alike to interact with and leverage the full potential of this emerging standard.

Team

Name	Role	Tags
Darren Holland	Software Engineer	Database Management, Application Design, Documentation, Solidity, JavaScript, React, Node.js, Full-stack
Brad Weidner	Operations Analyst	Research, Oversight, Relations, JavaScript, Solidity, React, Python, SQL
Tomoya Williams	QA Engineer	Component Testing, JavaScript, React, Node.js, Solidity
Ben Hammond	UI/UX Designer	Design, User Experience, Front-end, React, Node.js, JavaScript, SCSS

The team has a combined 20+ years of experience in software and web development, having previously built Ethereum projects and Web3 platforms. For the scope of this proposal, the development tasks have been delegated to specific team roles to maintain fluidity, reduce overlap, and adhere to an efficient time-to-release schedule.

Objectives

Our main objectives in developing an Account Abstraction Block Explorer for ERC-4337 are to:

Provide a user-friendly interface for users to explore and understand account abstraction.
Develop a subgraph to support indexing of account abstraction data.
Foster adoption and engagement with ERC-4337.
Offer educational resources and support for developers and users interested in account abstraction.

Goal of the Project

Create and maintain an application that enables users and developers to explore blockchain information related to Account Abstraction as it pertains to the ERC-4337 standard.

By using current trends, parallel projects and previous successful applications as an inspiration; a baseline familiarity, navigation, ease of use and feel will hopefully be acheived.

Timeline

We are proposing a conservative 3-month deadline until release of the application, with the likely potential of early deployment.

We plan to achieve our objectives through the following steps:

Research and analyze EIP-4337 in further detail to understand its technical requirements and potential impact on the Ethereum ecosystem.
Develop a subgraph as per the guidelines provided by The Graph (https://thegraph.com/docs/en/developing/creating-a-subgraph/) to support indexing of account abstraction data.
Design and develop an intuitive user interface for the Account Abstraction Block Explorer.
Integrate the subgraph with the block explorer to provide real-time data and analytics.
Create educational resources and documentation to support developers and users interested in account abstraction.
Test the block explorer and subgraph extensively to ensure accurate and reliable data representation.
Launch the Account Abstraction Block Explorer and promote its adoption within the Ethereum community.

Our Development Timeline below shows the prospective project task milestones and deadlines.

Infrastructure Details

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

Subgraph

In our Account Abstraction Block Explorer for ERC-4337, we will use the subgraph as the backend to efficiently index and query account abstraction data from the Ethereum blockchain. The subgraph will serve as a vital component, ensuring seamless access to the required data and facilitating a user-friendly experience for the block explorer.

Subgraph Development: First, we will develop a custom subgraph tailored to the needs of the Account Abstraction Block Explorer. The subgraph will be designed to index relevant data from the Ethereum blockchain, specifically focusing on account abstraction as introduced in EIP-4337. We will follow The Graph's guidelines for creating subgraphs to ensure optimal performance and maintainability.
Data Schema Definition: We will define a clear and concise data schema for the subgraph, identifying the necessary entities, relationships, and attributes to represent account abstraction information. This data schema will ensure that the subgraph accurately captures the required data, enabling efficient querying and data representation in the block explorer.
Subgraph Deployment: Once the subgraph is developed and tested, we will deploy it to The Graph network. This will allow the subgraph to be accessible by the Account Abstraction Block Explorer and other applications that may require access to account abstraction data.
Integration with Block Explorer: We will integrate the deployed subgraph with our block explorer's frontend, allowing users to query the subgraph for real-time data on account abstraction. This integration will enable the block explorer to display relevant information such as account contract details, transactions, and other account abstraction-specific data.
Continuous Updates and Maintenance: We will ensure that the subgraph remains up-to-date with the latest changes in the Ethereum ecosystem, particularly with respect to ERC-4337 and account abstraction. This will involve monitoring the Ethereum blockchain for relevant updates and making necessary adjustments to the subgraph's schema and mappings as needed.

By leveraging the subgraph as the backend for our Account Abstraction Block Explorer, we can provide users with a fast, reliable, and efficient way to explore and understand account abstraction in the Ethereum ecosystem. This approach will also enable easier scalability and adaptability as the Ethereum network and account abstraction features continue to evolve.

Listener

In addition to using a subgraph as the primary backend for the Account Abstraction Block Explorer, we will also implement a custom indexer to backstop the subgraph. This custom indexer will provide an additional layer of data retrieval and processing, ensuring the accuracy and reliability of the data displayed on the block explorer.

Custom Indexer Development: We will design and develop a custom indexer tailored to account abstraction data, focusing on efficiently retrieving and processing the information relevant to ERC-4337. The custom indexer will be built to work in tandem with the subgraph, providing an extra layer of data verification and resilience.
Data Synchronization: To ensure the custom indexer has access to the most up-to-date account abstraction data, we will implement a synchronization mechanism that keeps the indexer in sync with the Ethereum blockchain. This will involve monitoring the blockchain for new blocks, transactions, and events related to account abstraction and updating the custom indexer accordingly.
Data Validation and Quality Assurance: The custom indexer will play a crucial role in validating the data presented by the subgraph. By comparing and cross-referencing the data from both sources, we can identify any potential issues or inaccuracies in the subgraph's data and make necessary adjustments or corrections to improve its reliability.
Load Balancing and Performance Optimization: The custom indexer can also help in load balancing and performance optimization by sharing the data retrieval and processing workload with the subgraph. This will ensure that the block explorer remains responsive and efficient, even during periods of high network traffic or increased query volume.

proof of concept.

Database

To build a robust and user-friendly frontend for the Account Abstraction Block Explorer, we'll need a small application database to support various frontend functionalities and store relevant metadata. This application database will complement the subgraph and custom indexer by providing quick access to non-blockchain data required for an efficient and seamless user experience.

User Management and Authentication: The application database will store user information, including authentication and authorization data, preferences, and settings. This will enable user registration, login, and management of their personal settings, creating a more personalized experience when using the block explorer.
Metadata Storage: The database will store metadata related to account abstraction entities, such as account contracts, transactions, and other relevant data not directly available on the Ethereum blockchain. This metadata can enhance the user experience by providing additional context, insights, and analytics.
Caching and Performance Optimization: The application database can be used to cache frequently accessed data, reducing the need to fetch the same information repeatedly from the subgraph or custom indexer. This will improve the block explorer's performance by reducing latency and the load on the backend data sources.
User Interface Customization: The database will store user-specific data related to the block explorer's user interface, such as custom filters, display preferences, and other personalizations. This allows users to tailor the block explorer to their needs and preferences, enhancing their experience and engagement with the platform.
Analytics and Usage Tracking: The application database can store user interaction data, enabling the tracking of user behavior and preferences. This information can be used to analyze user engagement and identify areas for improvement, ensuring that the block explorer continues to evolve and meet the needs of its users.
Data Backup and Redundancy: The application database will provide an additional layer of data redundancy, ensuring that the block explorer's essential non-blockchain data remains accessible and secure, even in case of any unexpected issues with the subgraph or custom indexer.

Design

The main goal for the design and style of this project is to create an easy-to-read and navigate web application. Fancy animations on every interaction may feel good the first few times, but after a while, it will become tedious to the user. Creating well defined sections and flow will help on-board new users and teach them how to interact with the application.

Previous observations and issues with current implementations

There are many block explorers that do a lot with the information and data they are displaying to the user; some provide a better experience than others. The data displayed on block explorers is often presented using technical terms such as hashes, hexes, and cryptographic signatures. This data can be difficult to decipher for users who are not familiar with these terms. Additionally, the lack of context around the data can make it difficult for users to understand how the data relates to the broader blockchain ecosystem.

The bar of experience that is needed to understand and follow blockchain data is too high, many users do not even know block explorers exist. We hope our efforts to make the information more digestible will help improve adoption, development and use in the years to come.

Lack of information about the data being viewed

Other explorers lack explanation for viewed information, making it difficult to understand. Although looking up terms and data on a web browser is a solution, in-app help/information is more efficient. Creating context around information helps with understanding and problem-solving, a feature missing from many explorers. Having extra information reinforces ideas, terms, and structure for users at any level, especially when diving into a new concept or standard.

Logical sections of information

Block explorers often display a lot of information on a single page, including transaction histories, wallet balances, and network statistics. It can be challenging for users to navigate through this information and understand the relationships between different data points.

The idea of having high level information displayed first and low level information displayed when going down into single transactions is how most explorers do it. We are not going to change this process.

What we are suggesting is to take chunks of information and group them together into sections that relate to one and other. This should help with navigation, reading and understanding.

Front-end

Mass amounts of information and data must be displayed on this site in a succinct and easy to follow order. The best way to order this data is by the levels of detail that they provide. Less detail at the top level and more detail at the lower levels makes it easy for users to drill down as much or as little as the need.

Accessibility and scalability are very important, this is why we will be using components and a design system to help with the ever-increasing complexity of the project.

Methodology

The atomic design methodology is what we will be using throughout this project, it provides scalability as well as the shared understanding required to help the entire team use, implement, and develop the design system over time. If and/or when the project is handed over to another team, this system will hopefully make it easy for the team to pick up where we left off.

Modular Design: Atomic Design encourages designers to break down designs into smaller, modular components that can be combined and reused to create more complex designs. This approach makes it easier to maintain consistency across an application and to scale the design as the application grows.
Component-Based Design: Atoms, molecules, and organisms are the building blocks of a design system in Atomic Design. These components can be used and reused across different parts of an application, making it more efficient to design and develop.
Hierarchy: Atomic Design organizes components into a hierarchy, with atoms being the smallest building blocks, followed by molecules, organisms, templates, and pages. This hierarchy helps ensure that designers maintain consistency across the design system and can create new designs quickly and efficiently.
Collaboration: Atomic Design emphasizes collaboration between designers and developers to create a shared language and understanding of the design system. This collaboration helps ensure that the design system is usable and effective for all stakeholders.

Lightweight

Web applications where users are quickly moving between pages should be lightweight and fast-loading. Unnecessary visual elements, such as images and styling, can cause delays and hinder the user experience. A lightweight design accommodates users with slow connections or low-spec devices, expanding the potential user base. Additionally, some users face data usage constraints; reducing bandwidth usage makes the application accessible to users with limited data plans.

Budget

The tentative budget for this project is as follows:

Research and analysis: $2,000
Subgraph development: $3,000
Block explorer design and development: $20,000
Educational resources and documentation: $5,000
Testing and quality assurance: $5,000
Marketing and community outreach: $15,000

We hope to be flexible with the project spending as the grant allows, so we can efficiently allocate the funds to the areas that may end up needing it the most. We are happy to discuss the budget with the reviewing team to provide more insight or receive feedback.

Conclusion

The Account Abstraction Block Explorer for ERC-4337 will make it easier for users to understand and interact with this revolutionary new standard. By providing an intuitive interface and supporting the indexing of account abstraction data through a subgraph, we aim to foster the adoption of ERC-4337 and contribute to the growth of the Ethereum ecosystem. We seek your support to fund this project and make this vision a reality.

Research and ideas

Reputation
Failed userOperations

Implementation Details

User Operation Struct

/UserOperation.sol



























/**
 * User Operation struct
 * @param sender the sender account of this request.
 * @param nonce unique value the sender uses to verify it is not a replay.
 * @param initCode if set, the account contract will be created by this constructor/
 * @param callData the method call to execute on this account.
 * @param callGasLimit the gas limit passed to the callData method call.
 * @param verificationGasLimit gas used for validateUserOp and validatePaymasterUserOp.
 * @param preVerificationGas gas not calculated by the handleOps method, but added to the gas paid. Covers batch overhead.
 * @param maxFeePerGas same as EIP-1559 gas parameter.
 * @param maxPriorityFeePerGas same as EIP-1559 gas parameter.
 * @param paymasterAndData if set, this field holds the paymaster address and paymaster-specific data. the paymaster will pay for the transaction instead of the sender.
 * @param signature sender-verified signature over the entire request, the EntryPoint address and the chain ID.
 */
struct UserOperation {
    address sender;
    uint256 nonce;
    bytes initCode;
    bytes callData;
    uint256 callGasLimit;
    uint256 verificationGasLimit;
    uint256 preVerificationGas;
    uint256 maxFeePerGas;
    uint256 maxPriorityFeePerGas;
    bytes paymasterAndData;
    bytes signature;
}

Events

Entrypoint.sol


































































// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.12;

import "./UserOperation.sol";
import "./IStakeManager.sol";
import "./IAggregator.sol";

/**
 * Account-Abstraction (EIP-4337) singleton EntryPoint implementation.
 * Only one instance required on each chain.
 */
interface IEntryPoint is IStakeManager {

    /**
     * An event emitted after each successful request
     * @param userOpHash - unique identifier for the request (hash its entire content, except signature).
     * @param sender - the account that generates this request.
     * @param paymaster - if non-null, the paymaster that pays for this request.
     * @param nonce - the nonce value from the request.
     * @param success - true if the sender transaction succeeded, false if reverted.
     * @param actualGasCost - actual amount paid (by account or paymaster) for this UserOperation.
     * @param actualGasUsed - total gas used by this UserOperation (including preVerification, creation, validation and execution).
     */
    event UserOperationEvent(
        bytes32 indexed userOpHash, 
        address indexed sender, 
        address indexed paymaster, 
        uint256 nonce, 
        bool success, 
        uint256 actualGasCost, 
        uint256 actualGasUsed
    );

    /**
     * account "sender" was deployed.
     * @param userOpHash the userOp that deployed this account. UserOperationEvent will follow.
     * @param sender the account that is deployed
     * @param factory the factory used to deploy this account (in the initCode)
     * @param paymaster the paymaster used by this UserOp
     */
    event AccountDeployed(
        bytes32 indexed userOpHash,
        address indexed sender,
        address factory,
        address paymaster
    );

    /**
     * An event emitted if the UserOperation "callData" reverted with non-zero length
     * @param userOpHash the request unique identifier.
     * @param sender the sender of this request
     * @param nonce the nonce used in the request
     * @param revertReason - the return bytes from the (reverted) call to "callData".
     */
    event UserOperationRevertReason(
        bytes32 indexed userOpHash,
        address indexed sender,
        uint256 nonce,
        bytes revertReason
    );

    /**
     * signature aggregator used by the following UserOperationEvents within this bundle.
     */
    event SignatureAggregatorChanged(address indexed aggregator);
}

IStakeManager.sol








































// SPDX-License-Identifier: GPL-3.0-only
pragma solidity ^0.8.12;

/**
 * manage deposits and stakes.
 * deposit is just a balance used to pay for UserOperations (either by a paymaster or an account)
 * stake is value locked for at least "unstakeDelay" by the staked entity.
 */
interface IStakeManager {

    event Deposited(
        address indexed account,
        uint256 totalDeposit
    );

    event Withdrawn(
        address indexed account,
        address withdrawAddress,
        uint256 amount
    );

    /// Emitted when stake or unstake delay are modified
    event StakeLocked(
        address indexed account,
        uint256 totalStaked,
        uint256 unstakeDelaySec
    );

    /// Emitted once a stake is scheduled for withdrawal
    event StakeUnlocked(
        address indexed account,
        uint256 withdrawTime
    );

    event StakeWithdrawn(
        address indexed account,
        address withdrawAddress,
        uint256 amount
    );
}