Permissions d’émission et de destruction

Source maître EN · P08-L03 · 45 minutes estimées · needs_review

« Émission désactivée » et « destruction activée » semblent simples, mais décrivent des opérations spécifiques selon des règles d’autorisation spécifiques. Un détenteur détruisant ses propres unités diffère d’un administrateur affectant le solde d’un autre détenteur. Un plafond contraint la quantité uniquement si le chemin pertinent l’applique réellement.

Votre tâche est d’énumérer capacités, conditions et périmètre de changement d’offre. Vous évaluez des permissions, sans enseigner l’émission de jetons ni prédire si une autorité agira.

Demander qui peut faire quoi à quel solde

Un relevé de permission doit nommer opération, compte ou rôle de contrôle, périmètre cible, contraintes de quantité et modifiabilité. « Administrateur présent » omet l’information la plus utile. Émettre vers un destinataire, détruire son propre solde et détruire le solde d’un tiers sont des capacités différentes.

Pour chaque chemin, demander si le contrôle concerne l’appelant, une allowance, un rôle ou une condition médiée par programme. Consigner la condition assez littéralement pour reproduire le raisonnement. Un nom de fonction n’est pas son implémentation : une méthode nommée burn peut transférer intérieurement des unités, et une méthode nommée distribute peut en émettre.

Utiliser un tableau de capacités avec pointeurs de preuves. Si une opération a été observée historiquement, cela étaye cet événement ; cela seul ne prouve pas toutes les permissions présentes. Si une permission existe dans un instantané, cela étaye sa disponibilité sous conditions ; cela ne prouve pas qu’elle a été exercée.

Distinguer les chemins standard de destruction

La destruction standard Solana réduit le solde du compte et l’offre du mint. L’autorisation peut provenir du propriétaire du compte de jetons ou d’un délégué approuvé ; la délégation permanente du Token Extension Program ajoute un chemin au niveau du mint [S08-BURN]. Une approbation ordinaire est limitée au compte et montant pertinents, donc ne pas la décrire comme propriété administrative générale.

L’extension PermanentDelegate peut autoriser transferts et destructions entre comptes de son mint ; les propriétaires de comptes de jetons ne peuvent la révoquer localement [S08-DELEGATE]. C’est une raison concrète d’inspecter l’état d’extension plutôt que de conclure que toute autorité disparaît lorsque l’autorité de mint manque. Ne pas déduire l’existence de l’extension uniquement parce que le jeton utilise un programme capable d’extensions.

OpenZeppelin ERC20Burnable distingue destruction de son propre solde et burnFrom fondé sur une allowance. Le comportement plafonné contraint l’émission selon cette implémentation [S08-OZERC20]. La documentation de bibliothèque étaye ces modèles, pas un constat qu’un contrat déployé particulier les inclut. Inspecter code et état réels.

Traiter les plafonds d’offre comme affirmations conditionnelles

Un plafond a une unité et un contexte. Un maximum de 1,200 jetons affichés avec six décimales représente 1,200,000,000 unités brutes. Comparer un total actuel affiché à un plafond brut peut créer une estimation fausse de marge.

Le plafond n’a de sens que pour les chemins qui l’appliquent. Si d’autres chemins contournent le contrôle ou qu’une mise à niveau peut changer la règle, rapporter ces limites. Dans ce jeu, la règle fournie couvre tous les appels d’émission répertoriés selon l’implémentation actuelle. Les implémentations futures sont explicitement hors de l’hypothèse de chemins complets.

Les destructions peuvent réduire l’offre totale et créer une marge selon un plafond de total en cours. Une limite d’émission sur toute la durée de vie est une politique différente. Ne jamais supposer l’une à partir du mot « plafond ». Indiquer si la règle compte l’offre en cours, l’émission cumulée, un budget d’époque ou autre chose.

Inspecter l’administration des rôles

Appartenance au rôle et administration du rôle sont distinctes. Un compte pouvant attribuer un rôle d’émetteur peut créer indirectement de futurs émetteurs même s’il ne peut émettre selon son appartenance actuelle. OpenZeppelin AccessControl utilise des contrôles et une administration propres au rôle ; Ownable est un modèle différent [S08-ACCESS]. Un champ propriétaire générique ne peut résumer chaque chemin d’autorisation.

Suivre la chaîne assez loin pour décrire qui peut modifier la permission. Si un administrateur est un contrat, ses signataires, seuil et délai exigent des preuves distinctes. Un libellé multisignature ne prouve pas un seuil. Si ces détails sont indisponibles, conserver le rôle de contrat et marquer son organisation de contrôle inconnue.

Autorité de changement d’offre et autorité de mise à niveau sont liées mais distinctes. Cette leçon identifie une lacune fournie de mise à niveau ; P08-L04 l’analyse directement. Une conclusion « fixe selon les règles actuelles » ne peut devenir silencieusement « fixe pour toujours » lorsque la logique peut changer.

Distinguer comportement potentiel et événements terminés

Une opération réussie modifiant l’offre exige plus qu’une transaction soumise ou un libellé ressemblant à un événement. Vérifier résultat d’exécution, actif affecté, variation comptable et contexte. Les tentatives échouées ne doivent pas être ajoutées à l’offre. Les transferts vers une adresse inaccessible peuvent réduire les stocks accessibles sans réduire l’offre totale du protocole.

Même une destruction vérifiée ne dit rien sur l’appréciation du prix. Quantité et exécution de marché sont des mesures différentes. De même, un privilège d’émission disponible ne prouve pas une intention malveillante. Un constat professionnel précise périmètre et conditions, puis demande quelles preuves résoudraient les lacunes.

Écrire un constat circonscrit de permissions

Préférer « À S0, M peut augmenter l’offre jusqu’au plafond de total en cours selon la règle actuelle fournie ; G peut attribuer ce rôle » à « le jeton est inflationniste et dangereux ». Le premier est reproductible ; le second combine une classification économique non définie avec une recommandation non étayée.

Lorsque la révocation est fournie, nommer le rôle exact. Le retrait d’autorité Solana est propre au rôle [S08-SET]. Retirer un rôle de mint ne retire pas logiquement un délégué indépendant, un rôle de gel ni un chemin de changement d’implémentation.

• Permission d’émission : capacité d’augmenter l’offre comptable.
• Permission de destruction : capacité de réduire soldes et offre selon une règle.
• Allowance : permission limitée en montant associée à un détenteur et un dépensier.
• Délégué permanent : autorité du Token Extension Program au niveau du mint.
• Plafond en cours : offre présente maximale selon la règle fournie.
• Administrateur de rôle : compte pouvant changer l’appartenance.

ILLUSTRATIVE — FIX-P08-03. Deux actifs fictifs distincts à S0 ; les libellés sont invalides et ne sont pas des instructions d’exécution.

La destruction hypothétique de 40 de E3 précède une émission hypothétique de 220. H a un solde suffisant et les deux opérations réussissent selon les règles fournies. Aucun autre changement d’offre ne survient.

OBSERVED dans le jeu : MINT-P n’a aucune autorité de mint mais a D ; TOKEN-C a un chemin d’émission contraint et un administrateur de rôle.

INFERRED: TOKEN-C a une marge initiale de plafond de 200 ; après destruction de 40 il a 240, donc l’émission de 220 convient et laisse un total de 1,180.

UNKNOWN: Humain contrôlant D, comportement d’extension omis, contrôle de mise à niveau de TOKEN-C et changements futurs de règles.

INSUFFICIENT EVIDENCE: L’absence d’autorité de mint ne prouve pas que les soldes MINT-P ne peuvent être détruits. Un plafond n’établit pas une politique d’offre immuable ni un résultat de prix.

Assimiler révocation de mint et retrait de tous les privilèges ; traiter sa propre destruction comme destruction arbitraire d’un tiers ; ignorer les chemins d’attribution de rôle ; mélanger plafonds bruts/affichés ; et supposer que les destructions garantissent l’appréciation.

Écrire un tableau de capacités pour S1/S2 et E1–E4. Calculer marge initiale et après destruction et offre finale. Évaluer si G peut affecter l’émission future et si J peut détruire 100 de H selon l’allowance fournie.

• Nommer opération, cible et condition.
• Vérifier unités de montant et total actuel.
• Distinguer rôle actuel et administration de rôle.
• Inspecter les extensions pertinentes.
• Distinguer changements d’offre terminés et pouvoirs disponibles.
• Indiquer les chemins non résolus de changement d’implémentation.

Les permissions sont des capacités conditionnelles. Un examen utile distingue création d’offre, destruction de soldes et pouvoir de changer qui peut agir.

Aucun rôle de mint ne signifie pas aucun autre contrôle. Un plafond exige définition et périmètre d’application. La disponibilité d’autorité ne prouve pas une intention.

Créer deux matrices distinctes de permissions pour MINT-P et TOKEN-C avec acteur,opération,cible,condition et ligne de preuve. Ajouter le calcul actuel de plafond200→240→20 de marge restante. Montrer la lacune de mise à niveau comme inconnue, pas absente.

Périmètre d’autorité et plafond d’offre en cours illustratifs ; aucun constat sur un jeton déployé.

Utiliser du SVG/HTML déterministe ou des graphiques avec alternatives textuelles, bleu marine foncé/noir et accents mesurés cyan, bleu électrique et violet. Étiqueter chaque quantité et incertitude. À 390px, empiler les panneaux ; la vérification 768px/ordinateur et RTL arabe reste un travail futur sur les actifs. Garder les identifiants LTR et les axes factuels/sens des arêtes inchangés. Utiliser uniquement la marque officielle BlockAssay fournie si une identité de marque est ajoutée. Les deux enregistrements sont des spécifications, pas des actifs livrés.

Utiliser RADAR pour l’objectif pédagogique circonscrit de la leçon uniquement si la prise en charge du réseau, l’identité exacte, les champs et la provenance sont vérifiés. Ce contenu n’affirme aucun point de terminaison d’exécution ni capacité de fournisseur. Utiliser le jeu hors ligne intégré sans accès payant. Les données manquantes restent inconnues ; aucune connexion de portefeuille, signature de transaction, lancement de jeton ou transaction en direct n’est requis. Les progrès Academy, paiements et recommandations ne changent jamais les preuves Radar. Un Passeport diagnostique préserve observations et limites, pas une prévision de prix ni un certificat de sécurité.

• Destruction de jetons Solana — Autorisation standard de destruction et effet sur le solde de compte et l’offre du mint. Vérifié le 2026-09-30.
• Délégué permanent Solana — Autorité de transfert/destruction au niveau du mint du Token Extension Program. Vérifié le 2026-09-30.
• OpenZeppelin 5.x ERC20 — Extensions de destruction, plafond et pause ; le comportement d’une bibliothèque ne prouve pas le code déployé. Vérifié le 2026-09-30.
• Contrôle d’accès OpenZeppelin 5.x — Modèles de privilèges Ownable et par rôles ; inspecter l’autorisation réellement déployée. Vérifié le 2026-09-30.
• Définir l’autorité Solana — Changements et révocation propres au rôle ; pas un verdict global de sécurité. Vérifié le 2026-09-30.

La documentation étaye les mécanismes, pas les valeurs fictives du jeu. Tous les exemples et enregistrements d’exercice sont du matériel original ILLUSTRATIVE, figé dans ce fichier. S0/S1 sont des libellés synthétiques de contexte ; observedAt est null car aucune mesure de registre en direct ou historique n’a été collectée. Réexaminer la documentation et le comportement réellement déployé avant toute publication ou intégration.

P08-L04 après l’exercice corrigé et l’examen du quiz.