getblock: return the valuesPools and chainSupply fields

[teor2345]

Motivation

We've had a request to add the valuePools field to the getblock RPC response, to support a Zcash dashboard:

Not sure if this is the right place for a feature request, but it would be nice if the getblock rpc supported level 2 verbosity like zcashd. It would be useful to have an rpc that gives the shielded pool balances for each block height
With level 2 verbosity it gives info about each shielded pool balance at each block height. I’m interested in this and other data to put in a Zcash dashboard
The zebra rpc commands are much much faster than zcashd so it would be nice to have this data available from zebra in addition to zcashd

https://discord.com/channels/676527656170160146/913808952997863434/1032724714805800990

This field is supplied by zcashd when verbosity >= 1.

Specifications

https://github.com/zcash/zcash/blob/99ad6fdc3a549ab510422820eea5e5ce9f60a5fd/src/rpc/blockchain.cpp#L773-L781

Designs

Store the value pool amounts for every height, not just the tip value pool amount. This requires a database change and version increment. (Possible alternative: build a memory index from scratch when starting, if that's fast enough. It will require special code to not fully parse transactions, for speed)

Add verbosity >=1 2 parameter with valuePools field to getblock.

[oxarbitrage]

I had been doing some research about this and i think the complexity depends on the fields needed.

The value_pools field is available in level 1 verbosity and also in level 2.

Getting the value pools from each transaction is not hard for zebra, i wrote a proof of concept here: https://github.com/ZcashFoundation/zebra/compare/issue5449?expand=1

It also displays the transacions as json (something we don't have in verbosity = 0 or verbosity = 1).

PoC is currently untested.

This works depends on the fileds we want to display in verbose = 2.
But it also depends on the fields we need for each value pool. In zcash each elements of the valuePools vector has the following fields:

id
monitored
chainValue
chainValueZat
valueDelta
valueDeltaZat

The proof of concept only supports id and chainValueZat, other fields could be added (i am unsure about what the delta means so i will have to make some research) but one option can be to get from the dashboard developers the exact fields needed in order to estimate the whole thing properly.

[teor2345]

The proof of concept only supports id and chainValueZat, other fields could be added (i am unsure about what the delta means so i will have to make some research)

The valueDelta field means "the change in the chain value pool", which is what your proof of concept is showing.

The chainValue field is the total value pool for the entire chain after the block or transaction. To support this field, we'll need to change the database to store the chain value pools for every height.

[oxarbitrage]

The valueDelta field means "the change in the chain value pool", which is what your proof of concept is showing.

The chainValue field is the total value pool for the entire chain after the block or transaction. To support this field, we'll need to change the database to store the chain value pools for every height.

Yea, i was imagining that will be the case but just have the fields upside down.

This is a bit harder to do but i think we can do it, if we really want it. Before doing that we should ask what other fields will be needed so we can estimate their complexity. And we should also decide if we want to do it, and if so, if we want to do it now.

[mpguerra]

We definitely don't want to do this until we've finished #5234

[mpguerra]

Is this still something that is necessary or would be worth doing or should we just close it?

[teor2345]

Is this still something that is necessary or would be worth doing or should we just close it?

I think it might be very useful to test the ZSA work, but it is a reasonably sized change: database upgrade, new state request, new RPC field.