Как запустить полную ноду Bitcoin на VPS в 2026 году

Собственная нода Bitcoin сама проверяет каждое правило сети, поэтому вашему кошельку не приходится доверять чужому серверу сведения о своём балансе и адресах. VPS — удачное место для такой ноды: он работает круглосуточно, имеет постоянный адрес, по которому к нему могут подключаться другие ноды, и не съедает исходящий канал вашего домашнего интернета. Начнём с выбора размера сервера — именно здесь чаще всего ошибаются, — а затем установим Bitcoin Core из проверенных бинарников и создадим конфигурацию и сервис, которые переживут перезагрузки и обновления.

Урезанная (pruned) или полная нода: определитесь до заказа

Bitcoin Core всегда скачивает и проверяет всю историю целиком. Меняется лишь то, что нода оставляет у себя. Полная нода хранит каждый блок — сейчас это около 890 GB, — поэтому может отдавать блоки другим нодам, пересканировать любой кошелёк и служить источником данных для Electrum-сервера или блокчейн-эксплорера. Урезанная нода (pruned) проверяет всё точно так же, но удаляет старые блоки сразу после проверки и оставляет только chainstate (набор UTXO) и самые свежие блоки: при минимальной настройке это около 12 GB на диске.

Цифры по состоянию на октябрь 2026 года: 774 GB блоков, около 108 GB undo-данных и 12 GB chainstate. Общий объём растёт примерно на 94 GB в год, а индекс транзакций добавляет около 66 GB. Тома на 1 TB сегодня хватает для полной ноды, но примерно через год станет тесно; если вам нужны индексы, Electrum-сервер или запас на годы вперёд, начинайте с 5 TB. Во многих руководствах до сих пор пишут 600 GB — эта цифра устарела.

Память, CPU, диск и трафик

• Память важнее всего при первичной синхронизации: Bitcoin Core держит неизрасходованные выходы (UTXO) в кэше, размер которого задаёт dbcache, и чем больше кэш, тем меньше записей на диск. Начиная с версии 31 значение по умолчанию — 1024 MiB на машинах с RAM от 4 GiB и 450 MiB на тех, где памяти меньше. На тарифе с 4 GB для первичной синхронизации безопасное значение — около 1500 MiB; при 16 GB — 8000 и больше.
• CPU: Bitcoin Core пропускает проверку подписей в блоках, лежащих глубже встроенной точки assumevalid, поэтому хватит двух vCPU; дополнительные ядра в основном ускоряют самую свежую часть синхронизации.
• Скорость диска: chainstate постоянно читается и записывается, а файлы блоков в основном дописываются. Жёсткие диски хорошо справляются с файлами блоков, но плохо — с мелкими случайными чтениями и записями chainstate. В тарифах для хранения данных перед массивом RAID-10 из жёстких дисков стоит NVMe-кэш с отложенной записью (write-back), а небольшой chainstate целиком помещается в нём.
• Трафик: при первичной синхронизации вся цепочка блоков скачивается один раз — это около 0.8 TB. После этого нода, принимающая входящие соединения, раздаёт блоки пирам, которые ещё синхронизируются: bitcoin.org отмечает, что полные ноды на быстрых каналах обычно отдают 200 GB в месяц и больше. Ограничить отдачу можно параметром maxuploadtarget. В ST-1 входит 8 TB в месяц; при превышении лимита порт замедляется до 100 Mbps, при этом дополнительная плата не взимается.

Установка Bitcoin Core из проверенных бинарников

Скачайте релиз, список контрольных сумм и подписи к этому списку, а затем проверьте и то и другое: контрольная сумма подтверждает, что архив — именно тот, что указан в списке, а подписи — что список исходит от тех, кто собирает Bitcoin Core.

VER=31.1
cd /tmp
wget https://bitcoincore.org/bin/bitcoin-core-$VER/bitcoin-$VER-x86_64-linux-gnu.tar.gz \
     https://bitcoincore.org/bin/bitcoin-core-$VER/SHA256SUMS \
     https://bitcoincore.org/bin/bitcoin-core-$VER/SHA256SUMS.asc
sha256sum --ignore-missing --check SHA256SUMS
git clone --depth 1 https://github.com/bitcoin-core/guix.sigs
gpg --import guix.sigs/builder-keys/*
gpg --verify SHA256SUMS.asc SHA256SUMS

Первая проверка должна вывести OK рядом с именем архива. Вторая выводит по одному результату на каждого сборщика: должно получиться несколько строк Good signature; предупреждение о том, что ключи не заверены доверенной подписью, — норма, если вы не подписывали их сами. Затем установите два нужных бинарника и создайте системного пользователя:

tar xzf bitcoin-$VER-x86_64-linux-gnu.tar.gz
install -m 0755 -o root -g root -t /usr/local/bin bitcoin-$VER/bin/bitcoind bitcoin-$VER/bin/bitcoin-cli
adduser --system --group --home /var/lib/bitcoind bitcoin

Настройка ноды

mkdir -p /etc/bitcoin
cat > /etc/bitcoin/bitcoin.conf <<'EOF'
server=1
# RPC on the server only; reach it through SSH or WireGuard.
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
# UTXO cache in MiB: large for the first sync, smaller afterwards.
dbcache=1500
maxconnections=40
# Upload served to peers, in MiB per 24 hours (0 = no limit).
maxuploadtarget=5000
# Pruned node: uncomment to keep only about 550 MB of recent blocks.
#prune=550
# Transaction index, needed by Fulcrum and some explorers (full node only).
#txindex=1
EOF
chown -R root:bitcoin /etc/bitcoin
chmod 0640 /etc/bitcoin/bitcoin.conf

Для аутентификации RPC используется cookie-файл, который bitcoind записывает в свой каталог данных при каждом запуске, поэтому пароль не нужно ни придумывать, ни хранить, и он не может утечь. Программы, которым нужен RPC, например Electrum-сервер или нода Lightning, работают на том же сервере и читают этот cookie-файл.

Запуск в виде сервиса

cat > /etc/systemd/system/bitcoind.service <<'EOF'
[Unit]
Description=Bitcoin Core
After=network-online.target
Wants=network-online.target

[Service]
User=bitcoin
Group=bitcoin
ExecStart=/usr/local/bin/bitcoind -conf=/etc/bitcoin/bitcoin.conf -datadir=/var/lib/bitcoind
Restart=on-failure
TimeoutStopSec=600
PrivateTmp=true
ProtectSystem=full
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now bitcoind

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

Файрвол и RPC

ufw allow 22/tcp
ufw allow 8333/tcp comment bitcoin-p2p
ufw enable

Порт 8333 позволяет другим нодам подключаться к вашей, и именно так нода помогает сети; если порт закрыт, нода всё равно работает, но только через исходящие соединения. Никогда не открывайте порт 8332: через RPC управляют нодой и любым загруженным в неё кошельком. Чтобы пользоваться RPC с ноутбука, пробросьте его через SSH командой ssh -L 8332:127.0.0.1:8332, после которой укажите своего пользователя и адрес сервера, или объедините обе машины в сеть WireGuard.

Первичная синхронизация

Следить за ходом синхронизации можно так:

sudo -u bitcoin bitcoin-cli -datadir=/var/lib/bitcoind getblockchaininfo \
  | grep -E '"blocks"|"headers"|verificationprogress|size_on_disk'

Это может занять от многих часов до нескольких суток: нужно скачать и проверить около 0.8 TB, а темп задают память, скорость диска и пиры. По опубликованным бенчмаркам, на мощных NVMe-машинах с большим кэшем синхронизация укладывается в 7–12 часов; на тарифе с 4 GB и жёсткими дисками она займёт больше времени. Когда blocks сравняется с headers, а verificationprogress превысит 0.9999, уменьшите dbcache до 450 на тарифе с 4 GB и перезапустите сервис: дальше эта память нужнее операционной системе — под страничный кэш. Начиная с версии 28 Bitcoin Core умеет также стартовать со снапшота UTXO с помощью loadtxoutset и проверять историю в фоне, но файл снапшота нужно получить самостоятельно; большинство просто дожидается обычной синхронизации.

Electrum-сервер, Lightning и Tor

• Electrum-сервер. electrs добавляет около 7% от объёма блоков — сейчас примерно 56 GB — и не требует индекса транзакций; Fulcrum быстрее обслуживает кошельки с длинной историей, но ему нужны txindex=1 и собственная база заметно больше 100 GB. Ни тот, ни другой не работает на урезанной ноде. Любой из них позволяет Sparrow или Electrum обращаться к вашему серверу вместо публичного; порты этих серверов держите доступными только через SSH, WireGuard или Tor.
• Lightning. И LND, и Core Lightning работают рядом с bitcoind на том же сервере и слушают порт 9735. LND поддерживает урезанную ноду в качестве бэкенда ценой некоторого замедления и дополнительного расхода трафика; Core Lightning поддерживает её лишь частично и может застрять, если отстанет настолько, что нужные блоки уже удалены, поэтому удобнее всего опираться на полную ноду.
• Tor. Если установлен tor, включён его управляющий порт (ControlPort 9051 и CookieAuthentication 1 в torrc), а пользователь bitcoin добавлен в группу debian-tor, Bitcoin Core сам создаёт onion-сервис через этот порт; чтобы и исходящие соединения шли через Tor, добавьте proxy=127.0.0.1:9050. Реле Tor в нашей сети приветствуются, выходные узлы — нет.

Поддержание ноды в рабочем состоянии

• Обновления: повторите загрузку и обе проверки для новой версии, замените два бинарника и перезапустите сервис. Каталог данных сохраняется.
• Диск: раз в месяц проверяйте df -h /var/lib/bitcoind и переходите на более крупный тариф до того, как заполнение тома превысит 85%.
• Снапшоты: сделайте снапшот сразу после первичной синхронизации. Если обновление или сбой когда-нибудь повредит данные, откат займёт минуту вместо повторной синхронизации.
• Ключи: храните ключи, которыми тратятся средства, в аппаратном кошельке, а ноду используйте как его бэкенд. Если же вы всё-таки загружаете кошелёк на сервер, сделайте резервную копию дескрипторов кошелька и зашифруйте его.
• Майнинг на тарифах VPS запрещён, а нода — разрешена. На выделенных и GPU-серверах майнинг допускается: там в вашем распоряжении вся машина.