A ERPC leva o XDP e o zero-copy para produção nos nós RPC e Geyser gRPC em todas as regiões

A ELSOUL LABO B.V. (sede: Amsterdã, Países Baixos; CEO: Fumitake Kawasaki) e a Validators DAO, que operam a ERPC, têm o prazer de anunciar que a ERPC levou o caminho rápido XDP e o zero-copy AF_XDP do Solana v4 (Agave 4.x) para produção nos nós RPC e nos nós Solana Geyser gRPC de todas as regiões. Isso expande para a infraestrutura de produção de cada região a otimização comprovada primeiro na origem do Geyser gRPC da região de Nova York (NY).

O caminho rápido XDP e o zero-copy AF_XDP são otimizações orientadas ao Turbine que se tornaram disponíveis no Solana v4 (Agave 4.x). Quanto às flags de inicialização, a linha Agave 4.1 tornou obsoleta a família --experimental-retransmit-xdp-* e a organizou em --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy. Apoiando-se nesse caminho rápido XDP orientado ao Turbine e no zero-copy, a ERPC aplicou-o em produção não apenas nos nós de origem que sustentam o Geyser gRPC, mas também nos nós RPC. Tanto os nós RPC quanto os nós Geyser gRPC recebem via Turbine os shreds que compõem os blocos. Ao usar XDP e zero-copy para reduzir a sobrecarga do kernel nesse caminho de propagação e ingestão de shreds, o Geyser gRPC apresenta menor atraso na entrega de stream, enquanto o RPC ganha melhor frescura de estado e maior capacidade de acompanhar o estado mais recente. Essa mudança já está em execução em produção em todas as regiões. Clientes que priorizam o desempenho de first-arrival podem experimentar o RPC e o Geyser gRPC de todas as regiões imediatamente — via cobrança por hora (por hora) ou Crypto Pay (SOL / USDC / EURC).

Site oficial da ERPC: https://erpc.global/pt Painel da ERPC: https://dashboard.erpc.global/pt

O que a implantação em todas as regiões muda — tornando mais rápido, em todo lugar, o caminho que captura os shreds

No Solana, o leader responsável pela produção de blocos é rotacionado em um ciclo curto, de modo que a origem da comunicação está sempre em movimento. Nessa estrutura, o que importa na prática não é estar próximo de um único ponto fixo, mas ter alta probabilidade de estar próximo da rede onde os principais nós e validadores estão concentrados — e isso afeta diretamente a latência, as taxas de retransmissão e as taxas de falha na operação real. É por isso que a ERPC acredita que faz sentido não tornar rápida apenas uma máquina, mas elevar ao mesmo nível os nós de produção de todas as regiões.

A chave dessa implantação é que o alvo da otimização é o "caminho de propagação e ingestão de shreds no Turbine". Tanto para o RPC quanto para o Geyser gRPC, a velocidade final é sustentada por "quão rapidamente um nó consegue capturar um bloco". XDP e zero-copy são otimizações que reduzem a sobrecarga exatamente desse estágio de captura — a recepção, o retransmit e a propagação de shreds pelo Turbine. Ao aplicar isso aos nós de produção de cada região, não importa qual ponto de conexão de qual região o cliente utilize, ele pode receber dados por um caminho otimizado.

O que são o caminho rápido XDP e o zero-copy do Solana v4

XDP (eXpress Data Path) é uma tecnologia do kernel Linux que permite que código de rede de alto desempenho contorne grande parte do caminho usual de processamento de pacotes do kernel. Ao reduzir cópias de dados e trocas de contexto, ele processa pacotes com muito menos sobrecarga do que a pilha de rede padrão.

No Agave (o cliente validador do Solana), o XDP é aplicado ao Turbine, o protocolo que propaga os blocos entre os nós validadores. Os shreds recebidos são processados por um programa eBPF anexado próximo à placa de interface de rede (NIC) e mapeados para buffers no espaço de usuário via AF_XDP. Quando o modo zero-copy é usado, os dados recebidos são entregues diretamente do kernel ao espaço de usuário sem cópia. Os shreds de saída também aproveitam o caminho de envio do AF_XDP para reduzir cópias e sobrecarga de chamadas de sistema no caminho crítico.

A Anza introduziu o XDP para o Turbine na linha Agave 3.x (a partir do v3.0.9) e o levou para a base do Solana v4 (Agave 4.x). As flags de inicialização foram organizadas ao longo de versões sucessivas: a linha Agave 4.1 tornou obsoleta a família --experimental-retransmit-xdp-* e a organizou em --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy. Segundo o guia de configuração da Anza, com o XDP, grandes validadores podem aproximar-se de 150.000 pacotes de saída por segundo através do fanout do Turbine.

Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide

Aplicado aos nós Geyser gRPC — acelerando a ingestão no lado da origem

O Geyser gRPC é o caminho para receber atualizações de conta, slot, bloco e transação como um stream, em vez de por polling. Aqui, uma diferença de um milissegundo está diretamente ligada à captura de oportunidades de execução e à velocidade percebida no front-end. O atraso do Geyser é, em última análise, sustentado por "quão rapidamente a origem consegue capturar um bloco".

XDP e zero-copy são justamente as otimizações que reduzem a sobrecarga desse caminho de propagação e ingestão de shreds no lado da origem. À medida que a origem consegue receber e propagar shreds mais rápido, ela pode observar e reconstruir os blocos em um estágio mais precoce, o que encurta o atraso até que essas atualizações cheguem aos clientes através do stream Geyser gRPC. Na região de Nova York (NY), onde aplicamos isso primeiro, confirmamos por meio de medição de código aberto que essa otimização é eficaz na região de cauda do atraso de entrega. Agora estendemos a mesma otimização aos nós Geyser gRPC de todas as regiões.

Aplicado aos nós RPC — melhorando a frescura do estado e acompanhando o estado mais recente

O que há de novo nesta implantação é que aplicamos essa otimização também aos nós RPC. Os nós RPC também recebem via Turbine os shreds que compõem os blocos e atualizam seu próprio ledger e estado. Quando XDP e zero-copy reduzem a sobrecarga dessa ingestão e propagação de shreds baseada no Turbine, os nós RPC conseguem ingerir blocos mais novos mais cedo.

Para os clientes que usam RPC, isso não significa que todos os métodos RPC fiquem uniformemente mais rápidos, mas se manifesta como a frescura do estado que o nó mantém. Quando você consulta o slot ou bloco mais recente, ou o estado mais recente de uma conta, o fato de que a informação que o nó já ingeriu é mais nova está diretamente ligado à frescura dos dados na resposta. Além disso, uma menor sobrecarga no caminho de propagação e ingestão se traduz em margem para o nó processar atualizações sem descartá-las sob carga pesada. A mesma otimização da entrega de stream do Geyser gRPC também funciona como a base que sustenta a frescura dos dados que o RPC retorna — essa é a razão pela qual desta vez estendemos o escopo aos nós RPC.

Levado aos nós de produção de todas as regiões — o que habilitamos

A ERPC migrou os nós RPC e os nós Geyser gRPC de todas as regiões para o Solana v4 (Agave 4.x) e colocou em produção o caminho rápido XDP orientado ao Turbine e o zero-copy AF_XDP. Apoiando-nos no esquema de flags de inicialização --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy organizado na linha Agave 4.1, habilitamos de acordo com a configuração de cada região.

Habilitar o XDP exige um ajuste avançado e propenso a erros: um kernel recente, uma NIC compatível com XDP, as capabilities corretas de systemd para o processo do validador, as flags de inicialização corretas e o pinning apropriado de núcleos de CPU. Implantar isso não em um único nó, mas nos nós de produção de cada região — verificando ao mesmo tempo a NIC, o kernel e a configuração de rede diferentes de cada região — eleva ainda mais a dificuldade operacional. A ERPC aplica o know-how operacional acumulado ao operar validadores no topo da rede diretamente à construção e operação dos nós de origem e dos nós RPC de cada região.

E o know-how operacional dessa otimização está consolidado como uma receita na ferramenta de operação Solana de código aberto SLV. O SLV oferece desde a habilitação do XDP (por meio de variáveis de configuração como xdp_enabled / xdp_zero_copy) até a medição do atraso de entrega (slv check geyserbench), de uma forma que qualquer pessoa pode reproduzir por meio de conversas com um agente de IA ou via CLI. A otimização que a ERPC alcançou em todas as regiões não é um truque pontual para uma única máquina, mas se apoia em uma receita operacional reproduzível.

SLV GitHub: https://github.com/validatorsDAO/slv

Verifique com seus próprios números, a partir da sua própria conexão

O quanto de diferença essa otimização gera varia com a origem da conexão, a rota, o horário e a distribuição do leader. É exatamente por isso que a ERPC dá importância a mostrar a qualidade de entrega não por meio de alegações subjetivas ou textos de marketing, mas por meio de medições que qualquer pessoa pode verificar com o mesmo método. O que os clientes podem verificar não é um número fixo, mas o próprio método de medição.

Para o Geyser gRPC, as ferramentas de benchmark da ERPC são de código aberto. Para comparações de first-arrival você pode usar slv check geyserbench --kind grpc, e para verificações de conectividade e latência de um endpoint individual, slv check grpc, comparando em condições próximas à sua própria carga de trabalho. Para o RPC, da mesma forma, a abordagem mais confiável é medir e observar a frescura dos dados retornados e o comportamento das respostas a partir do seu próprio ponto de conexão, usando as requisições que o seu próprio bot ou aplicação realmente envia.

Poder tomar decisões com base em números que você mesmo mediu, em vez de alegações de um fornecedor, é o ponto de partida para clientes que priorizam o desempenho de first-arrival. Os passos desde a instalação do SLV até a execução da medição estão publicados no guia SLV Getting Started.

Site oficial do SLV: https://slv.dev/pt SLV Getting Started: https://slv.dev/pt/doc/general/getting-started/ Comparação de velocidade do Solana Geyser gRPC: https://erpc.global/pt/doc/geyser-grpc/speed-comparison/

Suprimindo a latência derivada da distância por design — o data center específico para Solana AS200261

A vantagem de latência da ERPC não vem apenas da otimização de software. Ao posicionar nós de origem, endpoints de recepção e nós de processamento dentro de data centers premium onde os validadores Solana estão densamente concentrados, a ERPC suprime a latência derivada da distância já na fase de design.

A ELSOUL LABO opera um data center específico para Solana sob seu próprio ASN (AS200261), atribuído pela RIPE NCC, como parte da plataforma ERPC. Otimizações de software como o XDP e o zero-copy de hoje só entregam seu efeito máximo sobre esse design de proximidade física e de rede. Com a proximidade em nível de design e a otimização de software no lado do nó ambas em vigor, concretizam-se o desempenho de first-arrival, a qualidade de streaming de baixa latência e as respostas RPC frescas.

Uma linhagem de fortalecimento contínuo da infraestrutura

Esta implantação em todas as regiões insere-se na linhagem de fortalecimento de infraestrutura que a ERPC vem buscando continuamente. É a otimização de geração mais recente, seguindo o upgrade da infraestrutura Geyser gRPC em todas as regiões em dezembro de 2025, o fortalecimento em larga escala da região de Frankfurt (FRA) em janeiro de 2026 e a aplicação anterior de XDP e zero-copy na região de Nova York (NY) em junho de 2026. A otimização comprovada em NY foi agora estendida — com os nós RPC adicionados ao seu escopo — à infraestrutura de produção de cada região.

Em vez de responder ao aumento da demanda com limites ou degradação, a ERPC a absorve de forma consistente fortalecendo a própria infraestrutura. Continuamos a refletir as otimizações de geração mais recente em nossa infraestrutura de produção, verificando repetidamente NICs, kernels e configurações de rede compatíveis. O RPC e o Geyser gRPC da ERPC continuarão a evoluir.

Verifique a partir de uma única hora com a cobrança por hora

O RPC e o Geyser gRPC da ERPC podem ser experimentados a partir de uma única hora por meio do plano de cobrança por hora. Isso torna possível um ciclo de verificação de baixo risco: contrate por apenas uma hora, confirme o comportamento real visto a partir do ponto de conexão do seu próprio bot ou aplicação dentro dessa hora e decida sobre migrar para um plano mensal ou anual com base nos resultados. As medições com slv check descritas acima podem ser executadas como estão dentro dessa hora de teste.

Assim que sua configuração e seu uso se tornarem claros, mudar para um plano mensal ou anual mantém você no mesmo painel e na mesma qualidade de endpoint.

Painel da ERPC: https://dashboard.erpc.global/pt

Crypto Pay (SOL / USDC / EURC) suportado

A ERPC oferece o Crypto Pay para a compra de créditos ERPC e para o pagamento de seus planos, e ele também é suportado para o plano de cobrança por hora. Você pode escolher SOL, ou as stablecoins USDC / EURC, como ativo de pagamento. O EURC pode ser enviado diretamente, enquanto USDC ou SOL são trocados por EURC via Orca, com a transferência concluída dentro do mesmo fluxo.

Para equipes que constroem e operam no Solana, poder lidar com os custos de infraestrutura de uma maneira próxima ao seu fluxo existente de gestão de fundos baseado em carteira é uma melhoria prática que reduz o atrito para iniciar a verificação. A verificação por cobrança por hora descrita acima também pode ser iniciada diretamente a partir dos ativos em sua carteira Solana.

Encomende, pague e gerencie infraestrutura específica para Solana em uma única plataforma

A ERPC permite 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 em uma única plataforma.

O Painel da ERPC oferece suporte a 16 idiomas, permitindo que você lide com a seleção de plano, a seleção de região, as verificações de estoque, a adição ao carrinho, as recargas de crédito, o checkout, a revisão de chaves de API e endpoints, a verificação de uso e a criação de tickets de suporte — tudo a partir da mesma tela.

P&D e melhoria contínua da infraestrutura específica para Solana

Por trás da ERPC está a pesquisa e o desenvolvimento de infraestrutura específica para Solana que a ELSOUL LABO continua a perseguir. A ELSOUL LABO foi aprovada por cinco anos consecutivos desde 2022 no âmbito do WBSO, o programa governamental de apoio a P&D dos Países Baixos. Ela continua a P&D em infraestrutura de RPC do Solana, operação de validadores, entrega de dados em tempo real e operação e desenvolvimento assistidos por agente de IA, e esses resultados são refletidos em serviços que incluem ERPC, SLV, SLV AI e o data center específico para Solana AS200261.

O suporte de hoje a Solana v4 / XDP / zero-copy em todas as regiões também tomou forma a partir da operação de validadores no topo da rede. A ERPC continuará a fornecer infraestrutura de baixa latência próxima à rede Solana e a demonstrar sua qualidade por meio de medições que qualquer pessoa pode verificar com o mesmo método.

Uso e consultoria

Para configurações regionais ideais, incluindo o RPC e o Geyser gRPC de todas as regiões, a escolha entre planos gRPC autônomos e planos gRPC Bundle, a opção entre cobrança por hora, mensal e anual, e o design de migração a partir de uma configuração existente, oferecemos consultoria individual no Discord oficial da Validators DAO.

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 usuários pelo uso contínuo da ERPC.

A ERPC leva o caminho rápido XDP e o zero-copy do Solana v4 para produção nos nós RPC e nos nós Geyser gRPC em todas as regiões — estendendo a prova de NY a cada região, elevando tanto a entrega de stream quanto a frescura do estado no RPC