12142 | Proposition de texte – Suppression des modules bifurqués de Terra Classic
Résumé
OrbitLabs propose de supprimer les modules principaux de la blockchain Terra Classic afin d’améliorer la maintenabilité, de réduire la dette technique et de s’aligner sur l’écosystème Cosmos au sens large.
Pour une présentation complète de nos équipes et de nos qualifications, veuillez consulter : https://hackmd.io/@orbitlabs/SJiDiG22A
Situation actuelle
La base de code de Terra Classic utilise actuellement plusieurs versions forkées des modules Cosmos pour prendre en compte ses caractéristiques uniques. Ces forks ont entraîné une divergence croissante entre la base de code et les modules en amont, ce qui augmente les coûts de maintenance tant que cela perdure.
Avec les versions actuelles de Luna Classic et les modules en amont, nous avons maintenant la possibilité de.. :
- Supprimez les modules forkés maintenus par l’équipe Terra Classic
- Intégrer les modules standard en amont
- Changements spécifiques au module Terrad lui-même pour Port Terra Classic
Cette approche permettrait à Terra Classic d’hériter des titres et des fonctionnalités les plus récents de l’équipe de développement de Cosmos, ce qui réduirait considérablement les coûts et le temps consacrés à la maintenance.
Terra Classic Personnalisations/Fourches
#### CosmosSDK :
- Logique personnalisée pour OracleTx : Prise en charge de la gestion de la priorité des transactions Oracle.
- Logique de mise en jeu personnalisée : Limitez le pouvoir de vote des validateurs à 20 %.
#### CometBFT (anciennement Tendermint) :
- Transactions Oracle : Ajout d’une fonctionnalité permettant de traiter les transactions Oracle spécifiques à Terra Classic.
#### Wasmd
- Dépréciation des clés : Les clés actuelles utilisées dans la fourche Wasmd de Terra Classic sont dépréciées. Cela affecte la façon dont les données liées au contrat sont stockées et accessibles dans l’état de la blockchain.
Conséquences de l’inaction
Si nous n’abordons pas cette question :
Augmentation des coûts de maintenance
Comme Terra Classic continue à maintenir des versions forkées des modules de base de Cosmos, la charge de maintenir ces forks en synchronisation avec les développements en amont augmentera. Cela nécessitera des ressources importantes de la part des développeurs pour gérer les mises à jour, les corrections de bogues et la compatibilité, ce qui se traduira par une augmentation des coûts d’exploitation.
Améliorations manquées en amont
En s’écartant du SDK Cosmos principal et des modules associés, Terra Classic risque de prendre du retard dans l’adoption d’améliorations clés et de nouvelles fonctionnalités développées par l’ensemble de la communauté Cosmos. Cela peut limiter la compétitivité de Terra Classic et rendre plus difficile l’intégration des technologies futures, des mises à jour, des améliorations de performance et d’autres innovations.
Risques accrus en matière de sécurité
L’adoption tardive des correctifs de sécurité et de vulnérabilité en amont exposera la chaîne Terra Classic à des exploits potentiels. Plus Terra Classic restera sur des modules forkés et obsolètes, plus le risque d’être affecté par des vulnérabilités connues qui ont déjà été corrigées dans l’écosystème Cosmos sera grand.
Un écosystème de développeurs restreint
Une base de code de plus en plus décalée par rapport à l’écosystème principal de Cosmos pourrait décourager les développeurs de L1 de contribuer à Terra Classic. Les développeurs seraient confrontés à une complexité supplémentaire dans l’apprentissage de la base de code, ce qui pourrait limiter l’innovation et l’engagement des développeurs.
Solution proposée
Nous proposons de supprimer les modules principaux forkés et de les remplacer par les modules standards de Cosmos. Ce processus sera divisé en deux phases
Phase 1
- Déboucher CometBFT de la version 0.37.4-terra1 vers la version principale 0.37.4
- Il s’agira de mettre à jour le moteur de consensus pour l’aligner sur la version 0.37.4 de CometBFT.
- Des tests approfondis seront nécessaires pour garantir la stabilité du réseau.
- Mise à jour de CosmosSDK de v0.47.10-terra.1 à v0.47.10
- Migrer vers la version v0.47.10 de CosmosSDK qui est compatible avec notre version cible v0.37.4 de CometBFT.
- Identifier et résoudre tout conflit avec les caractéristiques spécifiques de Terra Classic
- Déplacer l’oracle et la logique des enjeux vers Terrad
- Refonte du module oracle pour le rendre compatible avec la mise à jour du CosmosSDK.
- Veillez à ce que toutes les fonctionnalités d’Oracle spécifiques à Terra Classic soient conservées.
Phase 2
Migration de Wasmd de v0.46.0-classic.1 vers la version principale Wasmd v0.46.0
- Migration du magasin du contrat, pour assurer la compatibilité avec les contrats intelligents existants
- Tests approfondis de l’exécution des contrats et des migrations d’état
- Tests unitaires : Mise à jour des tests unitaires existants et création de nouveaux tests unitaires pour la logique de migration des magasins de contrats, les migrations d’état.
- Tests d’intégration : Développez des tests de bout en bout simulant l’ensemble du processus de migration, y compris le déploiement et l’exécution des contrats, ainsi que les interactions multi-contrats.
- Test de l’instantané de l’état : Importez un instantané de l’état actuel de la blockchain, effectuez une migration à blanc, vérifiez les états et les fonctionnalités du contrat après la migration et testez les procédures de retour en arrière.
Avantages
- Amélioration de la maintenabilité et réduction de la dette technique
- Adoption plus facile des futures mises à jour de CosmosSDK
- Amélioration de la sécurité grâce à une mise en œuvre plus rapide des correctifs en amont
- Amélioration de l’interopérabilité avec d’autres chaînes basées sur Cosmos
- Possibilité d’attirer plus de développeurs Cosmos dans l’écosystème Terra Classic
Calendrier et étapes
Phase 1 (estimée à 8 semaines) :
- Semaine 1 : Analyse détaillée et planification
- Semaines 2-3 : CometBFT unfork et intégration
- Semaines 4-5 : Mise à jour du CosmosSDK et résolution des conflits
- Semaine 6 : Migration d’Oracle et de la logique de jalonnement vers Terrad
- Semaines 7-8 : Tests approfondis, examen par la communauté et préparation du déploiement du réseau test.
Phase 2 (estimée à 10 semaines) :
- Semaines 1-2 : Planification de la migration Wasmd et mise en œuvre initiale
- Semaines 3-6 : Intégration de Wasmd et tests de compatibilité des contrats
- Semaines 7 et 8 : Tests à l’échelle du réseau et optimisation des performances
- Semaines 9-10 : Examen final, documentation et préparation du déploiement de Testnet.
Budget
Budget total demandé : Le paiement sera divisé en deux phases et fera l’objet de deux propositions de dépenses distinctes.
Phase 1
Valeur Fiat : 16 000 USD
Phase 2
Valeur Fiat : 20 000 USD
*Valeur totale de la monnaie fiduciaire : 36 000 USD
*Note : Le montant réel de LUNC pour chaque phase sera calculé en fonction du prix en temps réel de LUNC au moment de la soumission de chaque proposition de dépense.
Certification KYC
Conformément à la proposition #12129, les révisions approuvant le code sur les dépôts de Terra Classic doivent être effectuées par des personnes KYCées. OrbitLabs est contrôlé par sollidproof.io.
https://github.com/solidproof/Projects/blob/main/2024/Kien/KYC_Certificate_SolidProof_Individual_Kien.jpg
https://github.com/solidproof/Projects/blob/main/2024/Tien/KYC_Certificate_SolidProof_Individual_Tien.jpg
https://github.com/solidproof/Projects/blob/main/2024/Tuan%20Tran%20/KYC_Certificate_SolidProof_Individual_TuanTran.jpg
Mise à jour de l’état d’avancement des travaux
Nous fournirons des rapports d’avancement hebdomadaires ou bihebdomadaires tout au long du projet afin de garantir la transparence et de tenir la communauté Terra Classic informée de tous les développements. Afin de maximiser l’engagement et de fournir des mises à jour en temps réel, nous utiliserons plusieurs canaux de communication, comme indiqué ci-dessous :
Mises à jour de Twitter
- Nous fournirons des mises à jour régulières via notre site officiel [Twitter account] (https://twitter.com/orbit__labs). Ces mises à jour porteront sur les principales étapes, les progrès du développement, les difficultés rencontrées et les éventuels ajustements du calendrier. Twitter servira également de plateforme pour répondre aux demandes de la communauté et fournir de brèves mises à jour.
- En plus des mises à jour spécifiques au projet, nous fournirons des informations générales sur les développements de la blockchain et les discussions de gouvernance liées à Terra Classic.
Commits GitHub
- Toutes les modifications du code seront accessibles au public dans nos dépôts officiels GitHub. Chaque livraison sera accompagnée d’un message de livraison détaillé expliquant la portée de la modification, la raison d’être de la modification et toutes les considérations techniques connexes.
- Les demandes de retrait (PR) seront accompagnées d’une documentation complète et seront soumises à l’examen de la communauté. Nous encourageons les développeurs de la communauté à participer aux discussions sur ces PR afin de garantir une transparence et une collaboration maximales.
AMA de la Communauté
- Lors d’étapes clés (telles que l’achèvement de phases majeures), nous organiserons des sessions “Ask Me Anything” (AMA). Elles permettront à la communauté de poser des questions directement à l’équipe de développement.
- Les AMA seront organisés sur Twitter Spaces. Nous annoncerons les AMA à l’avance via Twitter, et les principaux enseignements tirés de ces sessions seront résumés dans les mises à jour post-AMA.seront résumés dans les mises à jour post-AMA.
Medium/HackMD Blog Posts :
Pour des mises à jour plus approfondies et plus détaillées, nous publierons périodiquement des articles de blog sur Medium/HackMD. Ces articles serviront de rapports complets comprenant des aperçus de projets, des défis techniques, des résolutions et des feuilles de route pour l’avenir.
Conclusion
En supprimant les modules principaux forkés, nous souhaitons positionner Terra Classic pour une durabilité et une croissance à long terme au sein de l’écosystème Cosmos. Nous pensons que cette approche permet d’équilibrer le besoin d’amélioration avec une gestion prudente des risques et l’implication de la communauté.
Nous souhaitons recevoir les commentaires et les discussions de la communauté Terra Classic sur cette proposition.
Détails
- Auteurs :OrbitLabs
- Lien du forum de proposition : https://commonwealth.im/terra-luna-classic-lunc/discussion/24923-proposal-removal-of-forked-modules-from-terra-classic
Vote_option_context
- Oui : soutenir la proposition d’OrbitLabs de supprimer les modules forkés de la base de code de Terra Classic.
- Non : S’opposer à la proposition d’OrbitLabs de supprimer les modules forkés de la base de code de Terra Classic.
- Abstention : vous n’avez pas d’opinion tranchée et vous accepterez la décision de la majorité.
- Non avec veto : Vous estimez que cette proposition est nuisible et ne devrait pas être mise en œuvre.

