ERPC amplía la Leader Slot API de Solana con medición de ping desde 7 regiones globales — También se lanza la Validators Information API
ERPC amplía la Leader Slot API de Solana con medición de ping desde 7 regiones globales — También se lanza la Validators Information API
ELSOUL LABO B.V. (sede: Ámsterdam, Países Bajos; CEO: Fumitake Kawasaki) y Validators DAO, operadores de ERPC, han mejorado las API para conocer la información de los líderes de Solana, sus ubicaciones estimadas y la latencia: la Leader Slot API ahora admite el RTT de referencia (medición de ping) desde 7 regiones de todo el mundo, y se ha lanzado la nueva Validators Information API.
En primer lugar, hemos ampliado la Leader Slot API (
getLeaderSlots) para poder obtener el RTT de referencia desde 7 regiones de observación de ERPC en todo el mundo (Fráncfort, Ámsterdam, Nueva York, Londres, Tokio, Singapur y Sídney). Anteriormente, las mediciones se tomaban únicamente desde Fráncfort.Al mismo tiempo, hemos lanzado la nueva Validators Information API (
getValidatorsInformation). Esta API lista, en una sola llamada, todos los validadores que ocupan al menos un leader slot en la época actual. Además del 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 de las 7 regiones.Ambas API están disponibles para todos los usuarios de ERPC a través de la interfaz JSON-RPC estándar.
- Documentación de la Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- Documentación de la Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
La diferencia frente a la infraestructura de trading tradicional: en Solana el destino de la comunicación cambia dinámicamente
En las bolsas y los sistemas financieros tradicionales, los destinos a los que se envían las órdenes —la bolsa, la pasarela, el motor de emparejamiento— suelen estar fijados a centros de datos o redes específicos.
Por ello, una vez que el usuario conoce el destino de conexión, puede optimizar continuamente su ruta de red hacia él. Como las ubicaciones de los servidores de destino no cambian con frecuencia, la ubicación de 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 los bloques— rota cada pocos slots según el calendario de líderes. Como los validadores que actúan como líderes están distribuidos por todo el mundo, tanto el destino al que deben llegar tus transacciones como la ruta de red más cercana a ese destino cambian continuamente.
En otras palabras, en Solana el destino de comunicación que hay que optimizar no puede tratarse como un punto de conexión único y fijo.
Primero es necesario identificar a los líderes actuales y futuros a partir del calendario de líderes. Además, hay que comprobar en qué región o red es más probable que se encuentre cada validador, y cuánta latencia hay desde cada ubicación de envío, antes de decidir la ruta de envío.
Comprender correctamente esta estructura es el punto de partida para el envío de transacciones de baja latencia y el diseño de infraestructura global en Solana.
Tratar el calendario de líderes y las ubicaciones de red como datos
En un entorno donde el destino cambia dinámicamente, no es práctico que una persona compruebe el líder y la ubicación de envío cada vez y cambie las rutas manualmente.
Lo que se necesita es obtener continuamente la siguiente información e integrarla en 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 de los que es responsable 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
- El momento en que se realizó cada medición y su estado de respuesta
La ubicación estimada y la latencia medida desempeñan papeles diferentes.
La información de ubicación puede utilizarse para decisiones a medio y largo plazo sobre dónde colocar la infraestructura y la capacidad. El RTT de referencia de cada región, en cambio, sirve para juzgar qué ubicación es actualmente más probable que ofrezca una ruta corta.
Un lugar física o geográficamente cercano no siempre es el más corto en la red. Por eso es importante decidir combinando la ubicación estimada con los valores realmente observados.
La Leader Slot API y la Validators Information API de ERPC son API pensadas para que puedas programar estas decisiones basándote en datos.
Leader Slot API: medición del RTT de referencia desde 7 regiones de todo el mundo
La Leader Slot API devuelve los próximos leader slots junto con la identidad del validador, el stake activo, los endpoints de red, la ubicación estimada, el RTT de referencia y más.
Hasta ahora, las mediciones de
pingToLeaders se recogían únicamente desde el origen de Fráncfort: un único punto de observación frente a una red de Solana distribuida globalmente.Con esta actualización, ahora puedes obtener el RTT de referencia medido desde las siguientes 7 regiones.
frankfurtamsterdamnylondontokyosingaporesydney
Al comparar el RTT de referencia de las 7 regiones de observación para cada líder, puedes juzgar desde qué ubicación de envío es más probable alcanzar una ruta de red corta.
Esto sirve como base de decisión no solo para el enrutamiento de transacciones, sino también para decidir en qué regiones colocar capacidad de RPC, gRPC, Direct Shreds, servidores de envío de transacciones y más.
Los resultados de la medición incluyen
icmpReplied, que indica si el validador respondió al ICMP, y measuredAt, que indica el momento en que se obtuvo la última medición correcta.Un validador que no responde al ICMP puede seguir operando con normalidad servicios como TPU y QUIC. Por eso, cuando
icmpReplied es false, debe tratarse no como "lejano" sino como "no medible por ICMP".Además, cuando no se puede obtener una medición correcta en el momento de la actualización, la entrada no se sobrescribe con un valor no medido: se conservan el último valor medido correctamente y su momento de medición.
Validators Information API: lista de la información de líderes de toda la época
La Leader Slot API es adecuada para decisiones a nivel de slot: "¿quién es el líder responsable de los próximos slots?"
La ubicación de la infraestructura y la planificación de capacidad, en cambio, requieren una visión más amplia.
- Qué validadores actúan como líderes en la época actual
- De cuántos slots es responsable cada uno
- En qué países y regiones se distribuyen
- Dónde colocar la infraestructura para acercarse a más líderes
La nueva Validators Information API (
getValidatorsInformation) es la API creada para responder a estas preguntas.Llamada sin parámetros, devuelve todos los validadores que actúan como líderes en al menos un slot de la época actual, una fila por validador. Por defecto, los resultados se devuelven en orden descendente por el número de leader slots ocupados.
Cada fila incluye la siguiente información.
slotCountstakeWeight(stake activo en SOL)- Identidad del validador
Cuando están disponibles, también se devuelve la siguiente información.
- Región, ciudad y país estimados
- Endpoints de red
- Versión del cliente
- RTT de referencia de las 7 regiones
Como los datos se actualizan con regularidad, llamar a la API periódicamente mantiene tu conjunto de datos de planificación al día.
También puedes acotar los resultados con los parámetros opcionales
limit (1–2000), country y region.La facturación se calcula según el número de validadores devueltos. El número de validadores líderes varía de una época a otra; en el ejemplo del momento de escribir este artículo, obtener los 673 validadores consume 6,800 tokens de API (créditos de uso de la API de ERPC), y obtener hasta 10 validadores consume 100 tokens de API.
Hacia un enrutamiento programable basado en datos
Estas API no están pensadas simplemente para mostrar una lista de validadores o el RTT de referencia.
El objetivo final es que puedas integrar el calendario de líderes, las ubicaciones estimadas de los validadores y el RTT de referencia de cada región de observación en la lógica de decisión de tus aplicaciones.
Por ejemplo, una aplicación puede obtener el próximo calendario de líderes, comparar el RTT de referencia de las 7 regiones de observación para cada líder y, a continuación, seleccionar la RPC o la ruta de envío de transacciones que va a utilizar.
También puedes analizar la distribución de líderes a lo largo de toda la época y colocar infraestructura por adelantado en regiones cercanas a los validadores con alto número de slots.
Los usos principales son los siguientes.
- Selección de rutas de envío a nivel de slot
- Planificación de capacidad a nivel de época
- Análisis de los validadores líderes por región
- Priorización que tiene en cuenta el stake activo y el número de slots
- Monitorización de los cambios en la distribución geográfica y de red entre épocas
- Selección automática 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 por sí sola no es suficiente.
Se vuelve importante seguir continuamente al líder cambiante y seleccionar dinámicamente las rutas de envío y la infraestructura según su ubicación y las condiciones de la red.
Hacia una infraestructura de Solana diseñada para la operación global
ERPC es una infraestructura de alto rendimiento para Solana, diseñada desde el primer día pensando en la operación global.
Nuestra red edge, las ofertas de bare metal y VPS, Direct Shreds, Geyser gRPC, los endpoints SWQoS y estas API de inteligencia operativa se ofrecen al servicio de un propósito común.
Ese propósito es proporcionar tanto datos como infraestructura a los desarrolladores que exigen una ejecución de baja latencia y eficiente en un entorno en el que usuarios y líderes están distribuidos por todo el mundo.
El RTT de referencia desde 7 regiones de todo el mundo y la información de validadores de toda la época ya pueden obtenerse mediante simples llamadas RPC. Las aplicaciones de Solana ahora pueden seleccionar ubicaciones de envío y rutas de red basándose en datos, en respuesta al líder en constante cambio.
Para los desarrolladores que buscan envíos de baja latencia, ubicación global de infraestructura y optimización dinámica del enrutamiento en Solana, se trata de una base de decisión directamente vinculada a la operación real.
Esperamos que te sea útil para seleccionar rutas de envío de baja latencia, diseñar infraestructura que reduzca las transferencias innecesarias de larga distancia y planificar la ubicación global de capacidad.
Para más detalles, consulta la documentación.
- 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
Noticias
