Пропускная способность и задержка: два скрытых KPI валидатора

Большинство людей, которые поднимают ноду, совершают одну и ту же ошибку. Заходят на сайт хостинга, выбирают максимально жирный CPU, проверяют поколение оперативки, убеждаются, что диск — NVMe. И считают, если железо соответствует минимальным требованиям из документации, значит, награды будут максимальными.

Не будут.

Почему CPU и RAM не вся история

Как только вы закрыли базовые требования по железу, оно перестаёт быть узким местом. Блокчейны — это распределённые конечные автоматы. Узкое место — не ваш сервер, а канал между ним и всеми остальными нодами в кластере.

Если CPU быстрый, а сеть медленная, нода большую часть времени просто ждёт. Ждёт последний блок. Ждёт голоса других валидаторов. Ждёт, пока её собственная подпись дойдёт до лидера. К моменту, когда мощный процессор обработает данные, сеть уже на следующем блоке.

Когда вы оптимизируете железо вместо связности, вы оптимизируете не ту метрику. В блокчейн-хостинге скорость коммуникации важна не менее скорости вычислений.

KPI №1 — Пропускная способность

Многие операторы смотрят на месячную статистику трафика и успокаиваются: израсходовано 30% канала, всё нормально. Но в нод-хостинге средняя утилизация канала вторична. Важна burst capacity — способность обработать пиковую нагрузку.

Блокчейн-сети не передают данные ровным потоком. Они работают импульсами. Когда появляется новый блок, каждая нода в сети пытается получить эти данные в один и тот же момент. Это создаёт резкие всплески трафика.

Проблема gossip-протокола

Большинство блокчейнов распространяют данные через gossip-протокол. Одна нода передаёт трём, те трём — девяти, и так далее. Если ваш сетевой интерфейс упирается в лимит во время такого всплеска — вы теряете пакеты.

Потеря пакетов запускает цепную реакцию: нода запрашивает данные повторно, к моменту получения уже отстаёт от кластера, пропускает окно для голосования по блоку. И вот вы уже в хвосте.

Бенчмарк пропускной способности

Не стоит верить надписи «1 Gbps» в тарифе на слово. Нужно знать, как этот канал ведёт себя под пиковой нагрузкой. Проверить реальную пропускную способность между нодами можно через iperf3:

# Проверка скорости соединения с пиром
iperf3 -c [peer_ip_address] -p 5201 -t 10

Если в выводе много retransmissions — соединение нестабильно. Часто это признак того, что провайдер оверселлит магистраль. Для стабильной работы стоит рассмотреть выделенные серверы с выделенным каналом.

KPI №2 — Задержка

Если пропускная способность — это ширина трубы, то задержка — время, за которое один пакет проходит от точки A до точки B.

Во многих PoS-сетях валидаторы должны согласовать состояние цепочки в очень узком временном окне. В высокопроизводительных сетях вроде Solana слот-тайм может составлять 400 мс. Если сетевая задержка добавляет 150 мс, на обработку данных и подпись блока остаётся 250 мс. Не уложились — не заработали.

География консенсуса

Если большинство валидаторов конкретной сети сидят во Франкфурте, а ваша нода — в Сингапуре, вы начинаете каждый раунд с гандикапом. Физическое расстояние создаёт задержку на уровне скорости света, и никакое количество оперативки её не исправит.

Цифры ориентировочные и основаны на стандартной маршрутизации по оптоволокну.

Если голос приходит поздно, протокол считает, что вы были офлайн. Результат — урезание наград или пропуск комиссий за транзакции. 

Миф: для валидатора подойдёт любой облачный провайдер

Распространённое заблуждение: виртуалка у обычного облачного провайдера ничем не хуже специализированного сервера. На практике generic VM проигрывают для валидаторов. Вот почему:

• Оверселл портов. Многие провайдеры продают 1 Gbps, но реально вы получите долю от этого, когда соседи по свитчу активны.
• Маршрутизация через кучу хопов. Публичные облака экономят на маршрутах — больше хопов, выше вероятность packet loss и задержек.
• P2P-трафик и CDN. CDN не помогает с пиринговым трафиком. Здесь решают физическое расположение и BGP-маршрутизация.
• DDoS-риски. Крупные облачные IP-диапазоны — частая мишень для атак. Если сосед по подсети попал под DDoS, ваша нода тоже просядет.
• Репутация IP. Если ваш адрес раньше использовался для спама или атак, другие ноды могут троттлить соединение с вами.
• Cold potato routing. Некоторые провайдеры передают ваш трафик другому оператору как можно быстрее, даже если у того маршрут длиннее. Экономия провайдера, задержка ваша.

Если размещение валидатора выбрано наугад, награды тоже будут непредсказуемыми. Операторы, которые подходят к этому серьёзно, выбирают VPS-тарифы с оптимизированными сетевыми маршрутами.

Архитектура валидатора: Core + Sentry

Профессиональные операторы используют Sentry Node архитектуру как щит для основного валидатора.

Core Validator хранит приватные ключи и подписывает блоки. У него нет публичного IP, он общается только с вашими Sentry-нодами.

Sentry Nodes — публичная часть инфраструктуры. Они принимают gossip-трафик, фильтруют данные и передают только валидное на Core.

Архитектура позволяет масштабировать пропускную способность, добавляя Sentry-ноды. Если одна попадает под DDoS, Core продолжает подписывать блоки через остальные. Подробнее о защите — в статье о настройке DDoS-защищённого хостинга.

Sentry-ноде не нужен мощный процессор — Medium VPS (3 vCPU, 4 ГБ RAM, безлимитный трафик, $21.24/мес.) закрывает gossip-трафик для большинства сетей. Core Validator требует больше — Elite, Exclusive или выделенный сервер, в зависимости от блокчейна.

Что мониторить

Конкретные сетевые метрики, за которыми стоит следить:

• Jitter — разброс задержки. Если пинг скачет между 20 мс и 200 мс, нода не сможет держать синхронизацию.
• Packet loss. Всё, что выше 0.1% — повод разбираться. Обычно это перегрузка или умирающий компонент сети.
• Количество пиров. Если число подключённых пиров резко падает, вашу ноду, скорее всего, ограничивают.
• Утилизация исходящего трафика. Если outbound стабильно упирается в лимит, вы не контрибьютите в сеть. Пиры начнут дропать соединение с вами.

Проверка стабильности сети

Утилита mtr покажет, где именно теряются пакеты или растёт задержка:

# Трассировка до пира или блок-эксплорера
mtr -rw [target_ip]

Ищите хоп посередине маршрута с высокой задержкой или потерями. Если лаг начинается с первого хопа, то проблема на стороне вашего провайдера.

Компромиссы: качество стоит сложности

Оптимизация сети — это баланс между производительностью, операционной сложностью и стоимостью.

• Географическое распределение. Sentry-ноды в нескольких странах улучшают задержку глобально, но добавляют серверов, которые нужно поддерживать и мониторить.
• Слои сетевой абстракции. Каждый дополнительный слой между интернетом и валидатором добавляет внутреннюю задержку. Внутренняя сеть должна быть максимально быстрой.
• Стоимость трафика. Перегон данных между Sentry в одном регионе и Validator в другом может быть дорогим — большинство провайдеров тарифицируют исходящий трафик из региона.

Для большинства операторов задача — найти баланс: достаточно избыточности для надёжности, достаточно скорости для конкурентоспособности, но не настолько много сложности, чтобы всё время уходило на починку конфигов. Подробнее о выборе конфигурации в нашем гайде по подбору тарифа.

Итог: вы оптимизируете железо или размещение?

Запустите iperf3 и mtr с текущей ноды. Если retransmissions выше 1% или jitter больше 50 мс — узкое место не железо, а хостинг. Проверьте аллокацию порта и маршрутизацию у провайдера, прежде чем апгрейдить CPU или RAM.

Если нужен безлимитный трафик с нешаренным 1Gbps портом — вот тут  тарифы VPS от Medium и выше для валидаторных нагрузок.