Comprender la latencia en sistemas blockchain distribuidos
Cuando trabajas con servicios de streaming de blockchain, medir la latencia se vuelve complejo porque los sistemas distribuidos no tienen un reloj universal. A diferencia de los sistemas tradicionales, donde puedes medir el tiempo de ida y vuelta a un solo servidor, las redes blockchain incluyen varios validadores, y cada uno recibe y procesa la misma transacción en momentos diferentes. El desafío fundamental: Las blockchains como Solana no tienen un concepto de tiempo absoluto. Cada nodo validador del mundo recibe la misma transacción en un momento diferente, y la confirmación depende de que un porcentaje del clúster alcance un consenso. Esto hace imposible medir la latencia de forma determinista en el sentido tradicional.Niveles de compromiso y prioridades de latencia
Solana expone tres valores de compromiso. Con Alpenglow,confirmed e finalized describen el mismo estado permanente:
- Procesado: Ejecución observada por el validador conectado; ofrece la latencia más baja, pero puede revertirse
- Confirmado: Alias de compatibilidad para
finalized; se eliminará en una versión posterior - Finalizado: Compromiso permanente del libro mayor, normalmente unos 150 ms después de la propuesta del bloque
Tres enfoques para medir la latencia
1. Comparar streams de gRPC en paralelo
El método más confiable: compara dos streams independientes de la misma fuente de datos y mide cuál recibe primero los eventos idénticos. Ventajas:- Elimina los problemas de sincronización de relojes
- Permite comparar el rendimiento relativo
- Es el más preciso para comparar servicios
2. Comparar la marca de tiempo local con created_at
Confiabilidad moderada: mide la diferencia entre el momento en que tu sistema recibe un mensaje y la marca de tiempo que el servicio LaserStream incorporó en el mensaje. Limitaciones:- Solo representa el momento en que LaserStream creó el mensaje internamente
- No captura los retrasos anteriores a LaserStream
- Es menos preciso que el método 1 para medir la latencia real de extremo a extremo
3. Análisis de la marca de tiempo del bloque (no recomendado)
No recomendado: compara la hora de recepción local con la marca de tiempo del bloque de Solana. Limitaciones importantes:- Las marcas de tiempo de los bloques solo tienen una precisión de un segundo
- Solana produce bloques cada 200 ms
- Proporciona muy poca información útil
Requisitos de configuración
Coubicación regional
Para obtener mediciones de latencia útiles, despliega tu infraestructura de pruebas en el mismo centro de datos o región que tu endpoint de LaserStream. Regiones disponibles de LaserStream:- ewr: Nueva York, EE. UU. (costa este) -
https://laserstream-mainnet-ewr.helius-rpc.com - pitt: Pittsburgh, EE. UU. (centro) -
https://laserstream-mainnet-pitt.helius-rpc.com - slc: Salt Lake City, EE. UU. (costa oeste) -
https://laserstream-mainnet-slc.helius-rpc.com - ams: Ámsterdam, Europa -
https://laserstream-mainnet-ams.helius-rpc.com - fra: Fráncfort, Europa -
https://laserstream-mainnet-fra.helius-rpc.com - tyo: Tokio, Asia -
https://laserstream-mainnet-tyo.helius-rpc.com - sgp: Singapur, Asia -
https://laserstream-mainnet-sgp.helius-rpc.com
https://laserstream-devnet-ewr.helius-rpc.com
Consulta la documentación de gRPC de LaserStream para obtener instrucciones completas de configuración y pautas para seleccionar un endpoint.
Configuración del entorno de Rust
Todos los scripts de medición usan Rust con Cargo. Configuración básica:.env con tus credenciales:
Método 1: Comparación de streams en paralelo
Este script establece dos conexiones independientes con distintos endpoints de gRPC y mide cuál recibe primero los mismos mensajesBlockMeta. Este enfoque elimina los problemas de sincronización de relojes mediante tiempos relativos.
- Diferencia positiva: El primer servicio (YS) es más lento que el segundo (LS); LaserStream es más rápido
- Diferencia negativa: El primer servicio (YS) es más rápido que el segundo (LS); LaserStream es más lento
- Media/mediana: Diferencia de rendimiento promedio
- P95: Diferencia de latencia del percentil 95
Método 2: Análisis de la marca de tiempo de creación
Este enfoque compara la marca de tiempocreated_at incorporada en los mensajes con la hora de tu sistema local al recibirlos.
Prácticas recomendadas para las pruebas de latencia
Principios clave
- Coubicación: Despliega las pruebas en la misma región que tu endpoint de LaserStream para minimizar la latencia de red
- Varios métodos: Usa la comparación de streams en paralelo (método 1) como métrica principal y compleméntala con el análisis de marcas de tiempo
- Monitoreo a largo plazo: Ejecuta las pruebas durante periodos prolongados para capturar distintas condiciones de red y niveles de congestión de la blockchain
- Análisis estadístico: Céntrate en los percentiles (P95, P99), no solo en los promedios, para comprender la latencia de cola
Interpretar los resultados
- Establece una referencia: Ejecuta las pruebas durante al menos 1 hora para establecer el rendimiento de referencia en condiciones normales
- Identifica patrones: Busca patrones en los picos de latencia. ¿Se correlacionan con una alta actividad de la blockchain o con la congestión de la red?
- Compara percentiles: La latencia P95 suele ser más importante que la latencia promedio para la experiencia del usuario
- Monitorea la consistencia: Un rendimiento consistente suele ser más valioso que la latencia mínima absoluta