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 vote, certificate, 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 vote mux backup channel (since there are no subchannels registered with the muxer on epochs 1 through 5), it hints to the marshal actor that a finalization certificate for the node’s current epoch’s boundary height must exist.
If such a finalization certificate exists, the marshal actor will fetch and verify it, and move the network finalized tip there. If that happens, the epoch manager actor will read the DKG outcome from the finalized tip and move on to the next epoch. It will not start a full simplex engine (the DKG manager is responsible for driving that), but it will “soft-enter” the new epoch by registering the new public polynomial on the scheme provider.
This process is repeated until the node catches up to the current network epoch.