Skip to content
This repository has been archived by the owner on Aug 30, 2022. It is now read-only.

Allow producers to register WTMsig block signing authorities in system contract #349

Merged
merged 9 commits into from
Oct 3, 2019

Conversation

arhag
Copy link
Contributor

@arhag arhag commented Oct 1, 2019

Change Description

Change setprods action of the eosio.bios contract to take a vector of eosio::producer_authority instead and use the new set_proposed_producers_ex intrinsic to propose producer schedules using weighted threshold multisig block signing authorities.

Add the regproducer2 action to the eosio.system contract to allow block producers candidates to register a weighted threshold multisig block signing authority instead of just a single block signing key. The old regproducer action is still usable.

Deployment Changes

  • Deployment Changes

The eosio.system contract and eosio.bios contract can now only be deployed on an EOSIO chain that has activated the WTMSIG_BLOCK_SIGNATURES protocol feature.

API Changes

  • API Changes

The eosio.bios contract's setprods action now takes a vector of eosio::producer_authority as the schedule rather than a vector of eosio::producer_key.

The eosio.system contract adds a new action regproducer2 which does the same thing as the existing regproducer action except that it allows the block producer candidate to register a weighted threshold multisig block signing authority rather than just a single block signing key.

This PR also adds a binary extension field producer_authority to the producers table of the eosio.system contract and it subtly changes the meaning of the producer_key field. The producer_key will still be set as it was before if the block producer candidate uses the regproducer action to register a block signing key or even if the regproducer2 action is used to set a block signing authority consisting of a single key (that single key is repeated in producer_key). However, if a block signing authority with multiple keys is registered, then producer_key will be set to the null key (the same key it would have if the block producer candidate was disabled through unregprod or rmvproducer).

The changes in this PR introduce both variants (through block_signing_authority) and binary extensions (two new features of ABI 1.1) to the eosio.system contract ABI. They also introduce variants (through the authority field of producer_authority) to the eosio.bios contract ABI. Clients must be able to parse v1.1 ABIs to interact with this new version of the system contract.

Documentation Additions

  • Documentation Additions

…rities to eosio.bios and eosio.system contracts.

The setprods action of eosio.bios contract has been modified to support
block signing authorities in a way that is not backwards compatible.

The regproducer action of eosio.system contract is backwards compatible
for valid submitted producer keys. A new regproducer2 action has been
added to eosio.system contract to support registering a block signing
authority to a producer.

Both the eosio.bios and eosio.system contract now depend on the
set_proposed_producers_ex intrinsic and therefore can only be deployed
on an EOSIO chain that has activated the WTMSIG_BLOCK_SIGNATURES
protocol feature.
@arhag arhag marked this pull request as ready for review October 2, 2019 03:20
contracts/eosio.system/src/voting.cpp Outdated Show resolved Hide resolved
contracts/eosio.system/src/voting.cpp Show resolved Hide resolved
arhag added 3 commits October 2, 2019 09:36
…elax validation rules on keys. Also use the new CDT `is_valid` member function of `block_signing_authority_v0` to validate the user-submitted block signing authorities (requires bumping dependency on CDT).

Changes to tests to reflect the fact that `set_proposed_producers_ex` 
now accepts authorities even with invalid keys (requires bumping 
dependency on EOSIO).
@b1bart
Copy link
Contributor

b1bart commented Oct 3, 2019

this PR also closes #296

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants