Plan to upgrade Kovan Testnet to POA Governance model

Kovan Ethereum Testnet
#1
Here is the proposed plan to upgrade Kovan Testnet to POA Governance model

  1. Validators generate and provide public keys to be included in governance contracts https://forum.poa.network/c/kovan-testnet/validators-intro

  2. POA Team prepares POA Governance contracts with initial validators and deploys them to Kovan

  3. Validators agree on HF date

  4. POA Team prepares new spec:

    4.1. Change list: [...] to multi: { 0: { list: [...] } }

    4.2. Add PoaNetworkConsensus contract address to engine.authorityRound.params.validators.multi for the specified future block defined on point 3 (like here)

  5. POA Team deploys governance dapps

  6. POA Team provides changed spec to existing validators

  7. Existing validators update their spec, parity-ethereum version to the current stable, and restart their nodes

4 Likes
#2
#3

What is the recommended hardware specifications ( cpu, RAM, network ) to. host our own validation node and what is the average data transfer out from validation node if anyone host its own validation node.

1 Like
#4

We are using r5.large instance for Kovan Archive node. I’d say t3.large will be good option to start.
Don’t know about traffic since we are using many different nodes on one account and some traffic is paid and some is free on AWS. I will check it out how to collect paid traffic on a given EC2 instance.

Btw which project do you represent?

#5

Hey @igorbarinov, Thanks. I am thinking around to setup my own validator node so I need some insight related to server details + if some instruction manual exists to do so. If you have any more information regarding the same then please let me know.

Polymath

#6

We will provide instruction. Also, will have ansible playbook to spin up a node. You can preview instruction for the xDai Chain which uses the same governance

Feel free to post an intro here Validators Intro - Forum
We expect validators to be represented as entities/companies/organizations and not individuals.
Please check intro by PepperSec
PepperSec.com as Validator

#7

@igorbarinov I had already posted network account addresses into the forum Polymath.network as Validator. Please add it as a new validator.

#8

If applying to become a Validator on different networks, you should probably use different addresses.

#9

What do you mean by different networks here. ?

#10

You applied to be a validator on Kovan network but after added validator to the xDai chain. which you edited. I suppose it was a typo and you are going to be a validator on the Kovan.

1 Like
#11

@igorbarinov Yes. Exactly. Please add me as the validator on Kovan network.

2 Likes
#12

I have some doubts regarding the transition that took place on 10960500. So I expected that the new validators added in the contract would start signing from block 10960500 although this was not the case. blocknumber 10960500 and 10960501 were signed the previous validators(POS-paritytech & POA-Grids). So is there some kind of finality that is required? Or is it round completion the netowrk waits for?

1 Like
#13

Yes, you are right, the new validators started signing from the block 10960502 because the new validator set cannot be finalized immediately: https://wiki.parity.io/Aura.html

Since there were three validators in the validator set before the block 10960500, at least two of them had to confirm the validator set changing. That’s why the new validator set was finalized at the block 10960502.

1 Like
#14

So until the transition block is not finalized the authorized validators are the previous ones. right?

#15

Also why is finalization required for a fork? Because if I am validator with a new chainspec then I have already agreed for the change. And as far agreeing on the validator set inside the contract is being considered the previous validators have already agreed to it in the previous blocks. Do I make sense? Please correct me or point me in the right direction

#16

So until the transition block is not finalized the authorized validators are the previous ones. right?

Right.

Also why is finalization required for a fork?

To apply the changes there should be majority of the votes: this rule assumes at least 50%+1 validator votes to agree on the change for security reasons (if we talk about AuRa consensus) because there can be some malicious validators in the validator set, especially in the networks where the validators are anonymous persons. BTW, we recently implemented in our Parity client fork an improved consensus formula which assumes to have at least 2/3 of the votes for successful finality: https://github.com/poanetwork/parity-ethereum/pull/109

2 Likes