Populære emner
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
TL; DR: Det eksisterende paradigmet for oppgradering av Solana-programmer er en katastrofe.
Det farligste med å skrive smart kontrakt-kode er at programdatamodellene i praksis låses fast etter utrulling.
I tradisjonell programvareutvikling er klient-API-et koblet fra backend. Du kan usynlig endre et backend-skjema eller legge til migreringer i en database.
I Solana-programmering kan du forsøke å fremtidssikre en kontrakt ved å:
- Legge til struct-utfylling og håpe at det er nok tomme biter i kontodataene for fremtidige endringer
- Krever at brukere manuelt signerer for å migrere applikasjonstilstand (forferdelig UX)
- Implementering av applikasjonsnivå-administrasjonshandlinger for å migrere skjemaer
Merk at alt dette har potensial til å ødelegge komponerbarheten på VM-nivå. De krever også kompleks og feilutsatt logikk for å kjøre trygt. Det introduserer ikke bare logisk datarisiko, men også nøkkelstyringsrisiko.
Et argument er å aldri endre koden etter utrulling. Tross alt gjør det eksisterende rammeverket det ekstremt vanskelig å endre eksisterende dataformater trygt.
Men selv om uforanderlighet er ønskelig, er det naivt og uforsvarlig å tro at det ikke finnes katastrofale feil å fikse eller kritiske funksjoner å legge til i fremtiden (noen av dem kan kreve bytte av ledninger). Bedrifter som bygger på denne stakken må velge mellom sikkerhet, hastighet og kvalitet.
I dag er verktøyene som muliggjør vedlikehold og kontinuerlig utvikling av en tilstrekkelig kompleks smartkontrakt ikke-eksisterende.
Her er noen av funksjonene jeg ville tenkt å inkludere hvis jeg skulle bygge dette miljøet fra grunnprinsippene:
- Det bør være separate API-er i VM-en for å lese og skrive kontodata. Dette muliggjør skjemaendringer uten å bryte wire-formatet for både on-chain og off-chain brukere.
- Noen (opt-in) administrative smartkontraktsfunksjoner bør eksistere på systemnivå, ikke på applikasjonsnivå.
- Ved kjørbar oppgradering skal det samtidig være en valgfri atommigrering av kontoer eid av det programmet.
Selv om målet er uforanderlighet, er det avgjørende å bygge inn systemnivåverktøy for å muliggjøre sikre programvareoppgraderinger for forbrukerapplikasjoner med utviklende tilstand. Det nåværende systemet er så skjørt at det beste rådet til disse utviklerne er å aldri røre on-chain-skjemaer med mindre de virkelig vet hva de gjør.

Topp
Rangering
Favoritter
