Развертывание узла RPC для блокчейн-сети POLYGON

Протокол и узлы RPC

Децентрализованное приложение (dApp, сокр. от англ. decentralized application) не может работать изолированно само по себе. Для успешной обработки запросов пользователя ему необходимо подключение к различным блокчейн-сетям. Для связи dApp с блокчейном применяется протокол RPC (сокр. от англ. Remote Procedure Call). Клиентом RPC выступает децентрализованное приложение, а роль сервера выполняет узел RPC (англ. RPC Node) [1].

Протокол удалённого вызова процедур – это легковесный протокол обмена данными между приложениями. Он позволяет клиенту общаться с удалённым сервером без необходимости знать подробности о сети, в которой находится этот сервер [2]. К примеру, локальный компьютер использует RPC для запроса некоторых ресурсов у удалённого сервера. Как только клиент совершает запрос, RPC инициирует выполнение на сервере подпрограммы.

Узлом RPC называется компьютер, на котором запущено клиентское приложение блокчейна. Например, это может быть сервер, на котором развёрнута инфраструктура уровня исполнения транзакций (англ. Execution Layer, сокр. EL) и уровня консенсуса (англ. Consensus Layer, сокр. CL).

Информационные технологии

и телекоммуникации

2.3.6

Рисунок 1. Схема работы узла RPC Когда программа инициирует выполнение подпрограммы, узел RPC получает необходимые запро… — см. PDF статьи.

Конечные точки и поставщики узлов RPC Конечная точка RPC – это такое место в сети, куда программа может передавать RPC-запросы для доступа к данным на сервере. Как только dApp присоединяется к конечной точке RPC, пользователю становятся доступны различные операции с блокчейном.

Узел, на котором развёрнуто необходимое ПО, сможет обрабатывать запросы RPC и отвечать на них. Конечная точка RPC, функционирующая на узле RPC, это, по сути, служба, через которую dApp получает информацию о блокчейне для пользователей. Таким образом, термины «конечная точка RPC» и «узлы RPC» можно использовать попеременно.

Конечные точки RPC делятся на две большие категории: публичные (public) и частные (private). Кроме них также существует категория альтернативных (alternative) точек, которые используются для резервирования.

1. Публичные точки RPC – это общедоступные ресурсы с ограничением по скорости передачи запросов. Они позволяют любому пользователю обмениваться данными с блокчейном.

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

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

Частные узлы RPC запускаются по запросу.

Кроме того, поставщики узлов нередко обеспечивают поддержку явных соглашений об уровне обслуживания (англ. service-level agreements, сокр. SLA) для повышения производительности dApp в случае необходимости.

Поставщик узла RPC берёт на себя ответственность за настройку, управление, поддержку и бесперебойную работу этого узла для dApp, что позволяет разработчикам сэкономить время и деньги на развёртывании и поддержке собственных узлов. Среди популярных поставщиков узлов для разнообразных сетей можно отметить GetBlock, Alchemy, Infura и др. [3].

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

Разработчики блокчейнов 1 и 2 уровней предлагают программное обеспечение и инструкции, необходимые для создания собственной частной точки. Но программное обеспечение регулярно обновляется, а инструкции зачастую содержат ошибки и не отражают в полной мере процесс развёртывания конечной точки. Поэтому ниже будет описан проверенный механизм создания узла для сети Polygon, которая выгодно выделяется среди аналогов высокой скоростью обработки транзакций и простотой получения бесплатных тестовых токенов MATIC, необходимых для оплаты комиссий при совершении транзакций в сети. Подготовка к развёртыванию узла RPC Узел сети Polygon состоит из двух слоёв:

Heimdall и Bor, поэтому для работы конечной точки основной или тестовой сетей Polygon понадобится запустить и синхронизировать оба этих клиента [4].

Heimdall – это разновидность клиента Tendermint, который мониторит контракты наряду с сетью Ethereum.

Bor – это разновидность клиента Geth, который генерирует блоки, перетасованные узлами Heimdall.

Tendermint – это механизм консенсуса, устойчивый к «задаче византийских генералов» (англ. Practical Byzantine Fault Tolerance) [5]. Он может использоваться в качестве первого слоя для PoS-блокчейнов (от англ. Proof Of Stake – доказательство владения). На практике Tendermint позволяет разработчикам разворачивать свои блокчейны и объединять их в «интернет блокчейнов» без необходимости создавать всю инфраструктуру с нуля. Данный механизм обеспечивает эффективную ретрансляцию изменений в блокчейне по всей сети, гарантируя, что все узлы будут синхронизированы с журналом транзакций и состоянием блокчейна.

Heimdall, как и Tendermint, работает на множестве специальных узлов, называемых валидаторами. Они отвечают за добавление блоков транзакций в блокчейн. В момент работы с каждым блоком среди множества валидаторов алгоритм выбирает одного, который будет предлагать следующий блок. Блок считается валидным, если все транзакции в нём валидны, и более двух третей валидаторов одобрили его добавление в блокчейн.

Клиенты Heimdall и Bor поставляются в виде пакетов DEB для установки на операционные системы Linux семейства Debian/Ubuntu. Для развёртывания узла далее будет использоваться операционная система Ubuntu Server 22.04.3 LTS. Требования к аппаратной конфигурации компьютера для тестовой сети Polygon Mumbai следующие:

• Процессор: 4-ядерный не старше 7-го поколения Intel Core или 1-го поколения AMD Ryzen • Память: не менее 8 ГБ • Накопитель: не менее 500 ГБ • Сеть: внешний («белый») IP-адрес и открытые порты 8545, 30303 и 26656-26660 для протокола TCP Порты в диапазоне с 26656 по 26660 используются клиентом Heimdall для общения с блокчейном. Порт 30303 используется клиентом Bor.

Децентрализованные приложения будут общаться с узлом RPC по порту TCP 8545. Открытие портов, как правило, выполняется через веб-интерфейс роутера, в разделе настроек «Переадресация портов».

Для установки клиентов сети Polygon в системе должны присутствовать следующие необходимые пакеты:

• curl – кроссплатформенная служебная программа командной строки, позволяющая взаимодействовать с серверами по протоколам с синтаксисом URL; • build-essential – метапакеты, необходимые для компиляции программного обеспечения.

Сюда входит отладчик GNU, различные компиляторы g++/GNU и прочие библиотеки, и компоненты для компиляции.

Для удалённой работы с сервером настоятельно рекомендуется установить и настроить сервер SSH. Это сетевой протокол прикладного уровня, позволяющий удалённо управлять системой в терминальном сеансе. В отличие от Telnet, поддерживает шифрование передаваемых данных.

Также потребуется консольный текстовый редактор. Для примера будет использоваться nano, хотя вместо него можно использовать любой другой редактор, например, vi или gedit. Для установки какого-либо компонента в Ubuntu используется команда apt install, исполняемая от лица суперпользователя:

sudo apt install::имя_компонента::

Настройка системы и установка необходимых пакетов Первым делом необходимо установить правильный часовой пояс на сервере (например, Москва, GMT+3):

sudo timedatectl set-timezone Europe/Moscow Далее обновить систему и пакеты:

sudo apt update && sudo apt upgrade 1) Установка Heimdall Установка клиента Heimdall производится из исходных файлов с репозитория разработчика.

Вместо указывается актуальная версия клиента, вместо – тип сети: основная (mainnet) или тестовая (mumbai), а вместо – тип узла RPC: узел-валидатор (validator), который будет уча� - ствовать в одобрении транзакций, или узел-часовой (sentry), который будет отвечать за синхрони� - зацию и децентрализацию сети. Итоговая команда для тестовой сети Polygon Mumbai будет выглядеть следующим образом:

Перед установкой выбранной версии Heimdall скрипт найдёт и удалит любую другую версию этого клиента, уже присутствующую в системе. Также скрипт установит Go – компилируемый многопоточный язык программирования, разработанный в компании Google.

Проверить версию установленного клиента Heimdall можно командой:

heimdalld version –long

2) Настройка «сидов» Heimdall «Сиды» (от англ. seed – источник) – это участники P2P-сети, отдающие файлы. Именно через них будет выполняться синхронизация узла RPC с блокчейном. Для добавления в конфигурационный файл Heimdall тестовой сети Mumbai сидов потребуется выполнить две команды:

Первая внесёт правки в текстовый файл конфигурации Heimdall:

/var/lib/heimdall/config/config.toml Вторая сделает пользователя heimdall вла�- дельцем одноимённой директории.

Для корректного подключения Heimdall к сидам в файл конфигурации потребуется вручную внести ещё некоторые изменения:

sudo nano /var/lib/heimdall/config/config.toml Обозначение узла RPC (может быть любым):

Разрешить «небезопасные» команды RPC, вроде ручного подключения к сидам или очистки базы данных подключений:

Задать перечень постоянных соединений:

Включить автоматическое перенаправление портов на роутере по технологии UPNP (для работы должна иметься поддержка со стороны роутера):

upnp = true — см. PDF статьи.

Увеличить максимальное число входящих пиров:

max_num_inbound_peers = 300 Включить режим сида, чтобы узел RPC постоянно искал в сети пиров:

Задать максимальное число открытых соединений с пирами. Пиры (от англ. peer – равнозначный) – это участник P2P-сети (компьютер), общающийся с другим участником этой же сети напрямую, а не через центральный сервер:

max_open_connections = 3

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

Теперь нужно обновить разрешения пользователя для доступа к файлу конфигурации службы запуска клиента Heimdall:

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

sudo systemctl daemon-reload 3) Установка Bor Установка клиента Bor выполняется по аналогии с Heimdall командой:

Вместо указывается актуальная версия клиента, вместо – тип сети: основная (mainnet) или тестовая (mumbai), а вместо – тип узла RPC: валидатор (validator) или часовой (sentry). Итоговая команда для тестовой сети будет выглядеть следующим образом:

Проверить версию установленного клиента Bor можно командой:

bor version

4) Настройка сидов Bor

Настройка сидов Bor для тестовой сети Mumbai осуществляется следующими командами:

Первые две внесут необходимые изменения в файл конфигурации Bor:

/var/lib/bor/config.toml

Третья команда сделает пользователя bor владельцем одноимённой директории.

Теперь нужно обновить разрешения пользователя для доступа к файлу конфигурации службы запуска клиента Bor:

Запуск клиентов

Первым всегда запускается клиент Heimdall, и только после его полной синхронизации запускается клиент Bor. Запуск Bor до завершения синхронизации приведёт к порче файлов Heimdall!

Запуск Heimdall осуществляется командой:

sudo service heimdalld start Для проверки, завершена ли синхронизация Heimdall с сетью или ещё нет, можно выполнить команду:

curl localhost:26657/status У переменной catching_up должно быть значение false – это значит, синхронизация завершилась. Значение true указывает на продолжающуюся синхронизацию.

Просмотреть журнал состояния Heimdall можно командой:

sudo journalctl-u heimdalld.service-f Сразу после запуска службы Heimdall в журнале могут появляться записи об ошибках соединения с пирами «ERROR dialing failed». Если порт 26656 на роутере открыт, и сиды прописаны в файле конфигурации, обычно достаточно просто подождать. Если соединение всё равно не устанавливается, нужно остановить службу Heimdall, очистить его адресную книгу сидов, после чего снова запустить службу:

После завершения синхронизации Heimdall можно запустить Bor командой:

sudo service bor start

Просмотреть журнал состояния рест-сервера Bor можно командой:

sudo journalctl-u bor.service –f При успешном соединении с сетью Bor начнёт свою синхронизацию.

Скачивание и распаковка снимков После запуска клиента Heimdall можно дождаться, пока он сам скачает все предшествующие цепочки блоков и синхронизируется с сетью. Однако такой способ синхронизации займёт очень много времени (может растянуться на несколько дней или даже недель) То же верно и для клиента Bor. Поэтому разработчик предоставляет для скачивания архивы с инкрементными «снимками» состояний блокчейна. Скачивание и развёртывание таких снимков сильно ускорит процесс синхронизации.

Для автоматического скачивания и распаковки снимков разработчик Polygon подготовил shell-скрипт [6].

После его запуска пользователю предлагается выбрать сеть: основную (mainnet) или тестовую (mumbai). Если пользователь не ввёл имя сети, будет использовано значение по умолчанию – mumbai. Затем устанавливаются зависимости, а курсор помещается в директорию извлечённых файлов. Скачивается список скомпилированных инкрементальных файлов снимков, а следом за ним – все инкрементальные файлы. Производится автоматическая проверка контрольной суммы для каждого инкрементного снимка. Для уменьшения занимаемого дискового пространства в скрипте предусмотрен вспомогательный метод извлечения всех файлов и удаления уже извлечённых скачанных файлов. После скачивания всех снимков выполняется финальное извлечение данных.

Допустим, файлы снимков были скачаны и распакованы в директории ~/ heimdall_extract для Heimdall и ~/bor_extract для Bor. После скачивания и извлечения файлов нужно сначала удалить все существующие директории с данными для Далее необходимо переместить директории с распакованными снимками и задать связи symlink с файлами конфигураций клиентов (из директории пользователя):

Теперь можно снова запускать клиент После синхронизации Heimdall запускается Доступ к узлу RPC Доступ к узлу RPC (конечной точке) из децентрализованного приложения осуществляется по доменному имени и порту 8545. Например:

mumbai.rpc.myrpcnode.com:8545 Для подключения dApp к узлу потребуется запустить веб-сервер (например, apache2) и получить действующий SSL-сертификат. Эти действия выходят за рамки материала статьи, но при наличии SSL-сертификата необходимо открыть файл конфигурации Heimdall:

и там в категории [rpc] указать пути для файлов сертификата и ключа:

Путь к сертификату может быть как абсолютным, как и относительным для конфигурационной директории Tendermint. Если сертификат подписан центром сертификации, то его файл должен представлять собой объединение сертификатов сервера, всех посредников и центра сертификации.