TL;DR: Il paradigma attuale per l'aggiornamento dei programmi Solana è un disastro. La cosa più pericolosa nella scrittura del codice dei contratti smart è che i modelli di dati del programma sono effettivamente bloccati dopo il deployment. Nello sviluppo software tradizionale, l'API client è disaccoppiata dal backend. Puoi cambiare invisibilmente uno schema di backend o aggiungere migrazioni a un database. Nella programmazione Solana, puoi tentare di rendere un contratto a prova di futuro: - Aggiungendo padding alle strutture e sperando che ci siano abbastanza bit vuoti nei dati dell'account per futuri cambiamenti - Richiedendo agli utenti di firmare manualmente per migrare lo stato dell'applicazione (esperienza utente orribile) - Implementando azioni di amministrazione a livello di applicazione per migrare gli schemi Nota che tutte le opzioni sopra hanno il potenziale di rompere la composabilità a livello di VM. Richiedono anche logiche complesse e soggette a errori per essere eseguite in modo sicuro. Non solo introduce rischi logici sui dati, ma anche rischi nella gestione delle chiavi. Un argomento è di non cambiare mai il codice dopo il deployment. Dopotutto, il framework esistente rende estremamente difficile modificare in modo sicuro i formati di dati esistenti. Tuttavia, anche se l'immutabilità è desiderabile, è ingenuo e sconsiderato pensare che non ci siano bug catastrofici da correggere o funzionalità critiche da aggiungere in futuro (alcune delle quali potrebbero richiedere cambiamenti a livello di wire). Le aziende che costruiscono su questo stack sono costrette a scegliere tra sicurezza, velocità e qualità. Oggi, gli strumenti per abilitare la manutenzione e lo sviluppo continuo di un contratto smart sufficientemente complesso non esistono. Ecco alcune delle funzionalità che considererei di includere se stessi costruendo questo ambiente da principi fondamentali: - Dovrebbero esserci API separate nella VM per leggere e scrivere i dati dell'account. Questo consente cambiamenti di schema senza rompere il formato wire per i consumatori on-chain e off-chain. - Alcune funzioni di contratto smart amministrative (su base opt-in) dovrebbero esistere a livello di sistema, non a livello di applicazione. - Durante l'aggiornamento eseguibile, dovrebbe esserci simultaneamente una migrazione atomica opzionale degli account di proprietà di quel programma. Anche se l'obiettivo è l'immutabilità, costruire strumenti a livello di sistema per abilitare aggiornamenti software sicuri è fondamentale per le applicazioni consumer con stato in evoluzione. L'attuale sistema è così fragile che il miglior consiglio per questi sviluppatori è di non toccare gli schemi on-chain a meno che non sappiano davvero cosa stanno facendo.

Buona tecnologia, pazzesco che ci siano voluti 5 anni per arrivare qui @solana 😭

La definizione di DEX è davvero evoluta nel corso degli anni. 2021: Il matching viene eseguito e convalidato su una rete distribuita a livello globale. 2025: Deposita token su Solana, Arbitrum o BSC, e l'exchange lo registrerà in una tabella SQL. Il matching avviene in ap-northeast-1.