Avoid validating keys within block signing authorities in proposed schedule

[arhag]

Change Description

The set_proposed_producers intrinsic validated that all of the keys in the proposed schedule are valid (according to the valid() member function) and aborted if one of them was not valid. This PR still maintains that behavior to avoid introducing an unintended consensus change.

The protocol feature introduced in #7404 added a new intrinsic set_proposed_producers_ex which allows for a proposed producer schedule to include the new block_signing_authority rather than merely single producer keys.

The set_proposed_producers_ex also provides a mode that unpacks the provided schedule data according to the old format of set_proposed_producers (this requires provided a packed_producer_format value of 0). In the case of using that legacy mode, the system will again validate that the keys in the schedule (just one key per producer) are valid according to the valid() member function.

The original behavior of set_proposed_producers_ex under the new mode that allows for block_signing_authority (when packed_producer_format has a value of 1) was to also validate all of the keys. This PR changes that behavior to avoid validating the keys. All the other validation checks on the block_signing_authority are still in place.

The reason for this change is to allow contracts to call set_proposed_producers_ex in a manner that gives the contract confidence that the intrinsic will not abort the transaction. Doing this requires validating the inputs to avoid triggering any of the assertions in the native side implementation of set_proposed_producers_ex. The validation of the public keys causes a huge burden on the contract because there is no easy way to pre-validate whether, for example, a given R1 public key is valid without bringing in a lot of cryptography code into the contract. Furthermore, passing in invalid keys does no harm to the system (assuming a supermajority of producers do not all simultaneously make all their block signing keys invalid). It may only harm the producer who chooses the invalid keys because it can prevent them from signing blocks; and, there are already many ways of generating public keys that are considered valid points on the elliptic curve and yet have a corresponding private key that no one knows (short of breaking the cryptography).

Consensus Changes

• Consensus Changes

While this is technically a consensus change, it merely modifies the behavior of the currently unreleased consensus changes introduced in #7404.

API Changes

• API Changes

Documentation Additions

• Documentation Additions