Testnet

• 1: Jailing
• 2: Q&A

1 - Jailing

TL;DR: If a validator looses sync with the blockchain, they are punished (slashed) and delegator rewards are reduced. This is an incentive for the validator to monitor and maintaining their nodes on good infrastructure.

What is Jailing?

Validators are the active actors that ensure the integrity and security of the network. Their tasks consist — in a nutshell — of validating the transactions, voting on the next state of the blockchain and committing it when a consensus is reached.

To maintain a high level of security and performance on the network, a validator is supposed to keep signing and committing blocks permanently. However, a validator can fail to commit blocks due to multiple reasons, such as a connection loss or a server failure. To protect the network, and prevent any performance drop, an inactive validator needs to be eliminated from the validator list. In Cosmos based chains this process of temporarily eliminating a validator is called “Jailing”.

When am I Jailed?

A validator is jailed when they make liveness or Byzantine fault, when a validator is jailed, it will no longer be considered as an active validator until they are un-jailed. Furthermore, it cannot be un-jailed before downtime_jail_duration. This downtime_jail_duration is a network parameter which can be configured during genesis.

Important: When a validator is jailed because of a byzantine fault, their validator public key is added to a list of permanently banned validators and cannot re-join the network as a validator with the same public key, see staking tombstone

Network Parameters

The consensus params define the conditions for Jailing.

• signed_blocks_window: Number of blocks for which the liveness is calculated for uptime tracking
• min_signed_per_window: Maximum percentage of blocks with faulty/missed validations allowed for an account in last; signed_blocks_window blocks before it gets deactivated;
• downtime_jail_duration: Duration for Jailing
• slash_fraction_double_sign: Percentage of funds being slashed when validator makes a byzantine fault
• slash_fraction_downtime : Percentage of funds being slashed when a validator is non-live.

Network Parameters Aya

These parameters are in the genesis of the Aya-Sidechain.

1
2
3
4
5

signed_blocks_window : 100
min_signed_per_window : 0.5
downtime_jail_duration :  600s
slash_fraction_double_sign: 0.05
slash_fraction_downtime: 0.01

Slashing Mechanism:

Punishments for a validator are triggered when they either make a byzantine fault or become non-live.

Liveness Faults

A validator is said to be non-live when they fail to sign at least **min_signed_per_window blocks **(in percentage) in the last signed_blocks_window blocks successfully. signed_blocks_window and min_signed_per_window are network parameters and can be configured during genesis and can be updated during runtime by the governance module.

For example, if block_signing_window is 100 blocks and min_signed_per_window is 0.5, 
validator will be marked as non-live and jailed
if they fail to successfully sign at least 100*0.5=50 blocks
in last 100 blocks.

When a validator fails to successfully sign missed_block_threshold blocks in last block_signing_window blocks, it is immediately jailed and punished by deducting funds from their bonded and unbonded amount and removing them from active validator set. The funds to be deducted are calculated based on slash_fraction_downtime.

Byzantine Faults

A validator is said to make a byzantine fault when they sign conflicting messages/blocks at the same height and round. Tendermint has mechanisms to publish evidence of validators that signed conflicting votes so they can be punished by the slashing module. For example:

Validator who votes for two different blocks within a single round (“Equivocation validator”/ “Double signing”);

Validator who signs commit messages for arbitrary application state ( “Lunatic validator”).

The evidence of a set of validators attempting to mislead a light client can also be detected and captured. However, even the Amnesia attack can be detected, punishment can not be applied at this stage, as we can not deduce the malicious validators.

Un-jailing

When a jailed validator wishes to resume normal operations (after downtime_jail_duration has passed), they can create anunjail transaction which marks them as un-jailed. Validator will then rejoin the validator set once it has been successful un-jailed

If the slashing mechanism is reducing your stake/voting power to zero you cannot unjail. In this case it is needed to increase your unslashed stake to regain voting power

Commands to unjail

1

ayad tx slashing unjail --from <aliasOfYourAccount> --home /opt/aya

aliasOfYourAccount is the account name you used when installing the validator. The -a argument.

If you cannot unjail due to zero stake you first need to self-delegate the additional token we sent to you before performing the unjailing

1

ayad tx staking delegate <validatorAddress(the ayavaloper one)> 1uswmt --home /opt/aya/ --from aliasOfYourAccount

How can I find my validator address?

You can easily get the validator address using the Nodebase tool script showkeys.sh, located here

Source

https://crypto.org/docs/chain-details/module_slashing.html#overview slashing module | Crypto.org Chain

2 - Q&A

I don’t have a cosmovisor service?

The cosmovisor service is a daemon process to keep your node running. When the ayad process would exit, the service would automatically restart. So it has a vital function to keep your validator running healthy.

The cosmovisor service is installed during the node installation (install_node.sh), after your registered your node with the ENNFT. If you failed to register the node, and stopped the installation script, the installation didnt complete.

You can still register the ENNFT following the published instructions, but the cosmovisor service you would need to configure manually.

ayafix.sh is also part of the nodebase tools

Or you can install it manually from here as follows:

1. copy the content below to a file ex. ayafix.sh
2. chmod +x ayafix.sh
3. sudo ./ayafix.sh

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

#!/usr/bin/env bash

aya_home=/opt/aya

echo -e "-- Configuring your node to start on server startup\n"
sudo ln -s $aya_home/cosmovisor/current/bin/ayad /usr/local/bin/ayad >/dev/null 2>&1
sudo ln -s $aya_home/cosmovisor/cosmovisor /usr/local/bin/cosmovisor >/dev/null 2>&1

sudo tee /etc/systemd/system/cosmovisor.service > /dev/null <<EOF
[Unit]
Description=Aya Node
After=network-online.target

[Service]
User=$USER
ExecStart=$(which cosmovisor) run start --home "$aya_home" &>>"$aya_home"/logs/aya.log
Restart=always
RestartSec=3
LimitNOFILE=4096

Environment="/opt/aya"
Environment="DAEMON_NAME=ayad"
Environment="DAEMON_DATA_BACKUP_DIR=/opt/aya/backup"
Environment="DAEMON_ALLOW_DOWNLOAD_BINARIES=true"
Environment="DAEMON_RESTART_AFTER_UPGRADE=true"
Environment="DAEMON_HOME=/opt/aya"
[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable cosmovisor

What is my validator address?

The validator address is a function of the validator’s public key, which is used to sign prevotes and precommits.

Cosmos uses a bech32 encoded validator address, which is a more human-readable version of the same public key.

To retrieve your node’s address you can use our script addresses.sh in tools or do it manually as follows.

1
2

ayad keys list --home /opt/aya
Enter keyring passphrase:

The output will look like:

1
2
3
4

- address: aya1fnxullwf0r72hlmjyyuhjca23pl09a7rf5f752
  name: EarthNodeChile
  pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"A7tC1Yexx3ithv611VdPEySAffVP6nqTNvN9iKX1buMr"}'
  type: local

With the address get the HEX presentation of it

1

ayad keys parse aya1fnxullwf0r72hlmjyyuhjca23pl09a7rf5f752 --home /opt/aya

1
2

bytes: 4CCDCFFDC978FCABFF7221397963AA887EF2F7C3
human: aya

Now parse the HEX address to get all bech32 representations

1

ayad keys parse 4CCDCFFDC978FCABFF7221397963AA887EF2F7C3 --home /opt/aya

The third entry with prefix ayavaloper is your validator address

1
2
3
4
5
6
7

formats:
- aya1fnxullwf0r72hlmjyyuhjca23pl09a7rf5f752
- ayapub1fnxullwf0r72hlmjyyuhjca23pl09a7rklpry4
- ayavaloper1fnxullwf0r72hlmjyyuhjca23pl09a7re7t8j5
- ayavaloperpub1fnxullwf0r72hlmjyyuhjca23pl09a7rng04ad
- ayavalcons1fnxullwf0r72hlmjyyuhjca23pl09a7rddcm74
- ayavalconspub1fnxullwf0r72hlmjyyuhjca23pl09a7rzv5ahu

How to add a profile image to your validator for WM Explorer?

Written by Nodebase Team member Gertjan

1. Go to the website https://keybase.io
2. Create an account. This can be done by going to “Login” and after that choosing for “Join Keybase”
3. Test if your account is working properly
4. Logout of your account. On the home page of Keybase click the button “Install”
5. Select the correct operating system and install the software
6. Start the Keybase client on you computer and login with the account you created in step 2
7. Change your profile image. This is the image that will show up in WM Explorer as your validator image
8. Create a PGP key by selecting “Add a PGP key”
9. Choose “Get a new PGP key”
10. Fill in the form and click “Let the math begin”
11. Click on the button “Done” in the dialog after
12. You can now see a 16 character PGP key
13. On your validator run the following command:

1

ayad tx staking edit-validator --identity="16 character PGP key" --from <operator name> --home /opt/aya/

14. A transaction hash (txhash) is returned. Check in WM Explorer if the transaction was successful. If not, run the command in step 13 again
15. After a successful transaction, your profile image will appear in WM Explorer