Solana Alpenglow explicado: o que o Votor muda no consenso

Principais pontos

• A Solana tem previsão de substituir seu consenso TowerBFT pelo Votor, a primeira metade do projeto Alpenglow, na mainnet-beta na quarta-feira, 21 de outubro de 2026. A Anza, desenvolvedora do cliente de validador Agave, indicou a entrada em operação por volta das 14h50 UTC.
• A Solana Foundation afirma que a finalidade deve cair de cerca de 12,8 segundos para uma meta de aproximadamente 150 milissegundos. A Foundation chama esse número de "uma expectativa, não uma constante".
• Segundo a Anza, o Votor tolera ao mesmo tempo 20% de stake malicioso e outros 20% de stake offline. O TowerBFT tolerava menos de 33% de stake malicioso.
• O Rotor, a segunda metade do Alpenglow, substituiria a camada de propagação de blocos Turbine. Ele não faz parte da troca de hoje e não tem data de lançamento.
• A transição acontece em uma rede em funcionamento, sem reinicialização. Ela exige que 82% do stake assine um "certificado gênese", e apenas clientes baseados no Agave podem participar da migração.

O que é o Alpenglow

O Alpenglow é um novo protocolo de consenso para a Solana, projetado por pesquisadores da Anza. Consenso é o processo que os validadores usam para concordar sobre quais blocos são definitivos. Desde o lançamento, a rede usa o TowerBFT, um sistema de votação ligado ao Proof of History, o relógio criptográfico da Solana. No TowerBFT, os validadores enviam votos como transações comuns na blockchain. Esses votos ocupam uma grande parte do espaço dos blocos, e um bloco só é considerado definitivo depois de muitas rodadas de confirmações.

O Alpenglow divide o trabalho em dois componentes. O Votor cuida da votação e da finalidade. O Rotor cuida de como os dados dos blocos circulam entre os validadores. A Anza descreve a troca de 21 de outubro como a Fase 1: o Votor entra em operação enquanto a camada de propagação Turbine existente é mantida. Os validadores aprovaram a proposta geral do Alpenglow em uma votação de governança em setembro de 2025. O Decrypt informou que cerca de 98% dos votos foram favoráveis.

A Anza apresenta a migração como a primeira do mundo a trocar motores de consenso em uma rede em funcionamento, segundo o relato do Solana Compass sobre o anúncio. A afirmação é da própria Anza, e o Bullquill não a verificou de forma independente. A empresa também descreveu o esforço como 18 meses de trabalho para uma migração que acontece em um único slot.

Como o Votor muda o consenso

A página da atualização da Solana Foundation apresenta três mudanças principais.

Os votos saem da blockchain

No Votor, os validadores enviam votos diretamente uns aos outros, em vez de enviá-los como transações. Esses votos são então agregados em certificados compactos com assinaturas BLS. As chaves BLS dos validadores foram ativadas na mainnet em 8 de julho de 2026, como preparação. Os certificados são registrados em um "rodapé" (footer) do bloco, e não como transações de voto individuais.

Dois caminhos para a finalidade

O Votor executa dois caminhos de votação ao mesmo tempo, e vale o primeiro que finalizar um bloco. No caminho rápido, um bloco é definitivo após uma rodada se pelo menos 80% do stake votar para notarizá-lo. Se esse limite não for atingido, uma segunda rodada finaliza o bloco com 60% do stake. Os mesmos limites de 60% se aplicam aos certificados de notarização e de salto (skip). A página do Alpenglow da Anza diz que a geografia influencia qual caminho vence, porque a velocidade dos votos depende de onde os validadores estão.

O Proof of History deixa de ditar o ritmo dos blocos

A Foundation diz que os ticks saem do ledger e que o carimbo de data e hora do sysvar Clock é definido pelo líder do bloco, dentro de certos limites. Assim, o Proof of History deixa de ditar o ritmo da produção de blocos. Separadamente, o tempo de slot foi reduzido de 400 ms para 200 ms em quatro etapas ao longo de outubro de 2026. A Foundation ressalta que tempo de bloco e finalidade são medidas diferentes.

Os números: parâmetros de projeto confirmados versus metas

A tabela abaixo lista os principais números e indica o tipo de afirmação de cada um. "Parâmetro de projeto" significa uma regra escrita na especificação do protocolo. "Meta" significa um objetivo de desempenho que ainda não foi medido na mainnet.

Dados referentes ao momento da pesquisa deste artigo, em 21 de outubro de 2026, com base nas fontes listadas abaixo.

Se a meta for atingida, a queda de 12,8 segundos para 150 milissegundos tornaria a finalidade cerca de 85 vezes mais rápida. Em maio de 2026, o economista-chefe da Anza, Max Resnick, disse ao Decrypt que o tempo até a finalidade "caiu ~100 vezes" quando os clusters de teste passaram do TowerBFT para o Alpenglow. Nenhum dos dois números foi medido ainda sob a carga total da mainnet.

Como a troca deve acontecer

O procedimento de migração está definido no SIMD-0384, escrito por Kobi Sliwinski, Ashwin Sekar e Carl Lin, da Anza. A página da Solana Foundation e a especificação descrevem a seguinte sequência:

1. Feature gate. O recurso Alpenglow é ativado no início da época 1064. A Anza diz que "nada migra imediatamente". O TowerBFT continua funcionando nos primeiros 5.000 slots da época.
2. Blocos só de votos. Depois desses 5.000 slots, os blocos podem conter apenas votos de validadores. As transações dos usuários ficam pausadas nessa janela. A Foundation situa a tomada do consenso no slot 459.653.000.
3. Certificado gênese. Os validadores escolhem um bloco recente como ponto de partida, ou "bloco gênese", do Alpenglow e assinam votos BLS para ele. Quando pelo menos 82% do stake tiver assinado, forma-se um certificado gênese.
4. Reversão e transição. Os validadores descartam os blocos só de votos posteriores ao bloco gênese, passam o consenso ao Votor e retomam as transações dos usuários. O SIMD-0384 diz que o efeito sobre as transações dos usuários é, "na melhor das hipóteses, de apenas um slot além do slot-limite da migração". A Anza espera que a transição leve centenas de milissegundos.

O horário é uma estimativa

Os horários divulgados não coincidem. A Solana Foundation estima que a época 1064 começa por volta das 13h20 UTC. O anúncio da Anza, segundo o Solana Compass, indica cerca de 14h50 UTC para a entrada em operação. O Solana Compass observou que a Anza não esclareceu se 14h50 UTC se refere à ativação do feature gate ou à transição. Os limites de época dependem da velocidade de produção dos slots, então o momento exato pode mudar. A página do Alpenglow da Anza também diz que a migração da mainnet "será anunciada" depois que seu período de observação confirmar os testes anteriores. Quando este artigo foi escrito, o Bullquill não havia encontrado confirmação pública de que o certificado gênese da mainnet tivesse se formado.

A própria data também mudou. No fim de setembro, relatos indicavam que a ativação poderia ocorrer em 28 de setembro. O cofundador da Solana Anatoly Yakovenko e o chefe de pesquisa da Anza Roger Wattenhofer contestaram esses relatos no X, segundo o KuCoin News. A testnet migrou então em 24 de setembro e a devnet em 25 de setembro, antes de a data de 21 de outubro ser definida.

O que os validadores precisam ter pronto

• Cliente. A Solana Foundation diz que os validadores precisam rodar a v4.3.2 do Agave, do Jito-Solana ou do Harmonic Salsa antes da época 1064. Firedancer e Frankendancer não são suportados durante a migração.
• Saldo da vote account. Os validadores precisam manter pelo menos 0,8 SOL acima do mínimo isento de aluguel (rent-exempt) na vote account (não na identity account) para pagar o Validator Admission Ticket. O primeiro ticket é cobrado no início da época 1064 e cobre a época 1065. Um validador que não puder pagar não vota nem produz blocos na época seguinte.
• Stake fora dos clientes suportados. Em 13 de outubro, o Solana Compass contou cerca de 15,8% do stake entre os 500 principais validadores em clientes da família Firedancer. Pelas contas dele, isso deixa cerca de 84% em clientes suportados, pouco acima do limite gênese de 82%. Esse retrato tem uma semana, e os operadores podem ter trocado de cliente desde então.
• Jito BAM. Segundo a leitura do Solana Compass sobre o changelog da Jito, a Jito informou que os nós BAM da mainnet entrariam em modo de manutenção antes da ativação e desaconselhou rodar FireBAM ou FrankenBAM durante a transição.

O que desenvolvedores e usuários vão notar

• Contagens de transações menores que não refletem menos atividade. Os votos saem dos blocos, então os painéis que contam todas as transações vão mostrar uma queda acentuada. Nos dados de 10 a 12 de outubro citados pelo Solana Compass, os votos tiveram média de cerca de 3.060 por segundo, contra cerca de 1.780 transações de usuários por segundo. A Foundation chama isso de "uma mudança contábil".
• Níveis de commitment. processed, confirmed e finalized continuam existindo, e nenhuma alteração de código é necessária no dia da ativação. Depois da ativação, confirmed e finalized descrevem o mesmo estado, e confirmed será removido em uma versão futura. A Foundation recomenda mudar o código para finalized somente depois que o Alpenglow estiver ativo.
• Como verificar se a troca aconteceu. O método RPC getAgGenesisCert retorna null enquanto o cluster roda o TowerBFT e retorna um certificado após a migração. Nós RPC anteriores à v4.3 retornam o erro "Method not found". A Foundation recomenda condicionar a lógica específica do Alpenglow a essa chamada, e não a uma data.
• Pipelines de dados. Um slot agora pode conter mais de um bloco candidato. A Foundation recomenda que consumidores de Geyser e gRPC armazenem os dados em buffer por slot e por bank_id.

Para usuários comuns, a principal mudança esperada é que as transações alcancem finalidade plena e irreversível muito mais rápido. A Foundation não promete nenhuma mudança específica em taxas ou capacidade de processamento decorrente apenas do Votor.

O que está confirmado, o que está programado e o que não foi verificado

O que significa

O Alpenglow é a maior mudança já feita no protocolo central da Solana. Ele substitui o sistema de votação que a rede usa desde o lançamento. Se o Votor atingir suas metas, aplicações que precisam de certeza de liquidação, como pagamentos, exchanges e pontes entre blockchains, poderão considerar as transações definitivas em uma fração de segundo, em vez de esperar mais de dez segundos. A retirada dos votos dos blocos também muda a forma de medir a atividade da rede, então comparações de transações por segundo antes e depois de 21 de outubro não serão equivalentes.

Há também riscos reais de execução. A transição depende de 82% do stake rodar software suportado no momento certo, o que deixa uma margem estreita, considerando a fatia de stake em clientes da família Firedancer. A diversidade de clientes diminui enquanto a migração ocorre. O modelo de tolerância a falhas é novo e só foi testado em redes de teste. O número de 150 ms vai depender da distribuição do stake e da geografia. Os pontos a acompanhar são se o certificado gênese se forma no prazo, quanto tempo dura a pausa nas transações dos usuários, como ficam os tempos de finalidade nos primeiros dias e quando Firedancer e Rotor ganham datas.

Fontes

• Solana Foundation: Alpenglow upgrade page
• Anza: Alpenglow
• SIMD-0384: Alpenglow migration (Solana Improvement Documents)
• Solana Compass: Anza sets Alpenglow mainnet date
• Decrypt: Solana Alpenglow upgrade begins testing ahead of full rollout
• KuCoin News: Solana developers deny Alpenglow mainnet activation on September 28
• Jito BAM changelog, September 23 to October 9

Este artigo é apenas informativo e não constitui recomendação de investimento.