Skip to content

HF16 / релиз 4.2.0 ​

Активация и обновление ​

HF16 назначен на 31 октября 2026, 00:00:00 UTC (1793404800), версия 4.2.0. Дополнительно нужен порог голосования валидаторов за хардфорк; установка бинарника не активирует его раньше времени. Обновите валидаторов заранее. Используйте проверенный production-образ, а не BUILD_TESTNET: у него другая идентичность цепи и кворум.

После сборки master перед распространением проверьте ревизию/версию конкретного образа, запуск, синхронизацию и производство блоков. Сохраните настроенный ключ валидатора и резервную копию данных. Удаление каталога данных не является процедурой обновления.

Проверка готовности ​

Для активации нужно CHAIN_HARDFORK_REQUIRED_VALIDATORS = 17 слотов расписания с голосом за 4.2.0 на 2026-10-31T00:00:00. В расписание попадают только валидаторы с ключом подписи, поэтому слотов может быть меньше 21. Если их меньше 17, форк не активируется, сколько бы валидаторов ни обновилось. Обновлённый валидатор с пустым ключом возвращается в расписание на следующей перетасовке после validator_update с ключом. Цепь пересчитывает голоса каждые 21 блок. Если порог набран после 31.10.2026 00:00 UTC, форк активируется в самом блоке пересчёта, без объявленного момента.

Тот же пересчёт, что делает цепь:

bash
python3 scripts/hardfork_readiness.py --url https://api.viz.world

Скрипт выводит число слотов, число слотов за каждый вариант голоса, валидаторов расписания, голосующих иначе, и валидаторов, которые голосуют за 4.2.0, но выпали из расписания из-за пустого ключа (только с голосами > 0, см. ниже). Код выхода 0 — порог набран, 1 — ещё нет, 2 — пересчёт расходится с цепью или ответ API непригоден.

Проверка вручную:

json
{ "method": "database_api.get_next_scheduled_hardfork", "params": [] }
{ "method": "validator_api.get_active_validators", "params": [] }
  • get_next_scheduled_hardfork возвращает hf_version 4.2.0 и live_time 2026-10-31T00:00:00, когда голосование набрало порог. До этого поле повторяет текущую версию.
  • get_active_validators возвращает слоты расписания — ровно тот набор, который считает цепь. В аварийном режиме уберите committee, проверьте каждое имя через validator_api.get_validator_by_account и посчитайте hardfork_version_vote 4.2.0 с hardfork_time_vote 2026-10-31T00:00:00. Если имён меньше 17, форк пока не может активироваться.
  • get_validators_by_vote не совпадает с этим набором: в нём есть валидаторы вне расписания с пустым ключом, и список обрывается на первом валидаторе без голосов, поэтому в нём нет валидаторов с нулём голосов, занимающих резервные слоты.

Слоты, QC, TC и финальность ​

  • При HF16 рабочий слот меняется с 3 секунд на 1 секунду. Читайте текущее значение get_config и время блоков: прежняя константа CHAIN_BLOCK_INTERVAL не задаёт слот после форка.
  • QC собирает подписи валидаторов из расписания. Формула реализации: max(floor(2N/3)+1, floor(0.75N)), то есть 15 из 21, а не старые 14 подтверждений поствалидации.
  • При передаче хода другому производителю блок несёт QC родителя. Сертификаты таймаута (TC) позволяют продолжить работу после пропущенных раундов. LIB использует 2-chain: сертифицированные родитель и ребёнок на локальной основной ветви, соседние высоты и последовательные раунды. Одного QC недостаточно.
  • Валидатор голосует за один блок за раунд; максимальный проголосованный раунд сохраняется до рассылки. Повтор того же голоса разрешён. Доказательство конфликтующих голосов помещается в заголовок и создаёт виртуальную операцию validator_equivocation (ID 106).
  • Новые теги расширений заголовка: 3 QC, 4 TC, 5 доказательство двойного голоса. Расширения транзакций и прежние ID операций не меняются.
  • Параметры управления, измеряемые в блоках и сохраняющие смысл по времени, масштабируются при активации. Не заменяйте все таймеры в 3 секунды механически: независимые интервалы повторов и завершения процесса — отдельные настройки.

Восстановление и аварийный режим ​

После временного нарушения связи обычное восстановление не требует перезапуска или аварийного ключа. На стенде из 21 валидатора проверены недоступность шести валидаторов, потери 20% с задержкой 150±50 мс, полный обрыв на 241 секунду и разделение 10/11. После восстановления связи все 21 узел финализировали один проверенный блок. Это проверенные сценарии, а не гарантия времени восстановления при любой атаке.

Догонялка отложенной цепочки сохраняет предков LIB, пока fork_db опережает применённое состояние. Аварийный режим отдельный: его таймаут остаётся 1200 секунд (20 минут). Короткие тесты не меняют его на пять минут. См. Аварийный консенсус.

DAO и рынки ​

При создании заявки максимум DAO равен floor(current_supply.amount / 100) в минимальных единицах: 1% текущего общего количества VIZ, округлённый вниз до 0.001 VIZ. Лимит вычисляется для каждой заявки, не от начальной эмиссии и не от остатка фонда комитета. До HF16 при воспроизведении истории сохраняется старый потолок 500 000 VIZ. Суммы существующих заявок не переписываются. См. Операции комитета.

У no-contest, объявленного после HF16, номинальная цена фиксируется при объявлении. При расчёте применяется предел страхового остатка; старые объявления сохраняют прежний расчёт. Замороженный ноль отличается от отсутствия заморозки. См. Заморозка цены no-contest.

UI оператора и MCP ​

Необязательный плагин node_admin предоставляет встроенный UI браузера /ui/ и HTTP MCP на отдельном административном слушателе. Доступны здоровье, диагностика, плагины, логи, аудит, P2P, снапшоты, операции валидаторов и планы настроек. Bearer-токены разграничивают права; настройки и плагины меняются через проверяемые plan / apply. По умолчанию слушатель локальный; для удалённой работы используйте туннель. Не публикуйте его как публичный API цепи. См. Управление нодой.

Клиентские библиотеки ​

JS 0.18.5 поддерживает новые заголовки и опубликован в npm. PHP сохраняет формат транзакций и передаёт JSON заголовков без изменения. Исходники Python 1.4.0 и зависимости проверены CI на Python 3.10–3.14; публикация PyPI — отдельный шаг. Клиенты не должны ограничивать DAO старой фиксированной суммой.

Эмиссия и окно доказательств ​

HF16 намеренно сохраняет 1.000 VIZ на произведённый блок (решение владельца Q3105=C). При непрерывном выпуске блоков годовая валовая эмиссия растёт примерно с 10.5 до 31.5 млн VIZ. Пропущенный слот не выпускает награду.

Окно хранения голосов и подачи доказательств двойного голосования сохраняет длительность один час: 3600 / block_interval() раундов, то есть 3600 после HF16. Это не аварийный таймер и не обещание срока восстановления. Пороги обнуления ключа за пропуски увеличены втрое в блоках, сохраняя прежние примерно 10 минут в обычном режиме и 5 минут в аварийном. Минимальная длительность распределительного периода также сохраняется: новые голоса за параметры проверяются по увеличенной нижней границе; воспроизведение до HF16 сохраняет старую.

Повторное голосование параметров ​

Параметры хранятся и голосуются в реальном числе блоков, согласно выбранной политике миграции HF16. Однократная миграция увеличивает существующие голоса и медиану втрое, но не распознаёт последующий голос из старого скрипта. Делегатам нужно увеличить зашитые inflation_recalc_period, distribution_epoch_length, pm_batch_epoch_blocks, pm_reveal_window_blocks втрое для сохранения длительности. Для голосования defaults используйте актуальный get_config.CHAIN_DEFAULT_CHAIN_PROPERTIES; при изменении другого поля сохраняйте остальные текущие on-chain значения. Старые defaults структуры повторно не отправляйте.

get_config согласованно возвращает текущие блоки/час/сутки/год, ёмкость undo, пороги пропусков и defaults. Шаг изменения reserve ratio сохраняет 60 секунд. CHAIN_EMERGENCY_EXIT_NORMAL_BLOCKS — неиспользуемая историческая константа: выход из emergency определяется кворумом активных валидаторов, а не таймером 21 блок.

Пороги P2P-синхронизации (отставание, разрешение форка, wedge watchdog) масштабируются по текущей длине слота и сохраняют прежнюю длительность. Опции оператора в блоках не пересчитываются: dlt-block-log-max-blocks, snapshot-every-n-blocks, history-count-blocks, block-archive-range после HF16 покрывают втрое меньший срок. Скользящий block log по умолчанию (100000 блоков) обслуживает синхронизацию пиров около 28 часов вместо 3,5 дней; значение 300000 сохраняет прежнее окно.