Individual pool provenance missing since 1.33.0

[renesecur]

We are a user of Ogmios, which uses one of the mini-protocols to fetch information from the cardano-node. Since version 1.33.0 I have noticed that the rewards provenance no longer includes the provenance for individual pools and opened CardanoSolutions/ogmios#171

I'm not sure if this is expected (couldn't find a reference in the release notes) or a regression.

My workaround currently is to downgrade to 1.32.1

[JaredCorduan]

My apologies, I had thought that this query was going to be deprecated in the node in 1.33.0. Indeed we are deliberately no longer populating that data

[KtorZ]

@JaredCorduan What about the RewardInfoPool; it's not a 1:1 replacement but I imagine it could be used in some scenario to provide similar information.

Is this what people should use instead or is this one also deprecated?

[KtorZ]

(Note: I haven't yet integrated the GetRewardInfoPool query in Ogmios, support for it was recently added to the network protocols and I was planning to add it as part of 5.2.0).

[JaredCorduan]

We probably should have made it more clear that those queries were not intended to be a part of any kind of stable API. I do not think that we want to make any promises about GetRewardInfoPools either. Folks can use it for now, but with the expectation that we may deprecate it. The reasons for deprecating could include: changes to the ranking in Daedalus, changes to how we store large state in the node like the stake distribution.

[renesecur]

Thanks for the answer. If I have means to query the node for the amount delegated, then I can almost completely reconstruct the provenance in combination with other existing queries. I'd really like to be able to do this without having to sync the chain to some other datasource.

[JaredCorduan]

@renesecur do you need the amount per stake pool or per stake account?

This query gives the amount per stake pool (in terms of total stake, not active stake). And this query gives you the delegation map (for a set of given stake credentials). I don't know if that is enough for your use case.

The ledger state dump would contain all the data you need, but it is a massive query that is really only fit for debugging purposes (and which we do not claim a stable API for).

[renesecur]

Thanks again. Yes I was using the ledger state dump before, but it has become too massive and as you mentioned its format is not stable. I have to rely on an intermediary tool to use the interfaces you are referencing, either Ogmios or cardano-cli. Getting the stake of the pool for a given snapshot is pretty straightforward, but I also need to know s (e.g. the share pledged by the owners). Querying the stake key only gives available rewards and pool delegated, not amount delegated in a specific snapshot. This is probably not the right gitrepo to be asking for this :)

[KtorZ]

(@renesecur I think that is just about the right repository since everything starts from here. If there's no way to get this information from the ledger, you won't find it in other layers either).

I guess the GetRewardInfoPool should do in your case then @renesecur, at least until another alternative is provided. I can get support for it in Ogmios promptly, this was already on the pipeline for 5.2.0 anyway.

[renesecur]

That would be awesome. Thanks!

What would feel very natural to me would be a command like cardano-cli query-stake-snapshot, which you can give either a poolId as argument or a stakekey as argument that just returns the amounts for all three snapshots.

[JaredCorduan]

I can definitely see how helpful that command would be. @renesecur . Unfortunately, right now we are in the middle of a pretty massive refactoring (in the consensus layer) of how we store some of the larger components of the ledger state. Currently everything is in memory, and we will be transitioning the "big" items to disk. "Big" here basically means anything as big at the UTxO or the map of registered stake credentials. Which means that the snapshots are caught in the middle of the work. Adding the query you described would be pretty easy, but it would probably have to be completely redone in a new and unknown way fairly soon. Let me talk with the various teams involved and see what a short and long term plan should look like.

[renesecur]

Thank you @JaredCorduan interested to hear what comes out of it