Как запустить полный узел Bitcoin на VPS

Полный узел — единственный способ пользоваться Bitcoin, не спрашивая кого-то ещё, где правда. Любой другой вариант — сервис вида block explorer, лёгкий кошелёк, общающийся с публичным сервером, баланс на бирже — означает, что вы доверяете свою историю третьей стороне и заодно отдаёте ей свою приватность. Сам Bitcoin Core устанавливается минут за десять. А вот полезен ли ваш узел на самом деле, решает машина под ним: сколько вы выделили диска, тарифицируется ли исходящий трафик и что вообще видит хостер.

Что делает полный узел — и чего не делает

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

• Он проверяет независимо — ни сервис вида block explorer, ни биржа, ни сервер лёгкого кошелька не могут диктовать вам, что верно и какой у вас баланс.
• Он избавляет вас от утечки адресов на чужой сервер при каждой синхронизации кошелька — а это самая распространённая утечка приватности у большинства пользователей Bitcoin.
• Он передаёт блоки и транзакции дальше — и именно эта часть помогает не только вам, но и всей сети.
• Он ничего не зарабатывает, ни за что не «голосует» и не делает ваши монеты безопаснее, если ключи и так хранятся небрежно.

Архивный узел, узел с prune и индексированный узел: три совершенно разных требования к месту на диске

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

• Узел с prune — Core скачивает и проверяет абсолютно всё, а затем отбрасывает старые файлы блоков, оставляя только последние. При prune=5000 данные блоков занимают около 5 GB; добавьте набор UTXO и саму операционную систему — и в сумме выйдет около 25 GB.
• Архивный — каждый блок хранится вечно. На сегодня один только объём данных блоков превышает 750 GB и растёт примерно на 7 GB в месяц, а сверху добавляется ещё набор UTXO. Он нужен, чтобы отдавать исторические блоки другим пирам или переиндексировать данные позже без повторной загрузки цепочки.
• Индексированный — архивный режим плюс txindex=1: он позволяет искать любую транзакцию по её ID, и именно этого ожидают от узла сервисы вида block explorer и часть серверного софта. Это добавляет сверху ещё десятки гигабайт и несовместимо с prune.

Выбор VPS для узла Bitcoin: диск, RAM и безлимитный порт

К процессору Bitcoin Core нетребователен, а вот к диску придирчив. Именно случайные чтения и записи в базу UTXO делают синхронизацию быстрой или мучительной, поэтому здесь NVMe значит куда больше, чем количество ядер. Каждый тариф линейки офшорных VPS поставляется с NVMe Gen4 в RAID-10 и безлимитным трафиком, так что реальный выбор — это только объём.

• Узел с prune: VPS-4 за $7.49/mo — 2 vCPU EPYC, 4 GB DDR5 ECC и 60 GB NVMe, с комфортным запасом под prune=5000 и логи. Подойдёт и VPS-2 за $3.99, если обрезать историю сильнее.
• Узел с prune, который быстро синхронизируется: VPS-8 за $13.99/mo — 4 vCPU и 8 GB позволяют выделить Core несколько гигабайт под dbcache, а это самый мощный рычаг ускорения синхронизации.
• Архивный узел: VPS-64 за $89.99/mo — единственный тариф VPS, чьи 800 GB NVMe вообще способны вместить неусечённую цепочку, а при нынешнем её размере запаса здесь от силы на год.

Для архивного или индексированного узла честно посчитайте, а не берите самый большой VPS на автомате: выделенный сервер начинается от $64/mo с 64 GB памяти и 2 × 1 TB NVMe — и это одновременно дешевле и значительно просторнее, чем старший тариф VPS. Если вы планируете хранить цепочку годами или разместить рядом ещё и Electrum-сервер с сайтом, размещённым без KYC, начните сразу с него — вместо двух апгрейдов подряд.

Шаг за шагом: от пополнения в криптовалюте до синхронизированного узла

1. 01Создайте аккаунт на одноразовый emailEmail и пароль. Ни имени, ни телефона, ни документов — с нашей стороны ничего не связывает узел с вами.
2. 02Пополните баланс в криптовалютеПополните предоплаченный баланс через Bitcoin, Monero или любую из 8 монет. Он никогда не сгорает и никогда не замораживается.
3. 03Разверните VPSВыберите тариф, регион и образ Debian или Ubuntu. Root-доступ в среднем готов примерно за минуту.
4. 04Установите Bitcoin Core и проверьте загрузкуВозьмите релиз с сайта проекта Bitcoin Core и сверьте подписи, прежде чем распаковывать архив. Кто пропускает этот шаг, в итоге запускает чужой бинарник.
5. 05Запустите узел от отдельного пользователя под systemdОтдельный пользователь bitcoin, каталог данных в его владении и unit-файл, чтобы узел сам поднимался после перезагрузки.
6. 06Напишите bitcoin.conf, запустите узел и следите за логомЗадайте уровень prune, dbcache и сетевые параметры, запустите службу и следите за логом, пока прогресс проверки не достигнет 1.

Строки bitcoin.conf, которые реально важны

Core поставляется с разумными настройками по умолчанию, и хорошая конфигурация — это обычно шесть-семь строк. Вот те, которые стоит понимать, а не просто копировать с форума.

• dbcache — память для базы UTXO, по умолчанию 450 MB. Поднять его до нескольких тысяч на время первичной синхронизации — самое дешёвое ускорение из всех доступных, а потом значение можно снова понизить.
• prune — предел размера хранилища блоков в MB, минимум 550. Переход от prune к архивному режиму позже означает повторную загрузку всей цепочки, так что решайте до первого запуска.
• txindex=1 — строит полный индекс транзакций. Включайте только если это реально нужно инструменту, которым вы пользуетесь: добавление позже потребует полной переиндексации.
• listen=1 и открытый порт 8333 делают вас узлом, принимающим входящие соединения, до которого могут достучаться другие пиры. Именно это отличает того, кто просто пользуется сетью, от того, кто ей помогает.
• maxuploadtarget — мягкий суточный потолок исходящего трафика, имеет смысл выставить на любом хостинге, который тарифицирует трафик.
• blocksonly=1 — прекращает ретрансляцию отдельных транзакций. Резко снижает расход трафика ценой полезного mempool и участия в распространении транзакций по сети.

Первичная синхронизация: что на самом деле её замедляет

Первая синхронизация — единственная по-настоящему тяжёлая часть работы. Core заново проигрывает всю цепочку, и хотя по умолчанию она пропускает проверку скриптов до определённого недавнего блока, набор UTXO всё равно собирается заново с нуля — так что основная нагрузка приходится на случайные операции с диском и хеширование, а не на скорость вашего интернет-соединения. На NVMe Gen4 с щедрым dbcache полная синхронизация обычно укладывается в куда меньше суток; та же работа на классическом жёстком диске может растянуться на неделю. Дайте узлу больше памяти, а не ядер, и не перезапускайте его от нетерпения: прогресс периодически сохраняется на диск, но перезапуск в момент сброса кэша стоит вам того самого кэша, за который вы платили.

Запуск узла через Tor

Узел, принимающий входящие соединения, объявляет о себе пирам. На обычном clearnet-адресе это объявление публично и прямо указывает на ваш сервер. У Core полноценная поддержка Tor: дайте ему локальный SOCKS-прокси Tor и доступ к control-порту Tor — и он опубликует собственный onion-сервис и будет принимать входящие соединения через него. Добавьте onlynet=onion — и узел вообще перестанет обращаться к clearnet.

Это не то же самое, что запуск узла Tor, который переносит чужой трафик и намеренно публичен. Здесь Tor — это просто способ, которым ваш собственный узел находит своих пиров, и компромисс невелик: узлы, работающие только через onion, синхронизируются немного медленнее и выбирают пиров из более узкого пула — а для машины, которая работает годами без перерыва, это редко становится проблемой.

Трафик: расход, который никто не закладывает в бюджет

Узел, принимающий входящие соединения, отдаёт куда больше данных, чем скачивает. Каждый пир, проходящий собственную первичную синхронизацию, способен утянуть с вас сотни гигабайт, а хорошо подключённый архивный узел с готовностью отдаёт несколько терабайт в месяц, если вы ему это позволите. На тарифе с лимитом это оборачивается счётом за перерасход — это именно тот профиль нагрузки, от которого тарифы «unlimited» на самом деле защищаются в своих условиях. Безлимитная передача данных здесь стандарт для всей линейки, а если вы хотите активно раздавать цепочку другим, линейка 10 Gbps Unmetered от $34.99/mo даёт для этого выделенный порт. Если предпочитаете держать нагрузку скромной, ограничьте отдачу осознанно через maxuploadtarget, а не полагайтесь на случай.

Подключение кошельков, Electrum-сервера или BTCPay

Сам по себе узел — только половина настройки: смысл в том, чтобы с ним говорило именно ваше собственное ПО, а не чужое. Кошельки вроде Sparrow и Specter подключаются напрямую к RPC Core через туннель. Кошелькам с протоколом Electrum нужен промежуточный сервер: electrs или Fulcrum строят собственный индекс из сырых файлов блоков — и это одна из конкретных причин не включать prune. А если вы хотите принимать платежи сами, BTCPay Server, работающий поверх вашего узла, полностью убирает платёжного посредника — та же логика self-hosting, что и в случае с сайтом, размещённым без KYC.

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

Честный компромисс приватности узла, которым вы не владеете

Узел на VPS — не то же самое, что узел под столом у вас дома, и стоит точно понимать почему. Он устраняет самую большую и самую распространённую утечку: обращения к публичным сервисам вида block explorer и к сторонним Electrum-серверам, которые логируют, какими именно адресами вы интересовались. Чего он не устраняет — так это самого хостера. Любой, у кого есть физический доступ к машине, в принципе может прочитать её диск и её память, а полное шифрование диска на удалённом сервере защищает от кражи выключенного накопителя, а не работающего.

Так что дельный вопрос — не «может ли хостер это увидеть», а «знает ли хостер, кто я». Хостинг без KYC отвечает именно на него: email и пароль, без верификации, в деле нечего запрашивать и нечему утекать. Оплата с криптобаланса убирает банк из уравнения. Насколько далеко вы зайдёте в вопросах оплаты — вопрос вашей модели угроз: Bitcoin псевдонимен, а не анонимен, поэтому монеты, прослеженные до верифицированной биржи, всё равно куда-то приводят, а пополнение через Monero закрывает этот разрыв на уровне протокола. Та же логика применима и к ноде Monero — там вы защищаете уже связку «кошелёк — нода».

Ошибки, из-за которых узел зависает, простаивает или остаётся открытым

• Диск переполняется на середине синхронизации, потому что решение о prune приняли постфактум — определитесь до первого запуска, а не на полпути.
• Порт 8333 забыт закрытым в файрволе, поэтому узел делает только исходящие соединения и никогда не обслуживает ни одного пира.
• RPC привязан к 0.0.0.0 «просто для теста» — на публичном IP это находят за считаные часы.
• txindex включили на автомате на небольшом диске, а потом выяснилось, что для отключения нужна полная переиндексация.
• Узел запущен от root из домашнего каталога без systemd-юнита, так что первая же перезагрузка тихо обнуляет весь эксперимент.

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