
A Solana reduziu seu tempo de slot alvo de 300 milissegundos para 250 milissegundos, aumentando a taxa na qual a rede produz slots em quase 17%, sem elevar seu teto de processamento geral na mesma proporção.
De acordo com dados da blockchain, a nova configuração entrou em vigor em 18 de setembro e leva a Solana a quatro slots alvos por segundo, em comparação com aproximadamente 3,3 na configuração anterior de 300ms. A mudança é a terceira fase do SIMD-0525, que foi projetado para reduzir gradualmente os tempos de slot da configuração original de 400ms da rede para um alvo final de 200ms.
Um slot é o período no qual um validador designado pode produzir um bloco. Encurtar esse período dá a carteiras, exchanges e aplicativos de negociação atualizações mais frequentes sobre o estado da rede.
Os validadores continuam a servir como líderes por quatro slots consecutivos. Com cada slot agora visando 250ms, a janela nominal de líder de um validador caiu de 1,2 segundos na configuração anterior para um segundo.
A Solana iniciou a implementação atual em agosto, quando reduziu seu tempo de slot de 400ms para 350ms pela primeira vez desde o lançamento da rede, conforme relatado anteriormente pelo crypto.news.
O SIMD-0525 dividiu o processo em quatro estágios: 350ms, 300ms, 250ms e 200ms, em vez de passar diretamente para o alvo final. Cada redução requer uma ativação de funcionalidade separada, permitindo que desenvolvedores e operadores de validadores avaliem o desempenho da rede antes de prosseguir.
A 250ms, quatro oportunidades de slot chegam a cada segundo. Os intervalos mais curtos podem fornecer aos aplicativos uma visão mais atual das transações e do estado da rede, enquanto a produção de blocos passa de um validador para outro mais rapidamente.
Mercados baseados em oráculos e criadores de mercado automatizados (AMMs) estão entre os aplicativos cobertos pela proposta, pois suas operações podem depender da idade dos dados on-chain. Um intervalo mais curto reduz a quantidade de tempo entre as atualizações da rede, enquanto os usuários podem ver as mudanças no status da transação mais rapidamente.
Para swaps, o tempo mais curto pode estreitar o período entre o envio de uma transação e sua chegada à rede. A proposta subjacente identifica confirmações mais rápidas e atualizações mais frequentes como benefícios da redução da duração do slot.
A mudança não aumenta a capacidade bruta de transações da Solana em quase 17%.
Sob o SIMD-0525, os limites de recursos são reduzidos em proporção à duração do slot. Mais slots são produzidos em um determinado período, mas cada slot tem permissão para carregar menos computação e dados, mantendo a quantidade de trabalho que a rede pode processar em tempo real aproximadamente no mesmo nível.
No baseline de 60 milhões de unidades de computação usado pela proposta, o limite por slot diminui à medida que o relógio acelera. A configuração de 250ms corresponde a um limite de 37,5 milhões de unidades de computação, enquanto o estágio planejado de 200ms o reduziria para 30 milhões.
Os provedores de infraestrutura agora têm mais blocos individuais para processar e armazenar, embora o teto de processamento geral permaneça amplamente inalterado.
Aplicativos que calculam o tempo decorrido multiplicando números de slot por uma duração de slot fixa podem precisar considerar o relógio mais rápido. Os hashes de bloco expiram mais cedo em tempo real à medida que os slots avançam mais rapidamente, deixando menos tempo para processos de transação envolvendo assinaturas offline ou aprovações humanas atrasadas.
O tempo das épocas muda pela mesma razão. A Solana mantém cada época fixada em 432.000 slots, o que significa que uma época se torna mais curta à medida que a duração de cada slot diminui.
No alvo anterior de 300ms, uma época durava aproximadamente 36 horas. A configuração de 250ms reduz a duração esperada para cerca de 30 horas. Uma mudança para o alvo final de 200ms a reduziria para aproximadamente 24 horas.
As reduções escalonadas de slot da Solana fazem parte do lançamento do Agave 4.2. O lançamento do cliente começou a ativar várias mudanças na rede em agosto, incluindo aluguel de armazenamento on-chain mais baixo, transações maiores e o caminho para slots de 200ms.
O design escalonado inclui uma salvaguarda ligada às taxas de salto de bloco. O progresso em direção à próxima configuração de slot pode ser interrompido se as taxas de salto aumentarem além do nível que os desenvolvedores consideram aceitável, dando tempo aos validadores para operar sob cada configuração antes que outra redução seja ativada.
Nenhuma data para a mainnet foi definida para o estágio de 200ms.
O tempo de slot é apenas uma parte das mudanças de rede que estão sendo implementadas através do Agave.
A Solana introduziu separadamente a Transação V1, que eleva o tamanho máximo da transação serializada de 1.232 bytes para 4.096 bytes. O formato de transação maior pode acomodar operações com grande volume de dados, como provas de conhecimento zero e instruções complexas de múltiplas assinaturas dentro de uma única transação.
A Transação V1 é opcional, enquanto transações legadas e de versão zero continuam sendo suportadas. Aplicativos que leem blocos precisam suportar o formato mais recente para lidar corretamente com transações V1.
O aumento do tamanho da transação é separado do SIMD-0525. Transações individuais maiores, portanto, não determinam o relógio do slot, enquanto slots mais curtos não aumentam automaticamente o tamanho máximo de uma transação.
A Solana tem ativado as mudanças independentemente por meio de portões de funcionalidade. A estrutura permite que uma atualização prossiga sem exigir que as outras funcionalidades incluídas no Agave 4.2 sejam ativadas ao mesmo tempo.
O estágio final sob o SIMD-0525 reduziria o tempo de slot alvo de 250ms para 200ms, levando a rede a cinco slots alvos por segundo.
A janela de líder de validador de quatro slots cairia consequentemente para aproximadamente 800ms. A duração da época diminuiria de cerca de 30 horas sob a configuração atual de 250ms para aproximadamente 24 horas.
Os desenvolvedores da Solana não forneceram uma data de ativação na mainnet para a redução final. O progresso depende do comportamento da rede sob a configuração atual, incluindo se os validadores conseguem manter taxas de salto de bloco aceitáveis.
As reduções de slot são separadas do Alpenglow, o redesenho de consenso planejado da Solana. O Alpenglow pretende substituir o TowerBFT por um sistema de votação chamado Votor e remover as transações de voto on-chain do processo de consenso central da rede.
A atualização de consenso do Alpenglow visa uma finalidade de aproximadamente 150ms. Seu código foi incluído para testes, enquanto a implantação na mainnet foi vinculada ao Agave 4.3, em vez dos portões de funcionalidade de tempo de slot usados para o SIMD-0525.
O Alpenglow entrou em testes de validadores da comunidade no início de 2026, permitindo que os operadores executassem o design de consenso em um cluster de teste antes da implantação na mainnet. Anza descreveu o sistema como a maior mudança de consenso na história da Solana.
Para o SIMD-0525, a rede permanece no estágio de 250ms até que os desenvolvedores ativem o portão de funcionalidade final. A configuração de 200ms completaria uma implementação que começou em 400ms e passou por 350ms, 300ms e 250ms, enquanto reduzia os limites de recursos em cada etapa.








