Cripto: Solana quer corrigir um risco oculto em sua blockchain

Solana estuda uma reforma para impedir que seus validadores interpretem de maneira diferente as regras da blockchain. Em 30 de outubro de 2026, Brennan Watt, CEO da Anza, propôs reunir as normas técnicas da rede cripto em uma única especificação. O documento inicial já abrange 18 áreas, incluindo transações, consenso e recompensas dos validadores. A iniciativa pretende reduzir o risco de divergências capazes de prejudicar o funcionamento da rede.

Solana tenta eliminar um risco oculto na rede cripto

Os desenvolvedores da Solana querem resolver um problema relacionado aos programas que mantêm a blockchain funcionando. Recentemente, a Fidelity apontou três fragilidades na rede Solana, apesar dos avanços em estabilidade.

Agora, uma nova proposta trata especificamente da maneira como diferentes softwares interpretam as regras do protocolo.

Os validadores são computadores responsáveis por verificar transações, processar blocos e participar do consenso. Para que a blockchain funcione corretamente, todos precisam aplicar as mesmas normas.

A Solana utiliza diferentes programas de validação. O Agave, desenvolvido pela Anza, continua entre os principais. Já o Firedancer, criado pela Jump Crypto, possui uma arquitetura independente.

Essa diversidade oferece uma vantagem importante para a segurança cripto. Um problema em determinado software não precisa necessariamente atingir os demais, desde que eles não compartilhem a mesma falha.

Entretanto, manter diferentes programas também cria dificuldades técnicas. Cada equipe precisa interpretar corretamente as regras que definem quais transações são válidas e como os blocos devem ser processados.

Se dois validadores chegarem a resultados incompatíveis para uma mesma operação, podem surgir divergências no consenso.

Em situações mais graves, isso poderia interromper a finalização de blocos ou provocar uma divisão temporária da blockchain. Nenhum novo incidente desse tipo foi confirmado em relação à proposta atual.

Brennan Watt acredita que a documentação existente contribui para essa dificuldade.

As regras da Solana estão distribuídas entre o código dos validadores e diversos documentos chamados Solana Improvement Documents, ou SIMD.

Esses documentos apresentam alterações individuais, mas não formam uma referência completa e centralizada.

Os desenvolvedores precisam consultar propostas anteriores e examinar diferentes partes do código para entender o comportamento esperado da rede.

Nova proposta reúne 18 áreas técnicas da Solana

A solução apresentada pela Anza prevê uma especificação oficial contendo as regras de funcionamento da blockchain.

O primeiro documento já possui 18 seções. Elas abrangem o processamento de transações, as contas, a comunicação entre validadores, o consenso, as taxas e as recompensas.

O objetivo é oferecer uma referência comum para todos os programas de validação.

Atualmente, os desenvolvedores apresentam propostas SIMD para modificar partes específicas do protocolo. Essas alterações passam por discussões técnicas e procedimentos de aprovação antes de entrar em funcionamento.

Pelo novo modelo, as mudanças também seriam apresentadas como alterações diretamente no documento compartilhado.

Cada proposta precisaria identificar quais regras serão modificadas e explicar seus efeitos sobre outras partes do sistema.

As análises técnicas e os processos de governança continuariam necessários. Uma mudança só passaria a integrar oficialmente a especificação depois de ser ativada na rede principal.

A iniciativa surge após uma importante atualização do protocolo.

Em 21 de outubro, a Solana substituiu o TowerBFT pelo Alpenglow em sua rede principal.

O novo mecanismo busca reduzir o tempo de finalização das transações de aproximadamente 12,8 segundos para cerca de 150 milissegundos.

Parte da arquitetura planejada ainda depende de novas etapas de implementação.

Essas mudanças tornam mais importante manter uma documentação técnica consistente. Agave, Firedancer e outros clientes precisam interpretar corretamente as atualizações para continuar participando do mesmo consenso.

Para as equipes que desenvolvem programas independentes, a especificação também reduziria a necessidade de utilizar o código do Agave como principal referência.

A proposta não exige que os validadores adotem um único software nem altera imediatamente as operações realizadas pelos usuários de criptomoedas.

Reforma ainda depende de acordo entre desenvolvedores

A iniciativa permanece em discussão. Brennan Watt ainda não apresentou um calendário para a adoção da especificação nem uma data para sua implementação.

Os desenvolvedores precisam definir como o documento será atualizado e de que maneira as futuras mudanças serão revisadas.

Jacob Creech, colaborador ligado à Solana Foundation, levantou questões sobre a numeração das propostas e o processo de análise das alterações.

Outros participantes destacaram a necessidade de documentar corretamente as dependências entre diferentes partes do protocolo.

Uma das próximas etapas poderá envolver a atualização do SIMD-0001, documento que atualmente estabelece as regras para apresentar e aprovar propostas técnicas.

Também será necessário estabelecer uma versão inicial da especificação que corresponda ao funcionamento real da rede principal.

A mudança não elimina todos os riscos de programação. Softwares diferentes podem apresentar erros próprios, mesmo quando seguem exatamente as mesmas regras.

A Solana também enfrenta outros desafios de descentralização. Segundo o estudo da Fidelity publicado em outubro, aproximadamente 18 validadores concentram mais de um terço do SOL em staking.

Além disso, várias implementações ainda compartilham partes importantes da mesma base de código.

A reforma proposta pela Anza procura resolver um problema específico: evitar interpretações incompatíveis entre clientes independentes.

Para o mercado cripto, o projeto acompanha a expansão de uma blockchain utilizada em pagamentos, finanças descentralizadas e ativos tokenizados. A Cointribune já havia destacado os riscos de concentração e de falhas de software na Solana. A nova especificação poderá facilitar o desenvolvimento de clientes independentes, mas ainda precisará passar pelas discussões técnicas antes de se tornar uma referência oficial.