Это пошаговое руководство по настройке Вашей полноценной ноды, что позволит Вам приступить к работе в качестве Валидатора в последнем Тестнете Joystream.
- Обзор
- Инструкции
- На Вашей машине
- В приложении Pioneer (браузер)
- Advanced
- Rewards
- Slashing
- Troubleshooting
Эта страница содержит всю информацию о том, как настроить свою ноду и стать Валидатором
в тестовой сети Joystream. Данное руководство будет обновляться с целью улучшения содержания или когда будут измения в новых релизах тестовой сети.
Если Вы хотите заработать больше токенов tJOY
, но по какой-то причине не можете или не хотите стать Валидатором
, Вы можете вместо этого Номинировать
.
Приведенные ниже инструкции относятся к Mac и Linux (64-разрядная версия и armv7) платформе. Двоичные файлы для операционной системы Windows в настоящее время недоступны.
Примечание
Если Вы просто запускаете ноду и не хотите быть Валидатором
, Вы можете не использовать флаги
--pruning archive
и --validator
- Каждый раз, когда что-то написано в
<скобках>
, это означает, что вы должны заменить данный блок своими значениями без<>
. - Когда что-то написано в
"двойных_кавычках"
, это означает, что количество/данные будут варьироваться в зависимости от Вашего узла или текущего состояния блокчейна. - Для команд в командной строке,
$
означает, что Вы должны ввести команду, после данного символа.#
Говорит о том, что это просто комментарий/некое описание, и его нельзя вводить.
# Это просто комментарий, не вводите и не вставляйте его в командную строку!
$ cd ~/
# Введите/вставьте только "cd ~ /", символ $ копировать не нужно!
Откройте командную строку (Приложения->Утилиты):
$ cd ~/
$ wget https://github.com/Joystream/joystream/releases/download/v7.5.0/joystream-node-3.3.0-fdb75f5ec-x86_64-macos.tar.gz
$ wget https://github.com/Joystream/joystream/releases/download/v7.5.0/joy-testnet-4.json
----
# Если у Вас не установлен wget, скопируйте ссылку и загрузите файл через браузер.
# Проположительно, что он будет сохранён в папке ~/Downloads:
$ mv ~/Downloads/joystream-node-3.3.0-fdb75f5ec-x86_64-macos.tar.gz ~/
---
$ tar -vxf joystream-node-3.3.0-fdb75f5ec-x86_64-macos.tar.gz
$ ./joystream-node --chain joy-testnet-4.json --pruning archive --validator
- Если Вы хотите, чтобы Ваш узел имел неслучайный идентификатор, добавьте флаг
--name <nodename>
- Если Вы хотите получить более подробный вывод журнала событий, добавьте флаг
<имя узла> --log runtime
Теперь Ваш узел должен начать блокчейн синхронизацию. Результат должен выглядеть так:
Joystream Node
version "Version"-"your_OS"
by Joystream, 2019-2020
Chain specification: "Joystream Version"
Node name: "nodename"
Roles: AUTHORITY
Initializing Genesis block/state (state: "0x…", header-hash: "0x…")
Loading GRANDPA authority set from genesis on what appears to be first startup.
Loaded block-time = BabeConfiguration { slot_duration: 6000, epoch_length: 100, c: (1, 4), genesis_authorities: ...
Creating empty BABE epoch changes on what appears to be first startup.
Highest known block at #0
Local node identity is: "peer id"
Starting BABE Authorship worker
Discovered new external address for our node: /ip4/"IP"/tcp/30333/p2p/"peer id"
New epoch 0 launching at block ...
...
...
Syncing, target=#"block_height" ("n" peers), best: #"synced_height" ("hash_of_synced_tip"), finalized #0 ("hash_of_finalized_tip"), ⬇ "download_speed"kiB/s ⬆ "upload_speed"kiB/s
Обратите внимание на последнюю строку target=#"block_height"
и best: #"synced_height"
где target=#block_height
имеет тоже самое значение что и best: #"synced_height"
, это значит Ваш узел полностью синхронизирован!
Не закрывайте консоль.
Теперь Вам нужно сгенерировать свои ключи. Перейдите сюда
Пришло время настроить ключи, чтобы начать валидацию. Перейдите сюда для настройки вашего Валидатора
.
- Каждый раз, когда что-то написано
<скобках>
, это означает, что вы должны заменить данный блок своими значениями без<>
. - Когда что-то написано в
"двойных_кавычках"
, это означает, что количество/данные будут варьироваться в зависимости от Вашего узла или текущего состояния блокчейна. - Для команд в командной строке:
$
означает, что Вы должны ввести команду, после данного символа#
Говорит о том, что это просто комментарий/некое описание, и его нельзя вводить.
# Это просто комментарий, не вводите и не вставляйте его в командную строку!
$ cd ~/
# Введите/вставьте только "cd ~ /", символ $ копировать не нужно!
Откройте командную строку:
$ cd ~/
# 64 bit debian based Linux
$ wget https://github.com/Joystream/joystream/releases/download/v7.5.0/joystream-node-3.3.0-fdb75f5ec-x86_64-linux-gnu.tar.gz
$ tar -vxf joystream-node-3.3.0-fdb75f5ec-x86_64-linux-gnu.tar.gz
# armv7 (eg. raspberry pi)
$ wget https://github.com/Joystream/joystream/releases/download/v7.5.0/joystream-node-3.3.1-arm-v7.tar.gz
$ tar -vxf joystream-node-3.3.1-arm-v7.tar.gz
# Для обеих
$ wget https://github.com/Joystream/joystream/releases/download/v7.5.0/joy-testnet-4.json
$ $ ./joystream-node --chain joy-testnet-4.json --pruning archive --validator
- Если Вы хотите, чтобы Ваш узел имел неслучайный идентификатор, добавьте флаг
--name <nodename>
- Если Вы хотите получить более подробный вывод журнала событий, добавьте флаг
<имя узла> --log runtime
Теперь Ваш узел должен начать блокчейн синхронизацию. Результат должен выглядеть так:
Joystream Node
version "Version"-"your_OS"
by Joystream contributors, 2019-2020
Chain specification: "Joystream Version"
Node name: "nodename"
Roles: AUTHORITY
Initializing Genesis block/state (state: "0x…", header-hash: "0x…")
Loading GRANDPA authority set from genesis on what appears to be first startup.
Loaded block-time = BabeConfiguration { slot_duration: 6000, epoch_length: 100, c: (1, 4), genesis_authorities: ...
Creating empty BABE epoch changes on what appears to be first startup.
Highest known block at #0
Local node identity is: "peer id"
Starting BABE Authorship worker
Discovered new external address for our node: /ip4/"IP"/tcp/30333/p2p/"peer id"
New epoch 0 launching at block ...
...
...
Syncing, target=#"block_height" ("n" peers), best: #"synced_height" ("hash_of_synced_tip"), finalized #0 ("hash_of_finalized_tip"), ⬇ "download_speed"kiB/s ⬆ "upload_speed"kiB/s
Обратите внимание на последнюю строку target=#"block_height"
и best: #"synced_height"
где target=#block_height
имеет тоже самое значение что и best: #"synced_height"
, это значит Ваш узел полностью синхронизирован!
Не закрывайте консоль.
Теперь Вам нужно сгенерировать свои ключи. Перейдите сюда
Пришло время настроить ключи, чтобы начать валидацию. Перейдите сюда для настройки вашего Валидатора
.
Пока узел синхронизируется, Вы можете начать процесс настройки остальных компонентов.
- Перейдите в Приложение Pioneer, и выбирете
Мои ключи
на боковой панели. Нажмите кнопкуДобавить аккаунт
.
Имена не обязательны, но следующие шаги будут проще, если Вы будете следовать предложенной системе.
- Для простоты использования, назовите свою первую пару ключей "stash", или хотя бы что-то, что содержит слово.
Если в будущем Вы хотите иметь возможность восстановить свои ключи, запишите свою мнемоник фразу, тип криптопары ключей и порядок слов.
-
В зависимости от Вашего браузера Вам может потребоваться подтвердить сохранение json файла.
-
Повторите процесс для Вашего "controller" ключа.
Теперь у Вас должно быть два набора ключей, а именно:
- ключ "stash", который будет учавствовать с тейкинге ваших средств
- ключ "controller", который Вы будете использовать для работы с Вашей учётной записью валидатора
-
Если у Вас уже есть токены, переведите их основную часть на свой "stash" аккаунт. Если у Вас еще нет монет на счету, запросите их в Discord чате, чтобы получить их :)
-
Отправьте хотя бы 1 токен на свой аккаунт "controller"
Чтобы стать Валидатором
, Вам нужно выполнить стейкинг Ваших токенов. Обратите внимание, что Вам, возможно, придется обновить браузер, если Вы не видите параметры сразу.
ВАЖНО: Внимательно прочтите шаг 6. Перед переходом к шагу 7 ваш узел должен быть полностью синхронизирован.
- В командной строке Вашей машины/VPS, на котором запущена нода, вставьте следующую строку:
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933
Если Ваша нода запущена, то команда должна вернуть следующий вывод:
{"jsonrpc":"2.0","result":"0xa0very0long0hex0string","id":1}
Это сохранит ключи сеанса на вашем узле. Убедитесь, что Вы не закрыли окно перед копированием строки 0xa0very0long0hex0string
.
Если Ваш нода не запущена, работает на другом порту, или не установлена curl
утилита, Вам будет возвращён следующий вывод:
curl: (7) Failed to connect to localhost port 9933: Connection refused
# или
{"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found"},"id":1}
- Вернитесь в Pioneer, нажмите на иконку
Validators
на боковой панели, а затем вкладкуДействия с аккаунтом
. - Нажмите кнопку
+ Stash
, и выберите ключи из первых двух раскрывающихся списков. - В третьем поле введите сумму, которую Вы хотите застейкать (это должна быть максимальная сумма монет на счету -1 монета).
- В нижнем раскрывающемся списке выберите пункт - назначение платежа. Ваш выбор здесь зависит от Ваших предпочтений.
- Если транзакция пройдёт успешно, Вы должны будете увидеть кнопку
Установить ключ сессии
рядом с ключами "stash" и "controller". Нажмите на неё, вставьте в поле свою0xa0very0long0hex0string
строку, и затем подтвердить. - Если транзакция пройдёт успешно, Вы должны увидеть вместо нее кнопку
Валидатор
. Нажмите на нее и установитепроцент вознаграждения
, число от 0 до 100. Ваш вклад здесь зависит от ваших предпочтений. "Высокое" значение, будет означать что у Вас меньше шансов получить Номинаторов.
Обновите браузер и выберите вкладку Ожидание
. Если Ваша учетная запись отображается на вкладке назначения
, дождитесь следующей эры
, и Вы будете перемещены в список валидаторов
(на вкладке Обзор Стейкинга
).
Если Вы не хотите рисковать, чтобы получить штраф, Вам нужно плавно
остановить валидацию.
This can be done easily in Pioneer
- Click
Validators
in the sidebar, then choose theAccount actions
tab. - Click the "Stop" button to the right, and confirm.
- Once you are dropped from the Validator set (can take up to 70min), you can safely stop your node.
If you are running your node on a Linux and want to run it as a service, you can set it up this way. Note that you should avoid this unless you know what you are doing, are running your node on your own VPS or a single board computer. With great (sudo) privileges, comes great responsibilities!
If you are already running as a validator
, consider unstaking first, as you may experience some downtime if you make any mistakes in the setup.
Either as root, or a user with sudo privileges. If the latter, add sudo
before commands.
$ cd /etc/systemd/system
# you can choose whatever name you like, but the name has to end with .service
$ touch joystream-node.service
# open the file with your favorite editor (I use nano below)
$ nano joystream-node.service
The example below assumes the following:
- You want to restart your node every 24h (
86400
s) - You have setup a user
joystream
to run the node - The path to the
joystream-node
binary is/home/joystream/joystream-node
[Unit]
Description=Joystream Node
After=network.target
[Service]
Type=simple
User=joystream
WorkingDirectory=/home/joystream/
ExecStart=/home/joystream/joystream-node \
--chain joy-testnet-4.json \
--pruning archive \
--validator \
--name <nodename>
Restart=on-failure
RestartSec=3
LimitNOFILE=8192
[Install]
WantedBy=multi-user.target
The example below assumes the following:
- You want to restart your node every 24h (
86400
s) - You have setup a user
root
to run the node - The path to the
joystream-node
binary is/root/joystream-node
[Unit]
Description=Joystream Node
After=network.target
[Service]
Type=simple
User=root
WorkingDirectory=/root/
ExecStart=/root/joystream-node \
--chain joy-testnet-4.json \
--pruning archive \
--validator \
--name <nodename>
Restart=on-failure
RestartSec=3
LimitNOFILE=8192
[Install]
WantedBy=multi-user.target
You can add/remove any flags
as long as you remember to include \
for every line but the last. Also note that systemd is very sensitive to syntax, so make sure there are no extra spaces before or after the \
.
After you are happy with your configuration:
$ systemctl daemon-reload
# this is only strictly necessary after you changed the .service file after running, but chances are you will need to use it once or twice.
# if your node is still running, now is the time to kill it.
$ systemctl start joystream-node
# if everything is correctly configured, this command will not return anything.
# To verify it's running:
$ systemctl status joystream-node
# this will only show the last few lines. To see the latest 100 entries (and follow as new are added)
$ journalctl -n 100 -f -u joystream-node
# To make the service start automatically at boot:
$ systemctl enable joystream-node
You can restart the service with:
systemctl restart joystream-node
If you want to change something (or just stop), run:
systemctl stop joystream-node
Before you make the changes. After changing:
$ systemctl daemon-reload
$ systemctl start joystream-node
If you make a mistake somewhere, systemctl start joystream-node
will prompt:
Failed to start joystream-node.service: Unit joystream-node.service is not loaded properly: Invalid argument.
See system logs and 'systemctl status joystream-node.service' for details.
Follow the instructions, and see if anything looks wrong. Correct it, then:
$ systemctl daemon-reload
$ systemctl start joystream-node
If you don't want to use the default settings, here are some of the options you can configure.
The bonding preferences decide on how your (tJOY) staking rewards are distributed. There are three alternatives:
Stash account (increase the amount at stake)
(default).
This automatically sends all rewards the stash
address, where it gets bonded as additional stake. This will increase your probability of staying in the validator
set.
Stash account (do no increase the amount at stake)
As for 1. this automatically sends all rewards the stash
address, but does not get bonded as stake, meaning you it will not help "guard" your spot in the validator
set.
Controller account
This sends all rewards to the controller
, at your disposal.
The reward commission
determines how the (tJOY) staking rewards are split between yourself and any potential nominators. The default - 0(%) - means that the reward is split based on the amount of bonded stake the validator
and nominators
have put up. Example:
- Let
v
be the bonded tokens by the validatorsstash
key - Let
c
be thereward commission
decided by the validator - Let
n1
be the bonded tokens by the nominator1stash
- Let
n2
be the bonded tokens by the nominator2stash
- Let
r
be the reward for the individual validators thatera
# payout for the validator
c*r + r*(1 - c)*v/(v + n1 + n2)
# payout for the nominator1
r(1 - c) * n1/(v + n1 + n2)
- assume there are 10 active validators in this era
- validator 1 bonds 100,000 tJOY
- validators 2-10 all bonds 300,000tJOY
- validator 1 has
reward commission
set to 10% - nominator A bonds 100,000 tJOY, and nominates validator 1
- nominator B bonds 50,000 tJOY, and nominates validator 1
- thus, validator A has an effective stake of 250,000 tJOY
- after the end of the era, the total rewards are 25,000 tJOY
# All validators gets an equal share, before sharing with nominators:
R_v = 25,000tJOY / 10 = 2,500tJOY
# payout for validator 1
R_v.1 = 0.1 * 2,500tJOY + 2,500tJOY *(1 - 0.1) * (100,000tJOY / 250,000tJOY) = 1,150tJOY
# payout for nominator A
R_n.A = 2,500tJOY *(1 - 0.1) * (100,000tJOY / 250,000tJOY) = 900tJOY
# payout for nominator B
R_n.B = 2,500tJOY *(1 - 0.1) * (50,000tJOY / 250,000tJOY) = 450tJOY
As the Validator carries the cost of operating and maintaining their nodes, it makes sense for them to take a slice of the pie before sharing.
If you want to get some return on your tokens without running a node yourself, you can nominate
another validator
and get a share of their rewards.
This might also come in handy if there are too many validators
and you don't have enough tokens get a spot, or if you have to shut down your own node for a while.
- Go to the Pioneer App, and select
My keys
in the sidebar. Click theAdd account
button.
Names are entirely optional, but the next steps will be easier if you follow the system suggested.
- For ease of use, name your first keypair "stash", or at least something that contains the word.
If you want to be able to recover your keys later, write down your mnemonic seed, key pair crypto type and secret derivation path.
-
Depending on your browser, you might have to confirm saving the json file.
-
Repeat the process for your "controller" key.
You should now have two sets of keys, namely:
- the "stash" key that will stake your funds
- the "controller" key that you will use to operate your validator
-
If you already have tokens, transfer the bulk to your "stash" account. If you don't yet have any tokens, ask in the Discord chat, and you shall receive :)
-
Send at least 1 token to your "controller".
In order to be a Nominator
, you need to stake. Note that you may have to refresh your browser if you're not seeing the options right away.
- In Pioneer, click
Validators
in the sidebar, and then theAccount actions
tab. - Click the
+ Stash
button, and select the keys from the first two dropdowns. - In the third field, enter the amount you want to stake (the maximum amount is the tokens in the account -1).
- In the bottom dropdown, select the payment destination. Your selection here depends on your preferences.
- If the transaction goes through, you should now see a
Nominate
button next to your "stash" and "controller" keys in this window. Click it, and select the "stash" account(s) of theValidator(s)
you want toNominate
for. - Once submitted, you will start earning a share of the rewards.
Rewards are the most critical part of any blockchains infrastructure, block production, whether it's from Proof of Work (using miners, e.g. Bitcoin) or Proof of Stake (using validators, like Joystream). Validators are rewarded for producing, propagating and securing the network.
Rewards are no longer paid out automatically to the validators, and it must be done manually. We have made it so you have ~2 weeks to claim your rewards, but after that, they can no longer be claimed.
This was not a voluntary decision from Jsgenesis, but part of the new staking module from Substrate. The reason is simply that if your validator set is very large and with a lot of nominators (which will be the case for many Substrate based chains), every payout would require a lot of transactions. By instead making it manual, this will be spaced out.
Note: Claiming rewards for a specific Validator can be done by anyone, not just the Validator themselves. However, only the Validator (and Nominator) can batch up multiple claims in one bulk.
This can only be done if you have the keys for the Validator or Nominator you want to claim for:
In the UI, Validators can claim rewards in "bulks" of 40 eras
at the time:
- In Pioneer, click
Validators
in the sidebar, and then thePayouts
tab - Make sure the
Max, x eras
are selected - At the bottom of the page, all your you will see an overview of:
- which
eras
you can claim rewards for - the total amount
available
you are "owed" - the time
remaining
to claim (your "oldest") reward
- Click the
Payout
button at the right end of the row, and confirm to claim the "oldest" 40era
rewards for you, and any potential Nominators that has claim to some of your rewards - If you have more than 40
eras
, you can repeat this after the first transaction is complete
Note:
- If a Validator had any Nominator(s) in the
eras
for which they claim rewards, the Nominator(s) will automatically get their rewards for saideras
- A Nominator that claims rewards for multiple
eras
, the Validator(s) they nominated in saideras
will automatically also get their rewards.
This can be done by any account:
- Go to the extrinsics tab
- Select
staking.payoutStakers(validator_stash, era)
- Select/paste the address of the
stash
account you want to claim on behalf of/for - Type in the
era
you want to claim for, and submit
To find out if a "stash" have claimed reward(s) from era(s)
:
- chain state query of
ledger(AccountId): Option<StakingLedger>
with the any current, or "historic" controller. Output:
{
stash: 5YourStashAddress,
total: <tot_bonded> JOY,
active: <act_bonded> JOY,
unlocking: [],
claimedRewards: [
<era_a>,
<era_b>,
...
<era_i>,
]
}
Note:
To understand what unlocking
means, go here.
For Substrate based blockchains, the validator rewards depends on some dynamic parameters, that will change continuously, and some fixed parameters in the chain spec.
- Active validators (
V_a
) - the number ofvalidators
currently running. This can be found:
- in the Validators tab -> validator (
V_a
/V_i
) - or through a chain state query of
session.validators()
(and count them)
- Max/Ideal validators
V_i
- the max number of active validators. This number can be changed through proposals, but was initially set to 20. Current value can be found:
- in the Validators tab -> validator (
V_a
/V_i
) - or through a chain state query of
staking.validatorCount()
- Issuance
I
- total tJOY tokens in circulation. This can be found:
- in the explorer tab
- or through a chain state query of
balances.totalIssuance()
- Validator stake (
S_v
) - ie. the total stake of thevalidators
set, corresponding to the sum of the stakes of eachvalidator
, plus the stake of their nominators if any. This can be found:
- in the staking tab (alongside
I
, and the percentage ofS_v / I
- also known as the Active staking ratio,S_v,ar
, see 5.) - or through a chain state query of
staking.erasTotalStake(<EraIndex>)
- the
<EraIndex>
can be found bystaking.activeEra()
- the
- Active staking ratio,
S_v,ar
- the current ratio of tokens staked by active validators (and their nominators) and the issuance. SoS_v,ar = S_v / I
- Minimum inflation,
I_min
- the min yearly inflation distributed to validators.
- This number is currently set to
5%
.
- Maximum inflation,
I_max
- the max yearly inflation distributed to validators.
- This number is currently set to
75%
.
- Ideal staking ratio,
S_v,ir
- the ideal ratio of effective stake over issuance for maximum validator rewards.
- This number is currently set to
25%
.
- Falloff,
F_v
- how quickly the validator rewards drop when the actual staking rateS_v,ar
exceeds the ideal staking rateS_v,ir
.
- This number is currently set to
5%
.
- Sessions,
session_l
- eachsession
(orepoch
) should last ~10 minutes / 100 blocks*
- Era length,
era_l
- eachera
lasts 60 minutes should last 6sessions
-> ~60 minutes / 600 blocks*
*
For a variety of reasons (such as latency, validators going down, etc.) anera
can be as little as 1session
and asession
can be a lot fewer blocks than 100.
At the end of each era, a new set of active validators V_a
is determined by sorting all those that have declared their intention (eg. both the active and next up) by their stake, and selecting up to V_i
in a descending order.
Those selected are treated as equals, and will have the same chance of being selected to produce blocks and thus get an equal share of the rewards. Slashes however, are applied as a percentage of stake, so a validator with more stake risks getting slashed more despite earning the same.
As shown, the maximum total validator reward per year is 75% for S_v,ar = S_v,ir = 0.25
. With an era length of 600 blocks, each era, the maximum total, R_vm,te
and individual, R_vm,ie
reward for the validators are:
Note For all calculations, we assume there are (365.2425×24×60×60s)/year.
R_vm,te = I * I_max * era_l / year
= I * 0.75 * 3600s / (31556952s)
= 0.0000855596*I
R_vm,ie = R_vm,te / V_a
= 0.0000342238*I/V_a
For S_v,ar<S_v,ir
, the total rewards drop linearly down to the minimum inflation rate I_min
for S_v,ar = 0
For S_v,ar>S_v,ir
, the total rewards drop exponentially down to the minimum inflation rate for I_min
S_v,ar = 1
.
The exact formulae:
R_v,te = I * (I_min + (I_max - I_min) * 2^((S_v,ir − S_v,ar) / F_v)) * era_l / year
The tJOY rewards for the validators can be calculated using this spreadsheet. The examples below should assist in using it:
In addition to the fixed parameters above, suppose:
V_a = 20
I = 100,000,000tJOY
S_v = 25,000,000tJOY
As S_v / I = 0.25
, meaning S_v,ar = S_v,ir
the maximum yearly inflation rate I_max = 75%
will be shared among the validators. Each era, the total, R_v,te
and individual, R_v,ie
reward for the validators are:
R_v,te = I * I_max * era / year
= 100,000,000tJOY * 0.75 * 3600s / (31556952s)
= 8,556tJOY
R_v,ie = R_v,te / V_a
= 8,556tJOY / 20
= 428tJOY
In addition to the fixed parameters above, suppose:
V_a = 20
I = 100,000,000tJOY
S_v = 20,000,000tJOY
With S_v / I = 0.2
. Each era, the total, R_v,te
and individual, R_v,ie
reward for the validators are:
R_v,te = I * (I_min + (I_max - I_min) * S_v,ar / S_v,ir) * era_i / year
= 6,959tJOY
R_v,ie = R_v,te / V_a
= 6,959tJOY / 20
= 348tJOY
In addition to the fixed parameters above, suppose:
V_a = 20
I = 100,000,000tJOY
S_v = 30,000,000tJOY
With S_v,t=S_v,eff/I=0.3
. Each era, the total, R_v,te
and individual, R_v,ie
reward for the validators are:
R_v,te = I * (I_min + (I_max - I_min) * 2^((S_v,ir − S_v,ar) / F_v)) * era_l / year
= 4,563tJOY
R_v,ie = R_v,te / V_a
= 4,563tJOY / 20
= 228tJOY
As seen above, the difference from staking 5% more or less than the ideal, is quite substantial.
- By staking 5% less, the "loss" is only 18% (6,959tJOY vs 8,556tJOY)
- By staking 5% more, the "loss" is instead 47% (4,563tJOY vs 8,556tJOY)
More information on the staking, rewards and slashing mechanics can be found on the Web3 Foundation's research papers here.
Just as the Validators are rewarded for producing, propagating and securing the network, they are punished for misbehaving. The slashing mechanics are more complex, so it will not be covered as detailed as the rewards.
Although there are other reasons for getting slashed as a Validator, the reasons that stem from intentional malicious behavior will not be covered here. If you want to learn more about the details of slashing, visit this guide from the Polkadot wiki guide on slashing (and staking).
The most likely reason a Validator will get slashed is for going offline without first stopping gracefully.
If n
Validators go offline, there will be an two "events" at the end of that session
:
imOnline:SomeOffline
offences.Offence
Suppose we have two Validators offline, - v_0
and v_1
. v_1
has one nominator n_1
(all accountId
/address of their "stash"):
By selecting the block the event occured in the explorer, it will appear like so:
1 imOnline:SomeOffline
:
At the end of the session, at least one validator was found to be offline.
Vec<IdentificationTuple>
0: IdentificationTuple: IdentificationTuple
[
<v_0>,
{
total: <v_0 stake> JOY,
own: <v_0 stake> JOY,
others: []
}
]
1: IdentificationTuple: IdentificationTuple
[
<v_1>,
{
total: <v_1+n_1 stake> JOY,
own: <v_1> JOY,
others: [
{
who: <n_1>,
value: <n_1 stake> JOY,
}
]
}
]
This identities which valididators are reported "offline".
2 offences.Offence
:
There is an offence reported of the given `kind` happened at the `session_index` and (kind-specific) time slot. This event is not deposited for duplicate slashes. last element indicates of the offence was applied (true) or queued (false).
Kind
im-online:offlin
OpaqueTimeSlot
0xsomething
bool
<Yes> or <No>
The key here is whether bool
is Yes
(true
) or No
(false
).
- If
Yes/true
, this means a slash will be applied. - If
No/false
, this means no slash will be applied.
The magnitude of the slash (and whether one will be applied at all), depends on the max number of Validator slots allowed (V_max
), and the number of Validators reported offline V_off
.
- If
V_off / V_max
< 1/10- No slash will be applied
- If
V_off / V_max
> 1/3- A max slash of 7% is initiated
*
- A max slash of 7% is initiated
The exact formula, from the comment in the codebase, is presented below (with variables changed for clarity):
// the formula is min((3 * (V_off - (V_max / 10 + 1))) / V_max, 1) * 0.07
// basically, 10% can be offline with no slash, but after that, it linearly climbs up to 7%
// when 13/30 are offline (around 5% when 1/3 are offline).
*
A single Offence
adds an entry to the Validators slash span
. The actual slashing (burning) of tokens will happen ~24h hours later. For more info, we again refer to the Polkadot Wiki
If you had any issues setting it up, you may find your answer here!
Due to an unfortunate error in Pioneer which we are working to fix, unstaking requires either lots of patience, or using the chain state/extrinsics tab for certain tasks:
If you stop validating by killing your node before unstaking, you will get slashed and kicked from the Validator
set. If you know in advance (it can take up to 70min) you can do the following steps instead:
- In
Validator -> Account Actions
, clickStop
.
If you are just pausing the validator
and intend to start it up later, you can stop here. When you are ready to start again, fire up your node, go to Validator Staking
, and click Validate
.
If you want to stop being a validator
and move your tokens to other/better use, continue.
- Next you must unbond. In the same window (
Validator -> Account Actions
), next to your keypair, click the rightmost triple dotted "settings" button, selectUnbond funds
, and choose the amount you wish to unbond.
After the transaction has gone through, you will see a new line appearing in the bonded
column, showing the amount and a "clock" icon. Hovering over this with your cursor will tell you when your unbonding is complete ( starts at <24h / <14,400 blocks), and you can go to the third and final step.
- Within 24h, the tokens should be unbonded, and you will see a new line appearing in the
bonded
column, showing the amount you can claim and a blue "lock" button. Click the button to finalize the unbonding, and your tokens will be "free" to spend from your "stash".
Notes:
- If you have performed multiple unbondings, in different
eras
:- hovering over the "clock" will show multiple entries, eg.
<amount>, <time_left>, <block_left>
- you may also have both the "clock" and "lock" button, if some of your unbondings are completed
- if you have any pending slashes, these will be deducted when you perform step 3.
- hovering over the "clock" will show multiple entries, eg.
First, make sure you have set Fully Featured
interface in the Settings
sidebar.
<tot_bonded>
Is the total amount you have staked/bonded<act_bonded>
Is the amount of tokens that is not being unlocked<unbonding_n>
Is the amount of tokens that is in the process of being freed from yourn
thUnbond funds
requestsum <unbonding_n>
+<act_bonded>
=<tot_bonded>
<era_unbonded_n>
Is theera
when yourn
thUnbond funds
request tokens will be "free" to transfer/bond/vote
To find out if you have started/completed your n
unbonding(s):
- chain state query of
ledger(AccountId): Option<StakingLedger>
with the controller. Output:
# If you have successfully initiated unbonding, but the tokens are not unlocked:
{
stash: 5YourStashAddress,
total: <tot_bonded> JOY,
active: <act_bonded> JOY,
unlocking: [
{
value: <unbonding_0> JOY,
era: <era_unbonded_0>
},
{
value: <unbonding_1> JOY,
era: <era_unbonded_1>
},
...
{
value: <unbonding_n> JOY,
era: <era_unbonded_n>
}
],
claimedRewards: [
<era_a>,
<era_b>,
...
<era_i>,
]
}
Note:
To understand what claimedRewards
means, go here.
- The
era
should only change every 600 blocks, but certain events may trigger a new era. To calculate when your funds are "free" InChain State
->staking.currentEra()
. Let output be<era_current>
If <era_unbonded_n>
>= <era_current_n>
, you can claim the unbonded funds in step 3..
- Once the unbonding is complete, go to extrinsics, with the
controller
, selectstaking.withdrawUnbonded(num_slashing_spans)
Note: If you have any "pending" slashes, this will require some more chain state queries, to find the input num_slashing_spans
.
Your tokens will be "free" to spend from your "stash".