RPC & WebSockets In Depth

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

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

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

Resumo

• Solana RPC é a superfície de API voltada ao cluster: clientes usam HTTP JSON-RPC para leituras e submissão de transações, assinaturas WebSocket para atualizações push, e (em provedores com DAS) métodos centrados em ativos sobre dados indexados da chain.
• Por que importa: Transporte, método ou escolhas de commitment erradas criam rate limits, UI obsoleta, estados de sucesso falsos e timeouts na mainnet; um mapa compartilhado de HTTP vs WS, métodos baratos vs caros e RPC core vs DAS evita tratar toda 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, priority fee.
• Quando usar: Primeira orientação antes de conectar clientes @solana/kit; escolher poll vs assinar; planejar leituras GPA mainnet e portfólio NFT; selecionar features de provedor e caminhos de estimativa de fee.
• Limitações / trade-offs: RPC público tem rate limits apertados e sem SLA; DAS e APIs enhanced de fee são features de provedor, não garantidas em toda URL; assinaturas WebSocket são visões locais do nó e ainda precisam disciplina de commitment; GPA não substitui indexer real em escala.
• Tópicos relacionados: Noções básicas de RPC e commitment, métodos de leitura core, filtros GPA, paginação, provedores e APIs de priority-fee/simulação.

Fundamentos

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

Um nó RPC roda (ou encaminha) software de validador como Agave, serve JSON-RPC 2.0 via HTTPS e tipicamente expõe endpoint WebSocket companheiro para assinaturas.

Clientes não precisam rodar validador; precisam de URL RPC correta para o cluster pretendido (mainnet-beta, devnet, testnet ou localnet).

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

Respostas trazem result ou error com código e mensagem; código de aplicação deve tratar HTTP 429, timeouts e erros JSON-RPC como modos de falha de primeira classe.

Commitment (processed, confirmed, finalized) é ortogonal à escolha de método: 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 fork; ler em finalized é mais lento e mais seguro para decisões irreversíveis de produto.

O caminho HTTP é request/response: busque esta conta, envie esta transação, simule este payload, retorne uma vez.

O caminho WebSocket é long-lived: assine uma vez, receba notificações push quando conta mudar, assinatura atingir 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 core hidratam estado de aplicativo a partir de contas que o runtime já conhece por pubkey: saldos, dados de conta única e cargas multi-conta em lote.

getProgramAccounts faz pergunta mais difícil: retorne toda conta owned por um programa (opcionalmente filtrada), o que força scan do estado owned pelo programa e é fonte clássica de timeouts e rate limits na mainnet.

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

DAS não é built-in Agave obrigatório em toda URL pública; é capacidade de provedor que você habilita quando UX de NFT, cNFT e portfólio seria dolorosa só com walks de token brutos.

Provedores (RPC gerenciado, DAS, webhooks, gRPC) e validadores self-hosted trocam carga ops por controle; apps de produção deixam endpoints públicos gratuitos para trás.

Paginação e eficiência mantêm você sob tetos de RPS e payload: agrupe pubkeys conhecidas, cursor histórico de assinaturas, filtre GPA com rigor e mova descoberta para indexers quando conjuntos crescem.

APIs de simulação e priority fee ficam no caminho de escrita: estime compute units e micro-lamports por CU, e use simulateTransaction para expor erros de programa sem gastar fees mainnet em todo dry run.

Juntos esses pedaços formam um mapa:

  Client (@solana/kit, wallet, backend worker)
       |
       +-- HTTPS JSON-RPC --------> RPC / provider edge
       |     reads, send, simulate, fees
       |
       +-- WSS subscriptions -----> same cluster surface
       |     account / logs / signature / slot
       |
       +-- DAS methods (optional) -> DAS-enabled provider
             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 de requisição HTTP

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

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

sendTransaction aceita transação serializada e assinada e retorna handle de assinatura; durabilidade ainda exige polling ou assinatura WebSocket até o commitment escolhido ser atingido.

  App builds + signs tx
       |
       v
  HTTP sendTransaction  -->  signature S
       |
       +-- poll getSignatureStatuses(S), or
       +-- signatureSubscribe(S) over WSS
       |
       v
  commitment ladder: processed -> confirmed -> finalized

Assinaturas WebSocket

O cliente abre wss://..., envia método *Subscribe e recebe id de assinatura mais mensagens *Notification depois.

Assinaturas comuns:

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

Cancele assinatura (ou abort a assinatura kit) quando componentes desmontam para conexões não vazarem.

Leituras baratas vs descoberta cara

Sempre prefira leituras de pubkey conhecida quando indexer, derivação PDA ou resposta anterior já deu endereços.

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

Quando GPA ainda não atende escala de produto, mova descoberta para pipelines Geyser/Yellowstone ou indexer dedicado em vez de retentar o mesmo scan.

DAS em relação ao RPC core

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

DAS responde "quais ativos digitais este owner mantém, e qual metadado/prova de compressão preciso para renderizar ou verificar?"

Use RPC core (e kit) para contas de programa customizadas, fee payers e submissão de transação.

Use DAS para galerias 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 encaminham Agave (ou equivalente) com load balancers, API keys e sidecars opcionais (DAS, webhooks, estimativas enhanced de fee).

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

Regras de eficiência que se aplicam em todo lugar:

• Divida getMultipleAccounts (frequentemente ~50-100 chaves por chamada, sujeito a docs do provedor).
• Paginate getSignaturesForAddress com cursores before / until e limit.
• Cache dados de conta imutáveis ou de mudança lenta; atualize em assinatura ou após suas próprias escritas.
• Faça backoff em 429; faça failover para URL secundária quando SLAs permitirem.

Simulação e priority fees

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

1. simulateTransaction com opções como sigVerify: false e replaceRecentBlockhash para ler unitsConsumed, logs e erros.
2. Amostram getRecentPrioritizationFees (e/ou APIs de fee percentil do provedor) para contas no conjunto de lock.
3. Anexam instruções de compute budget com margem sobre CUs simuladas e preço de CU em micro-lamports.

Simulação não substitui confirmação na mainnet; reduz falhas evitáveis e inclusão subprecificada.

Considerações avançadas e aplicações

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

Assinaturas WebSocket e DAS têm páginas how-to dedicadas nesta seção; operacionalmente ainda dependem da mesma URL de provedor e política de commitment descrita acima.

Projetando uma stack de cliente

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

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

Para produtos write-heavy, combine limites de CU orientados por simulação com priority fees dinâmicas e caminho de confirmação que não trate sucesso de sendTransaction como liquidação.

Quando sair de 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 SDK de provedor até você encapsular; mantenha URLs base DAS configuráveis ao lado de URLs RPC kit.

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

Equívocos comuns

• "Assinatura de transação de sendTransaction significa que a transferência é final." A assinatura é handle para polling de status ou signatureSubscribe; durabilidade é o nível de commitment que você espera depois.
• "HTTP e WebSocket são intercambiáveis para todo caso de uso." HTTP cabe em leituras e envios pontuais; WebSockets cabem em atualizações contínuas, mas ambos ainda precisam disciplina de commitment, auth e cleanup.
• "getProgramAccounts é só outra leitura como getAccountInfo." GPA pode escanear conjuntos grandes owned por programa; sem filtros é frequentemente a chamada RPC mais cara do seu app.
• "Métodos DAS funcionam em qualquer URL RPC Solana." DAS exige endpoint de provedor com DAS habilitado; RPC público vanilla errará ou omitirá esses métodos.
• "Polling a cada 200ms equivale a assinatura." Polling agressivo queima rate limits e ainda atrasa; assinaturas reduzem chatter mas não são eventos globais ordenados entre nós.
• "Priority fees e simulação garantem inclusão." Melhoram predição e reduzem falhas evitáveis; leaders, congestionamento e expiração de blockhash ainda exigem lógica de retry e confirmação.

FAQs

Relacionados

• RPC Basics - formato JSON-RPC, níveis de commitment e rate limits
• Core RPC Methods - getAccountInfo, getBalance, getMultipleAccounts, visão geral GPA
• getProgramAccounts & Filters - memcmp, dataSize e scans seguros de programa
• Pagination & Efficiency - loteamento, cursores e evitar scans pesados
• Priority Fee & Simulation APIs - amostras de fee, simulateTransaction e margem de CU
• RPC Providers - provedores gerenciados, RPC público e trade-offs de self-hosting

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.