Closed arhag closed 4 months ago
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 https://github.com/eosnetworkfoundation/mandel/issues/265.
Next step is to discuss the goals of this task
Depends on https://github.com/AntelopeIO/cdt/issues/215, https://github.com/AntelopeIO/cdt/issues/210, and https://github.com/AntelopeIO/leap/issues/1525.
Contract Actions
Switchover: Action to permanently transition to HotStuff consensus.
Register Finalizer Key: Action to register a finalizer key.
Activate Finalizer Key: Action to mark a finalizer key as active.
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.
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.
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:
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:
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 theupdate_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 useset_proposed_producers
to set the block proposer schedule as well as using the new IF host function to set the finalizer set.