A Solana avançou com sua atualização de consenso Alpenglow para implantação na testnet pública, enquanto os desenvolvedores se preparam para testar um design destinado a reduzir a finalidade das transações de cerca de 13 segundos para aproximadamente 150 milissegundos.
Segundo o GitHub, a fase de testnet permitirá que os desenvolvedores testem a migração no ambiente de testes já estabelecido da Solana antes que o sistema de consenso possa ser considerado para a rede principal.
Finalidade refere-se ao momento em que uma transação se torna irreversível sob as regras de consenso da rede. Exchanges normalmente aguardam a finalidade antes de creditar depósitos, enquanto bridges de blockchain a utilizam antes de liberar ativos em outra rede.
Atualmente, a Solana depende do TowerBFT para consenso, com validadores registrando votos on-chain e acumulando votos suficientes ao longo de 32 slots antes que um bloco atinja finalidade. O Alpenglow substitui esse processo por um protocolo chamado Votor, que permite aos validadores trocar votos diretamente.
Sob o novo design, os validadores podem chegar a um acordo após uma ou duas rodadas de votação. A mudança elimina a sequência mais longa de votos de consenso on-chain exigida pelo TowerBFT, mantendo a execução de transações em grande parte inalterada para aplicações e usuários.
O Alpenglow já passou mais de quatro meses operando em um cluster menor da comunidade criado especificamente para testar o sistema de consenso. Levar a atualização para a testnet pública já estabelecida da Solana a expõe a um grupo maior de validadores, provedores de infraestrutura e serviços já conectados à rede.
A testnet pública usa tokens sem valor monetário, permitindo que os desenvolvedores reiniciem a rede, testem procedimentos de migração e investiguem problemas sem colocar em risco os fundos da mainnet.
A Anza levou o Alpenglow pela primeira vez para testes com validadores da comunidade em maio, descrevendo a atualização como a maior mudança de consenso na história da Solana. Como a crypto.news relatou anteriormente, o cluster da comunidade permitiu que operadores de validadores testassem o novo design de consenso antes da implantação na infraestrutura de testes existente da Solana.
O Votor foi projetado para atingir finalidade por meio de um de dois caminhos de votação, dependendo da participação dos validadores. Especificações anteriores indicavam que um bloco poderia ser liquidado após uma rodada quando stake suficiente participasse, enquanto uma segunda rodada forneceria outra rota para a finalidade sob menor participação.
O resultado esperado é uma redução acentuada em relação ao tempo de finalidade atual da Solana. A Anza estimou a finalidade mediana em cerca de 150 milissegundos, com simulações anteriores apontando valores tão baixos quanto 100 milissegundos em condições favoráveis.
Os desenvolvedores não alteraram a forma como as aplicações executam transações como parte da atualização. Usuários de carteiras continuarão enviando transações pelas mesmas interfaces, enquanto as principais mudanças ocorrem na forma como os validadores se comunicam e chegam a um acordo sobre o estado permanente da blockchain.
Os validadores que participam do teste do Alpenglow precisam executar o Agave 4.3, o branch mais recente do principal software de validadores mantido pela Anza.
A Anza recomendou o Agave 4.3 para adoção geral entre os validadores da mainnet em 21 de setembro. A implementação já havia avançado anteriormente por estágios controlados, primeiro pedindo que operadores responsáveis por 10% do stake da mainnet atualizassem antes de expandir a recomendação para 25%.
O desenvolvimento do Alpenglow está vinculado aos lançamentos do Agave há meses. Em agosto, esperava-se que a meta de finalidade de 150 milissegundos chegasse por meio do Agave 4.3, depois que o código-base do Alpenglow já havia sido incluído para testes no branch anterior do software.
A data de 28 de setembro listada no cronograma do Agave 4.3 da Anza refere-se à retomada provisória da ativação de recursos na mainnet. A Anza afirma que suas datas de lançamento estão sujeitas a alterações, enquanto seu rastreador de feature gates ainda listava a ativação do Alpenglow na testnet como pendente no início da quarta-feira.
Portanto, 28 de setembro não representa uma data confirmada para o Alpenglow começar a operar na mainnet da Solana.
A distinção surge no momento em que várias atualizações de desempenho da Solana vêm avançando em cronogramas de ativação separados. A finalidade das transações, a produção de slots e a capacidade de transação são controladas por diferentes mudanças na rede, embora cada uma possa afetar a rapidez com que as aplicações interagem com a Solana.
Recentemente, a Solana reduziu seu tempo-alvo de slot de 300 milissegundos para 250 milissegundos sob o SIMD-0525, levando a rede a uma meta de quatro slots por segundo.
A atualização para slots de 250 milissegundos reduziu a janela de liderança de quatro slots de cada validador de 1,2 segundo para um segundo. Os limites de processamento da rede foram ajustados junto com os slots mais curtos, o que significa que a mudança não elevou a capacidade geral de processamento na mesma proporção.
Uma etapa final sob o SIMD-0525 mira slots de 200 milissegundos, o que levaria a rede a cinco slots-alvo por segundo. Os desenvolvedores ainda não definiram uma data confirmada de ativação na mainnet para essa etapa.
Tempo de slot e finalidade medem partes diferentes da rede. O tempo de slot determina com que frequência a Solana pode produzir novos slots, enquanto o Alpenglow altera a forma como os validadores chegam a um consenso de que um bloco é irreversível.
A Solana iniciou a atual sequência de reduções de slots em agosto, quando sua meta caiu para 350 milissegundos, ante a configuração de 400 milissegundos usada desde o lançamento da rede. O SIMD-0525 estabeleceu metas sucessivas de 350, 300, 250 e, eventualmente, 200 milissegundos.
O Alpenglow segue um caminho separado por meio do SIMD-0326 e substitui o TowerBFT pelo Votor em vez de modificar a duração de slots individuais.
Firedancer e Frankendancer, clientes validadores desenvolvidos pela Jump Crypto, atualmente não oferecem suporte ao teste do Alpenglow, deixando a migração inicial dependente do Agave.
A diversidade de clientes fornece aos validadores da Solana diferentes implementações de software para participar da mesma rede. Se clientes separados estiverem disponíveis, uma falha de software que afete uma implementação não necessariamente afetará todos os validadores.
O Firedancer começou a produzir blocos na mainnet no início deste ano após anos de desenvolvimento pela Jump Crypto. A equipe recomendou inicialmente uma implementação gradual enquanto as auditorias de segurança continuavam, com o cliente desenvolvido de forma independente destinado a reduzir a dependência das implementações de validadores já existentes da Solana.
O Frankendancer funciona como uma implementação híbrida que combina componentes do Firedancer com o software existente da Solana. Nenhuma das duas implementações aparece listada como compatível com o recurso pendente Alpenglow do SIMD-0326 no atual rastreador de feature gates da Anza.
Portanto, o Agave 4.3 é o cliente suportado para a primeira migração na testnet pública. O rastreador da Anza lista o Alpenglow como uma ativação pendente na testnet sob o SIMD-0326, enquanto os campos de suporte para Firedancer e Frankendancer continuam marcados como indisponíveis.
ETH
SOL
