Если для производительности Solana-приложения вы хотите выиграть даже 20 мс, ключевую роль играют выделенные RPC-эндпоинты и SWQoS

Если для производительности Solana-приложения вы хотите выиграть даже 20 мс, ключевую роль играют выделенные RPC-эндпоинты и SWQoS

Если для производительности Solana-приложения вы хотите выиграть даже 20 мс, ключевую роль играют выделенные RPC-эндпоинты и SWQoS
В высокочастотной торговле и других критичных Solana-приложениях даже 20 мс могут оказаться решающими. Выделенные RPC-эндпоинты и общие RPC-эндпоинты изначально устроены по-разному, и этот разрыв в 20 мс невозможно полностью закрыть. В этой статье мы объясняем, почему так происходит и как ERPC комплексно решает эту задачу.

Как выиграть 20 мс, используя http вместо https

Вы наверняка замечали, что URL RPC-эндпоинтов обычно начинаются с https. Буква s означает TLS/SSL-шифрование, которое защищает соединение. Но за эту защиту приходится платить: каждый запрос требует TLS-рукопожатия и постоянных операций шифрования и дешифрования, что добавляет около 20 мс задержки на каждый запрос.
Иными словами, если RPC-коммуникация идет по http, а не по https, эти 20 мс можно убрать на корневом уровне. Для Solana, где аукционы блоков завершаются примерно за 50 мс, такая разница критична.

Почему http нельзя использовать на общих эндпоинтах

Некоторые могут спросить: «Тогда почему бы просто не разрешить http на общих эндпоинтах?» Ответ прост: это невозможно.
Разрешить http в общей среде означало бы допустить нешифрованную передачу, а значит — открыть путь для атак типа «человек посередине», перехвата пакетов и даже кражи подписанных транзакций. Атакующий, использующий тот же общий эндпоинт, в реальности мог бы вмешиваться в ваши транзакции или воспроизводить их повторно.
Именно поэтому общие эндпоинты всегда должны принудительно использовать TLS/SSL. Наши общие RPC-эндпоинты спроектированы так, чтобы быть максимально быстрыми в этих ограничениях, но накладные расходы TLS в 20 мс устранить невозможно по самой архитектуре.

Как выделенный RPC устраняет эти 20 мс

Выделенные RPC-эндпоинты предоставляют доступ только конкретным доверенным клиентам. Благодаря этому мы можем снять обязательное требование TLS и разрешить прямую работу по http.
В результате выигрыш в 20 мс становится гарантированным. Независимо от нагрузки других пользователей или рисков атак, эта структурная разница означает, что зазор в 20 мс между общими и выделенными эндпоинтами не исчезнет никогда.

Оставшаяся задача: SWQoS

Но одной скорости недостаточно. В Solana действует Stake-weighted QoS (SWQoS): узлы без доверия на основе стейка получают доступ только к 20% доступных линий для транзакций.
Например, решения типа Lite-RPC, которые отправляют транзакции напрямую текущему валидатору-лидеру, могут выглядеть быстрыми, но без SWQoS они все равно ограничены этими 20% линий. То есть даже если пакет приходит быстро, вероятность его включения остается заметно ниже.
Сократить 20 мс с помощью выделенного RPC критически важно, но для реального выигрыша и по скорости, и по успешности транзакций его нужно сочетать с SWQoS.
ERPC предоставляет возможность включить SWQoS на выделенных RPC-эндпоинтах.
Это означает, что вы можете использовать связку выделенный RPC + SWQoS и одновременно добиваться более низкой задержки и более высокой вероятности прохождения транзакций.
Solana RPC Price

Какие проблемы решают Validators DAO и ERPC

ERPC решает следующие задачи:
  • Сбои транзакций и скачки задержки в RPC-средах
  • Искусственное ограничение производительности со стороны многих инфраструктурных провайдеров
  • Сильное влияние сетевой дистанции на качество связи
  • Ограниченный доступ небольших проектов к качественной инфраструктуре
Во время разработки Epics DAO, проекта поддержки вкладов в открытый исходный код Solana, мы сами столкнулись с тем, насколько трудно собрать по-настоящему высокопроизводительную Solana-среду с низкой задержкой. Именно эта проблема подтолкнула нас к созданию собственной платформы, на базе которой сегодня мы предоставляем ERPC и SLV.
Финансовые и другие критичные приложения особенно чувствительны к задержкам и ошибкам, потому что это напрямую влияет на пользовательский опыт. Среда Solana сложна сама по себе: валидаторы распределены по всему миру, а поверх этого накладывается дополнительная сложность Web3. Разработчикам трудно видеть картину целиком, и именно поэтому оптимизация часто продвигается медленно.
Предоставляя высокопроизводительную инфраструктуру Solana, мы хотим убрать эти барьеры и улучшить пользовательский опыт во всей экосистеме. ERPC и наш проект с открытым исходным кодом SLV — важные части этой задачи.