Approvazioni, allowance e revoca

Master sorgente EN · P03-L04 · needs_review

Solo studio senza rete/in sola lettura. Non fornire mai segreti, password o codici di autenticazione. Nessuna connessione del wallet, approvazione reale, revoca in tempo reale, firma di transazione, trasferimento, fondi o operazione di trading. I visual sono soltanto specifiche.

Le autorizzazioni sono specifiche di asset/spender/contesto. Un'allowance zero può sostenere un risultato utile mentre altri token e autorizzazioni firmate restano irrisolti.

Indicare la tupla completa

ERC-20 descrive la semantica di allowance, approve e transferFrom [ERC20]. Una riga di autorizzazione richiede rete, token, owner, spender e contesto di osservazione. Un token diverso è un'autorizzazione diversa anche quando lo spender visualizzato è identico.

Leggere lo stato anziché le etichette della sessione

R1/R3 mostrano la stessa tupla in due contesti stipulati. R2 mostra una disconnessione dell'interfaccia; non descrive un cambiamento di stato del contratto del token. Una revoca richiesta, un'azione inviata e lo stato risultante sarebbero fasi separate dell'evidenza. R3 è fornito senza rete; lo studente non deve inviare una revoca in tempo reale.

R4 riguarda TOKEN-B e non può essere unito alla riga di TOKEN-A. Riportare soltanto lo zero rassicurante omettendo l'altra riga perderebbe una parte rilevante della portata. Preservare entrambi i valori e spiegare a quale domanda risponda ciascuno.

Lasciare irrisolte le autorizzazioni firmate dove necessario

Un permit ha semantica separata di firma/nonce/deadline secondo le regole pertinenti del contratto [PERMIT]. R5 omette deliberatamente la relazione con lo stato attuale di nonce/utilizzo. Un'allowance zero non dimostra che ogni firma ancora utilizzabile sia invalidata. La richiesta successiva necessaria riguarda regole applicabili e stato pertinente, non un'altra transazione didattica in tempo reale.

Uno stato di allowance non annulla inoltre un trasferimento precedente né dimostra che un owner non abbia mai esposto materiale di recupero. Inventario delle autorizzazioni ed esposizione della capacità di firma sono domande di ricerca distinte.

Dichiarare risultati circoscritti

OBSERVED: valori dei dati dell'esercizio e stato della sessione. INFERRED: cambiamento della tupla selezionata da 100 a zero. UNKNOWN: inventario completo delle autorizzazioni e utilizzabilità di R5. INSUFFICIENT EVIDENCE: «tutti gli asset sono sicuri». Una conclusione circoscritta indica la tupla selezionata a H12 e lascia irrisolte le righe separate.

• Allowance: valore di autorizzazione circoscritta.
• Spender: ruolo pertinente di autorizzazione.
• Evidenza della revoca: stato risultante dell'autorizzazione nel contesto.
• Copertura: righe di autorizzazione effettivamente fornite.

ILLUSTRATIVE schede. R1 SIM-N/TOKEN-A/OWNER-X/SPENDER-Y a SIM-H10 allowance 100 unità intere dell'esercizio. R2 interfaccia disconnessa a T1. R3 stessa tupla H12 allowance 0. R4 TOKEN-B/stesso owner/spender H12 allowance 80. R5 riepilogo permit TOKEN-A con relazione attuale nonce/utilizzo UNKNOWN. Nessuna approvazione, firma o transazione reale.

Matrice tupla/contesto. R1→R3 è un confronto selezionato; R4 resta 80, R5 sconosciuto. Mettere R2 in una riga di sessione senza collegamento automatico allo stato onchain.

Stati selezionati dei dati dell'esercizio e confronto circoscritto.

Revoca in tempo reale, annullamento completo delle autorizzazioni, invalidazione di tutti i permit, annullamento di una perdita o sicurezza garantita.

• Chiamare revoca una disconnessione.
• Generalizzare uno zero a ogni token.
• Assumere che uno stato zero annulli ogni firma.

Costruire le righe di autorizzazione R1/R3/R4. Spiegare i limiti di R2 e R5. Riscrivere «disconnessione e zero rendono ogni asset sicuro».

Consegnare tabella e conclusione circoscritta basate solo sul materiale fornito senza rete. Ripartizione editoriale: studio 12 min, esercizio 8 min, correzione/quiz 10 min.

• Tupla/contesto completi.
• Sessione e stato separati.
• Richieste ed esiti separati.
• Token diversi tenuti distinti.
• Lacune sulle firme ancora utilizzabili indicate.

Un risultato sulle autorizzazioni dipende dal contesto. Disconnessione e una sola allowance zero non dimostrano annullamento completo delle autorizzazioni o sicurezza degli asset.

• Esaminare spender, importo e limiti della revoca
• Leggere tuple complete delle allowance e relativi contesti.
• Delimitare uno stato zero senza affermare che tutte le autorizzazioni siano state annullate.

P03-L05 dopo la verifica dei prerequisiti e della correzione.

NONE nel catalogo autorevole. Bastano i dati forniti senza rete; non servono acquisto del prodotto o operazioni di wallet.

• [ERC20] Standard dei token ERC-20 — approve, allowance e transferFrom per interfacce conformi.
• [PERMIT] Approvazioni firmate ERC-2612 — Autorizzazione di allowance tramite permit con owner, spender, value, nonce e deadline.

La documentazione spiega meccanismi. I record storici mantengono la classe dichiarata della fonte. La verifica delle fonti non è un’approvazione editoriale indipendente.