Why "account-centric" indexing?

Retrieving and computing semantics out of crypto data is repetitive, complicated and expensive. Hemera Protocol abstracts away the complexity and makes the task simple.

Challenges

To have a full grasp of the complications behind programming for account-level semantic data, it is crucial to first dissect the blockchain data structures. Ethereum blockchain data can be categorized into two types of non-overlapping datasets: state, needed to build and validate new blocks; and history, necessary for syncing a node from Genesis to the latest block. State is composed of contract bytecode, contract storage, account balance (i.e. Ether balance) and account nonces. History is composed of blocks and transactions.

From these definitions, when it comes to programming for account-level semantic data, i.e. assets tracking, social graph etc., developers need to perform at least the following three types of operations touching both states and history data:

1. Account to contract address mapping: for each account, iterate through all historical transactions and record the respective contract addresses it has transacted with, and keep this mapping updated in real-time. Since transactions are stored chronically, developers will have to first search for the raw data transaction by transaction using Remote Procedure Call (RPC) services, which is time consuming and expensive. This mapping enables operations in type 2 & 3 operations.

2. Retrieve asset balances: each asset’s (except for Ether) current balance is stored in contract storage. If asset balance history is needed, developers need to replay and store the balance change history by iterating through transactions. Further complications exist when considering the differences in assets types and respective implications.

3. interpret transactions' semantic meaning: this task is most time consuming and repetitive. It requires developers to have access to the deployed smart contract source code as well as traces and logs in order to interpret the functionality of each smart contract. Developers can access smart contract source code via blockchain explorers, which host the compiled and verified smart contract code alongside the contract bytecode on-chain. Third-party developers would invest additional time and efforts to parse smart contracts, as they need to delve into trace and log data. One could imagine that blockchain explorers transform into interfaces where contract developers submit adapters to help third party developers interpret their contracts. This is crucial, as without this capability, basic metrics such as portfolio net worth or profit and loss (P&L) may be inaccurately calculated.

In today’s modular blockchain ecosystem, with the emergence of more rollups, high-performance chains, and Danksharding to continuously scale the EVM ecosystem, account-level data becomes fragmented across multiple blockchains. As a result, Dapp developers often find themselves reinventing the wheel, compelled to build programmable indexers from scratch in-house.

What use cases is account-centric indexing addressing?

Developers who are building applications that need access to end users' on-chain activities need account-centric indexing. The use cases can be broadly categorized as follows:

1. Real-time (or as fast as blockchains' block time is) access to on-chain activities

2. Semantic understanding of user's on-chain activities

Real-time access to on-chain activities

User-facing applications often build product features based on users' on-chain activities.

Wallet applications need to provide essential portfolio management features for better user experience; Web3 social applications rely on on-chain records to foster trust among users; Quest-based applications incentivize users' on-chain actions both in-app and outside of app for calculated rewards.

Semantic understanding of user's on-chain activities

Web3 user-facing builders often find themselves wondering about their community, figuring and rewarding the most loyal users, performing the airdrops properly etc. Yet none of this is possible without being able to extract semantics beyond raw on-chain transaction records.