Solana acabou de reduzir em 50 milissegundos o tempo que os validadores levam para produzir um bloco, e é a primeira vez que a rede faz isso. A atualização do tempo de slot da Solana entrou em vigor na mainnet na sexta-feira, reduzindo o tempo de slot alvo de 400 milissegundos para 350 milissegundos e dando início ao que os desenvolvedores descrevem como uma marcha em estágios, época por época, rumo a uma meta muito mais rápida de 200 milissegundos.
Summary
Pontos-chave
- O tempo de slot da mainnet da Solana caiu de 400 milissegundos para 350 milissegundos, a primeira redução desse tipo desde o lançamento da rede.
- A mudança foi ativada como funcionalidade SIMD-0525 no slot 440.208.000 na época 1019, após ter sido incorporada ao código em 14 de maio.
- Mais três reduções de 50 milissegundos, para 300, 250 e finalmente 200 milissegundos, estão planejadas por meio de gates de funcionalidades separados, cada uma condicionada a taxas saudáveis de blocos pulados.
- A atualização é rotulada como uma mudança incompatível (breaking change), e a Solana afirma que os ajustes de indexação para ferramentas de terceiros ainda estão sendo definidos.
- Jacob Creech, vice-presidente de tecnologia da Solana Foundation, confirmou que 300 milissegundos é o próximo alvo no roadmap.
Solana Reduz o Tempo de Slot da Mainnet pela Primeira Vez
A resposta central é simples: a Solana acabou de fazer com que os blocos cheguem mais rápido, sem alterar a estrutura subjacente da rede. Esta é a primeira redução do tempo de slot desde a criação da Solana, e ela encurta diretamente a janela que cada validador tem para montar e transmitir um bloco de transações.
Detalhes da Ativação e Efeitos Imediatos
A funcionalidade, rastreada como SIMD-0525, entrou em operação na Mainnet Beta no slot 440.208.000 na época 1019, de acordo com o próprio explorador da Solana. A proposta em si foi incorporada aos documentos de melhoria da rede em 14 de maio, dando aos desenvolvedores uma margem de vários meses para preparar o software dos validadores antes de acionar a mudança.
O efeito prático aparece quase imediatamente na velocidade de confirmação. Uma verificação pontual relatada pelo The Block constatou que um intervalo de 1.000 slots pouco antes da mudança levou 415 segundos para ser concluído, em comparação com 368 segundos para um intervalo semelhante após a ativação da atualização na época 1020 — uma queda no mundo real consistente com a nova meta de 350 milissegundos.
Como cada época na Solana ainda contém 432.000 slots, slots mais rápidos se traduzem diretamente em épocas mais rápidas. O que antes levava aproximadamente 48 horas para ser concluído agora termina em cerca de 42 horas, embora nada na contagem interna da época tenha mudado.
Fundamentos Técnicos que Possibilitaram a Atualização
Nada disso teria sido possível sem o trabalho no lado do cliente validador. A Solana atribuiu a atualização a melhorias no Turbine, a camada de propagação de blocos da rede, e no Replay, o processo que os validadores usam para verificar e votar em blocos recebidos, como os habilitadores técnicos que tornaram um tempo de slot mais curto viável em escala.
Esses dois sistemas precisaram ficar mais rápidos antes que a rede pudesse comprimir com segurança o tempo disponível para que um líder finalize um bloco, o repasse via Gulf Stream para o próximo líder e permita que o restante do conjunto de validadores o reexecute (replay) e vote. Encolher essa janela sem essas melhorias provavelmente teria elevado as taxas de blocos pulados e desestabilizado a produção de blocos.
Abordagem em Fases para Novas Reduções no Tempo de Slot
A Solana não está indo diretamente ao ponto final. Em vez disso, a rede está avançando por quatro estágios separados, de 400 milissegundos até 200 milissegundos, com cada etapa exigindo sua própria ativação e sua própria verificação de saúde antes que a próxima possa ser acionada.
Mecanismo de Feature Gate para Futuras Atualizações
Cada redução adicional de 50 milissegundos, seja para 300, 250 ou 200 milissegundos, será acionada por meio de um feature gate separado ativado em uma época posterior, em vez de um único interruptor geral. Essa estrutura dá à Solana Foundation e aos operadores de validadores espaço para observar como a rede se comporta em cada nova velocidade antes de se comprometer com a próxima redução.
A Anza, a equipe de desenvolvimento de clientes validadores que se separou da Solana Labs original, apresentou um cronograma preliminar do Agave v4.2 que mira as quatro reduções em estágios para eventual ativação na mainnet. Nenhuma data de calendário ou época específica foi definida ainda para o passo de 300 milissegundos, que é o próximo na fila.
Controles de Risco Baseados em Taxas de Blocos Pulados
É aqui que a cautela realmente aparece. A Solana Foundation tem sido explícita ao afirmar que a rede não avançará para a próxima redução do tempo de slot se as taxas de blocos pulados subirem demais — ou seja, se muitos validadores deixarem de produzir seus blocos atribuídos a tempo. Esse freio embutido é importante porque slots mais curtos comprimem todos os processos subsequentes: conclusão de blocos, propagação de transações e votação dos validadores passam a ter menos tempo de relógio para ocorrer corretamente.
Por que isso importa: um rollout em estágios com um gatilho baseado na taxa de blocos pulados transforma efetivamente a velocidade em uma variável monitorada, em vez de uma promessa fixa. Se o hardware ou o software dos validadores não conseguir acompanhar a 300 milissegundos, a rede pode simplesmente pausar nesse ponto em vez de seguir adiante e arriscar instabilidade.
Implicações Mais Amplas e Impacto na Rede
Slots mais rápidos não significam automaticamente uma rede mais rápida em todos os sentidos, e essa distinção é importante para quem acompanha as alegações de throughput da Solana. Os validadores lidam com slots com mais frequência, mas cada slot individual carrega menos trabalho, de modo que a mudança melhora principalmente a latência e a velocidade de confirmação, em vez da capacidade bruta de transações. Separadamente, a Solana elevou seu limite de unidades de computação para 100 milhões em julho de 2025, uma atualização distinta voltada a expandir quanto trabalho cabe em cada bloco.
Status de Mudança Incompatível e Impacto na Indexação
A própria Solana classifica a atualização do tempo de slot da Solana como uma mudança incompatível (breaking change), e os ajustes de indexação necessários para ferramentas e serviços de terceiros ainda precisam ser determinados. Isso é uma lacuna notável: a documentação da própria Solana ainda descreve a duração padrão do slot como 400 milissegundos, embora o explorador da rede confirme que o primeiro feature gate de 350 milissegundos já está ativo. Desenvolvedores que constroem sobre indexadores, painéis de análise ou exploradores de blocos devem esperar alguma fricção no curto prazo enquanto as ferramentas se alinham ao novo tempo da rede.
Declarações Oficiais e Visão sobre o Caminho de Atualização
Jacob Creech, vice-presidente de tecnologia da Solana Foundation, descreveu a mudança como a primeira redução do tempo de slot da rede e confirmou que 300 milissegundos é o próximo alvo no roadmap. Nem Creech nem a página pública de upgrades da Fundação anexaram uma data firme a esse próximo passo, e o plano depende explicitamente de como a rede se comporta primeiro a 350 milissegundos.
Há também um horizonte mais longo aqui. Tempo de slot e finalidade total não são a mesma coisa — os blocos da Solana ainda levam cerca de 12,8 segundos para se tornarem totalmente irreversíveis hoje, mesmo com o novo ritmo de slots de 350 milissegundos. Uma reformulação separada, ainda em desenvolvimento, chamada Alpenglow, busca eventualmente reduzir essa janela de finalidade para cerca de 150 milissegundos, o que seria uma mudança estrutural muito maior do que as atuais reduções em estágios do tempo de slot. A rede também adicionou recentemente o cliente Firedancer da Jump Crypto, construído em uma linguagem de programação diferente do stack Agave dominante, melhorando a diversidade de clientes validadores à medida que o esforço mais amplo por velocidade continua.
Perguntas Frequentes (FAQ)
Que mudança a Solana fez recentemente em seu tempo de slot?
A Solana reduziu o tempo de slot da mainnet de 400 milissegundos para 350 milissegundos, representando a primeira redução desde a criação da rede.
Como serão gerenciadas as futuras reduções do tempo de slot?
Futuras reduções para 300, 250 e 200 milissegundos serão ativadas separadamente por meio de feature gates e dependerão de as taxas de blocos pulados não se tornarem muito altas.
A redução do tempo de slot afeta a estrutura de épocas da Solana ou os ticks por slot?
Não, a atualização não altera o número de ticks por slot, o intervalo de liderança (leader span) ou o número de slots em uma época.
Por que a atualização é considerada uma mudança incompatível (breaking change)?
A atualização é considerada incompatível porque exige mudanças de indexação para ferramentas e infraestruturas de terceiros, embora esses ajustes ainda precisem ser determinados.
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Que mudança a Solana fez recentemente em seu tempo de slot?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”A Solana reduziu o tempo de slot da mainnet de 400 milissegundos para 350 milissegundos, representando a primeira redução desde a criação da rede.”}},{“@type”:”Question”,”name”:”Como serão gerenciadas as futuras reduções do tempo de slot?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Futuras reduções para 300, 250 e 200 milissegundos serão ativadas separadamente por meio de feature gates e dependerão de as taxas de blocos pulados não se tornarem muito altas.”}},{“@type”:”Question”,”name”:”A redução do tempo de slot afeta a estrutura de épocas da Solana ou os ticks por slot?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Não, a atualização não altera o número de ticks por slot, o intervalo de liderança (leader span) ou o número de slots em uma época.”}},{“@type”:”Question”,”name”:”Por que a atualização é considerada uma mudança incompatível (breaking change)?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”A atualização é considerada incompatível porque exige mudanças de indexação para ferramentas e infraestruturas de terceiros, embora esses ajustes ainda precisem ser determinados.”}}]}
Artigo produzido com a assistência de inteligência artificial e revisado pela equipe editorial.
