Gel, propriété et autorité

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

Un badge « propriété abandonnée » peut coexister avec un rôle actif de pause ou un contrôleur de mise à niveau. Une autorité de mint retirée peut coexister avec une autorité de gel. Ces affirmations peuvent chacune être vraies tandis que la conclusion générale « personne n’a de contrôle » est fausse.

Cette leçon enseigne une carte de contrôle par couches. Vous relierez chaque privilège à son objet, détenteur actuel, condition et chemin possible d’administration. Le résultat est un relevé de preuves, pas une note de sécurité ni une accusation.

Définir l’objet contrôlé

Ne pas utiliser propriétaire sans nom d’objet. Le programme propriétaire d’un compte de données Solana, une autorité de compte de jetons, un propriétaire EVM Ownable et un propriétaire de position NFT sont des champs distincts. Leurs noms se ressemblent mais régissent des mécanismes différents. Écrire le champ et l’objet à côté de la valeur.

Distinguer contrôle de solde de jeton, restrictions au niveau du mint, rôles d’application et autorité de changement de code. Un constat sur une couche ne peut effacer une permission d’une autre. Par exemple, un mint de jeton peut manquer d’autorité de mint tandis qu’une application interagissant avec le jeton reste modifiable. Examiner séparément le rôle de l’application plutôt que de supposer qu’elle régit le Token Program standard lui-même.

Une carte de contrôle est un graphe de capacités, pas d’identités humaines. Une autorité répertoriée peut être un compte utilisateur ou une adresse médiée par programme. Les libellés publics de comptes n’établissent pas qui a les clés ni si plusieurs comptes partagent un contrôleur.

Comprendre le gel comme restriction d’état

Le mécanisme de gel Solana préserve propriétaire, mint et solde du compte de jetons tout en empêchant les opérations documentées de réception, transfert et destruction jusqu’au dégel [S08-FREEZE]. Ce n’est ni une suppression de solde ni un transfert à l’autorité de gel.

État et autorité doivent être consignés séparément. Une autorité de gel peut exister tandis qu’un compte est actuellement non gelé. Inversement, observer un état gelé ne dit pas qu’un humain particulier l’a causé. Demander l’opération réussie et son autorisation si l’attribution compte.

La révocation retire un rôle d’autorité choisi, pas un ensemble universel de pouvoirs [S08-SET]. Ne pas supposer qu’une révocation de rôle de mint a changé l’état de gel. Les comptes gelés existants et les chemins possibles de récupération/dégel exigent leur propre examen ; éviter de décrire une révocation étroite comme preuve que chaque compte est transférable.

Inspecter les rôles d’application au-delà de Ownable

L’abandon Ownable d’OpenZeppelin désactive les fonctions protégées par son contrôle de propriétaire, tandis que les permissions par rôles sont un modèle distinct [S08-ACCESS]. Le fait qu’un jeton déployé combine ces modèles est une question de code et d’état. Si un rôle de pause subsiste, l’abandon du propriétaire seul ne peut le retirer.

Construire un tableau pour propriété, pause, attribution/révocation de rôles et mises à niveau. Pour chaque ligne, consigner contrôle réel, autorité présente, chemin d’administration et incertitude. Un nom de rôle est seulement descriptif tant qu’il n’est pas lié à une opération accessible. « PAUSER » dans des métadonnées ne prouve pas une fonction de pause.

Un contrôle peut dépendre d’un verrou temporel ou d’une multisignature. Vérifier contrat pertinent, seuil, délai et conditions de contournement plutôt que d’accepter un badge. Un délai est une condition temporelle, pas une disparition du contrôle. Un seuil multisignature décrit des signatures, pas nécessairement des humains indépendants.

Retracer le contrôle du proxy et de l’implémentation

Pour les proxies de type ERC-1967, distinguer le lien d’implémentation ou de beacon de l’emplacement facultatif d’administrateur. Un beacon résout la logique pour les proxies associés ; l’autorisation de type UUPS peut résider dans la logique d’implémentation, donc un emplacement d’administrateur vide seul n’est pas une conclusion complète [S08-PROXY; S08-UUPS].

L’adresse de proxy utilisée par l’utilisateur peut rester identique lorsque ses règles changent. Fixer l’implémentation au contexte examiné, puis inspecter le chemin pouvant la changer. Ne pas auditer une page d’implémentation vérifiée en laissant le lien de proxy non vérifié. Une implémentation ultérieure peut invalider les hypothèses antérieures de comportement.

Cette leçon n’enseigne pas l’exécution de mises à niveau. Elle enseigne comment décrire le chemin fourni d’autorisation en lecture seule. Si les règles internes du contrôleur sont indisponibles, les marquer inconnues même lorsque l’adresse d’autorité externe est connue.

Distinguer mises à niveau de programme Solana et rôles de mint

Selon le loader-v3 Solana, les mises à niveau de programme dépendent de l’autorité de mise à niveau ; retirer cette autorité rend ce programme immuable [S08-DEPLOY]. Ce n’est pas le champ d’autorité de mint du mint. Cela s’applique au programme examiné et au mécanisme de chargeur, pas à chaque contrat connecté ni service hors chaîne.

Un mint régi par un Token Program standard ne doit pas être décrit à la légère comme modifiable indépendamment simplement parce qu’une application personnalisée l’utilise. Nommer le programme personnalisé et expliquer sa pertinence. Dans le jeu, PROGRAM-X est une application auxiliaire, pas le Token Program propriétaire de MINT-F.

L’immutabilité est limitée à l’objet de code. Elle ne prouve pas des utilisateurs honnêtes, des métadonnées immuables, une liquidité suffisante ni des systèmes environnants sécurisés. De même, une autorité active de mise à niveau prouve une capacité sous conditions, pas que le code changera de façon malveillante.

Rapporter un résultat par couches

Une phrase défendable nomme contexte et limites : « À S0, le champ propriétaire est abandonné, tandis que PAUSER reste attribué et le contrôleur de mise à niveau du proxy est fourni mais son seuil interne est inconnu. » Cela informe davantage qu’un libellé catégorique « décentralisé ».

Demander si une affirmation peut être réfutée par une seule ligne restante. « Aucun contrôle privilégié » est contredit par une seule capacité active prouvée. Une affirmation étroite comme « le rôle de propriétaire Ownable est absent » peut rester étayée même lorsque l’énoncé général échoue. Préserver les deux.

• État de gel : restriction d’opérations sur un compte de jetons.
• Propriétaire Ownable : autorité selon un modèle particulier de contrôle de propriétaire.
• Détenteur de rôle : compte satisfaisant un contrôle spécifique d’appartenance.
• Contrôleur de mise à niveau : autorité régissant un chemin de changement de code.
• Beacon : mécanisme reliant la logique d’un proxy.
• Verrou temporel : condition imposant un délai à des opérations précisées.

ILLUSTRATIVE — FIX-P08-04. Objets fictifs distincts à S0.

PROGRAM-X n’est pas le Token Program régissant MINT-F. Le jeu ne fournit pas les effets de code reliant cette application auxiliaire au mint.

OBSERVED dans le jeu : F subsiste, V est gelé, P/G subsistent et C/U sont des autorités fournies de mise à niveau.

INFERRED: « Tous les contrôles retirés » est contredit par ces capacités distinctes. Le propriétaire abandonné est un énoncé plus étroit étayé concernant P2.

UNKNOWN: Règles internes de C, contrôleurs humains, qui a gelé V et effets applicatifs exacts de PROGRAM-X.

INSUFFICIENT EVIDENCE: Le gel ne signifie pas que le solde de V a été détruit. Un propriétaire absent ne prouve pas l’absence de rôles ni de mises à niveau. U ne prouve pas que le Token Program standard est contrôlé par U.

Utiliser propriétaire sans son objet ; confondre solde gelé et zéro ; supposer qu’un emplacement administrateur de proxy vide exclut toutes les mises à niveau ; interpréter un libellé multisignature comme contrôle indépendant vérifié ; et fusionner autorité de programme auxiliaire et autorité de mint.

Produire quatre couches de contrôle : état de compte, rôles de mint, rôles d’application EVM et chemins de changement d’implémentation. Réécrire « toute propriété est abandonnée donc tout est immuable ». Lister les prochaines preuves requises pour C et V.

• Nommer l’objet de chaque champ propriétaire.
• Distinguer autorité et état actuel.
• Inspecter les rôles après abandon de propriété.
• Résoudre logique et chemins de mise à niveau dans le même contexte.
• Vérifier seuils/délais plutôt que libellés.
• Limiter l’immutabilité à l’objet examiné.

Le contrôle a plusieurs couches. Un rôle retiré établit un fait étroit ; les rôles actifs et chemins de changement de code exigent un examen distinct.

Le gel est une restriction, pas une suppression. L’abandon du propriétaire n’est pas l’abandon de tout contrôle. Les autorités de proxy, programme et mint sont distinctes.

Carte de permissions à quatre pistes avec pointeurs F1–F3,P1–P3,X1 ; montrer le solde gelé inchangé 50. Dessiner PROXY-Q→LOGIC-Q et le contrôleur C distinct ; PROGRAM-X/U isolé de MINT-F. Marquer la configuration de C inconnue.

Contrôles illustratifs par couches ; l’absence de propriétaire est une affirmation étroite.

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é.

• Proxy OpenZeppelin 5.x — Mécanismes de mise à niveau transparent, beacon et UUPS fondé sur l’implémentation ; l’autorisation réelle exige une inspection. Vérifié le 2026-09-30.
• Gel de compte Solana — Restrictions d’état de compte distinctes du montant ou de la propriété. 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.
• 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.
• Emplacements de stockage de proxy ERC-1967 — Emplacements d’implémentation, beacon et administrateur facultatif ; inspection propre au mécanisme. Vérifié le 2026-09-30.
• Déploiement de programme Solana — Autorité de mise à niveau de programme loader-v3 ; pas un rôle de mint de jeton. 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-L05 après l’exercice corrigé et l’examen du quiz.