Solana Alpenglow: a maior reformulação de consenso da história do Solana

Hoje, as transações do Solana levam 12,8 segundos para serem finalizadas. A partir de 21 de outubro de 2026, esse tempo cai para 150 milissegundos, em todo o mainnet.

A mudança é o Alpenglow, a maior atualização de consenso do Solana desde o lançamento. Ele remove o Proof of History e o Tower BFT, os dois sistemas que definem como a rede chega a um acordo desde o primeiro dia, e os substitui por um design mais simples e muito mais rápido. Foi aprovado na governança com 98,27% de aprovação e deve entrar no ar no mainnet na epoch 1064, que começa por volta das 13:20 UTC de 21 de outubro, e o Votor assume no slot 459.653.000, cerca de 18 minutos depois.

Veja o que esperar quando a troca acontecer, como a Alchemy está se preparando e o que realmente muda por dentro. Para a fonte oficial no nível do protocolo, consulte a página de upgrade do Alpenglow da Solana Foundation e o SIMD-0326, a proposta de governança que o especifica.

O que esperar quando a troca no mainnet acontecer

Uma nova epoch (a janela de agendamento do Solana, de aproximadamente dois dias) começa por volta das 13:20 UTC de 21 de outubro. Como as epochs sempre têm a mesma duração, já sabemos o slot exato em que a troca acontece: 459.653.000. Mas a rede não muda no instante em que a epoch começa. Durante os primeiros 18 minutos, mais ou menos, ela continua usando o método de consenso antigo, o Tower BFT, antes de passar para o Votor, o substituto do Alpenglow, exatamente nesse slot. Isso muda apenas como a rede chega a um acordo sobre as transações internamente, não como você se comunica com ela, então os endpoints de RPC, WebSocket e gRPC devem continuar funcionando normalmente o tempo todo.

A troca em si deve levar cerca de dois blocos, aproximadamente 400 milissegundos, enquanto uma parte suficiente da rede confirma que está pronta. Durante essa breve janela, os novos blocos conterão apenas votos de validadores, sem transações de usuários. Nada deve ser rejeitado: uma transação enviada nesse momento deve simplesmente ser incluída um instante depois, quando a troca terminar.

Um efeito colateral que vale avisar sua equipe com antecedência: a contagem de transações e o TPS em painéis públicos vão parecer menores logo após a ativação. Isso não significa menos uso, e sim que os votos de validadores deixam de contar como transações. É também por isso que o Alpenglow libera 75% do espaço de bloco: os votos costumavam ocupar a maior parte dele, e agora não ocupam mais.

Depois que a ativação acontecer, você pode verificar se uma determinada rede já fez a troca chamando getAgGenesisCert. Ele não retorna nada antes da troca e retorna um resultado (com detalhes como o slot exato) depois.

Como a Alchemy se preparou para o Alpenglow

Todos os nós de Solana RPC da Alchemy já executam um cliente compatível com o Alpenglow antes da ativação, então os endpoints de RPC, WebSocket e Yellowstone gRPC não exigem nenhuma mudança do seu lado. Nosso roteamento de transações também já tenta novamente em outro backend quando um validador fica brevemente para trás em relação ao novo tempo de finalidade, a mesma proteção que lida hoje com servidores comuns que ficam atrasados.

Aproveite a Alchemy para ter RPC do Solana, dados de arquivo e streaming gRPC de nível excepcional, usados por equipes líderes no Solana como Phantom, Solflare, Cielo Finance e outras:

• Latência média de leitura de 9,21ms, cerca de 26% mais rápida que o provedor seguinte, medida nas 24 horas encerradas em 29 de setembro de 2026
• Consultas de arquivo até 20x mais rápidas e 10x mais rápidas em chamadas pesadas como getProgramAccounts, com tempos de resposta abaixo de 200ms em consultas históricas grandes (validado em produção pela Solflare)
• SLA de uptime de 99,99% e throughput 2x maior que o da stack da geração anterior
• gRPC compatível com Yellowstone com entrega média de 5-15ms e replay de blocos de 48 horas, cerca de 5x mais barato que as alternativas

Se você faz streaming de dados do Solana diretamente, este também é um bom momento para verificar a versão do seu cliente Yellowstone gRPC e confirmar que você só está fazendo commit de dados confirmed durante qualquer janela de migração. E como confirmed e finalized agora são resolvidos no mesmo ponto, fluxos que antes esperavam o finalized, como o crédito de depósitos, provavelmente podem ficar mais rápidos.

Obtenha um endpoint RPC gratuito do Solana →

Tudo sobre o Alpenglow

Como o Votor e o Rotor substituem o Tower BFT e o Turbine

O Alpenglow roda sobre dois novos protocolos: o Votor, que cuida da votação e da finalização, e o Rotor, que cuida da propagação de blocos. A pesquisa saiu do laboratório de sistemas distribuídos do Professor Wattenhofer na ETH Zurique, com a Anza liderando a implementação e a equipe do Firedancer, da Jump Crypto, trabalhando na compatibilidade entre múltiplos clientes.

Como a finalidade fica 85x mais rápida

O Tower BFT precisa de 32 confirmações incrementais, cada uma adicionando um período de lockout. O Votor condensa isso em uma ou duas rodadas de votação.

• Caminho rápido (~100ms): 80% ou mais dos validadores aprovam na primeira rodada, e pronto.
• Caminho lento (~150ms): 60-80% aprovam na primeira rodada, e uma segunda rodada conclui com um limite de 60% ou mais.

Os dois caminhos rodam ao mesmo tempo, e vence o que terminar primeiro. Em simulações, 65% do stake é finalizado em até 50ms de latência bruta de rede.

Os validadores enviam os votos como pequenas mensagens diretamente uns aos outros, em vez de transações na rede. Em seguida, o Votor comprime milhares desses votos em uma única prova de ~1.000 bytes usando uma técnica de combinação de assinaturas chamada agregação BLS, de modo que apenas essa pequena prova é registrada, substituindo os ~500KB de dados de voto registrados por bloco hoje.

Se você indexa ou consulta esse estado diretamente, chamadas mais pesadas como getProgramAccounts já rodam até 10x mais rápido na API de Solana da Alchemy, independentemente das melhorias de tempo do Alpenglow.

Como o Alpenglow libera 75% do espaço de bloco

Hoje, cerca de 75% de todas as transações do Solana são votos de validadores. O Alpenglow move a votação totalmente para fora da chain, então esse espaço volta para os usuários reais. Não é um ajuste: três quartos da capacidade da rede devolvidos ao uso real, com taxas mais baixas e menos congestionamento em períodos de pico.

Como o Alpenglow aposenta o Proof of History

O Alpenglow também abandona o relógio criptográfico original do Solana. Em vez de uma cadeia contínua de hashes, os validadores agora usam timers simples ligados ao tempo que um bloco deve levar: o bloco chega a tempo, aprove-o; o timer acaba sem nada, pule-o. O desvio de relógio é tratado de forma proporcional: um desvio de 5% só precisa de um timeout 5% maior.

O tempo para produzir cada bloco é um número separado da finalidade, e ele também mudou: quatro reduções em etapas o levaram de 400ms para 200ms, concluídas neste mês de outubro, antes da ativação do Alpenglow.

Como a finalidade cai de três níveis para um

Esta talvez seja a mudança que os desenvolvedores mais vão sentir. Atualmente, o Solana oferece três formas de verificar se uma transação passou: processed (a mais rápida, a menos certa), confirmed (~500ms, ainda com uma pequena chance de reversão) e finalized (~12,8s, permanência garantida). Qualquer coisa que não tolere nem uma pequena chance de reversão, como depósitos em exchanges, confirmações de bridges e liquidações, precisa esperar o finalized. Todo o resto se contenta com o confirmed e aceita esse pequeno risco.

O Alpenglow reduz confirmed e finalized a um só: 100-150ms, e toda transação é permanente no momento em que é confirmada. O processed continua sendo a etapa de observação mais cedo e menos certa, então não o trate como definitivo. Chega de trocar velocidade por certeza.

Isso abre padrões que antes não funcionavam. Order books com spreads mais apertados porque os market makers sabem que uma cotação é final em 150ms. Leilões JIT mais baratos em exchanges de perps. Bridges entre chains sem um gargalo de finalidade do lado do Solana. Depósitos em exchanges que passam de uma espera de 13 segundos para instantâneos. E, para bancos e fintechs, transações que liquidam rápido o suficiente para competir com os meios de pagamento tradicionais na liquidação de stablecoins e em transferências internacionais.

A finalidade rápida e determinística também torna as transações gasless uma experiência mais limpa de construir no Solana, já que patrocinadores e usuários finais recebem uma resposta final em uma única etapa, em vez de esperar uma janela de confirmação.

Como o Alpenglow muda a economia dos validadores

As taxas de voto, cerca de 1 SOL/dia por validador, deixam de existir. No lugar delas entra um Validator Admission Ticket de aproximadamente 0,8 SOL/dia, totalmente queimado. A rede é limitada a 2.000 validadores, começando pelo maior stake. O stake mínimo lucrativo cai de ~4.850 SOL para ~450 SOL, uma barreira cerca de 90% menor para operar um validador, e os custos operacionais totais caem de 20% a 50%. As chaves de identidade também podem ir para módulos de segurança de hardware, já que não assinam votos o tempo todo.

Como o Alpenglow troca segurança por velocidade

O Alpenglow usa um modelo de segurança "20+20". Isolado, ele tolera menos validadores abertamente maliciosos do que antes: 20% da rede em vez de 33%. Mas, combinado com validadores offline ou sem resposta, ele tolera até 40% da rede falhando de alguma forma, mais do que o antigo limite de 33%. Como as interrupções no mundo real costumam ser uma mistura de validadores maliciosos e simplesmente offline, esse número combinado é a medida mais realista.

A matemática continua garantindo que duas versões conflitantes da história não possam ser aprovadas ao mesmo tempo, já que os dois limites de aprovação (80% e 60%) somam mais de 100% da rede.

Como o rollout do Alpenglow chegou até aqui

O Alpenglow foi apresentado no Solana Accelerate em maio de 2025, passou na governança em setembro daquele ano (SIMD-0326), avançou por testes em cluster privado e pelo lançamento do Agave 4.1, chegou à devnet em setembro de 2026 e está programado para ser ativado no mainnet na epoch 1064, em 21 de outubro. Algumas partes do whitepaper original, como smart sampling, execução assíncrona e refinamentos adicionais do Rotor, ficam reservadas para propostas futuras.

Resultado final: uma troca completa de consenso em uma rede em operação, transações que se tornam permanentes em menos de 200ms, 75% do espaço de bloco liberado e uma barreira 90% menor para operar um validador.

FAQ

Quando o Alpenglow é ativado no mainnet do Solana?

Epoch 1064, por volta das 13:20 UTC de 21 de outubro de 2026. O Votor deve assumir no slot 459.653.000, cerca de 18 minutos após o início da epoch.

O Alpenglow vai causar downtime?

Não se espera nenhum downtime. O tráfego de RPC, WebSocket e gRPC deve funcionar normalmente o tempo todo. Espera-se uma breve pausa em novas transações de usuários, de cerca de 400ms, exatamente na troca, mas nada enviado nesse momento deve ser descartado: deve ser incluído assim que a troca terminar.

O confirmed ainda é um nível de commitment separado após o Alpenglow?

Não. Confirmed e finalized agora são resolvidos no mesmo ponto, de ~150ms, substituindo o antigo modelo de três níveis.

Como verifico se uma rede já fez a troca para o Alpenglow?

Chame getAgGenesisCert (Agave v4.3+). Ele não retorna nada se a rede ainda estiver no Tower BFT e retorna um resultado se estiver rodando o Alpenglow.

Preciso alterar minha integração Alchemy com o Solana para o Alpenglow?

Não. Os endpoints de RPC, WebSocket e Yellowstone gRPC não exigem nenhuma mudança, os nós de Solana da Alchemy já executam um cliente compatível com o Alpenglow.