A Comprehensive Understanding of the Current Status and Future Development Directions of Blockchain Data Business

Original source: sankin.eth Long Tweet

Author: sankin.eth

The industry has developed for 14 years, gradually shifting from initial speculation to practical applications. Blockchain data analysis can be conducted from three levels: on-chain macro, project protocols, and address analysis. On-chain macro allows for comparisons of metrics across different chains. Project protocols require a deep understanding of business logic. Address analysis can involve multi-dimensional tagging. Several future directions worth noting include Bitcoin Layer 2 scaling solutions, Ethereum staking data, and account abstraction multi-signature addresses. Overall, there is significant room for growth in the blockchain data market.

Introduction

If we consider the formal deployment of Bitcoin as the birth year of the industry, the blockchain sector has evolved over 14 years from pure speculation and trading to a technology concept with practical applications. Particularly after the Decentralized Finance (DeFi) concept was recognized and accepted by users, value has returned to the chain, and on-chain data has gradually become the focus of attention for investors and developers.

The headline of The Times on January 3, 2009 - Chancellor on brink of second bailout for banks

Despite the relatively limited scale of blockchain data compared to the vast amounts of big data in the current internet, and its relatively simple nature from the original data perspective, the actual analysis and interpretation process often requires analysts and developers to spend a significant amount of time parsing and utilizing the data due to the relatively free input and the presence of many hard-to-understand bytecodes. Based on work experience, I believe blockchain data can be categorized from a business perspective for better understanding:

1. On-chain macro

2. Project protocols

3. Address analysis

Blockchain networks can be divided into three levels from macro to micro, with the network level consisting of multiple protocols, each of which is composed of activities from multiple addresses. Currently, most blockchain data analysis products targeting consumers focus on specific scenarios within these three levels. Next, I will elaborate on the business logic and application forms corresponding to each level.

On-chain Macro

From the network level, it can be further subdivided into:

• Bitcoin (UTXO model)

• Ethereum-based Ethereum Virtual Machine (EVM)

• Other non-EVM architecture public chains (such as Solana developed in Rust, modular public chain Cosmos ecosystem, and the Move language system inherited from Libra, etc.).

Typically, for comparison, we can examine four metrics: number of users, number of transactions, transaction value, and transaction fees, and conduct secondary analysis based on these. Here are a few simple examples:

• Evaluate developer activity on the network based on the number of users deploying contracts and the number of transactions;

• Calculate transactions per second (TPS) based on the time intervals of transactions to assess the network's transaction processing performance;

• Calculate the ratio of transaction amounts to transaction counts to obtain the average amount per transaction; an excessive number of low-value transactions can actually burden the network;

• Observe the total transaction fees over a period to assess the network's popularity; unlike transaction counts, a low point in transaction fees indicates lower urgency for users to transact.

Data source: Dune

For data users, network-level data can provide assistance when choosing among numerous public chains, allowing them to select the most suitable public chain for development or use based on their own situation and seize the best opportunity to participate.

Project Protocols

The classification of project protocols is very broad, including DeFi, Game, Non-Fungible Token (NFT), Decentralized Identity (DID), etc. New categories are continuously emerging, so I won't delve into a specific category here, but rather share a few experiences in analyzing project protocol data:

• Typically, a complete protocol consists of multiple business contracts, most of which require in-depth reading of documentation (clear and timely updated documentation is crucial) and combining it with one's own usage to better understand the project.

• Products in the same domain tend to have similar business logic; for example, the core business of all DEXs revolves around trading and liquidity. Understanding leading products makes it relatively easier to analyze other projects in the same field. From the perspective of the project parties themselves, they are familiar with their own data but always wish to understand more about competitors and industry status, making vertical domain data very valuable.

• Currently, most projects include a lot of off-chain data, such as team and financing information, social media data, user website operation data, internal order information, etc. Some of this data is public, while some is not, which can limit analysis of the project. However, as the industry develops, more business data will gradually be brought on-chain, as one of the purposes of users utilizing blockchain is to achieve greater transparency.

  

Data source: Dune

A typical example is during DeFi Summer when SushiSwap challenged UniSwap. The on-chain trading volumes and transaction counts of both were once similar, but in-depth analysis revealed that UniSwap had a significantly higher number of unique users compared to SushiSwap, indicating that most of SushiSwap's trading and liquidity came from a smaller number of users. The reason here is that the issuance mechanism of Sushi Token stimulated capital inflow, but later, due to an unsustainable economic model, the funds flowed back to Uniswap. Similar situations are currently reflected in the data of OpenSea and Blur, where the former has more retail trading, while the latter has more professional user trading. (Note! There is no value judgment on the projects here; rather, it illustrates that user behavior differences can be reflected in the data.)

Data source: Dune

Address Analysis

From the perspective of popular EVM architecture public chains, addresses are currently divided into two types: Externally Owned Accounts (EOA) and Contract Accounts (CA). Regarding the existing business forms of data products for addresses, I believe there are mainly:

• Asset dashboards (commonly used to display wallet asset status)

• Transaction records (often used to show badges and reward proofs, such as airdrops or DID)

• Tagging systems (multi-dimensional tags for recommendations or risk control)

Data source: DeBank

Here, I want to focus on the dimension of tagging. Currently, tags are very crucial in consumer-end data products. For example, for users, the address 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 is incomprehensible at first glance, but displaying it as vitalik.eth (the founder of Ethereum) allows for immediate recognition. Of course, this is just one of many tagging dimensions. I have summarized several dimensions of address tagging:

• Entity tags (indicating who)

• Behavior tags (indicating what has been done)

• Status tags (indicating current or past status)

• Prediction tags (indicating what might be done in the future)

• Other tags (user-defined and hard-to-classify tags)

Currently, most data products simply display entity tags and then show fund flows through behavior and status tags, lacking in-depth exploration. For example, when a transaction is initiated, displaying the counterpart address's age, assets, and number of transaction objects could alert users to potential risks; or recommending similar projects based on users' past trading behaviors, such as suggesting what NFTs are being minted the most today to addresses that have participated in multiple NFT mints, could save users' search time. Rich data support can provide stronger algorithmic services for products.

Personal Views

Finally, I would like to discuss three directions in business data that I personally find noteworthy in the next 1-2 years:

• Bitcoin Layer 2 (including data generated by other scaling solutions)

• Ethereum Staking (Beacon Chain data)

• Account Abstraction (data on account abstraction and multi-signature addresses based on the ERC-4337 proposal)

Bitcoin Layer 2

For solutions like Ordinals, which assign numbers to the smallest unit "sat" of the Bitcoin network, opinions within the Bitcoin community vary. However, its popularity has added imaginative space and miner income (transaction fees) to the Bitcoin ecosystem. From the perspective of block space and transaction volume, Ordinals once caused transaction fees to exceed block income, but the Bitcoin network clearly cannot accommodate more users for asset transactions. Even if the peer-to-peer payment narrative of Bitcoin has been replaced by the consensus of digital gold, with the halving of block rewards, the Bitcoin network's hash rate will face significant challenges. Reduced income and intensified competition will inevitably eliminate some hash power. When block rewards become negligible, transaction fees will become the primary source of income for miners. If network transaction volume and fees do not grow steadily, this translates to unstable miner income in reality, which can affect the diversity and robustness of the network. In this context, future credible scaling becomes particularly important, and the Lightning Network solution currently receives considerable consensus within the community.

Ethereum Staking

As the foundational value storage of the entire Ethereum ecosystem, Beacon Chain data is one of the data businesses that carries the most funds. However, due to the differing structures of the consensus layer and execution layer, existing data platforms have not yet effectively presented the flow relationship of funds between the two. Currently, Ethereum's staking rate is around 20%, which is relatively low in the POS consensus mechanism, especially since the Shanghai upgrade opened up staking withdrawals, the net inflow of staking has been gradually increasing. Therefore, I believe this market segment has the potential to absorb stagnant funds in the long term and has significant growth potential.

Account Abstraction

From the current data analysis perspective, most project protocols only regard EOA addresses as user accounts. However, with the emphasis on asset security and usage thresholds, programmable accounts have been proposed for abstraction. From a business perspective, the analysis logic of CA as user accounts has undergone some changes. CA cannot actively initiate transactions in EVM, so an EOA is needed to initiate the address calling CA to call other CAs. This EOA can be a different address or not one of the CA's multi-signature addresses. For these transactions, the analysis logic will change. Of course, the ERC-4337 is still in draft form, so most developers have only heard about it in articles and conferences and have not yet started using it. In on-chain data business, this is also a relatively early vertical track.

Finally, I want to make a somewhat imprecise analogy: if the data market of an industry ultimately accounts for 8% of the total scale of that industry, then the current $1 trillion market value of the cryptocurrency industry (which experienced a tenfold increase from a low of $200 billion to $2 trillion from early 2020 to the end of 2021) could accommodate about $80 billion. There is still significant room for user and capital growth in the future. The data track has currently only completed the decentralization of data storage; many stages such as data computation, data validation, and data processing require more creativity.