Solana poderá receber um impulso turbo enquanto Firedancer visa restrições de blocos

O impulso de desempenho da Solana ganhou novo momentum esta semana, quando os engenheiros por trás do Firedancer, o cliente validador alternativo de alto desempenho liderado pela Jump, apresentaram um novo Documento de Melhoria da Solana (SIMD-0370) para remover o limite de unidade de computação (CU) a nível de bloco da rede—uma mudança que eles argumentam ser redundante após o Alpenglow e que se traduziria imediatamente em maior throughput e menor latência quando a demanda aumenta.

Próximo Turbo Boost Para Solana

O pull request, escrito pela "Equipe Firedancer" e aberto em 24 de setembro de 2025, é explicitamente enquadrado como uma proposta "pós-Alpenglow". No Alpenglow, os nós votantes transmitem um SkipVote se não conseguirem executar um bloco proposto dentro do tempo alocado. Como os blocos lentos são automaticamente ignorados, os autores afirmam que um teto de CU separado imposto pelo protocolo por bloco é desnecessário.

"No Alpenglow, os nós votantes transmitem um SkipVote se não conseguirem executar um bloco a tempo... Este SIMD, portanto, remove a aplicação do limite de unidade de computação do bloco", afirma o documento, descrevendo o limite como supérfluo sob as regras de agendamento atualizadas.

Além da limpeza técnica, os autores propõem um alinhamento econômico mais acentuado. O atual limite de CU a nível de bloco, argumentam, quebra incentivos ao limitar a capacidade via protocolo em vez de melhorias de hardware e software. Removê-lo permitiria que os produtores preenchessem blocos até o que suas máquinas podem processar e propagar com segurança, colocando a competição de clientes e hardware em primeiro plano.

"A capacidade da rede é determinada não pelas capacidades do hardware, mas pelo limite arbitrário de unidade de computação do bloco", escrevem, antes de delinear por que levantar esse limite realinharia incentivos tanto para clientes validadores quanto para desenvolvedores de programas.

Comentários iniciais de revisão de código de colaboradores principais e equipes de clientes sublinham tanto o impacto de curto prazo para o usuário quanto os limites da mudança. Um revisor resumiu a vantagem prática: "Remover o limite hoje tem benefícios tangíveis para o ecossistema e usuários finais... sem esperar que a arquitetura futura da rede seja desenvolvida." Outro enfatizou que algumas restrições de bloco permaneceriam, citando um "limite máximo de fragmentação", enquanto outros sugeriram que a rede provavelmente deveria manter limites de CU por transação por enquanto e tratar qualquer mudança ali como uma discussão separada e de maior alcance.

Considerações de segurança e vivacidade são destaque. Os revisores pediram que a proposta explicasse explicitamente por que a segurança é preservada mesmo se um bloco for muito pesado para se propagar a tempo; a resposta do Alpenglow é que tais blocos simplesmente não são votados, ou seja, são ignorados—mantendo o progresso sem penalizar a rede. Os autores do Firedancer concordam que a proteção decisiva é o relógio e o orçamento de propagação, não um teto estático de CU.

A proposta também aborda uma preocupação frequente nos debates sobre throughput: coordenação. Se um produtor de bloco atualizar o hardware agressivamente enquanto outros ficam para trás, a rede corre o risco de rotatividade devido a blocos ignorados? Um revisor observa que produtores excessivamente ambiciosos já se autocalibram porque blocos perdidos significam recompensas perdidas, limitando naturalmente o tamanho do bloco ao que os pares podem aceitar a tempo. O documento argumenta ainda que, com o limite de CU removido, as forças de mercado governam a capacidade: produtores e equipes de clientes que otimizam execução, rede e agendamento ganharão mais blocos e taxas, empurrando a fronteira para fora conforme a demanda justificar.

Crucialmente, o SIMD-0370 é compatível com o futuro. Designs em andamento para múltiplos proponentes concorrentes—um item de longo prazo no roteiro da Solana—às vezes assumem um limite de bloco e às vezes não. Os revisores enfatizam que remover o limite atual não impede arquiteturas de proponentes concorrentes mais tarde; simplesmente desbloqueia melhorias que "podem ser realizadas hoje".

Enquanto a discussão do GitHub fornece a parte técnica, a Anza—a equipe cliente da Solana por trás do Agave—também amplificou a proposta em canais sociais, sinalizando ampla atenção da equipe cliente à mudança e suas implicações voltadas para o usuário.

O que mudaria para usuários e desenvolvedores se o SIMD-0370 for lançado? Em períodos de pico—airdrops, cunhagens, volatilidade do mercado—os blocos poderiam carregar mais computação, desde que possam ser executados e propagados dentro do tempo de slot, potencialmente aumentando o throughput sustentado e suavizando picos de taxas.

Para desenvolvedores da Solana, maior espaço e incentivos mais fortes para otimização de cliente/hardware poderiam reduzir a latência de cauda para cargas de trabalho exigentes, embora com a necessidade contínua de otimizar programas para paralelismo e localidade. Para validadores, a vantagem competitiva se inclinaria ainda mais para a eficiência de execução, desempenho de rede e políticas inteligentes de construção de blocos que equilibram a receita de taxas contra o risco de produzir um bloco tão pesado que seja ignorado.

Como acontece com todos os SIMDs, a mudança está sujeita à revisão da comunidade, implementação e coordenação de implantação entre clientes validadores. Mas a direção é clara. Pós-Alpenglow, os designers da Solana acreditam que o orçamento de tempo de slot é o verdadeiro limitador.

No momento da publicação, a Solana era negociada a $205,38.