Релизы и обновления
ZooBC меняет свою программу, не меняя свою цепочку. Новые версии объявляются в самой цепочке, каждый узел устанавливает их через программу обновления, которой управляет его владелец, а новые правила консенсуса включаются только тогда, когда их уже исполняют две трети производителей. Никто не может навязать узлу программу, и новой версии никогда не нужна новая цепочка.
Реестр релизов
Орган выпуска релизов — один ключ, указанный в генезисе цепочки, — регистрирует каждый релиз транзакцией RegisterRelease (тип 32): строка версии, 32-байтовый хеш манифеста (отпечаток файлов релиза) и адрес релиза. Релиз регистрируется для каждой архитектуры и каждой цепочки, и его строка версии называет и то и другое. Строку версии можно зарегистрировать только один раз, поэтому исправлению нужна новая версия, а отозванная версия никогда не может вернуться. Орган выпуска может также отозвать релиз (тип 35) и передать свою роль другому ключу, что делается в два шага: предложение (тип 33) и принятие (тип 34).
У зарегистрированных мест есть противовес этому ключу:
- Вето. Когда две трети зарегистрированных мест аттестуют «вето» против версии, она отзывается в точности так, как если бы её отозвал орган выпуска: самообновляющиеся узлы её пропускают, а установщик отказывается её ставить. Приостановленные места в подсчёт не входят, поэтому при 11 активных местах для вето нужно 8. Каждый голос — аттестация без комиссии, подписанная ключом узла, и операторы подают его сами; ничто не голосует автоматически.
- Замена. Голос, называющий новый орган выпуска релизов, засчитывается, только когда самому старому голосу исполняется неделя (40 320 блоков), так что нынешний держатель роли видит его заранее. При двух третях роль переходит к адресу, за который проголосовали.
Регистрация или отзыв носят рекомендательный характер. Они направляют узлы, владельцы которых выбрали автообновление; оператора, запускающего бинарный файл по собственному выбору, они не затрагивают. Любой может сверить скачанный релиз с реестром (проверка загруженного файла).
Программа обновления
Установщик ZooBC добавляет небольшую программу обновления, которая работает рядом с узлом, а не внутри него. Первый раз она запускается через 15 минут после загрузки машины, затем примерно каждые 10 минут (плюс-минус 2). Каждый раз она запрашивает у локального узла /api/v1/release/list и ищет самый новый зарегистрированный и не отозванный релиз для своей цепочки и своего типа машины (amd64 или arm64), который новее работающего.
Программа обновления устанавливает этот релиз, только когда наступает его срок: высота регистрации релиза плюс задержка обновления плюс собственный слот этого узла. Тогда она скачивает релиз, проверяет его подпись и хеш манифеста по цепочке, устанавливает его рядом с работающей версией, перезапускает узел и выполняет проверку работоспособности. Если проверка не проходит, она откатывается к старой версии, а неудавшееся обновление повторяет через 12 часов.
- Задержка по умолчанию в mainnet — 2 дня (11 520 блоков). Каждый узел задаёт свою, и орган выпуска релизов не может её сократить. Она оставляет время отозвать плохой релиз, прежде чем он распространится.
- Слоты упорядочивают узлы по ключу и разносят время начала обновления так, чтобы по умолчанию в любом блоке обновление начинали не более 2 узлов. Цепочка никогда не теряет много производителей одновременно.
- Переключатель владельца,
auto_update, принимает значенияon(по умолчанию),offилиchain. Приchainпрограмма обновления следует настройке, которую владелец подписывает в цепочке из кошелька, так что владелец может включать и выключать обновления, не заходя на сервер.
Каждого оператора уведомляют о появлении более нового релиза: программа обновления, даже выключенная, называет его вместе с состоянием порога готовности, узел ежедневно пишет предупреждение в журнал, маршрут узла /node/info сообщает о нём, веб-кошелёк показывает баннер, а обозреватель показывает версию каждого узла.
Порог готовности
Новые правила консенсуса поставляются в релизе в виде набора с идентификатором набора больше 0. Каждый блок несёт версию программы своего производителя, и порог готовности её читает. Правила набора включаются на всех узлах одновременно на первой высоте, которая удовлетворяет всем условиям:
- она не раньше запланированной высоты набора и не раньше чем через 5 760 блоков (одни сутки) после регистрации релиза;
- как минимум две трети зарегистрированных мест (с округлением вверх, без учёта приостановленных) создали каждое хотя бы по блоку с версией не ниже идентификатора набора в пределах окна сигнализации, которое равно большему из 720 блоков и 5 блоков на узел;
- релиз не отозван; отзыв останавливает ожидающий набор.
Начиная с этой высоты блоки со старой версией отклоняются. Узел, который не обновился, не получает отсрочки: он пропускает свои ходы, ничего не зарабатывает и теряет оценку с первого же отклонённого хода (пропущенные ходы, приостановка и исключение). Именно поэтому операторов предупреждают о каждом новом релизе.
Поскольку считаются производители, а не блоки, меньшинство, отрезанное от остальных, не может само по себе набрать две трети. Ни один ключ тоже не может принудительно включить правила: орган выпуска релизов не подписывает сообщения об активации, а одна лишь высота никогда ничего не решает, пока производители не перешли. У порога есть известные ограничения: у него нет крайнего срока, поэтому чуть больше трети мест может задержать обновление, и он не обнаруживает неисправный релиз — для этого существуют задержка и вето.
В цепочках, запущенных с версией 0.5.8, все 121 правило консенсуса включены с блока 0, и ни одно правило не входит в набор, поэтому порог впервые станет важен для более позднего релиза. Узел также отказывается запускаться, если его бинарный файл располагает активацию правила иначе, чем записано для цепочки, а релиз может поставлять пин релиза, который привязывает его к известному spine-блоку.