Conception des autorités et mises à niveau

« Renoncé » décrit imparfaitement les contrôles si un administrateur proxy, un rôle de création séparé ou une autorité de pause demeure. Une carte de permissions doit nommer la fonction concernée et toutes les voies pertinentes.

Inventoriez les capacités : création, destruction, pause, liste noire ou restrictions de transfert, mise à jour des métadonnées, changement des frais et mise à niveau de l’implémentation. Certaines peuvent ne pas exister ; leur absence exige des preuves d’implémentation, pas un bouton manquant. Nommez le rôle ou l’autorité pouvant invoquer chaque voie, sa délégation/récupération et ses conditions de changement.

Une révocation est limitée à une capacité particulière. Retirer la propriété du token ne retire pas intrinsèquement l’administrateur de mise à niveau du proxy ou un autre rôle privilégié. Les emplacements proxy normalisés aident à localiser certains champs d’implémentation/admin ; les conceptions personnalisées exigent leurs propres preuves. Multisignature et délais peuvent modifier les conditions d’exécution ; ils ne prouvent ni indépendance des signataires ni disparition de tout risque de compromission.

Pour chaque contrôle conservé proposé, déclarez conséquence pratique et raison d’être. Pour chaque transfert ou révocation, listez voies résiduelles et vérifications nécessaires. Ne transformez pas une déclaration paraissant irréversible en score de sécurité. Cette leçon ne change aucun rôle et n’exécute aucune transaction.

Capacité : action privilégiée accessible par une voie précise.

Révocation de rôle : suppression d’une relation d’autorisation.

Voie de mise à niveau : mécanisme pouvant changer le comportement de l’implémentation.

Contrôle résiduel : capacité restant après un changement déclaré.

ILLUSTRATIVE carte Cedar : rôle de création M ; rôle de pause P ; administrateur proxy U ; éditeur de métadonnées D. Un changement proposé révoque M mais conserve P, U, D. U est décrit comme 2-of-3 avec délai de 24 heures ; indépendance des signataires et application déployée ne sont pas étayées.

Carte des permissions avec nœuds M, P, U, D avant/après révocation proposée de M. Conservez U/P/D comme voies pleines retenues ; annotez2-of-3/24h comme hypothèses de conception non vérifiées.

Légende : Révocation fictive propre à un rôle ; les voies de mise à niveau et pause conservées restent visibles.

SPECIFICATION_ONLY — le visuel rendu n’a pas été produit ni examiné indépendamment.

La carte fictive montre que la révocation proposée du rôle de création laisse trois capacités déclarées. Le 2-of-3 et le délai ne sont que des affirmations de conception.

Il n’existe ni état de rôle déployé, multisig vérifié, révocation réelle, garantie permanente d’offre ni preuve de signataires indépendants. U pourrait changer le comportement si l’implémentation proposée le permet.

Appeler révocation de M « tous les contrôles retirés » ; supposer que multisig prouve des personnes indépendantes ; traiter un délai comme un audit ; ignorer voies de métadonnées ou frais.

Produisez des lignes de capacités avant/après et reformulez « Cedar a tout renoncé et ne peut changer ». Indiquez deux contrôles nécessaires avant toute affirmation de révocation réelle.

• Inventorier chaque voie privilégiée substantielle.
• Décrire révocation spécifique et contrôle résiduel.
• Qualifier hypothèses de signataires et délai.
• Séparer affirmations de conception et état déployé.

La déclaration des contrôles est propre à chaque capacité ; un rôle retiré ne prouve pas un actif immuable ou sans autorité.

• Une révocation a un périmètre.
• Les voies de mise à niveau et délégation peuvent conserver le contrôle.
• Une étiquette multisig ne prouve pas l’indépendance des signataires.

P12-L04

Utilisez l’outil BlockAssay nommé uniquement comme contexte de lecture des preuves. Cette leçon ne crée aucune sortie d’outil, session de compte ni droit d’accès. Exercice hors ligne ; ne signez, ne déployez, n’approuvez et ne financez rien.

• PROXY: Emplacements de stockage du proxy ERC-1967 — Emplacements normalisés d’implémentation/admin ; renoncer à un rôle ne prouve pas que toutes les voies de mise à niveau sont désactivées. Limite : Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.
• ERC20: Norme ERC-20 — Interface du token et sémantique des autorisations ; la norme n’établit ni l’identité de l’émetteur ni la sécurité des permissions. Limite : Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.

ILLUSTRATIVE — entrées hors ligne entièrement fictives ; aucune observation actuelle.

null — aucune observation réelle

1

null

needs_review