A Solana moveu sua atualização de consenso Alpenglow em direção à implantação em testnet pública enquanto os desenvolvedores se preparam para testar um design destinado a reduzir a finalidade das transações de aproximadamente 13 segundos para cerca de 150 milissegundos.
Resumo
- A atualização Alpenglow da Solana está se movendo para a testnet pública com o objetivo de reduzir a finalidade das transações de aproximadamente 13 segundos para cerca de 150 milissegundos.
- O Alpenglow substitui o TowerBFT pelo Votor, permitindo que os validadores cheguem a um acordo por meio de uma ou duas rodadas de votação direta.
- O Agave 4.3 é necessário para o teste, enquanto o Firedancer e o Frankendancer ainda não suportam o Alpenglow.
- 28 de setembro está listado para ativação provisória do recurso Agave 4.3 na mainnet, mas não é uma data de lançamento confirmada do Alpenglow.
De acordo com o github, a fase de testnet permitirá que os desenvolvedores testem a migração no ambiente de testes estabelecido da Solana antes que o sistema de consenso possa ser considerado para a rede principal.
Finalidade refere-se ao ponto em que uma transação se torna irreversível sob as regras de consenso da rede. As exchanges normalmente esperam pela finalidade antes de creditar depósitos, enquanto as pontes blockchain a utilizam antes de liberar ativos em outra rede.
A Solana atualmente depende do TowerBFT para consenso, com validadores registrando votos onchain e acumulando votos suficientes em 32 slots antes que um bloco atinja a 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 remove a sequência mais longa de votos de consenso onchain exigida sob o TowerBFT, deixando a execução de transações em grande parte inalterada para aplicativos e usuários.
Solana Alpenglow entra na testnet pública
O Alpenglow já passou mais de quatro meses operando em um cluster comunitário menor criado especificamente para testar o sistema de consenso. Mover a atualização para a testnet pública 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 fundos da mainnet em risco.
A Anza moveu o Alpenglow pela primeira vez para testes de validadores comunitários em maio, descrevendo a atualização como a maior mudança de consenso na história da Solana. Como o crypto.news relatou anteriormente, o cluster comunitário permitiu que os operadores de validadores testassem o novo design de consenso antes da implantação em toda a infraestrutura de testes existente da Solana.
O Votor foi projetado para alcançar a 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 houver participação de stake suficiente, enquanto uma segunda rodada fornece outra rota para a finalidade sob menor participação.
O resultado esperado é uma redução acentuada do tempo de finalidade existente da Solana. A Anza estimou a finalidade mediana em cerca de 150 milissegundos, com simulações anteriores colocando-a em até 100 milissegundos sob condições favoráveis.
Os desenvolvedores não alteraram como os aplicativos executam transações como parte da atualização. Os 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 concordam sobre o estado permanente da blockchain.
Agave 4.3 carrega o código do Alpenglow
Os validadores que participam do teste do Alpenglow precisam executar o Agave 4.3, a versão mais recente do software principal 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 implantação havia passado anteriormente por estágios controlados, primeiro pedindo aos operadores responsáveis por 10% do stake da mainnet que atualizassem antes de expandir a recomendação para 25%.
O desenvolvimento do Alpenglow tem estado vinculado aos lançamentos do Agave por meses. Em agosto, a meta de finalidade de 150 milissegundos era esperada para chegar através do Agave 4.3 depois que o código subjacente do Alpenglow já havia sido incluído para testes na versão 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 da mainnet. A Anza afirma que suas datas de lançamento estão sujeitas a alterações, enquanto seu rastreador de feature gate ainda listava a ativação da testnet do Alpenglow 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 têm avançado por cronogramas de ativação separados. A finalidade de transação, a produção de slots e a capacidade de transação são controladas por mudanças de rede diferentes, embora cada uma possa afetar a rapidez com que os aplicativos interagem com a Solana.
A Solana já reduziu os tempos de slot para 250ms
A Solana recentemente reduziu seu tempo de slot alvo de 300 milissegundos para 250 milissegundos sob o SIMD-0525, levando a rede a uma meta de quatro slots por segundo.
A atualização de slot para 250 milissegundos reduziu a janela de líder de quatro slots de cada validador de 1,2 segundos para um segundo. Os limites de processamento da rede foram ajustados juntamente com os slots mais curtos, o que significa que a mudança não aumentou a capacidade geral de processamento na mesma proporção.
Um estágio final sob o SIMD-0525 tem como meta slots de 200 milissegundos, o que levaria a rede a cinco slots alvo por segundo. Os desenvolvedores não definiram uma data confirmada de ativação na mainnet para esse estágio.
O tempo de slot e a finalidade medem partes diferentes da rede. O tempo de slot determina com que frequência a Solana pode produzir novos slots, enquanto o Alpenglow muda a forma como os validadores chegam a um acordo de que um bloco é irreversível.
A Solana iniciou a atual sequência de reduções de slot em agosto, quando sua meta caiu para 350 milissegundos em relação à 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.
O Firedancer permanece fora do primeiro teste do Alpenglow
O Firedancer e o Frankendancer, clientes validadores desenvolvidos pela Jump Crypto, atualmente não suportam o teste do Alpenglow, deixando a migração inicial dependente do Agave.
A diversidade de clientes oferece 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 afeta necessariamente 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 inicialmente recomendou uma implantação gradual enquanto as auditorias de segurança continuavam, com o cliente construído de forma independente destinado a reduzir a dependência das implementações de validadores existentes da Solana.
O Frankendancer serve como uma implementação híbrida que combina componentes do Firedancer com o software existente da Solana. Nenhuma das implementações está listada como compatível com o recurso pendente SIMD-0326 Alpenglow no rastreador atual de feature gate da Anza.
O Agave 4.3 é, portanto, o cliente compatível para a primeira migração pública para a testnet. O rastreador da Anza lista o Alpenglow como uma ativação de testnet pendente sob o SIMD-0326, enquanto os campos de suporte para Firedancer e Frankendancer permanecem marcados como indisponíveis.
