Autorisations, allowances et révocation

Source maître EN · P03-L04 · needs_review

Étude exclusivement hors ligne/en lecture seule. Ne fournissez jamais de secrets, de mots de passe ni de codes d’authentification. Aucune connexion de portefeuille, autorisation réelle, révocation en direct, signature de transaction, aucun transfert, fonds ou échange. Les visuels sont uniquement des spécifications.

Les permissions sont propres à un actif, un spender et un contexte. Une allowance nulle peut soutenir une conclusion utile tandis que les autres tokens et les autorisations signées restent non résolus.

Nommer le tuple complet

ERC-20 décrit la sémantique d’allowance, approve et transferFrom [ERC20]. Une ligne de permission nécessite réseau, token, owner, spender et contexte d’observation. Un autre token constitue une autre permission, même lorsque le spender affiché est identique.

Lire l’état plutôt que les libellés de session

R1 et R3 montrent le même tuple dans deux contextes stipulés. R2 montre une déconnexion d’interface ; elle ne décrit pas de changement d’état du contrat de token. Une révocation demandée, une action soumise et l’état résultant seraient des étapes de preuves distinctes. R3 est fournie hors ligne ; l’apprenant ne doit pas envoyer de révocation en direct.

R4 concerne TOKEN-B et ne peut pas être fusionnée avec la ligne de TOKEN-A. Ne rapporter que le zéro rassurant en omettant l’autre ligne ferait perdre une partie importante du périmètre. Préservez les deux valeurs et expliquez à quelle question chacune répond.

Conserver les autorisations signées non résolues lorsque nécessaire

Un permit possède une sémantique distincte de signature, nonce et deadline selon les règles du contrat applicable [PERMIT]. R5 omet délibérément sa relation avec l’état actuel du nonce et de la consommation. Une allowance nulle n’établit pas que chaque signature encore en circulation est invalidée. La suite requise concerne les règles applicables et l’état pertinent, et non une autre transaction pédagogique en direct.

Un état d’allowance n’annule pas non plus un transfert antérieur et n’établit pas qu’un owner n’a jamais exposé d’éléments de récupération. L’inventaire des permissions et l’exposition d’une capacité de signature constituent des questions de recherche distinctes.

Énoncer des résultats limités

OBSERVED : valeurs du jeu de données et état de session. INFERRED : passage du tuple sélectionné de 100 à zéro. UNKNOWN : inventaire complet des permissions et possibilité d’utilisation de R5. INSUFFICIENT EVIDENCE : « tous les actifs sont sûrs ». Une conclusion limitée nomme le tuple sélectionné à H12 et laisse les lignes distinctes non résolues.

• Allowance : valeur de permission limitée à un périmètre.
• Spender : rôle d’autorisation applicable.
• Preuve de révocation : état résultant de la permission dans un contexte.
• Couverture : lignes de permissions effectivement fournies.

Fiches ILLUSTRATIVE. R1 SIM-N/TOKEN-A/OWNER-X/SPENDER-Y à SIM-H10, allowance 100 unités entières du jeu de données. R2 interface déconnectée à T1. R3 même tuple à H12, allowance 0. R4 TOKEN-B, mêmes owner et spender à H12, allowance 80. R5 résumé de permit TOKEN-A avec relation au nonce actuel et à la consommation UNKNOWN. Aucune autorisation réelle, signature ou transaction.

Matrice tuple/contexte. R1→R3 est une comparaison sélectionnée ; R4 reste à 80, R5 est inconnue. Placer R2 dans une ligne de session sans arête automatique vers un état onchain.

Les états sélectionnés du jeu de données et leur comparaison dans un périmètre défini.

Une révocation en direct, une réinitialisation complète des permissions, l’invalidation de tous les permits, l’annulation d’une perte ou une sécurité garantie.

• Qualifier une déconnexion de révocation.
• Généraliser un zéro à tous les tokens.
• Supposer qu’un état nul annule chaque signature.

Construisez les lignes de permissions R1, R3 et R4. Expliquez les limites de R2 et R5. Réécrivez « la déconnexion et le zéro rendent chaque actif sûr ».

Remettez un tableau et une conclusion délimitée en utilisant uniquement le matériel hors ligne fourni. Répartition éditoriale du temps : étude 12 min, exercice 8 min, correction/quiz 10 min.

• Tuple et contexte complets.
• Session et état séparés.
• Demandes et résultats séparés.
• Tokens différents maintenus distincts.
• Lacunes concernant les signatures encore en circulation nommées.

Une conclusion sur une permission est contextuelle. Une déconnexion et une allowance nulle n’établissent pas une réinitialisation complète des autorisations ou la sécurité des actifs.

• Examiner le spender, le montant et les limites de révocation
• Lire les tuples complets d’allowance et leurs contextes.
• Limiter la portée d’un état nul sans affirmer que toutes les autorisations sont réinitialisées.

P03-L05 après revue des prérequis et de la correction.

NONE dans le catalogue de référence. Les données hors ligne fournies suffisent ; aucun achat de produit ni aucune opération de portefeuille n’est requis.

• [ERC20] Norme de jeton ERC-20 — approve, allowance et transferFrom pour les interfaces conformes.
• [PERMIT] Autorisations signées ERC-2612 — Autorisation d’allowance par permit avec owner, spender, value, nonce et deadline.

La documentation explique les mécanismes. Les enregistrements historiques conservent leur classe de source déclarée. L’inspection d’une source ne constitue pas une acceptation éditoriale indépendante.