Почему мое Solana-приложение работает медленно: почему расстояние до сети действительно важно

Мы часто слышим от трейдеров и builders:

«Стратегия у меня примерно такая же, но именно мой bot исполняется позже».
«Цены обновляются нормально, а транзакции всё равно не успевают».
«Я уже менял RPC providers, но по ощущениям ничего кардинально не меняется».

Обычно в такой ситуации первым делом подозревают:

«Наверное, у меня медленный код».
«Скорее всего, проблема в характеристиках сервера».

Оба фактора действительно важны.
Но в такой быстрой среде, как Solana, раньше всего часто проявляется более фундаментальное ограничение: расстояние до сети.

В сети Solana работает огромное количество dApps, DeFi-протоколов и рынков, и многие из них опираются на автоматизированную торговлю через ботов. По сути это high-frequency trading (HFT) среда, где тот, кто раньше замечает событие и раньше отправляет действие, получает преимущество и шанс забрать прибыль.

В этой статье разберем, почему именно расстояние до сети становится решающим фактором, когда вы пытаетесь ускорить обнаружение событий и исполнение на Solana, и как Bundle Plans и VPS от ERPC помогают решать эту задачу.

Почему иногда кажется, что «тормозит только моё приложение»

Для начала стоит разложить по полочкам типовые ситуации:

На сервере достаточно CPU и памяти, но сделки всё равно срабатывают медленнее, чем у конкурентов.
Вы видите новые события через getProgramAccounts или log subscriptions, но отправка транзакций постоянно запаздывает.
Вы уже попробовали несколько облачных сред и разных RPC-провайдеров, но прорыва всё равно не произошло.

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

Вы изначально находитесь в "дальней сети".
С точки зрения leader-валидатора ваше приложение физически находится в проигрышной точке.

Если это так, то сколько бы вы ни шлифовали ПО, вы всё равно не выйдете на тот уровень производительности, к которому стремитесь.

Чтобы по-настоящему использовать скорость Solana, нужно смотреть сразу на три слоя:

Code
Hardware
Network

И очень часто начинать стоит именно с расстояния до сети.

Три слоя, которые определяют скорость

Code (ПО и стратегия)

Для ботов и HFT-подобных систем на Solana ваш код и стратегия напрямую влияют на результат:

Какие события вы используете как triggers
При каких условиях входите и выходите из позиции
Насколько избавились от лишнего I/O и насколько хорошо распараллелили обработку

Это самые очевидные рычаги оптимизации для большинства разработчиков. Улучшение кода необходимо, но это только часть картины.

Hardware

Следующий крупный фактор - производительность сервера. Недостаточно просто иметь «достаточно ресурсов», нужно учитывать:

High clock-speed CPU, то есть насколько быстро одно ядро обрабатывает задачи
Количество ядер, то есть сколько задач можно выполнять параллельно
Объём памяти и число memory channels, чтобы большие рабочие наборы данных не упирались в stalls
Быстрое хранилище, например NVMe, чтобы логирование и запись данных не становились bottleneck

Торговые нагрузки часто работают с большими индексами и объемным state. В таком контексте:

Крупный CPU cache
Достаточный запас RAM без риска swapping

дают более стабильную производительность.

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

Network

Именно сеть чаще всего недооценивают, хотя для задержки она нередко оказывается самым важным фактором.

Оптимизация CPU может сэкономить сотни наносекунд или несколько микросекунд.
Оптимизация сети легко меняет картину уже на сотни миллисекунд. По масштабу это может быть разница в тысячу раз.

Даже если у вас:

Мощный сервер
Эффективное ПО
Хорошо продуманная стратегия

неудачно выбранная сеть обнулит значительную часть усилий. Поэтому первый шаг - правильно выбрать дата-центр и сеть для вашего приложения.

Как заново почувствовать, что такое расстояние до сети

Сеть нельзя увидеть так же наглядно, как CPU или RAM, поэтому интуиция здесь часто подводит. Чтобы её восстановить, полезно представить себе транспорт.

Думайте об интернете так:

Ваш сервер - это точка отправления
Solana-валидатор или RPC-эндпоинт - это точка назначения

И мысленно представьте поездку между ними на машине или самолёте.

Короткие маршруты:

Имеют меньше светофоров и пересечений
Меньше страдают от пробок
Обычно дают более предсказуемое время прибытия

Длинные маршруты:

Идут через магистрали, туннели и hub airports
Проходят через большее количество промежуточных точек
Гораздо сильнее зависят от ремонтов, аварий и перегрузок

Поэтому время прибытия начинает заметно гулять.

Сети работают так же:

Чем короче оптоволоконные линии
Чем меньше промежуточных маршрутизаторов и коммутаторов

тем меньше round-trip time и jitter.

Bandwidth (1Gbps, 10Gbps, 25Gbps) похожа на количество полос на дороге.
Чем больше полос, тем больше данных можно передать параллельно и тем ниже риск перегрузки. Но если сам маршрут слишком длинный или идет в обход, итоговое время все равно будет большим.

На Solana реальная скорость требует одновременно:

Достаточно «полос» (bandwidth)
Короткого расстояния и качественного маршрута

Почему структура Solana ещё сильнее усиливает эффект расстояния

В Solana блоки производятся leader-валидаторами, которые меняются каждый слот, и сами лидеры находятся в разных точках мира.

Сейчас большое число валидаторов сосредоточено, например, во Франкфурте. Но даже при этом лидеры постоянно смещаются между:

Франкфуртом
Нью-Йорком
Токио
Сингапуром

и другими регионами по всему миру.

Из этого следует очень простая, но очень важная вещь:

Когда лидер находится во Франкфурте, узлы внутри франкфуртской сети получают явное преимущество.
Когда лидер находится в Токио, выигрывают узлы поблизости от Токио.

Межконтинентальная связь только по одному round-trip ping часто стоит более 100 мс. Например:

Когда вы "догоняете" лидера в Токио из Франкфурта
Или пытаетесь ловить лидера в Нью-Йорке из Токио

то с учетом получения потока Shreds и последующей обработки реальная задержка обнаружения легко может превысить 1000 мс. Для торговых и мониторинговых приложений это огромный разрыв.

Почему смотреть только на среднюю задержку недостаточно

Многие в первую очередь смотрят на:

Average ping
Average response time

Это полезные метрики, но для такой сети, как Solana, где лидеры прыгают по миру слот за слотом, есть огромная разница между:

Хорошей средней величиной
Скоростью именно в те моменты, когда это действительно важно

Даже если какой-то setup показывает среднюю задержку 200 мс, реальная картина может быть такой:

В одних слотах 20 мс
В других слотах 600 мс

Для 0-slot trading или любой стратегии, которая живет в окне 200-400 мс, важна не средняя цифра сама по себе:

Важно, можете ли вы работать с низкой задержкой
В конкретные моменты
В нужном для вас регионе

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

Если смотреть только на average latency и игнорировать эту реальность, очень легко застрять в состоянии "я не понимаю, почему проигрываю".

Как понять, где именно ваше приложение теряет время

Теперь разберём, как локализовать проблему.

Измерьте текущую задержку

Сначала переведите расстояние до текущих эндпоинтов в цифры, а не в ощущения.

Ваши текущие RPC / gRPC / Shredstream endpoints
Nodes, находящиеся в том же регионе, что эти endpoints

Запустите ping-тесты и зафиксируйте базовый round trip.

Не полагайтесь на одно измерение.
Сделайте несколько серий за короткий промежуток времени и смотрите прежде всего на median, а не только на mean. Так вы получите более честную картину "дорожной ситуации" на конкретный день.

Отделите сетевое время от времени обработки в приложении

Внутри самого приложения стоит логировать:

Время отправки запроса
Время получения ответа
Время начала и конца внутренней обработки

Дальше разделите:

Сколько времени уходит на сетевые round trip
Сколько тратится на собственно бизнес-логику

Очень часто выясняется следующее:

Ваш код заканчивает работу за несколько миллисекунд или десятки миллисекунд
А сетевые round trip съедают сотни миллисекунд

Типовые bottleneck patterns

Часто встречаются такие сценарии:

Один и тот же RPC-эндпоинт используется по всему миру
Подключение идет из дома или офиса через несколько слоев VPN и прокси
Серверы стоят в одном регионе и оттуда пытаются догонять всех лидеров по всей планете

В таких архитектурах сама структура Solana почти гарантирует, что часть лидеров вы всегда атакуете из проигрышной точки.

Как строить архитектуру так, чтобы расстояние до сети играло на вашей стороне

Чтобы расстояние до сети помогало, а не мешало, важно пройти несколько шагов.

Сначала определите, в какой сети вы вообще играете

Для Solana важна прежде всего сеть, которую формируют валидаторы.
Поскольку количество leader-слотов пропорционально величине stake, то:

Сети, в которых размещены валидаторы с крупным stake

на практике становятся «основными сетями».

Имеет смысл сначала понять:

Какие регионы ближе к рынкам или dApps, на которых держится ваша стратегия
Как вы собираетесь покрывать такие stake-heavy регионы, как Франкфурт

Именно так определяется, в каких сетях вам вообще нужно конкурировать.

Выбор дата-центра и сети

Для Solana-нагрузок принципиально важно понимать:

Находитесь ли вы в том же дата-центре, что ключевые валидаторы или Jito Block Engine
Или хотя бы подключены к ним через PNI (Private Network Interconnect)

Интернет глобален, и приложение в целом будет «работать» почти где угодно.
Но для HFT и near-real-time обнаружения ключевой вопрос другой:

Сколько внешнего сетевого пути можно убрать?
Насколько близко можно подойти к zero-distance конфигурации?

Именно эти решения создают первый крупный разрыв в производительности.

Переход к multi-region архитектуре

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

Практичный первый шаг выглядит примерно так:

Франкфурт как основной регион
И еще один регион, критичный для вашей стратегии: Нью-Йорк, Токио, Сингапур и т.д.

Потом от этого минимального набора можно постепенно расширяться.

В каждом регионе вы:

Получаете Shreds и gRPC локально
Либо обрабатываете всё локально, либо пересылаете по собственной сети кратчайшим маршрутом

Так становится намного проще поддерживать состояние, в котором вы "где-то всё время быстрые".

Сетевой дизайн ERPC и роль Bundle / VPS

Теперь приложим всё сказанное к архитектуре ERPC.

Solana-focused сеть и архитектура на базе PNI

ERPC изначально строится как сеть, заточенная именно под Solana. Мы тщательно подбираем:

Регионы с высокой концентрацией stake
Дата-центры, где размещаются крупные валидаторы и Jito Block Engine
Дата-центры, напрямую связанные с ними через PNI

Так формируется topology, способная выдавать максимальный результат именно для Solana-нагрузок.

Интернет глобален, и приложение технически запустится почти где угодно.
Но если для вас важны HFT и быстрое обнаружение событий, сначала нужно правильно выбрать и дата-центр, и сеть. ERPC как раз и строился под решение этой проблемы.

Автоматическая маршрутизация по ping

Для shared Solana RPC-эндпоинтов ERPC не полагается только на IP geolocation.
Вместо этого мы:

Автоматически измеряем ping из каждого региона до каждого whitelisted IP
Выбираем ближайший регион по реальным измерениям

Это позволяет избежать ситуаций, когда:

На карте маршрут кажется коротким, а в реальности идёт длинным обходом
Решение принимается на основе устаревших geo-location databases

В итоге соединение идёт по кратчайшему маршруту из тех, что реально подтверждаются на практике.

Solana RPC Bundle Plans

Solana RPC Bundle Plans дают в одном пакете:

RPC (HTTP / WebSocket)
Geyser gRPC (без ограничений по filters)
Shredstream gRPC

Большинство команд начинает путь к работе с данными в реальном времени на Solana именно с Geyser gRPC. Поскольку он отдает уже декодированные данные:

Его проще внедрять
Для него много примеров и reference materials
Порог входа заметно ниже

Затем профессиональные команды добавляют Shredstream, чтобы приблизить обнаружение событий и исполнение к leading edge.

С Bundle Plans:

Можно сохранить текущий production setup на RPC / gRPC
И при этом добавить Shredstream без резкого роста затрат

Ценообразование устроено так, чтобы вы могли:

Сначала собрать стабильное базовое приложение на RPC + gRPC
А затем в том же окружении подключить Shredstream и постепенно идти к более высокой производительности

И все это без остановки production-систем.

EPYC VPS / Premium Ryzen VPS

Чтобы еще сильнее сократить расстояние до сети, ERPC также предлагает VPS в той же сети, где работают эндпоинты ERPC.

В линейку входят:

EPYC VPS с сильным соотношением цены и производительности
Premium Ryzen VPS на базе Ryzen CPU 5.7GHz

Эти среды дают:

High clock-speed CPU
Память ECC DDR5
Хранилище NVMe4
Сеть 25Gbps × 2

в конфигурациях, настроенных именно под Solana-нагрузки.

Эти VPS работают в той же сети, что:

Jito Block Engine
ShredStream-узлы
Geyser gRPC-узлы

Такая «zero-distance» конфигурация позволяет запускать приложение рядом с leaders, не проходя через внешние сети.

Комбинируя Bundle Plans с этими VPS, можно одновременно оптимизировать:

Расстояние до сети
Производительность аппаратной части
Качество потоков данных

и построить прочную основу для use cases, чувствительных к задержке.

С чего начать: checklist

Вот несколько шагов, которые стоит сделать сразу после этой статьи:

Измерьте ping до текущих RPC / gRPC / Shredstream-эндпоинтов
Делайте это несколько раз подряд за короткий интервал и смотрите на median, а не на один удачный sample.
Добавьте в приложение логи, которые разделяют сетевое время и время обработки
Измеряйте отправку запроса, получение ответа и внутреннюю обработку между этими точками.
Проверьте, какие регионы действительно близки к вашим целевым рынкам или dApps
Если возможно, измерьте ping из нескольких кандидатных регионов, чтобы опираться на данные, а не только на интуицию.
Разверните один VPS или Bundle в регионе, близком к вашей ключевой аудитории, и проведите сравнение
Зафиксируйте, насколько снизилась задержка по сравнению с вашим текущим окружением.
При необходимости переходите к multi-region архитектуре
Например: Франкфурт + Нью-Йорк, Франкфурт + Токио или Франкфурт + Сингапур, в зависимости от вашей стратегии.
На более длинной дистанции собирайте данные по leader schedules и расположению валидаторов
Это позволит понять, какие регионы получают преимущество в какие периоды, и постепенно настраивать сеть под epoch-by-epoch изменения.

Итог: почему начинать нужно именно с расстояния до сети

Если вы хотите строить быстрые trading- или monitoring-системы на Solana, нужно одновременно смотреть на код, аппаратную часть и сеть. И среди этих трех факторов расстояние до сети:

Является одним из самых сильных рычагов улучшения
И при этом чаще всего недооценивается

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

Именно поэтому первым делом стоит:

Корректно измерить свое расстояние до сети
Понять, в каких сетях вы вообще конкурируете
Перенести приложения туда, где для Solana это действительно имеет смысл

Это и есть первые шаги к настоящей производительности.

ERPC и Validators DAO предоставляют Solana-focused сети и серверные ресурсы, чтобы такие архитектуры были не теорией, а практикой.

Если вы хотите обсудить оптимизацию расстояния до сети или понять, как лучше построить ваш Bundle и VPS setup, обращайтесь в официальный Discord Validators DAO.

ERPC official site: https://erpc.global/en
Validators DAO official Discord: https://discord.gg/C7ZQSrCkYR