Congelamento, proprietà e autorità

EN fonte principale · P08-L04 · 45 minuti stimati · needs_review

Un badge «proprietà rinunciata» può coesistere con un ruolo attivo di pausa o un controllore degli aggiornamenti. Un’autorità di mint rimossa può coesistere con un’autorità di congelamento. Queste affermazioni possono essere tutte vere mentre la conclusione ampia «nessuno ha controllo» è falsa.

Questa lezione insegna una mappa stratificata dei controlli. Collegherai ogni privilegio al suo oggetto, detentore corrente, condizione e possibile percorso di amministrazione. Il risultato è un record probatorio, non un punteggio di sicurezza o un’accusa.

Definire l’oggetto controllato

Non usare proprietario senza un sostantivo. Proprietario del programma di un account dati Solana, autorità di un account token, proprietario Ownable EVM e proprietario di una posizione NFT sono campi distinti. I nomi si somigliano ma governano meccanismi diversi. Scrivere campo e oggetto accanto al valore.

Separare controllo dei saldi token, restrizioni a livello di mint, ruoli dell’applicazione e autorità che cambia il codice. Un risultato su un livello non può cancellare un permesso a un altro. Per esempio, un mint token può mancare di autorità di mint mentre un’applicazione che interagisce con il token resta aggiornabile. Esaminare separatamente il ruolo dell’applicazione anziché presumere che governi lo stesso Token Program standard.

Una mappa dei controlli è un grafo di capacità, non di identità umane. Un’autorità elencata può essere un account utente o un indirizzo mediato dal programma. Etichette pubbliche degli account non stabiliscono chi abbia le chiavi o se più account condividano un controllore.

Comprendere il congelamento come restrizione di stato

Il meccanismo di congelamento Solana preserva proprietario dell’account token, mint e saldo impedendo le operazioni documentate di ricezione, trasferimento e burn fino allo scongelamento [S08-FREEZE]. Non è cancellazione del saldo o trasferimento all’autorità di congelamento.

Stato e autorità vanno registrati separatamente. Un’autorità di congelamento può esistere mentre un account è attualmente non congelato. Viceversa, osservare uno stato congelato non dice che un particolare umano lo abbia causato. Richiedere l’operazione riuscita e la sua autorizzazione se l’attribuzione conta.

La revoca rimuove un ruolo selezionato di autorità, non una raccolta universale di poteri [S08-SET]. Non presumere che la revoca di un ruolo mint abbia cambiato lo stato di congelamento. Account già congelati e possibili percorsi di recupero/scongelamento richiedono un esame proprio; evitare di descrivere una revoca ristretta come prova che ogni account sia trasferibile.

Esaminare ruoli dell’applicazione oltre Ownable

La rinuncia OpenZeppelin Ownable disabilita funzioni protette dal controllo del proprietario, mentre permessi basati su ruoli sono uno schema separato [S08-ACCESS]. Se un token distribuito combini questi schemi è una domanda di codice e stato. Se resta un ruolo di pausa, la sola rinuncia del proprietario non può rimuoverlo.

Costruire una tabella per proprietà, pausa, assegnazione/revoca di ruoli e aggiornamenti. Per ogni riga registrare controllo effettivo, autorità presente, percorso di amministrazione e incertezza. Un nome di ruolo è soltanto descrittivo finché non è collegato a un’operazione raggiungibile. «PAUSER» nei metadati non è prova di una funzione di pausa.

Un controllo può dipendere da timelock o multisig. Verificare contratto pertinente, soglia, ritardo e condizioni di aggiramento anziché accettare un badge. Un ritardo è una condizione temporale, non scomparsa del controllo. Una soglia multisig descrive firme, non necessariamente umani indipendenti.

Tracciare controllo di proxy e implementazione

Per proxy di tipo ERC-1967, distinguere collegamento a implementazione o beacon dallo slot amministratore opzionale. Un beacon risolve la logica per proxy associati; l’autorizzazione UUPS può risiedere nella logica dell’implementazione, quindi il solo slot amministratore vuoto non è una conclusione completa [S08-PROXY; S08-UUPS].

L’indirizzo rivolto all’utente di un proxy può restare uguale quando cambiano le regole. Fissare l’implementazione al contesto esaminato, poi esaminare il percorso che può cambiarla. Non verificare una pagina d’implementazione verificata lasciando non controllato il collegamento del proxy. Un’implementazione successiva può invalidare ipotesi precedenti sul comportamento.

Questa lezione non insegna a eseguire aggiornamenti. Insegna a descrivere il percorso di autorizzazione fornito in sola lettura. Se le regole interne del controllore non sono disponibili, indicarle sconosciute anche quando l’indirizzo esterno di autorità è noto.

Distinguere aggiornamenti dei programmi Solana e ruoli mint

Secondo loader-v3 Solana, gli aggiornamenti dei programmi dipendono dall’autorità di aggiornamento del programma; rimuoverla rende quel programma immutabile [S08-DEPLOY]. Non è il campo autorità di mint del mint. Si applica al programma e al meccanismo loader esaminati, non a ogni contratto o servizio off-chain connesso.

Un mint governato da un Token Program standard non dovrebbe essere descritto casualmente come aggiornabile indipendentemente solo perché un’applicazione personalizzata lo usa. Nominare il programma personalizzato e spiegarne la rilevanza. Nel materiale, PROGRAM-X è un’applicazione ausiliaria, non il Token Program proprietario di MINT-F.

L’immutabilità è circoscritta all’oggetto codice. Non dimostra utenti onesti, metadati immutabili, liquidità sufficiente o sistemi circostanti sicuri. Analogamente, autorità attiva di aggiornamento dimostra una capacità secondo condizioni, non che il codice cambierà con intenzioni malevole.

Riportare un risultato stratificato

Una frase difendibile nomina contesto e limiti: «A S0 il campo proprietario è rinunciato, mentre PAUSER resta assegnato e il controllore degli aggiornamenti del proxy è fornito ma la sua soglia interna è sconosciuta». È più informativa di un’etichetta categorica «decentralizzato».

Chiedere se un’affermazione possa essere falsificata da una riga residua. «Nessun controllo privilegiato» è contraddetto da una capacità attiva dimostrata. Un’affermazione ristretta come «il ruolo proprietario Ownable è assente» può restare sostenuta anche quando fallisce l’affermazione ampia. Preservare entrambe.

• Stato di congelamento: restrizione delle operazioni su un account token.
• Proprietario Ownable: autorità secondo uno schema particolare di controllo del proprietario.
• Detentore del ruolo: account che soddisfa un controllo specifico di appartenenza.
• Controllore degli aggiornamenti: autorità che governa un percorso di modifica del codice.
• Beacon: meccanismo di collegamento della logica del proxy.
• Timelock: condizione che impone ritardo su operazioni specificate.

ILLUSTRATIVE — FIX-P08-04. Oggetti fittizi separati a S0.

PROGRAM-X non è il Token Program che governa MINT-F. Il materiale non fornisce effetti del codice che collegano questa applicazione ausiliaria al mint.

OBSERVED nel materiale: F resta, V è congelato, P/G restano e C/U sono autorità di aggiornamento fornite.

INFERRED: «Tutti i controlli rimossi» è contraddetto da queste capacità separate. Proprietario rinunciato è un’affermazione più ristretta sostenuta su P2.

UNKNOWN: Regole interne di C, controllori umani, chi ha congelato V ed effetti esatti dell’applicazione PROGRAM-X.

INSUFFICIENT EVIDENCE: Congelamento non significa che il saldo di V sia stato distrutto. Proprietario assente non dimostra assenza di ruoli o aggiornamenti. U non dimostra che il Token Program standard sia controllato da U.

Usare proprietario senza il suo oggetto; confondere saldo congelato con zero; presumere che slot amministratore vuoto del proxy escluda ogni aggiornamento; interpretare un’etichetta multisig come controllo indipendente verificato; e unire autorità del programma ausiliario e autorità di mint.

Produrre quattro livelli di controllo: stato degli account, ruoli mint, ruoli dell’applicazione EVM e percorsi di cambiamento dell’implementazione. Riscrivere «ogni proprietà è rinunciata quindi tutto è immutabile». Elencare le prove successive richieste per C e V.

• Nominare l’oggetto di ogni campo proprietario.
• Separare autorità e stato corrente.
• Esaminare ruoli dopo la rinuncia di proprietà.
• Risolvere logica e percorsi di aggiornamento allo stesso contesto.
• Verificare soglie/ritardi anziché etichette.
• Circoscrivere l’immutabilità all’oggetto esaminato.

Il controllo è stratificato. Un ruolo rimosso stabilisce un fatto ristretto; ruoli attivi e percorsi di modifica del codice richiedono revisione separata.

Congelamento è restrizione, non cancellazione. Rinuncia del proprietario non è rinuncia di ogni controllo. Autorità di proxy, programma e mint sono distinte.

Mappa dei permessi a quattro corsie con riferimenti F1–F3,P1–P3,X1; mostrare saldo congelato invariato 50. Disegnare PROXY-Q→LOGIC-Q e controllore C separato; PROGRAM-X/U isolato da MINT-F. Indicare sconosciuta la configurazione di C.

Controlli stratificati illustrativi; assenza del proprietario è un’affermazione ristretta.

Usare SVG/HTML deterministici o grafici con alternative testuali, blu navy scuro/nero e accenti sobri ciano, blu elettrico e viola. Etichettare ogni quantità e incertezza. A 390px impilare i pannelli; verifica a 768px/desktop e RTL arabo restano lavoro futuro sulle risorse. Tenere gli identificatori in LTR e invariati assi fattuali/direzioni degli archi. Usare soltanto il marchio ufficiale BlockAssay fornito se viene aggiunto il marchio. Entrambi i record sono specifiche, non risorse consegnate.

Usare RADAR per lo scopo educativo circoscritto della lezione soltanto se sono verificati supporto della rete, identità esatta, campi e provenienza. Questo contenuto non afferma alcun endpoint runtime o capacità del fornitore. Usare il materiale offline incorporato senza accesso a pagamento. I dati mancanti restano sconosciuti; non sono necessari collegamento a wallet, firma di transazioni, lancio di token o operazioni dal vivo. Progressi nell’Academy, pagamenti e referral non cambiano mai le prove di Radar. Un Diagnostic Passport preserva osservazioni e limiti, non una previsione di prezzo o un certificato di sicurezza.

• Proxy OpenZeppelin 5.x — Meccanismi di aggiornamento trasparenti, beacon e UUPS basati sull’implementazione; l’autorizzazione effettiva richiede esame. Verificato 2026-09-30.
• Solana: congelare un account — Restrizioni dello stato dell’account distinte da importo o proprietà. Verificato 2026-09-30.
• Solana: impostare l’autorità — Cambiamenti e revoca specifici del ruolo; non un verdetto globale di sicurezza. Verificato 2026-09-30.
• Controllo degli accessi OpenZeppelin 5.x — Schemi di privilegi Ownable e basati su ruoli; esaminare l’autorizzazione effettivamente distribuita. Verificato 2026-09-30.
• Slot di memoria dei proxy ERC-1967 — Slot di implementazione, beacon e amministratore opzionale; esame specifico del meccanismo. Verificato 2026-09-30.
• Distribuzione dei programmi Solana — Autorità di aggiornamento dei programmi Loader-v3; non un ruolo di mint del token. Verificato 2026-09-30.

La documentazione sostiene meccanismi, non valori dei dataset fittizi. Tutti gli esempi e i record degli esercizi sono materiale originale ILLUSTRATIVE, fissato in questo file. S0/S1 sono etichette di contesto sintetiche; observedAt è null perché non è stata raccolta alcuna misurazione di un registro dal vivo o storico. Riesaminare documentazione e comportamento effettivamente distribuito prima di qualsiasi pubblicazione o integrazione.

P08-L05 dopo l’esercizio svolto e la revisione del quiz.