---
title: "Nós Solana: validadores, nós RPC e self-hosting"
description: "O que são nós Solana, como validadores, nós RPC e sistemas de dados secundários se diferenciam, e quando optar por self-hosting versus usar um provedor."
---

# Nós Solana: validadores, nós RPC e self-hosting

<ImageBlock
  src="https://media.alchemy.com/blog/solana-nodes-hero-2026-07.png"
  alt="Nós Solana: validadores, nós RPC e auto-hospedagem"
  width={5760}
  height={2700}
  priority
/>

Uma carteira lendo um saldo, um explorer recuperando uma transação de dois anos atrás, e um sistema de trading consumindo atualizações de contas podem parecer usar o mesmo serviço Solana. Por baixo, dependem de infraestruturas diferentes.

Para times de aplicação, a pergunta útil não é simplesmente "Devemos rodar um node Solana?". É: quais workloads a nossa aplicação precisa, e quais partes do stack devemos operar nós mesmos?

## Quais são as três camadas da infraestrutura Solana?

Ao construir na Solana, existem 3 tipos de infraestrutura que derivam todos de nodes Solana. Então, o que é um node Solana? Simplificando, um node Solana é um servidor rodando o software cliente validador.

Validadores votantes garantem a segurança e produzem a chain, enquanto nodes RPC (remote procedure call) não votantes expõem estado ao vivo e APIs de transação. Sistemas separados de arquivamento, indexação, cache e streaming atendem workloads que um node padrão não consegue reter ou responder de forma eficiente sozinho.

### Validadores votantes garantem a segurança da chain

Validadores votantes participam do consenso e ajudam a rede a concordar sobre a chain canônica. Eles também produzem blocos quando selecionados como leader. Sua responsabilidade principal é manter-se sincronizados, votar corretamente e desempenhar as funções de leader de forma confiável.

Aplicações dependem desse consenso, mas a maioria das requisições de aplicação não é enviada diretamente a validadores votantes.

### Nodes RPC atendem o tráfego de aplicação em tempo real

Um node RPC geralmente roda o mesmo software cliente validador sem votar. Ele acompanha o cluster, faz replay dos blocos e mantém o estado atual das contas, mas não vota nem entra no leader schedule.

Em vez disso, ele expõe a interface RPC da Solana. Carteiras, exchanges, explorers, bots e outras aplicações usam essa interface para consultar dados da chain, simular transações e enviar transações.

Um validador votante tecnicamente também pode expor RPC. Em produção, operadores normalmente mantêm essa interface privada ou restrita para que o tráfego imprevisível de aplicações não compita com o consenso e a produção de blocos.

### Sistemas secundários atendem workloads de dados especializados

Nodes RPC expõem a API da Solana, mas os provedores não precisam responder toda requisição diretamente a partir de um node ao vivo. Eles podem usar sistemas construídos para:

- histórico de longo prazo de transações e blocos
- indexação de contas e consultas filtradas custosas
- cache de dados frequentemente requisitados
- streams em tempo real com filtragem, buffering, replay e recuperação

Para métodos RPC padrão atendidos por esses sistemas, as aplicações podem continuar usando os mesmos métodos, parâmetros, filtros e formatos de resposta já conhecidos. Apenas o sistema que responde à requisição muda. Histórico antigo vem de um armazenamento separado porque o node ao vivo não o tem mais, enquanto consultas custosas sobre o estado atual podem ser atendidas de forma mais eficiente a partir de índices ou caches dedicados.

## Qual camada de infraestrutura lida com cada workload Solana?

Considere algumas requisições comuns de aplicação:

- Uma carteira verifica um saldo ou simula uma transação. Um node RPC ao vivo pode responder diretamente a partir do estado atual.
- Um explorer carrega uma transação de dois anos atrás. A aplicação ainda chama um método RPC padrão, mas o provedor responde a partir de armazenamento arquivado porque o node ao vivo não tem mais os dados.
- Um app de portfólio consulta todas as contas pertencentes a um programa grande. O mesmo método RPC e os mesmos filtros podem ser atendidos por um índice de contas ou cache, em vez de fazer um node escanear repetidamente seu estado.
- Um sistema de trading precisa de toda atualização de conta ou transação no momento em que acontece. Ele usa infraestrutura de streaming para entrega contínua, geralmente junto com RPC para consultas pontuais.
- Um operador de rede quer votar e produzir blocos. Isso requer um validador votante, não um serviço RPC de aplicação.

Um provedor pode expor várias dessas capacidades como um único serviço. A aplicação vê interfaces familiares enquanto sistemas diferentes fazem o trabalho por trás delas.

## Como nodes Solana atendem dados históricos?

Métodos como `getTransaction`, `getBlock` e `getSignaturesForAddress` podem consultar atividade antiga. Um node RPC padrão, no entanto, retém localmente apenas uma janela limitada do ledger. Uma vez que dados mais antigos foram removidos (pruned), adicionar mais CPU não faz a consulta funcionar. Os dados simplesmente não estão mais naquele node.

Dados arquivados profundos da [Solana](https://www.alchemy.com/overviews/solana-archival-data) exigem um caminho separado que:

1. Ingere blocos e transações de fontes ao vivo e históricas
2. Detecta e corrige dados ausentes
3. Armazena os dados para retenção longa e alto volume de consultas
4. Atende requisições RPC históricas a partir dessa camada de armazenamento

É por isso que "archive RPC" não é simplesmente um node normal com um disco maior. Em escala de produção, provedores tipicamente atendem archive RPC a partir de sistemas separados de armazenamento e consulta, apresentados por meio de uma interface RPC familiar.

Na Alchemy, aprendemos essa restrição diretamente. Inicialmente usamos o Google Bigtable para o histórico da Solana, e depois reconstruímos o [stack de arquivamento em HBase auto-hospedado](https://www.alchemy.com/blog/how-alchemy-built-the-fastest-archival-methods-on-solana). Hoje, cada registro é escrito duas vezes, validado programaticamente e escaneado quanto à completude. Quando o sistema encontra uma lacuna, ele reingere a entrada faltante. Métodos históricos como `getTransaction` e `getSignaturesForAddress` agora leem a partir dessa camada de dados otimizada, em vez de depender da retenção local da frota RPC ao vivo, para oferecer a velocidade e a confiabilidade que nossos clientes esperam.

## Por que `getProgramAccounts` é custoso?

`getProgramAccounts` ilustra uma limitação diferente. Os dados da conta existem no estado atual, mas responder à requisição pode exigir buscar em um grande conjunto de contas e aplicar filtros no momento da consulta.

Um node armazena contas principalmente para poder fazer replay de blocos e manter o estado atual da chain. Não é um banco de dados analítico de propósito geral. Varreduras diretas ocasionais podem ser aceitáveis, mas escanear repetidamente milhões de contas se torna lento e intensivo em recursos sob tráfego de produção.

Para workloads sustentados, operadores podem consumir atualizações de contas continuamente e manter índices ou views em cache voltados para consulta. As requisições então leem resultados preparados em vez de repetir uma varredura completa a cada vez.

Requisições repetidas de `getProgramAccounts` são um problema de indexação, não uma questão de precisar de um node maior. Dito de outra forma, a distinção não é "node pequeno versus node grande". É atendimento a partir de dados ao vivo do node versus atendimento a partir de dados indexados.

## Como funcionam o streaming Geyser e gRPC?

Sistemas de trading, indexadores e outras aplicações em tempo real frequentemente precisam processar atualizações de contas, transações, slots ou blocos assim que elas acontecem.

Assinaturas WebSocket fazem parte da interface padrão da Solana e funcionam bem para eventos ao vivo selecionados. Para workloads que precisam de latência menor, throughput maior ou filtragem mais rica, o Yellowstone gRPC oferece uma interface de streaming mais performática construída sobre gRPC via HTTP/2.

O cliente validador Agave, inclusive quando roda como node RPC não votante, também pode rodar [plugins Geyser](https://www.alchemy.com/overviews/solana-geyser-plugin). O Geyser emite atualizações de contas, transações, slots e blocos enquanto o node processa a chain. Provedores podem expor esses dados por meio de [gRPC Solana compatível com Yellowstone](https://www.alchemy.com/solana-grpc), adicionando filtragem, buffering, replay, confiabilidade e entrega multi-node.

Streaming não substitui RPC. RPC responde a uma pergunta sobre estado. Streaming informa à aplicação que o estado mudou. Muitos sistemas de produção usam ambos.

## Quando você deve auto-hospedar infraestrutura Solana?

A maioria dos times de aplicação deve começar com um provedor. Um único node RPC auto-hospedado não cobre automaticamente todos os casos de uso que você precisa (fornecer histórico durável, consultas indexadas, APIs replicadas globalmente ou streams de dados), e fazer isso de forma confiável é bastante trabalho.

Auto-hospedar faz sentido quando o controle sobre sua infraestrutura melhora o produto ou quando requisitos de política descartam um serviço gerenciado. Exemplos incluem:

- um operador de validador participando do consenso
- um sistema de trading sensível a latência que precisa de posicionamento específico de node ou controle de roteamento de transações
- um serviço que exige plugins Geyser customizados, índices ou políticas de retenção
- uma organização com requisitos rígidos de compliance ou controle de infraestrutura
- uma plataforma grande cujo tráfego sustentado justifica um time dedicado de infraestrutura

O teste é se possuir a infraestrutura cria uma vantagem mensurável que supera o trabalho de hardware, engenharia e plantão (on-call).

## O que é preciso para operar infraestrutura Solana?

A orientação de hardware atual do [Agave](https://docs.anza.xyz/operations/requirements) estabelece um ponto de partida alto antes mesmo de considerar tráfego de produção, redundância e sistemas de dados adjacentes.

<EmbeddedTable
  table={{
    columns: [
      { key: "role", width: 180, title: "Role", dataType: "object" },
      {
        key: "baseline",
        width: 280,
        title: "Baseline requirements",
        dataType: "object",
      },
      {
        key: "production",
        width: 280,
        title: "What production adds",
        dataType: "object",
      },
    ],
    data: [
      {
        role: { title: "Voting validator", tooltip: "", icon: "" },
        baseline: {
          title:
            "12 cores, 24 threads, 256 GB RAM, and separate high-endurance NVMe storage",
          tooltip: "",
          icon: "",
        },
        production: {
          title:
            "Vote-account security, voting costs, upgrades, monitoring, and reliable leader performance",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        role: { title: "Non-voting RPC node", tooltip: "", icon: "" },
        baseline: {
          title:
            "16 cores, 32 threads, and 512 GB RAM when running all account indexes",
          tooltip: "",
          icon: "",
        },
        production: {
          title:
            "Replicas, load balancing, rate limits, failover, abuse protection, and on-call support",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        role: { title: "Secondary data systems", tooltip: "", icon: "" },
        baseline: {
          title: "Workload-dependent compute, storage, and networking",
          tooltip: "",
          icon: "",
        },
        production: {
          title:
            "Ingestion, verification, repair, replication, retention, and query-serving capacity",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

O hardware é apenas o piso. Sob o sistema de consenso atual da Solana, validadores votantes também podem gastar até aproximadamente 1,1 SOL por dia em transações de voto. Serviços RPC de produção precisam de nodes redundantes para evitar um ponto único de falha. Times que auto-hospedam e precisam de histórico profundo, índices ou streams confiáveis também precisam operar esses sistemas.

## Como você roda um node Solana?

A configuração começa pela função, não pela linha de comando.

1. Escolha o workload. Decida se a implantação vai votar, atender RPC ou alimentar um pipeline de dados especializado.
2. Provisione o host. Ajuste os requisitos atuais de CPU, memória, armazenamento, banda, sistema operacional e IP público ao cliente e à função.
3. Configure a função. Um operador RPC roda sem votar e seleciona o histórico, os índices de contas e as configurações de retenção necessários. Um operador de validador configura sua identidade e sua conta de voto.
4. Proteja chaves e endpoints. Mantenha chaves sensíveis fora do host do validador. Coloque os endpoints RPC e WebSocket públicos atrás de autenticação, rate limits e balanceamento de carga.
5. Opere o serviço completo. Monitore sincronização, disco, CPU, rede, saúde do processo e erros a nível de aplicação. Planeje upgrades, recuperação, failover e abuso.

Use os guias mantidos do Agave para os [comandos e flags de validador](https://docs.anza.xyz/operations/setup-a-validator) atuais ou a [configuração de node RPC](https://docs.anza.xyz/operations/setup-an-rpc-node).

## Como você deve avaliar um provedor de infraestrutura Solana?

Comece pelos workloads que sua aplicação precisa, depois pergunte como o provedor atende a cada um deles.

<EmbeddedTable
  table={{
    columns: [
      { key: "workload", width: 180, title: "Workload", dataType: "object" },
      {
        key: "evaluate",
        width: 480,
        title: "What to evaluate",
        dataType: "object",
      },
    ],
    data: [
      {
        workload: { title: "Live RPC", tooltip: "", icon: "" },
        evaluate: {
          title:
            "Which regions and node fleets serve reads, simulations, and transaction submission?",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        workload: { title: "Historical data", tooltip: "", icon: "" },
        evaluate: {
          title:
            "How far back does retention go, and how does the provider detect and repair missing data?",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        workload: { title: "Indexed queries", tooltip: "", icon: "" },
        evaluate: {
          title:
            "How are expensive methods such as getProgramAccounts served under sustained traffic?",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        workload: { title: "Streaming", tooltip: "", icon: "" },
        evaluate: {
          title:
            "Which Geyser or gRPC interface is supported, and what happens during a disconnect?",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        workload: { title: "Reliability", tooltip: "", icon: "" },
        evaluate: {
          title:
            "How are traffic, failover, replay, and regional incidents handled?",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
      {
        workload: { title: "Commercial fit", tooltip: "", icon: "" },
        evaluate: {
          title:
            "How do rate limits, burst traffic, pricing, and dedicated capacity change as usage grows?",
          tooltip: "",
          icon: "",
        },
        id: 5,
      },
    ],
  }}
/>

Faça benchmark dos métodos, assinaturas e regiões que sua aplicação vai usar. O [guia de provedores RPC Solana](https://www.alchemy.com/overviews/solana-rpc) compara as opções atuais segundo esses critérios.

## Conclusão

Uma aplicação Solana não precisa de "um node" no abstrato. Ela precisa de capacidades específicas: estado ao vivo, APIs de transação, histórico, consultas indexadas, streams ou, em um conjunto bem menor de casos, participação no consenso.

Identifique esses workloads primeiro. Depois decida quais partes do stack oferecem uma vantagem real quando operadas internamente e quais é melhor obter de um serviço gerenciado.

## Construa na Solana com a Alchemy

A maioria dos times de aplicação não precisa operar sua própria frota RPC, bancos de dados de arquivamento, índices e infraestrutura de streaming. Nós fornecemos RPC Solana ao vivo para estado e transações, histórico de blocos e transações desde o genesis via métodos padrão, e gRPC compatível com Yellowstone para streams em tempo real.

[Comece a construir na Solana](https://www.alchemy.com/solana), siga o [quickstart da Solana API](https://www.alchemy.com/docs/reference/solana-api-quickstart), ou [fale com nosso time](https://www.alchemy.com/contact-sales) sobre capacidade dedicada e workloads customizados.

## Perguntas frequentes

### O que é um node Solana?

Um node Solana é um servidor rodando o software cliente validador. Ele acompanha o cluster, faz replay dos blocos, mantém o estado atual da chain e se comunica com peers. Validadores votantes participam do consenso e da produção de blocos. Nodes RPC não votantes expõem APIs de aplicação.

### Qual é a diferença entre um validador e um node RPC?

Ambos acompanham e fazem replay da chain. Um validador votante participa do consenso e pode produzir blocos quando selecionado como leader. Um node RPC não vota nem entra no leader schedule. Ele se concentra em atender estado ao vivo e APIs de transação para aplicações.

### Um archive node é um tipo separado de node Solana?

Geralmente não. Histórico profundo de transações e blocos costuma ser atendido por um sistema de dados de arquivamento separado, por trás de uma interface compatível com RPC, e não por um node padrão com um disco maior.

### Aplicações precisam rodar um validador?

Normalmente não. Aplicações dependem de validadores para estabelecer a chain, mas suas próprias requisições normalmente vão para nodes RPC e serviços de dados especializados. Rodar um validador é necessário para participação no consenso, não para acesso comum de aplicações.

### Quais são os requisitos de hardware para um validador ou node RPC Solana?

A orientação atual do Agave começa em 12 cores, 24 threads e 256 GB de RAM para um validador votante. Um node RPC não votante começa em 16 cores e 32 threads, com 512 GB de RAM recomendados ao rodar todos os índices de contas. Ambos exigem armazenamento NVMe rápido e rede confiável.

### Preciso de SOL para rodar um node Solana?

Um node RPC não votante não exige SOL para votar. Um validador votante precisa de contas de identidade e de voto financiadas, e paga os custos de transações de voto sob o sistema de consenso atual.

### Rodar um validador Solana é lucrativo?

Depende do stake delegado, do desempenho de votação, da comissão, da receita de taxas de transação quando selecionado como leader, da receita de maximum extractable value e dos custos operacionais. Validadores com pouco stake delegado frequentemente têm dificuldade para atingir o ponto de equilíbrio. Trate a operação de validador como um negócio de infraestrutura próprio, não como uma forma de dar acesso RPC a uma aplicação.

### Como você roda um node Solana?

Escolha a função primeiro, provisione conforme os requisitos atuais do cliente, configure o comportamento de votação ou RPC, proteja chaves e endpoints, e adicione monitoramento e failover. Use a documentação atual do Agave para comandos e flags, porque os releases suportados e as recomendações mudam.

### Devo auto-hospedar um node RPC ou usar um provedor?

Use um provedor quando você precisar de capacidade gerenciada, dados históricos, métodos indexados, streaming ou failover sem operar esses sistemas você mesmo. Auto-hospede quando controle, configuração customizada, posicionamento físico, escala sustentada ou requisitos de política justificarem um time dedicado de infraestrutura.