Weighted-Threshold-Multi-Signature (WTMsig) Block Production

[b1bart]

Background

Block producers should provide high availability for their core service of extending the blockchain (aka producing blocks). In order to achieve this they need support for redundant infrastructure in a way that safely maintains the other invariants that are expected of them.
For instance, not double signing blocks. This is the first of many features that attempt to enable a safer paradigm for highly available block production.

Goals

1. Allow BPs to have redundant block production infrastructure that does not share private key material
2. Allow Block Production to be resilient to the compromise of some portion of this infrastructure by a malicious actor

Consensus upgrade feature

In service of the above goals, the WTMSIG_BLOCK_SIGNATURES feature will transition the block_header and signed_block such that they allow for the declaration and use of a full key-only weighted-threshold multi-signature authority that is similar to the one used in account permissions.

We have discussed alternatives, such as 1-of-N multisig or M-of-N multisig. We felt that 1-of-N did not actually achieve goals (1) and (2) as each of the keys represents a valuable target for forging blocks ( violating (2) ) and any system that would attempt to mitigate this would effectively require sharing private key data ( violating (1) ). M-of-N was sufficient, but as our authority structure for validating transaction signatures is based on WTMSig and WTMSig is a super set of the functionality of M-of-N, we felt that the incremental reduction in technical complexity did not outweigh the additional cognitive complexity for users who must now understand multiple schemes for multisig.

In this scheme, a Block Producer can define a threshold and a set of weighted public keys, signing a block with as many signatures as necessary to satisfy the threshold with the sum of associated weights.

Implementation Details

Upon activation:

• validation logic will enforce that the existing new_producers field in block_header MUST be empty for all new blocks regardless of source.
• A new block_header_extension will be introduced that is used to announce new producer * schedules based on the new producer_authority type.
• a new intrinsic set_proposed_producers_ex will be valid and linkable
  • this intrinsic allows the legacy format to be used as well as a new format based on producer_authority
  • note the existing set_proposed_producers intrinsic will remain valid and only support the legacy format (which will be upgraded to a full producer_authority schedule automatically)

[arhag]

Resolved by #7404.