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 aplicações 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ções de aproximadamente 150 milissegundos.
• A Quicknode alerta para 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 aos operadores que 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 aplicação 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 das reduções anteriores na duração dos slots, 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 as aplicações 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.

A implementação 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 a devnet após a transição da testnet no dia anterior, conforme coberto anteriormente pela crypto.news. As equipes de aplicação 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 fornecedor, 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. O Firedancer e o 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 votação 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 reforma do consenso. O relatório contemporâneo registrou 1,05% contra e 0,69% abstendo-se, com a pequena diferença de arredondamento preservada nas figuras publicadas.

A entrega de RPC pode atrasar-se em relação ao alvo 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 que utiliza o caminho de entrega padrão aprende a finalização a partir de certificados transportados em blocos posteriores, normalmente somando até um intervalo de bloco produzido.

Blocos pulados ou atrasados podem prolongar 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. Os blocos candidatos devem permanecer separados até a confirmação, e os dados de participação dos validadores mudam de transações de voto ordinárias para 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. Serviços que contam ambas as categorias devem redefinir suas comparações, enquanto sistemas que rastreiam os votos dos validadores precisam ler os dados do certificado de substituição.