Firme, messaggi e transazioni

Master sorgente EN · P03-L03 · 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.

La didascalia di una richiesta può dire login mentre i suoi campi autorizzano la spesa. Richiesta effettiva ed evidenza dell'esecuzione successiva devono essere valutate separatamente.

Classificare l'autorizzazione

Le transazioni portano istruzioni firmate [ETH_TX]. Anche i messaggi possono autorizzare azioni dell'applicazione. EIP-712 definisce firma strutturata e contesto di dominio; la gestione del replay resta responsabilità dell'applicazione [TYPED]. ERC-2612 fornisce un meccanismo di allowance firmata usando owner, spender, value, nonce e deadline [PERMIT]. In questa lezione non viene creata alcuna firma.

Confrontare tre riepiloghi senza rete

R1 stipula una dichiarazione di tipo login, R2 una richiesta strutturata come permit e R3 una richiesta di trasferimento. La didascalia login di R2 non elimina i campi spender/value. R1 non ha autorità stipulata sugli asset, ma la sua innocuità fuori dall'esercizio semplificato non è dimostrata. Un pulsante generico di firma non risponde a come un'applicazione accetterà il contenuto firmato.

Preservare la portata

Leggere rete/dominio, contratto di verifica, autorità, spender, importo, nonce e deadline dove pertinenti. Se mancano, registrare UNKNOWN anziché prendere campi da un'altra scheda. Un campo di nome di dominio familiare non è autenticazione indipendente del progetto. Nonce e scadenza richiedono le regole dell'applicazione che accetta; il solo formato non è una politica completa di sicurezza.

Un permit può essere inviato da un'altra parte secondo le regole pertinenti del contratto. Quindi l'assenza di una transazione con gas inviata dal firmatario non prova che un messaggio non possa autorizzare un'allowance. Al contrario, una richiesta permit visualizzata non prova che esista una firma o che sia stata utilizzata.

Tenere le fasi nel resoconto

Richiesto, firmato, inviato ed eseguito sono righe separate. Qui sono fornite soltanto richieste. OBSERVED: riepiloghi e didascalie. INFERRED: classificazione secondo schemi stipulati. UNKNOWN: produzione della firma ed esecuzione. INSUFFICIENT EVIDENCE: perdita, intento malevolo o identità umana. Valutare la capacità senza formulare accuse e fermarsi senza firmare nulla.

• Messaggio tipizzato: contenuto strutturato di firma.
• Permit: meccanismo pertinente di approvazione firmata.
• Separazione del dominio: contesto di portata, non prova d'identità.
• Nonce: valore confrontato con lo stato del contratto che accetta per distinguere le autorizzazioni; ERC-2612 incrementa il nonce dell'owner dopo un permit riuscito.
• Deadline: ultimo momento in cui un permit ERC-2612 può essere accettato secondo le sue regole, non garanzia di esecuzione.
• Utilizzo: uso dell'autorizzazione da parte dell'applicazione/contratto.

ILLUSTRATIVE riepiloghi privi di dati sensibili, non payload firmabili. R1 login/SIM-LOGIN/SIM-CHALLENGE, nessun permesso sugli asset stipulato. R2 didascalia login, tipo Permit, owner SIM-A, spender SIM-S, value 500 unità intere dell'esercizio, nonce 4, deadline SIM-T3, dominio SIM-N/contratto SIM-C. R3 richiesta di trasferimento di 7 unità SIM a SIM-B su SIM-N. Nessuna firma, calldata o ricevuta.

Matrice delle autorizzazioni: didascalia/tipo/portata/evidenza dell'esecuzione. Evidenziare R2 Permit/SIM-S/500 nonostante la didascalia login. Tutte le schede si fermano prima della firma; nessun payload utilizzabile o pulsante di transazione.

Campi delle richieste e classificazioni delle capacità stipulate.

Firma, inclusione, perdita di asset, protezione completa dal replay o intento umano malevolo.

• Chiamare tutti i messaggi login innocui.
• Interpretare nessun gas come nessuna autorità.
• Equiparare visualizzazione della richiesta ed esecuzione.

Classificare R1–R3 ed elencare i campi di autorità di R2. Compilare le righe richiesto/firmato/inviato/eseguito e specificare un record mancante necessario per l'esecuzione.

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

• Leggere i campi prima della didascalia.
• Registrare contratto/rete/spender/importo.
• Conservare il contesto di nonce/scadenza.
• Separare quattro fasi.
• Non firmare mai come esercizio.

La firma di messaggi può autorizzare azioni con conseguenze. Esaminare la capacità non prova l'esecuzione né stabilisce indipendentemente un intento malevolo.

• Distinguere la firma dei messaggi dalle istruzioni che modificano gli asset
• Leggere i campi dei messaggi che conferiscono approvazioni.
• Separare le fasi richiesta, firma, invio ed esecuzione.

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

• [TYPED] Firma strutturata tipizzata EIP-712 — Campi della firma strutturata/dominio; le protezioni dal replay dell'applicazione restano separate.
• [PERMIT] Approvazioni firmate ERC-2612 — Autorizzazione di allowance tramite permit con owner, spender, value, nonce e deadline.
• [ETH_TX] Transazioni Ethereum — Istruzioni firmate e inclusione distinte dall'invio.

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