Skip to content Skip to sidebar Skip to footer

12162 | SDK v0.50.X Mise à jour par Antier Solutions

6 min read 1,199 words 224 views

Source de :

SDK v0.50.X Mise à jour par Antier Solutions

Suite à l’unfork des laboratoires d’orbite, nous proposons une mise à jour en chaîne vers le SDK le plus récent.

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

Par cookie FrgValidator et Luncvers3

Mise à jour du SDK 0.50.x Final

Document mis à jour Proposition :

Terra Classic SDK & Wasm Upgrade Executive Summary Cette proposition décrit une mise à jour sécurisée et rétrocompatible de l’infrastructure de base de Terra Classic vers Cosmos SDK v0.50.9 et Wasm Module v0.53.2, en traitant les problèmes non résolus de la mise à jour v0.47, en améliorant la sécurité et en assurant la viabilité à long terme. La mise à jour dépend de l’achèvement de l’unforking d’Orbit Labs et inclut des corrections 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.14 Version proposée : v0.50.9 Justification : La version actuelle contient quelques failles de sécurité. La mise à jour vers la version 0.50.9 résout ces problèmes de manière exhaustive. Changements : mises à jour du module x/params (nécessite une migration vers de nouveaux paramètres basés sur la gouvernance). mises à jour de x/authz et x/feegrant (impact sur les dApps utilisant la délégation/les allocations). Ajustements des modules personnalisés (par exemple, Oracle, Market, Staking) en raison de la refonte du SDK. Considérations relatives à Terra Classic : Assure une rétrocompatibilité 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 dApp Impact : Les contrats CosmWasm existants restent fonctionnels. Les contrats adhéreront aux derniers standards tout en maintenant une compatibilité ascendante avec les contraintes existantes. Compatibilité des liaisons Wasm personnalisées Terra Classic : Les liaisons personnalisées pour les modules oracle, taxe et marché seront maintenues.
  3. IBC-GO IBC-GO : v7.4.0 → v8.4.0 Préserve la compatibilité entre les chaînes sans introduire de changements qui brisent l’IBC. Amélioration des performances, optimisation des performances des relais et réduction de la latence des transactions. Une protection du futur, assurant la compatibilité avec les chaînes Cosmos à venir qui adoptent IBC v8.4.0. Améliorations de la sécurité dans IBC-GO v8.4.0 : Corrige une vulnérabilité critique d’attaque par réentrance dans les hooks IBC, assurant une gestion sécurisée du cycle de vie des paquets afin d’éviter la perte de fonds ou le monnayage involontaire de jetons. La mise à jour atténue ces risques, en renforçant la sécurité inter-chaînes de Terra Classic.
  4. Modules personnalisés de Terra Classic et plan de mise à niveau Les modules personnalisés de Terra Classic doivent être manipulés avec soin lors de cette mise à niveau : Module Oracle : Gère les flux de taux de change pour les stablecoins. Nécessite des tests de compatibilité avec la nouvelle structure SDK pour 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 de trésorerie : Gouverne 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, comme le staking, le slashing, le mint, 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 pour vérifier le bon fonctionnement sous le nouveau SDK. Identifier les domaines nécessitant un remaniement pour s’aligner sur le SDK v0.50.9. 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 ?
  5. Terra Classic-Specific Research Unforking Synergy : L’unforking d’Orbit Labs supprime les correctifs originaux de Terra, ce qui permet une intégration transparente du SDK v0.50.
  6. Couche de compatibilité ascendante pour la réduction des risques : Cales temporaires pour les modules obsolètes afin d’éviter toute perturbation de la dApp. Mesures de sécurité : Audit par Oak Security (axé sur la migration v0.47 → v0.50). Déroulement et calendrier Phase 1 : Préparation de la mise à niveau (2 semaines) Tâches : Audit du code (après le débridage), correction des problèmes hérités, documentation sur la compatibilité ascendante, configuration du réseau de test. Phase 2 : Exécution de la mise à niveau (5 semaines) Tâches : Intégration du SDK v0.50.9. 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. Phase 3 : Mises à jour progressives, tests 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 jusqu’à la v0.50.9 suivi d’un test fictif.Mises à jour progressives de la chaîne jusqu’à la v0.50.9 suivi d’un test fictif Audits de sécurité, tests de validation, tests de migration de dApp, primes de bogues. Phase 4 : Déploiement du réseau de test (2 semaines) Tâches : Lancement du réseau de test public, intégration des validateurs et des applications, surveillance. Phase 5 : Déploiement du réseau principal (2 semaines) Tâches : Vote de gouvernance, coordination CEX, mise à niveau du réseau principal, suivi post-lancement. Calendrier total : 20 semaines (~5 mois) Phase Durée Activités clés Coût

Phases

  • Pré-mise à jour : 2 semaines Audit du code après le débridage, correction des bogues du SDK v0.47, documentation des changements importants, mise en place d’un réseau de test. $6,000
  • Mise à jour du noyau : 5 semaines Intégrer SDK v0.50.9, Wasm v0.53.2, CometBFT v0.38.11, couches de rétrocompatibilité. $25,000
  • Test et validation : 9 semaines Audits de sécurité, essais de validation, tests de migration de dApp, bug bounties. $12,000
  • Déploiement du réseau de test : 2 semaines Lancement du réseau de test public, intégration du validateur/de l’application, surveillance. $8,000
  • Déploiement du réseau principal : 2 semaines Vote de gouvernance, coordination CEX, mise à niveau du réseau principal, suivi post-lancement. $6,000

Après cette discussion de 48 heures, la proposition sera soumise au vote.

Cette proposition est proposée par #Cookie #FRGValidator et l’équipe de #LUNCVERS3 pour luna classic.

Mise à jour réalisée par Antier Solutions

Considération importante : La mise à jour de wasmd ne peut commencer qu’après l’exécution du “wasmd unfork” d’Orbit Labs, ou bien en coordination avec Orbit Labs dans le cadre d’un effort commun pour combiner le wasmd unfork avec le sdk et la mise à jour de wasmd.

Une nouvelle proposition de dépense sera soumise après chaque étape.

Was this article helpful?
YesNo
E-mail
Password
Confirm Password
QuoraTelegram