RPC & WebSockets In Depth

Clientes Solana nunca se comunicam com o ledger como um banco de dados bruto; eles se comunicam com nós RPC que expõem JSON-RPC sobre HTTP e atualizações em tempo real sobre WebSockets.

Saldos de carteira, buscas de contas de programa, envios de transação, esperas de assinatura e (em muitos provedores) galerias de ativos digitais utilizam essa camada de acesso.

Esta página é o guarda-chuva da seção: HTTP vs. assinaturas, métodos baratos vs. caros, RPC principal vs. DAS, e como provedores, paginação e APIs de taxa/simulação completam uma stack de produção.

Resumo

• Solana RPC é a superfície da API voltada para o cluster: clientes usam HTTP JSON-RPC para leituras e submissão de transações, assinaturas WebSocket para atualizações push e (em provedores habilitados para DAS) métodos centrados em ativos sobre dados indexados da chain.
• Por que importa: Escolhas erradas de transporte, método ou commitment criam limites de taxa, UI desatualizada, estados de sucesso falsos e timeouts na mainnet; um mapa compartilhado de HTTP vs. WS, métodos baratos vs. caros, e RPC principal vs. DAS evita tratar cada chamada como gratuita e intercambiável.
• Conceitos-chave: JSON-RPC, commitment, HTTP RPC, assinatura WebSocket, getAccountInfo, getMultipleAccounts, getProgramAccounts (GPA), filtros, DAS, provedor, paginação, simulateTransaction, taxa de prioridade.
• Quando usar: Orientação inicial antes de conectar clientes @solana/kit; escolher entre polling e assinatura; planejar leituras de GPA na mainnet e portfólios NFT; selecionar recursos do provedor e caminhos de estimativa de taxa.
• Limitações/Trade-offs: RPC público tem limites de taxa restritos e sem SLA; DAS e APIs de taxa aprimoradas são recursos do provedor, não garantidos em todas as URLs; assinaturas WebSocket são visualizações locais do nó e ainda exigem disciplina de commitment; GPA não substitui um indexador real em escala.
• Tópicos relacionados: Noções básicas de RPC e commitment, métodos de leitura principais, filtros GPA, paginação, provedores e APIs de taxa de prioridade/simulação.

Fundamentos

RPC (Remote Procedure Call) é como os aplicativos observam e submetem trabalho em um cluster Solana.

Um nó RPC executa (ou atua como front-end para) software de validação como o Agave, serve JSON-RPC 2.0 via HTTPS e tipicamente expõe um endpoint WebSocket complementar para assinaturas.

Clientes não precisam executar um validador; eles precisam de uma URL RPC correta para o cluster desejado (mainnet-beta, devnet, testnet ou localnet).

As requisições são objetos JSON-RPC: nomes de method como getBalance ou sendTransaction, params opcionais e um id ecoado na resposta.

As respostas contêm um result ou um error com código e mensagem; o código da aplicação deve tratar HTTP 429, timeouts e erros JSON-RPC como modos de falha de primeira classe.

Commitment (processed, confirmed, finalized) é ortogonal à escolha do método: ele informa ao nó quão profundo no consenso uma leitura ou notificação deve estar antes de responder.

Ler em processed é rápido e sensível a forks; ler em finalized é mais lento e mais seguro para decisões de produto irreversíveis.

O caminho HTTP é de requisição/resposta: obtenha esta conta, envie esta transação, simule este payload, retorne uma vez.

O caminho WebSocket é de longa duração: assine uma vez, receba notificações push quando uma conta mudar, uma assinatura atingir o commitment, ou logs correspondentes aparecerem.

HTTP e WebSocket são duas faces do mesmo produto RPC, não dois ledgers; você ainda escolhe um cluster e uma política de commitment.

Métodos de leitura principais hidratam o estado da aplicação a partir de contas que o runtime já conhece por chave pública: saldos, dados de conta única e cargas de múltiplas contas em lote.

getProgramAccounts faz uma pergunta mais difícil: retorne todas as contas pertencentes a um programa (opcionalmente filtradas), o que força uma varredura do estado pertencente ao programa e é a fonte clássica de timeouts e limites de taxa na mainnet.

APIs DAS (Digital Asset Standard) estendem JSON-RPC com métodos centrados em ativos (getAsset, getAssetsByOwner, consultas de busca/grupo) apoiados por indexadores de provedor que unem programas de token, metadados e árvores de compressão em um único modelo.

DAS não é um recurso integrado obrigatório do Agave em toda URL pública; é uma capacidade do provedor que você habilita quando a experiência do usuário de NFT, cNFT e portfólio seria dolorosa apenas com buscas de token brutas.

Provedores (RPC gerenciado, DAS, webhooks, gRPC) e validadores auto-hospedados trocam o fardo operacional por controle; aplicações de produção deixam endpoints públicos gratuitos para trás.

Paginação e eficiência mantêm você dentro dos limites de RPS e payload: agrupe chaves públicas conhecidas, histórico de assinaturas com cursor, filtre GPA rigorosamente e mova a descoberta para indexadores quando os conjuntos crescem.

APIs de simulação e taxa de prioridade ficam no caminho de escrita: estime unidades de computação e micro-lamports por CU, e use simulateTransaction para expor erros de programa sem gastar taxas da mainnet em cada execução de teste.

Juntas, essas peças formam um mapa:

  Cliente (@solana/kit, carteira, worker de backend)
       |
       +-- HTTPS JSON-RPC --------> Borda RPC / provedor
       |     leituras, envio, simulação, taxas
       |
       +-- Assinaturas WSS -----> Mesma superfície do cluster
       |     conta / logs / assinatura / slot
       |
       +-- Métodos DAS (opcional) -> Provedor habilitado para DAS
             getAsset, getAssetsByOwner, searchAssets

Páginas irmãs nesta seção aprofundam cada ramo; esta página mantém o diagrama inteiro em vista.

Mecânica e Interações

Ciclo de vida da requisição HTTP

Uma leitura típica é um POST com Content-Type: application/json.

O nó resolve o método contra o snapshot do banco de dados no commitment solicitado, codifica os dados da conta (base64, base58 ou jsonParsed onde suportado) e retorna.

sendTransaction aceita uma transação serializada e assinada e retorna um identificador de assinatura; a durabilidade ainda requer polling ou uma assinatura WebSocket até que o commitment escolhido seja alcançado.

  App constrói + assina tx
       |
       v
  HTTP sendTransaction  -->  assinatura S
       |
       +-- poll getSignatureStatuses(S), ou
       +-- signatureSubscribe(S) via WSS
       |
       v
  Escada de commitment: processed -> confirmed -> finalized

Assinaturas WebSocket

O cliente abre wss://..., envia um método *Subscribe e recebe um ID de assinatura, seguido por mensagens *Notification.

Assinaturas comuns:

Notificações são visualizações push do nó ao qual você se conectou, não um barramento global ordenado entre todos os provedores.

Cancele a assinatura (ou aborte a assinatura do kit) quando os componentes forem desmontados para evitar vazamento de conexões.

Leituras baratas vs. descoberta cara

Sempre prefira leituras de chave pública conhecida quando um indexador, derivação de PDA ou resposta anterior já lhe forneceu os endereços.

Use GPA com filtros dataSize e memcmp apenas quando precisar descobrir contas por layout; nunca use GPA sem filtro na mainnet para programas grandes por padrão.

Quando GPA ainda não atender à escala do produto, mova a descoberta para pipelines do tipo Geyser/Yellowstone ou um indexador dedicado em vez de tentar a mesma varredura repetidamente.

DAS em relação ao RPC principal

RPC principal responde "qual é a conta neste endereço?"

DAS responde "quais ativos digitais este proprietário detém, e quais metadados/prova de compressão preciso para renderizar ou verificar?"

Use RPC principal (e kit) para contas de programa personalizadas, pagadores de taxa e submissão de transações.

Use DAS para galerias de NFT, consultas de coleção e ativos comprimidos onde o provedor já pagou o custo de indexação.

Provedores, limites e eficiência

Provedores gerenciados atuam como front-end para Agave (ou equivalente) com balanceadores de carga, chaves de API e sidecars opcionais (DAS, webhooks, estimativas de taxa aprimoradas).

URLs de cluster públicas existem para aprendizado e trabalho leve em devnet; elas limitam agressivamente e não são um plano de produção.

Regras de eficiência que se aplicam em todos os lugares:

• Divida getMultipleAccounts (frequentemente ~50-100 chaves por chamada, sujeito à documentação do provedor).
• Pagine getSignaturesForAddress com cursores before / until e um limit.
• Armazene em cache dados de conta imutáveis ou que mudam lentamente; atualize após uma assinatura ou após suas próprias escritas.
• Implemente backoff em caso de 429; faça failover para uma URL secundária quando os SLAs permitirem.

Simulação e taxas de prioridade

Antes de finalizar transações sensíveis, os clientes frequentemente:

1. Usam simulateTransaction com opções como sigVerify: false e replaceRecentBlockhash para ler unitsConsumed, logs e erros.
2. Amostram getRecentPrioritizationFees (e/ou APIs de percentil do provedor) para contas envolvidas no conjunto de bloqueio.
3. Anexam instruções de orçamento de computação com margem acima das CUs simuladas e um preço de CU em micro-lamports.

A simulação não é um substituto para a confirmação na mainnet; ela reduz falhas evitáveis e inclusão subprecificada.

Considerações Avançadas e Aplicações

Mapa conceitual da seção (o que cada página irmã cobre)

Assinaturas WebSocket e DAS têm páginas dedicadas de "como fazer" nesta seção; operacionalmente, elas ainda dependem da mesma URL do provedor e política de commitment descritas acima.

Projetando uma stack de cliente

Separe a configuração de HTTP RPC, WSS e DAS, mesmo quando um único fornecedor emite os três.

Fixe o commitment por classe de ação em um módulo em vez de espalhar literais de string.

Para produtos com muitas escritas, combine limites de CU orientados por simulação com taxas de prioridade dinâmicas e um caminho de confirmação que não trate o sucesso de sendTransaction como liquidação.

Quando abandonar o RPC puro

Alinhamento de ferramentas

@solana/kit 7.0.0 fornece createSolanaRpc para HTTP e createSolanaRpcSubscriptions para WSS em métodos padrão.

DAS frequentemente usa fetch direto ou um SDK do provedor até você o encapsular; mantenha as URLs base do DAS configuráveis ao lado das URLs RPC do kit.

A CLI (solana contra a mesma URL RPC) é útil para depurar os métodos idênticos que seu aplicativo chama.

Equívocos Comuns

• "Uma assinatura de transação de sendTransaction significa que a transferência é final." A assinatura é um identificador para polling de status ou signatureSubscribe; a durabilidade é o nível de commitment para o qual você espera depois.
• "HTTP e WebSocket são intercambiáveis para todos os casos de uso." HTTP é adequado para leituras e envios pontuais; WebSockets são adequados para atualizações contínuas, mas ambos ainda precisam de disciplina de commitment, autenticação e limpeza.
• "getProgramAccounts é apenas outra leitura como getAccountInfo." GPA pode varrer grandes conjuntos pertencentes a programas; sem filtros, é frequentemente a chamada RPC mais cara em seu aplicativo.
• "Métodos DAS funcionam em qualquer URL RPC Solana." DAS requer um endpoint de provedor habilitado para DAS; RPC público padrão retornará erro ou omitirá esses métodos.
• "Polling a cada 200ms é equivalente a uma assinatura." Polling agressivo consome limites de taxa e ainda atrasa; assinaturas reduzem o tráfego, mas não são eventos globais ordenados entre nós.
• "Taxas de prioridade e simulação garantem a inclusão." Elas melhoram a previsão e reduzem falhas evitáveis; líderes, congestionamento e expiração de blockhash ainda exigem lógica de retentativa e confirmação.

FAQs

Relacionados

• RPC Basics - formato JSON-RPC, níveis de commitment e limites de taxa
• Core RPC Methods - getAccountInfo, getBalance, getMultipleAccounts, visão geral do GPA
• getProgramAccounts & Filters - memcmp, dataSize e varreduras seguras de programa
• Pagination & Efficiency - agrupamento, cursores e evitando varreduras pesadas
• Priority Fee & Simulation APIs - amostras de taxa, simulateTransaction e margem de CU
• RPC Providers - provedores gerenciados, RPC público e trade-offs de auto-hospedagem

Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0.