Fonte da:

• https://validator.info/terra-classic/governance/12162
• https://station.terraclassic.community/proposal/columbus-5/12162
• https://common.xyz/terra-luna-classic-lunc/discussion/26630

Aggiornamento SDK v0.50.X da Antier Solutions

Dopo l’unfork dei laboratori orbitali proponiamo un aggiornamento a catena al più recente SDK

https://common.xyz/terra-luna-classic-lunc/discussion/26630

Per cookie FrgValidator e Luncvers3

Aggiornamento SDK 0.50.x Finale

Documento Aggiornato Proposta:

Aggiornamento SDK e Wasm di Terra Classic Sintesi Questa proposta illustra un aggiornamento sicuro e retrocompatibile dell’infrastruttura principale di Terra Classic a Cosmos SDK v0.50.9 e Wasm Module v0.53.2, risolvendo i problemi irrisolti dall’aggiornamento v0.47, migliorando la sicurezza e garantendo la sostenibilità a lungo termine. L’aggiornamento è subordinato al completamento dell’unforking da parte di Orbit Labs e comprende la correzione dei debiti tecnici, la mitigazione delle rotture e miglioramenti mirati agli sviluppatori. La proposta garantisce la piena retrocompatibilità per le dApp esistenti. Specifiche tecniche e implicazioni

1. Aggiornamento dell’SDK Cosmos Attuale: v0.47.14 Proposta: v0.50.9 Motivazione: La versione attuale contiene alcune vulnerabilità di sicurezza. L’aggiornamento alla versione 0.50.9 risolve questi problemi in modo completo. Modifiche: aggiornamenti del modulo x/params (richiede la migrazione a nuovi parametri guidati dalla governance). Aggiornamenti di x/authz e x/feegrant (ha un impatto sulle dApp che utilizzano deleghe/concessioni). Adattamenti dei moduli personalizzati (ad es. Oracle, Market, Staking) dovuti al refactoring dell’SDK. Considerazioni su Terra Classic: Assicura la piena retrocompatibilità con le caratteristiche e le funzionalità della catena esistente.
2. Modulo e macchina virtuale Wasm Attuale: v0.46.0 / wasmvm v1.5.8 Proposta: v0.53.2 / wasmvm v2.1.4 Impatto della dApp: I contratti CosmWasm esistenti rimangono funzionanti. I contratti aderiranno agli standard più recenti mantenendo la retrocompatibilità con i vincoli esistenti. Compatibilità dei vincoli Wasm personalizzati Terra Classic: I vincoli personalizzati per i moduli oracolo, tasse e mercato saranno mantenuti.
3. IBC-GO IBC-GO: v7.4.0 → v8.4.0 Preserva la compatibilità cross-chain senza introdurre modifiche che rompono l’IBC. Miglioramenti delle prestazioni, ottimizzando le prestazioni dei relayer e riducendo la latenza delle transazioni. Protezione per il futuro, assicurando la compatibilità con le prossime catene Cosmos che adotteranno IBC v8.4.0. Miglioramenti della sicurezza in IBC-GO v8.4.0: Risolve una vulnerabilità critica di attacco di rientranza negli hook di IBC, garantendo una gestione sicura del ciclo di vita dei pacchetti per evitare la perdita di fondi o il conio involontario di token. L’aggiornamento attenua questi rischi, rafforzando la sicurezza cross-chain di Terra Classic.
4. Moduli personalizzati di Terra Classic e piano di aggiornamento I moduli personalizzati di Terra Classic richiedono un’attenta gestione durante l’aggiornamento: Modulo Oracle: Gestisce i feed dei tassi di cambio per le monete stabili. Richiede test di compatibilità con la nuova struttura dell’SDK per garantire che i prezzi inviati dal validatore rimangano accurati. Modulo Mercato: Facilita gli scambi di stablecoin. Richiede la convalida dei parametri e l’ottimizzazione delle prestazioni con il nuovo modello di esecuzione dell’SDK. Modulo Tesoro: Gestisce le politiche economiche, comprese le aliquote fiscali. Deve essere preservato senza perdita di funzionalità e testato in base ai nuovi parametri di governance. Saranno aggiornate anche tutte le altre personalizzazioni effettuate nei vari moduli, come ad esempio le scommesse, i tagli, le zecche, ecc. Strategia di aggiornamento: Test dettagliati delle unità e refactoring: Eseguire test unitari sui moduli Oracle, Market e Treasury per verificare la corretta funzionalità con il nuovo SDK. Identificare le aree che necessitano di refactoring per allinearsi all’SDK v0.50.9. Implementazione del livello di compatibilità all’indietro: Sviluppare spessori di compatibilità temporanei per i moduli x/treasury e x/market per evitare interruzioni della dApp. Assicurati che i parametri di governance esistenti rimangano invariati durante l’aggiornamento. Perché questo aggiornamento?
5. Sinergia di unforking per la ricerca di Terra Classic: L’unforking di Orbit Labs rimuove le patch originali di Terra, consentendo una perfetta integrazione dell’SDK v0.50.
6. Mitigazione del rischio Strato di compatibilità all’indietro: Moduli temporanei per i moduli deprecati per evitare l’interruzione della dApp. Misure di sicurezza: Audit da parte di Oak Security (incentrato sulla migrazione v0.47 → v0.50). Flusso di lavoro e tempistica Fase 1: Preparazione all’aggiornamento (2 settimane) Attività: Verifica del codice (post-unforking), correzione dei problemi legacy, documentazione sulla retrocompatibilità, configurazione della testnet. Fase 2: Esecuzione dell’aggiornamento del nucleo (5 settimane) Attività: Integrazione dell’SDK v0.50.9. Aggiornamento del modulo Wasm v0.53.2. Migrazione di moduli personalizzati per le caratteristiche uniche di Terra Classic. Garantire la funzionalità dei contratti CosmWasm 1.0-1.5. Fase 3: Aggiornamenti progressivi, test e convalida (9 settimane) Compiti: Impostare la catena sulla versione che supporta i contratti 0.16, istanziare tali contratti e quindi aggiornare progressivamente la catena alla versione 0.50.9 seguita da test di simulazione. Aggiornamenti progressivi della catena fino alla versione 0.50.9 seguiti da test di simulazione. Fase 4: Distribuzione della Testnet (2 settimane) Compiti: Lancio di una testnet pubblica, inserimento di validatori e dApp, monitoraggio. Fase 5: Distribuzione della Mainnet (2 settimane) Compiti: Votazione della governance, coordinamento del CEX, aggiornamento della mainnet, monitoraggio post-lancio. Tempistica totale: 20 settimane (~5 mesi) Fase Durata Attività chiave Costo

Fasi

• Pre-aggiornamento: 2 settimane Verifica del codice post-unforking, correzione dei bug dell’SDK v0.47, documentazione delle modifiche di rottura, configurazione della testnet. $6,000
• Aggiornamento del nucleo: 5 settimane Integrare SDK v0.50.9, Wasm v0.53.2, CometBFT v0.38.11, livelli di retrocompatibilità. $25,000
• Test e convalida: 9 settimane Audit di sicurezza, prove a secco del validatore, test di migrazione della dApp, bug bounty. $12,000
• Implementazione della testnet: 2 settimane Lancio di una testnet pubblica, validatore/app onboarding, monitoraggio. $8,000
• Distribuzione Mainnet: 2 settimane Voto di governance, coordinamento CEX, aggiornamento mainnet, monitoraggio post-lancio. $6,000

Dopo 48 ore di discussione, la proposta sarà sottoposta a votazione.

Questa proposta è stata avanzata dal team di #Cookie #FRGValidator e #LUNCVERS3 per luna classic.

Aggiornamento in corso di implementazione da parte di Antier Solutions

Considerazione importante: L’aggiornamento di wasmd può essere avviato solo dopo che è stato eseguito il “wasmd unfork” di Orbit Labs o, in alternativa, in coordinamento con Orbit labs come parte di uno sforzo congiunto per combinare il wasmd unfork con l’aggiornamento di sdk e wasmd.

Una nuova proposta di spesa sarà presentata in seguito a ciascuna milestone.