Support for new BallotType: AddValidator or OnBoard Validator Ballot which takes (3) keys

[johnnynuuma]

Currently, to add/onboard a Validator using Governance. (3) Ballots are required, 1 for each key ( mining, voting, payout ). There is some questions whether these ballots can be done concurrently or if the mining key needs to be added first.

There is now a 48 hour minimum for a Ballot so would take a minimum of 4 days to fully onboard a Validator.

I propose a single Ballot that support specifying the (3) keys in a single Ballot ( i.e. Add Validator or OnBoard Validator Ballot ).

There has been some discussion of decoupling the process these keys are added some, but my feeling is that to be a fully-qualified Validator you need all (3) keys so think best to keep them together. This would reduce the onboarding of a Validator to 48 hours and mitigate risk of decoupling the process.

[micwebnet]

From the perspective of NCP, there is value in low onboarding velocity. One could also argue that before validator gets to vote, they need to first verifiably demonstrate that they are capable to operate a node. A certain minimum balance on the voting account (mined and moged to it) would demonstrate that validator has enough stake to vote.

Right now we are trying to bootstrap a network, but consider the steady state when you don't necessarily want to quickly add new validators without built in safeties in place.

-MM

[johnnynuuma]

Not sure what NCP is?

I think it is a core capability to be able to move quickly because it is a requirement for certain circumstances and as you pointed out multi-stepped, safe and slow also has its advantages. We should have both capabilities.

Also, if POA Networks plan to replicate and bootstrap many Networks then I think the (3) keys API makes sense. I can imagine when rolling out a new network/demo-ing the onboarding via Governance functionality lack of this API would cause frustration and undermine confidence in the platform.

[jflowers1974]

Streamlining this tool would be hugely helpful. Only one place to make a mistake is always better than allowing for many places....

So the on boarding of a new validator's set of key in one interface would be great.

As for the removal of a validator from consensus... Then it would be the removal of only two keys (mining and voting) and not the payout. As the payout is simply a holding spot for mining rewards that are delayed X number of blocks.