github.com/aakash4dev/cometbft@v0.38.2/docs/core/validators.md (about)

     1  ---
     2  order: 6
     3  ---
     4  
     5  # Validators
     6  
     7  Validators are responsible for committing new blocks in the blockchain.
     8  These validators participate in the consensus protocol by broadcasting
     9  _votes_ which contain cryptographic signatures signed by each
    10  validator's private key.
    11  
    12  Some Proof-of-Stake consensus algorithms aim to create a "completely"
    13  decentralized system where all stakeholders (even those who are not
    14  always available online) participate in the committing of blocks.
    15  CometBFT has a different approach to block creation. Validators are
    16  expected to be online, and the set of validators is permissioned/curated
    17  by some external process. Proof-of-stake is not required, but can be
    18  implemented on top of CometBFT consensus. That is, validators may be
    19  required to post collateral on-chain, off-chain, or may not be required
    20  to post any collateral at all.
    21  
    22  Validators have a cryptographic key-pair and an associated amount of
    23  "voting power". Voting power need not be the same.
    24  
    25  ## Becoming a Validator
    26  
    27  There are two ways to become validator.
    28  
    29  1. They can be pre-established in the [genesis state](./using-cometbft.md#genesis)
    30  2. The ABCI app responds to the EndBlock message with changes to the
    31     existing validator set.
    32  
    33  ## Setting up a Validator
    34  
    35  When setting up a validator there are countless ways to configure your setup. This guide is aimed at showing one of them, the sentry node design. This design is mainly for DDoS prevention.
    36  
    37  ### Network Layout
    38  
    39  ![ALT Network Layout](../imgs/sentry_layout.png)
    40  
    41  The diagram is based on AWS, other cloud providers will have similar solutions to design a solution. Running nodes is not limited to cloud providers, you can run nodes on bare metal systems as well. The architecture will be the same no matter which setup you decide to go with.
    42  
    43  The proposed network diagram is similar to the classical backend/frontend separation of services in a corporate environment. The “backend” in this case is the private network of the validator in the data center. The data center network might involve multiple subnets, firewalls and redundancy devices, which is not detailed on this diagram. The important point is that the data center allows direct connectivity to the chosen cloud environment. Amazon AWS has “Direct Connect”, while Google Cloud has “Partner Interconnect”. This is a dedicated connection to the cloud provider (usually directly to your virtual private cloud instance in one of the regions).
    44  
    45  All sentry nodes (the “frontend”) connect to the validator using this private connection. The validator does not have a public IP address to provide its services.
    46  
    47  Amazon has multiple availability zones within a region. One can install sentry nodes in other regions too. In this case the second, third and further regions need to have a private connection to the validator node. This can be achieved by VPC Peering (“VPC Network Peering” in Google Cloud). In this case, the second, third and further region sentry nodes will be directed to the first region and through the direct connect to the data center, arriving to the validator.
    48  
    49  A more persistent solution (not detailed on the diagram) is to have multiple direct connections to different regions from the data center. This way VPC Peering is not mandatory, although still beneficial for the sentry nodes. This overcomes the risk of depending on one region. It is more costly.
    50  
    51  ### Local Configuration
    52  
    53  ![ALT Local Configuration](../imgs/sentry_local_config.png)
    54  
    55  The validator will only talk to the sentry that are provided, the sentry nodes will communicate to the validator via a secret connection and the rest of the network through a normal connection. The sentry nodes do have the option of communicating with each other as well.
    56  
    57  When initializing nodes there are five parameters in the `config.toml` that may need to be altered.
    58  
    59  - `pex:` boolean. This turns the peer exchange reactor on or off for a node. When `pex=false`, only the `persistent_peers` list is available for connection.
    60  - `persistent_peers:` a comma separated list of `nodeID@ip:port` values that define a list of peers that are expected to be online at all times. This is necessary at first startup because by setting `pex=false` the node will not be able to join the network.
    61  - `unconditional_peer_ids:` comma separated list of nodeID's. These nodes will be connected to no matter the limits of inbound and outbound peers. This is useful for when sentry nodes have full address books.
    62  - `private_peer_ids:` comma separated list of nodeID's. These nodes will not be gossiped to the network. This is an important field as you do not want your validator IP gossiped to the network.
    63  - `addr_book_strict:` boolean. By default nodes with a routable address will be considered for connection. If this setting is turned off (false), non-routable IP addresses, like addresses in a private network can be added to the address book.
    64  - `double_sign_check_height` int64 height.  How many blocks to look back to check existence of the node's consensus votes before joining consensus When non-zero, the node will panic upon restart if the same consensus key was used to sign `double_sign_check_height` last blocks. So, validators should stop the state machine, wait for some blocks, and then restart the state machine to avoid panic.
    65  
    66  #### Validator Node Configuration
    67  
    68  | Config Option            | Setting                    |
    69  | ------------------------ | -------------------------- |
    70  | pex                      | false                      |
    71  | persistent_peers         | list of sentry nodes       |
    72  | private_peer_ids         | none                       |
    73  | unconditional_peer_ids   | optionally sentry node IDs |
    74  | addr_book_strict         | false                      |
    75  | double_sign_check_height | 10                         |
    76  
    77  The validator node should have `pex=false` so it does not gossip to the entire network. The persistent peers will be your sentry nodes. Private peers can be left empty as the validator is not trying to hide who it is communicating with. Setting unconditional peers is optional for a validator because they will not have a full address books.
    78  
    79  #### Sentry Node Configuration
    80  
    81  | Config Option          | Setting                                       |
    82  | ---------------------- | --------------------------------------------- |
    83  | pex                    | true                                          |
    84  | persistent_peers       | validator node, optionally other sentry nodes |
    85  | private_peer_ids       | validator node ID                             |
    86  | unconditional_peer_ids | validator node ID, optionally sentry node IDs |
    87  | addr_book_strict       | false                                         |
    88  
    89  The sentry nodes should be able to talk to the entire network hence why `pex=true`. The persistent peers of a sentry node will be the validator, and optionally other sentry nodes. The sentry nodes should make sure that they do not gossip the validator's ip, to do this you must put the validators nodeID as a private peer. The unconditional peer IDs will be the validator ID and optionally other sentry nodes.
    90  
    91  > Note: Do not forget to secure your node's firewalls when setting them up.
    92  
    93  More Information can be found at these links:
    94  
    95  - <https://kb.certus.one/>
    96  - <https://forum.cosmos.network/t/sentry-node-architecture-overview/454>
    97  
    98  ### Validator keys
    99  
   100  Protecting a validator's consensus key is the most important factor to take in when designing your setup. The key that a validator is given upon creation of the node is called a consensus key, it has to be online at all times in order to vote on blocks. It is **not recommended** to merely hold your private key in the default json file (`priv_validator_key.json`). Fortunately, the [Interchain Foundation](https://interchain.io) has worked with a team to build a key management server for validators. You can find documentation on how to use it [here](https://github.com/iqlusioninc/tmkms), it is used extensively in production. You are not limited to using this tool, there are also [HSMs](https://safenet.gemalto.com/data-encryption/hardware-security-modules-hsms/), there is not a recommended HSM.
   101  
   102  Currently CometBFT uses [Ed25519](https://ed25519.cr.yp.to/) keys which are widely supported across the security sector and HSMs.
   103  
   104  ## Committing a Block
   105  
   106  > **+2/3 is short for "more than 2/3"**
   107  
   108  A block is committed when +2/3 of the validator set sign
   109  [precommit votes](https://github.com/aakash4dev/cometbft/blob/main/spec/core/data_structures.md#vote)
   110  for that block at the same `round`.
   111  The +2/3 set of precommit votes is called a
   112  [commit](https://github.com/aakash4dev/cometbft/blob/main/spec/core/data_structures.md#commit).
   113  While any +2/3 set of precommits for the same block at the same height&round can serve as
   114  validation, the canonical commit is included in the next block (see
   115  [LastCommit](https://github.com/aakash4dev/cometbft/blob/main/spec/core/data_structures.md#block)).