ERPC amplía Solana Leader Slot API con mediciones de ping desde 7 regiones del mundo y lanza Validators Information API
ELSOUL LABO B.V. (con sede en Ámsterdam, Países Bajos; CEO: Fumitake Kawasaki) y Validators DAO, operadores de ERPC, han mejorado las API para consultar información sobre los líderes de Solana, sus ubicaciones estimadas y la latencia. Leader Slot API ahora admite el RTT de referencia —medición de ping— desde 7 regiones del mundo y se ha lanzado la nueva Validators Information API.
En primer lugar, hemos ampliado Leader Slot API (
getLeaderSlots) para obtener el RTT de referencia desde 7 regiones de observación de ERPC repartidas por el mundo: Fráncfort, Ámsterdam, Nueva York, Londres, Tokio, Singapur y Sídney. Antes, las mediciones se realizaban únicamente desde Fráncfort.Además, hemos lanzado la nueva Validators Information API (
getValidatorsInformation). Con una sola llamada, esta API enumera todos los validadores que tienen asignado al menos un slot de líder en la época actual. Junto con el número de slots y el stake activo, devuelve, cuando están disponibles, la ubicación estimada, los endpoints de red, la versión del cliente y el RTT de referencia desde las 7 regiones.Ambas API están disponibles para todos los usuarios de ERPC mediante la interfaz JSON-RPC estándar.
- Documentación de Leader Slot API: https://erpc.global/es/doc/rpc/leader-slot-api/
- Documentación de Validators Information API: https://erpc.global/es/doc/rpc/validators-information-api/
La diferencia respecto a la infraestructura de trading tradicional: el destino cambia dinámicamente
En las bolsas y los sistemas financieros tradicionales, los destinos a los que se envían las órdenes —bolsas, gateways y motores de emparejamiento— suelen estar fijados en centros de datos o redes concretos.
Por tanto, una vez conocido el destino de la conexión, los usuarios pueden optimizar continuamente su ruta de red hacia él. Como la ubicación de los servidores de destino no cambia con frecuencia, la infraestructura y las rutas de comunicación pueden diseñarse de forma relativamente estática.
En Solana, en cambio, el líder —el validador responsable de producir bloques— rota cada pocos slots conforme al calendario de líderes. Dado que los validadores que actúan como líderes están repartidos por el mundo, cambian continuamente tanto el destino que deben alcanzar las transacciones como la ruta de red más próxima a ese destino.
En otras palabras, en Solana no se puede tratar el destino de comunicación que debe optimizarse como un único punto de conexión fijo.
Primero hay que identificar en el calendario a los líderes actuales y futuros. Después, antes de elegir una ruta de envío, se comprueba en qué región o red es más probable que se encuentre cada validador y qué latencia existe desde cada ubicación de origen.
Comprender correctamente esta estructura es el punto de partida para entregar transacciones con baja latencia y diseñar infraestructura global en Solana.
Tratar como datos el calendario de líderes y las ubicaciones de red
En un entorno donde el destino cambia dinámicamente, no resulta práctico que una persona compruebe cada vez el líder y la ubicación de envío y cambie las rutas de forma manual.
Es necesario obtener de manera continua la siguiente información e incorporarla a la lógica de decisión de las aplicaciones y la infraestructura.
- Los líderes responsables de los slots actuales y próximos
- El número de slots asignados a cada validador
- El país, la ciudad y la región estimados de cada validador
- Endpoints de red como TPU y QUIC
- El RTT de referencia recogido desde cada región de observación
- La hora de cada medición y el estado de su respuesta
La ubicación estimada y la latencia medida cumplen funciones distintas.
La información de ubicación sirve para tomar decisiones a medio y largo plazo sobre dónde situar infraestructura y capacidad. El RTT de referencia de cada región, por su parte, aporta datos para evaluar qué ubicación tiene más probabilidades de ofrecer una ruta corta en ese momento.
Una ubicación físicamente o geográficamente próxima no siempre corresponde a la ruta más corta en la red. Por ello, es importante combinar la ubicación estimada con los valores observados realmente al tomar decisiones.
Leader Slot API y Validators Information API de ERPC están diseñadas para programar estas decisiones a partir de datos.
Leader Slot API: RTT de referencia medido desde 7 regiones del mundo
Leader Slot API devuelve los próximos slots de líder junto con la identidad del validador, el stake activo, los endpoints de red, la ubicación estimada, el RTT de referencia y otros datos.
Hasta ahora, las mediciones de
pingToLeaders se recogían únicamente desde el origen de Fráncfort: un solo punto de observación para una red Solana distribuida por todo el mundo.Con esta actualización, ya se puede obtener el RTT de referencia medido desde las 7 regiones siguientes.
frankfurtamsterdamnylondontokyosingaporesydney
Al comparar para cada líder el RTT de referencia de las 7 regiones de observación, se puede evaluar qué ubicación de envío tiene más probabilidades de ofrecer una ruta de red corta.
Estos datos sirven para decidir no solo el enrutamiento de transacciones, sino también en qué regiones situar capacidad para RPC, gRPC, Direct Shreds, servidores de envío de transacciones y otros recursos.
Los resultados de la medición incluyen
icmpReplied, que indica si el validador respondió a ICMP, y measuredAt, que señala la hora de la última medición correcta.Un validador que no responde a ICMP puede seguir operando con normalidad servicios como TPU y QUIC. Por ello, cuando
icmpReplied es false, no debe interpretarse como «distante», sino como «no medible mediante ICMP».Además, si durante una actualización no se consigue una medición correcta, la entrada no se sobrescribe con un valor sin medir: se conservan el último valor medido correctamente y la hora de esa medición.
Validators Information API: información sobre los líderes de toda la época
Leader Slot API está indicada para decisiones a escala de slot: «¿qué líder es responsable de los próximos slots?».
En cambio, la ubicación de infraestructura y la planificación de capacidad requieren una perspectiva más amplia.
- Qué validadores actúan como líderes en la época actual
- Cuántos slots tiene asignados cada uno
- En qué países y regiones están distribuidos
- Dónde situar infraestructura para acercarse a un mayor número de líderes
La nueva Validators Information API (
getValidatorsInformation) se ha creado para responder a estas preguntas.Cuando se invoca sin parámetros, devuelve una fila por cada validador que actúa como líder de al menos un slot en la época actual. De forma predeterminada, los resultados se ordenan de mayor a menor número de slots de líder asignados.
Cada fila incluye la información siguiente.
slotCountstakeWeight(stake activo en SOL)- Identidad del validador
Cuando están disponibles, también se devuelven estos datos.
- Región, ciudad y país estimados
- Endpoints de red
- Versión del cliente
- RTT de referencia desde las 7 regiones
Los datos se actualizan con regularidad, por lo que invocar periódicamente la API permite mantener al día el conjunto de datos utilizado para la planificación.
También es posible acotar los resultados mediante los parámetros opcionales
limit (1–2000), country y region.La facturación se basa en el número de validadores devueltos. La cantidad de validadores líderes varía entre épocas; en el ejemplo disponible al redactar este artículo, obtener los 673 validadores consume 6.800 tokens de API —créditos de uso de la API de ERPC— y obtener un máximo de 10 validadores consume 100 tokens.
Hacia un enrutamiento programable basado en datos
Estas API no están pensadas únicamente para mostrar una lista de validadores o valores de RTT de referencia.
El objetivo final es incorporar el calendario de líderes, las ubicaciones estimadas de los validadores y el RTT de referencia de cada región de observación a la lógica de decisión de las aplicaciones.
Por ejemplo, una aplicación puede obtener el próximo calendario de líderes, comparar para cada uno el RTT de referencia desde las 7 regiones de observación y seleccionar después el RPC o la ruta de envío de transacciones que utilizará.
También se puede analizar la distribución de líderes de toda la época y situar de antemano infraestructura en regiones próximas a los validadores que tienen asignados muchos slots.
Entre los usos habituales se encuentran los siguientes.
- Seleccionar rutas de envío a escala de slot
- Planificar capacidad a escala de época
- Analizar los validadores líderes por región
- Priorizar teniendo en cuenta el stake activo y el número de slots
- Monitorizar cambios entre épocas en la distribución geográfica y de red
- Seleccionar automáticamente entre servidores RPC y de envío desplegados en varias regiones
En Solana, donde el destino cambia dinámicamente, la optimización estática de la red no basta por sí sola.
Resulta importante seguir continuamente los cambios de líder y seleccionar de forma dinámica las rutas de envío y la infraestructura según su ubicación y las condiciones de red.
Hacia una infraestructura de Solana diseñada para operar en todo el mundo
ERPC es infraestructura de alto rendimiento para Solana diseñada desde el primer día para operar globalmente.
Nuestra red edge, los servicios bare metal y VPS, Direct Shreds, Geyser gRPC, los endpoints SWQoS y estas API de inteligencia operativa responden a un mismo objetivo.
Ese objetivo es proporcionar datos e infraestructura a quienes desarrollan y exigen una ejecución eficiente y de baja latencia en un entorno donde usuarios y líderes están distribuidos por el mundo.
El RTT de referencia desde 7 regiones y la información de los validadores de toda una época ya pueden obtenerse mediante sencillas llamadas RPC. Las aplicaciones de Solana pueden seleccionar ubicaciones de envío y rutas de red basándose en datos para responder a los continuos cambios de líder.
Para quienes buscan entrega de baja latencia, una distribución global de la infraestructura y optimización dinámica del enrutamiento en Solana, estos datos para la toma de decisiones están directamente vinculados a las operaciones reales.
Esperamos que ayuden a seleccionar rutas de envío de baja latencia, diseñar infraestructura que reduzca transferencias de larga distancia innecesarias y planificar la distribución global de la capacidad.
Consulte la documentación para obtener más información.
- Leader Slot API: https://erpc.global/es/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/es/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/es
