Os desenvolvedores da Solana agendaram a atualização de consenso Alpenglow para 21 de outubro, visando uma finalidade de aproximadamente 150 milissegundos, enquanto pedem que validadores e operadores de aplicativos se preparem para mudanças durante a transição da mainnet.
Resumo
- A atualização Alpenglow da Solana está agendada para 21 de outubro, visando uma finalidade de transação de aproximadamente 150 milissegundos.
- A Quicknode alerta sobre uma breve pausa nas transações e possíveis interrupções no fluxo de dados durante a transição.
- Os validadores devem usar software compatível e financiar contas de voto para a taxa de admissão de 0,8 SOL.
- Alguns nós RPC podem receber informações de finalidade mais tarde do que os validadores que participam diretamente do consenso.
O aviso de manutenção da Quicknode identifica quarta-feira como o dia planejado para ativação, mas sua atualização mais recente alerta que a estimativa original de 14:50 UTC pode ser adiantada para 13:20 UTC à medida que a produção de blocos avança. O provedor pede que os operadores estejam prontos a partir das 13:00 UTC, com a transição de consenso ocorrendo aproximadamente 20 minutos após a ativação.
A página atual de atualizações da Solana Foundation coloca a mudança na época 1064 e lista a mainnet como ainda não ativada. Sua estimativa atualizada coloca o início da época perto das 13:20 UTC, tornando o limite da época o gatilho relevante em vez de um horário fixo no relógio.
Solana Alpenglow visa finalidade, não execução mais rápida
No design da Anza, o Votor substitui a lógica de votação e finalidade do TowerBFT. A meta é de aproximadamente 150 milissegundos em condições normais de rede, não uma garantia de que toda carteira, exchange ou aplicativo de negociação exibirá uma transação concluída dentro desse período.
A Fundação afirma que a execução de transações, o comportamento dos programas e a mecânica de taxas permanecem inalterados. Usuários comuns não precisam alterar como assinam ou aprovam transações, enquanto a atualização separada de distribuição de dados Rotor está reservada para uma versão posterior. Sua documentação separa a implantação do consenso das reduções anteriores na duração do slot, que governam com que frequência a rede produz blocos.
A visão técnica da Quicknode descreve dois caminhos de votação operando simultaneamente. Um pode finalizar um bloco em uma única rodada quando 80% dos validadores participam, enquanto o outro usa uma segunda rodada quando a participação atinge 60%.
O provedor distingue esse processo das confirmações antecipadas que os usuários já veem. Sua visão geral diz que os aplicativos comumente exibem confirmações dentro de dois a três segundos sob configurações otimistas, antes que o sistema antigo atinja a finalidade completa em cerca de 13 segundos.
A implantação de outubro segue um roteiro anterior que vinculava o Alpenglow ao Agave 4.3. Um relatório de 14 de agosto documentou que o código do Alpenglow estava presente no Agave 4.2 para testes, sem autorizar a ativação na mainnet naquela versão.
Em 26 de setembro, a atualização havia chegado à devnet após a transição da testnet no dia anterior, conforme coberto anteriormente pelo crypto.news. As equipes de aplicativos puderam então verificar o novo comportamento de consenso antes de implantar na rede que lida com os fundos dos usuários.
Traders enfrentam uma breve interrupção durante a transição
A Quicknode alerta que novas transações pararão brevemente de entrar em blocos enquanto a rede muda os sistemas de consenso. Seu aviso descreve uma pausa com duração de alguns segundos, com uma interrupção mais longa possível se a transição levar mais tempo.
O envio de transações pode retornar temporariamente um erro de pré-voo "node unhealthy", diz o provedor. Os fluxos de dados Yellowstone podem desconectar uma vez, enquanto assinaturas usando o compromisso processado mais antigo podem exibir slots que nunca chegam à confirmação.
O aviso de manutenção recomenda compromisso confirmado ou finalizado para dados que não devem ser revertidos. A Quicknode diz que seus endpoints Solana existentes permanecerão no lugar e que sua equipe monitorará a rede durante toda a mudança.
Na visão técnica do provedor, a liquidação irreversível mais rápida é relevante para aplicações financeiras, transferências de tesouraria corporativa e serviços em tempo real. O documento apresenta esses usos como capacidades da arquitetura de consenso proposta, sem estabelecer que plataformas de negociação individuais adotarão novas políticas de liquidação no dia da ativação.
A prontidão do validador inclui software e financiamento da conta
A lista de verificação atual da Solana Foundation instrui os validadores a executar a versão 4.3.2 do Agave, Jito-Solana ou Harmonic Salsa antes da época 1064. Firedancer e Frankendancer não são suportados durante a migração, de acordo com a mesma orientação.
Os operadores devem manter pelo menos 0,8 SOL acima do mínimo isento de aluguel em suas contas de voto para cobrir o Validator Admission Ticket. A primeira cobrança paga pela participação na época 1065, e uma taxa não paga impede um validador de votar ou produzir blocos na próxima época.
A aprovação da governança antecede esses requisitos operacionais. A proposta foi aprovada em setembro de 2025 com 98,27% dos votos a favor, de acordo com a cobertura da votação concluída. A participação representou 52% do stake, portanto a porcentagem de aprovação descreve os votos emitidos e não toda a população de validadores.
Essa votação anterior aprovou o SIMD-0326, a proposta por trás da reformulação do consenso. O relatório da época registrou 1,05% contra e 0,69% de abstenção, com a pequena diferença de arredondamento preservada nos números publicados.
A entrega do RPC pode ficar atrás da meta de 150ms
A documentação do operador da Anza explica que as mensagens de consenso normalmente circulam entre os validadores admitidos. Um nó sem stake usando o caminho de entrega padrão aprende a finalidade a partir de certificados carregados em blocos posteriores, normalmente adicionando até um intervalo de bloco produzido.
Blocos ignorados ou atrasados podem prolongar essa espera. Um nó associado a um validador admitido pode receber mensagens diretamente, embora a latência de rede entre os dois continue sendo parte do tempo de entrega.
A cobertura da devnet de setembro documentou mudanças separadas para indexadores e exploradores. Os blocos candidatos devem permanecer separados até a confirmação, e os dados de participação do validador se afastam das transações de voto comuns em direção a certificados anexados aos dados do bloco.
De acordo com esse relatório, a remoção das transações de voto altera os totais do painel mesmo quando o número de pagamentos e negociações de usuários permanece constante. Os serviços que contam ambas as categorias devem redefinir suas comparações, enquanto os sistemas que rastreiam os votos dos validadores precisam ler os dados do certificado de substituição.
