Expand description
Actor implementing the epoch manager logic.
This actor is responsible for:
- entering and exiting epochs given messages it receives from the DKG manager.
- catching the node up by listening to votes for unknown epoch and requesting finalizations for the currently known boundary height.
§Entering and exiting epochs
When the actor receives an Enter message, it spins up a new simplex
consensus engine backing the epoch stored in the message. The message also
contains the public polynomial, share of the private key for this node,
and the participants in the next epoch - all determined by the DKG ceremony.
The engine receives a subchannel of the recovered, pending, and resolver
p2p channels, multiplexed by the epoch.
When the actor receives an Exit message, it exists the engine backing the
epoch stored in it.
§Catching up the node
The actor makes use of the backup mechanism exposed by the subchannel multiplexer API: assume the actor has a simplex engine running for epoch 0, then this engine will have a subchannel registered on the multiplexer for epoch 0.
If the actor now receives a vote in epoch 5 over its pending mux backup channel (since there are no subchannels registered with the muxer on epochs 1 through 5), it will request the finalization certificate for the boundary height of epoch 0 from the voter. This request is done over the boundary certificates p2p network.
Upon receipt of the request for epoch 0 over the boundary certificates p2p network, the voter will send the finalization certificate to the recovered p2p network, tagged by epoch 0.
Finally, this certificate is received by the running simplex engine (since remember, it’s active for epoch 0), and subsequently forwarded to the marshal actor, which finally is able to fetch all finalizations up to the boundary height, which will eventually trigger the node to transition to epoch 1.
This process is repeated until the node catches up to the current network epoch.