IF: Design proposal for how to handle changes to proposer policy

[arhag]

The current algorithm for updating the producer schedule (which determines who is allowed to produce blocks and for which blocks based on timestamp) involves a complicated three phase process that goes from proposed to pending to active.

This complicated process was created partly because the producer schedule also determines the set of keys that are allowed to participate in the consensus process that determines finality, and so it is important to ensure updates to the set happen in a way that does not violate the safety of the consensus algorithm. Since Instant Finality decouples the role of producers into finalizers and proposers, and because the mechanism of updating the set of finalizers (captured in what is called a "finalizer policy") is handled in a separate part of the design, the process for updating the rules for who gets to propose and when (called the "proposer policy") can be greatly simplified.

The active proposer policy must include all the information that is necessary for a light node to determine from a given block header the set of entities (identified by an Antelope account name) and their corresponding signing authorities that are allowed to propose that block. The critical input from the block header to determine that set is the timestamp.

The current algorithm effectively gives a set of one member (so there is exactly one producer that is allowed to produce a block of any particular timestamp). The new algorithm could also restrict the set to exactly one member, but we also have the option of relaxing that and allowing for more than one member in the set for each block.

Currently, the signing authority associated with each proposer is a weighted set of keys with a threshold (assuming WTMSIG_BLOCK_SIGNATURES protocol feature is activated). We could continue to maintain that added complexity in the new algorithm. Or we could rollback that feature (which has not been adopted on EOS) and only associate one public key (K1 or R1) to each proposer within the proposer policy. If we do go with rolling back that feature, a transition plan should be designed as part of this proposal to handle the case of a block producer who may have adopted the usage of an authority with multiple keys.

The requirements for the design of how to handle proposer policies include:

1. No storage of proposed proposer policy in Chainbase state. The existing fields related to this in the global_propery_object can be deprecated.
2. The ephemeral state tracked while building a block can contain the latest proposed proposer policy (subsequent proposals replace the existing one in the ephemeral state). At the end of the block, if there is any new proposer policy in the ephemeral state, it is exposed by including it within the block header (via the new IF block header extension) of the new block that is being built/completed. This means each block can propose at most one new proposer policy.
3. The queue of proposed proposer policies within ancestor blocks should be tracked in the new block_header_state. A queue may be necessary rather than just the last one because the rules of promoting a proposed proposer policy to active may delay the promotion for several blocks which can allow multiple proposals to be generated within that period of time. However, the queue should prune proposer policies that are no longer necessary to keep around, either because they were promoted to active or because they were skipped over as a subsequent one in the queue was promoted to active.
4. The proposer policy data structure should be versioned to support future data structures that enable more sophisticated policies.
5. The rules for promoting proposer policies should be determined deterministically by a light node that only processes the sequence of block headers. It should also be possible for a full node to theoretically be able to convince a light node that trusts a particular block header (whether due to some out-of-band means where the finalizer digest of that block is trusted or by validating finality proofs that indicate the block is final) what the active proposer policy of that block is with appropriate proofs. This allows a light node to establish the current proposer policy even if it sparsely validates block headers. This implies that the contents of the active proposer policy must be cryptographically committed to through the finalizer digest.
6. The rules for promoting proposer policies must not promote a newly proposed proposer policy to active in the very next block because the appropriate proposer nodes may have not had a chance to prepare to produce the block in time. Some delay is needed. One choice is to account for proposer rounds (the sequence of 12 blocks by the same proposer) and delay the promotion until after the current round and the one following completes.

This issue is a design spike to figure out:

• the data structure of a proposer policy;
• how it is integrated into the new block_header_state and into the computed finalizer digest associated with the block_header_state;
• how the algorithm that updates the block_header_state correctly incorporates the evolution of the tracked data within the block_header_state relating to proposer policies;
• when and how a proposed proposer policy is promoted to active;
• how the active proposer policy constrains and determines how a (full or light) node is able to validate that a given block header respects the proposal rules and how it is able to validate the proposer signature(s) on that block header;
• and, finally how to transition from the current producer schedule system to this new proposer policy system within the Leap implementation but also how other relevant components such as the system contracts need to adapt for this transition.

And all of the above should be determined while respecting the requirements listed above. The deliverable for this issue would be a design document covering the proposed design that addresses the above which will be reviewed with the team.

[heifner]

https://hackmd.io/@9xzIZ7ZaRwegCHgQW02r3Q/BkQ4Oc4Up