Розгортування ноди Arbitrum
Arbitrum One — Optimistic Rollup поверх Ethereum. Нода Arbitrum не просто "синхронізує блокчейн" — вона верифікує L2 стан відносно L1, і від конфігурації залежить, який саме рівень довіри ви отримуєте.
Типи нод Arbitrum
Full node — синхронізує всі транзакції і стан, але не верифікує fraud proofs самостійно. Для більшості use cases (RPC для додатку, індексування) — достатньо.
Archive node — зберігає повну історію всіх станів. Потрібна для eth_getStorageAt на історичних блоках, форків для тестування. Вимагає значно більше місця.
Validator node — активно верифікує і може оскаржувати мошеннечні state assertions. Вимагає стейкинг ETH, призначена для операторів рівня біржі/протоколу.
Для переважної більшості завдань потрібна Full node або Archive node.
Системні вимоги
| Тип | CPU | RAM | SSD | Мережа |
|---|---|---|---|---|
| Full node | 4 cores | 8 GB | 500 GB NVMe | 100 Mbps |
| Archive node | 8 cores | 16 GB | 3+ TB NVMe | 200 Mbps |
Arbitrum використовує NVMe — HDD катастрофічно повільний для синхронізації. AWS: c6i.xlarge для full, r6i.2xlarge для archive.
Розгортування через Docker
Офіційний спосіб — Docker Compose. Arbitrum нода (nitro) вимагає підключену Ethereum L1 ноду (Geth, Erigon) або L1 RPC endpoint:
# docker-compose.yml
services:
nitro:
image: offchainlabs/nitro-node:v3.2.0-d81324d
ports:
- "8547:8547" # HTTP RPC
- "8548:8548" # WebSocket
volumes:
- ./arbitrum-data:/home/user/.arbitrum
command:
- --l1.url=https://mainnet.infura.io/v3/${INFURA_KEY}
- --l2.chain-id=42161
- --http.api=eth,net,web3,debug
- --http.corsdomain=*
- --http.addr=0.0.0.0
- --http.vhosts=*
- --ws.port=8548
- --ws.addr=0.0.0.0
- --ws.api=eth,net,web3,debug
- --node.data-availability.enable=false
restart: unless-stopped
Для archive ноди додаємо:
- --node.caching.archive
Снапшоти для швидкої синхронізації
Синхронізація з нуля на Arbitrum One — кілька днів. Arbitrum надає снапшоти для швидкого старту:
# Скачуємо останній снапшот (кілька сотень GB для full node)
curl -O https://snapshot.arbitrum.foundation/arb1/nitro-genesis.tar
# Розпаковуємо в data директорію
tar -xvf nitro-genesis.tar -C ./arbitrum-data/
Після снапшоту нода досинхронізує тільки різницю — від кількох годин до дня.
Моніторинг статусу синхронізації
# Поточний блок ноди
curl -s -X POST -H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
http://localhost:8547
# Статус синхронізації
curl -s -X POST -H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
http://localhost:8547
# false — синхронізована; об'єкт з currentBlock/highestBlock — в процесі
Корисна метрика: відставання від голови ланцюга. Алерт якщо нода відстає > 100 блоків (300 секунд) — ознака проблеми з L1 RPC або disk I/O.
Nitro vs Classic
Arbitrum Classic (стара архітектура до ~2022) — дані до блока 22207817. Nitro — все після. Якщо потрібен доступ до історичних даних до переходу на Nitro — потрібна окрема classic нода або використання Arbitrum's офіційного archive RPC для старих блоків.
Використання ноди
Після синхронізації — стандартний JSON-RPC на http://localhost:8547. Для додатків у тій же мережі docker-контейнерів: http://nitro:8547. Для публічного доступу — nginx з rate limiting перед нодою.
Розгортування full ноди з снапшоту: 4–8 годин (скачування + досинхронізація). Archive нода з нуля: 1–3 дні.