Solana desenvolvedores estão considerando um novo conjunto de regras de protocolo projetado para tornar o software de validador desenvolvido independentemente mais confiável e mais fácil de manter.
A proposta, publicada em 30 de outubro, vem de Brennan Watt, CEO da Anza, a empresa de engenharia de blockchain por trás do Agave, um dos principais programas de software utilizados para operar a rede Solana.
Watt deseja que a Solana estabeleça uma única especificação autoritativa que defina como sua blockchain processa transações, valida blocos e alcança consenso, em vez de depender de regras espalhadas pelo software existente e por propostas técnicas separadas.
A variação pode abordar um desafio crescente à medida que o Solana se expande além do seu software original de validador para incluir alternativas desenvolvidas independentemente, como Firedancer, construído pela empresa de negociação Jump Crypto.
Validadores são computadores que verificam transações e ajudam a proteger a blockchain. Embora diferentes desenvolvedores possam criar o software que executa esses computadores, cada implementação deve seguir as mesmas regras fundamentais para manter o acordo na rede.
Desacordos sobre essas regras poderiam fazer com que validadores processem transações idênticas de maneira diferente, potencialmente criando visões conflitantes da blockchain e ameaçando confiabilidade da rede.
Watt argumenta que o processo de desenvolvimento existente do Solana torna desnecessariamente difícil para equipes independentes determinarem exatamente como a rede deveria funcionar.
No sistema atual, as alterações no protocolo são propostas por meio de Solana Improvement Documents, conhecidos como SIMDs. Esses documentos descrevem atualizações individuais, mas as regras completas de funcionamento da rede não estão consolidadas em uma referência autorizada.
Como resultado, os desenvolvedores às vezes precisam examinar o código do validador existente ou reconstruir decisões anteriores de atualização para entender quais regras estão ativas.
Watt disse que essa abordagem pode produzir descrições repetidas ou inconsistentes do comportamento existente, tornando mais difícil identificar todas as partes do protocolo afetadas por uma atualização proposta.
Novo regulamento pode redefinir o processo de atualização do Solana
Sob a proposta, os desenvolvedores continuarão discutindo possíveis atualizações por meio do processo SIMD existente, mas alterações técnicas formais seriam submetidas como edições a uma especificação de protocolo compartilhada.
Cada emenda descreveria com precisão como a atualização afeta transações, comunicações de rede, consenso e outras funções relevantes.
As alterações passariam por revisão técnica e quaisquer aprovações de governança necessárias antes de se tornarem parte da especificação oficial quando ativadas no mainnet da Solana.
Isso permitiria que equipes desenvolvendo Agave, Firedancer e software de validador futuro trabalhassem a partir dos mesmos requisitos documentados, em vez de depender do código de outra implementação como referência principal.
Onde o cliente começa?
A construção child-bank aplica a transição de limite de epoch-E uma vez antes de suas transações.
Um conjunto comum de regras deixa o alvo explícito. A confiança no estado inicial e o próximo epoch permanecem como requisitos separados.
Este é um rascunho de especificação, não uma alteração de protocolo adotada. Ele não estabelece correção do estado inicial, replay histórico ou operação contínua em E+1. Nenhum ganho de confiabilidade do cliente é quantificado.
Também poderia tornar os testes de software mais eficazes. Quando validadores independentes produzem resultados diferentes, os desenvolvedores teriam um padrão comum para examinar a discrepância e identificar qual implementação precisa ser corrigida.
Watt já publicou uma especificação rascunho abrangendo 18 áreas das operações da Solana, incluindo processamento de transações, comunicações de rede, consenso, taxas e recompensas de validadores.
No entanto, o rascunho permanece limitado a um período definido da história da blockchain do Solana e assume que os desenvolvedores começam a partir de um estado de rede já confiável. Serão necessários mais trabalhos para abranger atualizações subsequentes e garantir que as implementações permaneçam compatíveis ao longo do tempo.