Princípio fundamental da internet: quanto mais perto, mais rápido. Sempre — inclusive na Solana
Muitos traders e projetos que buscam o “ambiente mais rápido” olham primeiro para a latência média.
Ela pode ser útil como referência de comparação, mas, se o objetivo é negociar em zero slot — em outras palavras, na faixa de 200–400 ms —, a latência média nunca mostrará o que você precisa.
A Solana é distribuída globalmente, e a comunicação intercontinental inevitavelmente incorre em centenas de milissegundos de atraso.
Enquanto você estiver focado em uma média que inclui tais atrasos, a velocidade que você realmente precisa permanecerá fora de alcance.
Na realidade, o resultado é decidido reduzindo apenas alguns milissegundos dentro de sua própria região, onde ocorre a comunicação de curta distância.
Recupere a intuição de velocidade
Ao pensar em redes, imagine-se dirigindo um carro. O ponto de partida é a sua casa, o destino é o seu escritório. Uma curta viagem é simples e rápida, com pouco risco de acidentes ou de trânsito.
Uma longa viagem, em contraste, envolve cruzamentos, rodovias, túneis — e em algum lugar ao longo da viagem de ida e volta, é provável que ocorra congestionamento.
A internet funciona da mesma forma. Quanto mais longe o servidor, mais saltos são necessários, e o tempo de ida e volta torna-se mais variável. Aproximar o destino é a rota mais curta para alcançar a máxima velocidade e estabilidade.
Por que as médias não ganham
Dados da rede Solana: Validators Solutions
Na Solana, os líderes alternam para produzir blocos, por isso a proximidade física com o líder atual determina o resultado. Líderes são distribuídos globalmente, e não é incomum que eles estejam localizados em diferentes continentes.
A comunicação intercontinental supera 100 ms no ping, e aumenta para várias centenas de milissegundos para fluxos.
Por mais que você tente melhorar uma média que inclui esses atrasos, ela não se traduzirá em desempenho real. É simplesmente impossível recuperar a desvantagem nos slots intercontinentais.
O ponto não é perseguir médias, mas focar em sua própria região e minimizar os percursos de ida e volta dentro desse escopo. Lutar por alguns milissegundos a curta distância é a única abordagem prática com uma vantagem competitiva real.
Para referência, estes são valores básicos de ida e volta por distância:
| Distância | Ping de ida e volta (aprox.) |
|---|---|
| Mesma rede | ~0,1 ms |
| Conexão privada | ~0,2 ms |
| Mesmo data center | ~0,3 ms |
| Mesma cidade | ~1 ms |
| País vizinho | ~5–10 ms |
| Intercontinental | ~100–300 ms |
A latência efetiva aumenta ainda mais dependendo do método de comunicação devido aos custos de manutenção e sobrecarga do protocolo:
| Método | Multiplicador de latência | Observações |
|---|---|---|
| Ping (ideal) | 1× | Apenas o limite inferior de referência |
| POST (envio único) | ~2–3× | Controle de ida e volta, novas tentativas e TLS |
| Stream | ~5× | Conexão persistente, controle de congestionamento e buffers |
Como medir a proximidade
A proximidade deve ser medida com dados, não por intuição. Comece verificando a posição atual da epoch. Use o RPC getEpochInfo para obter os dados mais recentes da epoch e as quantidades de slots decorridos e restantes.
Em seguida, use getRecentPerformanceSamples para estimar os tempos médios recentes dos slots. Multiplicar o tempo médio de slot pela quantidade de slots restantes dá uma estimativa aproximada de quantos segundos até a transição — útil para planejar a preparação e as trocas.
À medida que a transição se aproxima, prepare-se para recuperar os líderes-alvo com getSlotLeaders.
A lista de nós do cluster está disponível com getClusterNodes, para que você possa cruzar os dados dos líderes com informações de nó, usando IPs públicos ou endereços de gossip para estimar a localização geográfica dos líderes programados.
Um cuidado: a geolocalização IP tem erros e atrasos, então as estimativas podem estar erradas. Depois de mapear locais, sempre execute pings a partir de cada local para medir diretamente os atrasos de ida e volta.
A rede é como uma viagem de carro — não apenas a distância, mas a rota escolhida afeta o tempo de chegada. O ping mostra, de forma simples, quão congestionadas são as estradas atuais.
Não confie em uma única medição; faça várias medições em intervalos curtos e use a mediana para reduzir o ruído.
Não descarte os resultados após a utilização. Acumule dados de ida e volta e mapeamentos por local em seu próprio banco de dados, e atualize-os incrementalmente com workers leves em cada transição de época. Isso estabiliza as operações e acelera a tomada de decisão.
A localização da aplicação define a latência
A velocidade não é determinada apenas pelas especificações do servidor. A localização da aplicação é igualmente importante.
Como exemplo extremo, monitorar a partir de Tóquio o que acontece em Frankfurt é desvantajoso. A latência de ida e volta, por si só, acumula atrasos e sempre coloca sua aplicação em desvantagem.
Implante recursos em cada local, conclua a recepção e o processamento localmente ou encaminhe os dados ao próximo local pela rota mais curta. Essa estrutura melhora a cobertura e a capacidade de resposta.
VPS implantado na mesma rede
Nossas instâncias VPS são implantadas por região na mesma rede que os endpoints dedicados à Solana, reduzindo a comunicação externa e alcançando os menores tempos de ida e volta.
Essas instâncias podem ser implantadas rapidamente e em pequena escala por região. Mesmo distribuir workers de apenas 1 a 2 núcleos reduz a latência efetiva e aumenta a resiliência contra oportunidades perdidas.
Próximo lançamento em setembro de 2025: “SUPER EPYC VPS”
Este mês, a partir da região mais popular de Frankfurt, planejamos lançar “SUPER EPYC VPS”, usando CPUs de data center com frequência líder de mercado de 5,7 GHz.
A adoção das CPUs de última geração para produtos VPS não é comum, o que limita a disponibilidade. Para aqueles que procuram o VPS mais rápido, será uma opção forte.
Para máxima qualidade e velocidade: bare metal
Embora o VPS divida um servidor físico em partes virtualizadas, os servidores de bare metal dedicam toda a CPU, memória, disco e largura de banda de rede somente a você.
Isso torna mais fácil manter um desempenho estável e alto mesmo durante os horários de pico, ideal para aplicações Solana que requerem latência consistentemente baixa.
Para casos de uso Solana, as CPUs Ryzen são especialmente populares, alcançando velocidades máximas de clock de 5,7 GHz. O EPYC é projetado para minimizar a sobrecarga da virtualização, enquanto o Ryzen é projetado para maximizar o desempenho em uma única thread sem virtualização. Escolha de acordo com o seu caso de uso.
Desafios que a ERPC resolve
- Falhas de transação e flutuações de latência comuns em ambientes RPC típicos
- Limitações de desempenho impostas por muitos prestadores de infraestrutura
- Impacto significativo da distância da rede na qualidade da comunicação
- Acesso limitado de projetos menores a uma infraestrutura de alta qualidade
Detalhes sobre produtos, testes gratuitos, processo de integração, configurações dedicadas, consultas de estoque e participação na lista de espera estão disponíveis pelo Painel Web do ERPC:
- Site oficial do ERPC: https://erpc.global/pt
- Painel Web do ERPC: https://dashboard.erpc.global/pt
Continuaremos nossos esforços em P&D, trabalhando para estabilizar a oferta e expandir nossa linha de produtos, oferecendo valor para mais projetos em todo o mundo.
Agradecemos seu apoio contínuo.
