FAQ - Solana Shreds

P. Minha saída de Shreds / getBlock de repente parece quebrada ou retorna -32015 — o que mudou?

A Solana Transaction v1 (SIMD-0385) entrou em vigor na mainnet da Solana em 15 de setembro de 2026, no epoch 1035. O layout wire de uma transação v1 começa com o byte de prefixo de versão 0x81, as assinaturas vêm depois da mensagem e não há mais o prefixo de comprimento legacy.

Se você decodifica por conta própria as entries do ShredStream ou do UDP Forwarding, um decodificador bincode ou solana-entry abaixo da versão 4.2 interpreta esse byte 0x81 como a quantidade de assinaturas, o que aparece como um erro de EOF, um overflow de compact-length ou um erro "invalid message version". Usuários do Geyser gRPC que desserializam transações raw com crates anteriores à 4.2 têm o mesmo problema. Chamadas RPC a getBlock e getTransaction com maxSupportedTransactionVersion: 0 retornam -32015 Transaction version (1) is not supported by the requesting client; getTransactionsForAddress no modo full reporta o mesmo erro em cada linha afetada. Você não é afetado se já lê as respostas JSON parseadas da ERPC com a versão 1 definida.

Defina maxSupportedTransactionVersion como 1 no objeto de opções — o segundo parâmetro de getBlock e getTransaction, e também nas opções de getTransactionsForAddress:

json

{
  "maxSupportedTransactionVersion": 1
}

{
  "maxSupportedTransactionVersion": 1
}

Atualize o Solana Stream SDK para 2.0.0: solana-stream-sdk em Rust no crates.io, ou @validators-dao/solana-stream-sdk e @validators-dao/solana-shreds-client no npm. Atualize @validators-dao/solana-entry-decoder separadamente para 2.5.0. 1.4.0 e entry-decoder 2.4.0 não suportam v1. Decodificadores Rust próprios deveriam migrar para solana-entry 4.2.x.

P. Em que regiões estão localizados os seus nós?

Atualmente operamos nós nas seguintes regiões:

Frankfurt (FRA)
Amsterdã (AMS)
Londres (LON)
Dublin (DUB)
Nova York (NY)
Chicago (CHI)
Salt Lake City (SLC)
Tóquio (TY)
Singapura (SGP)
Sydney (SYD)

O ERPC mede a latência real da rede com base em caminhos reais de roteamento, selecionando automaticamente a região com a menor latência ao invés de depender da distância reta. Esta abordagem não só melhora a latência para usuários individuais, mas também aumenta a eficiência geral da rede e fortalece a resiliência global do ERPC contra ataques potenciais.

Se o seu ambiente não selecionar automaticamente a região ideal, entre em contato conosco através do ERPC Web Dashboard.

ERPC Web Dashboard: https://dashboard.erpc.global/pt

P. A latência mostra 9999ms e uma região não ideal é selecionada. O que devo fazer?

Para a seleção da região de Shreds, a ERPC envia sondas de latência ICMP ao seu IP registrado a partir dos hosts proxy listados abaixo. Permita solicitações de eco ICMP de entrada de todos os IPs de origem listados. Se forem bloqueadas por um firewall (ufw, firewall na nuvem, grupo de segurança etc.), a medição poderá resultar em 9999ms e uma região não ideal poderá ser selecionada. Vários IPs em uma mesma região correspondem a hosts de sonda distintos; todos são necessários.

Região	IPs de origem ICMP
🇳🇱 Amsterdam	`82.21.43.35`
🇺🇸 New York	`151.243.244.162`
🇩🇪 Frankfurt	`151.241.178.73`
🇯🇵 Tokyo	`143.20.238.88`
🇸🇬 Singapore	`151.245.186.3`
🇬🇧 London	`151.241.65.10`

Far Point selecionado

O Far Point do Shared Shreds é uma opção de contingência com capacidade limitada. Cada endpoint oferece suporte a até 32 streams simultâneos por proxy no total, considerando todos os clientes—não são 32 vagas por cliente. O streaming é mais eficiente quando o assinante é executado perto do endpoint Shreds selecionado; streams de longa distância mantêm conexões compartilhadas, janelas de controle de fluxo e capacidade de saída ocupadas por mais tempo. Para ajudar a manter a capacidade de resposta do ambiente compartilhado, permita todos os endereços IP de origem das sondas ICMP regionais listadas e execute novamente a seleção de região. Para uso contínuo, considere um ERPC VPS próximo ao endpoint selecionado. O UDP Forwarding está disponível como Standard e como Premium. Em qualquer um dos dois, você escolhe a região do UDP Forwarding no ERPC Web Dashboard e recebe os Raw Shreds por UDP no endereço IPv4 público e na porta que configurar.

Usar um ERPC VPS próximo a este endpoint · Comparar as opções de UDP Forwarding Ler o guia de início rápido do Solana Shreds

P. Eu liberei meu IP, mas ainda não consigo conectar. O que devo verificar?

Use o endpoint HTTPS criptografado selecionado no Dashboard. HTTPS usa a porta 443; HTTP na porta 80 continua sendo a opção de baixa latência sem criptografia.

Ambos os transportes usam a mesma allowlist de IPs registrados. Use o endpoint selecionado no Dashboard: HTTPS na 443 ou HTTP na 80.

Endpoint HTTPS: use o endpoint selecionado no Dashboard na porta 443.
Endpoint HTTP: use o endpoint selecionado no Dashboard na porta 80.
Use a URL exibida no Dashboard com https:// ou http://.

A autenticação é baseada no seu endereço IP registrado. Não adicione headers x-token, token ou Authorization a menos que uma página de produto específica diga isso explicitamente.

P. Eu só usei WebSocket ou Geyser gRPC (YellowStone) antes. Tem amostras?

Sim. Você pode começar rapidamente a testar conexões Shreds e desenvolvimento de aplicativos usando SLV.

Consulte o seguinte guia para detalhes:

Guia de início rápido do Shreds

P. Posso registrar dois endereços IP?

Você pode usar um endpoint por assinatura. Se você deseja usar dois endereços IP, precisa contratar duas assinaturas separadas.

P. Qual região você recomenda?

Não existe uma única região que seja sempre a melhor. A Solana é global, e o papel de líder passa de um validador para outro conforme a agenda de líderes. Regiões com mais validadores e mais stake recebem leader slots com mais frequência, o que pode ajudar as transações a serem incluídas em bloco mais rapidamente. O trade-off é que o tráfego concorrente também se concentra lá, por isso uma região menos congestionada pode às vezes oferecer melhores resultados, dependendo da sua estratégia.

Como ponto de partida prático, escolha uma região com alta densidade de validadores, como Frankfurt ou a Costa Leste dos EUA, quando o mais importante for uma oferta estável de leader slots, ou posicione sua infraestrutura perto de um validador-alvo específico quando a prioridade for a execução pelo caminho mais curto. Use o Validators Solutions para entender a distribuição pública da rede Solana e, em seguida, use a ERPC Leader Slot API e medições reais para decidir se é mais adequada uma implantação em uma única região, em duas regiões ou global.

Relatório de distribuição da Solana Mainnet

P. Preciso de uma latência de ~400ms ou menos.

Para alcançar uma latência de aproximadamente 400ms ou menos, considere estes pontos essenciais:

Compreensão realista dos valores de ping: Os valores de ping indicam condições ideais e não refletem a latência real das comunicações de streaming, que normalmente fica em torno de 5 vezes a latência do ping. Por exemplo, um ping de 100ms entre continentes resulta, na prática, em cerca de 500ms de latência. Por isso, a infraestrutura precisa estar na mesma região para atingir uma latência de ~400ms.
- Valores de ping típicos (referência):
  - Mesma rede: ~0.1ms
  - Interconexão de rede privada (PNI): ~0.2ms
  - Mesmo data center: ~0.3ms
  - Mesma cidade: ~1ms
  - País vizinho: ~5–10ms
  - Intercontinental: ~100–300ms
A armadilha da latência média: Os validadores da Solana estão espalhados geograficamente pelo mundo, e a agenda de líderes muda aleatoriamente a cada época. Contar com a latência média para atingir ~400ms não é prático. Em vez disso, você deve acompanhar com precisão as agendas dos validadores na sua região específica para identificar os slots com a menor latência. Para obter a latência mínima de forma consistente, é necessária infraestrutura em todas as regiões relevantes. Dentro da mesma região, a aquisição de dados pode levar dezenas de milissegundos, e a transmissão, apenas alguns milissegundos.
Acompanhamento da agenda de líderes: Monitore a agenda dos validadores líderes da sua região usando a ERPC Leader Slot API (getLeaderSlots). Ela retorna a agenda dos próximos líderes, o stake weight da época atual, a geolocalização estimada dos validadores e valores de ping de referência, para que você possa identificar os slots de menor latência a ter como alvo antes que eles cheguem. Dados públicos em formato de mapa e APIs RPC nativas são úteis para uma visão ampla da rede, mas não são precisos o suficiente para o timing de execução. A Leader Slot API preenche essa lacuna com a granularidade necessária para decisões de roteamento e negociação.
- Documentação da ERPC Leader Slot API
- ERPC Web Dashboard

Validators Solutions - Dados da rede Solana

Dados da rede Solana: Validators Solutions

P. Como posso alcançar a negociação de bloco zero (zero-slot)?

Ter sucesso na negociação de bloco zero (zero-slot) exige estratégias mais sofisticadas, como as seguintes:

Identificação de zonas de oportunidade: Os validadores da Solana estão distribuídos pelo mundo, e é fisicamente impossível alcançar a latência ideal em todos os slots. Portanto, monitore a agenda de líderes dos validadores na região onde sua infraestrutura está localizada e identifique as zonas de oportunidade mais favoráveis. A implantação de infraestrutura em várias regiões também pode ser vantajosa. Por exemplo, Frankfurt é uma região-chave devido à sua alta densidade de validadores, o que resulta em uma seleção de líderes mais frequente e em mais oportunidades de negociação.

Use a ERPC Leader Slot API (getLeaderSlots) para consultar a agenda dos próximos líderes, o stake weight da época atual, dados estimados de geolocalização dos validadores e valores de ping de referência com uma precisão muito maior do que a das fontes públicas de dados em formato de mapa ou das APIs RPC nativas. Isso permite mapear as zonas de oportunidade antes que os slots cheguem e executar operações com latência quase zero.
- Documentação da ERPC Leader Slot API
- ERPC Web Dashboard
Implantação de nós dedicados: Se estiver tendo dificuldade para competir, considere implantar nós dedicados. Nós compartilhados sofrem latência devido ao tráfego de outros usuários e, por isso, não são recomendados. Além disso, colocar seu nó dedicado na mesma rede que sua aplicação reduz significativamente a latência de rede e otimiza o desempenho.

P. Posso usar um endpoint específico?

Para manter um ambiente de baixa latência, nosso sistema seleciona automaticamente o nó mais próximo disponível. Se você deseja usar um endpoint específico, recomendamos alugar um servidor localizado mais próximo desse endpoint.

P. Por que os endpoints dedicados são mais rápidos?

Endpoints compartilhados são usados por vários clientes que compartilham os mesmos recursos. À medida que o tráfego aumenta, tende a surgir latência. Os recursos do servidor têm limites físicos, e a quantidade de trabalho com que eles conseguem lidar é finita. Quando chegam requisições demais ao mesmo tempo, elas precisam ser processadas sequencialmente, o que resulta em tempos de resposta mais lentos.

Embora tomemos várias medidas para otimizar o desempenho mesmo em endpoints compartilhados, com endpoints dedicados você é o único usuário do recurso. Isso significa que você não é afetado de forma alguma por outros usuários, garantindo respostas consistentemente estáveis e rápidas.

Além disso, endpoints dedicados fornecem opções de comunicação sem TLS, como HTTP. Ao evitar o handshake TLS (cerca de 20ms), a comunicação torna-se ainda mais rápida em comparação com HTTPS.

P. Meu preço será aumentado depois que eu assinar?

Enquanto sua assinatura permanece ativa, o preço que você garantiu ao se inscrever permanece em vigor. Ambientes que se sustentam sob a carga de trabalho em tempo real da Solana são globalmente escassos, e planejamos aumentar os preços de acordo com o aumento da demanda de hardware e rede. Configurações de alto desempenho e regiões de alta demanda vendem mais rápido, por isso garantir o preço atual é a escolha mais econômica a longo prazo.

P. Eu quero pagar com cripto

Pagamentos em cripto estão disponíveis no ERPC Web Dashboard quando o país do seu endereço de faturamento registrado é um dos países membros da UE. Se todos os cartões de pagamento registrados na sua conta foram emitidos fora da UE, os pagamentos em cripto não estão disponíveis. Você pode usar SOL, USDC ou EURC para comprar ERPC Credits.

Use esses ERPC Credits para ativar ou continuar planos ERPC. Abra o dashboard, escolha pagamento em cripto, envie a transferência da sua wallet, e o dashboard verificará a transação e aplicará os créditos à sua conta.

Países compatíveis: Alemanha, Áustria, Bélgica, Bulgária, Chipre, Croácia, Dinamarca, Eslováquia, Eslovênia, Espanha, Estônia, Finlândia, França, Grécia, Hungria, Irlanda, Itália, Letônia, Lituânia, Luxemburgo, Malta, Países Baixos, Polônia, Portugal, Romênia, Suécia, Tchéquia.

Para países fora da lista, pague com cartão de crédito.

ERPC Web Dashboard

P. Por que o ShredStream não inclui todas as transações?

Por design, Shreds não incluem todas as transações no blockchain Solana. Monitorar todas as transações exigiria implantar inúmeros proxies globalmente e receber Shreds de cada validador, o que não é prático.

Normalmente, os usuários operam com um subconjunto dos dados disponíveis, uma vez que esta abordagem é suficiente para a maioria das aplicações do mundo real. Se o seu caso de uso exige cobertura completa de dados sem qualquer perda, Shreds pode não ser adequado.

Para cenários que exigem monitoramento mais abrangente, Geyser gRPC fornece maior confiabilidade em comparação com Shreds. No entanto, atingir 100% da cobertura de dados no blockchain Solana ainda requer a implantação de inúmeros servidores de borda, o que pode não ser realista na prática.

Geyser gRPC oferece confiabilidade superior a 99%, notavelmente maior que a do Shreds, um fato confirmado por muitos usuários, incluindo nós. O Shreds, no entanto, normalmente oferece mais de 90% de confiabilidade.

Embora eles não capturem cada transação, sua principal vantagem é a capacidade de recuperar rapidamente a maioria das transações mais rápido do que Geyser gRPC.

Para uma compreensão mais profunda, recomendamos explorar os protocolos Turbine e Gulf Stream da Solana:

P. Quero o melhor ambiente possível.

O UDP Forwarding está disponível como Standard e como Premium. Ambos chegam ao seu receptor a partir da região que você escolher. No Standard, a ERPC encaminha os Shreds a partir de um nó nessa região, de modo que eles chegam até você de um único IP de origem. No Premium, a rede mesh repassa, de cada Shred, a cópia que chega primeiro a ela. Em qualquer um dos dois, escolha sua região no ERPC Web Dashboard e defina o endereço IPv4 público e a porta que devem receber os Raw Shreds.

Entre em contato conosco através do ERPC Web Dashboard para mais detalhes.

ERPC Web Dashboard

🔗 ERPC Web Dashboard

P. Como é a latência?

A latência varia dependendo do método de medição e do seu ambiente de uso específico. Em vez de se concentrar em valores numéricos exatos, é crucial garantir que a latência atenda aos seus requisitos operacionais reais.

Fornecemos ferramentas fáceis de usar em TypeScript e Rust para medir a latência.

P. Este RPC (gRPC, Shreds) é mais rápido do que outros?

Projetamos todos os níveis de plano pensando em velocidade e teremos prazer em ver essa velocidade medida lado a lado com qualquer outro provedor. Os resultados podem variar conforme a região, o uso de um endpoint compartilhado ou dedicado, o protocolo (WebSockets, gRPC ou Shreds) e a linguagem de programação do seu cliente.

Se o nosso serviço parecer mais lento, informe-nos pelo ERPC Web Dashboard as condições específicas e os concorrentes com os quais você o comparou. Vamos identificar a causa e melhorar ainda mais a velocidade.

ERPC Web Dashboard

P. Qual plano oferece o desempenho mais rápido?

Geralmente, nosso plano de nível mais alto oferece o desempenho mais rápido devido a CPUs superiores, capacidades de memória mais elevadas e configurações de hardware robustas.

Nós também oferecemos soluções personalizadas se você precisar de servidores ainda mais poderosos, mas nossos planos padrão são projetados para oferecer uma relação preço-desempenho ideal.

Estamos confiantes em fornecer desempenho de nível mundial em todas as faixas de preço. Se você encontrar um provedor mais rápido dentro da mesma faixa de preços, por favor, avise-nos para que possamos investigar e fazer melhorias.

P. Estou com latência alta. Por quê?

A latência aumenta significativamente com a distância do endpoint. Recomendamos o acesso de um servidor localizado mais próximo do endpoint fornecido. Os ambientes mais rápidos estão disponíveis através dos nossos servidores Bare-Metal e serviços VPS.

P. Qual é o mais rápido: WebSockets, gRPC ou Shreds?

Com base no feedback do cliente, a ordem de desempenho é:

Shreds > gRPC > WebSockets

Se a sua experiência difere, por favor informe-nos.

P. A latência não é o que eu esperava.

O desempenho varia significativamente dependendo da linguagem de programação utilizada. Geralmente, a ordem de desempenho é:

Rust > Go > TypeScript (JavaScript) > Python

Para comparações detalhadas, consultar:

Comparação da Velocidade da Linguagem de Programação

Recomendamos fortemente Rust para o máximo desempenho.