A atualização Alpenglow da Solana chegou à sua rede pública para desenvolvedores, permitindo que equipes de aplicações testem um sistema projetado para reduzir a finalidade das transações de cerca de 12,8 segundos para aproximadamente 150 milissegundos.

De acordo com a página de atualizações da Solana Foundation, o Alpenglow agora está ativo na devnet e na testnet, mas ainda não foi ativado na mainnet. A Anza, que desenvolve o software principal de validadores da Solana, anunciou a mudança na devnet em 25 de setembro, um dia após a testnet concluir sua transição.

As duas redes atendem a partes diferentes da implementação. Equipes de aplicações podem usar a devnet para verificar como seu software se comporta com tokens sem valor real, enquanto a testnet oferece a validadores e operadores de infraestrutura um ambiente para testar o software da rede sob condições mais exigentes.

Para os desenvolvedores, a nova etapa na devnet significa que eles podem testar aplicações com o Alpenglow sem esperar que o sistema chegue à blockchain que lida com os fundos dos usuários. A mainnet da Solana continua usando o TowerBFT, portanto o número de 150 milissegundos segue sendo uma meta da atualização planejada, e não um tempo de finalidade disponível aos usuários hoje.

O Alpenglow da Solana muda a forma como os validadores finalizam blocos

No TowerBFT, os validadores enviam votos como transações que aparecem dentro dos blocos. Votos suficientes precisam se acumular ao longo de 32 slots antes que um bloco se torne final, o que atualmente leva cerca de 12,8 segundos, segundo a Foundation.

A primeira fase do Alpenglow, chamada Votor, faz com que os validadores enviem votos diretamente uns aos outros. A Foundation afirma que um bloco pode atingir finalidade após uma rodada de votação se validadores que representem pelo menos 80% do stake votarem para aceitá-lo. Uma segunda rodada oferece outro caminho quando a primeira não atinge esse limite.

Finalidade é o ponto em que a rede concordou com uma transação de forma suficientemente forte para que ela não possa mais ser revertida sob suas regras de consenso. Um resultado mais rápido pode ser relevante para uma exchange dos EUA ao decidir quando creditar um depósito em Solana, ou para um provedor de pagamentos ao decidir quando tratar a venda de um comerciante como concluída. Cada serviço ainda pode aplicar suas próprias verificações antes de liberar fundos ou confirmar um pagamento ao cliente.

A Foundation separa a finalidade do tempo necessário para produzir um bloco. Em setembro, a Solana reduziu seu tempo-alvo de slot de 300 milissegundos para 250 milissegundos, com uma redução adicional para 200 milissegundos planejada em uma atualização separada. Slots mais curtos alteram a frequência com que a rede pode produzi-los; o Alpenglow altera como os validadores concordam que um bloco é final.

Uma reportagem anterior da crypto.news abordou os preparativos da testnet em 23 de setembro, quando os desenvolvedores estavam preparando o Agave 4.3 para o teste público. A mudança para a devnet agora dá às equipes de aplicações acesso ao sistema de consenso atualizado na rede que elas normalmente usam para desenvolvimento.

Serviços de dados de blocos enfrentam mudanças antes da mainnet

Para uma aplicação que envia transações e lê saldos de contas, a Foundation afirma que o Alpenglow não exige migração. A execução de transações, as taxas e os formatos usados para enviar transações permanecem os mesmos sob a atualização de consenso.

Os serviços que constroem históricos de transações têm mais trabalho a fazer. O Alpenglow pode expor blocos candidatos concorrentes para o mesmo slot antes de a rede selecionar um deles. A Foundation orienta os provedores de dados a manter esses candidatos separados e, em seguida, reter o bloco que alcançar confirmação. Combinar transações de candidatos diferentes pode deixar um explorador ou outro serviço com um registro incorreto.

Os votos dos validadores também desaparecerão dos blocos porque deixarão de ser enviados como transações. Como resultado, um gráfico que conte tanto as transações de usuários quanto os votos dos validadores mostrará um total menor de transações após a ativação, mesmo que os usuários façam o mesmo número de pagamentos e negociações. A Foundation orientou os provedores de dados a redefinir comparações e alertas baseados nos números antigos.

Alguns serviços também leem a participação dos validadores a partir das transações de voto. No Alpenglow, a Foundation diz que essa informação passa para certificados anexados aos dados dos blocos, exigindo que esses serviços mudem de onde a obtêm. Operadores que usam os fluxos de dados Geyser ou gRPC da Solana também devem considerar os identificadores que distinguem blocos candidatos dentro de um slot.

As mudanças tornam os testes na devnet relevantes para exchanges, exploradores e outras empresas que dependem de registros de transações, incluindo serviços dos EUA conectados à Solana. Suas regras de depósito continuam sendo uma decisão operacional própria; a atualização da rede não altera automaticamente quando uma plataforma disponibiliza os fundos.

A ativação na mainnet ainda não tem data definida

O roadmap anterior do Alpenglow na Solana vinculava a proposta de lançamento na mainnet ao Agave 4.3 e a uma meta para outubro. Nem a transição da testnet nem a ativação na devnet estabelecem uma data confirmada para a mudança na rede ao vivo.

O cronograma de software da Anza permite provisoriamente que ativações de recursos na mainnet sejam retomadas em 28 de setembro. O cronograma não identifica esse dia como a data de ativação do Alpenglow, e a página de status da Foundation ainda lista a atualização como inativa na mainnet.

A Foundation descreve o Votor como a primeira fase do Alpenglow. Uma fase posterior, Rotor, está planejada para substituir o sistema usado para propagar blocos pela rede. A implementação atual diz respeito às mudanças em votação e finalidade, enquanto a meta de aproximadamente 150 milissegundos vem de testes e simulações, e não de transações liquidadas sob condições de mercado ao vivo.