From 310825c63f8a58ef8a3eaa9a5eefb9fa9d54be49 Mon Sep 17 00:00:00 2001 From: ruslanglaznyov Date: Wed, 13 Dec 2023 14:20:19 +0200 Subject: [PATCH] feat: sync English --- packages/docs/pages/networks/_meta.en-US.json | 4 +- packages/docs/pages/networks/_meta.json | 4 +- .../docs/pages/operators/_meta.en-US.json | 4 +- .../docs/pages/operators/networks.en-US.mdx | 8 + .../pages/operators/networks/_meta.en-US.json | 4 + .../operators/networks/genesis-flow.en-US.mdx | 15 ++ .../networks/genesis-flow/_meta.en-US.json | 4 + .../genesis-flow/coordinator.en-US.mdx | 47 ++++ .../genesis-flow/participants.en-US.mdx | 204 ++++++++++++++++++ .../networks/local-network.en-US.mdx | 82 +++++++ .../operators/validators/_meta.en-US.json | 4 +- .../validators/validator-setup.en-US.mdx | 100 +++++++++ 12 files changed, 471 insertions(+), 9 deletions(-) create mode 100644 packages/docs/pages/operators/networks.en-US.mdx create mode 100644 packages/docs/pages/operators/networks/_meta.en-US.json create mode 100644 packages/docs/pages/operators/networks/genesis-flow.en-US.mdx create mode 100644 packages/docs/pages/operators/networks/genesis-flow/_meta.en-US.json create mode 100644 packages/docs/pages/operators/networks/genesis-flow/coordinator.en-US.mdx create mode 100644 packages/docs/pages/operators/networks/genesis-flow/participants.en-US.mdx create mode 100644 packages/docs/pages/operators/networks/local-network.en-US.mdx create mode 100644 packages/docs/pages/operators/validators/validator-setup.en-US.mdx diff --git a/packages/docs/pages/networks/_meta.en-US.json b/packages/docs/pages/networks/_meta.en-US.json index a0983e5a..d29c3ec4 100644 --- a/packages/docs/pages/networks/_meta.en-US.json +++ b/packages/docs/pages/networks/_meta.en-US.json @@ -1,4 +1,4 @@ { - "mainnets" : "Mainnets", - "testnets": "Testnets" + "mainnets" : "Основні мережі", + "testnets": "Тестові мережі" } diff --git a/packages/docs/pages/networks/_meta.json b/packages/docs/pages/networks/_meta.json index d29c3ec4..dba5b209 100644 --- a/packages/docs/pages/networks/_meta.json +++ b/packages/docs/pages/networks/_meta.json @@ -1,4 +1,4 @@ { - "mainnets" : "Основні мережі", - "testnets": "Тестові мережі" + "mainnets" : "Mainnets", + "testnets": "Testnets", } diff --git a/packages/docs/pages/operators/_meta.en-US.json b/packages/docs/pages/operators/_meta.en-US.json index 750a950d..74c5233a 100644 --- a/packages/docs/pages/operators/_meta.en-US.json +++ b/packages/docs/pages/operators/_meta.en-US.json @@ -2,9 +2,9 @@ "hardware": "Hardware requirements", "ledger": "Running a full node", "validators": "Validators", - "local-network": "Setting up a local network", + "networks": "Starting a network", "ibc": "IBC Relayers", "troubleshooting": "Troubleshooting", "eth-bridge": "Eth bridge", "hardware": "Hardware" -} +} \ No newline at end of file diff --git a/packages/docs/pages/operators/networks.en-US.mdx b/packages/docs/pages/operators/networks.en-US.mdx new file mode 100644 index 00000000..2b5710ef --- /dev/null +++ b/packages/docs/pages/operators/networks.en-US.mdx @@ -0,0 +1,8 @@ +# Starting Namada networks + +This guide will explore setting up Namada networks. + +It is broken into the following sections: + +* [Decentralised network setup](./networks/genesis-flow.mdx) +* [Local network setup](./networks/local-network.mdx) \ No newline at end of file diff --git a/packages/docs/pages/operators/networks/_meta.en-US.json b/packages/docs/pages/operators/networks/_meta.en-US.json new file mode 100644 index 00000000..fb0eb0e9 --- /dev/null +++ b/packages/docs/pages/operators/networks/_meta.en-US.json @@ -0,0 +1,4 @@ +{ + "genesis-flow": "Setting up a decentralised network", + "local-network": "Setting up a local network" +} \ No newline at end of file diff --git a/packages/docs/pages/operators/networks/genesis-flow.en-US.mdx b/packages/docs/pages/operators/networks/genesis-flow.en-US.mdx new file mode 100644 index 00000000..23901d6b --- /dev/null +++ b/packages/docs/pages/operators/networks/genesis-flow.en-US.mdx @@ -0,0 +1,15 @@ +# Setting up a decentarlised Namada network + +Setting up a decentralised Namada network requires coordination between two distinct parties: + +1. [The network coordinator](./genesis-flow/coordinator.mdx#the-network-coordinator) +2. [The pre-genesis network participants](./genesis-flow/participants.mdx#pre-genesis-network-participants) + +This process is also called the **genesis ceremony**. + + + + + + + diff --git a/packages/docs/pages/operators/networks/genesis-flow/_meta.en-US.json b/packages/docs/pages/operators/networks/genesis-flow/_meta.en-US.json new file mode 100644 index 00000000..0573abb0 --- /dev/null +++ b/packages/docs/pages/operators/networks/genesis-flow/_meta.en-US.json @@ -0,0 +1,4 @@ +{ + "coordinator": "The network coordinator", + "participants": "Pre-genesis participants" +} \ No newline at end of file diff --git a/packages/docs/pages/operators/networks/genesis-flow/coordinator.en-US.mdx b/packages/docs/pages/operators/networks/genesis-flow/coordinator.en-US.mdx new file mode 100644 index 00000000..41de6a9e --- /dev/null +++ b/packages/docs/pages/operators/networks/genesis-flow/coordinator.en-US.mdx @@ -0,0 +1,47 @@ +import { Steps } from 'nextra-theme-docs' + +## The network coordinator + +The network coordinator is responsible for: + + 0. [Setup](#setup) + 1. [Collecting pre-genesis public keys](#collecting-pre-genesis-public-keys) + 2. [Allocating pre-genesis NAM balances](#allocating-pre-genesis-nam-balances) + 3. [Collecting pre-genesis transactions](#collecting-pre-genesis-transactions) + 4. [Generating the genesis block](#generating-the-genesis-block) + +### Setup + +The genesis ceremony preperation includes creating a coordinated location for the pre-genesis network participants to submit their public keys. The network coordinator is responsible for setting up this location. Conventionally, the network coordinator will host a git repository that allows the pre-genesis network participants to submit their public keys. The network coordinator must ensure that the git repository is publicly accessible and that the pre-genesis network participants are able to submit their public keys in a secure manner. + +Further, the network coordinator is responsible for making clear timelines for the various steps in the genesis ceremony. The network coordinator must ensure that the pre-genesis network participants are aware of the timelines and that they are able to submit their public keys, transactions, and be online in due time. + + + +### Collecting pre-genesis public keys + +The ceremony begins by the network coordinator collecting the public keys of the pre-genesis network participants. The network coordinator must ensure that the total number of pre-genesis public keys collected is equal to the total number of pre-genesis network participants. + +Conventionally, the network coordinator hosts a git repository that allows the pre-genesis network participants to submit their public keys. The network coordinator must ensure that the git repository is publicly accessible and that the pre-genesis network participants are able to submit their public keys in a secure manner. + +### Allocating pre-genesis NAM balances + +Once the participants have [submitted their keys and addresses](./participants.mdx#submitting-keys-and-addresses) the network coordinator must allocate balances to these addresses/public keys. The coordinator will often have prior identity information associated with desired balances, which they will then associate with the public keys and addresses in order to set the correct balances in `balances.toml`. The coordinaotor must also ensure that the total pre-genesis NAM balances allocated to the pre-genesis network participants is equal to the total NAM supply. + +After this is completed, the network coordinator will publish the `balances.toml` file that contains the pre-genesis NAM balances allocated to the pre-genesis network participants. The `balances.toml` file should be published in the same location as the pre-genesis public keys were submitted. + + +### Collecting pre-genesis transactions + +Once the participants have [submitted their keys and addresses](./participants.mdx#submitting-keys-and-addresses) the network coordinator must collect the signed pre-genesis transactions from the pre-genesis network participants. The network coordinator must ensure that the total number of pre-genesis transaction files collected is equal to the total number of pre-genesis network participants. + +The network coordinator then aggregates these transaction files into one file and saves it as the `transactions.toml` file to be used in the generation of the genesis block. + +The `transactions.toml` file is validated by the network coordinator to ensure that each transaction has been correctly signed by each pre-genesis network participant. The network coordinator must ensure that the `transactions.toml` file is valid before proceeding to the next step. + +### Generating the genesis block + +Once the network coordinator has collected the pre-genesis public keys, allocated pre-genesis NAM balances, and collected pre-genesis transactions, the network coordinator is ready to generate the genesis block. + + + \ No newline at end of file diff --git a/packages/docs/pages/operators/networks/genesis-flow/participants.en-US.mdx b/packages/docs/pages/operators/networks/genesis-flow/participants.en-US.mdx new file mode 100644 index 00000000..1780c203 --- /dev/null +++ b/packages/docs/pages/operators/networks/genesis-flow/participants.en-US.mdx @@ -0,0 +1,204 @@ +import { Callout } from 'nextra-theme-docs' +import { Steps } from 'nextra-theme-docs' + + +## Pre-genesis network participants + +The pre-genesis network participants are the entities that are participating in the genesis ceremony. The pre-genesis network participants are responsible for: +1. [Generating their public and private keys](#generating-keys) +2. [Submitting their public keys and addresses to the network coordinator](#submitting-keys-and-addresses) +3. [Generating their pre-genesis transactions](#generating-transactions) +4. [Signing their pre-genesis transactions](#signing-transactions) +5. [Submitting their pre-genesis transactions to the network coordinator](#submitting-transactions) + + + +### Generating keys + +Before the genesis ceremony begins, the pre-genesis network participants must generate their public and private keys. The pre-genesis network participants must ensure that their private keys are kept secret and that their public keys are submitted to the network coordinator in due time. + +This can be done through the namada cli: + +```bash +ALIAS="" +namadaw --pre-genesis key gen --alias $ALIAS +``` + +After the user has entered their passwords and written down their mnemonic phrase, the namada cli will save the keys to the `pre-genesis` folder inside the [base directory](../../ledger/base-directory.mdx). + +In order to print the keys, the user can run the following command: + +```bash +# Not recommended in production since it will print the private key to the terminal (which can be recovered) +cat $BASE_DIR/pre-genesis/wallet.toml +``` + +It is the public keys that the pre-genesis network participants must submit to the network coordinator. + +```toml +# Example wallet.toml +[public_keys] +bengt = "ED25519_PK_PREFIXtpknam1qq2vscpcvhdwht9tldj9ntxnknandhnerhzd6d42xqzukw2kpcfpudh3dl2" + +... + +[addresses] +bengt = "tnam1qq97eqvv4lam8ds00j9em2s2f0r8e7r60qw9fdfq" +``` + +It is then the right hand side of each of these fields that is submitted to the network coordinator, i.e `ED25519_PK_PREFIXtpknam1qq2vscpcvhdwht9tldj9ntxnknandhnerhzd6d42xqzukw2kpcfpudh3dl2` and `tnam1qq97eqvv4lam8ds00j9em2s2f0r8e7r60qw9fdfq` in the example above. + +The network coordinator should specify the schema in which the pre-genesis network participants should submit their public keys and addresses. A toml file with the following schema is recommended: + +```toml +[] +"public-key" = "ED25519_PK_PREFIXtpknam1qpjs6jrjuu5cj508ys7ezee4r40v8as6vz4j3ddc9qm68nfhf5n7clp4xse" +"address" = "tnam1qq5skuga54tfs7422hzz8sqvk3s6lhe2dg32jjhd" +``` + +### Submitting keys and addresses + +After the network coordinator has published the location (conventionally a git repository) for the pre-genesis network participants to submit their public keys, the participants are expected to submit their generated public keys (and their corresponding addresses) to the network coordinator in due time. The deadline will be set by the network coordinator. + +### Generating transactions + +Participants are also responsible for generating the genesis-block transactions that set the initial state of the blockchain, including initialising genesis validator accounts and bonding to them. However, it is only possible to make transactions that require value once the balances of the keys become agreed upon (once the `balances.toml` file has been published). + +#### Generate an established account + +In order to generate a pre-genesis validator account, the pre-genesis network participants must first generate an established account. This can be done through the namada cli: + + +The `$ALIAS` variable is the alias of the pre-genesis keys that were generated in the [Generating keys](#generating-keys) step. + + +```bash +#Ensure $BASE_DIR is set to the base directory +TX_FILE_PATH="$BASE_DIR/pre-genesis/transactions.toml" +namadac utils init-genesis-established-account --path $TX_FILE_PATH --aliases $ALIAS + +# You can change the `--path` argument to any file path, but the recommended is `$BASE_DIR/pre-genesis/transactions.toml` +``` + +The command will ouptut the generated address of the established account. + +```text +Derived established account address: tnam1q8lsztqqhpjxdwzw88mqqc2mun7dvpxvas3v2dxk +``` + +It is useful to save this address for later use. + +```bash +ESTABLISHED_ACCOUNT_ADDRESS=tnam1q8lsztqqhpjxdwzw88mqqc2mun7dvpx +``` + +This will generate a `transactions.toml` file that contains the pre-genesis transaction that will establish the account. The `transactions.toml` file should look something like this: + +```toml +[[established_account]] +vp = "vp_user" +threshold = 1 +public_keys = ["tpknam1qr872zwdvw4u4nkpl0ykmvhyvxw7j0u6g7ymz03d7he0jr3szkuwczddjp2"] +``` + +#### Generate a pre-genesis multisignature account + +In order to generate a pre-genesis multisignature account, simply add multiple `--aliases` flags to the command: + +```bash +# Ensure $BASE_DIR is set to the base directory +# Assuming that the values of $ALIAS1, $ALIAS2, and $ALIAS3 are the aliases of the pre-genesis keys that were generated in the [Generating keys](#generating-keys) step. +TX_FILE_PATH="$BASE_DIR/pre-genesis/transactions.toml" +namadac utils init-genesis-established-account --path $TX_FILE_PATH --aliases $ALIAS1 --aliases $ALIAS2 --aliases $ALIAS3 +``` + +The command will ouptut the generated address of the multisignature account. + + +```text +Derived established account address: tnam1q8qvns6ndpff03wmszkhgepk2r8f9ws68ugktfml +``` + +The corresponding `transactions.toml` file should look something like this: + +```toml +[[established_account]] +vp = "vp_user" +threshold = 1 +public_keys = ["tpknam1qr872zwdvw4u4nkpl0ykmvhyvxw7j0u6g7ymz03d7he0jr3szkuwczddjp2", "tpknam1qpz5n0u49s6s5jx4nyycyw0w288yfq96p3lvwxkedxyw77y0vd53sqmryce"] +``` + +#### Generate a pre-genesis validator account + + +This step will require the `balances.toml` file to have been published by the network coordinator. + + +Once the pre-genesis network participants have generated respective pre-genesis established accounts, they can generate their pre-genesis validator accounts. This can be done through the namada cli: + +```bash +# Ensure $BASE_DIR is set to the base directory +# Ensure $ESTABLISHED_ACCOUNT_ADDRESS is set +# Ensure $TX_FILE_PATH is set + +EMAIL="" +SELF_BOND_AMOUNT=1000000 # Set this to the amount of NAM you want to self-bond +VALIDATOR_ALIAS="" +namadac utils init-genesis-validator \ + --address $ESTABLISHED_ACCOUNT_ADDRESS \ + --alias $VALIDATOR_ALIAS \ + --net-address "127.0.0.1:26656" \ + --commission-rate 0.05 \ + --max-commission-rate-change 0.01 \ + --self-bond-amount $SELF_BOND_AMOUNT \ + --email $EMAIL \ + --path $TX_FILE_PATH +``` + + + +The `SELF_BOND_AMOUNT` must be less than or equal to the amount of NAM allocated to the pre-genesis keys in the `balances.toml` that was published by the network coordinator. It will correspond to the self-bonded stake of the validator account at genesis. + +The `--net-address` specifies the network address of the validator node given by "IP:PORT". It is also possible to use DNS names instead of IP:PORT addresses. + +The `--alias` flag is the moniker name of the validator account. + +The `--commission-rate` and `--max-commision-rate` flags are the commission rate and the maximum permitted commission rate change of the validator account per epoch. See the validator docsfor more info. + +The `--email` flag is the email address of the validator account. This is used for the validator account to receive notifications from the network coordinator and other participants. + +The `--address` flag is the Namada address of the account. + +The `--path` flag is the path to the `transactions.toml` file that will be appended to, and requires the established account to already be initialised under. + + + +The above command will append the necessary transactions to the `transactions.toml` file. The `transactions.toml` file should look something like this: + +Successful execution will output the new validator address: + +```text +Validator account address: tnam1q8lsztqqhpjxdwzw88mqqc2mun7dvpxvas3v2dxk +``` + +### Signing transactions + +Once the `transactions.toml` file has been generated, the pre-genesis network participants must sign the transactions. This can be done through the namada cli: + +```bash +namadac utils sign-genesis-txs \ + --path $TX_FILE_PATH \ + --output $BASE_DIR/pre-genesis/signed-transactions.toml \ + --alias $VALIDATOR_ALIAS # This is only necessary if a validator account was generated, otherwise leave out the flag entirely +``` + +The above command will output a `signed-transactions.toml` file that contains the signed transactions. + + +### Submitting transactions + +Once all pre-genesis transactions have been generated and signed, the pre-genesis network participants must submit their transactions to the network coordinator in due time. The deadline will be set by the network coordinator. This will involve simply submitting the `signed-transactions.toml` file to the network coordinator at the agreed upon location. + +By convention, a directory for each pre-genesis network participant is created in the git repository. The `signed-transactions.toml` file is then submitted to the respective directory. + + diff --git a/packages/docs/pages/operators/networks/local-network.en-US.mdx b/packages/docs/pages/operators/networks/local-network.en-US.mdx new file mode 100644 index 00000000..5c2a809d --- /dev/null +++ b/packages/docs/pages/operators/networks/local-network.en-US.mdx @@ -0,0 +1,82 @@ +import Expandable from "../../../components/Expandable"; + +# Spinning up a local network + +## Prerequisites + +Namada must be installed [from source](../../introduction/install/source.mdx) in order to run a local network. + +There is a script that has been written specifically for this purpose, which can be found under `MakeFile` in the root directory. + +### Installing script dependencies + +The script has some dependencies that must be installed in order to run it successfully: + +1. python3 must be installed. +2. toml Python pip library https://pypi.org/project/toml/ must be installed. + +The script will require a set of genesis configuration files, which are TOML files that specify the parameters of the network. All of these files can be found in the `namada/genesis/localnet` directory. + +### Building wasm + +The script will also require all `wasm` files for transactions to be built. This can be done by running the following command (whilst in the namada directory): + +```shell +make build-wasm-scripts +``` + +## Running the script + +The script is called `gen_localnet.py` and can be run with the following command: + +```shell +# Ensure you are in the root of the namada repository directory +python3 ./scripts/gen_localnet.py +``` + +The script also takes a number of positional arguments that can be supplied. These are: + +```text +-h, --help show this help message and exit + --localnet-dir LOCALNET_DIR + The localnet directory containing the genesis templates. + -m MODE, --mode MODE The mode to run the localnet in. Can be release or debug, defaults to debug. + --epoch-length EPOCH_LENGTH + The epoch length in seconds, defaults to parameters.toml value. + --max-validator-slots MAX_VALIDATOR_SLOTS + The maximum number of validators, defaults to parameters.toml value. + --params PARAMS A string representation of a dictionary of parameters to update in the parameters.toml. Must be of the same format. +``` + +For example, a MacOS user would run something along the lines of: + +```bash +# Assuming pwd == root of namada repository +python3 ./scripts/gen_localnet.py \ +--localnet-dir genesis/localnet \ +--mode release # Assuming the binaries were built using `make build-release` \ +--parameters '{"parameters": {"max_expected_time_per_block": 10}, "pos_params": {"pipeline_len": "5"}}' +# In order to change max_expected_time_per_block to 10 seconds from the default 30, and the pipeline length to 5 epochs from the default 2. +``` + +### Modifying the genesis configuration file + +The genesis configuration can be modified in two ways. One is to change the contents of the toml file directly. The other is to use the `parameters` argument when running the script. The `parameters` argument takes a string representation of a dictionary of parameters to update in the parameters.toml. The format of the string must be the same as the format of the dictionary in the toml file. + +## Running the ledger + +After the script has been run, a python process will have started in the background. +The ledger can be run through the familiar command: + +```shell +./target/release/namada ledger # Assuming the binaries were built using `make build-release` +``` + +## Cleaning up + +After the local network has fulfilled its purpose, it can be cleaned up by running the following commands found in the cleanup function of the script: + +```shell copy + kilalll namadan + # delete the base_dir/chain_id directory +``` diff --git a/packages/docs/pages/operators/validators/_meta.en-US.json b/packages/docs/pages/operators/validators/_meta.en-US.json index 6efd10f5..c41995de 100644 --- a/packages/docs/pages/operators/validators/_meta.en-US.json +++ b/packages/docs/pages/operators/validators/_meta.en-US.json @@ -1,7 +1,5 @@ { - "genesis-validator-setup": "Genesis validator setup", - "run-your-genesis-validator": "Running a genesis validator", - "post-genesis-validator-setup": "Initialising a validator account", + "validator-setup": "Validator setup", "staking": "Staking", "proof-of-stake": "Proof of stake" } diff --git a/packages/docs/pages/operators/validators/validator-setup.en-US.mdx b/packages/docs/pages/operators/validators/validator-setup.en-US.mdx new file mode 100644 index 00000000..dcb991d9 --- /dev/null +++ b/packages/docs/pages/operators/validators/validator-setup.en-US.mdx @@ -0,0 +1,100 @@ +import { Callout } from 'nextra-theme-docs' + +# Setting up a validator account + +## Genesis validators + +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 + +### Method + +The method for setting up a genesis validator is described under the [pre-genesis participants](../networks/genesis-flow/participants.mdx#generate-a-pre-genesis-validator-account) section. + + +## Post-genesis validators + +Post-genesis validators are validators that become initialised after the genesis block. This is the most common way of becoming a validator, and is the method described in this section. + + +Note the use of the placeholder `aliace` for the alias parameter. This is a completely configurable parameter, and should just refer to the alias of the key/address generated. + + +### Initialising a new validator account + +The user must first generate a key pair for their validator account. + +```bash copy +KEY_ALIAS="aliace" +namada wallet key gen --alias $KEY_ALIAS +``` + +Now choose a name for your validator: + +```bash copy +export VALIDATOR_ALIAS="" +export EMAIL="" +``` + +A validator account requires additional keys compared to a user account, so start by initialising a validator account: + +```bash copy +namada client init-validator \ + --alias $VALIDATOR_ALIAS \ + --account-keys $KEY_ALIAS \ + --signing-keys $KEY_ALIAS \ + --commission-rate \ + --max-commission-rate-change \ + --email $EMAIL +``` + +It is also possible to convert an established account to a validator account: + +```bash copy +namada client become-validator \ + --address $ESTABLISHED_ACCOUNT_ADDRESS \ + --signing-keys $KEY_ALIAS \ + --commission-rate \ + --max-commission-rate-change \ + --email $EMAIL +``` + +The validator account will now have the same alias as the established account. + +When initialising a validator account, it is also mandatory to specify both the `commission-rate` charged by the validator for delegation rewards (in decimal format) as well as the `maximum-commission-rate-change` per epoch in the `commission-rate`. Both are expressed as a decimal between 0 and 1. The standard for mainnet will be set by social consensus, but for testnets, the standard has been `0.01` and `0.05`, respectively. + +This command will generate the keys required for running a validator: + +- Consensus key, which is used in [signing blocks in CometBFT](https://docs.cometbft.com/v0.37/core/validators#validator-keys). +- Validator account key for signing transactions on the validator account, such as token self-bonding, unbonding and withdrawal, validator keys, validity predicate, state and metadata updates. + +Then, it submits a transaction to the ledger that generates the new validator account with established address, which can be used to receive new delegations. + +The keys and the alias of the address will be saved in your wallet. + +### Start validating + + +**IMPORTANT** + +The local ledger node will also be setup to run this validator, you just have to shut it down with e.g. `Ctrl + C`, then start it again with the same command as before. + + +```shell copy +namadan ledger run +``` + +The ledger will then use the validator consensus key to sign blocks, should your validator account acquire enough voting power to be included in the active validator set. The size of the active validator set is limited to `128` (the limit is set by the PoS `max_validator_slots` parameter). + +Note that the balance of NAM tokens that is in your validator account does not count towards your validator's stake and voting power: + +```shell copy +namada client balance --owner my-validator --token NAM +``` + +That is, the balance of your account's address is a regular liquid balance that you can transfer using your validator account key, depending on the rules of the validator account's validity predicate. The default validity predicate allows you to transfer it with a signed transaction and/or stake it in the PoS system. Therefore, in order to increase the voting power of your validator, you need to accrue [some stake](./staking.mdx). +