Solana, agora
Como ser mais rápido na Solana?
Se você constrói na Solana, já falou uma destas.
Mesma estratégia da mesa ao lado — só o meu bot entra atrasado.
O preço aparece. Eu mando a ordem. Minha transação não passa.
Já troquei de provedor de RPC mil vezes — e nada muda.
O que o tuning profissional
Você afinou o código. Turbinou a máquina. Nenhum dos dois é o gargalo — você persegue de longe demais um leader que não para de se mover.
Só hardware e código não ganham o slot. Quem ganha é o timing e o lugar.
Velocidade se compra. A vantagem está em entender.
Veja como chegar primeiro
O alvo em movimento
O lugar mais rápido nunca fica parado.
A cada slot — os ~400 ms que a Solana tem para montar um block — outro validator assume como leader, e quem está mais perto dele leva a melhor.
Não é um ponto fixo onde dá para fincar pé uma vez e pronto: na Solana, o melhor assento nunca se repete.
~400 ms · um novo leader a cada slot
O melhor assento, slot a slot
O leader dá a volta ao mundo, slot a slot. Você ganha um, e o próximo já está em outro lugar.
Veja o leader em movimento
RPC Solana aprimorado, Geyser gRPC e ShredStream
Epoch —
— countries
Leader
—
Live block producer
Distância é latência
Atravesse um continente e fique 100–300 ms atrás.
A luz na fibra e uma sequência de roteadores criam um piso que nenhum hardware consegue baixar. No mesmo rack, são cerca de 0.1 ms. Cruzando um oceano, são 100–300 ms — e um slot dura só uns 400 ms.
Na prática: com o leader na sua porta, você está dentro da janela; com ele do outro lado do planeta, já ficou de fora. Ser rápido em todo slot é estar perto de onde o leader cair.
Piso de ida e volta por distância · física, não benchmark
Quanto a distância custa a um pacote
- Mesma rede
- 0.1 ms
- Mesmo datacenter
- 0.3 ms
- Mesma cidade
- 1 ms
- País vizinho
- 5–10 ms
- Outro continente
- 100–300 ms
Um continente de distância custa centenas de vezes um salto no mesmo rack — e mais do que um slot inteiro. Proximidade não é um ajuste — é o orçamento todo.
Cobertura — por que uma cidade não basta
Nem a cidade mais cheia chega a um quarto da rede.
Frankfurt é onde os operadores se concentram — e mesmo a cidade mais movimentada tem só cerca de um quarto da rede, tanto em validators quanto em stake. Na maioria dos slots, o leader da vez está em outro lugar.
Estar em todo lugar é o ideal; os orçamentos obrigam a escolher. Então a pergunta não é só quem é o maior, mas quem tem menos máquinas disputando o mesmo espaço — o menos disputado. Amsterdã tem stake parecido com o de Frankfurt e bem menos validators amontoados — em geral, o assento mais tranquilo, e melhor.
Onde estão os validators da Solana
Cobertura — um node já ao lado de cada leader
Onde o leader cair, já há um node potente, ligado direto à Solana.
O posto de leader circula o globo slot a slot — então o node que ganha é o que já está mais perto. Um node na mesma região evita o salto de longa distância que gera o atraso.
Por isso não apostamos em um lugar só. Velocidade constante é estar perto em cada slot — e como o leader vive trocando de região, isso exige cobertura entre regiões. Rodamos nodes de nível validator onde o stake da Solana se concentra, numa única malha de baixa latência, e seguimos somando regiões — cada região nova são mais slots em que você já está ao lado do leader.
Global Data Center Partner
A velocidade é determinada pela distância até a Solana.
A região importa. Mas o nome da cidade sozinho não define o caminho de rede. Mesmo na mesma cidade, trânsito externo e saltos extras podem aumentar a latência. A ERPC seleciona data centers próximos aos servidores da Solana e mantém rotas curtas, sem trânsito externo e com turbo boost sustentado.
Rota premium ERPC
sem trânsito externo
RTT mínimo
Seleção do nome da cidade
trânsito externo / 7 saltos
70x mais lento
- 01Mesmo data centerEscolha primeiro a região e depois o data center mais próximo de Solana.
- 02Sem trânsito externoEvite caminhos AS externos para manter RTT e jitter baixos.
- 03Aceleração totalERPC exclui perfis de economia de energia e mantém os recursos em turbo boost sustentado.
Prioridade ponderada por stake (SWQoS)
Se suas transações vivem ficando de fora, você está preso na faixa do spam.
Os leaders da Solana dividem a banda de prioridade em duas faixas. Conexões com lastro de stake — SOL delegado a um validator — ficam com 80% da banda. O resto briga pelos outros 20% — a faixa entupida de spam.
Mandar a transação direto pro leader parece a jogada mais rápida — mas sem stake você cai na faixa lotada dos 20%, e sob carga sua transação nunca entra no block.
A resposta de verdade é um validator com stake. Rodamos um de ponta ligado a linhas de RPC de alta qualidade — hardware bem ao lado da Solana — para a sua transação passar pela faixa larga.
Um validator de ponta no nosso Shinobi Performance Pool
Como os leaders da Solana dividem a banda de prioridade
O stake corre na faixa larga de 80% até o validator — antes de qualquer taxa. Sem stake, você fica espremido na faixa do spam, os 20%.
Divisão 80 / 20 definida pelos leaders da Solana, não por nós
Benchmark medido
Máquina da mesma classe. Mas não a mesma velocidade.
AMD Turin, 4 vCPU, Amsterdã, Ubuntu 24.04 — o mesmo nas duas máquinas: uma numa grande cloud, a outra a nossa. No papel, são iguais. No benchmark, não.
Mesmo silício. A diferença é o nosso tuning — a máquina afinada e plantada bem ao lado da Solana.
node_bench · mesma execução, mesma região
ERPC vs uma grande cloud · mesma spec
- Poder de CPUsysbench · 4 threads · maior é melhor
- mais throughput de CPU1.9×
- Banda de memóriaSTREAM Triad · 4 GiB · maior é melhor
- mais banda de memória3.2×
- IOPS de discofio · 4K randread · QD32 · maior é melhor
- mais IOPS de disco16.6×
- Latência de disco · p99fio · 4K randread · QD32 · menor é melhor
- mais rápido no p9925.7×
events/s
MB/s
IOPS
µs
Todo o ambiente, no nível mais alto.
A ERPC afina cada camada entre você e o slot — RPC, streaming, validators, o bare metal por baixo — e planta tudo ao lado da Solana. Antes, montar isso era tarefa sua. Agora é só combinar os nossos produtos — o caminho mais rápido até a Solana.