Original author: @sankin_eth

Original compilation: Wu Shuo Blockchain

The industry has been developing for 14 years and has gradually transformed from initial hype to practical applications. Blockchain data analysis can be carried out from three levels: macro on the chain, project agreement, and address. On-chain macro allows comparison of metrics across different chains. Project agreements require a deep understanding of business logic. Address analysis can perform multi-dimensional labeling. Several directions worth paying attention to in the future are Bitcoin Layer 2 expansion plan, Ethereum pledge data and account abstract multi-signature address. Overall, the blockchain data market has huge room for development.

Introduction

If the formal deployment of Bitcoin is regarded as the first year of the birth of the industry, with the 14-year development process of the blockchain industry, it has gradually evolved from simple hype and speculation to a technical concept with practical application scenarios, especially Decentralized After the finance (DeFi) concept is recognized and accepted by users, value returns to the chain, and the data on the chain has gradually become the focus of investors and developers.

The Times front page article headline of 3 January 2009 - Chancellor on edge of second bailout of banks

Although compared with the current volume of big data in the Internet, the data scale of the blockchain is still relatively limited and the original data is relatively single. However, in the actual analysis and interpretation process, since the data input end is relatively free and contains a large amount of Many analysts and developers often need to spend a lot of time parsing and using bytecode that is not easy to understand. From work experience, the author believes that blockchain data can be classified from the business level to better understand:

• On-chain macro

• project agreement

• address analysis

The blockchain network can be divided into three levels from macro to micro. The network level is composed of multiple protocols, and each protocol is composed of the activities of multiple addresses. Most of the current blockchain data analysis products for consumers focus on a specific scenario at these three levels. Next, the author will elaborate on the business logic and application forms corresponding to each level.

On-chain macro

From a network level perspective, it can be further subdivided into:

• Bitcoin (UTXO model)

• Ethereum Virtual Machine (EVM) based on Ethereum

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

Usually as a comparison, we can examine the four indicators of number of users, number of transactions, transaction value and transaction fees, and conduct secondary analysis on this basis. Here are a few simple examples:

Evaluate the developers activity on the network based on the number of users and transactions deploying the contract;

• Calculate the number of transactions per second (TPS) through the time interval of transactions to judge the performance of the network in processing transactions;

• Calculate the ratio of the transaction amount and the number of transactions to get the average amount of each transaction. Too many low-value transactions are actually a burden on the network;

• Observe the total transaction fees over a period of time to evaluate the popularity of the network. Unlike the number of transactions, the trough of transaction fees indicates that users have less urgency to trade.

Data source: Dune

For data users, network-level data can provide assistance when choosing among many public chains. They can choose a more suitable public chain for development or use according to their own circumstances, and seize the best opportunity to participate.

project agreement

The classification of project protocols is very broad, including DeFi, Game, Non-Fungible Token (NFT), Decentralized Identity (DID), etc. New categories are also emerging, so I will not expand on a specific category here, but Let’s talk about some experiences in analyzing project agreement data:

Usually a complete agreement will consist of multiple business contracts, most of which require in-depth reading of documents (clear and timely updates of documents are important) and combined with your own use to better understand the project.

The business logic of products in the same field will converge. For example, the core business of all DEXs is trading and liquidity. After understanding the head product, it will be relatively easy to analyze other projects in the entire field. Or from the perspective of the project party itself, they are familiar with their own data, but they always want to know more about competitors and the current status of the industry. At this time, data in vertical fields is very valuable.

Most current projects contain a lot of off-chain data, such as team and financing information, social media data, user website operation data, internal order information, etc. Some are public and some are non-public, which has limitations when analyzing projects. However, as the industry develops, more business data will gradually be put on the chain, because one of the purposes of users using the blockchain is to be more open and transparent.

Data source: Dune

A typical example is that in DeFi Summer, SushiSwap challenged UniSwap. The transaction volume and number of transactions on the chain of the two were once similar. However, in-depth analysis can find that the number of independent users of UniSwap is much higher than that of SushiSwap, which is the majority of SushiSwap. Transactions and liquidity came from fewer users. The reason here is that the issuance mechanism of Sushi Token stimulated the inflow of funds, but later because the economic model was unsustainable, the funds flowed back to Uniswap. A similar situation is currently reflected in the data of OpenSea and Blur. The former has mostly retail transactions, while the latter has mostly professional user transactions. (Note! There is no value judgment on the project here, but an explanation of the differences in user behavior that can be reflected in the data.)

Data source: Dune

address analysis

Judging from the more popular EVM architecture public chains, addresses are currently divided into two types, Externally Owned Accounts (EOA) and Contact Account (CA). Regarding the existing business forms of address data products, the author believes that the main ones are:

• Asset dashboard (mostly used in wallets to display asset status)

• Transaction records (mostly used to display badges and proof of rewards, such as airdrops or DID)

• Tag system (multi-dimensional tags for recommendation or risk control)

Data source: DeBank

Here we mainly talk about the dimension of labels. Labels are currently very critical in consumer data products. For example, for users, the meaning of 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 cannot be understood at first glance, but if it is displayed as vitalik.eth (Ethereum founder), it can be recognized immediately. Of course this is just one of many label dimensions. The author summarizes several dimensions of address labels:

• Entity tag (who it represents)

• Behavior tags (what you have done)

• Status tag (current or past status)

• Predictive label (what is likely to be done in the future)

• Other tags (user-defined and difficult-to-categorize tags)

Data source: OKLink

At present, most data products simply display entity tags, and then display the flow of funds through behavior and status tags. In-depth mining is not enough. For example, when a transaction is initiated, the age of the counterpartys address, assets, and number of transaction objects are displayed to remind users to pay attention to risks; or based on the users past The transaction behavior recommends similar items. For example, an address that participates in the minting of multiple NFTs can recommend to it which NFT is being minted by the most addresses today, which can save users search time. Rich data support can provide products with more powerful algorithm services.

personal opinion

Finally, the author would like to talk about the three directions that I am more concerned about in terms of business data in the next 1-2 years:

• Bitcoin Layer 2 (including data generated by other expansion plans)

• Ethereum Staking (Beacon Chain Data)

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

Bitcoin Layer 2

The Bitcoin community has different opinions on Ordinals, a scheme that allocates numbers to the smallest unit of the Bitcoin network sat, but its popularity has increased imagination and miner income (transaction fees) for the Bitcoin ecosystem. Judging from the block space and number of transactions, Ordinals once caused transaction fees to exceed block revenue, but the Bitcoin network is obviously unable to carry more users to complete asset transactions. Even if Bitcoins peer-to-peer payment story has been replaced by the digital gold consensus, Bitcoin network computing power will face huge challenges as the block reward is halved. Reduced income and intensified competition will inevitably eliminate some computing power. When block rewards are almost negligible, transaction fees will become the main source of income for miners. If network transaction volume and fees do not grow steadily, the reality is that miners’ income will be unstable, which will affect the diversity and robustness of the network. In this case, future trusted expansion is particularly important. Currently, the solution of Lightning Network is recognized by more consensus in the community.

Ethereum Staking

As the lowest value storage in the entire Ethereum ecosystem, Beacon Chains data can be said to be one of the data services that carries the most funds. However, due to the different structures of the consensus layer and execution layer, the existing data platform has not yet well demonstrated the capital flow relationship between the two. , the current pledge rate of Ethereum is around 20%, which is a relatively low rate in the POS consensus mechanism. Especially since Shanghai upgraded and opened pledge withdrawals, the net inflow of pledges has been slowly increasing, so the author It is believed that this part of the market is expected to absorb precipitated funds in the long term and has huge room for development.

Data source: beaconcha.in

Account Abstraction

From the current data analysis perspective, most project protocols only use EOA addresses as user accounts. However, with asset security and usage thresholds, programmable accounts are proposed for abstraction. From a business perspective, CA serves as the logic of post-analysis of user accounts. Some changes have occurred. CA cannot actively initiate transactions in EVM, so it needs an EOA as the initiating address to call CA and then call other CAs. This EOA can be a different address, or it can not be one of CAs multi-signature addresses. , for these transactions, the logic of analysis will change. Of course, ERC-4337 is still in draft, so most developers have only heard about it in articles and conferences, and have not really started to use it. This is also a fairly early vertical track in the on-chain data business. .

Data source: Dune

Finally, I would like to make a loose analogy. If the data market of an industry will eventually account for 8% of the total size of the industry, then the current market value of 1 trillion (we will have a market capitalization of 1 trillion in two full years from the beginning of 2020 to the end of 2021) The encryption industry, which has experienced a 10-fold increase from a trough of 200 billion to 2 trillion, can accommodate approximately 80 billion. There is still a lot of room for user and capital growth in the future. The data track has only completed the decentralization of data storage. , data calculation, data verification, data processing and many other stages require more creativity.