A ERPC Publica "How to be faster on Solana?" (Como ser mais rapido na Solana?) — um Relatorio que Visualiza, com Dados ao Vivo, o que Determina a Velocidade na Solana como a Fisica da Distancia de Rede
A ERPC Publica "How to be faster on Solana?" (Como ser mais rapido na Solana?) — um Relatorio que Visualiza, com Dados ao Vivo, o que Determina a Velocidade na Solana como a Fisica da Distancia de Rede
A ELSOUL LABO B.V. (Sede: Amsterdam, Paises Baixos; CEO: Fumitake Kawasaki) e a Validators DAO, que operam a ERPC, tem o prazer de anunciar a publicacao de "How to be faster on Solana?" (Como ser mais rapido na Solana?), uma pagina de relatorio que apresenta — num unico percurso, de cima a baixo, que ate um programador nao especialista capta num relance — como ganhar velocidade na Solana.
Nos ultimos anos, um numero crescente de programadores e equipas dedicou-se ao trading de alta frequencia (HFT) e a infraestrutura financeira em tempo real em blockchains, e na Solana em particular. No entanto, o conhecimento por tras das perguntas mais basicas — por que motivo alguns sao mais rapidos e como ficar mais rapido — manteve-se disperso por artigos tecnicos de blog isolados e explicacoes fragmentarias, com poucos recursos que permitam captar o quadro completo com rapidez. Este relatorio reorganiza o nucleo dos artigos tecnicos que a ERPC publicou ao longo do tempo numa unica "linha de fisica" continua.
Este relatorio partilha uma compreensao pratica para usar a rede de forma mais eficiente e a maior velocidade — mesmo numa rede descentralizada cujos participantes estao espalhados pelo mundo. Acreditamos que partilhar de forma sistematica onde, e porque, surgem as diferencas de velocidade contribui para a eficiencia e o crescimento saudavel do ecossistema blockchain mais amplo, incluindo a Solana, para alem do interesse de qualquer fornecedor isolado.
How to be faster on Solana? (o relatorio): https://erpc.global/pt/how-to-be-faster/
Site Oficial da ERPC: https://erpc.global/pt
Painel da ERPC: https://dashboard.erpc.global/pt
O que Determina a Velocidade Nao e o Seu Codigo nem a Sua Maquina — e a Terceira Camada Invisivel
"Corro a mesma estrategia, mas so o meu bot e preenchido tarde." "Os precos atualizam bem, mas so as minhas transacoes nao chegam." "Mudei de fornecedor de RPC e nada mudou." — as queixas que os programadores que competem em velocidade exprimem na Solana sao surpreendentemente semelhantes.
O primeiro suspeito e sempre "talvez o meu codigo seja lento" ou "talvez as minhas especificacoes nao sejam suficientes." Otimizar o seu codigo e a sua maquina ajuda, claro. Mas em muitos casos em que ja afinou ambos a fundo, o que permanece ate ao fim — e e o mais ignorado — e uma terceira camada invisivel: a sua distancia de rede ate a Solana.
Quando o seu caminho de execucao ja esta bem otimizado, aquilo que a afinacao da CPU ao nivel da instrucao ainda consegue poupar vive no mundo dos nanosegundos a, no maximo, alguns microssegundos. A distancia de rede, em contraste, governa centenas de milissegundos — uma alavanca da ordem de cerca de 1000x esta adormecida na camada que as pessoas mais ignoram. Para alem do ponto em que ja poliu o seu codigo e a sua maquina, a maior margem restante esta nessa terceira camada.
Na Solana, o "Lugar Mais Rapido" Move-se pelo Mundo a Cada Slot
Na Solana, um slot avanca aproximadamente a cada 400 milissegundos, e a cada slot e atribuido um validator como seu "leader" para construir essa fatia do bloco. Os leaders mudam rapidamente (o mesmo validator pode deter varios slots consecutivos), e o servidor mais proximo desse leader ganha uma grande vantagem para esse slot.
E isto que o torna fundamentalmente diferente do trading de alta frequencia tradicional. Em acoes ou cambio (FX), colocar os seus servidores junto ao motor de correspondencia unico da bolsa — um ponto fixo que nao se move — mantinha-o a frente para sempre. Na Solana, o leader move-se pelo mundo slot a slot. O lugar mais rapido fica todas as vezes num sitio diferente. Acampar uma vez junto a um unico ponto e dar o assunto por encerrado simplesmente nao funciona aqui.
No relatorio, um globo movido por dados ao vivo da Leader Slot Information API da ERPC (getLeaderSlots) mostra o leader atual, e a sua rotatividade vertiginosa, exatamente como acontece. "O lugar mais rapido nao para de se mover" — isto nao e uma metafora, mas um facto que pode observar ao vivo.
A Distancia e Latencia — de ~0.1ms na Mesma Rede a 100–300ms Entre Continentes
A velocidade da luz atraves da fibra, e o numero de saltos (hops) de router ao longo do caminho, fixam um piso que nenhum hardware consegue bater. A distancia produz efeito aproximadamente nas seguintes ordens de grandeza:
- Mesma rede: ~0.1ms
- Mesmo datacenter: ~0.3ms
- Mesma cidade: ~1ms
- Pais vizinho: ~5–10ms
- Entre continentes: ~100–300ms
Um unico slot dura apenas cerca de 400 milissegundos. Os 100–300 milissegundos de atravessar um continente consomem por si sos a janela de um slot inteiro. Quando o leader esta a sua porta, chega dentro da janela; quando esta do outro lado do planeta, ja o perdeu antes mesmo de enviar. Ser rapido em todos os slots significa estar sempre "perto" de onde quer que o leader caia.
Note que os contrastes no relatorio — "~0.1ms na mesma rede" versus "num caminho indireto o numero de saltos de retransmissao (hops = os routers por onde um sinal passa) sobe para cerca de 7, e a latencia alarga-se para cerca de 70x" — sao numeros redondos destinados a transmitir, de forma intuitiva, o fosso entre uma rota proxima e uma distante. As grandes oscilacoes medidas aparecem nos dados ao vivo da Leader Slot Information API da ERPC: a latencia medida de um dado no ate ao leader muda muito consoante onde o leader esta (qual slot), e foram observadas oscilacoes da ordem de dezenas de vezes entre slots proximos e distantes. Um unico numero de "latencia media" e muitas vezes apenas um slot rapido e um slot lento a alternarem; a media frequentemente esconde a realidade.
E um "nome de cidade" nao e o proprio caminho de rede. Mesmo dentro da mesma cidade, se forem inseridos transito externo ou saltos adicionais, a latencia acumula-se apenas por causa disso. E precisamente por isso que se escolhe o no mais proximo pelo tempo de chegada medido (ping), e nao pela distancia num mapa.
Uma So Cidade Nao Chega — Multi-Regiao, Sempre Perto do Leader
A cidade onde os validators da Solana se concentram com maior densidade e Frankfurt. Mesmo assim, num instantaneo medido a data da publicacao, os validators reunidos em Frankfurt representam apenas cerca de um quarto da rede no seu conjunto — tanto por numero de validators como por stake. Os restantes cerca de tres quartos dos slots sao liderados a partir de algum lugar que nao Frankfurt.
Por outras palavras, mesmo que coloque a sua melhor maquina, sozinha, na cidade mais lotada, isso por si so nunca o pode tornar "sempre o mais rapido." Estar de prontidao em varias regioes (por exemplo Frankfurt / Amsterdam / New York / Tokyo / Singapore), recebendo perto de qualquer leader que esteja ativo, e fazendo a passagem a medida que o leader se move — esta e a maneira de ser rapido em todos os slots.
Quando as Suas Transacoes Nao Chegam, Esta Preso na Faixa do Spam
A velocidade nao e apenas uma questao de onde fica o seu servidor. Por qual faixa entrega a sua transacao tambem decide o sucesso ou o fracasso.
Da capacidade da TPU (Transaction Processing Unit) que recebe as transacoes, o leader aloca ate cerca de 80% a prioridade ponderada por stake — isto e, a ligacoes apoiadas por SOL comprometida com um validator (stake) (SWQoS / Stake-Weighted Quality of Service). Os restantes cerca de 20% sao partilhados por todas as outras ligacoes. Esta ultima e uma faixa lotada, repleta de spam. Note que esta alocacao de ~80% e decidida do lado do leader como uma questao do protocolo da Solana, e nao algo que a ERPC define.
Disparar transacoes diretamente para o leader parece a jogada mais rapida. Mas sem o apoio de stake, isso significa ficar na fila da faixa lotada de ~20%, e sob carga a sua transacao acaba por nunca entrar no bloco. A resposta essencial e enviar atraves de um caminho apoiado por stake — a partir de um RPC ligado a um staked validator atraves de uma relacao de trusted peer. A ERPC opera um staked validator de primeira linha, ligado a linhas de RPC de alta qualidade, como o suporte para isto (Shinobi Performance Pool).
O Hardware So Importa Quando Funciona a Plena Potencia
Mesmo um servidor colocado no sitio certo nao consegue tirar partido da proximidade que conquistou se a propria maquina nao funcionar a todo o gas. Um VPS virtualizado partilha um hypervisor, pelo que e propenso a jitter e a bloqueios provocados por "vizinhos barulhentos" precisamente quando as coisas ficam mais lotadas. O bare metal dedicado nao tem isso. O piso de velocidade de relogio que um validator da Solana tem de cumprir e 2.8GHz; o bare metal da ERPC funciona bem acima disso, num relogio elevado da classe 5.7GHz, mantendo a utilizacao em 30–40% — porque uma CPU fixada a 95% gera jitter como uma estrada congestionada.
Esta diferenca nao se limita ao bare metal de primeira linha. No relatorio, colocamos o VPS da ERPC (VPS++) lado a lado com uma maquina virtual de uma grande nuvem (major cloud) de especificacoes comparaveis (ambas AMD Turin / 4 vCPU) usando um benchmark real (node_bench). Isto nao e uma encenacao; e uma "medicao" que qualquer pessoa pode reproduzir com o mesmo metodo. A ERPC enfatiza de forma consistente a demonstracao da qualidade e da velocidade de entrega atraves da medicao, e nao de afirmacoes subjetivas ou de texto de marketing.
A Resposta Final: Mesma Rede = Distancia Zero
O ponto onde toda esta linha de raciocinio chega e um so: estar "na mesma rede" que a infraestrutura da Solana — RPC, validators e os caminhos em tempo real envolvidos no trading, como Jito e Shredstream. Na mesma rede sao ~0.1ms, e os pacotes nunca atravessam de todo a internet publica. "Pela internet publica," o predefinido para a maioria das pessoas, e exatamente a razao pela qual a maioria das pessoas e lenta. A distancia zero e a conclusao que amarra localizacao, maquina e stake.
ERPC — Cada Otimizacao que a Fisica Exigiu, numa So Plataforma
Para cada resposta que o relatorio deriva como fisica, a ERPC tem um meio correspondente preparado: VPS e bare metal na mesma rede (distancia zero), prontidao em varias regioes (FRA / AMS / NY / TYO / SGP) (sempre o mais rapido), encaminhamento baseado em ping medido (ate ao no verdadeiramente mais proximo por caminho, e nao por mapa), a API getLeaderSlots (saber a posicao do leader slot a slot) e bare metal da classe 5.7GHz afinado com o SLV de codigo aberto (plena potencia).
A ERPC nasceu porque, antes de mais, nos proprios precisavamos dela. Ao operar a Epics DAO de codigo aberto (um jogo de cartas na Solana), nao conseguiamos comprar este tipo de infraestrutura mesmo quando tentamos, pelo que nao tivemos outra opcao senao construi-la nos mesmos. Agora pode assentar sobre esse mesmo alicerce.
Na ERPC, pode combinar Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, servidores bare metal, RPC dedicado, SWQoS, uma Price API habilitada para Pyth, e Jet Analytics & Indexed RPC numa unica plataforma.
Usar Redes Descentralizadas de Forma Mais Rapida e Mais Eficiente
Ha uma parte da velocidade que pode ser melhorada atraves do investimento certo em infraestrutura. Mas o que este relatorio tenta transmitir de forma consistente e que compreender "onde, e porque, surge a diferenca" e a verdadeira vantagem. Assim que perceber onde esta a perder tempo — localizacao, caminho, maquina ou stake — pode entao escolher os recursos certos e concentrar-se no seu trabalho central: estrategia, programacao e desenvolvimento.
Mesmo numa rede descentralizada, a rede pode ser usada de forma eficiente. Partilhar essa realidade de maneira sistematica deve contribuir para a eficiencia e o crescimento do ecossistema blockchain mais amplo, incluindo a Solana, para alem do interesse de qualquer fornecedor isolado.
I&D e Melhoria Continua de Infraestrutura Especifica da Solana
Por tras da ERPC esta a investigacao e o desenvolvimento de infraestrutura especifica da Solana que a ELSOUL LABO continua a prosseguir. A ELSOUL LABO foi aprovada por cinco anos consecutivos desde 2022 ao abrigo do WBSO, o programa governamental de apoio a I&D dos Paises Baixos. Continua a I&D em infraestrutura de Solana RPC, operacao de validators, entrega de dados em tempo real e operacao e desenvolvimento assistidos por agentes de IA, e esses resultados refletem-se em servicos que incluem a ERPC, o SLV, a SLV AI e o data center especifico da Solana AS200261. A publicacao deste relatorio e, tambem ela, um esforco que decorre diretamente desta investigacao e desenvolvimento continuos. A ERPC continuara a publicar os seus resultados de forma sistematica.
Utilizacao e Aconselhamento
Para questoes sobre o conteudo deste relatorio, aconselhamento sobre como melhorar a velocidade da sua propria configuracao, ajuda na selecao de recursos ou no planeamento de uma migracao, ou questoes sobre benchmarks, crie por favor um ticket de suporte no Discord oficial da Validators DAO.
How to be faster on Solana? (o relatorio): https://erpc.global/pt/how-to-be-faster/
Painel da ERPC: https://dashboard.erpc.global/pt
Site Oficial da ERPC: https://erpc.global/pt
Discord Oficial da Validators DAO: https://discord.gg/C7ZQSrCkYR
Agradecemos sinceramente a todos os nossos utilizadores pela utilizacao continuada da ERPC.
Links
- How to be faster on Solana? (o relatorio): https://erpc.global/pt/how-to-be-faster/
- Site Oficial da ERPC: https://erpc.global/pt
- Painel da ERPC: https://dashboard.erpc.global/pt
- Precos da ERPC: https://erpc.global/pt/price/
- Site Oficial do SLV: https://slv.dev/pt
- SLV GitHub: https://github.com/validatorsDAO/slv
- Discord Oficial da Validators DAO: https://discord.gg/C7ZQSrCkYR
Notícias
