Esse desenho ajudou a Solana a oferecer confirmações otimistas rápidas. Mas o Alpenglow mira uma camada mais forte de velocidade: a finalização. A Anza descreve a Solana atual como tendo finalidade otimista na casa de cerca de um segundo, enquanto a proposta SIMD-0326 compara a finalização de 12,8 segundos do Tower BFT com a faixa pretendida de 100–150 ms do Alpenglow .
Votor é a parte do Alpenglow que assume a lógica de votação e finalização de blocos . Na proposta SIMD-0326, ele é descrito como um protocolo leve, baseado em votos diretos, capaz de finalizar blocos em uma ou duas rodadas de votação, dependendo das condições da rede
.
A mudança é relevante porque substitui a lógica de torre de votos do Tower BFT. Em vez de depender de uma sequência mais longa de votos com lockouts, o Votor busca chegar à finalização em uma ou duas rodadas quando há participação suficiente de stake. Alguns resumos técnicos de terceiros citam limites de participação na faixa de 60% a 80% do stake, mas a leitura mais segura a partir da fonte primária é o modelo de finalização em rodada única ou dupla descrito no SIMD-0326 .
A Anza também afirma que o Alpenglow usa primitivas criptográficas BLS para reduzir drasticamente a latência de finalização sem abrir mão da segurança . O objetivo, portanto, não é só exibir uma confirmação mais rápida na interface: é encurtar o caminho até uma finalização determinística.
Rotor é o protocolo de disseminação de dados do Alpenglow. A Anza o descreve como uma evolução da abordagem do Turbine, o sistema atual de entrega de blocos da Solana .
A função é prática: não adianta o Votor votar depressa se os validadores não recebem os dados do bloco rápido o bastante para analisá-lo. Por isso, Rotor entra como a outra metade da proposta. Ele deve tornar a distribuição dos blocos mais rápida e previsível, sustentando a finalização de baixa latência.
Resumos de terceiros descrevem o Rotor como um sistema com caminhos de retransmissão mais estruturados e ponderados por stake. Algumas estimativas falam em propagação abaixo de 100 ms, e uma delas cita 18 ms em condições típicas de rede . Esses números devem ser tratados como metas ou estimativas, não como medições consolidadas da mainnet.
Em termos simples: a promessa mais direta do Alpenglow é reduzir a latência da finalização. Já os possíveis benefícios em throughput e custos de validadores vêm da redução do tráfego de consenso, especialmente dos votos, e não de uma mudança em todas as partes da execução da Solana.
A Anza apresentou o Alpenglow como um novo protocolo de consenso e o descreveu como a maior mudança já feita no protocolo central da Solana . A proposta formal SIMD-0326 foi publicada em agosto de 2025, chamando o Alpenglow de uma grande reforma do consenso principal da rede
.
A votação começou no fim de agosto de 2025. A SolanaFloor relatou uma janela de votação da epoch 840 até a epoch 842 . A proposta foi aprovada no início de setembro de 2025, embora os relatos publiquem percentuais ligeiramente diferentes: a Alchemy cita 98,27% de aprovação, enquanto a Blockworks cita 98,94% dos participantes votando a favor; ambas apontam participação de cerca de 52% do stake
. O ponto comum é que a governança foi aprovada com apoio amplo dos validadores.
O cronograma de testes até a rede principal é menos fechado. Um roadmap anterior da Anza mencionava expectativa de chegada à mainnet no início de 2026, enquanto um resumo da Alchemy publicado em abril de 2026 dizia que o Alpenglow estava em testes em cluster privado e que a mainnet era esperada para o fim de 2026 . A própria Anza também afirmou que o foco de 2026 era tirar o Alpenglow dos clusters de desenvolvimento e avançar para uma implantação mais ampla
.
A leitura mais prudente, com base nas fontes disponíveis, é: proposta e governança no 3º trimestre de 2025, desenvolvimento e testes em clusters privados ao longo de 2026, e possível chegada à mainnet em 2026 — com o fim de 2026 como cenário mais conservador se os testes continuarem sendo o principal filtro .
Se for implantado como proposto, o Alpenglow pode ser a mudança de consenso mais importante da história da Solana. O Votor foi desenhado para comprimir votos e finalização em uma ou duas rodadas rápidas; o Rotor, para fazer os dados dos blocos circularem pela rede de validadores com velocidade suficiente para sustentar esse novo caminho .
O número de 100–150 ms é forte e chama atenção, mas ainda deve ser lido como meta de engenharia até ser comprovado na mainnet. A proposta já tem o sinal verde da governança. Agora, a questão é se testes, clientes validadores e a economia real da rede confirmarão as reduções projetadas de latência, sobrecarga de votos e custos operacionais .
Comments
0 comments