Resumo; DR: O paradigma existente para modernizar os programas Solana é um desastre. A coisa mais perigosa de escrever código de smart contract é que os modelos de dados do programa ficam efetivamente travados após a implantação. No SWE tradicional, a API do cliente é desacoplada do backend. Você pode alterar invisivelmente um esquema backend ou adicionar migrações a um banco de dados. Na programação Solana, você pode tentar proteger um contrato para o futuro por meio de: - Adicionar preenchimento de estruturas e torcer para que haja bits vazios suficientes nos dados da conta para mudanças futuras - Exigir que os usuários assinem manualmente para migrar o estado da aplicação (UX horrível) - Implementar ações administrativas em nível de aplicação para migrar esquemas Note que tudo isso acima tem potencial para quebrar a composabilidade em nível de VM. Eles também exigem lógica complexa e propensa a erros para serem executados com segurança. Isso não apenas introduz risco lógico de dados, mas também risco de gestão de chaves. Um argumento é nunca mudar o código após a implantação. Afinal, o framework existente torna extremamente difícil modificar formatos de dados existentes com segurança. No entanto, mesmo que a imutabilidade seja desejável, é ingênuo e imprudente pensar que não há bugs catastróficos para corrigir ou recursos críticos para adicionar no futuro (alguns dos quais podem exigir trocas de fios). Empresas que desenvolvem essa pilha são obrigadas a escolher entre segurança, velocidade e qualidade. Hoje, as ferramentas para viabilizar a manutenção e o desenvolvimento contínuo de um contrato inteligente suficientemente complexo são inexistentes. Aqui estão algumas das funcionalidades que eu pensaria incluir se eu estivesse construindo esse ambiente a partir dos princípios básicos: - Devem haver APIs separadas na VM para ler e gravar dados da conta. Isso permite alterações de esquema sem quebrar o formato de fio tanto para consumidores on-chain quanto off-chain. - Algumas funções administrativas de contratos inteligentes (opt-in) devem existir no nível do sistema, não no nível da aplicação. - Na atualização executável, deve haver simultaneamente uma migração atômica opcional das contas pertencentes àquele programa. Mesmo que o objetivo seja a imutabilidade, incorporar ferramentas em nível de sistema para permitir atualizações seguras de software é fundamental para aplicações de consumo em estado evolutivo. O sistema atual é tão frágil que o melhor conselho para esses desenvolvedores é nunca tocar em esquemas on-chain a menos que eles realmente saibam o que estão fazendo.