Установка и настройка полной ноды блокчейна TON

cryptobro

New member
Сообщения
23
Реакции
6
Пошаговая инструкция по настройке полной ноды для блокчейна TON


Обратите внимание, что вам нужен компьютер с общедоступным IP-адресом и высокоскоростным сетевым подключением для запуска полного узла TON Blockchain. Обычно вам нужен достаточно мощный сервер в центре обработки данных. Это плохая идея, чтобы запустить полный узел на вашем домашнем компьютере; вместо этого вы можете запустить полный узел на удаленном сервере и использовать клиент TON Blockchain Lite для подключения к нему из дома.


0. Скачивание и компиляция

Полное программное обеспечение TON Blockchain Library и Validator загружается и компилируется аналогично Lite Client. Этот процесс описан в соответствующем файле README. Самое важное отличие состоит в том, что вам нужно скачать полный исходный архив, доступный по адресу https://test.ton.org/ton-blockchain-full.tar.xz, вместо меньшего исходного архива Lite Client. Вы также должны собрать все цели, определенные в CMakeLists.txt (например, запустив cmake <path-to-source-directory> и make в вашей директории сборки), не только те, которые конкретно связаны с Lite Client (который также включены в большее распространение).


1. Полный узел двоичных файлов

После успешной компиляции исходных кодов вы должны получить исполняемые файлы validator-engine/validator-engine и validator-engine-console/validator-engine-console в вашей директории сборки. Это самые важные файлы, которые вам нужны для запуска полного узла TON Blockchain (или даже для валидатора) и управления им. Вы можете установить их в ваш /usr/bin или аналогичный каталог. Вам также может понадобиться утилита «generate-random-id» во время установки.


2. Рабочий каталог полного узла

Полный узел (также известный как «механизм проверки») хранит свои данные в подкаталогах своего рабочего каталога, например, /var/ton-work/db. Требуется доступ для записи в этот каталог. Если вы хотите использовать другой каталог в качестве рабочего каталога полного узла, вы можете использовать параметр командной строки --db <path-to-work-dir>:

$ validator-engine --db $ {DB_ROOT}

где $ {DB_ROOT} - это /var/ton-work/db или любой другой каталог, где механизм проверки имеет разрешения на запись.


3. Макет рабочего каталога


Примерное расположение рабочего каталога программного обеспечения TON Blockchain Full Node выглядит следующим образом:

  • $ {DB_ROOT}/config.json - автоматически сгенерированный файл конфигурации. В некоторых случаях он автоматически восстанавливается средством проверки. Когда механизм валидатора не работает, вы можете редактировать этот файл в текстовом редакторе, потому что это файл JSON.
  • $ {DB_ROOT}/static - каталог с файлами, которые не могут быть загружены из сети, например, «нулевое состояние» (соответствующее блоку Genesis других архитектур блок-цепей) главной цепи и активных рабочих цепочек. Обычно вам не нужно инициализировать этот каталог, если вы не хотите запускать свой собственный экземпляр цепочки блоков TON (например, для целей тестирования или разработки). Полные узлы существующих экземпляров цепочки блоков TON (такие как «testnet» и «mainnet») смогут загружать все необходимые файлы с уже запущенных полных узлов.
  • $ {DB_ROOT}/keyring - Хранит открытые и закрытые ключи, известные ядру валидатора. Например, если ваш полный узел работает как валидатор для некоторых из цепочек цепочек блоков TON, ключ подписи блока валидатора сохраняется здесь. Возможно, вы захотите установить более ограничительные разрешения для этого каталога, например, 0700 (в системах * nix), чтобы только пользователь, под которым работает механизм проверки, имел доступ к этому каталогу.
  • $ {DB_ROOT}/error - каталог, в который механизм валидатора копирует файлы, связанные с серьезными ошибочными состояниями (например, недействительными кандидатами в блоки), для дальнейшего изучения. Обычно он пуст, и механизм проверки никогда не удаляет файлы из этого каталога.
  • $ {DB_ROOT}/archive - каталог, в котором старые и редко используемые блоки хранятся до истечения срока их хранения. Вы можете смонтировать больший, но более медленный раздел диска в этом каталоге, или сделать этот каталог символической ссылкой на каталог в таком разделе. Мы рекомендуем найти остаток от $ {DB_ROOT} в быстром устройстве хранения, таком как SSD.
  • $ {DB_ROOT}/etc - (неавтоматические) файлы конфигурации могут храниться здесь или в любом другом каталоге, доступном для чтения средством проверки.
  • Другие подкаталоги $ {DB_ROOT} используются для хранения данных кэша ADNL, последних блоков и состояний и т. Д. Они не имеют отношения к целям этого документа.
4. Глобальная конфигурация цепочки блоков TON

Для настройки вашего полного узла вам понадобится специальный файл JSON, который называется «глобальная конфигурация (файл)». Это называется так, потому что он одинаков для всех полных узлов, и даже узлы, участвующие в разных экземплярах цепочки блоков TON (например, «testnet» и «mainnet»), имеют почти идентичную глобальную конфигурацию.

Глобальную конфигурацию «testnet» можно скачать по адресу https://test.ton.org/ton-global.config.json следующим образом:

$ wget https://test.ton.org/ton-global.config.json

Вы можете поместить этот файл в /var/ton-work/etc/ton-global.config.json.

Мы обсудим структуру этого файла позже более подробно. А пока давайте отметим, что основная часть этого файла состоит из списка известных узлов TON DHT, необходимых для начальной загрузки сети TON. Небольшой раздел в конце этого файла описывает конкретный экземпляр цепочки блоков TON, к которому мы хотим подключиться.

Все экземпляры цепочки блоков TON используют одну и ту же «глобальную» сеть TON (то есть сеть TON не фрагментируется на несколько экземпляров для каждого экземпляра цепочки блоков). Хотя конфигурация глобальной сети, таким образом, не зависит от конкретного выбранного экземпляра цепочки блоков TON, полные узлы, принадлежащие разным экземплярам, позднее будут подключаться к разным подсетям наложения внутри сети TON.

Важно различать этот «глобальный файл конфигурации», используемый для настройки полного узла TON Blockchain, и «локальный» или «файл автоматической конфигурации», автоматически обновляемый механизмом проверки и обычно хранящийся в $ {DB_ROOT}/config .json. Глобальная конфигурация используется только один раз, чтобы сгенерировать исходный файл автоматической конфигурации, который впоследствии обновляется самим механизмом проверки (например, путем добавления новых узлов DHT или сохранения хэшей более новых блоков главной цепи).


5. Инициализация локальной конфигурации

После загрузки файла глобальной конфигурации его можно использовать для создания начальной локальной конфигурации в $ {DB_ROOT}/config.json. Для этого выполните validator-engine один раз:

$ validator-engine -C /var/ton-work/etc/ton-global.config.json --db /var/ton-work/db/ --ip <IP>: <PORT> -l /var/ton-work/log

Здесь /var/ton-work/log - это каталог журнала validator-engine, где он будет создавать свои файлы журналов. Аргументом опции командной строки -C является файл глобальной конфигурации, загруженный с test.ton.org, как описано выше, а /var/ton-work/db/ - это рабочий каталог $ {DB_ROOT}. Наконец, <IP>: <PORT> - это глобальный IP-адрес этого полного узла (здесь необходимо указать публичный IPv4-адрес) и порт UDP, используемый для запуска сетевых протоколов TON, таких как ADNL и RLDP. Убедитесь, что ваш брандмауэр настроен на передачу пакетов UDP с источником или адресом <IP>: <PORT>, по крайней мере, для двоичного файла 'validator-engine.

Когда механизм валидатора вызывается, как указано выше, и $ {DB_ROOT} /config.json не существует, он создает новый локальный файл конфигурации $ {DB_ROOT} /config.json, используя информацию из файла глобальной конфигурации и из команды Параметры строки, такие как --ip, а затем выход. Если $ {DB_ROOT}/config.json уже существует, он не перезаписывается; вместо этого глобальная конфигурация игнорируется, и механизм-валидатор запускается как демон с использованием локальной конфигурации.

Если вам необходимо изменить локальную конфигурацию впоследствии, вам нужно либо удалить этот файл и восстановить его из глобальной конфигурации (потенциально забывая другую важную информацию, накопленную в локальной конфигурации), либо отредактировать локальную конфигурацию в текстовом редакторе (когда validator-engine не работает).


6. Настройка дистанционного управления CLI

Вы почти наверняка захотите включить консоль validator-engine-console в локальной конфигурации, чтобы иметь возможность контролировать ваш полный узел (то есть демон validator-engine), когда он работает. Для этого вам нужно сгенерировать две пары ключей: одну для сервера (механизм проверки) и одну для клиента (консоль средства проверки). В приведенных ниже примерах мы предполагаем, что консоль validator-engine-console работает на той же машине и подключается к validator-engine через сетевой интерфейс обратной связи. (Это не обязательно так; вы также можете использовать консоль validator-engine-console для дистанционного управления.)

В качестве первого шага используйте исполняемый файл «generate-random-id», чтобы создать две пары ключей: одну для сервера (на компьютере с «validator-engine») и одну для клиента (на компьютере с «validator-engine-»). console):

$ ./generate-random-id -m ключи -n сервер
6E9FD109F76E08B5710445C72D2C5FEDE04A96357DAA4EC0DDAEA025ED3AC3F7 bp / RCfduCLVxBEXHLSxf7eBKljV9qk7A3a6gJe06w / c =

Эта утилита генерирует новую пару ключей и сохраняет закрытый ключ в файл server, а открытый ключ в server.pub. Шестнадцатеричное (6E9F ... F7) и base64 ("bp / RC ... 6wc / =") представления открытого ключа отображаются в стандартном выводе и в дальнейшем используются для идентификации этого ключа.

Мы должны установить закрытый ключ server в связку ключей полного узла (validator-engine):

Сервер $ mv/var/ton-work/db/keyring/6E9FD109F76E08B5710445C72D2C5FEDE04A96357DAA4EC0DDAEA025ED3AC3F7

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

Затем мы генерируем пару ключей клиента:

$ ./generate-random-id -m ключи -n client
8BBA4F8FCD7CC4EF573B9FF48DC63B212A8E9292B81FC0359B5DBB8719C44656 i7pPj818xO9XO5/0jcY7ISqOkpK4H8A1m127hxnERlY =

Мы получаем пару ключей клиента, сохраняемую в файлах client и client.pub. Эта вторая операция должна выполняться в рабочем каталоге клиента (validator-engine-console), возможно, на другом компьютере.

Теперь нам нужно перечислить открытый ключ клиента в локальном конфигурационном файле сервера $ {DB_ROOT}/config.json. Чтобы сделать это, откройте локальный файл конфигурации в текстовом редакторе (после завершения validator-engine, если он работал) и найдите пустой раздел «control»:

Код:
"control": [

]
Замените его следующим:

Код:
"control": [

  {"id": "bp/RCfduCLVxBEXHLSxf7eBKljV9qk7A3a6gJe06w/c=",

    "port": <КОНСОЛЬ-ПОРТ>,

    "allowed" : [

      {"id": "i7pPj818xO9XO5/0jcY7ISqOkpK4H8A1m127hxnERlY=",

        «permissions»: 15

      }

    ]

  }

]
Для control.0.id задан идентификатор base64 открытого ключа сервера, а для control.0.allowed.0.id - идентификатор base64 открытого ключа клиента. <CONSOLE-PORT> - это UDP-порт, который сервер будет прослушивать для консольных команд.


7. Запуск полной ноды

Чтобы запустить полную ноду, запустите двоичный файл средства проверки в консоли:

$ validator-engine --db $ {DB_ROOT} -l /var/ton-work/log

Он прочитает локальную конфигурацию из $ {DB_ROOT}/config.json и продолжит работу в режиме без вывода сообщений. Вы должны написать подходящие сценарии для вызова validator-engine в качестве демона (чтобы он не завершался при закрытии консоли), но мы пропустим эти соображения для простоты. (Использование «nohup» - дешевый способ добиться этого в некоторых системах Linux.)

Если конфигурация неверна, механизм валидатора немедленно прекратит работу и в большинстве случаев ничего не выдаст. Вам нужно изучить файлы журналов в /var/ton-work/log, чтобы узнать, что пошло не так. В противном случае, validator-engine будет продолжать работать тихо. Опять же, вы можете понять, что происходит, просматривая файлы журналов и просматривая подкаталоги каталога $ {DB_ROOT}.

Если все работает так, как ожидалось, механизм валидатора найдет другие полные узлы, участвующие в одном и том же экземпляре блокчейна TON, и загрузит последние блоки мастер-цепочки и все шард-цепочки. (На самом деле вы можете контролировать количество последних загружаемых блоков или даже загружать их все, начиная с нуля - но эта тема выходит за рамки этого документа; попробуйте запустить средство проверки с опцией командной строки -h узнать список всех доступных опций с краткими пояснениями).


8. Использование консоли CLI

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

$ ./validator-engine-console -k client -p server.pub -a <IP>:<CLIENT-PORT>

connecting to [<IP>:<CLIENT-PORT>]
local key: 8BBA4F8FCD7CC4EF573B9FF48DC63B212A8E9292B81FC0359B5DBB8719C44656
remote key: 6E9FD109F76E08B5710445C72D2C5FEDE04A96357DAA4EC0DDAEA025ED3AC3F7
conn ready
received validator time: time=1566568904

Команда gettime получает текущее время Unix в валидаторе. Если все настроено правильно, вы увидите вывод, похожий на приведенный выше. Обратите внимание, что для работы консоли требуется как личный ключ клиента («client»), так и открытый ключ сервера («server.pub»). Вы можете переместить их (особенно закрытый ключ клиента) в отдельный каталог с соответствующими разрешениями.

Другие консольные команды доступны в validator-engine-console. Например, help отображает список всех консольных команд с краткими описаниями. В частности, они используются для настройки полного узла в качестве валидатора для цепочки блоков TON, как объяснено в отдельном документе Validator-HOWTO.


9. Настройка полного узла в качестве облегченного сервера

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

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

Код:
$ utils/generate-random-id -m keys -n liteserver

BDFEA84525ADB3B16D0192488837C04883C10FF1F4031BB6DEECDD17544F5347 vf6oRSWts7FtAZJIiDfASIPBD/H0Axu23uzdF1RPU0c=

mv liteserver ${DB_ROOT}/keyring/BDFEA84525ADB3B16D0192488837C04883C10FF1F4031BB6DEECDD17544F5347
После этого остановите ядро валидатора, если оно работает, и откройте локальный файл конфигурации $ {TON_DB}/config.json в текстовом редакторе. Найти пустой раздел

Код:
"liteservers": [

]
и замените его записью, содержащей порт TCP для прослушивания входящих подключений Lite Client и открытого ключа сервера lite:

Код:
"liteservers" : [

{

"id" : "vf6oRSWts7FtAZJIiDfASIPBD/H0Axu23uzdF1RPU0c=",

"port" : <TCP-PORT>

}

]
Теперь запустите validator-engine снова. Если он не завершается немедленно, вероятно, вы правильно настроили его. Теперь вы можете использовать исполняемый файл lite-client (обычно расположенный как «lite-client/lite-client» по отношению к каталогу сборки) для подключения к Lite Server, работающему как часть вашего полного узла:

$ lite-client -a <IP>: <TCP-PORT> -p liteserver.pub

И снова help перечисляет все команды, доступные в Lite Client. Lite Client HOWTO содержит несколько примеров того, что можно сделать с помощью Lite Client.
 
Последнее редактирование модератором:

admin

Administrator
Команда форума
Сообщения
132
Реакции
27
Ещё один файл установщика. Проверена установка на Ubuntu 18.04
 

Вложения

Сверху