We need to keep multiple voting committee compositions available for voting and validation purposes. These are recomputed at epoch boundaries using the stake distribution of the previous epoch.
Ideally, this should be handled directly by the Ledger layer but, given that today the entire implementation of the voting committee component lives in Consensus, we will initially try to also handle this state within Consensus as much as possible.
One possible place to extend with a new field is ShelleyLedgerState, which already has other fields being updated at epoch boundaries (when ticking).
In addition, the voting committee state will internally keep track of the different participant's public keys, so we also need to find a way to pass obtain them there (albeit in a hacky way until we have proper on-chain key registration in place). This is tracked by #222
We need to keep multiple voting committee compositions available for voting and validation purposes. These are recomputed at epoch boundaries using the stake distribution of the previous epoch.
Ideally, this should be handled directly by the Ledger layer but, given that today the entire implementation of the voting committee component lives in Consensus, we will initially try to also handle this state within Consensus as much as possible.
One possible place to extend with a new field is
ShelleyLedgerState, which already has other fields being updated at epoch boundaries (when ticking).In addition, the voting committee state will internally keep track of the different participant's public keys, so we also need to find a way to pass obtain them there (albeit in a hacky way until we have proper on-chain key registration in place). This is tracked by #222