From d91991adefd00acfc5186cd8a5d21bd420d5e771 Mon Sep 17 00:00:00 2001 From: bengtlofgren Date: Tue, 5 Dec 2023 16:12:42 +0000 Subject: [PATCH] unjail added and duplicate doc removed --- .../pages/operators/validators/_meta.json | 3 +- .../validators/genesis-validator-setup.mdx | 128 ------------------ .../operators/validators/proof-of-stake.mdx | 20 ++- 3 files changed, 21 insertions(+), 130 deletions(-) delete mode 100644 packages/docs/pages/operators/validators/genesis-validator-setup.mdx diff --git a/packages/docs/pages/operators/validators/_meta.json b/packages/docs/pages/operators/validators/_meta.json index 52e83075..c41995de 100644 --- a/packages/docs/pages/operators/validators/_meta.json +++ b/packages/docs/pages/operators/validators/_meta.json @@ -1,4 +1,5 @@ { "validator-setup": "Validator setup", - "staking": "Staking" + "staking": "Staking", + "proof-of-stake": "Proof of stake" } diff --git a/packages/docs/pages/operators/validators/genesis-validator-setup.mdx b/packages/docs/pages/operators/validators/genesis-validator-setup.mdx deleted file mode 100644 index a8de3b3b..00000000 --- a/packages/docs/pages/operators/validators/genesis-validator-setup.mdx +++ /dev/null @@ -1,128 +0,0 @@ -import { Callout } from 'nextra-theme-docs' - -# Genesis validator setup - -A genesis validator is one which is a validator right from the first block of the chain, i.e., at genesis. The details of genesis validators are hardcoded into the genesis file that is distributed to all users who want to interact with a chain. - -### Prerequisites - -- a machine that meets the [requirements](../hardware.mdx) for running a validator node -- an associated public IPv4 address with ports 26656 reachable from anywhere for P2P connections - -## Pre-genesis - -To setup all the [required keys](#required-keys) for a genesis validator for an upcoming network, you can execute the following command with an alias of your choice. Note that this alias is public (the address of your validator account will be visible in every wallet) and must be unique within the network. - -You must also provide a static `{IP:port}` to the `--net-address` argument of your future node's P2P address. - -### 1. Create your validator keys: - -#### Before `v0.25.0` - -``` bash -export VALIDATOR_ALIAS="CHOOSE_A_NAME_FOR_YOUR_VALIDATOR" -export PUBLIC_IP="LAPTOP_OR_SERVER_IP" -namada client utils init-genesis-validator \ - --alias $VALIDATOR_ALIAS \ - --max-commission-rate-change 0.01 \ - --commission-rate 0.05 \ - --net-address $PUBLIC_IP:26656 -``` - -#### After `v0.25.0` - -##### 1.1 Generate your keys - -``` bash -export KEY_ALIAS="CHOOSE_A_NAME_FOR_YOUR_VALIDATOR-KEY" -namadaw key gen --pre-genesis --alias $KEY_ALIAS -``` -##### 1.2 Generate your validator - - -Before pre-genesis validator tomls are collected, the public keys must first be collected, and balances given to each key. This is done by the network organizer. - - -``` bash -export VALIDATOR_ALIAS="CHOOSE_A_NAME_FOR_YOUR_VALIDATOR" -export PUBLIC_IP="LAPTOP_OR_SERVER_IP/DNS" -export BALANCE_ON_KEY="The amount of tokens allocated at genesis to the key" # For testnets, usually 1000000000 -export EMAIL="The email address for validator communications" # Required field, but can be a dummy email (although not recommended) -namada client utils init-genesis-validator \ - --source $KEY_ALIAS \ - --alias $VALIDATOR_ALIAS \ - --net-address "${PUBLIC_IP}:26656" \ - --commission-rate 0.05 \ - --max-commission-rate-change 0.01 \ - --transfer-from-source-amount $BALANCE_ON_KEY \ - --self-bond-amount 1000000 \ - --email $EMAIL -``` - -### 2. After generating your keys, the command will print something like this: - -#### Before `v0.25.0` - - -If you have set the variable $XDG_DATA_HOME this is where the pre-genesis TOML will be written to. Otherwise see below for the default locations. - - -##### Linux -```text copy -Pre-genesis TOML written to $HOME/.local/share/namada -``` - -##### MacOS -```text copy -Pre-genesis TOML written to /Users/$USER/Library/Application\ Support/Namada -``` - -#### After `v0.25.0` - -##### Linux -```text copy -Pre-genesis transactions TOML written to $HOME/.local/share/namada/pre-genesis/$VALIDATOR_ALIAS/transactions.toml -``` - -##### MacOS -```text copy -Pre-genesis transactions TOML written to /Users/$USER/Library/Application Support/Namada/pre-genesis/$VALIDATOR_ALIAS/transactions.toml -``` - -This file is the public configuration of your validator. You can safely share this file with the network's organizer, who is responsible for setting up and publishing the finalized genesis file and Namada configuration for the chain. - -Note that the wallet containing your private keys will also be written into this directory. - -### 3. You can print the validator.toml by running: - -#### Before `v0.25.0` -### Linux -```shell copy -cat $HOME/.local/share/namada/pre-genesis/$VALIDATOR_ALIAS/validator.toml -``` - -### MacOS -```shell copy -cat $HOME/Library/Application\ Support/Namada/pre-genesis/$VALIDATOR_ALIAS/validator.toml -``` - -#### After `v0.25.0` -### Linux -```shell copy -cat $HOME/.local/share/namada/pre-genesis/$VALIDATOR_ALIAS/validator-wallet.toml -``` - -### MacOS -```shell copy -cat $HOME/Library/Application\ Support/Namada/pre-genesis/$VALIDATOR_ALIAS/validator-wallet.toml -``` - -## Required keys - -- Account key: Can be used to sign transactions that require authorization in the default validator validity predicate, such as a balance transfer. -- Tendermint node key: Can be used to sign transactions on the PoS staking rewards account. -- Protocol key pair: This key is used by the validator's ledger itself to sign protocol transaction on behalf of the validator. -- DKG key: Special key needed for participation in the DKG protocol. (No longer needed after `v0.26.0`) -- Consensus key: Used in CometBFT consensus layer. Currently, this key is written to a file which is read by CometBFT. -- Eth hot key: Used for validating eth-bridge transactions. (No longer after `v0.26.0`) -- Eth cold key: Used for emergency eth-bridge operations. diff --git a/packages/docs/pages/operators/validators/proof-of-stake.mdx b/packages/docs/pages/operators/validators/proof-of-stake.mdx index 59f0c816..99fd8c78 100644 --- a/packages/docs/pages/operators/validators/proof-of-stake.mdx +++ b/packages/docs/pages/operators/validators/proof-of-stake.mdx @@ -24,4 +24,22 @@ In order to query the current epoch, the following command can be run: ```shell copy namada client epoch -``` \ No newline at end of file +``` + +## Slashing + +Validators on Namada are slashed for misbehavior. Automatic slashing conditions are defined by the CometBFT, but validators can also report misbehavior by other validators. If a validator is deemed to have misbehaved, they are slashed by a certain amount of their stake. The amount of stake slashed, as well as the time required for the slash to take effect (pipeline) is defined by protocol parameters. + +## Jailing + +Validators on Namada are jailed for either misbehaviour or for being offline for too long. If a number of blocks pass (also defined in the protocol parameters under `liveness_window_check`) in which none have been signed by the validator in question, the validator is jailed. + +When a validator is jailed, they are unable to participate in the consensus protocol. A validator is jailed for at least the pipeline amount of epochs, but must be unjailed manually by the validator. This is done by submitting an `unjail-validator` command. + +```bash +VALIDATOR_ALIAS="" +SIGNING_KEYS="" +namada client unjail-validator --validator $VALIDATOR_ALIAS --signing-keys $SIGNING_KEYS +``` + +If successful, the validator will be unjailed after the pipeline amount of epochs, and is able to participate in the consensus protocol again.