Solana aproxima-se de slots de 200ms após última atualização de velocidade

De acordo com dados da blockchain, a nova configuração entrou em vigor a 18 de setembro e leva a Solana a quatro slots por segundo, em comparação com cerca de 3,3 na configuração anterior de 300ms. A alteração é a terceira fase do SIMD-0525, que foi concebido para reduzir gradualmente os tempos de slot desde a configuração original de 400ms da rede até um objetivo final de 200ms.

Um slot é o período em que um validador designado pode produzir um bloco. Encurtar esse período dá às carteiras, exchanges e aplicações de trading atualizações mais frequentes sobre o estado da rede.

Os validadores continuam a servir como líderes durante quatro slots consecutivos. Com cada slot agora definido para 250ms, a janela nominal de líder de um validador caiu de 1,2 segundos na configuração anterior para um segundo.

Tempo de slot da Solana atinge 250ms

A Solana iniciou a implementação atual em agosto, quando reduziu o tempo de slot de 400ms para 350ms pela primeira vez desde o lançamento da rede, como o crypto.news noticiou anteriormente.

O SIMD-0525 dividiu o processo em quatro fases de 350ms, 300ms, 250ms e 200ms, em vez de avançar diretamente para o objetivo final. Cada redução requer uma ativação de funcionalidade separada, permitindo que os programadores e operadores de validadores avaliem o desempenho da rede antes de avançar.

A 250ms, surgem quatro oportunidades de slot por segundo. Os intervalos mais curtos podem dar às aplicações uma visão mais atual das transações e do estado da rede, ao mesmo tempo que passam a produção de blocos de um validador para outro mais cedo.

Os mercados baseados em oráculos e os formadores de mercado automatizados estão entre as aplicações abrangidas pela proposta, porque as suas operações podem depender da idade dos dados onchain. Um intervalo mais curto reduz o tempo entre atualizações da rede, enquanto os utilizadores podem ver as alterações de estado das transações mais cedo.

Para swaps, o tempo mais curto pode reduzir o período entre a submissão de uma transação e a 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 alteração não aumenta a capacidade bruta de transações da Solana em quase 17%.

No âmbito do SIMD-0525, os limites de recursos são reduzidos proporcionalmente à duração do slot. São produzidos mais slots num determinado período, mas cada slot pode transportar menos computação e dados, mantendo a quantidade de trabalho que a rede pode processar em tempo real aproximadamente ao mesmo nível.

Na linha de base de 60 milhões de unidades de computação utilizada 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 a fase planeada de 200ms o reduziria para 30 milhões.

Blocos mais rápidos alteram os requisitos de infraestrutura da Solana

Os fornecedores de infraestrutura têm agora mais blocos individuais para processar e armazenar, embora o teto de processamento em tempo real permaneça praticamente inalterado.

As aplicações que calculam o tempo decorrido multiplicando os números dos slots por uma duração fixa de slot podem precisar de ter em conta o relógio mais rápido. Os blockhashes expiram mais cedo em tempo real à medida que os slots avançam mais rapidamente, deixando menos tempo para processos de transação que envolvem assinatura offline ou aprovações humanas demoradas.

O tempo de época muda pela mesma razão. A Solana mantém cada época fixa em 432.000 slots, o que significa que uma época se torna mais curta à medida que a duração de cada slot diminui.

No objetivo anterior de 300ms, uma época durava cerca de 36 horas. A configuração de 250ms reduz a duração esperada para cerca de 30 horas. Uma mudança para o objetivo final de 200ms reduzi-la-ia para aproximadamente 24 horas.

As reduções faseadas de slots da Solana fazem parte da implementação do Agave 4.2. O lançamento do cliente começou a ativar várias alterações de rede em agosto, incluindo rendas de armazenamento onchain mais baixas, transações maiores e o caminho para slots de 200ms.

O design faseado inclui uma salvaguarda ligada às taxas de saltos de blocos. O progresso para a próxima configuração de slot pode ser interrompido se as taxas de saltos subirem acima do nível que os programadores consideram aceitável, dando aos validadores tempo para operar sob cada configuração antes de outra redução ser ativada.

Não foi definida nenhuma data de mainnet para a fase de 200ms.

As atualizações da Solana vão além de slots mais rápidos

O tempo de slot é apenas uma parte das alterações de rede que estão a ser implementadas através do Agave.

A Solana introduziu separadamente a Transaction V1, que aumenta o tamanho máximo de transação serializada de 1.232 bytes para 4.096 bytes. O formato de transação maior pode acomodar operações com muitos dados, como provas de conhecimento zero e instruções multisig complexas, numa única transação.

A Transaction V1 é opcional, enquanto as transações legadas e de versão zero continuam a ser suportadas. As aplicações que leem blocos precisam de 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 vindo a ativar as alterações de forma independente através de feature gates. 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.

Solana continua a visar slots de 200ms

A fase final do SIMD-0525 reduziria o tempo de slot alvo de 250ms para 200ms, levando a rede a cinco slots alvo por segundo.

Uma janela de líder de validador de quatro slots cairia consequentemente para cerca de 800ms. A duração da época diminuiria de cerca de 30 horas na configuração atual de 250ms para aproximadamente 24 horas.

Os programadores 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 saltos de blocos aceitáveis.

As reduções de slots são separadas do Alpenglow, o redesenho de consenso planeado da Solana. O Alpenglow destina-se a substituir o TowerBFT por um sistema de votação chamado Votor e a remover as transações de voto onchain do processo de consenso central da rede.

A atualização de consenso Alpenglow visa uma finalidade de cerca de 150ms. O seu código foi incluído para testes, enquanto a implementação na mainnet foi associada ao Agave 4.3, em vez dos feature gates de tempo de slot usados para o SIMD-0525.

O Alpenglow entrou em testes comunitários de validadores no início de 2026, permitindo que os operadores executem o design de consenso num cluster de teste antes da implementação na mainnet. A Anza descreveu o sistema como a maior mudança de consenso na história da Solana.

Para o SIMD-0525, a rede permanece na fase de 250ms até que os programadores ativem o feature gate final. A configuração de 200ms completaria uma implementação que começou em 400ms e passou por 350ms, 300ms e 250ms, reduzindo os limites de recursos em cada passo.