🚧[under construction]🚧 EFM committee

[AlexHentschel]

► model/flow/filter/identity.go

• type EpochParticipationStatus currently does not document state transition to "unregistered"

► consensus/hotstuff/committee.go

• document that IdentitiesByBlock and IdentityByBlock omit ejected nodes

► state transition of ejected nodes in epoch state machine. Confirm what happens when a node is ejected?

• it should still stay the remaining unbonding period changing status from

      (positive initial weight, ejected) → (zero initial weight, ejected) → unregistered 
   where we explicitly allow                            ↑
                                          (zero initial weight, leaving)   _↑
  

► documentation of epochInfo

• Generally, I think it would be very helpful to explicitly explain how this implementation corresponds to the protocol definition. This is a very security critical piece of code. Already the fact that epochInfo objects can evolve over time, warrants a more detailed description about what fields are static vs mutable and why.

  suggestion: extend this documentation to

  // Per protocol definition, membership in the consensus committee is granted for an entire
  // epoch, because HotStuff requires that the leader selection is fork-independent. It is
  // important to note that a consensus committee member retains its proposer view slots
  // for the current epoch even if it is ejected. Nevertheless, proposals from ejected nodes
  // will not be certified, because the nodes' epoch participation status is no longer active,
  // and hence are not voted for.
  // The protocol convention implies that the leader selection is independent of the
  // `DynamicIdentity` of the nodes, which can be updated throughout the epoch. The consensus
  // committee is defined as the `Participants` in the EpochSetup event, filtered down to
  // consensus nodes with _positive_ `InitialWeight`.
  // Based on the same argument, the weight-threshold for creating a valid QuorumCertificate
  // and TimeoutCertificate are constant throughout an epoch. Together with the DKG, all
  // this information fully specified by the EpochSetup and EpochCommit events. Therefore,
  // we can cache it here.
  // CAUTION: epochInfo's LeaderSelection is the only field whose state may evolve over time.
  // Guaranteeing concurrency safety is delegated to the higher-level logic.
  

► PR comment suggesting dynamic leader extension

• provide an extendable leader selection, that in addition memorizes the rng and has a slice of extensions, where each extension is its own leader selection
  • we already have a binarySearchStrictlyBigger method that can be copied and extended to work on the extension and find the leader-selection, whose range contains the requested view
  • in documentation of binarySearchStrictlyBigger replace "non-decreasing" by "monotonically increasing" (for every indices i,j with i<j we must have arr[i] ≤ arr[j])

Notes

• IsVotingConsensusCommitteeMember omits ejected nodes