Пропуски подписи блоков и отключение нод — мнения ведущих экспертов Minter

В свете последних событий, мы решили собрать экспертные мнения по поводу пропуска подписей, отключения нод и защиты от штрафов.

Сергей Салей, сооснователь проекта Minterscan и валидатора Zen:

По другим валидаторам я не вправе разглашать информацию, почему происходят отключения.

Лично мы поймали дважды непонятную ошибку, из-за которой нода продолжает работать, но перестает подписывать блоки. В таких ситуациях срабатывает штатная защита.

У нас стоит Minter-guard от команды U-node. Благодаря ей, штрафов у нас не было.

Константин Мелёшкин, сооснователь валидатора BTC.Secure:

Защита только тогда является защитой, когда она :

• Имеет основной и резервный слой,
• Расположена в отличных от валидаторов дата центрах и провайдерах,
• Каждый валидатор имеет резервный сервер, который активируется в случаях проблем с основным.

Лучшая защита — это такая, которой не приходится пользоваться, т.к. инфраструктура валидатора должна строится по принципу «надежно и безопасно».

Надежно и безопасно  — это дорого. Иногда можно увидеть эти утверждения, которые не подкреплены делом. Ведь, на первый взгляд, не видно разницы, когда один валидатор использует пару дешевых серверов, а другой — 20-30 совсем не дешевых. В долгосрочной перспективе разница проявится лучше. Уже сейчас можно ее увидеть в разделе штрафы на InterchainZone.

В BTC.Secure, ещё со времен тестовых сетей, интегрирована защита от штрафов собственной разработки. Она запущена в отдельных от валидаторов дата-центрах, на независимых друг от друга выделенных серверах.

Алексей Кухновец, разработчик Interchain Zone, участник команды BTC.Secure:

В недавней ситуации отключения нод сработал закон Мёрфи. А именно: «Все, что может пойти не так, пойдет не так». Валидаторам не следовало хранить запасные ключи на той же связке.

Анатолий Устинов, основатель валидатора U-node:

Валидирование требует вдумчивого подхода, как к архитектуре, так и к реализации задуманного. Это дорого и отнимает много времени, но такова цена надежности.

Я бы советовал создавать свой тестнет, либо пользоваться публичным, для того, что бы проверить свои силы в действии, понять, как работает все в сети. В этом деле все и просто, и сложно одновременно, как везде – есть тонкости.

Наша программа Minter-guard отлично показала себя в работе нескольких валидаторов (U-node, 1%, Zen, Consul Node) и уже не раз спасала от штрафов их делегаторов. 

Я бы дал несколько советов для работы с Minter-guard:

• Обязательно без стеснения консультироваться со мной по применению программы, как делают 1%, Zen, Consul Node .
• Логи Minter-guard желательно смотреть. Он сообщит, если что то пойдет не так с API нодой или транзакция отключения ноды будет не верной.
• Для Minter-guard требуются отдельные API ноды, желательно свои и надежные. Мы используем 6 машин с API, которые не лягут одновременно и расположены в разных ЦОДах.
• На сентри и валидаторах применение/включение API и использование его для Minter-guard нежелательно. Особенно если используемое оборудование слабое. Вероятно, это и было причиной последних отказов.
• Советую избегать всяческой кластеризации, сложных скриптов автоматизации. Любой подобный «навес» может отказать и подвести.

Алексей Канев, основатель валиатора 1%

Относительно пропуска подписей, и, как следствие, отключения нод, я полностью разделяю взгляды, выраженные Алексеем из Monster Node  в его статье «Валидаторы и их тараканы».

Вот некоторые выдержки из этой статьи.

…Причины пропуска подписи:

• Недостаточная инфраструктура – отсутствие встроенных цепочек быстрого получения блока из каждой части сети, слабый сервер, слабая и нестабильная сеть, различный тормозящий обвес, облачные решения, скорость записи на диск, неправильная организация бэкапа… тут можно перечислять бесконечно.
• Избыточная инфраструктура – неэффетивное использование сентри-нод, неправильное использование файрвлов, использование промежуточных узлов для проверки дублирования подписей блоков, использование двойных приватных каналов чрезмерное дублирование подключений.
• Недостаточная или избыточная инфраструктура блок-пропоузера.
• Раздолбайство.

…У меня инфраструктура несколько интереснее, но и она не позволяет гарантировать отсутствие пропусков , она лишь снижает вероятность получения блока позже других…

…На данном этапе я вижу только возможность перераспределения нагрузки блокчейна, а уж с нашими «валидаторскими тараканами» мы как-нибудь разберемся…