Février 2026 : proposition de suppression et de nettoyage des contrats
Nom complet de cette proposition : « [CIP-050] Ajouter une fonctionnalité de suppression au registre des contrats et nettoyer les contrats orphelins LayerZero »
La période de vote se termine le jeudi 12 février à 11h00 CET
Description
Résumé
Cette proposition vise à mettre à niveau le registre des contrats sur Chiliz Chain afin d’inclure une removeContract fonction. De plus, elle autorise la suppression immédiate de deux adresses de contrats orphelines qui ont été ajoutées au registre à la suite d’un échec de déploiement. Ce nettoyage est un prérequis pour achever l’intégration omnichaîne de LayerZero.
Contexte
Dans le cadre de notre initiative omnichaîne, Chiliz Chain s’intègre à LayerZero. Lors de la configuration initiale du registre, deux adresses de contrats ont été ajoutées par erreur en raison d’un échec de déploiement. Actuellement, le registre des contrats ne dispose pas d’une fonction native permettant de supprimer ou de « désenregistrer » une adresse une fois qu’elle a été ajoutée.
Spécification technique
Ajout de fonction : implémenter une
removeContracts(address[] memory impls)fonction au sein du contrat DeployerProxy.Contrôle d’accès : cette fonction sera restreinte à
ONLY_GOVERNANCEafin d’empêcher toute suppression non autorisée.
Nettoyage de l’état : exécuter la suppression des deux adresses suivantes :
0x000000000000b361194cfe6312EE3210d53C15AA0x00000000000001E4A82b33373DE1334E7d8F4879
Motivation
La présence de ces adresses orphelines crée un conflit dans la logique d’intégration de LayerZero, empêchant le mappage réussi du mainnet de Chiliz Chain.
La suppression de ces entrées permettra de :
Débloquer l’expansion omnichaîne.
Garantir que le registre des contrats reste une « source de vérité » sans données obsolètes ou défectueuses.
Fournir à la gouvernance un mécanisme standard pour corriger de futures erreurs de déploiement.
Risques
Le risque est minime, car la fonction est protégée par le consensus de gouvernance. La suppression de ces adresses spécifiques est sans danger, car elles pointent vers des déploiements échoués/non fonctionnels qui ne sont actuellement utilisés par aucun service en production.
Mis à jour
Ce contenu vous a-t-il été utile ?