ERPC expande a Solana Leader Slot API com medição de ping a partir de 7 regiões globais — Validators Information API também lançada
ERPC expande a Solana Leader Slot API com medição de ping a partir de 7 regiões globais — Validators Information API também lançada
A ELSOUL LABO B.V. (sede: Amsterdã, Países Baixos; CEO: Fumitake Kawasaki) e a Validators DAO, operadoras da ERPC, aprimoraram as APIs para compreender as informações de líderes, as localizações estimadas e a latência da Solana, adicionando suporte a RTT de referência (medição de ping) a partir de 7 regiões globais na Leader Slot API e lançando a nova Validators Information API.
Primeiro, expandimos a Leader Slot API (
getLeaderSlots) para que o RTT de referência possa ser obtido a partir de 7 regiões de observação da ERPC ao redor do mundo (Frankfurt, Amsterdã, Nova York, Londres, Tóquio, Singapura e Sydney). Anteriormente, as medições eram feitas apenas a partir de Frankfurt.Ao mesmo tempo, lançamos a nova Validators Information API (
getValidatorsInformation). Essa API lista, em uma única chamada, todos os validators que detêm pelo menos um leader slot na epoch atual. Além da contagem de slots e do stake ativo, ela também retorna, onde disponível, a localização estimada, os endpoints de rede, a versão do client e o RTT de referência das 7 regiões.Ambas as APIs estão disponíveis para todos os usuários da ERPC por meio da interface JSON-RPC padrão.
- Documentação da Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- Documentação da Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
A diferença em relação à infraestrutura de negociação tradicional: na Solana, o destino da comunicação muda dinamicamente
Nas bolsas e nos sistemas financeiros tradicionais, os destinos para os quais as ordens são enviadas — bolsas, gateways, motores de correspondência — geralmente são fixos em data centers ou redes específicos.
Como resultado, uma vez que os usuários conhecem o destino da conexão, eles podem otimizar continuamente o caminho de rede até ele. Como as localizações dos servidores de destino não mudam com frequência, o posicionamento da infraestrutura e as rotas de comunicação podem ser projetados de forma relativamente estática.
Na Solana, por outro lado, o líder — o validator responsável por produzir blocos — alterna a cada poucos slots de acordo com o cronograma de líderes. Como os validators que atuam como líderes estão distribuídos pelo mundo, tanto o destino que suas transações precisam alcançar quanto o caminho de rede mais próximo desse destino mudam continuamente.
Em outras palavras, na Solana, o destino de comunicação a ser otimizado não pode ser tratado como um ponto de conexão único e fixo.
Primeiro, é preciso identificar, a partir do cronograma de líderes, quem são os líderes atuais e futuros. Em seguida, verifica-se em qual região ou rede cada validator provavelmente está localizado e qual é a latência a partir de cada local de envio, antes de decidir a rota de envio.
Compreender corretamente essa estrutura é o ponto de partida para o envio de transações com baixa latência e para o design de infraestrutura global na Solana.
Tratando o cronograma de líderes e as localizações de rede como dados
Em um ambiente em que o destino muda dinamicamente, não é prático que uma pessoa verifique o líder e o local de envio a cada momento e troque de rota manualmente.
O que é necessário é obter continuamente as seguintes informações e incorporá-las à lógica de decisão das suas aplicações e da sua infraestrutura.
- Os líderes responsáveis pelos slots atuais e futuros
- O número de slots pelos quais cada validator é responsável
- O país, a cidade e a região estimados de cada validator
- Endpoints de rede como TPU e QUIC
- RTT de referência coletado em cada região de observação
- O horário em que cada medição foi obtida e seu status de resposta
A localização estimada e a latência medida desempenham papéis diferentes.
As informações de localização podem ser usadas para decisões de médio e longo prazo sobre onde posicionar infraestrutura e capacidade. O RTT de referência de cada região, por outro lado, serve de insumo para avaliar a partir de qual local é atualmente mais provável alcançar um caminho curto.
Um local física ou geograficamente próximo nem sempre é o caminho mais curto na rede. Por isso, é importante tomar decisões combinando a localização estimada com os valores realmente observados.
A Leader Slot API e a Validators Information API da ERPC são APIs projetadas para permitir que você programe essas decisões com base em dados.
Leader Slot API: medindo RTT de referência a partir de 7 regiões globais
A Leader Slot API retorna os próximos leader slots junto com a identidade do validator, o stake ativo, os endpoints de rede, a localização estimada, o RTT de referência e mais.
Até agora, as medições de
pingToLeaders eram coletadas apenas a partir da origem em Frankfurt — um único ponto de observação em uma rede Solana distribuída globalmente.Com esta atualização, agora você pode obter o RTT de referência medido a partir das seguintes 7 regiões.
frankfurtamsterdamnylondontokyosingaporesydney
Ao comparar o RTT de referência das 7 regiões de observação para cada líder, você pode avaliar a partir de qual local de envio é mais provável alcançar um caminho de rede curto.
Isso serve como insumo de decisão não apenas para o roteamento de transações, mas também para decidir em quais regiões alocar capacidade de RPC, gRPC, Direct Shreds, servidores de envio de transações e mais.
Os resultados das medições incluem
icmpReplied, que indica se o validator respondeu ao ICMP, e measuredAt, que indica o horário em que a última medição bem-sucedida foi obtida.Um validator que não responde ao ICMP ainda pode estar operando normalmente serviços como TPU e QUIC. Por isso, quando
icmpReplied é false, o resultado deve ser tratado não como “distante”, mas como “não mensurável via ICMP”.Além disso, quando uma medição bem-sucedida não pode ser obtida no momento da atualização, a entrada não é sobrescrita com um valor não medido — o último valor medido com sucesso e o horário dessa medição são mantidos.
Validators Information API: listando informações de líderes de toda a epoch
A Leader Slot API é adequada para decisões no nível do slot — “quem é o líder responsável pelos próximos slots?”
O posicionamento de infraestrutura e o planejamento de capacidade, por outro lado, exigem uma visão mais ampla.
- Quais validators estão atuando como líderes na epoch atual
- Por quantos slots cada um deles é responsável
- Em quais países e regiões eles estão distribuídos
- Onde posicionar a infraestrutura para ficar mais próximo de mais líderes
A nova Validators Information API (
getValidatorsInformation) é a API criada para responder a essas perguntas.Chamada sem parâmetros, ela retorna todos os validators que atuam como líder em pelo menos um slot na epoch atual, uma linha por validator. Por padrão, os resultados são retornados em ordem decrescente do número de leader slots detidos.
Cada linha inclui as seguintes informações.
slotCountstakeWeight(stake ativo em SOL)- Identidade do validator
Onde disponíveis, as seguintes informações também são retornadas.
- Região, cidade e país estimados
- Endpoints de rede
- Versão do client
- RTT de referência das 7 regiões
Como os dados são atualizados regularmente, chamar a API periodicamente mantém seu dataset de planejamento atualizado.
Você também pode restringir os resultados usando os parâmetros opcionais
limit (1–2000), country e region.A cobrança é feita de acordo com o número de validators retornados. O número de validators líderes varia de uma epoch para outra; no exemplo do momento da redação, buscar todos os 673 validators consome 6,800 tokens de API (créditos de uso da API da ERPC), e buscar até 10 validators consome 100 tokens de API.
Rumo ao roteamento programável e baseado em dados
Essas APIs não servem simplesmente para exibir uma lista de validators ou o RTT de referência.
O objetivo final é permitir que você incorpore o cronograma de líderes, as localizações estimadas dos validators e o RTT de referência de cada região de observação à lógica de decisão das suas aplicações.
Por exemplo, uma aplicação pode buscar o cronograma de líderes futuros, comparar o RTT de referência das 7 regiões de observação para cada líder e, em seguida, selecionar a rota de RPC ou de envio de transações a ser usada.
Você também pode analisar a distribuição de líderes em toda a epoch e posicionar antecipadamente a infraestrutura em regiões próximas a validators com alta contagem de slots.
Os usos típicos incluem os seguintes.
- Seleção de rotas de envio no nível do slot
- Planejamento de capacidade no nível da epoch
- Análise de validators líderes por região
- Priorização que leva em conta o stake ativo e a contagem de slots
- Monitoramento de mudanças na distribuição geográfica e de rede entre epochs
- Seleção automática entre servidores de RPC e de envio implantados em várias regiões
Na Solana, onde o destino muda dinamicamente, a otimização estática de rede por si só não é suficiente.
Torna-se importante acompanhar continuamente o líder em mudança e selecionar dinamicamente rotas de envio e infraestrutura de acordo com sua localização e as condições da rede.
Rumo a uma infraestrutura Solana projetada para operação global
A ERPC é uma infraestrutura de alto desempenho para Solana, projetada desde o primeiro dia com a operação global em mente.
Nossa edge network, nossas ofertas de bare metal e VPS, Direct Shreds, Geyser gRPC, endpoints SWQoS e estas APIs de inteligência operacional são todos fornecidos com um propósito comum.
Esse propósito é fornecer tanto dados quanto infraestrutura aos builders que buscam execução eficiente e de baixa latência em um ambiente em que usuários e líderes estão distribuídos pelo mundo.
O RTT de referência de 7 regiões globais e as informações de validators de toda a epoch agora podem ser obtidos por meio de chamadas RPC simples. As aplicações Solana agora podem selecionar locais de envio e rotas de rede com base em dados, em resposta ao líder em constante mudança.
Para builders que buscam envio de baixa latência, posicionamento global de infraestrutura e otimização dinâmica de roteamento na Solana, este é um insumo de decisão diretamente ligado à operação real.
Esperamos que isso ajude na seleção de rotas de envio de baixa latência, no design de infraestrutura que reduz transferências desnecessárias de longa distância e no planejamento de capacidade global.
Para detalhes, consulte a documentação.
- 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
Notícias
