search

Magickbase / ckb-explorer-public-issues

CKB Explorer Issues
https://explorer.nervos.org/
3 stars 2 forks source link

[Request feature] Chart that shows the last movement of CKBytes in existence #424

Closed alejandroRbit closed 2 months ago

alejandroRbit commented 12 months ago

I recently wrote this article (https://www.nervos.org/knowledge-base/surprisingly_secondary_issuance_is_not_inflationary) in which I try to explain how the loss of coins affects the total spendable CKBytes over time. As a result of this article, I think it would be interesting for the community to have a chart in the CKB explorer that shows the liquidity of the network but taking into account how this liquidity moves over time. For example, we could display how many CKBytes have been moved in the last year, how many CKBytes have not been moved for X years, etc. In fact, Glassnode has similar charts like "Hold Wave" and "Hodled or lost coins" (we don't have to call it the same way, we simply show the temporalities and let the reader draw his own conclusions. It doesn't have to be the same either, it's just an example):

hold waves

Thanks to NervosDAO we can better identify and represent saving behaviors in the network compared to Bitcoin, but I think adding temporalities would add a richer and more nuanced view of network liquidity, especially to liquid CKBs that are not in the DAO, i.e. those CKBytes with transactional priorities. CKB economic model is richly nuanced and this type of chart can help community members understand it better. I also think it would be a good complement and contextualizes this other chart: https://explorer.nervos.org/charts/liquidity.

Some reference articles on this topic: Bitcoin Data Science (Pt. 1): HODL Waves Bitcoin Data Science (Pt. 2): The Geology of Lost Coins Bitcoin Data Science (Pt. 3): Dust & Thermodynamics A Primer on Bitcoin Investor Sentiment and Changes in Saving Behavior

Sven-TBD commented 8 months ago

@Keith-CY @Kirl70 We can make a similar chart like the one above with some little changes. Proposal here.

Keith-CY commented 8 months ago

@Keith-CY @Kirl70 We can make a similar chart like the one above with some little changes. Proposal here.

LGTM

zmcNotafraid commented 8 months ago

PR: https://github.com/nervosnetwork/ckb-explorer/pull/1534

Keith-CY commented 7 months ago

The API is ready, we may start the UX @Sven-TBD

Sven-TBD commented 7 months ago

Okay. The front-end work of issue has been delegated to @zmcNotafraid , coz it's not a high priority work, and Mingchang finished the backend

Do we still need a UI for this one as well? Something like the color for the Chart

zmcNotafraid commented 6 months ago

BackendPR: https://github.com/nervosnetwork/ckb-explorer/pull/1622 https://github.com/nervosnetwork/ckb-explorer/pull/1629 https://github.com/nervosnetwork/ckb-explorer/pull/1853 https://github.com/nervosnetwork/ckb-explorer/pull/1908 FrontendPR: https://github.com/Magickbase/ckb-explorer-frontend/pull/254 https://github.com/Magickbase/ckb-explorer-frontend/pull/385 image

zmcNotafraid commented 6 months ago

image

zmcNotafraid commented 6 months ago

In above chart, we needs to calcuate every day's different time range live cell's capacity as numerator.To get the ratio, we use every day's tip dao's C_ias denominator.But from the chart we can see, the all time range ratio's sum is less than 100%. So which dao's column should we use as denominator?

Keith-CY commented 6 months ago

In above chart, we needs to calcuate every day's different time range live cell's capacity as numerator.To get the ratio, we use every day's tip dao's C_ias denominator.But from the chart we can see, the all time range ratio's sum is less than 100%. So which dao's column should we use as denominator?

Based on the distribution mentioned at https://github.com/Magickbase/ckb-explorer-public-issues/issues/424#issuecomment-1963158081

dao.c includes total live cells, unclaimed dao rewards, burned to treasury. dao.s includes unclaimed dao rewards, burned to treasury

The chart is about live_cells_in_app / total_live_cells, so the denominator should be total live cells, which is dao.c - dao.s

zmcNotafraid commented 3 months ago

mainnet

block_0: #<OpenStruct c_i=3360000145238488200, ar_i=10000000000000000, s_i=35209330473, u_i=504120308900000000>
block_1: #<OpenStruct c_i=3360000290476976400, ar_i=10000000104789669, s_i=65136000891, u_i=504120308900000000>
- - -
block_0's live_cell_outputs in database capacity: 3360000000000000000
block_0_live_cells_capacity = [c_i] - [s_i] = 3360000110029157727
block_1's live_cell_outputs in database capacity: 0
block_1_live_cells_capacity = [c_i] - [s_i] = 3360000225340975509
---
But block 1 only have 1 tx that with no cell_outputs, so  why it increase capacity?

https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0023-dao-deposit-withdraw/0023-dao-deposit-withdraw.md#calculation C_i : C_{i-1} + p_i + s_i

zmcNotafraid commented 3 months ago

Question of block dao field parsed value

  1. We calculate live cells capacity of block 0 from our datatbase, the results is 3360000000000000000. But when we parse data from block 0's dao field, the dao[c] - dao[s] = 3360000110029157727, so the more110029157727 capacity is what?
  2. block 1 has no live cells generated, but dao[c] - dao[s] is 3360000225340975509.So how can I know the current time issued live cells total capacity(we expected get 3360000000000000000)
zmcNotafraid commented 3 months ago

After research, we can't directly get live cell ouputs capacity from dao field.So we use our explorer's data as taotal live cell capacity.