Настройка архивной ноды

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска 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 или состояние контракта два года назад — full node ответит ошибкой. Для этого нужна 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 предоставляет официальные снапшоты для ускорения начальной синхронизации.

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 — свободное место (архивная нода активно растёт)

Настройте алерт на 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-совместимое хранилище дешевле полного копирования каждый раз.