FAQ - Direct Shreds
Q. В каких регионах расположены ваши ноды?
Сейчас мы эксплуатируем ноды в следующих регионах:
- Frankfurt (FRA)
- Amsterdam (AMS)
- London (LON)
- Dublin (DUB)
- New York (NY)
- Chicago (CHI)
- Salt Lake City (SLC)
- Tokyo (TY)
- Singapore (SGP)
ERPC измеряет фактическую сетевую задержку по реальным маршрутам и автоматически выбирает регион с наименьшей задержкой, а не ориентируется на расстояние по прямой. Такой подход не только снижает задержку для отдельных пользователей, но и повышает общую эффективность сети и усиливает глобальную устойчивость ERPC к потенциальным атакам.
Если в вашей среде оптимальный регион не выбирается автоматически, свяжитесь с нами в Discord. В большинстве случаев проблема вызвана настройками firewall, которые блокируют ответы на ping от endpoint.
Официальный Discord Validators DAO: https://discord.gg/C7ZQSrCkYR
Q. Задержка показывает 9999ms и выбирается неоптимальный регион, хотя мои ресурсы находятся во Frankfurt.
Когда вы регистрируете свой IP, мы отправляем ping с каждого Shreds load balancer, чтобы найти ближайший регион. Если ответы ICMP блокируются вашим firewall (
ufw, cloud firewalls, security groups и т. д.), результат может стать 9999ms, из-за чего оптимальный ближайший регион не выберется. Добавьте IP-адреса ниже в allowlist, чтобы ближайший регион выбирался автоматически.| Region | Domain | IP Address |
|---|---|---|
| 🇳🇱 Amsterdam | shreds-ams6-1.erpc.global | 64.130.43.108 |
| 🇩🇪 Frankfurt | shreds-fra6-1.erpc.global | 64.130.41.236 |
| 🇬🇧 London | shreds-lon6-1.erpc.global | 64.130.63.211 |
| 🇮🇪 Dublin | shreds-dub6-1.erpc.global | 82.40.61.2 |
| 🇺🇸 New York | shreds-ny6-1.erpc.global | 64.130.37.235 |
| 🇺🇸 Chicago | shreds-chi-2.erpc.global | 84.32.71.34 |
| 🇺🇸 Salt Lake City | shreds-slc6-1.erpc.global | 72.244.154.7 |
| 🇸🇬 Singapore | shreds-sgp6-1.erpc.global | 67.209.55.19 |
| 🇯🇵 Tokyo | shreds-ty6-1.erpc.global | 198.13.133.89 |
Q. Раньше я использовал только WebSocket или Geyser gRPC (YellowStone). Есть примеры?
Да. Вы можете быстро начать тестирование подключений Shreds и разработку приложений с помощью SLV.
Подробности смотрите в следующем руководстве:
Q. Можно ли зарегистрировать два IP-адреса?
На одну подписку можно использовать один endpoint. Если вам нужны два IP-адреса, потребуется оформить две отдельные подписки.
Q. Мне нужна задержка примерно ~400ms или ниже.
Чтобы добиться задержки на уровне примерно 400ms или ниже, учитывайте следующие ключевые моменты:
-
Реалистичное понимание значений ping: Значения ping отражают идеальные условия и не показывают фактическую задержку при потоковой передаче данных, где задержка обычно составляет примерно 5 раз от ping. Например, ping 100ms между континентами на практике означает около 500ms задержки. Поэтому для достижения ~400ms инфраструктуру необходимо размещать в том же регионе.
- Типичные ориентиры по ping:
- Одна сеть: ~0.1ms
- Private Network Interconnect (PNI): ~0.2ms
- Один дата-центр: ~0.3ms
- Один город: ~1ms
- Соседняя страна: ~5–10ms
- Межконтинентально: ~100–300ms
- Типичные ориентиры по ping:
-
Не полагайтесь на среднюю задержку: Валидаторы Solana географически распределены по всему миру, а leader schedule случайным образом меняется с каждой эпохой. Ориентироваться на среднюю задержку, чтобы добиться ~400ms, непрактично. Вместо этого нужно точно отслеживать расписание валидаторов в нужном вам регионе и выявлять slots с наименьшей задержкой. Чтобы стабильно добиваться минимальной задержки, нужна инфраструктура во всех релевантных регионах. Внутри одного региона данные можно получать за десятки миллисекунд, а передавать за считаные миллисекунды.
-
Отслеживание leader schedule: Непрерывно отслеживайте leader schedule для вашего региона с помощью ERPC Leader Slot API (
getLeaderSlots).
Он предоставляет данные в реальном времени о ближайших лидерах, геолокации валидаторов и эталонных значениях ping, позволяя точно находить оптимальные торговые slots с минимальной задержкой.
Это снимает ограничения публичных источников данных, таких как Solana Beach или нативные RPC APIs, у которых ниже частота обновления и точность.
Q. Как добиться zero-block (zero-slot) trading?
Чтобы успешно добиться zero-block (zero-slot) trading, нужны более продвинутые стратегии, в частности:
-
Определение зон возможностей: Валидаторы Solana распределены по всему миру, и физически невозможно обеспечить оптимальную задержку для каждого slot. Поэтому отслеживайте leader schedule валидаторов в регионе, где размещена ваша инфраструктура, и определяйте наиболее выгодные зоны возможностей. Размещение инфраструктуры в нескольких регионах также может дать преимущество. Например, Frankfurt является ключевым регионом из-за высокой плотности валидаторов, поэтому лидеры там выбираются чаще и торговых возможностей больше.Используйте ERPC Leader Slot API (
getLeaderSlots), чтобы получать leader schedule в реальном времени, геоданные валидаторов и эталонные значения ping с существенно более высокой точностью, чем у Solana Beach или нативных RPC APIs. Это позволяет точнее прогнозировать зоны возможностей и исполнять сделки почти с нулевой задержкой. -
Развертывание dedicated nodes: Если вам сложно конкурировать, рассмотрите развертывание dedicated nodes. На shared nodes возникает задержка из-за трафика других пользователей, поэтому они не рекомендуются. Кроме того, размещение dedicated node в той же сети, что и ваше приложение, значительно снижает сетевую задержку и оптимизирует производительность.
Q. Можно ли использовать конкретный endpoint?
Чтобы сохранять среду с низкой задержкой, наша система автоматически выбирает ближайшую доступную ноду. Если вы хотите использовать конкретный endpoint, мы рекомендуем арендовать сервер, расположенный как можно ближе к этому endpoint.
Q. Почему dedicated endpoints быстрее?
Shared endpoints используются несколькими клиентами, которые делят одни и те же ресурсы. По мере роста трафика задержка становится более вероятной. Серверные ресурсы физически ограничены, и объем работы, который они могут обработать, конечен. Когда одновременно приходит слишком много запросов, их приходится обрабатывать последовательно, что приводит к более медленному времени ответа.
Хотя мы применяем различные меры для оптимизации производительности даже на shared endpoints, на dedicated endpoints вы являетесь единственным пользователем ресурса. Это означает, что другие пользователи никак на вас не влияют, и вы получаете стабильно быстрые и предсказуемые ответы.
Кроме того, dedicated endpoints поддерживают варианты соединения без TLS, например HTTP. За счет пропуска TLS handshake (около 20ms) соединение становится еще быстрее по сравнению с HTTPS.
Q. Я хочу платить криптовалютой
Сейчас ERPC разрабатывает “Subscription NFTs”. Этот механизм выпускает права подписки в виде NFT, позволяя ими владеть, передавать и перепродавать их, что значительно улучшает процесс оплаты криптовалютой. Релиз запланирован на конец 2025 года. Подробности по ссылке ниже:
Subscription NFTs Press Release: https://erpc.global/en/news/2025/08/31/erpc-subscription-nfts/
Однако на разработку и релиз потребуется время, поэтому, если вы хотите начать платить криптовалютой уже сейчас, мы рекомендуем попробовать сервисы, позволяющие использовать криптовалюту для оплаты как банковской картой:
- Bybit Crypto Card: https://www.bybit.com/en/cards
- Wirex Card: https://wirexapp.com/card
С помощью этих сервисов вы можете сразу начать оплачивать подписку криптовалютой так же, как обычной банковской картой.
Q. Почему ShredStream не включает все транзакции?
По своей природе Shreds не содержат все транзакции в блокчейне Solana. Для мониторинга всех транзакций потребовалось бы развернуть большое количество прокси по всему миру и получать Shreds от каждого валидатора, что на практике нереалистично.
Обычно пользователи работают с подмножеством доступных данных, и этого достаточно для большинства реальных кейсов. Если вашему сценарию использования требуется полное покрытие данных без каких-либо потерь, Shreds могут вам не подойти.
Для сценариев, где нужен более полный мониторинг, Geyser gRPC обеспечивает более высокую надежность по сравнению с Shreds. Однако для достижения 100% покрытия данных в блокчейне Solana все равно потребуется развернуть множество edge-серверов, что на практике может оказаться нереалистичным.
Надежность Geyser gRPC превышает 99%, что заметно выше, чем у Shreds, и это подтверждают многие пользователи, включая нас самих. При этом Shreds обычно обеспечивают надежность свыше 90%.
Хотя они не охватывают каждую транзакцию, их ключевое преимущество в том, что они позволяют получать большую часть транзакций быстрее, чем Geyser gRPC.
Чтобы глубже понять этот механизм, рекомендуем изучить протоколы Solana Turbine и Gulf Stream:
- Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol
- Turbine — Solana’s Block Propagation Protocol Solves the Scalability Trilemma
Q. Мне нужна максимально производительная среда.
Для оптимальной конфигурации мы рекомендуем сочетать dedicated Shreds node с нашими Bare-Metal servers. Благодаря общей сети такая конфигурация обеспечивает приватную связь с нулевой дистанцией и задержкой около 0.1ms ping.
Если нужны подробности, свяжитесь с нами в Discord.
Q. Какая здесь задержка?
Задержка зависит от способа измерения и вашей конкретной среды использования. Важнее не точное числовое значение, а то, соответствует ли задержка вашим реальным рабочим требованиям.
Мы предоставляем бесплатный пробный период для всех планов, чтобы вы могли протестировать производительность прямо в вашей реальной среде. Кроме того, у нас есть простые в использовании инструменты на TypeScript и Rust для измерения задержки. Смело используйте их параллельно с бесплатным пробным периодом.
Q. Этот RPC (gRPC, Shreds) быстрее других?
Мы рекомендуем воспользоваться бесплатным пробным периодом и сравнить производительность с другими сервисами. Если окажется, что наш сервис медленнее, сообщите нам в Discord конкретные условия и с какими конкурентами вы сравнивали. Мы разберемся в причине и дополнительно улучшим скорость.
Мы постоянно улучшаем задержку на основе обратной связи клиентов. Если вам нужен максимально быстрый endpoint, поделитесь с нами подробной информацией. Конкретные метрики и условия сравнения с конкурентами помогают нам обеспечивать более высокую производительность. Именно такой подход, основанный на обратной связи, уже не раз позволял нам улучшать сервис.
Q. Какой план обеспечивает самую высокую производительность?
Как правило, самый быстрый результат дает наш тариф верхнего уровня благодаря более мощным CPU, большему объему памяти и усиленной аппаратной конфигурации.
Если вам нужны еще более мощные серверы, мы также предлагаем кастомные решения, но наши стандартные планы рассчитаны на оптимальное соотношение цены и производительности.
Мы уверены, что обеспечиваем производительность мирового уровня в каждом ценовом сегменте. Если вы найдете более быстрого провайдера в том же ценовом диапазоне, сообщите нам, чтобы мы могли проверить это и улучшить сервис.
Q. У меня высокая задержка. Почему?
Задержка значительно растет с расстоянием до endpoint. Мы рекомендуем подключаться с сервера, расположенного ближе к предоставленному endpoint. Самые быстрые среды доступны через наши Bare-Metal servers и VPS services.
Q. Что быстрее: WebSockets, gRPC или Shreds?
По отзывам клиентов порядок производительности такой:
Shreds > gRPC > WebSockets
Если у вас наблюдаются другие результаты, пожалуйста, сообщите нам.
Q. Задержка оказалась не такой, как я ожидал.
Производительность заметно различается в зависимости от используемого языка программирования. Обычно порядок такой:
Rust > Go > TypeScript (JavaScript) > Python
Подробное сравнение смотрите здесь:
Если вам нужна максимальная производительность, мы настоятельно рекомендуем Rust.