Подробнее об обновлении компьютерного приложения Artery Network 1.3

В этом обновлении мы переработали интерфейс раздела валидации, но это лишь вершина айсберга, т.к. большая часть изменений связана с логикой работы и не видна невооруженным взглядом. Чтобы описать, какие именно изменения произошли, хочется немного рассказать о том, как именно устроена валидация в версиях приложения для Windows и MacOS.

Всем известно, что исходный код непосредственно блокчейн ноды выложен на нашем github. Именно скомпилированную из этого кода ноду и запускает внутри у себя приложение для компьютеров. А после запуска управляет ей, отправляя команды и получая результат. Так, как это делал бы системный администратор, запустивший ее, например, на linux или windows сервере. Таким образом блокчейн нода конкретной версии (1.3.4 сейчас) идентична для всех пользователей и не зависит ни от версии приложения Artery Network, ни от того, на какой платформе и каким образом она запущена. А само приложение упрощает пользователям работу, беря на себя большую часть операций по настройке ноды и ее окружения, включению / выключению валидации, размещению ключей, разблокировке и т.д.

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

Для нормальной работы валидации требуется несколько факторов действующих одновременно:

1. Достаточная производительность процессора

2. Достаточная производительность накопителя (SSD)

3. Интернет соединение с низкой латентностью (низким «пингом»; это важно, т.к. нода должна не только передать большой объем данных, но и сделать это в очень короткий промежуток времени — поэтому средний объем передаваемых данных может быть не большой, но с очень большими пиками в короткие временные отрезки)

4. Соединение с несколькими нодами одновременно, чтобы в случае потери одной из них (например обрыв электропитания) целый сегмент сети не оказался отрезанным от остальных.

5. Наличие возможности принимать входящие подключения (внешний IP адрес и правильно настроенный доступ к компьютеру снаружи).

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

Что же делает приложение при запуске валидации? Первым делом поверхностно проверяется соответствие компьютера требованиям к оборудованию — заявленная производителем частота процессора, минимальный объем памяти, наличие доступа из внешней сети.

Если система удовлетворяет первичным требованиям, проверяется текущее состояние ноды блокчейн — есть ли копия ноды нужной версии, наличие файла конфигурации с рекомендованными параметрами, скачанный файл с генезис блоком (если нет, нужные данные и настройки скачивается с сайта автоматически).

Затем проверяется наличие необходимых приватных ключей для работы. Если их нет — создаются новые.

Остается два необходимых действия для запуска валидации — получить все необходимые блоки из блокчейн и включить валидацию.

Для получения блоков можно либо загрузить их все по одному с самого генезиса, либо взять уже обработанную часть (слепок) и загрузить недостающие. Мы пошли именно по второму пути — сначала идет процесс загрузки слепка — все необходимые данные загружаются с сервера («загрузка»), а затем блоки, вышедшие с момента создания слепка, загружаются из блокчейн («синхронизация»). При этом нода считается синхронизированной, когда обрабатывает блок одновременно с остальными (т.е. нода отслеживает процесс достижение консенсуса валидаторами, https://docs.tendermint.com/master/introduction/what-is-tendermint.html#consensus-overview)

Вот теперь, когда нода синхронизирована, можно включить валидацию (Раньше этого нельзя сделать, т.к. она не знает какой блок сейчас обрабатывается и какие данные он может содержать и просто пропустит подписание и будет заблокирована).

Что же именно в этом процессе мы изменили в версии 1.3?

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

Также, в процессе синхронизации и запуска валидации нода несколько раз могла перезапускаться, что ухудшало процесс и могло привести к блокировке сразу после включения валидации, т.к. нода после перезапуска еще не успела синхронизироваться и отставала на 1–2 блока.

Нода блокчейн в Cosmos SDK может получать блоки в 2х режимах — нормальной работы и catchingup (быстрая синхронизация). В нормальном режиме — блоки скачиваются (и сразу обрабатываются) по одному, строго по порядку (так она работает когда синхронизирована и валидирует блоки). В режиме catchingup блоки загружаются сразу по несколько штук и затем быстро проверяются на неизменность (при этом нода не принимает транзакции, но рассчитывает блоки гораздо быстрее). По умолчанию нода запускается в режиме catchingup, догоняет блокчейн и переходит в нормальный режим. При этом переход обратно в catchingup в Cosmos SDK не реализован и, если нода по каким-то причинам отстала от блокчейн, она этого не отслеживает и может разрешить включить валидацию (это особенность Tendermint и Cosmos SDK, и ее изменение пока не запланировано).Чтобы такого не происходило, мы добавили в приложение функцию, которая отслеживает текущий обрабатываемый нодой блок и максимально известный блок в блокчейн, и если они отличаются более чем на 2 блока, не даст включить валидацию или попытаться снять блокировку — таким образом повысится стабильность сети и пользователь получит меньше штрафов.

Еще один важный фактор — постоянное наличие внешнего адреса, чтобы другие ноды могли подключаться из внешней сети — таким образом заметно повышается связность сети и в тоже время снижается нагрузка на отдельные ноды, что повышает надёжность системы в целом.

Часто нода работает на компьютере, находящемся за роутером провайдера, и для его настройки требуется либо ручная работа, либо автоматическая настройка приложением (если такое поддерживается оборудованием). Работу последней мы улучшили и повысили ее стабильность.

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

Были выведены следующие параметры:

- статус работы ноды (выключена, подключение, синхронизация, синхронизировано, отключение)

- внешний IP

- средняя скорость

- количество исходящих соединений (показывает к какому количеству нод подключилась ваша)

- количество входящих соединений (показывает какое количество нод подключилось к вашей из внешней сети)

- сила валидатора (подробнее смотрите в FAQ)

- группа валидатора (основная, дополнительная, очередь, заблокировано — более подробная информация также есть в FAQ)

- версия блокчейн, которая сейчас работает

- обработано блоков подряд (сколько блоков валидатор обработал вовремя с последнего опоздания на подписание)

- предупреждений — сколько подписаний валидатор пропустил (за 2 пропуска подряд нода блокируется на 120 блоков)

Чтобы реализовать все вышеперечисленное, был переработан механизм непосредственного обмена данными приложения с нодой.

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

Одно из ключевых изменений в данном случае — анонимный сбор информации о подключеннии нод друг к другу. Эта информация позволяет построить карту сети (какие ноды коммуницируют друг с другом, и как взаимодействуют валидаторы) и с её помощью лучше понять, в чем может быть проблема у конкретной ноды (например, медленные “соседи”) и дать рекомендации по её решению.