TL; DR: Det befintliga paradigmet för att uppgradera Solana-programmen är en katastrof. Det farligaste med att skriva smart contract-kod är att programdatamodellerna i praktiken är låsta efter distribution. I traditionell mjukvaruutveckling är klient-API:et frånkopplat från backend. Du kan osynligt ändra ett backend-schema eller lägga till migreringar i en databas. I Solana-programmering kan du försöka framtidssäkra ett kontrakt genom att: - Lägga till strukturutfyllnad och hoppas att det finns tillräckligt med tomma bitar i kontodata för framtida ändringar - Kräver att användare manuellt loggar för att migrera applikationstillstånd (fruktansvärd UX) - Implementering av applikationsnivå-administratörsåtgärder för att migrera scheman Observera att allt ovanstående kan förstöra VM-nivåkomposerbarhet. De kräver också komplex och felbenägen logik för att köras säkert. Det medför inte bara logisk datarisk, utan även risk för nyckelhantering. Ett argument är att aldrig ändra koden efter utrullning. Det befintliga ramverket gör det trots allt extremt svårt att säkert ändra befintliga dataformat. Men även om oföränderlighet är önskvärd är det naivt och vårdslöst att tro att det inte finns några katastrofala buggar att åtgärda eller kritiska funktioner att lägga till i framtiden (vissa av dessa kan kräva kabelbyten). Företag som bygger på denna stack tvingas välja mellan säkerhet, hastighet och kvalitet. Idag finns det inga verktyg för att möjliggöra underhåll och kontinuerlig utveckling av ett tillräckligt komplext smart kontrakt. Här är några av de funktioner jag skulle tänka mig att inkludera om jag byggde denna miljö från första principer: - Det bör finnas separata API:er i VM:n för att läsa och skriva kontodata. Detta möjliggör schemaändringar utan att bryta trådformatet för både on-chain- och off-chain-konsumenter. - Vissa (opt-in) administrativa smartkontraktsfunktioner bör finnas på systemnivå, inte på applikationsnivå. - Vid en exekverbar uppgradering bör det samtidigt ske en valfri atomär migrering av konton som ägs av det programmet. Även om målet är oföränderlighet är det avgörande för konsumentapplikationer med föränderligt tillstånd att bygga in systemnivåverktyg för att möjliggöra säkra mjukvaruuppgraderingar. Det nuvarande systemet är så sprött att det bästa rådet till dessa utvecklare är att aldrig röra on-chain-scheman om de inte verkligen vet vad de gör.