Как настроить Ethereum-ноду (гайд 2026)

Ethereum-нода даёт вам прямой доступ к сети: собственный JSON-RPC endpoint, без rate limit, без третьей стороны, читающей ваши запросы. Этот гайд проведёт вас от пустого сервера Ubuntu до синхронизированной ноды с командами для копирования — Geth в роли execution-клиента, Lighthouse в роли consensus-клиента, оба под управлением systemd. Он также охватывает то, что упускает большинство туториалов: железо в 2026 году, длительность синхронизации, ежемесячную стоимость и когда лучше использовать API.

Что такое Ethereum-нода?

Ethereum-нода — это компьютер, который запускает клиентское ПО Ethereum, хранит копию блокчейна, проверяет каждый входящий блок на соответствие правилам протокола и предоставляет интерфейс JSON-RPC, который wallet и приложения используют для чтения chain и отправки транзакций.

С момента Merge в сентябре 2022 года «клиент» на самом деле представляет собой две программы, которые должны работать бок о бок. Execution-клиент (Geth, Nethermind, Besu, Erigon или Reth) хранит state, исполняет транзакции и отвечает на JSON-RPC-вызовы. Consensus-клиент (Lighthouse, Prysm, Teku, Nimbus или Lodestar) отвечает за proof of stake: он следует за beacon chain и сообщает execution-клиенту, какой блок является текущей головой. Они общаются через аутентифицированный локальный порт (8551) и идентифицируют друг друга общим JWT-секретом. Один без другого — не работающая нода. Этот момент сбивает с толку большинство начинающих операторов.

Существует три профиля хранения. Full node хранит недавний state и удаляет старые данные путём pruning; Geth требует около 1,2–1,4 ТБ в середине 2026 года. Archive-нода хранит каждый исторический state — значительно больше 10 ТБ на классическом hash-based layout Geth, или около 2–3 ТБ на клиентах, созданных специально для этого, таких как Erigon и Reth. Light-нода загружает только заголовки; звучит привлекательно, но почти ни один peer не обслуживает light-клиенты в mainnet, поэтому это непрактичный путь доступа.

Требования к Ethereum-ноде

Приведённые ниже цифры описывают full node в 2026 году. Archive-нода — это отдельный проект, а валидатор не добавляет никакого дополнительного железа поверх солидной full node.

Две строки заслуживают пояснения.

Хранилище должно быть NVMe. Синхронизация записывает небольшие случайные фрагменты данных с высокой скоростью. SATA SSD регулярно застревают на несколько дней в фазе state heal у Geth, а облачные тома со стандартными IOPS часто вообще не завершают процесс. TLC NVMe-накопитель с DRAM-кэшем — безопасный выбор. О ёмкости: база данных Geth занимает около 1,2 ТБ, а Lighthouse добавляет примерно 200–250 ГБ, так что 2 ТБ работают сегодня, но оставляют мало запаса — 4 ТБ покупают вам годы.

Трафик тоже накапливается. Нода перемещает порядка 1 ТБ в месяц. Домашние подключения справляются с этим без проблем; VPS-тарифы с жёсткими лимитами трафика — нет.

Linux, macOS и Windows — все подходят. Каждая команда ниже предполагает Ubuntu 24.04, распространённый серверный стандарт.

Способы запустить ноду

Вам не обязательно собирать всё вручную. Устройства plug-and-play, такие как DappNode и Avado, представляют собой предварительно настроенные машины с дашбордом: купить, подключить, следовать мастеру настройки. ARM-платы тоже подходят — Ethereum on ARM публикует готовые образы для плат класса Raspberry Pi 5 с NVMe-накопителем, дешёвые в эксплуатации, но более медленные в синхронизации. Лаунчеры автоматизируют ручной путь: eth-docker (на основе Docker, требуются знания терминала), Stereum (устанавливает клиенты на удалённый сервер по SSH с GUI), NiceNode (выберите клиента, запустите в несколько кликов) и Sedge (CLI-мастер от Nethermind, генерирующий конфигурацию Docker).

Облако или локально? VPS подходит для разработки. Если сопротивление цензуре — часть вашей мотивации, запускайте ноду на собственном железе — нода внутри крупного облачного региона наследует юрисдикцию и условия обслуживания этого провайдера.

Остальная часть этого гайда посвящена ручной настройке. Она учит вас больше всего, и всё, что вы узнаете, переносится на лаунчеры.

Пошагово: Geth + Lighthouse на Ubuntu

1. Подготовка сервера

sudo apt update && sudo apt upgrade -y
sudo useradd --no-create-home --shell /usr/sbin/nologin geth
sudo useradd --no-create-home --shell /usr/sbin/nologin lighthouse
sudo mkdir -p /var/lib/geth /var/lib/lighthouse
sudo chown geth:geth /var/lib/geth
sudo chown lighthouse:lighthouse /var/lib/lighthouse

Откройте порты peer-to-peer и ничего больше:

sudo ufw allow 30303 comment 'geth p2p'
sudo ufw allow 9000 comment 'lighthouse p2p'
sudo ufw allow 9001/udp comment 'lighthouse quic'

Порты 8545 (JSON-RPC) и 8551 (engine API) остаются закрытыми снаружи; оба привязаны к localhost в юнитах ниже.

2. Установка Geth

sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt update
sudo apt install -y ethereum
geth version

3. Установка Lighthouse

Lighthouse поставляется в виде статического бинарного файла. Этот сниппет всегда получает последний релиз:

LH=$(curl -s https://api.github.com/repos/sigp/lighthouse/releases/latest | grep -m1 '"tag_name"' | cut -d '"' -f 4)
curl -LO "https://github.com/sigp/lighthouse/releases/download/${LH}/lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
tar xzf "lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
sudo mv lighthouse /usr/local/bin/
lighthouse --version

Проверьте загрузку: на каждой странице релиза указаны контрольные суммы SHA-256 и PGP-подпись; выполните sha256sum и сравните, либо импортируйте ключ Sigma Prime и используйте gpg --verify. Подменённые бинарные файлы — реальный вектор атаки, а проверка занимает минуту.

4. Создание JWT-секрета

sudo mkdir -p /var/lib/jwt
openssl rand -hex 32 | sudo tee /var/lib/jwt/jwt.hex > /dev/null

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

5. systemd-юнит для Geth

Создайте /etc/systemd/system/geth.service:

[Unit]
Description=Geth execution client (mainnet)
After=network-online.target
Wants=network-online.target

[Service]
User=geth
Group=geth
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
ExecStart=/usr/bin/geth \
  --mainnet \
  --syncmode snap \
  --datadir /var/lib/geth \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3,txpool \
  --authrpc.addr 127.0.0.1 --authrpc.port 8551 \
  --authrpc.vhosts localhost \
  --authrpc.jwtsecret /var/lib/jwt/jwt.hex

[Install]
WantedBy=multi-user.target

TimeoutStopSec=600 имеет значение: Geth сбрасывает state на диск при выключении, и слишком раннее завершение процесса — классический способ повредить базу данных.

6. systemd-юнит для Lighthouse

Создайте /etc/systemd/system/lighthouse.service:

[Unit]
Description=Lighthouse consensus client (mainnet)
After=network-online.target geth.service
Wants=network-online.target

[Service]
User=lighthouse
Group=lighthouse
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse bn \
  --network mainnet \
  --datadir /var/lib/lighthouse \
  --execution-endpoint http://127.0.0.1:8551 \
  --execution-jwt /var/lib/jwt/jwt.hex \
  --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \
  --http

[Install]
WantedBy=multi-user.target

URL checkpoint sync позволяет Lighthouse стартовать с недавнего финализированного state вместо повторного проигрывания beacon chain от genesis: секунды вместо дней. Вы доверяете этому endpoint как отправной точке; сверьте state root со вторым источником, например beaconstate.info, если это вас беспокоит.

7. Запуск и наблюдение

sudo systemctl daemon-reload
sudo systemctl enable --now geth lighthouse
journalctl -fu geth

Geth сначала логирует загрузку заголовков, затем бесконечный поток строк «Imported new chain segment»; Lighthouse сообщает о синхронизированных слотах в течение нескольких минут. Проверка прогресса синхронизации:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://127.0.0.1:8545

{"result":false} означает полную синхронизацию. Во время синхронизации вы вместо этого получите объект прогресса.

Сколько длится синхронизация?

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

Lighthouse с checkpoint sync достигает головы chain менее чем за минуту и догоняет исторические блоки в фоновом режиме. Geth в режиме snap sync (по умолчанию) загружает из сети примерно 800 ГБ – 1 ТБ, а затем восстанавливает state trie локально. На рекомендованном железе закладывайте один-два дня; на минимальном железе с посредственным диском — три-пять. Финальный этап — фаза «state heal», и если она длится днями без завершения, ваш диск слишком медленный — см. устранение неполадок.

После первоначальной синхронизации ситуация успокаивается. Начиная с версии 1.13 Geth удаляет старый state на лету путём pruning (path-based state storage), так что база данных больше не растёт неограниченно, как предупреждали более старые гайды. Geth 1.16 и новее также может отбросить историю до Merge (--history.chain postmerge), что освобождает несколько сотен ГБ, если места становится мало.

Режимы синхронизации: snap, full и archive

Флаг --syncmode в юните Geth определяет, сколько chain вы верифицируете самостоятельно и сколько дискового пространства за это платите. Существует три режима, и правильный вытекает из вопросов, на которые должна отвечать нода.

Snap sync — режим по умолчанию, и именно его использует этот гайд. Geth загружает текущий state напрямую от peer’ов, верифицирует заголовки блоков вплоть до genesis, а затем восстанавливает state trie. Результат: работоспособная full node за один-два дня и база данных объёмом около 1,2–1,4 ТБ в середине 2026 года, растущая с этого момента.

Full sync (--syncmode full) заново исполняет каждую транзакцию с 2015 года вместо загрузки state. Конечный результат на диске — та же база данных после pruning, но синхронизация занимает недели даже на мощном железе. Его выбирают по одной причине: вы отказываетесь доверять загрузке state и хотите пересчитать всю историю на собственной машине. Это исследовательская позиция, а не операционная необходимость.

Режим archive находится на другой оси: --gcmode archive поверх full sync хранит каждый промежуточный state вместо его удаления. Только archive-нода отвечает на вопрос «каким был этот баланс на блоке 15 000 000» или выполняет глубокие трейсы без пересчёта, что нужно индексаторам, налоговым инструментам и аналитическим платформам. На классическом hash-based layout Geth это стоит значительно больше 10 ТБ. Erigon и Reth хранят историю иначе и размещают archive-ноды в диапазоне 2–3 ТБ в середине 2026 года, так что почти каждое новое archive-развёртывание начинается с одного из этих двух; более новый path-based archive-режим Geth играет в той же весовой категории, но имеет меньше опыта в продакшне.

Для платёжного бэкенда snap sync отвечает на всё: текущие балансы, новые блоки, receipts транзакций. Archive — для того дня, когда вам нужно восстановить прошлое.

Выбор клиента и разнообразие

Geth плюс Lighthouse — надёжный выбор по умолчанию, и именно его популярность является ловушкой. Модель безопасности Ethereum предполагает, что ни один клиент не контролирует слишком большую часть сети: баг консенсуса в клиенте с более чем двумя третями валидаторов мог бы финализировать сломанную chain — единственный сбой, который протокол не может аккуратно отменить. Даже доля в одну треть вызывает дискомфорт, потому что сбой именно этого клиента остановил бы финализацию.

Положение сети в середине 2026 года: Geth по-прежнему лидирует на уровне execution с долей, которую измерения оценивают между третью и примерно 40 процентами, Nethermind следует с двадцатью-тридцатью процентами, Besu и Reth держатся на низких двузначных значениях, Erigon — несколько процентов. На стороне consensus Lighthouse, по большинству подсчётов, вырос за пределы комфортной черты в треть, Prysm следует на втором месте, затем Teku и Nimbus. Сеть становится безопаснее каждый раз, когда оператор выбирает клиента-меньшинство, и оператор при этом почти ничего не теряет — все execution-клиенты говорят на одном JSON-RPC, все consensus-клиенты — на одном beacon API.

Конец 2025 года сделал этот аргумент конкретным. Вскоре после апгрейда Fusaka баг в широко используемом consensus-клиенте вызвал необходимость экстренных патчей, в то время как ноды на других клиентах продолжали валидацию без перебоев. Операторы на комбинациях-меньшинствах читали об этом инциденте, вместо того чтобы им управлять.

Для первой ноды комбинация из этого гайда вполне подходит. Для второй ноды или любого профессионального использования выбирайте комбинацию-меньшинство, например Nethermind с Teku или Reth с Nimbus. Настройка выше переносится почти один в один — каждой комбинации нужен тот же JWT-секрет и та же engine-API-разводка; меняются только бинарники, флаги и директории данных.

Сколько стоит эксплуатация Ethereum-ноды

Точных цен здесь нет; они меняются ежемесячно и различаются по странам. Вместо этого — расчёт для самостоятельного выполнения.

Собственное железо: мини-ПК в категории требований (8 ядер, 32 ГБ RAM, 2–4 ТБ NVMe) — это разовая покупка в диапазоне нескольких сотен евро. Энергопотребление около 30–60 Вт. Расчёт: 0,03–0,06 кВт × 720 ч ≈ 20–45 кВт·ч в месяц; умножьте на ваш тариф на электроэнергию. При 0,30 €/кВт·ч это 6–13 € в месяц сверх интернет-подключения, за которое вы уже платите.

Арендованный сервер: VPS-тарифы с честными 2 ТБ NVMe встречаются редко, поэтому на практике вы приходите к выделенному серверу начального уровня. Это ставит вас в диапазон нескольких сотен евро в месяц по нижней границе — порядок величины, а не конкретное предложение. Облачные инстансы с выделенными IOPS стоят заметно дороже эквивалентного выделенного сервера.

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

Мониторинг и проверки состояния

Три вопроса охватывают здоровье ноды: работает ли процесс, синхронизирован ли он, есть ли у него peer’ы. systemd отвечает на первый с помощью systemctl is-active geth lighthouse. Остальные два имеют endpoint’ы на обоих уровнях:

# execution: peer count as hex; eth_syncing from step 7 covers sync state
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

# consensus: HTTP 200 = synced, 206 = still syncing
curl -s -o /dev/null -w '%{http_code}\n' \
  http://127.0.0.1:5052/eth/v1/node/health

REST API Lighthouse слушает на порту 5052 благодаря уже включённому в юнит флагу --http. Endpoint /eth/v1/node/health кодирует состояние синхронизации в HTTP-статус-коде, что делает его естественной проверкой для скриптов и балансировщиков нагрузки; /eth/v1/node/syncing возвращает расстояние в слотах, если вам нужно число. Cron-задача, выполняющая эти проверки плюс df -h /var/lib/geth и отправляющая письмо при аномалиях, — это полноценный мониторинг для личной ноды.

Для дашбордов добавьте --metrics к Geth (endpoint Prometheus на порту 6060) и --metrics к Lighthouse (порт 5054), держите оба на localhost, и импортируйте дашборды Grafana, которые публикуют оба проекта. Что бы вы ни строили, установите два алерта прежде всех остальных: использование диска выше 85 процентов и высота блока, неизменная в течение десяти минут. Эти два ловят почти любой реальный сбой раньше, чем его заметят ваши пользователи.

Обслуживание и обновления

Обновления клиентов не опциональны. Hard fork требует нового ПО, и нода на старой версии просто перестаёт следовать за chain на блоке форка. Подпишитесь на фиды релизов Geth и Lighthouse на GitHub и на блог Ethereum Foundation — в настоящее время сеть выпускает примерно одно крупное обновление в год, с релизами клиентов между ними.

Процедура остаётся короткой. Geth из PPA обновляется командами sudo apt upgrade и sudo systemctl restart geth; подтвердите через geth version. Lighthouse — единый бинарный файл: повторите загрузку из шага 3, замените /usr/local/bin/lighthouse, перезапустите юнит. Читайте release notes перед перезапуском — флаги иногда переименовывают, и переименованный флаг в systemd-юните означает сервис, который отказывается запускаться в 2 часа ночи.

Также закладывайте рост диска. Full node на Geth добавляет порядка 10–15 ГБ в неделю в середине 2026 года; Lighthouse растёт медленнее. На диске 2 ТБ это обратный отсчёт, который можно сбросить — истечение срока pre-Merge-истории освобождает несколько сотен ГБ (см. устранение неполадок), а свежий snap sync восстанавливает полностью компактную базу данных за один-два дня. При 4 ТБ рост становится ежегодным, а не ежеквартальным вопросом. Нода не обязана быть онлайн каждую секунду, но чем дольше она офлайн, тем дольше ей потребуется догонять.

Full node — это не валидатор

32 ETH, о которых все слышали, относятся к стейкингу, а не к работе ноды. Ноде из этого гайда вообще не нужен ETH — она валидирует блоки в смысле их проверки, что требует железа, а не стейка.

Валидатор — это третья программа рядом с двумя клиентами: она хранит ключи подписи, производит attestation’ы и блоки и зарабатывает за это вознаграждения, с настроенным адресом fee recipient для дохода. 32 ETH — это залог, который протокол может конфисковать за доказуемое нарушение. Операционная планка тоже смещается — RPC-нода, оффлайн на выходных, просто догоняет в понедельник, тогда как офлайн-валидатор получает небольшие штрафы каждую эпоху.

Имея менее 32 ETH, входной точкой становится пуловый стейкинг: Rocket Pool и похожие протоколы позволяют разрешённым без ограничений операторам запускать валидаторов с меньшим залогом, и некоторые настройки пулов работают именно на ноде, построенной выше. Обычная full node не зарабатывает ничего. Вы запускаете её ради независимости и приватности, для разработки, или как основу, на которой позже будет стоять валидатор.

Безопасность: расположение портов и есть политика

Вся модель безопасности этой настройки видна в правилах фаервола из шага 1. Порты 30303 и 9000/9001 открыты, потому что peer-to-peer нужны незнакомцы; 8545 и 8551 привязаны к 127.0.0.1, потому что ничему за пределами машины там делать нечего. JWT-секрет аутентифицирует engine API на 8551, но относитесь к нему как ко второму уровню защиты, а не как к причине открывать порт.

Открытый 8545 — более серьёзная ошибка, потому что у JSON-RPC вообще нет аутентификации. Сканеры быстро находят открытые Ethereum RPC-порты, и ущерб выходит за рамки бесплатного использования: с неправильными включёнными namespace посторонние получают отладочные внутренности и содержимое mempool, которые никогда не должны видеть. Держите --http.api в пределах четырёх namespace из юнита; admin, debug и personal должны быть отключены на любой машине, чей RPC-порт может когда-либо стать доступным.

Когда другим машинам легитимно нужен RPC, туннелируйте вместо того чтобы открывать: WireGuard или SSH-туннель для себя, nginx или Caddy с TLS и allowlist по IP для небольшой команды. Клиенты уже работают как системные пользователи без входа в систему из шага 1, поэтому скомпрометированный процесс клиента не наследует никакой shell-аккаунт. Добавьте unattended-upgrades для патчей ОС, и скучная часть безопасности сервера позаботится о себе сама.

Устранение неполадок

Lighthouse не может подключиться к Geth (“Unable to connect to execution endpoint”)

Либо Geth не работает (systemctl status geth), либо JWT-секреты различаются. Убедитесь, что оба юнита указывают на один и тот же путь jwt.hex. В случае сомнений один раз перегенерируйте секрет и перезапустите оба сервиса.

Geth зависает на “State heal in progress” на несколько дней

Фаза state heal преследует голову chain, а диск со слабой производительностью случайной записи никогда её не догоняет. Проведите бенчмарк с помощью fio; вам нужны десятки тысяч IOPS на блоках 4k. SATA SSD и облачные тома по умолчанию — обычные виновники. Решение — настоящее NVMe-хранилище: никакой флаг не спасёт медленный диск.

Количество peer остаётся на нуле

Порт 30303 (TCP и UDP) заблокирован или не проброшен через ваш NAT. Также проверьте системные часы: timedatectl должен показывать активную синхронизацию NTP, потому что смещённые часы ломают peer-хендшейки на стороне consensus.

Диск заполняется

Сначала найдите источник роста: du -h --max-depth=2 /var/lib/geth. Datadir, созданный до Geth 1.13, всё ещё использует старый hash-based layout; чистое решение — свежий resync, после чего state остаётся автоматически подрезанным. Включение истечения срока pre-Merge-истории освобождает ещё несколько сотен ГБ, а ancient store можно перенести на дешёвый HDD с помощью --datadir.ancient.

Geth сообщает о повреждении базы данных после сбоя

Отключение питания, kill -9 или OOM-kill в середине записи оставляет при следующем запуске строки лога о повреждении или отсутствующих данных. Иногда перезапуск это лечит; если лог зацикливается, прекратите чинить и вместо этого пересинхронизируйтесь — переместите datadir в сторону, начните заново, и snap sync восстановит всё за один-два дня, обычно быстрее, чем любая попытка ремонта. Профилактика уже заложена в юнит: TimeoutStopSec=600 даёт Geth время на flush, и чистый systemctl stop — единственный способ, которым процесс вообще должен завершаться.

OOM killer завершает Geth

journalctl -k | grep -i oom подтверждает подозрение. --cache у Geth по умолчанию установлен на 4096 МБ на mainnet, а реальное использование превышает это значение во время синхронизации; добавьте Lighthouse и операционную систему, и машина с 16 ГБ исчерпывает память. Установите --cache 2048 на небольших машинах и держите файл подкачки как буфер — медленно лучше, чем убито, потому что убитый Geth ничего не сбрасывает на диск и провоцирует случай повреждения выше.

Свой узел — или использовать API?

Честное сравнение, поскольку Chaingateway продаёт альтернативу.

Нода побеждает, когда вам нужен тяжёлый, постоянный сырой JSON-RPC: archive-запросы, tracing, наблюдение за mempool, или максимальная приватность и цензуроустойчивость. Нода — это фиксированная стоимость с неограниченным количеством запросов — при цифре в несколько сотен евро в месяц из раздела о стоимости она обходит любое тарифицируемое RPC-предложение, как только ваш объём становится достаточно высоким. Это также лучший способ понять, как Ethereum действительно работает.

API побеждает, когда нода была бы лишь средством для достижения цели, что для большинства бизнесов означает платежи. Синхронизированная нода даёт вам eth_sendRawTransaction и логи событий. Она не даёт вам депозитные адреса на клиента, уведомления при поступлении ERC-20-платежа, управление ключами или логику повторных попыток. Это прикладное ПО, которое вам пришлось бы строить и эксплуатировать поверх, и это обычно стоит больше часов, чем сама нода.

Ethereum API от Chaingateway — это именно тот недостающий слой: создание и импорт адресов (POST /api/v2/ethereum/addresses/import), отправка ERC-20-токенов (POST /api/v2/ethereum/transactions/erc20) и получение подписанных HMAC webhook для входящих депозитов — неудачные доставки попадают в доступный для запроса список (GET /api/v2/ethereum/webhooks/notifications/failed) и могут быть отправлены повторно через endpoint retry. Точка окупаемости — это арифметика: стоимость сервера плюс ваши часы на постройку и эксплуатацию против плана на /ru/pricing/. Для платёжных потоков сторона API этого неравенства остаётся меньше вплоть до масштаба далеко за пределами хобби-уровня; для потребления сырого RPC сторона ноды побеждает рано. Начните с quickstart и гайда по webhook — 7-дневного пробного периода без KYC достаточно, чтобы протестировать поток депозита от начала до конца (зарегистрируйтесь здесь).

Работаете и с другими chain? Смотрите гайды для BNB Smart Chain и TRON.