A Solana reduziu seu tempo de slot alvo de 400 milissegundos para 350ms pela primeira vez desde o lançamento da rede, iniciando um plano de quatro etapas que pode eventualmente reduzir os slots para 200ms.
Resumo
- A Solana reduziu seu tempo de slot alvo de 400ms para 350ms pela primeira vez desde o lançamento da rede.
- A mudança é a primeira etapa do SIMD-0525, que planeja reduções adicionais para 300ms, 250ms e 200ms.
- Slots mais curtos são projetados para reduzir a latência de confirmação enquanto os limites de recursos da rede são ajustados proporcionalmente.
- As etapas restantes são direcionadas para o Agave v4.2, embora o cronograma de ativação permaneça provisório.
O vice-presidente de tecnologia da Solana Foundation, Jacob Creech, anunciou a mudança em 21 de agosto, dizendo que a rede havia entrado em "uma nova era de 350ms" antes de acrescentar: "Próxima parada, 300ms."
Os tempos médios de slot estavam em torno de 360ms no momento da escrita, de acordo com o explorador de tempo de slot da Solana, em comparação com o alvo original de 400ms da rede.
A mudança é o primeiro passo sob o SIMD-0525, uma proposta de melhoria da Solana que introduz quatro configurações de slot progressivamente mais curtas em 350ms, 300ms, 250ms e 200ms. A proposta foi aprovada e mesclada em 14 de maio.
Em vez de mover imediatamente para o alvo final, a Solana planeja ativar cada redução separadamente, dando aos operadores de validadores e desenvolvedores de clientes a chance de testar o comportamento da rede à medida que a produção de blocos se torna mais rápida.
O tempo de slot da Solana começa sua jornada em direção a 200ms
A Solana Foundation disse em junho que reduzir os slots de 400ms para 200ms diminuiria a latência e permitiria que as confirmações chegassem aos usuários mais rapidamente.
Sob o SIMD-0525, a primeira mudança de feature gate altera o alvo de slot para 350ms. Ativações posteriores o trariam para 300ms, depois 250ms e finalmente 200ms.
Todas as quatro etapas estão atualmente direcionadas para o Agave v4.2, o cliente validador desenvolvido pela Anza, embora o cronograma de implementação permaneça provisório e possa mudar dependendo dos testes.
Slots mais curtos significam que as oportunidades de produção de blocos passam entre os validadores com mais frequência. O SIMD-0525 mantém os 64 ticks por slot da rede e sua janela de líder de quatro slots, mas a quantidade de tempo real representada por cada janela de líder cai a cada redução.
No alvo anterior de 400ms, quatro slots davam a um líder uma janela nominal de 1,6 segundos. Um slot de 350ms reduz esse número para 1,4 segundos, enquanto 300ms o reduziria para 1,2 segundos. No alvo final de 200ms, uma janela de quatro slots duraria cerca de 800ms.
A proposta diz que reduzir a quantidade de tempo controlada por um líder também pode reduzir o período durante o qual as transações poderiam ser atrasadas ou reordenadas antes que outro validador receba a oportunidade de produzir blocos.
SIMD-0525 não simplesmente permite que a rede execute o dobro de trabalho após passar de 400ms para 200ms. Os limites de recursos são ajustados proporcionalmente à medida que a duração do slot diminui, para que as demandas de processamento em um determinado período não aumentem apenas porque mais slots estão sendo produzidos.
Na linha de base original de 60 milhões de unidades de computação usada na proposta, o limite por slot cairia para 52,5 milhões de CUs em 350ms, 45 milhões em 300ms, 37,5 milhões em 250ms e 30 milhões em 200ms.
Slots mais rápidos mudam confirmações e tempo de época
A latência de confirmação é uma das principais áreas visadas pela mudança, porque a Solana mede várias partes da operação da rede em slots.
Com os validadores passando pelos slots mais rapidamente, os limites de confirmação baseados em slots podem ser alcançados em menos tempo real. Aplicativos que usam números de slot para determinar quão recente é a informação do blockchain também podem receber intervalos de tempo mais precisos.
O SIMD-0525 identifica usuários de oráculos e formadores de mercado automatizados entre os aplicativos que poderiam se beneficiar dos intervalos mais curtos, especialmente quando as decisões dependem da idade dos dados on-chain.
A duração da época também cairá porque a Solana planeja manter 432.000 slots por época.
Uma época com slots de 400ms tem uma duração nominal de cerca de 48 horas. A mudança para 350ms reduz isso para aproximadamente 42 horas, enquanto 300ms traria uma época para cerca de 36 horas. A 250ms, o número cai para cerca de 30 horas, antes de atingir aproximadamente 24 horas se slots de 200ms forem ativados.
Os cálculos anuais de slots da Solana são ajustados junto com a mudança para que a emissão do protocolo permaneça baseada no tempo do mundo real, em vez de aumentar simplesmente porque mais slots ocorrem a cada ano.
O Ticket de Admissão de Validador proposto sob o sistema de consenso Alpenglow da Solana também é projetado para escalar à medida que as épocas ficam mais curtas. O SIMD-0525 especifica que um custo de 1,6 SOL por época a 400ms diminuiria para 1,4 SOL a 350ms, seguido por 1,2 SOL, 1 SOL e 0,8 SOL nas etapas subsequentes.
A proposta diz que os ajustes são destinados a manter o custo do validador em aproximadamente 0,8 SOL por dia, apesar das épocas mais curtas.
As melhorias de desempenho da Solana vão além dos tempos de slot
A implementação do tempo de slot ocorre enquanto os desenvolvedores da Solana trabalham em várias mudanças na infraestrutura de validador e consenso da rede.
Como relatado anteriormente pelo crypto.news, o Alpenglow entrou em testes com validadores da comunidade em maio, depois que a Anza implantou o design de consenso em um cluster de teste.
O Alpenglow é projetado para trazer tempos de confirmação para cerca de 150ms, removendo o Proof of History e transações de voto on-chain do processo central de consenso da Solana. A Anza chamou a atualização planejada de a maior mudança de consenso na história da Solana.
O sistema introduz um design de votação chamado Votor, que usa comunicação off-chain entre validadores e agregação de assinaturas para alcançar consenso. Seu desenvolvimento é separado do SIMD-0525, embora ambos os projetos foquem em reduzir a quantidade de tempo necessária para operações de rede.
O software de validador também se tornou mais diversificado durante 2026. O lançamento do Firedancer na mainnet da Jump Crypto começou a produzir blocos em maio após anos de desenvolvimento, fornecendo uma alternativa construída independentemente para as implementações existentes de validador da Solana.
A Jump Crypto aconselhou os validadores na época a não migrarem para o Firedancer em escala até que as auditorias de segurança fossem concluídas. O cliente foi desenvolvido tanto para melhorar o desempenho quanto para reduzir o risco criado quando uma blockchain depende fortemente de uma única implementação de software de validador.
Mais tarde naquele mês, a Coinbase divulgou uma configuração multi-cliente usando Jito e Firedancer em sua infraestrutura de validador da Solana. Sua arquitetura de validador suportava aproximadamente 40,48 milhões de SOL em stake na época, ou cerca de 9,52% do fornecimento em stake da rede, de acordo com o relatório de desempenho do validador do primeiro trimestre da exchange.
A Solana introduziu outra mudança no nível da rede em julho, quando lançou uma estrutura de governança on-chain que permite que validadores façam votos ponderados por stake em Propostas de Governança da Solana. Sob o novo processo de governança, propostas que recebem 15% de apoio inicial passam por um processo de 11 épocas contendo discussão, um snapshot de stake e votação formal.
Uma proposta é aprovada quando os votos a favor representam pelo menos 66,67% do stake participante "A favor" e "Contra", enquanto mudanças técnicas ainda podem passar pelo processo SIMD existente sem primeiro receber um voto de proposta de governança.
A próxima redução de slot levaria a Solana para 300ms
Com a configuração de 350ms agora ativa, o SIMD-0525 identifica 300ms como o próximo estágio na sequência.
A mudança reduziria a janela nominal de líder de quatro slots de 1,4 segundos para 1,2 segundos e traria uma época de cerca de 42 horas para 36 horas.
Ativações adicionais de recursos moveriam então a Solana para 250ms e 200ms. Cada configuração é calculada a partir dos valores de linha de base da rede, em vez de usar os limites arredondados do estágio anterior, um design destinado a evitar que diferenças de arredondamento se acumulem em reduções sucessivas.
Os testes da infraestrutura da Solana continuaram enquanto essas etapas estão sendo preparadas. Durante julho, a atividade da rede também atingiu níveis recordes à medida que os ativos tokenizados se expandiram na Solana, com atividade de ações tokenizadas contribuindo para o aumento do uso em toda a rede.
Para o SIMD-0525, no entanto, cada redução de slot restante ainda requer a ativação do recurso correspondente. Após a configuração de 350ms recém-ativada, Creech identificou 300ms como o próximo alvo da rede.
