12186 | Mise à jour du SDK de proposition vers la version 50.13 soumise par Luncverse
Source de :
- https://validator.info/terra-classic/governance/12186
- https://station.terraclassic.community/proposal/columbus-5/12186
- https://discourse.luncgoblins.com/t/updated-proposal-terra-classic-sdk-wasm-upgrade/74
Demande d’approbation pour la mise à niveau de la chaîne vers le SDK 50.13. Veuillez consulter l’intégralité de la proposition ici : https://discourse.luncgoblins.com/t/updated-proposal-terra-classic-sdk-wasm-upgrade/74
Proposition mise à jour : Terra Classic SDK & Wasm Upgrade
Terra Classic Upgrade
Document / ANTIER SOLUTIONS
Résumé
Cette proposition présente une mise à jour sécurisée et rétrocompatible de l’infrastructure de base de Terra Classic vers Cosmos SDK v0.50.13 et Wasm Module v0.53.2, en résolvant les problèmes non résolus lors de la mise à jour v0.47, en améliorant la sécurité et en garantissant la viabilité à long terme.
La mise à jour dépend de l’achèvement de l’unforking d’Orbit Labs et comprend des correctifs pour la dette technique, l’atténuation des changements de rupture, et des améliorations axées sur les développeurs. La proposition garantit une compatibilité ascendante totale pour les dApps existantes.
Spécifications techniques et implications
1. Mise à jour du SDK Cosmos
Version actuelle: v0.47.17
Proposition: v0.50.13
Justification: La mise à jour vers la version 0.50+ (“v50.13”) apporte un consensus moderne grâce à ABCI++, une architecture modulaire et maintenable, un stockage plus robuste, une logique de permission renforcée, une configuration basée sur la gouvernance et des outils conviviaux pour les développeurs, plaçant Terra Classic sur une voie plus solide et à l’épreuve du temps.
Changements :
x/params modules updates (requires migration to new governance-driven parameters).
x/authz and x/feegrant updates (impacts dApps using delegation/allowances).
Custom module adjustments (e.g., Oracle, Market, Staking) due to SDK refactoring.
Terra Classic Considérations :
Assure une compatibilité ascendante totale avec les caractéristiques et fonctionnalités existantes de la chaîne.
2. Module Wasm et machine virtuelle
Actuel : v0.46.0 / wasmvm v1.5.8
Proposé : v0.53.2 / wasmvm v2.1.4
Impact de la dApp :
- Les contrats CosmWasm existants restent en vigueur.
- Les contrats respecteront les normes les plus récentes tout en conservant une compatibilité ascendante avec les contraintes existantes.
Terra Classic Custom Wasm Bindings Compatibilité :
Les liens personnalisés pour les modules oracle, taxe et marché seront maintenus.
3. IBC-GO
IBC-GO: v7.4.0 → v8.7.0
Préserve la compatibilité entre les chaînes sans introduire de changements qui brisent le BAC.
Amélioration des performances, optimisation des performances des relais et réduction de la latence des transactions.
La protection de l’avenir, en garantissant la compatibilité avec les prochaines chaînes Cosmos adoptant la version 8.7.0 du BAC.
4. Terra Classic – Modules personnalisés et plan de mise à niveau
Les modules personnalisés de Terra Classic doivent être manipulés avec précaution lors de cette mise à jour :
Module Oracle: Gère les flux de taux de change pour les stablecoins. Nécessite des tests de compatibilité avec la nouvelle structure du SDK afin de s’assurer que les soumissions de prix des validateurs restent exactes.
Module de marché : Facilite les échanges de stablecoins. Nécessite une validation des paramètres et une optimisation des performances dans le cadre du nouveau modèle d’exécution du SDK.
Module Trésor : Il régit les politiques économiques, y compris les taux d’imposition. Il doit être préservé sans perte de fonctionnalité et testé selon les nouveaux paramètres de gouvernance.
Toutes les autres personnalisations effectuées dans les différents modules, telles que le jalonnement, l’abattage, la frappe, etc. seront également mises à jour.
Stratégie de mise à niveau :
Tests unitaires détaillés et refonte :
Effectuer des tests unitaires sur les modules Oracle, Marché et Trésorerie afin de vérifier le bon fonctionnement sous le nouveau SDK.
Identifier les domaines nécessitant un remaniement pour s’aligner sur le SDK v0.50.13.
Mise en œuvre de la couche de compatibilité ascendante :
Développer des cales de compatibilité temporaires pour les modules x/treasury et x/market afin d’éviter les perturbations de la dApp.
Veillez à ce que les paramètres de gouvernance existants restent inchangés pendant la mise à niveau.
Pourquoi cette mise à niveau ?
1. Recherche spécifique à Terra Classic
Synergie de débouchage :
L’unforking d’Orbit Labs supprime les correctifs originaux de Terra, ce qui permet une intégration transparente du SDK v0.50.
2. Atténuation des risques
Couche de compatibilité ascendante :
Cales temporaires pour les modules obsolètes afin d’éviter toute perturbation de la dApp.
Mesures de sécurité :
Les vulnérabilités de sécurité identifiées par Oak Security dans l’audit de Cosmos SDK v0.47 seront résolues en intégrant les correctifs correspondants de la v0.50.
Déroulement des opérations et calendrier
Phase 1 : Préparation à la mise à niveau (2 semaines)
Tâches : Analyse détaillée de la base de code actuelle, compatibilité ascendante et documentation, mise en place d’un réseau de test.
Phase 2 : Exécution de la mise à niveau du noyau (5 semaines)
Tâches :
SDK v0.50.13 intégration.
Mise à jour du module Wasm v0.53.2.
Migration de modules personnalisés pour les fonctionnalités uniques de Terra Classic.
S’assurer que les contrats CosmWasm 1.0-1.5 restent fonctionnels.
Assurer le soutien et la compatibilité totale des contrats CW-0.16 existants sur la chaîne, tout en permettant la compatibilité avec les contrats CW-1.0-1.5, de sorte qu’il n’y ait pas de risque pour les déploiements actuels et que nous soyons prêts pour l’avenir.
Phase 3 : Améliorations progressives, essais et validation (9 semaines)
Tâches :
Configurer la chaîne sur une version qui supporte les contrats 0.16, instancier ces contrats et ensuite mettre à jour la chaîne progressivement vers la version 0.50.13 suivi par des tests fictifs.
Audits de sécurité, essais de validation, tests de migration de dApp, bug bounties.
Nous conservons l’application v1 pour cette mise à jour afin de minimiser la complexité de la migration. Nous prévoyons d’évaluer la migration App v2/depinject dans une phase ultérieure, une fois que nous nous serons stabilisés sur la v0.50.
Phase 4 : Déploiement de Testnet (4 semaines)
Tâches :
Lancement d’un réseau d’essai public, intégration du validateur/de l’application, suivi.
Phase 5 : Déploiement du réseau principal (4 semaines)
Tâches : Vote de gouvernance, coordination CEX, mise à niveau du réseau principal, suivi post-lancement.
****Strathcole a contribué à la mise à jour des détails et a également corrigé le bogue SDK 47 signalé par Allnodes.
Ce document est le formulaire original que j’ai reçu. Après avoir posé quelques questions – qui fait cela. – ANTIER SOLUTIONS s’occuperait de la mise à niveau.
