The tapyrus-signerd in 0.4.0 takes its own public key, node_vss, and a threshold as parameters and participates in signature generation for the block. The Federation Management feature allows you to change the participants in the signature generation by swapping this parameter.
This issue deals with the implementation of changing participants.
Specifically, the following changes will be made
Assumption: We already have the parameters (block height, node_vss, threshold) for the next federation change.
Each signer will ignore messages from non-current federation members.
The master of the round checks to see if the height of the next block to be generated is greater than and equal to the height of the federation change and the change is not done yet, then the next candidate block would have aggregate block.
If a master does not candidate a block with an aggregate public key set despite the block height of the federation change, the master in subsequent rounds will do so.
Each member of the round checks if the received candidate block has an aggregate public key set, if any, and whether the block height is the block height of the federation's change, and if so, verifies that the aggregate public key matches what the node_vss et al. Once the verification passes, the signature generation is carried out as usual.
The next round in which a federation change occurs, the round begins with the reener with an index of 0 again as the master.
The tapyrus-signerd in 0.4.0 takes its own public key, node_vss, and a threshold as parameters and participates in signature generation for the block. The Federation Management feature allows you to change the participants in the signature generation by swapping this parameter.
This issue deals with the implementation of changing participants.
Specifically, the following changes will be made
Assumption: We already have the parameters (block height, node_vss, threshold) for the next federation change.