ERPC

FAQ - Geyser gRPC Stream

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)
  • Nova York (NY)
  • 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 gRPC, 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ãoIPs de origem ICMP
🇳🇱 Amsterdam82.21.43.34, 151.244.92.36
🇺🇸 New York151.243.244.5
🇩🇪 Frankfurt151.241.178.20, 151.241.178.34, 151.241.178.21
🇬🇧 London151.241.65.4
🇯🇵 Tokyo143.20.238.66
🇸🇬 Singapore151.245.186.2
🛰️ Far Point143.20.238.73

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 antes. Posso usar gRPC? Tem amostras?

Sim. Você pode rapidamente testar e começar a desenvolver com gRPC usando SLV.
Para um endpoint compartilhado que você pode testar sem um token, execute:
bash
slv check grpc --endpoint <YOUR_ENDPOINT> --token none
Confira o nosso Guia de início rápido do gRPC para mais detalhes.

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. Existem limites de filtro?

O Geyser gRPC Shared tem proteções de uso justo para que um stream não consuma os recursos necessários a outros clientes ERPC. Pela regra atual de Shared, todo mapa blocks não vazio é rejeitado, inclusive uma solicitação de blocos limitada. Cada filtro de conta deve incluir account, owner ou um filtro cuckoo compatível; memcmp ou dataSize isoladamente não bastam.
Remova uma forma rejeitada e assine apenas os dados de que sua aplicação precisa. Uma assinatura de transações ou metadados de blocos pode atender à necessidade sem transportar um bloco completo. O Geyser gRPC Dedicated é adequado quando uma carga legítima excede a margem de forma ou recursos de Shared; ele não torna válidos parâmetros inválidos nem corrige um cliente lento.

P. Como coleto um erro gRPC antes de reconectar?

Guarde o primeiro erro antes que um loop de reconexão o substitua. Registre o status e a mensagem gRPC dos metadados iniciais e trailers, junto com x-erpc-error-code, x-erpc-error-reason e x-erpc-doc-url. Quando a ERPC fornecer uma pausa, registre também x-erpc-retry-after-seconds e x-erpc-retry-at (segundos Unix).
Um erro pode aparecer como ERPC [STREAM_GUARD_SLOW_READER]: .... Cole o erro exibido ou o código na busca de FAQ. A explicação canônica está nas FAQ gRPC da ERPC. Não suponha que um trailer será entregue quando uma conexão termina cedo.
Você também pode buscar por um sintoma: receptor lento, desconectado, largura de banda, atraso de entrega, backlog, pausa, tentativa novamente, argumento inválido, recurso esgotado, permissão negada, registro de IP, muitos streams, blocos completos ou todas as contas.

P. Quais erros gRPC pausam minha conexão e quando meu cliente deve parar de reconectar?

Uma pausa é um período temporizado que a ERPC aplica após certos erros. O cliente não deve reconectar enquanto ela estiver em andamento.
O que é contabilizado. Estes erros são contabilizados e compartilham uma única sequência de degraus:
  • Toda solicitação Subscribe que a ERPC rejeita com ERPC_GRPC_INVALID_ARGUMENT, STREAM_GUARD_SHAPE_BLOCKS ou STREAM_GUARD_SHAPE_ACCOUNTS_ALL, incluindo a primeira. O primeiro erro contabilizado é o aviso, que não inicia nenhuma pausa.
  • STREAM_GUARD_SLOW_READER. No entanto, se o atraso de entrega surgir do lado da ERPC, a ERPC fecha o stream sem contabilizá-lo, e o erro não traz prazo de retry.
Não são contabilizados: a reconexão em si, os quatro códigos STREAM_ADMISSION_* (STREAM_ADMISSION_LIMIT_REACHED, STREAM_ADMISSION_IP_NOT_ADMITTED, STREAM_ADMISSION_SOURCE_UNAVAILABLE e STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE) e qualquer erro contabilizado que ocorra enquanto uma pausa estiver em andamento. Um erro contabilizado durante uma pausa não prolonga a pausa e não passa para o próximo degrau.
Os degraus. Cada erro contabilizado avança um degrau nesta ordem, começando pelo aviso:
  • Aviso: sem pausa.
  • Pausa de 60 segundos.
  • Pausa de 300 segundos.
  • Pausa de 1800 segundos.
  • Pausa de 86400 segundos (24 horas). Este é o último degrau: nele, cada erro contabilizado inicia outra pausa de 86400 segundos.
No degrau de aviso, o próximo erro contabilizado só passa para a pausa de 60 segundos quando chega em até 1 hora após o aviso. Um erro contabilizado que chega mais de 1 hora depois do aviso é outro aviso, sem pausa, e a janela de 1 hora passa então a correr a partir desse novo aviso.
Um erro contabilizado que chega menos de 60 segundos depois do último erro que foi contabilizado é contabilizado como parte desse erro e não avança nenhum degrau.
Quando os degraus voltam ao aviso. Depois que os degraus tiverem iniciado uma pausa, eles só voltam ao aviso após 24 horas sem nenhum erro contabilizado e sem nenhuma pausa, medidas a partir do fim da última pausa; o próximo erro contabilizado depois disso é um aviso sem pausa. Até lá, o próximo erro contabilizado inicia imediatamente o próximo degrau, sem aviso.
A pausa de egress. STREAM_GUARD_EGRESS_BUDGET inicia sua própria pausa fixa de 600 segundos. Ela não faz avançar os degraus.
Onde está o horário de término.
  • O erro que inicia uma pausa traz Retry after N seconds. e os headers x-erpc-retry-after-seconds e x-erpc-retry-at (segundos Unix). O aviso não traz prazo de retry.
  • Quando uma solicitação rejeitada contabilizada é a que inicia uma pausa, ela é devolvida como STREAM_GUARD_SHAPE_REJECT_PENALTY com ResourceExhausted (8) em vez do próprio código.
  • Durante uma pausa por leitor lento ou egress, uma reconexão recebe STREAM_GUARD_PENALTY_ACTIVE com o tempo restante.
  • Durante uma pausa iniciada por uma solicitação rejeitada, uma nova conexão é fechada imediatamente, sem status gRPC e sem código da ERPC. Uma solicitação em uma conexão que ainda está aberta pode receber de novo como resposta STREAM_GUARD_SHAPE_REJECT_PENALTY com o tempo restante antes que essa conexão seja fechada. O cliente pode nunca mais ver o horário de término, por isso deve salvar x-erpc-retry-at do primeiro erro que o trouxer.
CódigoStatus gRPCInicia ou faz avançar uma pausa?O que o cliente deve fazer
ERPC_GRPC_INVALID_ARGUMENTInvalidArgument (3)Sim, quando rejeita uma solicitação Subscribe. Nesse caso, é um erro contabilizado conforme os degraus acima.Pare o loop e não reenvie a mesma solicitação. A entrada específica deste código, mais abaixo, indica o que verificar.
STREAM_GUARD_SHAPE_BLOCKSPermissionDenied (7)Sim. É um erro contabilizado conforme os degraus acima.Pare o loop e não reenvie a mesma solicitação. A entrada específica deste código, mais abaixo, indica o que verificar.
STREAM_GUARD_SHAPE_ACCOUNTS_ALLPermissionDenied (7)Sim. É um erro contabilizado conforme os degraus acima.Pare o loop e não reenvie a mesma solicitação. A entrada específica deste código, mais abaixo, indica o que verificar.
STREAM_GUARD_SLOW_READERResourceExhausted (8)Sim. É um erro contabilizado conforme os degraus acima. No entanto, se o atraso de entrega surgir do lado da ERPC, a ERPC fecha o stream sem contabilizá-lo, e o erro não traz prazo de retry.Pare o loop. A entrada específica deste código, mais abaixo, indica o que verificar. Se ele iniciou uma pausa, não reconecte antes do horário indicado em x-erpc-retry-at.
STREAM_GUARD_EGRESS_BUDGETResourceExhausted (8)Sim. Inicia uma pausa fixa de 600 segundos fora dos degraus acima.Não reconecte antes do horário indicado em x-erpc-retry-at. A entrada específica deste código, mais abaixo, indica o que verificar.
STREAM_GUARD_SHAPE_REJECT_PENALTYResourceExhausted (8)Sim. É a solicitação rejeitada contabilizada que iniciou uma pausa. Pode chegar de novo com o tempo restante em uma conexão que ainda está aberta.Não reconecte antes do horário indicado em x-erpc-retry-at. Corrija a solicitação rejeitada e não a reenvie sem alterações.
STREAM_GUARD_PENALTY_ACTIVEResourceExhausted (8)Não. Informa uma pausa por leitor lento ou egress que já está em andamento.Não reconecte antes do horário indicado em x-erpc-retry-at.
STREAM_ADMISSION_LIMIT_REACHEDResourceExhausted (8)Não. Não tem pausa temporizada.Feche os streams não usados e depois tente novamente.
STREAM_ADMISSION_IP_NOT_ADMITTEDPermissionDenied (7)Não. Não tem pausa temporizada.A entrada específica deste código, mais abaixo, indica o que verificar.
STREAM_ADMISSION_SOURCE_UNAVAILABLEUnavailable (14)Não. Não tem pausa temporizada.Aplique backoff normalmente e tente de novo após um intervalo.
STREAM_ADMISSION_SNAPSHOT_UNAVAILABLEUnavailable (14)Não. Não tem pausa temporizada.Aplique backoff normalmente e tente de novo após um intervalo.
O que o cliente deve fazer. Diante de um erro contabilizado, pare o loop, não reenvie a mesma solicitação e corrija-a. Durante uma pausa, não reconecte antes do horário indicado em x-erpc-retry-at. Solicitações Subscribe rejeitadas são contabilizadas pelas regras acima, e a reconexão não.

P. O que significa STREAM_GUARD_SLOW_READER com ResourceExhausted (8) quando um receptor lento é desconectado?

A ERPC observou pouco progresso de escrita ou atraso de entrega neste stream. O atraso de entrega por si só não identifica a causa. Verifique perda de rede, largura de banda efetiva, capacidade do host e se o consumidor da aplicação acompanha o fluxo. Reduza os dados assinados e mova o processamento para fora do loop de recepção, para uma fila limitada. Uma fila limitada controla o uso de memória, mas não resolve um consumidor persistentemente lento. Se a ERPC fornecer um prazo de retry, aguarde-o antes de reconectar. A pergunta “Por que meu stream gRPC fica preso numa velocidade fixa e vai ficando para trás?” abaixo explica a janela de recepção e como ampliá-la na biblioteca do seu cliente.

P. Por que meu stream gRPC fica preso numa velocidade fixa e vai ficando para trás?

Uma janela de recepção pequena no seu cliente, ou em algo entre ele e a ERPC, pode causar encerramentos com STREAM_GUARD_SLOW_READER e as pausas que vêm depois deles. Esta resposta explica o que é uma janela de recepção, como saber se ela limita o seu stream e como ampliá-la em cada biblioteca. A pergunta “Quais erros gRPC pausam minha conexão e quando meu cliente deve parar de reconectar?” acima apresenta os degraus e suas durações.
O que é uma janela de recepção. No HTTP/2, o receptor informa ao remetente quantos dados podem ser enviados antes que o receptor confirme o recebimento; essa quantidade é a janela de recepção (a janela de controle de fluxo do HTTP/2). Uma ida e volta transporta no máximo uma janela, então a velocidade máxima fica perto do tamanho da janela dividido pelo tempo de ida e volta (o trajeto até o endpoint e de volta).
Os outros limites. Há duas janelas, uma por stream e uma por conexão (todos os streams de uma conexão a compartilham), e a menor delas define o limite. Na especificação do HTTP/2, as duas janelas começam em 65535 bytes. O buffer de recepção do TCP (memória para os dados que chegam) limita a velocidade da mesma forma. Um proxy, load balancer, gateway, VPN ou sidecar no caminho tem suas próprias janelas e buffers. Uma janela ou um buffer pequeno ali limita o stream mesmo quando as janelas do seu próprio cliente são grandes.
Como isso aparece. Um stream se estabiliza em quase a mesma velocidade, não importa o quanto a chain esteja movimentada, e o atraso de entrega dele cresce de forma constante. A ERPC mediu a partir de um local com tempo de ida e volta de cerca de 6 ms até o endpoint compartilhado de Frankfurt, mudando apenas a janela entre as execuções:
  • Janela de stream de 16 KiB: estável perto de 2.7 MB/s (16 KiB divididos por 6 ms); o atraso de entrega cresceu cerca de 0.6 segundo por segundo e chegou a 26 segundos em 45 segundos.
  • As duas janelas com 16 MiB: o atraso de entrega máximo foi de 14 ms.
Se o atraso de entrega surgir do lado da ERPC, a ERPC fecha o stream sem contabilizá-lo, e o erro não traz prazo de retry.
Verifique.
  1. Compare a velocidade e o atraso de entrega do stream com o padrão acima.
  2. Meça o tempo de ida e volta. Multiplique a velocidade do stream pelo tempo de ida e volta para estimar a janela (2.7 MB/s vezes 6 ms dá cerca de 16 KB).
  3. Verifique se alguma das duas janelas do seu cliente tem um valor pequeno ou se o crescimento automático (a biblioteca ampliando a janela sozinha) está desligado.
  4. Verifique o buffer de recepção do TCP. No Linux, execute sysctl net.ipv4.tcp_rmem net.core.rmem_max e veja se a sua aplicação define SO_RCVBUF, o que desliga o dimensionamento automático.
  5. Verifique as janelas e os buffers de tudo o que estiver no caminho.
  6. Se a velocidade não tem teto e só o atraso cresce, o processamento depois do recebimento está lento. A pergunta “O que significa STREAM_GUARD_SLOW_READER com ResourceExhausted (8) quando um receptor lento é desconectado?” acima explica como deixar o loop de recepção apenas lendo e mover o trabalho pesado para uma fila limitada.
Configurações por biblioteca. Os exemplos definem as duas janelas em 16 MiB, como na medição da ERPC. Para uma biblioteca que não está na lista, procure as configurações de janela inicial do HTTP/2.
Rust, yellowstone-grpc-client. Sem configurações de janela, GeyserGrpcClient::build_from_shared usa 2 MiB por stream e 5 MiB por conexão. Com 6 ms de ida e volta, esses padrões permitem mais de 300 MB/s, então não limitam o stream. Para definir as janelas você mesmo, use os dois métodos do builder e mantenha http2_adaptive_window desligado. Com ele ligado, a janela começa em 65535 bytes e cresce sozinha até 16 MiB, ignorando os seus valores.
rust
// As duas janelas fixas em 16 MiB; mantenha http2_adaptive_window desligado.
let client = GeyserGrpcClient::build_from_shared(endpoint)?
    .tls_config(ClientTlsConfig::new().with_native_roots())?
    .initial_stream_window_size(16 * 1024 * 1024)
    .initial_connection_window_size(16 * 1024 * 1024)
    .connect()
    .await?;
TypeScript, @triton-one/yellowstone-grpc 5.0.1 ou posterior. Padrões: 4 MiB por stream, 8 MiB por conexão, crescimento automático ligado. A janela começa em 64 KiB e cresce até 16 MiB, então os padrões raramente limitam o stream. Para fixar os tamanhos, passe o terceiro argumento com grpcHttp2AdaptiveWindow: false.
typescript
// Janela adaptativa desligada, para que estes tamanhos fixos sejam usados.
const client = new Client(endpoint, undefined, {
  grpcInitialStreamWindowSize: 16 * 1024 * 1024,
  grpcInitialConnectionWindowSize: 16 * 1024 * 1024,
  grpcHttp2AdaptiveWindow: false,
})
TypeScript, @triton-one/yellowstone-grpc 5.0.0 ou anterior. Essas versões usam @grpc/grpc-js, cuja janela padrão é de 65535 bytes: cerca de 11 MB/s com 6 ms e cerca de 0.66 MB/s com 100 ms. A partir da versão 1.14, o @grpc/grpc-js aplica 'grpc-node.flow_control_window' às duas janelas; a versão 1.13 só o aplica à janela de stream, então a janela de conexão continua em 65535 bytes (cerca de 11 MB/s com 6 ms). Com uma versão do @grpc/grpc-js anterior à 1.14, é mais rápido atualizar para @triton-one/yellowstone-grpc 5.0.1 ou posterior.
typescript
// Requer @grpc/grpc-js 1.14 ou posterior para ampliar as duas janelas.
const client = new Client(endpoint, undefined, {
  'grpc-node.flow_control_window': 16 * 1024 * 1024,
})
Go, google.golang.org/grpc. Por padrão, a biblioteca amplia as janelas sozinha, até 16 MiB. grpc.WithInitialWindowSize e grpc.WithInitialConnWindowSize as fixam e desligam o crescimento automático; valores abaixo de 64 KiB são ignorados. Defina as duas: só uma deixa a outra em 64 KiB.
go
// Defina as duas; isso também desliga o crescimento automático da janela.
conn, err := grpc.NewClient(target,
	grpc.WithTransportCredentials(creds),
	grpc.WithInitialWindowSize(16<<20),
	grpc.WithInitialConnWindowSize(16<<20),
)
Python, grpcio. grpc.http2.bdp_probe vem ligado por padrão, então as janelas crescem sozinhas; se o seu código passa ("grpc.http2.bdp_probe", 0), remova isso. grpc.http2.lookahead_bytes define a leitura antecipada por stream (padrão de 64 KB); valores maiores podem ajudar em uma ida e volta longa.
python
# Se as suas options incluem ("grpc.http2.bdp_probe", 0), remova-o.
channel = grpc.secure_channel(target, creds, options=[
    ("grpc.http2.lookahead_bytes", 16 * 1024 * 1024),
])
Receba mais perto. Uma ida e volta mais curta permite que a mesma janela entregue mais, e o serviço VPS e os servidores Bare-Metal da ERPC colocam o cliente perto do endpoint.
Divida com cuidado. O Standard permite 10 streams e o Premium 50, por IP de origem registrado. Cada stream tem a sua própria janela de stream, mas os streams de uma mesma conexão compartilham uma única janela de conexão, então uma janela de conexão pequena continua limitando a velocidade. Ao substituir um stream, feche o antigo primeiro: streams abertos contam para o limite, e ultrapassá-lo retorna STREAM_ADMISSION_LIMIT_REACHED (a pergunta específica dele está abaixo). Dividir não acelera um processamento lento.

P. O que significa STREAM_GUARD_EGRESS_BUDGET com ResourceExhausted (8)?

O tráfego agregado do IP excedeu a margem Shared, por isso streams relacionados podem fechar juntos. Reduza o volume de dados e streams paralelos desnecessários e aguarde o prazo retornado. Esta pausa de egress dura 600 segundos e não avança a escala de penalidades, embora uma pausa mais longa já existente possa continuar valendo.

P. O que significa STREAM_GUARD_PENALTY_ACTIVE com ResourceExhausted (8)?

Uma pausa anterior por leitor lento ou egress continua ativa, e esta resposta traz o tempo restante. Guarde o primeiro erro da ERPC, corrija a causa e não reconecte antes de x-erpc-retry-at; não reconecte antes para testar. As tentativas de reconexão não são contabilizadas. A pergunta “Quais erros gRPC pausam minha conexão e quando meu cliente deve parar de reconectar?” acima apresenta os degraus e suas durações.

P. O que significa STREAM_GUARD_SHAPE_BLOCKS com PermissionDenied (7)?

A regra atual de Shared rejeita todo mapa blocks não vazio, mesmo com uma solicitação limitada. Remova o mapa blocks. Use transações e/ou metadados de blocos quando atenderem à necessidade; nenhum deles equivale a um bloco completo. Para blocos completos, é necessário Geyser gRPC Dedicated; isso não implica que exista um plano de blocos seletivos em Shared.

P. O que significa STREAM_GUARD_SHAPE_ACCOUNTS_ALL com PermissionDenied (7)?

Uma entrada de filtro de conta deve selecionar dados com account, owner ou um filtro cuckoo compatível. memcmp e dataSize isoladamente não são suficientes. Restrinja a solicitação de conta a uma dessas formas compatíveis ou use Geyser gRPC Dedicated quando um stream completo de contas for necessário.

P. O que significa STREAM_GUARD_SHAPE_REJECT_PENALTY com ResourceExhausted (8)?

Este código é devolvido em vez de ERPC_GRPC_INVALID_ARGUMENT, STREAM_GUARD_SHAPE_BLOCKS ou STREAM_GUARD_SHAPE_ACCOUNTS_ALL quando essa solicitação rejeitada contabilizada é a que inicia uma pausa; a pergunta “Quais erros gRPC pausam minha conexão e quando meu cliente deve parar de reconectar?” acima explica quando isso acontece. Ele traz Retry after N seconds., x-erpc-retry-after-seconds e x-erpc-retry-at. Durante esta pausa, novas conexões são fechadas imediatamente, sem status gRPC e sem código da ERPC, por isso o cliente pode nunca mais ver o horário de término. Salve x-erpc-retry-at do primeiro erro que o trouxer. Solicitações Subscribe rejeitadas são contabilizadas pelas regras acima, e a reconexão não. Corrija a solicitação e não a reenvie sem alterações. Um encerramento precoce pode parecer um erro de transporte; por isso, guarde o primeiro erro da ERPC antes que o loop de reconexão o esconda.

P. O que significa STREAM_ADMISSION_LIMIT_REACHED com ResourceExhausted (8)?

A capacidade de admissão está cheia no momento. Feche streams não usados ou duplicados, verifique a margem da conexão e tente novamente quando houver capacidade. Esta resposta, sozinha, não significa que exista uma penalidade temporizada ativa.

P. O que significa STREAM_ADMISSION_IP_NOT_ADMITTED com PermissionDenied (7)?

A ERPC não pôde admitir a conexão, inclusive após expirar um período de carência de registro de IP. Compare o IP de saída real com o IP registrado e confirme o estado de acesso atual. Aguarde a propagação de uma alteração de registro sem assumir um prazo fixo e contate o suporte se a condição persistir.

P. O que significa STREAM_ADMISSION_SOURCE_UNAVAILABLE com Unavailable (14)?

A ERPC não pôde determinar a origem desta conexão naquele momento. Aplique backoff e tente de novo depois. Se persistir, contate o suporte com o primeiro erro e seus metadados; a resposta não comprova uma falha na rede ou no servidor do cliente.

P. O que significa STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE com Unavailable (14)?

A ERPC não pôde verificar o acesso naquele momento. Aplique backoff e tente de novo depois; contate o suporte se continuar. Registrar de novo repetidamente, ampliar filtros ou comprar Geyser gRPC Dedicated não corrige esta resposta de disponibilidade.

P. O que significa ERPC_GRPC_INVALID_ARGUMENT com InvalidArgument (3)?

A solicitação contém parâmetros, opções, tipos de campo, chaves ou combinações de filtro inválidos. Corrija a solicitação antes de tentar novamente e não reenvie a mesma solicitação. Cada solicitação Subscribe rejeitada com este código é um erro contabilizado pelas regras de pausa da pergunta “Quais erros gRPC pausam minha conexão e quando meu cliente deve parar de reconectar?” acima, regras compartilhadas com STREAM_GUARD_SHAPE_BLOCKS, STREAM_GUARD_SHAPE_ACCOUNTS_ALL e STREAM_GUARD_SLOW_READER. Quando uma dessas solicitações inicia uma pausa, ela é devolvida como STREAM_GUARD_SHAPE_REJECT_PENALTY com ResourceExhausted (8). Geyser gRPC Dedicated não torna válidos parâmetros inválidos.
A mensagem de erro termina o código com (reason: <token>), e o mesmo token é devolvido no header de resposta x-erpc-error-reason. Procure o token abaixo para ver o que alterar. Quando um limite se aplica, a mensagem de erro o informa.
ReasonO que significaO que alterar
too_many_filtersA requisição traz mais filtros nomeados ou data slices do que uma requisição admite.Use menos filtros nomeados (ou data slices) deste tipo por requisição.
empty_filterUm filtro não tem nenhum endereço, e um filtro vazio significa tudo.Dê a cada filtro pelo menos um endereço (accounts: uma conta ou um owner; transações: uma lista de contas). O Shared gRPC não atende um filtro vazio.
too_many_addressesUm campo de filtro lista endereços demais.Use menos endereços em um campo de filtro; divida-os entre filtros ou reduza a lista.
address_not_allowedUm filtro cita um endereço que o Shared gRPC não permite.Remova do filtro esse endereço de alto volume.
filter_name_too_longO nome de um filtro é longo demais.Use nomes de filtro mais curtos (as chaves do map).
invalid_commitmentO nível de commitment não é válido.Use processed, confirmed ou finalized.
invalid_addressUm filtro contém um endereço inválido.Cada endereço deve ser um endereço Solana base58 válido (sem strings vazias, espaços ou tamanho errado).
invalid_signatureO valor da assinatura da transação não é válido.Use uma assinatura de transação base58 válida.
invalid_account_data_filterUm filtro de dados de accounts não é válido.Corrija os filtros memcmp, datasize e de dados de token accounts, e mantenha o número deles dentro do limite informado na mensagem.
invalid_data_sliceOs data slices não são válidos.Ordene os data slices por offset e evite sobreposição.
blocks_include_not_allowedAs opções da assinatura blocks não estão disponíveis no Shared gRPC.Omita blocks e use no lugar uma assinatura de transações ou de blocks_meta.
invalid_token_accounts_modeO modo de token accounts não é válido.Use ALL (0) ou BALANCE_CHANGED (1).
invalid_argumentNenhum dos motivos acima se aplica.Verifique o filtro e os parâmetros da requisição antes de tentar novamente.

P. O que significa ERPC_GRPC_REQUEST_FAILED quando o gRPC retorna outro status diferente de zero?

A solicitação falhou com um status gRPC válido que determina a próxima etapa. Corrija uma solicitação com OutOfRange (11) quando um intervalo histórico for inválido; aplique backoff para um status de disponibilidade como Unavailable (14). Não classifique todo status diferente de zero como transitório nem tente novamente cada resposta sem alterações.

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.
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.
  • 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. Estou recebendo um erro 401. Por quê?

Para manter um ambiente de baixa latência, implementamos restrições de IP. Se você não tiver uma assinatura ou seu IP não estiver registrado, você receberá um erro 401.
Verifique se o IP registrado corresponde ao IP de acesso atual.

P. Estou recebendo um erro 429. Por quê?

Você atingiu o limite de conexão do seu plano.
Se você encontrar este erro, considere atualizar seu plano. Se você precisar de mais conexões do que o nosso plano premium fornece, um nó gRPC dedicado seria mais adequado.

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. Como posso alcançar a menor latência possível?

Recomendamos fortemente combinar um nó gRPC dedicado com o nosso servidor Bare-Metal.
Ambos compartilham a mesma rede, permitindo uma comunicação privada, de distância zero, sem atravessar a Internet. Esta configuração atinge latência extremamente baixa, normalmente com ping em torno de 0.1ms.
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. O que posso fazer?

A latência depende fortemente da sua proximidade com o endpoint. Recomendamos o acesso de um servidor próximo ao endpoint fornecido. As conexões mais rápidas são alcançadas com o nosso servidor Bare-Metal e o nosso serviço VPS.

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

O feedback de nossos clientes consistentemente classifica velocidade como segue:
Shreds > gRPC > WebSockets
Por favor, compartilhe sua experiência se você observar resultados diferentes.

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

O desempenho varia dependendo da linguagem de programação utilizada. Em geral, a ordem de velocidade das linguagens é:
Rust > Go > TypeScript (JavaScript) > Python
Para comparações detalhadas, ver:
Comparação da Velocidade da Linguagem de Programação
Para o máximo desempenho, recomendamos fortemente usar Rust.
AnteriorExemplos de códigoPróximoSolana Shreds / gRPC / Início rápido