ERPC расширяет Solana Leader Slot API измерением ping из 7 глобальных регионов — также запущен Validators Information API
ERPC расширяет Solana Leader Slot API измерением ping из 7 глобальных регионов — также запущен Validators Information API
ELSOUL LABO B.V. (штаб-квартира: Амстердам, Нидерланды; CEO: Fumitake Kawasaki) и Validators DAO, операторы ERPC, усовершенствовали API для получения информации о лидерах Solana, оценочных местоположениях и задержке, добавив поддержку референсного RTT (измерение ping) из 7 глобальных регионов в Leader Slot API и запустив новый Validators Information API.
Во-первых, мы расширили Leader Slot API (
getLeaderSlots), чтобы референсный RTT можно было получать из 7 регионов наблюдения ERPC по всему миру (Франкфурт, Амстердам, Нью-Йорк, Лондон, Токио, Сингапур и Сидней). Раньше измерения проводились только из Франкфурта.Одновременно мы запустили новый Validators Information API (
getValidatorsInformation). Этот API одним вызовом возвращает список всех валидаторов, лидирующих хотя бы в одном слоте текущей эпохи. В дополнение к количеству слотов и объему активного стейка он также возвращает, где это доступно, оценочное местоположение, сетевые endpoint'ы, версию клиента и референсный RTT из 7 регионов.Оба API доступны всем пользователям ERPC через стандартный JSON-RPC-интерфейс.
- Документация Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- Документация Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
Отличие от традиционной торговой инфраструктуры: в Solana адресат связи меняется динамически
В традиционных биржах и финансовых системах адресаты, которым отправляются ордера, — биржи, шлюзы, matching engine — обычно закреплены за конкретными дата-центрами или сетями.
Поэтому, однажды узнав точку подключения, пользователи могут постоянно оптимизировать сетевой путь к ней. Поскольку местоположение целевых серверов меняется нечасто, размещение инфраструктуры и маршруты связи можно проектировать относительно статично.
В Solana же лидер — валидатор, отвечающий за производство блоков, — меняется каждые несколько слотов согласно расписанию лидеров. Поскольку валидаторы, выступающие лидерами, распределены по всему миру, и адресат, которому должны достичь ваши транзакции, и ближайший к нему сетевой путь постоянно меняются.
Иными словами, в Solana оптимизируемый адресат связи нельзя рассматривать как фиксированную единственную точку подключения.
Сначала нужно определить из расписания лидеров, кто является текущим и будущими лидерами. Затем проверить, в каком регионе или сети, скорее всего, находится каждый валидатор и какова задержка от каждой точки отправки, — и только после этого выбирать маршрут отправки.
Правильное понимание этой структуры — отправная точка для низколатентной отправки транзакций и глобального проектирования инфраструктуры в Solana.
Расписание лидеров и сетевые местоположения как данные
В среде, где адресат меняется динамически, непрактично, если человек каждый раз проверяет лидера и точку отправки и вручную переключает маршрут.
Необходимо постоянно получать следующую информацию и встраивать ее в логику принятия решений ваших приложений и инфраструктуры.
- Лидеры, отвечающие за текущие и предстоящие слоты
- Количество слотов, за которые отвечает каждый валидатор
- Оценочные страна, город и регион каждого валидатора
- Сетевые endpoint'ы, такие как TPU и QUIC
- Референсный RTT, полученный из каждого региона наблюдения
- Время получения каждого измерения и статус ответа
Оценочное местоположение и измеренная задержка играют разные роли.
Информацию о местоположении можно использовать для средне- и долгосрочных решений о том, где размещать инфраструктуру и мощности. Референсный RTT из каждого региона, в свою очередь, служит входными данными для оценки того, от какой точки сейчас, скорее всего, доступен короткий путь.
Физически или географически близкое место не всегда оказывается кратчайшим путем в сети. Поэтому важно принимать решения, сочетая оценочное местоположение с фактически наблюдаемыми значениями.
Leader Slot API и Validators Information API от ERPC — это API, которые позволяют программировать такие решения на основе данных.
Leader Slot API: измерение референсного RTT из 7 глобальных регионов
Leader Slot API возвращает предстоящие лидерские слоты вместе с идентичностью валидатора, объемом активного стейка, сетевыми endpoint'ами, оценочным местоположением, референсным RTT и другими данными.
До сих пор измерения
pingToLeaders собирались только с точки во Франкфурте — единственной точки наблюдения в глобально распределенной сети Solana.С этим обновлением теперь можно получать референсный RTT, измеренный из следующих 7 регионов.
frankfurtamsterdamnylondontokyosingaporesydney
Сравнивая референсный RTT из 7 регионов наблюдения для каждого лидера, вы можете оценить, от какой точки отправки, скорее всего, доступен короткий сетевой путь.
Это служит входными данными для решений не только о маршрутизации транзакций, но и о том, в каких регионах размещать мощности RPC, gRPC, Direct Shreds, серверов отправки транзакций и т. д.
Результаты измерений включают
icmpReplied, который показывает, ответил ли валидатор на ICMP, и measuredAt, который показывает время получения последнего успешного измерения.Валидатор, не отвечающий на ICMP, может при этом нормально обслуживать такие сервисы, как TPU и QUIC. Поэтому, когда
icmpReplied равен false, это следует трактовать не как «далеко», а как «не измеряется через ICMP».Кроме того, если при очередном обновлении успешное измерение получить не удается, запись не перезаписывается неизмеренным значением — сохраняются последнее успешно измеренное значение и время его измерения.
Validators Information API: список лидерской информации за всю эпоху
Leader Slot API подходит для решений на уровне слота — «кто лидирует в ближайших слотах?»
Размещение инфраструктуры и планирование мощностей, напротив, требуют более широкого взгляда.
- Какие валидаторы лидируют в текущей эпохе
- Сколько слотов лидирует каждый из них
- В каких странах и регионах они распределены
- Где разместить инфраструктуру, чтобы быть ближе к большему числу лидеров
Новый Validators Information API (
getValidatorsInformation) — это API, созданный, чтобы отвечать на эти вопросы.При вызове без параметров он возвращает всех валидаторов, лидирующих хотя бы в одном слоте текущей эпохи, — по одной строке на валидатора. По умолчанию результаты возвращаются в порядке убывания количества лидируемых слотов.
Каждая строка включает следующую информацию.
slotCountstakeWeight(объем активного стейка в SOL)- Идентичность валидатора
Где это доступно, возвращается также следующая информация.
- Оценочные регион, город и страна
- Сетевые endpoint'ы
- Версия клиента
- Референсный RTT из 7 регионов
Поскольку данные регулярно обновляются, периодические вызовы API позволяют поддерживать ваш набор данных для планирования в актуальном состоянии.
Вы также можете сужать результаты с помощью необязательных параметров
limit (1–2000), country и region.Биллинг зависит от количества возвращенных валидаторов. Количество лидирующих валидаторов меняется от эпохи к эпохе; в примере на момент написания выборка всех 673 валидаторов расходует 6,800 API-токенов (кредиты использования API ERPC), а выборка до 10 валидаторов — 100 API-токенов.
К программируемой маршрутизации на основе данных
Эти API предназначены не просто для отображения списка валидаторов или референсного RTT.
Конечная цель — дать вам возможность встроить расписание лидеров, оценочные местоположения валидаторов и референсный RTT из каждого региона наблюдения в логику принятия решений ваших приложений.
Например, приложение может получить предстоящее расписание лидеров, сравнить референсный RTT из 7 регионов наблюдения для каждого лидера, а затем выбрать используемый RPC или маршрут отправки транзакций.
Можно также анализировать распределение лидеров по всей эпохе и заранее размещать инфраструктуру в регионах, близких к валидаторам с большим количеством слотов.
Типичные сценарии использования:
- Выбор маршрута отправки на уровне слота
- Планирование мощностей на уровне эпохи
- Анализ лидирующих валидаторов по регионам
- Приоритизация с учетом активного стейка и количества слотов
- Мониторинг изменений географического и сетевого распределения от эпохи к эпохе
- Автоматический выбор среди RPC и серверов отправки, размещенных в нескольких регионах
В Solana, где адресат меняется динамически, одной статической оптимизации сети недостаточно.
Становится важно постоянно отслеживать меняющегося лидера и динамически выбирать маршруты отправки и инфраструктуру в соответствии с его местоположением и состоянием сети.
К инфраструктуре Solana, рассчитанной на глобальную работу
ERPC — это высокопроизводительная инфраструктура для Solana, с первого дня спроектированная для глобальной работы.
Наша edge-сеть, предложения bare metal и VPS, Direct Shreds, Geyser gRPC, SWQoS-endpoint'ы и эти API операционной аналитики — все они предоставляются ради общей цели.
Эта цель — предоставить и данные, и инфраструктуру разработчикам, которым нужно низколатентное и эффективное исполнение в среде, где пользователи и лидеры распределены по всему миру.
Референсный RTT из 7 глобальных регионов и данные о валидаторах всей эпохи теперь доступны через простые RPC-вызовы. Solana-приложения теперь могут выбирать точки отправки и сетевые маршруты на основе данных, реагируя на постоянно меняющегося лидера.
Для разработчиков, которым в Solana нужны низколатентная отправка, глобальное размещение инфраструктуры и динамическая оптимизация маршрутизации, это материал для решений, напрямую связанный с реальной эксплуатацией.
Мы надеемся, что это поможет в выборе низколатентных маршрутов отправки, в проектировании инфраструктуры, сокращающей ненужные дальние передачи, и в глобальном планировании мощностей.
Подробности — в документации.
- Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/en
Новости
