Como projetamos para escalabilidade na Solana

Solana não se parece com nenhuma outra blockchain. Sua arquitetura foi projetada desde o primeiro dia para levar o throughput aos limites do hardware — execução paralela, cronometragem embutida, encaminhamento de transações sem mempool — tudo isso trabalhando em conjunto para entregar milhares de transações por segundo com finalidade em menos de um segundo. E com o Firedancer agora ativo na mainnet e o Alpenglow no horizonte, esse teto está prestes a subir drasticamente.

Construir infraestrutura que acompanhe esse ritmo exige mais do que nodes rápidos. Exige projetar cada camada do stack partindo do pressuposto de que a carga de amanhã será muito maior que a de hoje.

Foi assim que abordamos a escalabilidade quando reconstruímos nossa plataforma Solana do zero — e é assim que estamos posicionando-a para o que vem a seguir.

O modelo de escalabilidade da Solana é fundamentalmente diferente

Boa parte da infraestrutura blockchain é projetada em torno do modelo de execução do Ethereum: processamento sequencial de transações, uma trie de estado global e um volume de dados relativamente modesto. A Solana quebra todas essas premissas.

O Sealevel, o runtime paralelo da Solana, exige que cada transação declare previamente seus conjuntos de leitura e escrita, permitindo que transações que não se sobrepõem sejam executadas simultaneamente em vários núcleos de CPU. O Proof of History embute um relógio criptográfico diretamente no ledger, eliminando a sobrecarga de coordenação que torna o consenso mais lento em outras chains. E o Gulf Stream envia as transações diretamente para o próximo produtor de bloco, em vez de deixá-las esperando em um mempool, reduzindo ainda mais a latência de confirmação.

O resultado é uma rede que produz uma quantidade enorme de dados a uma velocidade extremamente alta — mais de 4 petabytes por ano em picos de velocidade. Uma infraestrutura que atende a esses dados não pode tratar a Solana como se fosse o Ethereum com um schema de RPC diferente. Ela precisa ser arquitetada em torno dos padrões de dados, características de acesso e escala específicos da Solana.

Foi esse entendimento que moldou cada decisão que tomamos.

Arquitetando para as características de dados da Solana

O perfil de dados da Solana cria um conjunto específico de desafios de infraestrutura. Os blocos são grandes e densos. As consultas históricas cobrem intervalos enormes. Os desenvolvedores precisam tanto de buscas pontuais aleatórias (recuperar uma única transação pela assinatura) quanto de varreduras sequenciais massivas (percorrer todo o histórico de assinaturas de um endereço). E tudo isso precisa acontecer com baixa latência, globalmente.

Cobrimos os detalhes técnicos mais profundos da nossa arquitetura de arquivamento em um post de engenharia separado — a migração para HBase, a ingestão com verificação tripla, os pipelines de autorrecuperação e as otimizações específicas que nos levaram a mais de 100.000 RPS por região em getTransaction. Este post trata dos princípios de design por trás dessas decisões.

O princípio central: separar as responsabilidades que precisam escalar de forma independente. A infraestrutura tradicional da Solana agrupa ingestão de dados, armazenamento e serviço em um único node validador monolítico. Esse acoplamento significa que não é possível escalar leituras facilmente, não é possível reiniciar um serviço sem horas de downtime e não é possível otimizar o layout de armazenamento sem mexer em todo o stack.

Decompomos o sistema em serviços independentes — servidores de RPC leves que iniciam em segundos, ingestores dedicados com controle granular sobre quais tipos de dados cada instância processa, e uma camada de armazenamento projetada especificamente para os padrões de acesso da Solana. Cada camada escala segundo seus próprios critérios. Quando o tráfego dispara, criamos instâncias adicionais de RPC em segundos contra a mesma camada de dados. Quando uma nova região precisa entrar em operação, a camada de armazenamento se replica de forma independente da camada de serviço.

Confiabilidade como pré-requisito para escalabilidade

Há um padrão na infraestrutura: as equipes otimizam para velocidade, batem em um limite de escala e então percebem que o limite era, na verdade, um problema de confiabilidade. Conexões perdidas, dados incompletos e falhas silenciosas sob carga são todas falhas de escalabilidade disfarçadas.

Projetamos tudo isso desde o início. Nossa arquitetura multi-região inclui de 3 a 5 camadas de failover autônomo — se um node, um rack ou uma região inteira degrada, o tráfego é redirecionado automaticamente.

No lado da integridade dos dados, cada registro é escrito duas vezes, validado programaticamente e continuamente escaneado em busca de integridade. Se surge alguma discrepância, nossos pipelines de autorrecuperação reingerem e corrigem automaticamente a lacuna — verificando cruzadamente até 30–50 endereços relacionados por bloco. Todo o processo de correção é automatizado e executa continuamente. Não é um painel estático de monitoramento com alertas.

A integridade dos dados na Solana é um problema mais difícil do que a maioria reconhece. O volume e a velocidade dos dados fazem com que até pequenas lacunas se acumulem rapidamente — e esse é um ponto de dor comum entre equipes de desenvolvimento, muitas das quais relataram dados ausentes ou inconsistentes vindos de seus provedores de infraestrutura. É um desses problemas que ficam invisíveis até que o app de um desenvolvedor quebre porque uma transação não foi indexada ou um histórico de assinaturas está incompleto. Tratamos a correção dos dados como algo não negociável, não como um esforço de melhor esforço.

O resultado é 99,99% de uptime, respaldado pelo mesmo rigor operacional que aplicamos há mais de 8 anos ao dar suporte a apps como o Polymarket na noite da eleição e o lançamento da mainnet da World. A confiabilidade nesse nível não é um recurso — é o que torna o restante da história de escalabilidade possível.

Projetando para a próxima era de throughput da Solana

O throughput atual da Solana é medido em milhares de transações por segundo. O roadmap do protocolo aponta para ordens de grandeza maiores, e a infraestrutura que não for arquitetada para essa trajetória se tornará o gargalo.

O Firedancer, cliente validador independente da Jump Crypto escrito em C, foi lançado na mainnet no final de 2025. Em condições de laboratório, já demonstrou mais de 1 milhão de transações por segundo. Sua arquitetura modular baseada em tiles, rede com kernel-bypass e verificação paralela de assinaturas representam uma reformulação fundamental de como o software validador usa o hardware. No final de 2025, cerca de 21% do stake da Solana estava rodando o Firedancer, e a adoção está acelerando.

Junto com o Firedancer, a atualização do protocolo Alpenglow visa reescrever o mecanismo de consenso da Solana e reduzir a finalidade dos blocos para aproximadamente 150 milissegundos. E propostas como a SIMD-0370 removeriam completamente o limite de computação no nível do bloco, permitindo que os blocos escalem de acordo com o que o hardware realmente consegue processar, em vez de um limite artificial de software.

Além disso, a ZK Compression, desenvolvida pela Light Protocol, permitirá que múltiplos estados de conta sejam comprimidos em uma única conta onchain usando provas de conhecimento zero. Isso resolve o crescente desafio de armazenamento de estado da Solana e abre novos padrões de design de aplicações.

Nossa infraestrutura é projetada com essas atualizações em mente. A arquitetura decomposta significa que podemos escalar cada camada de forma independente conforme os requisitos de throughput crescem. A implantação multi-região fornece a distribuição geográfica necessária para lidar com tráfego global em volumes maiores. Isso nos dá uma vantagem de throughput 2x em relação a outros provedores de Solana RPC — um ponto de partida, não um teto.

O que uma infraestrutura escalável viabiliza para os builders

A escalabilidade determina diretamente o que os desenvolvedores podem construir. Nos últimos oito anos, demos suporte a builders desde a primeira chamada de API até cada ponto de inflexão que se seguiu. Equipes como Circle, Robinhood e OpenSea escalaram na Alchemy desde protótipos iniciais até produtos que atendem centenas de milhões de usuários.

• Consultas de arquivo em milissegundos significam que carteiras podem renderizar históricos completos de transações instantaneamente.
• Consultas com prioridade de recência eliminam a necessidade de escanear anos de dados antigos só para exibir a atividade mais recente de um usuário.
• getTokenLargestAccounts retornando 1.000 resultados em vez de 20 dá às plataformas de análise visões significativamente mais ricas da distribuição de tokens.
• Transações nativas sem gas eliminam o atrito de onboarding que mata a conversão.
• Escritas 100% staked garantem que as transações cheguem a produtores de bloco reais, melhorando a confiabilidade de confirmação.

Essas capacidades existem porque tratamos a escalabilidade como um princípio fundamental.

O caminho à frente

A Solana está evoluindo rapidamente. A capacidade da rede vai aumentar, e as aplicações construídas sobre ela vão se tornar mais exigentes em escala.

Nosso compromisso é continuar à frente dessa curva, investindo em menor latência, maior throughput, acesso mais profundo a dados e novas capacidades que viabilizam casos de uso ainda não possíveis. A infraestrutura nunca deveria ser o motivo pelo qual um builder precisa comprometer seu produto.

Tudo o que descrevemos aqui está disponível hoje.

• Comece em alchemy.com/solana
• Fale conosco para benchmarking personalizado, preços especializados ou mais informações.

Perguntas frequentes

O que torna a escalabilidade da Solana diferente das outras blockchains?

A Solana usa execução paralela de transações via runtime Sealevel, Proof of History para cronometragem embutida e Gulf Stream para contornar mempools, permitindo milhares de transações por segundo com finalidade em menos de um segundo e produzindo mais de 4 petabytes de dados por ano em picos de velocidade.

Como a arquitetura decomposta da Alchemy melhora a escalabilidade na Solana?

A Alchemy separa a ingestão de dados, o armazenamento e o serviço em serviços independentes que escalam segundo seus próprios critérios, permitindo que servidores de RPC sejam criados em segundos, que o tráfego escale sem downtime e que novas regiões sejam implantadas sem mexer em todo o stack.

O que é o Firedancer e como ele impacta o throughput da Solana?

O Firedancer é o cliente validador independente da Jump Crypto escrito em C que foi lançado na mainnet no final de 2025, demonstrando mais de 1 milhão de transações por segundo em condições de laboratório por meio de arquitetura modular, rede com kernel-bypass e verificação paralela de assinaturas.

Como a Alchemy garante a integridade dos dados na escala da Solana?

Cada registro é escrito duas vezes, validado programaticamente e continuamente escaneado em busca de integridade, com pipelines de autorrecuperação que reingerem e corrigem automaticamente quaisquer lacunas verificando cruzadamente até 30–50 endereços relacionados por bloco.

O que é a ZK Compression e por que ela importa para a Solana?

A ZK Compression, desenvolvida pela Light Protocol, permite que múltiplos estados de conta sejam comprimidos em uma única conta onchain usando provas de conhecimento zero, resolvendo o crescente desafio de armazenamento de estado da Solana e viabilizando novos padrões de design de aplicações.

Como a Alchemy consegue consultas de arquivo mais rápidas na Solana?

Usamos uma camada de armazenamento baseada em HBase otimizada para os padrões de acesso da Solana, consultas com prioridade de recência e arquitetura multi-região para entregar consultas de arquivo em milissegundos com mais de 100.000 RPS por região em métodos como getTransaction.

O que torna a infraestrutura Solana da Alchemy confiável em escala?

Arquitetura multi-região com 3 a 5 camadas de failover autônomo, pipelines de autorrecuperação automatizados e validação contínua de dados entregam 99,99% de uptime, garantindo que o tráfego seja redirecionado automaticamente caso um node, rack ou região inteira degrade.

Quais recursos para desenvolvedores a infraestrutura escalável da Alchemy viabiliza?

Consultas de arquivo em milissegundos, consultas com prioridade de recência, getTokenLargestAccounts retornando 1.000 resultados em vez de 20, transações nativas sem gas e escritas 100% staked para maior confiabilidade de confirmação.