Inconsistency in baker in reward period yes/no?

1

Can someone check this for me in their GRPC v2 implementation?

block_hash = 'd2735387725c426c85e5242177f80b12a44c1ef6aaa8cc7453a7ed83f912dc10'
This is the last block from the Payday that happened on 2022-06-25.

I’m checking baker/pool 84252.

1
Querying GetBakerList for this hash and baker, which has 84252 in the returned baker list for this block. The documentation for GetBakerList states Get all the bakers at the end of the given block., however no mention of RewardPeriod.

2
Next up, I’d like to get this pool’s delegators (for that Payday, so from that block).
Querying GetPoolDelegatorsRewardPeriod, however, leads to an error, grpc_message:"block or pool not found."?

The documentation for GetPoolDelegatorsRewardPeriod states Get the fixed delegators of a given pool for the reward period of the given block. In contracts to the GetPoolDelegators which returns delegators registered for the given block, this endpoint returns the fixed delegators contributing stake in the reward period containing the given block.

3
There’s another thing to check, that is GetAccountInfo.
This returns a AccountInfo object, which has an optional property AccountStakingInfo, which leads to AccountStakingInfo.Baker, which has an optional property pool_info.

According to the documentation: Present if the account is currently a baker, i.e., it is in the baking committee of the current epoch.

Checking our baker at this hash leads to:

...
pool_info:
{'commission_rates': {
'baking': 0.1, 
'finalization': 1.0, 
'transaction': 0.1
}, 
'url': 'https://concordium.vn', 
'open_status': 'openForAll'}
...

4
We can query GetPoolInfo, which, according to the documentation, Get information about a given pool at the end of a given block.. This yields a PoolInfoResponse, which has an optional property called current_payday_info, according to the documentation, Information of the pool in the current reward period..

Now, for this baker/block, this yields:

...
current_payday_info=None,
...}

Hence, according to GetPoolInfo, our account in not a baker in this reward period.

Conclusion

  1. GetBakerList lists this account as a baker in this block
  2. GetPoolDelegatorsRewardPeriod can’t find the baker in this block
  3. The pool_info property is present in GetAccountInfo, so this account is a baker in the current reward period.
  4. GetPoolinfo tells us it’s not a baker in the current reward period.

Either my GRPCv2 implementation needs help, or this is inconsistent? If not, how can I determine if an account is a baker in a given payday?

(added the 4-th test to the first version of this post).

2

This is consistent. GetBakerList gives you the “current”, i.e., the snapshot of the state at the moment. The bakers that are currently allowed to bake are those that have been registered before the current payday started (more or less).

If you want to determine whether a pool is a baker in a given payday then use get_pool_info and check whether the current_payday_info is present.

The value in the account_info is still talking about the “current” epoch, not payday.

We can improve documentation here certainly.

1 Like
3

So that’s the best way to determine bakers in a reward period? GetBakersList at the last block of the previous payday?

4

It’s really one epoch before the start of the current payday.

If you want the commitee that is allowed to bake now, you can also use GetBirkParameters. That will give you the list of bakers that are eligible to bake in the payday of the block you query.

5

I don’t think GetBirkParameters exists in the v2 version yet?

I did find GetElectionInfo, which outputs an ElectionInfo class with a property baker_election_info that contains a list of bakers, documented as List of the currently eligible bakers..

If I were to query GetElectionInfo at the start of a Reward Period (ie. the block where the account reward and pool reward payout takes place), would that yield a list of bakers that are eligible in that Reward period?

I’m looking for the GRPCV2 replacement for Concordium-client consensus show-parameters --include-bakers, queried on a block in a Reward period…

6

Yes, sorry, GetBirkParameters was renamed to GetElectionInfo in V2.

Yes.

1 Like