Развёртывание ноды Arbitrum
Arbitrum One — Optimistic Rollup поверх Ethereum. Нода Arbitrum не просто "синхронизирует блокчейн" — она верифицирует L2 состояние относительно L1, и от конфигурации зависит, какой именно уровень доверия вы получаете.
Типы нод Arbitrum
Full node — синхронизирует все транзакции и состояние, но не верифицирует fraud proofs самостоятельно. Для большинства use cases (RPC для приложения, индексирование) — достаточно.
Archive node — хранит полную историю всех состояний. Нужна для eth_getStorageAt на исторических блоках, форков для тестирования. Требует значительно больше места.
Validator node — активно верифицирует и может challeng'ить мошеннические 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 node (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 дня.