Interactive metrics and statistics

[mvaivre]

We would like to display live, interactive charts showing how our network is performing, and how it's evolving over time.
Some inspiration:

• https://etherscan.io/charts
• https://explorer.solana.com/
• https://polkascan.io/polkadot/analytics/charts
• https://www.dfinityexplorer.org
• https://explorer.near.org/

1) Interesting aggregated metrics to start with (big numbers)

This will come first.

• Current hashrate
• Current total supply
• Current circulating supply
• Latest block height (for each chain)
• Avg. block time
• Number of chains
• Number of nodes online
• Number of total blocks (across all chains)
• Blockchain size (in Gb)?

2) Interesting charts to start with

This can come in a second phase after the big aggregated real-time numbers.

• Number of daily transactions
• Hashrate
• Number of addresses with funds > 0
• Number of active addresses per day
• Total supply
• Circulating supply
• Number of smart contracts

Research

• Investigate graphs librairies #44

Design

• Create mockups for phase 1 (aggregated metrics)
• Create mockups for phase 2 (charts, more data)

Implementation

• Implement first aggregated metrics
• Simpler explorer layout
• Show hashrate dynamics #27

TBC

[polarker]

Block time, the number of chains, the number of total blocks can be interesting as well.

[mvaivre]

After talking to @tdroxler:

• We'll go for an hybrid approach between etherscan (100% static, server-side rendering), and dfinity (real-time data). A bit like NEAR or Solana.
• We'll focus on useful data ;) (see above, lists are ordered according to a ratio between priority & complexity).
• A bit like Solana, we'll do some polling and create some nice update animations on the FE.

[VDAODAO]

Some other ideas :

• Current TPS / current transaction# per block
• Chart Mining Pools : https://coin.dance/blocks/allhashthisweek
• Number of Nodes : https://coin.dance/nodes
• Number of coins timelocked (+maturity ?)
• avg/median/mean transaction value
• avg/median/mean transaction fee value
• avg/median/mean transaction gaz priceper block
• reward per block / daily rewards / predicted rewards
• Current Price/Marketcap/Trading volume

Other explorers/sources/interesting analytics :

• Dune Analytics has quite some interesting charts for all things ETH
• https://solanabeach.io/ is quite well done in UX
• https://avascan.info / https://snowtrace.io/
• all explorers & stats : https://www.opensourceagenda.com/projects/awesome-crypto-trackers

[mvaivre]

Continuing the discussion started in #27

Do we want to allow people to "select" an area of the chart and "zoom in", like on Etherscan.io?
Do we want to allow people to export the chart in PDF/PNG/JPEG/SVG, like on Etherscan.io and blockchain.com?
Do we want to allow people to export the data in JSON/CSV, like on Etherscan.io and blockchain.com?
Do we want to allow people to select to view the data of the last [30 days|60 days|180 days|1 year|3 years|All Time], like on blockchain.com?
Do we want to display a linear scale or also a logarithmic one, like on blockchain.com?

1. Let's see with @tdroxler how complicated / long it would be to implement paging and allow pan / zoom features. It's not a must for our first iteration - especially because we're a new project and our data doesn't go far back in time - but it's definitely a nice to have. We could start static, but let's choose a chart library (Investigate graphs librairies #44) that would allow us to easily make it dynamic in the future.
2. Export in PDF/PNG/JPEG/SVG is not necessary for now. Let's consider this only if available for free thanks to a chart library for instance.
3. Exporting stats data can be interesting, but not a priority for now. Let's train with CSV export function #41 for addresses' transactions first.
4. Related to the first question. Let's see how hard it would be to have dynamic paging (from - to) in our first iteration.
5. Let's start linear only. We'll think about adding log scale in the future if some important data have a huge delta in time.

My comments after reviewing Etherescan.io and Blockchain.com:

• Both show daily average hashrate. Do we want to display more frequent than that? I doubt it. In that case, exporting a file from Prometheus/Grafana once a day and feeding it into the explorer would be sufficient.
• Both allow to "zoom in/out", either by selecting a custom area of the chart or by clicking on predefined buttons to see the latest periods (30|60|180 days, 1|3 years, All time). Is that a useful feature for our explorer users, or should we stick to a static "All time" chart for now?
• Both allow exporting the data in CSV and image.

1. Lot of the data cited above could be updated only once a day (number of chains, supply, hashrate, blockchain size...). In general, we can start slow, see how it scales, and increase the update frequency if it makes sense. However, we should keep some data dynamic, to give a sense of dynamism and real-time feeling. We can use tricks like in the solana explorer - example: we poll the number of TX every 5 secs, and we play an interpolation animation to fake a very short update time.
2. See above
3. See above

[polarker]

Considering both what users want and implementation complexity, Me personally think these metrics are the first to support: current hashrate, current circulating supply, total number of transactions (transaction per day is nicer, but it takes more effort to implement for now). Maybe also show number of chains, number of blocks. We could fit these in one row on the homepage of explorer

Edit: only need real-time numbers for such metrics. No need of charts for now so we could focus more on wallet development

[tdroxler]

I'm currently working on the hashrate.

[mvaivre]

Here is the resulting mockup taking into accounts the facts discussed above.

The goal was to keep it as simple as it can be for now, while giving ways to evolve in the future once we'll have more data to show.

[lf94]

How often should the statistics be updated? The current update time for latest blocks is every 10 seconds.

[nop33]

Do the endpoints in the backend always give the latest values or are they cached? If they are cached, I would say to update whenever the caches expire. If they are not, then every time we query for new blocks we can also query for new statistics. WDYT?

[lf94]

then every time we query for new blocks we can also query for new statistics.

My thoughts too.

[lf94]

Do the endpoints in the backend always give the latest values or are they cached?

I'm about to research this and anything which is missing that'll be needed by this iteration.

[lf94]

It appears SyncService.scala takes care of re-calculating those computation-heavy values every once in awhile. I suggest for the first iteration we stick to updating with the block updates every 10 seconds.

This leads me to my next question: this is going to look "noisey" if for each update spinners appear: should I instead use some sort of animation between value changes?

[nop33]

I would say just update the value without spinners. A value is already there, so why show a spinner while a new value is being fetched?

[lf94]

I've checked off the values we implemented in the end.

[lf94]

Currently there's only historical data for hashrates. I would like to see historical data for:

• TX per day
• Number of smart contracts over time

Personally, as they are good indicators of people using the network. @mvaivre @nop33 ?

@tdroxler could we focus on this next?

[nop33]

A community member already implemented the "Number of addresses with funds > 0": https://alephium.ono.re/api/stats/addresses?top=10&human

I don't find that statistic useful. What might be useful however is to see "active addresses of [day | week | month]" by simply checking that the latest timestamp of a transaction of an address is within range.

Here's part of the conversation I had with the user:

I think so. However, how do you define "active"? Does it mean "has received funds at least once in the history of the blockchain"? Wouldn't a more time-strict definition fit better the word "active" (i.e. last 1/7/30 days)? See an example here: https://studio.glassnode.com/metrics?a=BTC&m=addresses.ActiveCount&resolution=1month
You can switch the resolution to 1 month or 1 week, and the number of active addresses changes.

[lf94]

I agree; actually I think maybe more useful is TX per day, since a few addresses may have a lot of activity.

[mvaivre]

I would be good to start with a chart that reflects the growth / activity on the network. I'd put it on the home page, as many explorers do. Many of them display the number of transactions per day, so we could also start with this one.

I'll start to work on a mockup rn.

[mvaivre]

First iteration visible in the figma file.

As you can see, we would need a sixth stat box for this to be visually pleasing :) An estimation of the number of nodes would be awesome IMO. @polarker what do you think? Do you see a way to get this data, or do you have another proposition?

[lf94]

#89