IF: Unification: Modify quorum_certification to support strong and weak QCs

[arhag]

Votes for a proposal can either be strong or weak. A weak vote signs a different digest than the one used for a strong vote (the digest for a weak vote should be derived from the digest for a strong vote). The details of how these digests are computed or why a finalizer would choose to vote strong or weak is left for another issue. However, a finalizer can only choose between a weak or strong vote for any given proposal not both.

A pending_quorum_certificate is a data structure that contains the data needed to collect further finalizer votes to ultimately construct a valid QC that meets the necessary threshold for either a weak or strong QC (based on the reference finalizer policy):

• Strong bitset: 1 bit for each finalizer. If set, it means that the corresponding finalizer has contributed a strong vote to the strong aggregated signature.
• Strong aggregated signature: Aggregates all of the signatures corresponding to strong votes for the corresponding proposal of this QC.
• Weak bitset: 1 bit for each finalizer. If set, it means that the corresponding finalizer has contributed a weak vote to the weak aggregated signature. It is disallowed for a finalizer to have both a weak and strong vote present for any given QC.
• Weak aggregated signature: Aggregates all of the signatures corresponding to weak votes for the corresponding proposal of this QC.
• Note that we do not explicitly reference the proposal that this QC corresponds to. It is implied by the context in which the QC is included. The implied proposal also implies the finalizer policy to be used to validate the aggregate signatures.

There should be no intersection between the strong and weak bitsets.

A pending_quorum_certificate can be in one of the following states:

• unrestricted: Starting state.
• restricted: Enough votes to know it is impossible to reach the strong state.
• weak_achieved: Enough votes to have a valid weak QC but enough votes are pending that it is possible to still reach the strong state.
• weak_final: Enough votes to have a valid weak QC and also enough to know that it is impossible to reach the strong state.
• strong: Enough votes to have a valid strong QC.

If the accumulated weight of strong votes for a given proposal is greater than or equal to the threshold for the referenced finalizer policy, the pending_quorum_certificate is in the strong state. Otherwise, if the accumulated weight of strong votes and weak votes together is greater than or equal to the threshold for the referenced finalizer policy, the pending_quorum_certificate is in either the weak_achieved or weak_final state.

A valid_quorum_certificate is a data structure that contains just the necessary data for someone with access to the corresponding finalizer policy to validate the QC as either a weak or strong QC:

• Optional strong bitset: Same as for pending_quorum_certificate except the votes are contributed to the single aggregated signature in this data structure. Should not be present if there are no weak votes.
• Optional weak bitset: Same as for pending_quorum_certificate except the votes are contributed to the single aggregated signature in this data structure. Should not be present if there are no weak votes.
• Aggregated signature: Aggregates all of the signatures corresponding to either strong or weak votes for the corresponding proposal of this QC.

So when there are sufficient votes, we can construct a valid_quorum_certificate from a pending_quorum_certificate.

If there are sufficient strong votes for a strong QC (state: strong), then:

• The strong bitset is copied over to the new data structure.
• The weak bitset is omitted.
• The aggregated signature is set to the strong aggregated signature.

If there are not sufficient strong votes for a strong QC but there are enough strong + weak votes for a weak QC (states: weak_achieved or weak_final), then:

• The strong bitset is copied over to the new data structure.
• The weak bitset is copied over to the new data structure.
• The aggregated signature is set to the sum of the strong aggregated signature and weak aggregated signature.

Note (mostly relevant for an optimistically responsiveness implementation of IF): We wish to delay creating a valid_quorum_certificate from a pending_quorum_certificate if it has the status of weak_achieved because of a hope that it becomes strong. However, based on timeouts, we may wish to do the conversion rather than waiting longer and missing an opportunity to propagate a valid QC to finalizers. There is no value (other than maybe trying to increase representation of lagging finalizers in the QC) to wait to create a valid_quorum_certificate from a pending_quorum_certificate that has a weak_final status because it will never become strong.

Modify vote message to capture that the vote could either be strong or weak. For now, just keep them strong votes and use some finalizer digest (could just be block ID for now) as the hash to sign. Receiver of votes should aggregate the votes properly into pending_quorum_certificate. Anytime a vote is aggregated into pending_quorum_certificate its state should be re-evaluated.