Add core contract actions to support Instant Finality

[arhag]

Depends on AntelopeIO/cdt#215, AntelopeIO/cdt#210, and AntelopeIO/leap#1525.

Contract Actions

Switchover: Action to permanently transition to HotStuff consensus.

• Require the authority of the contract itself
• Set a flag altering the behavior of the update_elected_producers function
• Establish a new finalizer set (introduced by the Instant Finality protocol feature)
• Abort if an insufficient number of the top 21 block producers have registered a BLS finalizer key

Register Finalizer Key: Action to register a finalizer key.

• Registered BPs Only: must be a registered block producer
• Multiple Registered Finalizer Keys: A registered block producer can have multiple registered finalizer keys.
• Proof of Possession: The finalizer key to register must be accompanied by a valid Proof of Possession signature.
• Activate on First Key: If this is the first registered finalizer key of the block producer, it will also implicitly be marked active.
• Reject Duplicate Finalizer Keys: If this finalizer key was registered before (and still exists) even by other block producers, reject the registration.

Activate Finalizer Key: Action to mark a finalizer key as active.

• Registered Finalizer Keys Only: must be a registered finalizer key.
• Registered BPs Only: account must be a registered block producer.
• Only One Active Finalizer Key: A block producer may only have one active finalizer key.
• Deactivates Previously Active Finalizer Key: Activating a finalizer key of a block producer implicitly deactivates the previously active finalizer key of that block producer.
• Immediately Change Finalizer Policy: If the block producer is currently active (in top 21), then immediately call set_finalizers with the new policy after activating the finalizer key. Otherwise, wait until the periodic check that sets the proposers and finalizers.

Delete Finalizer Key: A registered block producer can delete a registered finalizer key that is not marked as active.

• Prevent Deletion of Active Key: A registered block producer should not be able to delete a registered finalizer key that is marked as active unless it was the last registered finalizer key of that block producer.

Other Requirements:

Equivalence of Proposers and Finalizers: The contract must ensure that the set of proposers selected is always the same as the set of finalizers selected.

BLS Public Key Handling: Contract actions handle BLS public keys as text-encoded strings.

• Proof of Possession: To guard against rogue key attacks, the contract must validate possession of BLS private keys corresponding to asserted BLS public keys by verifying a signature on the asserted BLS public key.
• Actions to register, activate, or delete finalizer keys must take strings of the text-encoded (base64url) BLS public keys.
• The text-encoding of the BLS public key should also be captured in the table entry (alongside the decoded binary) so that they can be conveniently displayed in block explorers.

Selective Key Aggregation: To prevent duplicate keys and maintain integrity of BLS Key Aggregation, the contract must only include keys associated with top-ranked block producers by testing the following criteria:

• The BP must have an active BLS finalizer key registered.
• The active BLS finalizer key associated with the BP must not have already been included by another higher-ranking BP in the set.

Establish first finalizer policy: During the switchover process, the contract should utilize a host function introduced by the Instant Finality protocol feature in Leap to establish a new finalizer policy.

Ongoing Consensus: After the switchover to the new Savanna consensus algorithm, the contract must:

• ensure uninterrupted creation of new blocks using the existing set_proposed_producers mechanism to establish the block proposer schedule.
• guarantee that finalizer keys are correctly handled and maintained under the new consensus algorithm by relying on the newly introduced Instant Finality (IF) host function to manage the finalizer policy in the update_elected_producers function: a finalizer policy should only be proposed if it is different than the last proposed one which should be tracked in the contract.

Original Issue

The core contract needs changes to allow block producers to register block finalizer keys. New action(s) should allow the BP to modify the set of candidate block finalizer keys associated to their BP from which they can mark one as active using another new action. The separate action to mark one from the set as active allows the BP to configure permissions so that they can have a dedicated key that can also change which one is active and include that as part of their failover scripts; this key would be able to only choose between the pre-approved finalizer keys rather than setting new ones or changing other parameters related to the BP. The BLS public keys are specified as string of the text encoded version of the BLS public key.

When adding new BLS public keys, the new public keys must be accompanied by a "proof that the corresponding private key is known by someone" (aka "proof of possession") which must be validated (can simply be a signature on the hash of some message we agree on, e.g. the public key itself). This is the protect against rogue key attacks. There is no need for replay protections of the proof.

When aggregrating the active finalizer keys from the top ranked BPs, the contract should skip over any BP that doesn't meet the conditions until it gets a sufficient number of them (21 on EOS). These conditions include: must have an active BLS finalizer key registered; and, that key must not have already been included by another higher ranking BP that was included into the set.

The core contract should also have a mechanism that allows the active authority of the core contract to permanently switchover to using the new HotStuff consensus algorithm, e.g. an action require authority of get_self() which sets a flag that changes the behavior of the logic in the update_elected_producers. The switchover occurs by calling the host function (introduced by the Instant Finality protocol feature in Leap) which sets a new finalizer set. The action could check that enough of the top 21 producers have registered a BLS finalizer key and abort otherwise.

After switchover has occurred, the update_elected_producers function will continue to use set_proposed_producers to set the block proposer schedule as well as using the new IF host function to set the finalizer set.

[arhag]

May need to rethink design above.

May want to not include BLS public key in regproducer and regproducer2 actions. May instead add new actions to manage finalizer keys. Can also make having an active finalizer key as a requirement for their BP to be considered active and considered for the top 21.

This is essentially the same idea as was described as Solution 1 in eosnetworkfoundation/mandel#265.

[bhazzard]

Next step is to discuss the goals of this task