A Solana passou a coordenar validadores com tempo-alvo de 250 milissegundos por slot. Cada slot representa o intervalo previsto para um validador produzir um bloco. Assim, usuários ganham mais oportunidades para incluir transações. Enquanto isso, validadores têm menos tempo para transferir a produção ao próximo líder.

A mudança entrou em vigor na epoch 1037, em 18 de setembro. O changelog de engenharia da Solana e um relatório da Solana Compass situaram a transição por volta das 05h06 UTC. Já uma amostra inicial de 20 de setembro registrou cerca de 266 ms por slot produzido. A medição considerou 60 janelas de um minuto.

Na epoch 1037, a rede ignorou cerca de 0,05% dos slots programados. No entanto, esse período curto oferece apenas uma leitura inicial favorável. O teste central será manter confiáveis as transferências de liderança, os reparos, o encaminhamento de transações e os diferentes clientes validadores.

Rede opera com margem menor entre validadores

O projeto SIMD-0525 reduz o limite de trabalho de cada slot conforme sua duração cai. O orçamento por bloco fica em 62,5 milhões de unidades computacionais durante 250 ms. Na possível etapa de 200 ms, esse limite cairia para 50 milhões de unidades. Portanto, ambas as configurações preservam um teto nominal próximo de 250 milhões de unidades computacionais por segundo.

Slots menores alteram diretamente a cadência e a latência, mas não ampliam automaticamente a capacidade. Ainda assim, demanda, agendamento e eficiência dos líderes continuam determinando o throughput efetivo. Na prática, blocos mais frequentes criam novas oportunidades de inclusão sem elevar o orçamento computacional por segundo.

Janelas de liderança ficam mais curtas

O mesmo desenho mantém o turno de cada líder em quatro slots. Em 250 ms, cada líder recebe uma janela nominal de um segundo. Já em 200 ms, essa janela cairia para 800 ms. Além disso, a distância geográfica pode consumir parte relevante dessa margem.

Uma análise de engenharia da Solana Foundation mediu penalidade mediana de 28 ms entre líderes separados por menos de 500 quilômetros. Quando a distância supera 8.000 quilômetros, a penalidade alcança 122 ms. Esse intervalo equivale a 61% de um slot-alvo de 200 ms. Embora a métrica não meça apenas latência, ela evidencia o impacto da localização dos validadores.

A distribuição geográfica reduz riscos de concentração local. Em contrapartida, transferências de longa distância consomem mais tempo da janela de produção. O changelog também aponta o desenvolvimento de encaminhamento pessimista ao próximo líder quando uma transação pode não alcançar o destino previsto. Ao mesmo tempo, equipes testam blocos e transações com binários de conformidade entre implementações e versões.

A recuperação de dados enfrenta uma restrição semelhante. O projeto mantém um adiamento de reparos limitado a 250 ms durante a etapa de 200 ms. Dessa forma, o atraso poderia superar um slot-alvo inteiro.

Falha de roteamento expôs concentrações

A falha de roteamento da TeraSwitch ocorreu em 12 de agosto, antes da adoção dos slots de 250 ms. Portanto, os slots mais rápidos não causaram o evento. Mesmo assim, o episódio mostrou como uma dependência compartilhada pode afetar vários validadores aparentemente independentes. Conforme o relatório do incidente, 12 locais perderam conectividade e a empresa retirou uma unidade de Miami para contenção.

A Solana Compass calculou que 28,83% do stake da rede ficou inativo por cerca de 33 minutos. Por outro lado, o relato da Solana Foundation informou que validadores continuaram produzindo blocos e incluindo transações. A rede, portanto, absorveu a falha sem paralisação. Dados independentes de 7 de setembro também estimaram em 18 o coeficiente de Nakamoto baseado em stake.

Naquela data, o maior validador concentrava perto de 4% do stake ativo. Na camada de hospedagem, o mesmo relatório atribuiu à TeraSwitch 22,1% do stake ativo. Contudo, a Foundation afirmou que a empresa hospedava 38% do stake no ano anterior, antes de reduzir a fatia para menos de 30%. Como os números usam datas e metodologias diferentes, a leitura de 7 de setembro oferece o retrato atual mais consistente.

Clientes também representam um domínio de falha

Em 20 de setembro, uma consulta ponderada por stake agrupou aproximadamente 87,4% do stake em clientes da versão 4.x. Outros 7,3% estavam na versão 0.x, enquanto 5,3% usavam a 26.x. Esses números indicam aproximadamente as famílias Agave, Frankendancer e Firedancer. Porém, a classificação por versão não substitui uma análise detalhada de cada implementação.

Os indicadores medem riscos distintos. O stake revela quantos líderes precisariam falhar ou coordenar ações. Por sua vez, a linhagem dos clientes mostra a exposição a falhas comuns de implementação. A hospedagem indica quanto stake pode desaparecer sob um único provedor ou domínio de roteamento.

Slots mais rápidos não criam essas concentrações. Entretanto, eles reduzem as margens disponíveis para responder a perturbações correlacionadas. Por isso, o desempenho depende tanto da velocidade quanto da diversidade operacional da rede.

Etapa de 200 ms ainda depende de dados

Em 20 de setembro, o recurso de 200 ms continuava pendente para a mainnet. O cronograma de feature gates da Anza não apresentava uma data firme de ativação. Por enquanto, a página sobre a redução do tempo de slots condiciona novos cortes a um desempenho aceitável. Entre os critérios está a taxa de slots ignorados.

Uma epoch concluída com taxa próxima de 0,05% oferece uma referência útil. Porém, a decisão exigirá dados sustentados sobre duração dos slots, falhas, inclusão de transações e transferências de liderança. Idealmente, as equipes devem separar essas medições por família de cliente e provedor de infraestrutura.

Alpenglow segue um cronograma separado

O Alpenglow segue um cronograma próprio porque representa uma atualização de consenso. Seu objetivo envolve uma finalidade próxima de 150 ms. Enquanto o consenso trata da confirmação, o tempo de slot define a cadência das oportunidades de produção. De acordo com as páginas oficiais, as janelas previstas ficam entre o terceiro trimestre e outubro, com o Agave 4.3.

As páginas, contudo, não indicam um dia exato de ativação. Até agora, as primeiras leituras de 250 ms não mostram choque imediato na taxa de slots ignorados. Ainda assim, a rede precisará repetir esse resultado por mais tempo e sob condições menos favoráveis.

Antes de avançar para 200 ms, a Solana terá de comprovar a confiabilidade das transições de liderança. O mesmo vale para encaminhamento de transações, reparos e clientes distintos. A menor margem transforma a coordenação entre validadores no principal teste da próxima etapa.

	Receba nossas últimas notícias em primeira mão.   Adicione-nos como sua fonte preferida no Google    e toque em “Favorito” para priorizar nossas atualizações.