ERPC расширяет Solana Leader Slot API: измерение задержки из 7 регионов мира и новый Validators Information API
ELSOUL LABO B.V. (штаб-квартира: Амстердам, Нидерланды; генеральный директор: Фумитакэ Кавасаки) и Validators DAO, операторы ERPC, усовершенствовали API для получения информации о лидерах Solana, их предполагаемом местоположении и задержке. В Leader Slot API добавлены измерения контрольного RTT (ping) из 7 регионов мира, а также запущен новый Validators Information API.
Во-первых, мы расширили Leader Slot API (
getLeaderSlots), чтобы контрольный RTT можно было получать из 7 регионов наблюдения ERPC по всему миру (Франкфурт, Амстердам, Нью-Йорк, Лондон, Токио, Сингапур и Сидней). Раньше измерения проводились только из Франкфурта.Одновременно мы запустили новый Validators Information API (
getValidatorsInformation). Этот API одним вызовом возвращает список всех валидаторов, которым назначен хотя бы один лидерский слот в текущей эпохе. Помимо количества слотов и объёма активного стейка, при наличии данных он возвращает предполагаемое местоположение, сетевые эндпоинты, версию клиента и контрольный RTT из 7 регионов.Оба API доступны всем пользователям ERPC через стандартный JSON-RPC-интерфейс.
- Документация Leader Slot API: https://erpc.global/ru/doc/rpc/leader-slot-api/
- Документация Validators Information API: https://erpc.global/ru/doc/rpc/validators-information-api/
Отличие от традиционной торговой инфраструктуры: в Solana адресат связи меняется динамически
На традиционных биржах и в финансовых системах адресаты отправки ордеров — биржи, шлюзы и механизмы сопоставления заявок — обычно привязаны к конкретным центрам обработки данных или сетям.
Поэтому, однажды узнав точку подключения, пользователи могут постоянно оптимизировать сетевой путь к ней. Поскольку местоположение целевых серверов меняется нечасто, размещение инфраструктуры и маршруты связи можно проектировать относительно статично.
В Solana лидер — валидатор, отвечающий за производство блоков, — меняется каждые несколько слотов согласно расписанию. Поскольку лидирующие валидаторы распределены по всему миру, постоянно меняются и адресат, которого должны достичь транзакции, и ближайший к нему сетевой маршрут.
Иными словами, в Solana оптимизируемый адресат связи нельзя рассматривать как фиксированную единственную точку подключения.
Сначала нужно определить из расписания лидеров, кто является текущим и будущими лидерами. Затем проверить, в каком регионе или сети, скорее всего, находится каждый валидатор и какова задержка от каждой точки отправки, — и только после этого выбирать маршрут отправки.
Правильное понимание этой структуры — отправная точка для низколатентной отправки транзакций и глобального проектирования инфраструктуры в Solana.
Расписание лидеров и сетевые местоположения как данные
В среде, где адресат меняется динамически, непрактично, если человек каждый раз проверяет лидера и точку отправки и вручную переключает маршрут.
Необходимо постоянно получать следующую информацию и встраивать её в логику принятия решений ваших приложений и инфраструктуры.
- Лидеры, отвечающие за текущие и предстоящие слоты
- Количество слотов, за которые отвечает каждый валидатор
- Предполагаемое местоположение каждого валидатора: страна, город и регион
- Сетевые эндпоинты, такие как TPU и QUIC
- Контрольный RTT, полученный из каждого региона наблюдения
- Время получения каждого измерения и статус ответа
Предполагаемое местоположение и измеренная задержка играют разные роли.
Информацию о местоположении можно использовать для средне- и долгосрочных решений о том, где размещать инфраструктуру и мощности. Контрольный RTT из каждого региона, в свою очередь, служит входными данными для оценки того, от какой точки сейчас, скорее всего, доступен короткий путь.
Физически или географически близкое место не всегда оказывается кратчайшим путем в сети. Поэтому важно принимать решения, сочетая предполагаемое местоположение с фактически наблюдаемыми значениями.
Leader Slot API и Validators Information API от ERPC позволяют закладывать такую логику принятия решений в программный код на основе данных.
Leader Slot API: измерение контрольного RTT из 7 регионов мира
Leader Slot API возвращает предстоящие лидерские слоты вместе с идентификатором валидатора, объёмом активного стейка, сетевыми эндпоинтами, предполагаемым местоположением, контрольным 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)- Идентификатор валидатора
При наличии данных возвращается также следующая информация.
- Предполагаемое местоположение: регион, город и страна
- Сетевые эндпоинты
- Версия клиента
- Контрольный 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, с первого дня спроектированная для глобальной работы.
Наша периферийная сеть, предложения bare metal и VPS, Direct Shreds, Geyser gRPC, эндпоинты SWQoS и API операционной аналитики служат общей цели.
Эта цель — предоставить и данные, и инфраструктуру разработчикам, которым нужно низколатентное и эффективное исполнение в среде, где пользователи и лидеры распределены по всему миру.
Контрольный RTT из 7 глобальных регионов и данные о валидаторах всей эпохи теперь доступны через простые RPC-вызовы. Solana-приложения теперь могут выбирать точки отправки и сетевые маршруты на основе данных, реагируя на постоянно меняющегося лидера.
Для разработчиков, которым в Solana нужны низколатентная отправка, глобальное размещение инфраструктуры и динамическая оптимизация маршрутизации, это исходные данные для решений, напрямую связанных с реальной эксплуатацией.
Мы надеемся, что это поможет в выборе низколатентных маршрутов отправки, в проектировании инфраструктуры, сокращающей ненужные дальние передачи, и в глобальном планировании мощностей.
Подробности — в документации.
- Leader Slot API: https://erpc.global/ru/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/ru/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/ru
