Add total mint transaction count and metalabels count per epoch

[rdlrt]

Currently there isnt a way to monitor total mint transactions per epoch.
The request here is:

• Create a cache table that contains epoch_no, distinct metalabel keys for that epoch, count of mint transactions for that epoch against each metalabel key
• Expose this data via a new RPC endpoint

[rdlrt]

Needs a bit of consideration for cache table design - as there are different type of counts that'd be needed for cache (sample columns from @edridudi ):

Epoch, NFTs count, FTs Count, medianfts (cip25) (721), Royalty Tokens (cip27) (777), etc
Above columns can go as RPC

Cache - Could instead be:
epoch_no, asset_id, minted, burnt, type

[edridudi]

Query rules for the different columns:

For NFT count:
sum(multi_assets.quantity)=1

For FT count:
sum(multi_assets.quantity)<>1

For media NFT count:
sum(quantity)=1 and metalabel.key = 721

(I wonder if we actually need to dive into each mint tx metadata and verify it according to cip-25 mandatory fields)

For Royalty Tokens count:
In cip-27 it was decided by the community that the royalty token is valid only if it is the first minted asset in a specific policy.
If it is burned afterwards it's still count as valid.

So... It makes things a lil bit more complex ☺️

So db query should be like
metalabel.key = 777 And count only if its first asset in a policy

Here we should count once only if the rules apply.

(Same as above, should we verify the existence of "address" and "rate" fields in the tx metadata according to cip-27?)

[Scitz0]

2nd asset cache table should include the following fields:
asset_id, total_supply, first_mint_tx_id, first_mint_keys, last_mint_tx_id, last_mint_keys, decimals

Also, need to ensure that all asset-related endpoints are accordingly updated as well to include asset type and decimals

[Scitz0]

@edridudi
I have spent time this weekend looking into the cache tables discussed for this. To be able to provide missing data as you suggested. Though I have run into a a few road forks and I'm currently unsure what data is actually needed.

Would you be willing to jump onto our bi-weekly call on Thursday at 22 UTC to discuss this further?

[edridudi]

Hey @Scitz0 ,
It would be midnight where I'm at but yeah I will make an effort.
Just if you can, send me an invite to the meeting so I will have a reminder.
The main idea is to have the ability to overview the Cardano Ledger over time (per epoch).
for starters, it could be assets minted but really it can be a lot of things such as the number of Transactions per epoch or new Policies per epoch/new Accounts per epoch ...

I know that it might be a lil bit complex but it's just a suggestion to have something no other API has.