Prevê-se que a Solana lance o Alpenglow — que Anza descreve como a maior atualização de consenso da sua história — na rede de testes pública ainda esta semana.
Numa publicação de terça-feira, Brennan Watt, CEO da Anza, deu a entender que a atualização entraria em funcionamento na rede de testes na Época 1042, prevista para daqui a menos de 2 dias, de acordo com os dados de Solana Beach.
Esta medida marca o primeiro passo formal numa migração que acabará por substituir o TowerBFT, o sistema de consenso existente da Solana, pelo Alpenglow. A atualização já está em funcionamento há mais de 4 meses num cluster dedicado da comunidade, onde os operadores ensaiaram repetidamente o processo de migração.
De 12,8 segundos para 150 milissegundos
A principal alteração do Alpenglow diz respeito à rapidez com que a Solana atinge a finalidade, o ponto em que a rede considera uma transação irreversível ao abrigo das suas regras de consenso.
A Anza estima que o Alpenglow possa reduzir a finalidade de cerca de 12,8 segundos para aproximadamente 100 a 150 milissegundos. Isso poderá alterar a forma como as bolsas, as pontes e os comerciantes tratam as transações da Solana, uma vez que estes serviços aguardam frequentemente a finalidade antes de creditar depósitos, libertar ativos ou confirmar pagamentos.
A atualização substitui o TowerBFT pelo Votor. Em vez de registar os votos de consenso como transações na blockchain, os validadores trocam votos diretamente. O Votor pode finalizar um bloco através de uma de duas vias de votação. Uma via é concluída após uma ronda quando 80% da participação participa, enquanto a outra utiliza duas rondas quando a participação atinge 60%. A remoção da votação na cadeia também liberta espaço no bloco atualmente consumido pelo tráfego de consenso.
Como a Solana irá mudar de consenso sem interromper o funcionamento
O Alpenglow não requer uma nova cadeia, reinício da rede nem migração de tokens. A Solana irá mudar o consenso enquanto a rede ativa continua a funcionar.
A migração segue quatro etapas. Primeiro, o gatilho da funcionalidade Alpenglow é ativado no limite de uma época. Nada é migrado imediatamente.
Em seguida, 5 000 slots mais tarde, chega o limite de migração. Os blocos deixam de transportar transações dos utilizadores e passam a conter apenas votos. Isto cria um ponto de reversão seguro, uma vez que os validadores podem descartar blocos após o limite sem perderem as transações dos utilizadores.
Os validadores continuam a executar o TowerBFT até que um bloco receba votos de 82 % da participação. O último antepassado desse bloco antes do limite torna-se o bloco génese do Alpenglow.
Os validadores assinam então um voto de génese BLS. Assim que 82% da participação contribuir, o certificado de génese é formado.
Por fim, os validadores revertem tudo o que se segue ao bloco génese, entregam o consenso ao Votor e retomam o processamento das transações dos utilizadores. O TowerBFT é desativado, enquanto o Alpenglow assume a partir do bloco génese.
O Agave 4.3 lidera o primeiro teste
Os validadores que participam na migração da rede de teste têm de executar o Agave v4.3.0. A Anza recomendou o Agave v4.3 para todos os validadores da Mainnet-beta a 21 de setembro, após uma implementação faseada que abrangeu inicialmente os operadores que representavam 10% da participação e, posteriormente, 25%.
O calendário atual da Anza indica 28 de setembro como data provisória para ativar as funcionalidades incluídas no Agave 4.3 na Mainnet-beta. No entanto, isso não representa uma data confirmada para o lançamento da mainnet do Alpenglow.
O Firedancer não suporta a migração para o Alpenglow
O Firedancer e o Frankendancer não suportam, atualmente, a migração para o Alpenglow. Os operadores da Testnet que utilizam qualquer um destes clientes têm de mudar para o Agave v4.3.0 antes da ativação do «feature gate».
A situação também suscitou preocupações quanto à diversidade de clientes. Mike MacCana, responsável pelas relações com desenvolvedores na QuickNode, manifestou preocupação com o facto de a rede depender de um único cliente durante a migração.
A equipa do Firedancer planeia encerrar o suporte ao Frankendancer quando o Alpenglow chegar à mainnet da Solana, o que se prevê que aconteça com a v4.3, alegando o peso da sua manutenção e segurança. Em vez disso, a equipa irá concentrar-se no cliente Firedancer completo.
Timothy Garcia, responsável pelas relações com os validadores da Fundação Solana, descreveu a ativação da rede de testes como o fim de uma era para o Frankendancer, ao mesmo tempo que reconheceu que o cliente teve um impacto significativo no ecossistema.
O que se segue
Após a rede de testes, o Alpenglow passará pela Devnet antes de chegar à Mainnet-beta. Cada cluster deve executar o mesmo processo de migração antes do início da fase seguinte.
A atualização também permanece separada das melhorias no tempo de slot da Solana. O tempo de slot da Solana baixou recentemente para 250 milissegundos ao abrigo do SIMD-0525, enquanto uma fase futura tem como objetivo os 200 milissegundos.
O Alpenglow, por sua vez, altera a rapidez com que os validadores alcançam a finalidade. Se a migração for bem-sucedida em cada fase, a Solana avançará para uma rede onde a finalidade dos blocos poderá ocorrer em cerca de 150 milissegundos, sem alterar a forma como os utilizadores enviam transações ou como as aplicações as executam.
Leia mais no SolanaFloor
A X adiciona um botão «Negociar» aos Cashtags, colocando o $BTC e o $SOL à distância de um clique para os utilizadores dos EUA
Cryptopunks, Boogles e zkSnarks registam milhões em volume de negociação à medida que os mercados de NFT reavivam
Como negociar na Solana como um profissional
