Запуск узла-валидатора

Валидаторы (производители блоков) — аккаунты, которые алгоритм Fair-DPOS планирует для производства блоков каждые 3 секунды. Для запуска узла-валидатора необходим зарегистрированный аккаунт, ключ подписи и правильно настроенный узел.

Требования

Аккаунт VIZ Ledger, зарегистрированный как валидатор через validator_update_operation.
WIF-приватный ключ, соответствующий ключу подписи, зарегистрированному в блокчейне.
Синхронизированный полный узел (плагин валидатора требует плагины chain + p2p + snapshot).

Конфигурация

Используйте share/vizd/config/config_witness.ini в качестве базового шаблона.

Ключевые настройки:

ini

# P2P — разрешить публичные входящие соединения для распространения блоков
p2p-endpoint = 0.0.0.0:2001
p2p-seed-node = seed1.viz.world:2001

# RPC — привязать к localhost для безопасности (валидаторам публичный API не нужен)
webserver-http-endpoint = 127.0.0.1:8090
webserver-ws-endpoint   = 127.0.0.1:8091

# Обязательные плагины для валидатора
plugin = chain p2p webserver json_rpc database_api network_broadcast_api validator validator_api

# Пропустить индексирование виртуальных операций для экономии памяти
skip-virtual-ops = true

# Разделяемая память — 2G достаточно для маломощных сборок валидатора
shared-file-size = 2G

# ─── Идентификатор валидатора ─────────────────────────────────
# Имя вашего аккаунта-валидатора
validator = myvalidator

# Ваш ключ подписи в формате WIF
private-key = 5JxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxWIF

# Порог участия — остановить производство при падении сети ниже этого значения
required-participation = 33

# НЕ включать на основной сети (только для тестовой сети/бутстрапа)
# enable-stale-production = false

Синхронизация NTP

Точное время критически важно для производства блоков. Плагин валидатора поддерживает собственный NTP-клиент:

ini

# NTP-серверы (по умолчанию: pool.ntp.org, time.google.com, time.cloudflare.com)
ntp-server = pool.ntp.org
ntp-server = time.cloudflare.com

# Проверять NTP каждые 15 минут
ntp-request-interval = 900

# Отбрасывать ответы NTP с временем roundtrip > 150 мс
ntp-round-trip-threshold = 150

Убедитесь, что системные часы сервера также синхронизированы (через chrony или systemd-timesyncd).

Запуск узла

bash

./vizd --config-file /data/vizd/config.ini --data-dir /data/vizd

Docker

bash

docker run -d \
  --name vizd-validator \
  --restart unless-stopped \
  -p 2001:2001 \
  -v /data/vizd:/var/lib/vizd \
  -e VIZD_WITNESS=myvalidator \
  -e VIZD_PRIVATE_KEY=5Jxxx... \
  vizblockchain/vizd:latest

Регистрация / обновление валидатора

Используйте cli_wallet или совместимый кошелёк для трансляции validator_update_operation:

json

{
  "type": "validator_update_operation",
  "value": {
    "owner": "myvalidator",
    "url": "https://mysite.example/validator",
    "block_signing_key": "VIZ5hqSa...",
    "props": [3, {
      "account_creation_fee": "1.000 VIZ",
      "maximum_block_size": 65536
    }]
  }
}

Значение block_signing_key должно совпадать с private-key в конфигурации узла.

Чтобы отключить валидатора (убрать из расписания), установите нулевой ключ:

json

"block_signing_key": "VIZ1111111111111111111111111111111114T1Anm"

Цикл производства: что делает узел

Плагин валидатора запускает таймер производства 250 мс в выделенном потоке (изолированном от P2P ввода-вывода). При каждом тике вызывается maybe_produce_block(), который проверяет (по порядку):

Проверка синхронизации (DLT-режим): не производить, если узел нагоняет пиров.
Проверка снапшота: не производить, если идёт создание снапшота.
Проверка участия: сеть должна иметь ≥33% участия валидаторов.
Назначение слота: запланирован ли валидатор этого узла для текущего слота?
Проверка ключа: есть ли у узла правильный приватный ключ?
Обнаружение minority fork: если последние 21 блок произведены только валидаторами этого узла — откат и повторная синхронизация.
Разрешение коллизии форков: если на той же высоте существует другой блок — применяется сравнение весов голосов.
Проверка задержки: если узел опоздал более чем на 500 мс — пропустить слот.
Генерация и трансляция блока.

Полный граф выполнения — в разделе Плагин валидатора.

Результаты производства (сообщения в логах)

Результат	Значение
`produced`	Блок успешно произведён и транслирован
`not_synced`	Узел нагоняет или выполняется снапшот
`not_time_yet`	Нет доступного слота или дрейф NTP
`not_my_turn`	Для этого слота запланирован другой валидатор
`no_private_key`	Запланированный валидатор настроен, но приватный ключ отсутствует
`low_participation`	Участие сети ниже порога
`lag`	Пробуждение >500 мс после слота — слот пропущен
`fork_collision`	Конкурирующий блок на следующей высоте — ожидание
`minority_fork`	Узел на изолированном форке — откат

Механизмы безопасности

Защита от сетевого раздела

Если менее 33% валидаторов участвуют в производстве, оно останавливается для предотвращения split-brain ситуаций. Переопределите с enable-stale-production = true только для бутстрапа/тестовой сети.

Обнаружение minority fork

Если форк-база данных узла показывает 21+ последовательных блоков только от собственных валидаторов, узел автоматически откатывается к LIB и выполняет повторную синхронизацию. Это позволяет обнаружить сетевую изоляцию.

Watchdog производства

Если в течение 180 секунд (60 с для экстренного мастера) при активном should_be_producing не был произведён ни один блок, watchdog автоматически сбрасывает зависшие флаги (minority_fork_recovering, нагон P2P, синхронизация цепочки) и пытается возобновить производство.

Безопасность снапшотов

Производство блоков приостанавливается во время создания снапшота во избежание конфликтов блокировок записи.

Мониторинг

Следите за этими паттернами в логах:

# Хорошо: блок произведён
produced block #123456 ... validator=myvalidator

# Предупреждение: пропущен слот
MISSED-SLOT-OUR-validator: ...

# Предупреждение: minority fork
MINORITY FORK DETECTED: rolling back to LIB

# Предупреждение: сработал watchdog
WATCHDOG: no production for 180s, clearing flags

Также см. Мониторинг и Validator Guard для автоматических оповещений.

Несколько валидаторов на одном узле

Параметры validator и private-key можно указывать несколько раз:

ini

validator = alice
validator = alice.backup
private-key = 5Jxxx...   # Ключ Alice
private-key = 5Jyyy...   # Ключ Alice.backup

Узел будет производить блоки для любого из настроенных валидаторов по расписанию.

Ключ экстренного консенсуса

Для узлов, участвующих в восстановлении экстренного консенсуса:

ini

emergency-private-key = 5Jzzz...   # Ключ экстренного комитета

При его наличии узел автоматически добавляет CHAIN_EMERGENCY_VALIDATOR_ACCOUNT в свой набор валидаторов и участвует в производстве экстренных блоков. См. Экстренный консенсус.

Устранение неполадок

Проблема	Что проверить
Не производит блоки	Проверьте `validator` и `private-key` в конфиге; убедитесь, что ключ подписи в блокчейне совпадает с конфигом
`no_private_key` в логах	Ключ подписи в блокчейне не совпадает ни с одним `private-key` в конфиге
`low_participation`	Проблема работоспособности сети — проверьте количество пиров и статус других валидаторов
`minority_fork`	Сетевая изоляция — проверьте подключение к начальным узлам
Предупреждения о зависании NTP	Проверьте синхронизацию системного NTP: `chronyc tracking` или `timedatectl`
Перехваты слотов	Ключ подписи мог быть обнулён экстренным мастером; восстановите через `validator_update_operation`

Запуск узла-валидатора ​

Требования ​

Конфигурация ​

Синхронизация NTP ​

Запуск узла ​

Docker ​

Регистрация / обновление валидатора ​

Цикл производства: что делает узел ​

Результаты производства (сообщения в логах) ​

Механизмы безопасности ​

Защита от сетевого раздела ​

Обнаружение minority fork ​

Watchdog производства ​

Безопасность снапшотов ​

Мониторинг ​

Несколько валидаторов на одном узле ​

Ключ экстренного консенсуса ​

Устранение неполадок ​