Solana define atualização Alpenglow para 21 de outubro com meta de finalização de 150ms

Os desenvolvedores da Solana agendaram a atualização de consenso Alpenglow para 21 de outubro, visando uma finalização de aproximadamente 150 milissegundos, enquanto pedem aos validadores e operadores de aplicativos que se preparem para mudanças durante a transferência da mainnet.

Resumo

• A atualização Alpenglow da Solana está agendada para 21 de outubro, visando uma finalização 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 transferência.
• 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 finalização mais tarde do que os validadores que participam diretamente do consenso.

O aviso de manutenção da Quicknode identifica quarta-feira como o dia de ativação planejado, mas sua atualização mais recente alerta que a estimativa original de 14:50 UTC pode ser antecipada 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 transferência de consenso ocorrendo cerca de 20 minutos após a ativação.

A página de atualização atual da Fundação Solana 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, fazendo da fronteira da época o gatilho relevante em vez de um compromisso fixo de horário.

Solana Alpenglow visa finalização, não execução mais rápida

Sob o design de Anza, o Votor substitui a lógica de votação e finalização do TowerBFT. A meta é de aproximadamente 150 milissegundos em condições normais de rede, não uma garantia de que cada 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 do programa e a mecânica de taxas permanecem inalterados. Usuários comuns não precisam alterar a forma como assinam ou aprovam transações, enquanto a atualização separada de distribuição de dados Rotor é reservada para um lançamento posterior. Sua documentação separa a implementação do consenso de 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 iniciais que os usuários já veem. Sua visão geral afirma que os aplicativos comumente exibem confirmações dentro de dois a três segundos em configurações otimistas, antes que o antigo sistema alcance a finalização total em cerca de 13 segundos.

O lançamento de outubro segue um roteiro anterior que vinculou Alpenglow ao Agave 4.3. Um relatório de 14 de agosto documentou que o código Alpenglow estava presente no Agave 4.2 para testes, sem autorizar a ativação da mainnet nessa versão.

Até 26 de setembro, a atualização havia alcançado o devnet após a transição do testnet no dia anterior, conforme coberto anteriormente pela crypto.news. As equipes de aplicativos puderam então verificar o novo comportamento de consenso antes de implantar contra a rede que lida com os fundos dos usuários.

Comerciantes enfrentam uma breve interrupção durante a transferência

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 que dura alguns segundos, com uma interrupção mais longa possível se a transição levar mais tempo.

As submissões de transações podem retornar temporariamente um erro de pré-vôo "nó não saudável", diz o provedor. Os fluxos de dados do Yellowstone podem desconectar uma vez, enquanto as assinaturas usando o compromisso processado mais cedo podem exibir slots que nunca alcançam a confirmação.

O aviso de manutenção recomenda compromisso confirmado ou finalizado para dados que não devem ser revertidos. A Quicknode afirma que seus pontos finais existentes da Solana permanecerão em vigor 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 dos validadores inclui software e financiamento de contas

A lista de verificação atual da Solana Foundation instrui os validadores a executarem 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 Bilhete de Admissão do Validador. 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 precede esses requisitos operacionais. A proposta foi aprovada em setembro de 2025 com 98,27% dos votos a apoiá-la, de acordo com a cobertura da cédula concluída. A participação representou 52% do stake, portanto, a porcentagem de aprovação descreve os votos emitidos em vez de toda a população de validadores.

Esse voto anterior aprovou o SIMD-0326, a proposta por trás da reformulação do consenso. O relatório contemporâneo registrou 1,05% contra e 0,69% abstendo-se, com a pequena diferença de arredondamento preservada nos números publicados.

A entrega de RPC pode atrasar em relação à meta de 150ms

A documentação do operador da Anza explica que as mensagens de consenso normalmente circulam entre validadores admitidos. Um nó não apostado usando o caminho de entrega padrão aprende a finalização a partir de certificados transportados em blocos posteriores, normalmente somando a um intervalo de bloco produzido.

Blocos pulados ou atrasados podem alongar essa espera. Um nó associado a um validador admitido pode receber mensagens diretamente, embora a latência da rede entre os dois permaneça parte do tempo de entrega.

A cobertura do devnet de setembro documentou mudanças separadas para indexadores e exploradores. Blocos candidatos devem permanecer separados até a confirmação, e os dados de participação dos validadores se afastam de transações de voto ordinárias em direção a certificados anexados a dados de bloco.

De acordo com esse relatório, a remoção de transações de voto altera os totais do painel, mesmo quando o número de pagamentos e negociações de usuários permanece constante. Serviços que contam ambas as categorias devem redefinir suas comparações, enquanto sistemas que rastreiam votos de validadores precisam ler os dados de certificados de substituição.