Общие сведения о задержке в распределенных блокчейн-системах
При работе с сервисами потоковой передачи данных блокчейна измерение задержки усложняется, поскольку в распределенных системах нет универсальных часов. В отличие от традиционных систем, где можно измерить время приема-передачи до одного сервера, блокчейн-сети включают несколько валидаторов, каждый из которых получает и обрабатывает одну и ту же транзакцию в разное время. Основная проблема: в таких блокчейнах, как Solana, нет понятия абсолютного времени. Каждый узел-валидатор в мире получает одну и ту же транзакцию в разное время, а подтверждение зависит от достижения консенсуса определенной долей кластера. Поэтому детерминированное измерение задержки в традиционном понимании невозможно.Уровни подтверждения и приоритеты задержки
Solana предлагает три уровня подтверждения с разными характеристиками задержки:- Processed: самый быстрый, подтверждение одним валидатором (~400 мс)
- Confirmed: средний, подтверждение квалифицированным большинством (~2–3 секунды)
- Finalized: самый медленный, полная финализация сетью (~15–30 секунд)
Три подхода к измерению задержки
1. Сравнение параллельных потоков gRPC
Самый надежный метод — сравнивает два независимых потока из одного источника данных и определяет, какой из них первым получает идентичные события. Преимущества:- Устраняет проблемы синхронизации часов
- Позволяет сравнивать относительную производительность
- Обеспечивает наиболее точное сравнение сервисов
2. Сравнение локальной временной метки с created_at
Средняя надежность — измеряет разницу между моментом получения сообщения вашей системой и временной меткой, добавленной в сообщение сервисом LaserStream. Ограничения:- Отражает только момент внутреннего создания сообщения в LaserStream
- Не учитывает задержки на пути к LaserStream
- Менее точен для измерения реальной сквозной задержки, чем метод 1
3. Анализ временной метки блока (не рекомендуется)
Не рекомендуется — сравнивает локальное время получения с временной меткой блока Solana. Существенные ограничения:- Временные метки блоков имеют точность только до секунды
- Solana создает блоки каждые 400 мс
- Предоставляет минимум полезной информации
Требования к настройке
Совместное размещение в одном регионе
Чтобы получить значимые результаты измерения задержки, разверните тестовую инфраструктуру в том же ЦОД или регионе, где находится конечная точка LaserStream. Доступные регионы LaserStream:- ewr: Нью-Йорк, США (восточное побережье) —
https://laserstream-mainnet-ewr.helius-rpc.com - pitt: Питтсбург, США (центральная часть) —
https://laserstream-mainnet-pitt.helius-rpc.com - slc: Солт-Лейк-Сити, США (западное побережье) —
https://laserstream-mainnet-slc.helius-rpc.com - ams: Амстердам, Европа —
https://laserstream-mainnet-ams.helius-rpc.com - fra: Франкфурт, Европа —
https://laserstream-mainnet-fra.helius-rpc.com - tyo: Токио, Азия —
https://laserstream-mainnet-tyo.helius-rpc.com - sgp: Сингапур, Азия —
https://laserstream-mainnet-sgp.helius-rpc.com
https://laserstream-devnet-ewr.helius-rpc.com
Полные инструкции по настройке и рекомендации по выбору конечной точки см. в документации по gRPC LaserStream.
Настройка среды Rust
Все скрипты измерения используют Rust и Cargo. Базовая настройка:.env со своими учетными данными:
Метод 1: сравнение параллельных потоков
Этот скрипт устанавливает два независимых подключения к разным конечным точкам gRPC и определяет, какое из них первым получает одинаковые сообщенияBlockMeta. Такой подход устраняет проблемы синхронизации часов благодаря использованию относительного времени.
- Положительная разница: первый сервис (YS) медленнее второго (LS) — LaserStream быстрее
- Отрицательная разница: первый сервис (YS) быстрее второго (LS) — LaserStream медленнее
- Среднее/медиана: средняя разница в производительности
- P95: разница задержки на 95-м процентиле
Метод 2: анализ временной метки создания
Этот подход сравнивает временную меткуcreated_at, встроенную в сообщения, с локальным системным временем в момент их получения.
Рекомендации по тестированию задержки
Основные принципы
- Совместное размещение: запускайте тесты в том же регионе, что и конечная точка LaserStream, чтобы свести сетевую задержку к минимуму
- Несколько методов: используйте сравнение параллельных потоков (метод 1) как основную метрику и дополняйте его анализом временных меток
- Долгосрочный мониторинг: запускайте тесты на длительное время, чтобы охватить разные состояния сети и периоды высокой нагрузки на блокчейн
- Статистический анализ: чтобы оценить задержку в хвосте распределения, учитывайте прежде всего процентили (P95, P99), а не только средние значения
Интерпретация результатов
- Определите базовый уровень: выполняйте тесты не менее 1 часа, чтобы определить базовую производительность в нормальных условиях
- Выявляйте закономерности: ищите закономерности во всплесках задержки — связаны ли они с высокой активностью блокчейна или перегрузкой сети?
- Сравнивайте процентили: для взаимодействия с пользователем задержка P95 часто важнее средней задержки
- Контролируйте стабильность: стабильная производительность часто важнее абсолютного минимума задержки