Signatures, messages et transactions

Source maître EN · P03-L03 · 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.

Le libellé d’une demande peut indiquer une connexion alors que ses champs autorisent une dépense. La demande réelle et les preuves ultérieures d’exécution doivent être évaluées séparément.

Classer l’autorisation

Les transactions portent des instructions signées [ETH_TX]. Les messages peuvent aussi autoriser des actions d’application. EIP-712 définit la signature structurée et le contexte de domaine ; la gestion du rejeu reste de la responsabilité de l’application [TYPED]. ERC-2612 fournit un mécanisme d’allowance signé utilisant owner, spender, value, nonce et deadline [PERMIT]. Aucune signature n’est créée dans cette leçon.

Comparer trois résumés hors ligne

R1 stipule une déclaration de type connexion, R2 une demande de type permit et R3 une demande de transfert. Le libellé de connexion de R2 ne supprime pas les champs spender/value. R1 ne possède pas d’autorité stipulée sur les actifs, mais son innocuité en dehors de l’exercice simplifié n’est pas établie. Un bouton générique de signature ne permet pas de déterminer quel rôle une application donnera au contenu signé.

Préserver le périmètre

Lisez le réseau/domaine, le contrat vérificateur, l’autorité, le spender, le montant, le nonce et la deadline lorsque ces champs s’appliquent. S’ils manquent, consignez UNKNOWN au lieu d’emprunter les champs d’une autre fiche. Un champ de nom de domaine familier n’authentifie pas indépendamment un projet. Le nonce et l’expiration nécessitent les règles de l’application qui accepte l’autorisation ; un format seul n’est pas une politique complète de sécurité.

Un permit peut être soumis par une autre partie selon les règles du contrat concerné. L’absence d’une transaction avec gas soumise par le signataire ne prouve donc pas qu’un message ne peut pas autoriser une allowance. Inversement, une demande de permit affichée ne prouve pas qu’une signature existe ou a été consommée.

Conserver les étapes dans le rapport

Demandé, signé, soumis et exécuté constituent des lignes distinctes. Seules des demandes sont fournies ici. OBSERVED : les résumés et les libellés. INFERRED : le classement selon les schémas stipulés. UNKNOWN : la production de signatures et l’exécution. INSUFFICIENT EVIDENCE : une perte, une intention malveillante ou une identité humaine. Évaluez la capacité sans formuler d’accusation et arrêtez-vous sans rien signer.

• Message typé : contenu structuré de signature.
• Permit : mécanisme applicable d’autorisation signée.
• Séparation de domaines : contexte de périmètre, et non preuve d’identité.
• Nonce : valeur vérifiée par rapport à l’état du contrat qui accepte l’autorisation pour distinguer les autorisations ; ERC-2612 incrémente le nonce de son owner lorsqu’un permit réussit.
• Deadline : dernier moment auquel un permit ERC-2612 peut être accepté selon ses règles, et non garantie d’exécution.
• Consommation : utilisation de l’autorisation par l’application ou le contrat.

Résumés ILLUSTRATIVE expurgés, et non des charges utiles signables. R1 login/SIM-LOGIN/SIM-CHALLENGE, aucune permission sur des actifs stipulée. R2 libellé login, type Permit, owner SIM-A, spender SIM-S, value 500 unités entières du jeu de données, nonce 4, deadline SIM-T3, domain SIM-N/contract SIM-C. R3 demande de transfert de 7 unités SIM vers SIM-B sur SIM-N. Aucune signature, calldata ou reçu.

Matrice de permissions : libellé, type, périmètre et preuves d’exécution. Mettre en évidence R2 Permit/SIM-S/500 malgré le libellé de connexion. Toutes les fiches s’arrêtent avant la signature ; aucune charge utile exploitable ni bouton de transaction.

Les champs des demandes et les classements stipulés de capacités.

Une signature, une inclusion, une perte d’actifs, une protection complète contre le rejeu ou une intention humaine malveillante.

• Qualifier tous les messages de connexions inoffensives.
• Interpréter l’absence de gas comme une absence d’autorité.
• Assimiler l’affichage d’une demande à une exécution.

Classez R1–R3 et listez les champs d’autorité de R2. Remplissez les lignes demandé, signé, soumis et exécuté et précisez un enregistrement manquant nécessaire pour établir l’exécution.

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.

• Lire les champs avant le libellé.
• Consigner contrat, réseau, spender et montant.
• Conserver le contexte du nonce et de l’expiration.
• Séparer les quatre étapes.
• Ne jamais signer pour l’exercice.

La signature d’un message peut autoriser des actions aux conséquences importantes. Examiner une capacité ne prouve pas l’exécution et n’établit pas indépendamment une intention malveillante.

• Distinguer la signature de messages des instructions modifiant des actifs
• Lire les champs de messages portant une autorisation.
• Séparer les étapes demandé, signé, soumis et exécuté.

P03-L04 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.

• [TYPED] Signature structurée typée EIP-712 — Champs de signature structurée et de domaine ; les protections contre le rejeu de l’application restent distinctes.
• [PERMIT] Autorisations signées ERC-2612 — Autorisation d’allowance par permit avec owner, spender, value, nonce et deadline.
• [ETH_TX] Transactions Ethereum — Instructions signées et inclusion distincte de la soumission.

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.