TL;DR: O paradigma existente para atualizar programas Solana é um desastre. A coisa mais perigosa sobre escrever código de contrato inteligente é que os modelos de dados do programa estão efetivamente bloqueados após a implantação. Na engenharia de software tradicional, a API do cliente é desacoplada do backend. Você pode mudar invisivelmente um esquema de backend ou adicionar migrações a um banco de dados. Na programação Solana, você pode tentar proteger um contrato para o futuro: - Adicionando preenchimento de estrutura e esperando que haja bits vazios suficientes nos dados da conta para futuras mudanças - Exigindo que os usuários assinem manualmente para migrar o estado da aplicação (horrível UX) - Implementando ações administrativas em nível de aplicação para migrar esquemas Note que todos os itens acima têm o potencial de quebrar a composabilidade em nível de VM. Eles também requerem lógica complexa e propensa a erros para serem executados com segurança. Isso não só introduz risco lógico de dados, mas também risco de gerenciamento de chaves. Um argumento é nunca mudar o código após a implantação. Afinal, a estrutura 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 a corrigir ou recursos críticos a adicionar no futuro (alguns dos quais podem exigir mudanças de wire). As empresas que constroem sobre esta pilha são forçadas a escolher entre segurança, velocidade e qualidade. Hoje, as ferramentas para permitir a manutenção e o desenvolvimento contínuo de um contrato inteligente suficientemente complexo não existem. Aqui estão algumas das características que eu pensaria em incluir se estivesse construindo este ambiente a partir de princípios básicos: - Deve haver APIs separadas na VM para ler e escrever dados de conta. Isso permite mudanças de esquema sem quebrar o formato de wire para consumidores on-chain e off-chain. - Algumas funções administrativas de contrato inteligente (opcionais) devem existir em nível de sistema, não em nível de aplicação. - Na atualização executável, deve haver simultaneamente uma migração atômica opcional de contas pertencentes a esse programa. Mesmo que o objetivo seja a imutabilidade, construir ferramentas em nível de sistema para permitir atualizações seguras de software é crítico para aplicações de consumo com estado em evolução. O sistema atual é tão frágil que o melhor conselho para esses desenvolvedores é nunca tocar em esquemas on-chain a menos que realmente saibam o que estão fazendo.