Nós RPC da Solana: Configuração, Provedores e Melhores Práticas

Os nós RPC da Solana fornecem as interfaces de leitura, submissão e subscrição que as aplicações utilizam para comunicar com a rede. Funcionalidades dos provedores, limites, preços, requisitos de hardware e métricas de desempenho mudam ao longo do tempo, pelo que as decisões de produção devem ser verificadas contra a documentação atual e testes de carga de trabalho.

Última Atualização: Julho de 2025

Os Endpoints públicos da Solana podem ser úteis para desenvolvimento, mas não são uma garantia universal de serviço de produção. Se uma dApp retornar erros 429, travar em consultas de conta ou tiver problemas de submissão sob carga, o seu caminho RPC é um componente a investigar juntamente com a construção de transações, taxas, Vencimento, rede e condições do cluster.

Este guia abrange o que é um nó RPC da Solana, como difere de um nó validador, como os pedidos fluem através do sistema, onde obter URLs de Endpoints públicos, quais os métodos RPC que mais importam, como conectar via @solana/web3.js, quais os provedores geridos a avaliar, o que realmente requer a auto-hospedagem e como corrigir os erros de limite de taxa que provavelmente já está a ver.

Resumo: Para desenvolvimento, utilize os Endpoints públicos gratuitos da Solana Foundation. Para produção, utilize um provedor gerido como Helius, QuickNode, Alchemy ou Triton One. A auto-hospedagem oferece mais controlo operacional, mas ainda requer planeamento de capacidade, políticas de acesso, monitorização e orientação de hardware atual.

Saltar para:

• O que são nós RPC da Solana?
• Nó RPC vs. Nó Validador
• Como funcionam os nós RPC da Solana
• Tipos de nós RPC da Solana
• Porque a Qualidade do Nó RPC Importa: DeFi, NFTs e Desempenho de dApps
• Melhores Provedores de Nós RPC da Solana
• Conectar a sua Aplicação Usando @solana/web3.js
• Métodos RPC da Solana: O que pode Consultar
• Como Executar o seu Próprio Nó RPC da Solana
• Erros Comuns de RPC da Solana e Como Corrigi-los
• Perguntas Frequentes
• Escolher a Estratégia de RPC da Solana Correta

O que são Nós RPC da Solana?

Um nó RPC da Solana é um servidor que implementa a API JSON-RPC da Solana, aceitando pedidos de aplicações cliente e retornando dados do estado da blockchain em resposta. As dApps, carteiras, exploradores de blocos e scripts automatizados utilizam estes nós para ler saldos de contas, submeter transações e subscrever eventos na blockchain sem manter uma cópia local do registo. On-Chain.

Materiais históricos citam uma taxa de transferência teórica da Solana próxima de 65.000 TPS e uma duração de slot alvo próxima de 400 milissegundos. Nenhum destes é um resultado garantido em tempo real: definições de transação, slots saltados, tráfego de votos, carga de trabalho, condições do cluster e versões de software afetam o desempenho observado. A cadência alvo e o volume de estado de contas ainda impõem exigências substanciais à infraestrutura RPC.

Chamada de Procedimento Remoto (RPC) é um padrão de comunicação em que um programa numa máquina chama uma função noutra máquina como se fosse local, com a complexidade da rede abstraída. A sua dApp pode consultar o estado da conta e submeter transações num nó remoto em vez de manter a sua própria cópia do registo. A Solana utiliza JSON-RPC 2.0 como seu protocolo de comunicação: um formato leve que roteia chamadas por nome de método via HTTP ou WebSocket, não por caminhos de URL baseados em recursos como as APIs REST.

A Solana Foundation opera Endpoints públicos gratuitos em https://api.mainnet-beta.solana.com e URLs equivalentes para devnet e testnet. Estes Endpoints aplicam limites de taxa por endereço IP. Quando a sua aplicação excede esses limites, recebe erros HTTP 429 Too Many Requests, causando falhas intermitentes e degradação da experiência do utilizador sob carga.

Nó RPC vs. Nó Validador: Compreender a Diferença

Um nó RPC serve dados da blockchain a clientes externos através da API JSON-RPC. Um nó validador participa no consenso e vota na validade dos blocos. Estes são os dois tipos primários de nós na Solana, e servem propósitos distintos.

Os nós validadores participam no consenso Tower BFT, um mecanismo de votação baseado em Proof-of-Stake. Proof of History (PoH), o mecanismo criptográfico de sequenciação da Solana (não o seu protocolo de consenso), estabelece a ordenação antes de os votos serem lançados. Tower BFT é a camada de consenso; PoH trata do controlo do tempo.

Gulf Stream, o protocolo de encaminhamento de transações da Solana, envia transações diretamente para nós líderes atuais e futuros, contornando a mempool que outras blockchains utilizam. Os validadores tratam deste processo de encaminhamento. Os nós RPC não.

Executar um nó RPC não requer SOL investido. Alguns operadores executam funcionalidade de validador e RPC na mesma máquina física, mas os papéis permanecem logicamente separados: um vota no consenso, o outro serve consultas de clientes. Para requisitos de hardware envolvidos na auto-hospedagem de um nó RPC, as exigências de RAM e armazenamento são substancialmente superiores às de um validador sozinho.

Como Funcionam os Nós RPC da Solana: Arquitetura e Fluxo de Dados

Um nó RPC da Solana mantém uma réplica local do registo e do estado da conta, servindo esses dados a qualquer cliente que envie um pedido JSON-RPC válido.

O Ciclo de Vida do Pedido JSON-RPC

1. Uma aplicação cliente (dApp, carteira ou script) envia um pedido POST HTTP ou uma mensagem WebSocket para o URL do Endpoint do nó RPC.
2. O corpo do pedido contém uma carga útil JSON-RPC 2.0 com quatro campos: jsonrpc, id, method, params.
3. O nó RPC recebe o pedido e encaminha-o para o gestor interno apropriado com base no campo method.
4. O nó consulta a sua réplica local do registo ou a loja de estado da conta para os dados solicitados.
5. O nó devolve uma resposta codificada em JSON contendo os dados solicitados ou um objeto de erro estruturado.

Um exemplo concreto de getBalance:

// Pedido
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBalance",
  "params": ["SuaChavePúblicaBase58Aqui", {"commitment": "confirmed
}


// Resposta
{
  "jsonrpc": "2.0",
  "result": {
    "context": {"slot": 285823400},
    "value": 5000000000
  },
  "id": 1
}
// Nota: O valor está em lamports. Divida por 1.000.000.000 para converter para SOL.

Ao contrário das APIs REST que utilizam URLs baseados em recursos, JSON-RPC roteia todas as chamadas através de um único Endpoint usando o campo method. Desenvolvedores com experiência em Ethereum reconhecerão a estrutura do pedido. A Solana difere em três aspetos chave: não existe mempool (as transações vão diretamente para o líder atual), o estado reside em contas em vez de armazenamento de contratos EVM, e os slots de 400ms são aproximadamente 30 vezes mais rápidos que os tempos de bloco de 12 segundos da Ethereum.

Níveis de Compromisso: processado, confirmado, finalizado

Cada chamada RPC que lê o estado aceita um parâmetro commitment:

• processed: O slot mais recente que o nó viu. Mais rápido, mas o slot poderia teoricamente ser revertido.
• confirmed: O slot recebeu uma supermaioria de votos de validadores. Forte finalidade para a maioria dos casos de uso de dApps.
• finalized: O slot é permanentemente parte da cadeia. Usar para operações de alto risco.

O que Armazena um Nó RPC da Solana

O nó detém duas categorias de dados. O estado atual da conta reside na RAM: o snapshot de todas as contas ativas no slot confirmado mais recente, necessário para respostas rápidas a consultas. Os dados históricos do livro-razão (ledger) residem em SSDs NVMe: todos os registos de transações organizados por slot. A Solana acumula aproximadamente 100 a 200 GB de dados de ledger por dia na Mainnet-beta. Esse crescimento do armazenamento, combinado com slots de 400ms, explica por que os nós RPC requerem no mínimo 256 GB de RAM e vários terabytes de armazenamento rápido.

Para a referência completa da API JSON-RPC da Solana, consulte docs.solana.com/api.

HTTP vs. WebSocket: Escolher o Transporte Certo

Tipos de Nós RPC da Solana: Públicos, Privados e Auto-Hospedados

Os nós RPC da Solana são acedidos de três formas: através dos endpoints públicos gratuitos da Solana Foundation, através de um fornecedor privado gerido ou através de um nó auto-hospedado operado por si diretamente.

Endpoints Públicos da Solana Endpoints (Gratuitos)

A Solana Foundation opera quatro endpoints RPC públicos, um por cluster de rede. Todos são gratuitos, mas aplicam limites de débito por endereço IP.

Os endpoints públicos aplicam um limite de débito de aproximadamente 100 pedidos por cada 10 segundos por endereço IP. Exceder este limite devolve o erro HTTP 429 Too Many Requests. Estes endpoints funcionam para desenvolvimento e testes. Para uso em produção, consulte a comparação de fornecedores de RPC da Solana abaixo.

Para documentação completa dos clusters, consulte docs.solana.com/clusters.

Fornecedores de Nós RPC Privados e Geridos

Um fornecedor de RPC gerido pode oferecer endpoints dedicados, limites publicados superiores, suporte para WebSocket, objetivos de serviço e múltiplas regiões; as funcionalidades exatas dependem do plano atual. Os quatro principais fornecedores para a Solana são:

• Helius: Fornecedor nativo da Solana com APIs RPC melhoradas e notificações por Webhook
• QuickNode: Fornecedor multi-chain com distribuição geográfica e um marketplace de add-ons
• Alchemy: Fornecedor multi-chain com ferramentas de desenvolvimento de nível empresarial
• Triton One: Especialista nativo da Solana focado em desempenho bruto de RPC para cargas de trabalho institucionais

Uma comparação completa com preços, suporte para WebSocket e diferenciais encontra-se na secção de comparação de fornecedores.

Nós RPC da Solana Auto-Hospedados

A auto-hospedagem dá-lhe controlo total sobre a sua infraestrutura RPC sem limites de débito, mas o custo do hardware começa nos milhares de dólares e a manutenção contínua de DevOps não é trivial. Os requisitos completos e uma visão geral da configuração estão em "Como Correr o Seu Próprio Nó RPC da Solana".

Por que a Qualidade do Nó RPC Importa: DeFi, NFTs e Desempenho de dApps

A qualidade do seu nó RPC determina diretamente se a sua aplicação funciona corretamente em condições de produção. Quatro casos de uso tornam isto concreto.

Bots de Trading e Arbitragem de DeFi

Protocolos de DeFi na Solana processam transações sensíveis ao tempo, onde a latência determina os resultados. Um Bot de trading que chama getLatestBlockhash e sendTransaction através de um endpoint público com limites de débito arrisca um blockhash desatualizado ou uma transação perdida durante um timeout 429. Na linha temporal de slots de 400ms da Solana, uma diferença de 50ms no tempo de resposta do RPC pode determinar se uma transação entra no slot pretendido ou se o perde completamente.

Jupiter (agregador), Raydium (AMM/DEX), Drift (perpétuos) e Marginfi (empréstimos) dependem todos de acesso RPC de baixa latência. Ao contrário da Mempool do Ethereum DeFi, as transações da Solana saltam a Mempool inteiramente via Gulf Stream, indo diretamente para o líder atual. Não existe uma fila de ordenação na qual possa confiar se a sua chamada RPC chegar atrasada.

Cunhagem de NFT e Monitorização de Marketplace

Cunhagens (mints) de NFT com elevada procura geram picos de centenas de chamadas sendTransaction concorrentes de compradores que competem por uma oferta limitada. Um endpoint público limitado a cerca de 10 pedidos por segundo devolve erros 429 à maioria dos participantes durante os picos de lançamentos. Marketplaces de NFT, tais como o Magic Eden e o Tensor, utilizam subscrições WebSocket logsSubscribe para detetar eventos de cunhagem em tempo real, o que requer um fornecedor que suporte ligações WebSocket estáveis em larga escala.

Carteiras e Dashboards de Portfólio

As aplicações de carteira chamam getBalance e getTokenAccountBalance para cada ativo que um utilizador detém, além de getAccountInfo para ler metadados na blockchain. Uma carteira que sirva 10.000 utilizadores ativos pode emitir dezenas de milhares de consultas RPC por minuto. Um fornecedor de RPC privado com capacidade suficiente de QPS (consultas por segundo) mantém estas consultas resolvidas sem degradar a experiência do utilizador. QPS aqui refere-se ao débito de pedidos RPC, não ao débito de transações ao nível da rede Solana.

Análise Na Blockchain, Indexadores e Integrações com Exchanges

Plataformas de análise e indexadores chamam getBlock repetidamente para replicar o histórico completo de transações do ledger da Solana. Uma sincronização histórica completa emite milhares de pedidos getBlock em sequência. Nós RPC auto-hospedados ou planos dedicados de nível empresarial são as únicas opções que sustentam este volume de forma fiável. Exchanges Centralizadas que operam os seus próprios nós RPC da Solana utilizam padrões semelhantes de elevado débito para reconciliar saldos de utilizadores e detetar depósitos em escala.

O tempo de slot de 400ms da Solana comparado com o tempo de bloco de aproximadamente 12 segundos do Ethereum significa que uma dApp da Solana consulta o RPC cerca de 30 vezes mais frequentemente por unidade de tempo para operações equivalentes, tornando o desempenho do nó RPC desproporcionalmente mais crítico aqui do que na maioria das outras redes. Se está a atingir limites de débito sob tráfego de produção, atualizar para um fornecedor de RPC privado é a correção mais direta.

Comparar Fornecedores de Nós RPC da Solana

Para a maioria das dApps em produção, a questão não é se deve usar um fornecedor de RPC gerido, mas sim qual deles se ajusta à sua carga de trabalho. A tabela cobre as quatro opções principais, tendo o endpoint público gratuito da Solana Foundation como base.

As informações de preços nesta tabela estavam corretas no momento da publicação. Os planos, preços e funcionalidades dos fornecedores mudam frequentemente. Verifique os detalhes atuais diretamente no website de cada fornecedor antes de efetuar uma seleção.

Última Atualização: julho de 2025

A Helius anuncia métodos RPC focados na Solana, webhooks e funcionalidades de análise de transações. As capacidades, quotas, preços, regiões e termos de serviço devem ser verificados diretamente em helius.dev e testados com a carga de trabalho pretendida.

A QuickNode anuncia infraestrutura RPC multi-cadeia, Endpoints regionais e suplementos opcionais. Verifique a cobertura atual de Solana, quotas, preços e termos de serviço em quicknode.com e, em seguida, avalie os métodos e regiões necessários.

A Alchemy anuncia infraestrutura de programador multi-cadeia que inclui suporte para Solana. Confirme a cobertura atual de métodos, o comportamento de WebSocket, limites, regiões e preços em alchemy.com antes de a tratar como equivalente a outro fornecedor.

A Triton One anuncia infraestrutura Solana para cargas de trabalho de maior rendimento. A sua latência, disponibilidade, cobertura geográfica, limites e termos comerciais requerem verificação direta em triton.one e testes específicos da carga de trabalho.

A GenesysGo operou anteriormente um serviço RPC de Solana sob a marca Shadow. Verifique o Status atual em genesysgo.com antes de avaliar.

Todos os principais fornecedores oferecem escalões gratuitos ou planos de teste suficientes para desenvolvimento e testes. Os limites de taxa tornam-se uma preocupação de produção apenas quando a sua aplicação serve utilizadores reais em escala.

Como Avaliar um Fornecedor de RPC da Solana

O fornecedor certo depende da sua carga de trabalho:

As alegações de latência dos fornecedores não são permutáveis. p50 é o tempo médio de resposta, enquanto p99 captura o 1% mais lento dos pedidos e pode ser importante para operações sensíveis ao tempo. Os resultados reais dependem da combinação de métodos, carga, proximidade geográfica, cache e limites do plano, por isso avalie o padrão de pedido pretendido antes de escolher um plano pago.

Ligar a Sua App a um Nó RPC da Solana Usando @solana/web3.js

Mudar do endpoint público da Fundação Solana para um fornecedor privado requer a alteração de uma linha na sua aplicação: a string do URL passada para o construtor da Connection.

Nota de versão: Os exemplos de código nesta secção utilizam o @solana/web3.js v1.x, o padrão de produção atual. Os Solana Labs estão a desenvolver a v2.0 com uma API significativamente diferente. Se estiver a utilizar a v2.0, consulte a documentação oficial da v2.0 para os métodos equivalentes.

Instalar e Ligar

Passo 1: Instalar o pacote

npm install @solana/web3.js

Passo 2: Instanciar uma Connection e consultar um Saldo

import { Connection, PublicKey, LAMPORTS_PER_SOL } from "@solana/web3.js";

// Obtenha o endpoint de uma variável de ambiente — nunca codifique um URL privado diretamente
const RPC_ENDPOINT = process.env.RPC_URL ?? "https://api.devnet.solana.com";

const connection = new Connection(RPC_ENDPOINT, "confirmed");

async function getWalletBalance(address: string): Promise<void> {
  const publicKey = new PublicKey(address);

  // getBalance devolve lamports; divida por LAMPORTS_PER_SOL (10^9) para obter SOL
  const balanceLamports = await connection.getBalance(publicKey);
  const balanceSOL = balanceLamports / LAMPORTS_PER_SOL;

  console.log(`Saldo: ${balanceSOL} SOL`);
}

Passo 3: Ler dados da conta

async function getAccountData(address: string): Promise<void> {
  const publicKey = new PublicKey(address);

  // getAccountInfo devolve null se a conta não existir
  const accountInfo = await connection.getAccountInfo(publicKey);

  if (!accountInfo) {
    console.log("Conta não encontrada");
    return;
  }

  console.log("Programa proprietário:", accountInfo.owner.toBase58());
  console.log("Comprimento dos dados (bytes):", accountInfo.data.length);
  console.log("Lamports:", accountInfo.lamports);
}

Passo 4: Enviar uma transação

import {
  Transaction,
  SystemProgram,
  Keypair,
  sendAndConfirmTransaction,
} from "@solana/web3.js";

async function transferSOL(
  sender: Keypair,
  recipientAddress: string,
  amountSOL: number
): Promise<string> {
  const recipient = new PublicKey(recipientAddress);
  const lamports = amountSOL * LAMPORTS_PER_SOL;

  const transaction = new Transaction().add(
    SystemProgram.transfer({
      fromPubkey: sender.publicKey,
      toPubkey: recipient,
      lamports,
    })
  );

  // sendAndConfirmTransaction aguarda pelo compromisso "confirmed" antes de resolver
  const signature = await sendAndConfirmTransaction(connection, transaction, [sender]);
  return signature;
}

Passo 5: Configurar a mudança de endpoint baseada no ambiente

Configure um módulo de configuração para alternar clusters através de uma variável de ambiente em vez de tocar no código da aplicação:

// config/rpc.ts
const RPC_ENDPOINTS: Record<string, string> = {
  "mainnet-beta": "https://api.mainnet-beta.solana.com",
  "devnet":       "https://api.devnet.solana.com",
  "private":      process.env.PRIVATE_RPC_URL ?? "",
};

const NETWORK = process.env.SOLANA_NETWORK ?? "devnet";
export const connection = new Connection(RPC_ENDPOINTS[NETWORK], "confirmed");

Nota de segurança: Nunca codifique o URL do seu endpoint RPC privado diretamente no JavaScript do lado do cliente. Um URL exposto no navegador revela a sua Chave da API a qualquer pessoa que inspecione o tráfego de rede. Encaminhe-o através de um proxy no lado do servidor ou uma rota de API de backend.

Para a referência completa da API @solana/web3.js, consulte solana-labs.github.io/solana-web3.js.

Ligações RPC HTTP vs. WebSocket: Quando Usar Cada Uma

As ligações WebSocket utilizam wss:// em vez de https://. A maioria dos fornecedores geridos disponibiliza ambos os Endpoints no mesmo plano.

// Subscrição WebSocket: monitorizar alterações de conta em tempo real
const publicKey = new PublicKey("YourAccountPublicKeyHere");

const connectionWithWS = new Connection(
  process.env.RPC_URL ?? "https://api.devnet.solana.com",
  {
    commitment: "confirmed",
    wsEndpoint: process.env.WSS_URL ?? "wss://api.devnet.solana.com",
  }
);

// onAccountChange retorna um ID de subscrição usado para limpeza posterior
const subscriptionId = connectionWithWS.onAccountChange(
  publicKey,
  (accountInfo, context) => {
    console.log("Conta alterada no slot:", context.slot);
    console.log("Novo saldo em lamports:", accountInfo.lamports);
  },
  "confirmed"
);

// Remova a subscrição quando não for mais necessária:
// connectionWithWS.removeAccountChangeListener(subscriptionId);

Lidar com Limites de Taxa (Rate Limits) e Erros 429

Um erro 429 Too Many Requests de um endpoint público da Solana significa que a sua aplicação excedeu o limite de taxa por IP. Três estratégias resolvem isto:

1. Mude para um fornecedor privado gerido. Helius, QuickNode, Alchemy e Triton One oferecem planos dimensionados para tráfego de produção. Consulte a comparação de fornecedores de RPC privados da Solana.
2. Implemente o backoff exponencial. Numa resposta 429, tente novamente com um atraso que duplica a cada tentativa (veja o código abaixo).
3. Leituras de conta em lote com getMultipleAccounts. Obter 20 contas numa única chamada consome um pedido em vez de 20.

// Wrapper de backoff exponencial para qualquer chamada RPC
async function withRetry<T>(
  fn: () => Promise<T>,
  maxRetries: number = 5
): Promise<T> {
  let attempt = 0;
  while (attempt < maxRetries) {
    try {
      return await fn();
    } catch (error: any) {
      const is429 = error?.message?.includes("429");
      if (is429 && attempt < maxRetries - 1) {
        // Aguarda 500ms, depois 1s, depois 2s, depois 4s, depois 8s
        const waitMs = 500 * Math.pow(2, attempt);
        await new Promise((resolve) => setTimeout(resolve, waitMs));
        attempt++;
      } else {
        throw error;
      }
    }
  }
  throw new Error("Número máximo de tentativas excedido");
}

Métodos RPC da Solana: O Que Pode Consultar

A API JSON-RPC da Solana expõe mais de 80 métodos. A tabela abaixo cobre os que a maioria dos programadores de dApps utiliza regularmente.

Métodos RPC HTTP

getRecentBlockhash foi descontinuado. Use getLatestBlockhash em substituição. A substituição também retorna lastValidBlockHeight, o que permite uma gestão fiável do Vencimento da transação.

Métodos de Subscrição WebSocket

As subscrições WebSocket adequam-se a qualquer dApp que precise de reagir a eventos Na blockchain sem polling. O accountSubscribe é acionado quando os dados de uma conta específica mudam, sendo útil para rastrear a carteira de um utilizador ou a conta de estado de um programa Solana (o equivalente a um Smart Contract no Ethereum). O logsSubscribe transmite logs de transações que correspondem a um filtro de ID de programa, utilizado por protocolos DeFi como Jupiter e Raydium para detetar eventos de swap à medida que ocorrem.

O Anchor, a framework de desenvolvimento de programas Solana mais utilizada, gera clientes TypeScript que chamam estes métodos através da @solana/web3.js internamente. A configuração de RPC aplica-se de forma idêntica a dApps baseadas em Anchor.

Para a referência completa dos métodos, incluindo parâmetros, tipos de retorno e códigos de erro, consulte a Documentação da API da Solana.

Como Executar o Seu Próprio Nó RPC da Solana: Requisitos e Visão Geral da Configuração

Alojar o seu próprio nó RPC da Solana dá-lhe controlo total, sem limites de taxa e máxima privacidade de dados. O investimento em hardware ascende a milhares de dólares e manter o nó saudável requer capacidade de DevOps dedicada. Grandes protocolos, exchanges e equipas com infraestruturas existentes são o público-alvo para este caminho.

Requisitos de Hardware

Os requisitos de hardware evoluem à medida que a rede cresce. Verifique as especificações atuais na documentação oficial da Solana em docs.solana.com/running-validator antes de adquirir hardware.

O modelo baseado em contas da Solana armazena todo o estado do programa em contas individuais. Um nó RPC completo deve manter o estado atual de cada conta ativa na RAM para respostas rápidas a consultas, além de dados históricos do ledger em SSD NVMe. O crescimento do armazenamento de 100 a 200 GB por dia na Mainnet-beta significa que os operadores devem planear a rotação contínua do ledger.

Visão Geral do Processo de Configuração

São necessárias sete fases. Cada passo liga à documentação oficial da Solana para detalhes completos de configuração.

1. Provisionar hardware que cumpra ou exceda as especificações acima.
2. Instalar o sistema operativo e configurar os parâmetros do kernel Linux: aumentar os limites de descritores de ficheiros ulimit e ajustar as definições de rede sysctl para o elevado volume de tráfego UDP da Solana.
3. Instalar a CLI da Solana e o binário do validador agave (anteriormente solana-validator) a partir do canal oficial de lançamentos da Solana Labs.
4. Configurar o nó para modo RPC passando a flag --no-voting para desativar a participação no consenso, e definir --rpc-port 8899 (HTTP) e --rpc-pubsub-port 8900 (WebSocket).
5. Descarregar um snapshot do repositório de snapshots da Solana Foundation para iniciar a sincronização a partir de um estado recente, em vez de reproduzir desde a génese.
6. Iniciar o nó e monitorizar o progresso da sincronização utilizando solana catchup para acompanhar o quão atrasado o nó está em relação à ponta do cluster.
7. Configurar regras de firewall para expor as portas 8899 e 8900 apenas a endereços IP autorizados. Não exponha a sua porta RPC publicamente sem autenticação.

Tempo de Sincronização e Manutenção Contínua

A sincronização por snapshot demora de 1 a 3 dias em hardware recomendado. Sincronizar desde a génese demora consideravelmente mais e não é recomendado.

O hardware dedicado (bare metal) custa tipicamente entre $500 e $1,500 por mês, dependendo das especificações e da localização geográfica do centro de dados. Os equivalentes em cloud custam mais devido à sobrecarga de virtualização em cargas de trabalho intensivas em armazenamento. O crescimento do armazenamento de 100 a 200 GB por dia obriga a escolher entre pré-alocar volumes massivos ou automatizar a poda (pruning) do ledger.

Para equipas que estejam a avaliar a decisão entre construir ou comprar, compare os custos dos fornecedores geridos na secção de comparação de fornecedores antes de se comprometerem com a aquisição de hardware.

Erros Comuns de RPC da Solana e Como Resolvê-los

429 Too Many Requests

A sua aplicação excedeu o limite de taxa por IP no endpoint público da Solana. Para resolver:

1. Mude para um fornecedor privado gerido. Helius, QuickNode, Alchemy e Triton One oferecem planos dimensionados para tráfego de produção. Veja a comparação de fornecedores privados de Solana RPC.
2. Implemente o backoff exponencial. Numa resposta 429, tente novamente com um atraso que duplica a cada tentativa. Um exemplo de código encontra-se na secção de tratamento de limites de taxa.
3. Agrupe leituras de contas com getMultipleAccounts. Obter 20 contas numa chamada consome um pedido em vez de 20.

Timeouts de Confirmação de Transações

Uma transação enviada através de sendTransaction não é concretizada. O blockhash pode ter expirado ou a rede pode ter estado congestionada. Para resolver:

1. Chame getLatestBlockhash imediatamente antes de construir uma transação. Não use getRecentBlockhash (descontinuado).
2. Verifique lastValidBlockHeight da resposta e tente novamente antes que essa altura seja atingida.
3. Use sendAndConfirmTransaction em vez de sendTransaction puro para retentativas automáticas em falhas transitórias.

Falhas de Limite de Taxa do getProgramAccounts

getProgramAccounts é uma das chamadas RPC mais intensivas em recursos. Endpoints públicos frequentemente restringem ou rejeitam esta chamada por completo devido à carga que coloca na infraestrutura partilhada. Se vir erros 403 ou timeouts especificamente nestas chamadas, atualize para um fornecedor RPC privado com suporte explícito para consultas de grandes contas de programa.

Perguntas Frequentes: Nós RPC da Solana

O que é um nó RPC da Solana?

Um nó RPC da Solana é um servidor que implementa a API JSON-RPC da Solana, aceitando pedidos de aplicações cliente e devolvendo dados de estado da Blockchain. DApps, carteiras e exploradores de blocos usam-nos para ler saldos de contas, obter histórico de transações e enviar transações assinadas para a rede sem executar uma cópia local do ledger.

Qual é a diferença entre um nó RPC da Solana e um nó validador?

Os dois servem funções diferentes. Um nó RPC serve dados para clientes externos através da API JSON-RPC, não participa no consenso e não obtém recompensas de Staking. Um nó validador vota na validade dos blocos a cada slot, requer SOL em Staking e obtém recompensas de SOL por votos corretos. Alguns operadores executam ambos no mesmo hardware, mas as funções permanecem logicamente separadas.

O endpoint RPC público da Solana é gratuito?

Sim. Os endpoints públicos da Fundação Solana em api.mainnet-beta.solana.com, api.devnet.solana.com e api.testnet.solana.com são gratuitos. Estes aplicam um limite de taxa de aproximadamente 100 pedidos por janela de 10 segundos por endereço IP. Estes endpoints são suficientes para desenvolvimento e testes, mas não são adequados para dApps de produção que servem utilizadores reais.

Como evito os limites de taxa no RPC público da Solana?

Três abordagens funcionam em conjunto: mudar para um fornecedor RPC privado gerido para tráfego de produção; implementar o backoff exponencial para tentar novamente pedidos falhados com intervalos de espera crescentes; e agrupar várias leituras de contas em chamadas únicas getMultipleAccounts em vez de emitir um getAccountInfo por conta.

Que hardware requer um nó RPC da Solana auto-hospedado?

No mínimo: uma CPU de 12 núcleos, 256 GB de RAM DDR4, 2 TB de SSD NVMe e uma ligação de rede dedicada de 1 Gbps. Recomendado para produção: uma CPU de 24 núcleos, 512 GB de RAM, 2x 2 TB de SSD NVMe e rede de 10 Gbps. Verifique as especificações atuais na documentação do validador Solana,) pois os requisitos aumentam à medida que a rede cresce.

Quanto tempo demora a sincronizar um nó RPC da Solana?

Planeie 1 a 3 dias usando um snapshot recente em hardware recomendado. A sincronização a partir do génese leva consideravelmente mais tempo. A Fundação Solana fornece snapshots oficiais para acelerar o processo.

Qual é a diferença entre ligações RPC HTTP e WebSocket na Solana?

O RPC HTTP utiliza um modelo sem estado de pedido-resposta. A sua aplicação envia um pedido e recebe uma resposta, o que funciona para consultas únicas como getBalance ou sendTransaction. O RPC WebSocket utiliza uma ligação persistente com um modelo de subscrição. A sua aplicação subscreve eventos Na blockchain e recebe notificações push quando esses eventos ocorrem. Use WebSocket para qualquer funcionalidade em tempo real na sua dApp.

Como é que as dApps de produção devem avaliar um fornecedor RPC da Solana?

Helius e QuickNode são duas Opções frequentemente discutidas, mas a visibilidade da comunidade não é prova de adequação ou desempenho. Helius é adequado para equipas que constroem exclusivamente na Solana e que necessitam de APIs melhoradas nativas da Solana. QuickNode é adequado para equipas que suportam várias blockchains numa única conta. Triton One é a Opção para cargas de trabalho institucionais onde a latência p99 é a principal restrição. A escolha certa depende da sua carga de trabalho e se as funcionalidades específicas da Solana ou o suporte multi-blockchain são mais importantes.

Guias Relacionados da Solana

• Propagação de blocos Solana Turbine
• Slots e tempo de bloco da Solana

Explore SOL em Bybit

Os leitores podem rever informações de mercado atuais de SOL) ou o mercado Spot SOL/USDT.). Estes links fornecem informações de mercado e acesso; não validam uma afirmação técnica nem implicam que SOL seja adequado para todos os leitores.

Escolher a Estratégia RPC Solana Certa para o Seu Caso de Uso

Existem três caminhos, e a maioria das equipas reconhecerá imediatamente qual se adapta à sua fase atual.

A fiabilidade do RPC afeta as leituras da aplicação e o envio de transações, mas uma duração de slot alvo não é uma garantia de confirmação e a latência do RPC é apenas um fator em se uma transação é concretizada. Escolha o nível que corresponde à sua escala atual e planeie atualizar antes que os limites de taxa se tornem um problema para o utilizador.

Próximos passos:

• Inscreva-se para um plano de desenvolvimento gratuito: helius.dev ou quicknode.com
• Reveja a referência completa dos métodos JSON-RPC da Solana: docs.solana.com/api
• Reveja as especificações de hardware antes de aprovisionar para auto-hospedagem: Como Executar o Seu Próprio Nó RPC Solana