Мережевий стек валідатора Solana — це не просто «підключення до інтернету». Консенсус Turbine розраховує на те, що кожен вузол отримує та ретранслює блоки за суворими часовими рамками. Будь-яке звуження каналу, сплеск джиттера або заблокований порт безпосередньо призводить до пропущених слотів (skipped slots) і втрати винагород. Нижче — перевірені операційні дані про те, який саме трафік генерує валідатор, які порти необхідні та як перевірити мережу до запуску.
Операційні вимоги для «Мережеві вимоги валідатора: пропускна здатність, latency, порти» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Обсяг трафіку валідатора
Валідатор Solana обмінюється даними з мережею безперервно, навіть коли не є лідером. Трафік складається з кількох типів:
- Gossip-протокол (UDP та TCP) — періодичні обміни статусами (push/pull) з сусідами по кластеру. Кожен цикл передає компактні серіалізовані структури з хешами, інвалідаціями та інформацією про лідера.
- Turbine-розповсюдження блоків (UDP) — найбільш інтенсивний компонент. Коли лідер транслює блок, він розбивається на shards (шарди), які передаються деревоподібною топологією. Валідатор отримує свої шарди та ретранслює їх нижчим рівням дерева.
- Ретрансляція транзакцій (UDP/TCP) — якщо валідатор приймає транзакції від користувачів або інших вузлів, він пересилає їх до поточного лідера.
- RPC-запити (TCP) — лише якщо на вузлі увімкнено RPC-endpoint. Цей трафік залежить від кількості клієнтів і не є обов'язковим для валідатора.
Сукупний обсяг inbound та outbound трафіку на mainnet-beta типово становить від 300 МБ до 1 ГБ на годину в спокійні періоди та може значно зростати під час спайків активності. Точні цифри залежать від розміру блоків у конкретний період, тому оператор має орієнтуватися на моніторинг власного інтерфейсу, а не на фіксовану норму.
Мінімальна та рекомендована пропускна здатність
Клієнт: agave-validator (Agave), кластер: mainnet-beta, дата перевірки: червень 2025.
| Параметр | Мінімум (працездатність) | Рекомендація (продакшн) |
|---|---|---|
| Пропускна здатність (inbound + outbound) | 1 Гбіт/с | 10 Гбіт/с |
| Тип інтерфейсу | 1GbE (RJ45) | 10GbE (SFP+ або RJ45 Cat6a) |
| Білінг трафіку | Безлімітний або >5 ТБ/місяць | Безлімітний |
Чому 1 Гбіт/с — це мінімум, а не норма. Теоретично валідатор може функціонувати на 1GbE-інтерфейсі, але в моменти пікового навантаження інтерфейс стає вузьким місцем: пакети Turbine втрачаються, валідатор не встигає ретранслювати шарди, і сусіди по дереву позбавляють його лідерства. На 10GbE такі ситуації практично виключені за умови, що провайдер не має власних перевантажень.
Типова помилка: оренда сервера з 10GbE-інтерфейсом, але з фактичним лімітом каналу 1 Гбіт/с на рівні дата-центру. Завжди перевіряйте реальну пропускну здатність iperf3 до зовнішнього вузла, а не лише специфікацію NIC.
Latency та джиттер: допустимі межі
Solana використовує фіксовані часові слоти (на mainnet-beta — близько 400 мс). Лідер має сформувати блок, розповсюдити його через Turbine, а валідатори — проголосувати (vote) до закінчення слота. Мережева затримка прямо зменшує час, відведений на обчислення та серіалізацію.
- Latency до більшості сусідів по Gossip: <50 мс — комфортна зона; 50–100 мс — допустимо, але зменшує запас часу; >100 мс — ризик пропущених голосувань.
- Джиттер (варіація затримки): <10 мс — норма; 10–30 мс — прийнятно за умови стабільного медіану; >30 мс — свідчить про нестабільність маршруту або перевантаження каналу.
- Packet loss: 0% на локальному сегменті; >0.1% на магістральному каналі — привід для розслідування або зміни провайдера.
Варто розуміти, що latency вимірюється не до «інтернету загалом», а до конкретних сусідів у Gossip-табличці валідатора. Оператор не може обрати, з ким саме зв'язуватися, але може забезпечити мінімальну базову затримку до основних магістралей, де розміщені інші валідатори.
Порти, які потрібно відкрити
Клієнт Agave використовує обмежену кількість портів. Усі інші повинні бути закриті на рівні хостового фаєрвола.
| Порт | Протокол | Призначення | Напрямок | Обов'язковість |
|---|---|---|---|---|
| 8000–8020 | UDP + TCP | Gossip-протокол: обмін статусами, Turbine-розповсюдження | Inbound та Outbound | Обов'язково |
| 8899 | TCP | JSON-RPC (якщо увімкнено --rpc-port) | Inbound | Тільки за потреби |
| 9100 (або інший) | TCP | Metrics (Prometheus, --metrics-port) | Inbound (від внутрішнього моніторингу) | Рекомендовано, не назовні |
Увага: Gossip-порт за замовчуванням — 8001, але клієнт може використовувати діапазон 8000–8020 залежно від конфігурації та версії. Рекомендується відкривати весь цей діапазон, щоб уникнути проблем при оновленнях.
UDP — критично важливий. Turbine працює виключно через UDP. Якщо фаєрвол або провайдер блокує або обмежує UDP-трафік (наприклад, через NAT або rate-limiting), валідатор не зможе отримувати та ретранслювати блоки. Це одна з найпоширеніших причин «мовчазних» відмов: вузл здається здоровим у Gossip, але не отримує дані Turbine.
Не відкривайте SSH (22) та інші адміністративні порти для всього інтернету. Використовуйте VPN, бастіон-хости або ACL за IP-адресами операторів.
Налаштування мережевого інтерфейсу
Базові кроки для сервера на Ubuntu 24.04 LTS з інтерфейсом enp1s0f0 (10GbE). Адаптуйте ім'я інтерфейсу під ваше оточення.
1. Вимкнути offloading, який заважає UDP. Деякі механізми offloading NIC генерують фрагментовані пакети або спотворюють порядок доставки, що критично для Turbine.
sudo ethtool -K enp1s0f0 rx off tx off tso off gso off gro off lro off
Ризик: відключення offloading зменшує пропускну здатність на дуже високих навантаженнях (>5 Гбіт/с стабільного трафіку). Для типових навантажень валідатора це прийнятний компроміс. Якщо після вимкнення спостерігається зростання CPU-утилізації на обробку переривань, розгляньте selective offloading: залиште rx увімкненим, але вимкніть tso та gso.
2. Збільшити розмір кільця прийому (ring buffer). Зменшує ймовірність втрати пакетів при сплесках.
sudo ethtool -G enp1s0f0 rx 4096 tx 4096
3. Зробити налаштування стійкими до перезавантаження. Додайте команди у /etc/network/if-up.d/ або у systemd service, оскільки ethtool не зберігає зміни між перезавантаженнями.
4. Налаштувати sysctl для мережевого стека.
net.core.rmem_max = 134217728
net.core.rmem_default = 16777216
net.core.wmem_max = 134217728
net.core.wmem_default = 16777216
net.core.netdev_max_backlog = 5000
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192
Застосувати без перезавантаження: sudo sysctl -p /etc/sysctl.d/99-solana-network.conf
5. Перевірити, що інтерфейс працює на очікуваній швидкості.
ethtool enp1s0f0 | grep "Speed:"
Очікуваний результат: Speed: 10000Mb/s (для 10GbE). Якщо показує 1000Mb/s — перевірте кабель, SFP-модуль та налаштування комутатора.
Перевірка мережевого з'єднання
Перед запуском валідатора та після будь-яких змін інфраструктури виконайте наступні перевірки.
1. Базова пропускна здатність (iperf3). Запустіть сервер на віддаленому вузлі та підключіться з валідатора:
iperf3 -c <remote_ip> -p 5201 -t 30 -P 4
Очікуваний результат: ≥9 Гбіт/с на 10GbE-інтерфейсі. Якщо результат <5 Гбіт/с — проблема на рівні каналу, комутатора або NIC.
2. Latency та джиттер (MTR).
mtr -r -c 100 -u <gossip_peer_ip>
Прапорець -u вмикає UDP-режим, що релевантніше для Turbine. Оцініть середню затримку (Avg) та стандартне відхилення (StDev) на фінальному хопі. StDev >20 мс — привід для розслідування.
3. Втрата пакетів (ping).
ping -c 1000 <gossip_peer_ip>
Очікуваний результат: 0% packet loss. Будь-яка втрата на прямому маршруті до сусіда по Gossip вимагає звернення до провайдера.
4. Перевірка відкритих портів ззовні. З іншого вузла (не з localhost):
nc -zuv <validator_ip> 8001
Очікуваний результат: Connection to <validator_ip> 8001 port [udp/*] succeeded!
Якщо з'єднання не вдається, але локально порт слухається — проблема в фаєрволі дата-центру або провайдера.
5. Перевірка після запуску валідатора. Коли agave-validator працює, перевірте стан Gossip-з'єднань:
solana gossip --url http://127.0.0.1:8899
Очікуваний результат: валідатор бачить десятки сусідів (peers), має статус Peer або Leader, а не Unknown. Якщо кількість сусідів менша за 10–15 — перевірте UDP-зв'язність повторно.
Наступний крок: після підтвердження мережевої готовності перейдіть до вибору дата-центру, де географічне розташування та якість магістралей доповнять налаштований інтерфейс.