Своя нода — це межа між «повірити комусь на слово про ланцюг» і «перевірити самому». Ваша нода незалежно застосовує кожне правило консенсусу, а гаманці можуть питати вашу ноду замість публічного сервера, який тихо логує всі ваші адреси. Стіна, об яку спотикаються: повній архівній ноді потрібно 600 ГБ+ диска, і вона тільки зростає. Pruned-нода це обходить — вона так само валідує весь ланцюг, а потім викидає старі блоки, які більше не потрібні, і вкладається приблизно в 10–15 ГБ. Це влазить у невеликий VPS. Нижче — чесне «як» і в що вам обходиться прунінг.
Що реально дає нода
- Незалежна валідація. Правила застосовуєте ви самі. Нічого невалідного не пройде через вашу ноду через те, що вона повірила незнайомцю.
- Приватність власних запитів. Гаманець питає вашу ноду, а не публічний оглядач, який бачить кожну адресу, яку ви дивитеся.
- База для решти. Нода — фундамент, на який потім стає інше: Lightning, оглядачі, ваші застосунки.
Pruned проти повної — чесна суть
Під час початкової синхронізації нода завантажує й перевіряє весь ланцюг. Це приблизно 600 ГБ трафіку, один раз. Прунінг міняє лише те, що відбувається після: вона тримає свіжі блоки й скидає старі, тому підсумковий диск лишається маленьким.
Те, чим ви жертвуєте, реальне: pruned-нода не може віддавати історичні блоки іншим пірам і не може пересканувати довільну стару історію гаманця. Тож якщо будете імпортувати старий гаманець із ранніми транзакціями, потрібна повна історія — повна нода на великому диску, а не pruned. Для того щоб просто валідувати й ганяти поточні гаманці, pruned — саме те, що треба.
Що потрібно
- Диск: ~15–20 ГБ для pruned-ноди — маленької машини вистачає.
- Оперативка: 2–4 ГБ. Більше
dbcache— швидше початкова синхронізація; потім можна знизити. - Канал: нормальна пропускна здатність для разового повного завантаження.
- Доступний IP: щоб приймати вхідних пірів на порт 8333 і реально допомагати мережі, потрібен публічний IP з відкритим 8333 — тариф із виділеним IP. На NAT у вас один SSH-порт, і 8333 не відкрити.
Встановлення
Поставте bitcoind, потім мінімальний bitcoin.conf:
prune=10000 # тримати ~10 ГБ свіжих блоків
dbcache=2048 # швидше початкова синхронізація; потім знизити
listen=1 # приймати вхідних пірів
Запустіть під systemd, щоб рестартував після падіння й піднімався після ребуту, і відкрийте порт 8333, щоб піри до вас достукалися. Потім дайте синхронізуватися — це довга частина, від годин до доби-двох, бо ланцюг перевіряється від генезису.
Закрийте машину
- SSH лише за ключами, фаєрвол на 8333 і ваш SSH-порт. (Чек-лист на десять хвилин.)
- Ніколи не виставляйте RPC-порт в інтернет. Прив'яжіть його до localhost і ходіть через SSH-тунель або лише із застосунків на тій самій машині. Відкритий RPC — відчинені двері.
Чесні обмеження
- Перша синхронізація довга й ненажерлива до трафіку. Це неминуче — перевірку ланцюга з нуля не обійти конфігом.
- Pruned-нода не віддає старі блоки й не пересканує стару історію. Потрібно це? Тоді повна нода й великий диск.
- Про Monero питання справедливе, і чесна відповідь — про охоплення. Його ланцюг більший — пара сотень ГБ, і навіть pruned близько 90 ГБ, — тож йому потрібен диск більший, ніж несуть наші невеликі тарифи. Це історія про повну ноду на іншій машині, і ми краще скажемо прямо, ніж вдамо, що вона влазить.
- Обслуговування на вас: оновлення, диск, рідкі затримки з пірами. Нода — невелике зобов'язання, а не «поставив і забув».
Як платити
Реєстрація за email, оплата в USDC чи USDT — без картки й без документів. Логічний спосіб оплатити свій власний куточок Bitcoin.