Consensus
Proof of Authority (PoA) Overview
The IBFT PoA is the default consensus mechanism in the Polygon Edge. In PoA, validators are the ones responsible for creating the blocks and adding them to the blockchain in a series.
All of the validators make up a dynamic validator-set, where validators can be added to or removed from the set by employing a voting mechanism. This means that validators can be voted in/out from the validators-set if the majority (51%) of the validator nodes vote to add/drop a certain validator to/from the set. In this way, malicious validators can be recognized and removed from the network, while new trusted validators can be added to the network.
All of the validators take turns in proposing the next block (round-robin), and for the block to be validated/inserted in the blockchain, a supermajority (more than 2/3) of the validators must approve the said block.
Besides validators, there are non-validators who do not participate in the block creation but do participate in the block validation process.
This guide describes how to add a new validator node to an active IBFT network with 4 validator nodes. If you need help setting up the network refer to the Local Setup / Cloud Setup sections.
Step 1: Initialize data folders for IBFT and generate validator keys for the new node
In order to get up and running with IBFT on the new node, you first need to initialize the data folders and generate the keys:
This command will print the validator key (address) and the node ID. You will need the validator key (address) for the next step.
Step 2: Propose a new candidate from other validator nodes
For a new node to become a validator at least 51% of validators need to propose him.
Example of how to propose a new validator (0x8B15464F8233F718c8605B16eBADA6fc09181fC2) from the existing validator node on grpc address: 127.0.0.1:10000:
The structure of the IBFT commands is covered in the CLI Commands section.
BLS public key
BLS public key is only necessary if the network is running with the BLS, for the network not running in BLS mode --bls is unnecessary
Step 3: Run the client node
Because in this example we are attempting to run the network where all nodes are on the same machine, we need to take care to avoid port conflicts.
After fetching all blocks, inside your console you will notice that a new node is participating in the validation
Promoting a non-validator to a validator
Naturally, a non-validator can become a validator by the voting process, but for it to be successfully included in the validator-set after the voting process, the node has to be restarted with the --seal flag.
This operation is fairly simple. To remove a validator node from the validator-set, this command needs to be performed for the majority of the validator nodes.
BLS public key
BLS public key is only necessary if the network is running with the BLS, for the network not running in BLS mode --bls is unnecessary
After the commands are performed, observe that the number of validators has dropped (in this log example from 4 to 3).
Last updated