search

alephium / explorer

The explorer front-end for Alephium protocol
https://explorer.alephium.org
GNU Lesser General Public License v3.0
12 stars 7 forks source link

Interactive metrics and statistics #32

Open mvaivre opened 3 years ago

mvaivre commented 3 years ago

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

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

This will come first.

2) Interesting charts to start with

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

Research

Design

Implementation

TBC

polarker commented 2 years ago

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

mvaivre commented 2 years ago

After talking to @tdroxler:

VDAODAO commented 2 years ago

Some other ideas :

Other explorers/sources/interesting analytics :

mvaivre commented 2 years ago

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 (#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 #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 commented 2 years ago

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 commented 2 years ago

I'm currently working on the hashrate.

mvaivre commented 2 years ago

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 commented 2 years ago

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

nop33 commented 2 years ago

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 commented 2 years ago

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

My thoughts too.

lf94 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

lf94 commented 2 years ago

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

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

@tdroxler could we focus on this next?

nop33 commented 2 years ago

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 commented 2 years ago

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

mvaivre commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

https://github.com/alephium/explorer/issues/89