Налаштування архівної ноди

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Налаштування архівної ноди
Середній
~3-5 днів
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1308
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1221
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    921
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1149
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    611
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    886

Налаштування архівної ноди

Звичайна повна нода (full node) зберігає лише поточний стан блокчейну плюс кілька тисяч останніх блоків. Це достатньо для більшості операцій: відправлення транзакцій, читання поточних балансів, виклик view-функцій контрактів. Але якщо вам потрібно дізнатися баланс адреси на блоці 15 000 000 або стан контракту два роки тому — повна нода повернуть помилку. Для цього потрібна archive node.

Archive node зберігає state trie для кожного блоку в історії мережи. Це потребує колосального дискового простору:

Мережа Full Node Archive Node
Ethereum mainnet ~1 TB ~18+ TB (2024)
BSC ~1.5 TB ~3+ TB
Polygon PoS ~600 GB ~8+ TB
Arbitrum One ~300 GB ~4+ TB
Optimism ~200 GB ~2+ TB

Коли реально потрібна archive нода

Перш ніж розгортувати archive — перевірте, чи не підходить альтернатива:

  • Для аналітики історичних даних — часто достатньо The Graph subgraph або Dune Analytics, у них уже індексовані історичні дані
  • Для розовых запитів — можна використовувати платні archive RPC (Alchemy, Infura, QuickNode з archive доступом)
  • Для регулярних запитів у production — тоді власна archive нода виправдана

Власна archive нода потрібна коли: високий обсяг archive-запитів робить платні RPC дорогими, потрібна низька затримка, потрібна конфіденційність запитів, потрібен кастомний трейсинг (debug_traceTransaction, trace_block).

Ethereum Archive Node (Erigon)

Geth archive займає 18+ TB та історично повільний. Erigon — альтернативна реалізація, яка зберігає archive дані значно компактніше (~3 TB для Ethereum) за рахунок іншої структури зберігання та етапної синхронізації:

# Установка Erigon
git clone https://github.com/ledgerwatch/erigon
cd erigon
make erigon

# Або через релізний бінарник
wget https://github.com/erigontech/erigon/releases/latest/download/erigon_linux_amd64.tar.gz

Конфігурація Erigon для archive

erigon \
  --datadir=/data/erigon \
  --chain=mainnet \
  --prune='' \             # порожня строка = archive (зберігати все)
  --http \
  --http.addr=0.0.0.0 \
  --http.port=8545 \
  --http.api=eth,erigon,web3,net,debug,trace,txpool \
  --ws \
  --ws.port=8546 \
  --torrent.download.rate=512mb \   # прискорює початкову завантаження через BitTorrent
  --metrics \
  --metrics.addr=0.0.0.0 \
  --metrics.port=6060

Ключове: --prune='' означає archive режим. Якщо вказати --prune=hrtc — це режим full node з агресивною обрізкою.

Етапи синхронізації Erigon

Erigon синхронізується поетапно (stages), що дозволяє возобновити синхронізацію після перерви:

Stage 1: Headers         (~1 GB, швидко)
Stage 2: Block Bodies    (~500 GB, повільно)
Stage 3: Senders         (відновлення адрес з підписів)
Stage 4: Execution       (виконання всіх транзакцій — найдовше, 3-7 днів)
Stage 5: Hash State      (побудова state trie)
Stage 6: Intermediate Hashes
Stage 7: History Index   (індекс змін state за блоками)
Stage 8: Log Index
Stage 9: Tx Lookup
Stage 10: Finish

Повна синхронізація Ethereum archive на NVMe: 5–14 днів залежно від залізо.

Вимоги до сервера для Ethereum Archive

CPU:  16+ cores (етап Execution CPU-intensive)
RAM:  64 GB (32 GB мінімум, буде swap та повільно)
Disk: 4 TB NVMe SSD (не HDD, не SATA SSD — лише NVMe)
Net:  1 Gbps

Arbitrum / Optimism Archive (Nitro / OP Stack)

L2 archive ноди технічно простіше та компактніше:

# Arbitrum Nitro archive
docker run --rm -it \
  -v /data/arbitrum:/home/user/.arbitrum \
  -p 8547:8547 \
  offchainlabs/nitro-node:latest \
  --node.chain-id=42161 \
  --parent-chain.connection.url=$L1_RPC_URL \
  --http.api=eth,web3,net,arb,debug \
  --node.archive \     # archive режим
  --init.url=https://snapshot.arbitrum.io/mainnet/nitro.tar  # snapshot для швидкого старту

Arbitrum надає офіційні snapshots для прискорення початкової синхронізації.

Reth: альтернатива для Ethereum

reth (Rust Ethereum) — нова реалізація від Paradigm, дуже швидка синхронізація:

reth node \
  --datadir /data/reth \
  --chain mainnet \
  --full \              # archive за замовчуванням у reth
  --http \
  --http.api "eth,net,web3,debug,trace" \
  --ws

Reth показує швидшу синхронізацію, ніж Erigon на деяких конфігураціях, але менш зрілий за стабільністю (2024).

Моніторинг та health check

# Перевірити, що нода в archive режимі — запросити старий баланс
curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc":"2.0",
    "method":"eth_getBalance",
    "params":["0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045", "0xF4240"],
    "id":1
  }'
# Блок 0xF4240 = 1000000. Якщо повернуть баланс — archive працює.
# Якщо повернуть помилку "missing trie node" — це full node, не archive.

Prometheus + Grafana моніторинг

Erigon та Reth експортують метрики у форматі Prometheus. Ключові метрики для dashboard:

  • erigon_stages_progress — прогресс кожного етапу синхронізації
  • chain_head_block — поточний блок
  • p2p_peers — кількість пірів
  • system_disk_free — вільне місце (archive нода активно росте)

Налаштуйте алерт на system_disk_free < 500 GB — без попередження нода впаде через заповнений диск.

Зберігання snapshot та бекапи

Archive ноду пересинхронізувати з нуля — втрата кількох днів. Бекапи критичні:

# Erigon: зупинити ноду, створити snapshot через cp або rsync
systemctl stop erigon
rsync -avz --progress /data/erigon/ backup-server:/backup/erigon-$(date +%Y%m%d)/
systemctl start erigon

# Або використовувати LVM snapshot якщо сервер на LVM
lvcreate -L100G -s -n erigon-snap /dev/vg0/erigon-data

Incremental бекапи через rclone на S3-сумісне сховище дешевше, ніж полне копіювання щоразу.