--- title: "Prova di umanità e unicità" description: "I sistemi Prova di umanità e unicità cercano di fornire a ogni essere umano idoneo un singolo identificativo utilizzabile all'interno di un ambito definito senza richiedere a ogni applicazione di apprendere l'identità civile di quella persona." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Prova di umanità e unicità > Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite. ## Risposta diretta Prova di umanità e unicità (PoP) è una famiglia di sistemi che cerca di permettere a un'applicazione di far rispettare la regola di un essere umano idoneo per ogni credenziale, account, voto, richiesta o altra azione specifica. Una credenziale PoP può essere pseudonima: l'applicazione può sapere solo che un emittente accettato ha registrato un essere umano unico e che la stessa credenziale non ha già agito in questo ambito. Non è necessario che conosca il nome, l'indirizzo o l'identificativo governativo della persona. Quella descrizione compatta nasconde diverse rivendicazioni indipendenti. **Umanità** chiede se una persona vivente abbia partecipato. **Unicità** chiede se quella persona possieda già un altro titolo secondo le regole del sistema. **Controllo** chiede se il presentatore controlli attualmente il titolo. **Idoneità** chiede se la persona appartenga alla popolazione autorizzata ad agire. **Non collegabilità** chiede se le presentazioni in contesti diversi possano essere correlate. Un progetto può soddisfare una rivendicazione e fallirne un'altra: un controllo di vitalità non deduplica le persone, un passaporto unico non prova che il suo presentatore controlli ancora l'account risultante, e una prova anonima non rende equo un processo di registrazione parziale. PoP non è lo stesso della verifica know-your-customer (KYC). KYC generalmente stabilisce un'identità civile e raccoglie attributi per scopi legali o di conformità. PoP può invece emettere un'affermazione limitata come "un partecipante accettato in questo registro" e successivamente dimostrarla senza divulgare l'identità civile. Al contrario, un record KYC può aiutare a deduplicare i candidati ma non fornisce automaticamente presentazioni non collegabili, resistenza al trasferimento o copertura globale. PoP non è nemmeno, di per sé, un protocollo di consenso blockchain, una regola di scelta del fork o un meccanismo di finalità. Un protocollo può utilizzare un registro di persone per assegnare appartenenza, ricompense o peso di voto, ma ha comunque bisogno di regole per proporre, convalidare e finalizzare lo stato. L'articolo originale del 2017 proponeva token personali come input per un progetto di criptovaluta; quella proposta non trasforma ogni moderna credenziale PoP in un sistema di consenso. ## Come funziona Non esiste un metodo universale PoP. I sistemi utilizzano documenti governativi, deduplicazione biometrica, attestazioni della rete sociale, cerimonie in presenza o sincronizzate, sfide online, istituzioni fidate o combinazioni di questi. Ogni metodo trasferisce la fiducia anziché eliminarla: i sistemi documentali si fidano degli emittenti e della convalida dei documenti; i sistemi biometrici si fidano dell'hardware di acquisizione, del software di confronto e della gestione dei template; i sistemi sociali si fidano dell'inserimento nel grafo e della resistenza alla collusione; le cerimonie si fidano dei controlli di partecipazione e degli organizzatori. Un'implementazione dovrebbe rendere esplicito il seguente ciclo di vita: 1. **Definire l'ambito e la politica.** Specificare l'azione da proteggere, la popolazione idonea, la finestra temporale, i tassi di errore accettabili e cosa significa "una persona" nei casi limite. Umanità globale, residenza locale, età adulta e appartenenza sono affermazioni diverse. 2. **Modella l'avversario e gli incentivi.** Stimare il valore di una credenziale extra e se gli aggressori possono falsificare prove, reclutare persone reali, corrompere operatori, compromettere dispositivi, collaborare in un social graph o acquistare credenziali dopo il rilascio. 3. **Iscriviti e prova l'umanità.** Raccogli solo le prove richieste dalla politica. Il rilevamento della vitalità o degli attacchi di presentazione può aiutare a dimostrare che è presente una persona reale, ma non è un test di unicità. 4. **Eliminare i duplicati all'interno della popolazione iscritta.** Confronta documenti, dati biometrici, partecipazione a cerimonie, attestazioni o altri segnali secondo le regole pubblicate. Il risultato è l'unicità rispetto a quel registro, al tempo e al metodo, non la prova che nessuna credenziale esista altrove. 5. **Rilasciare e vincolare un'identificazione.** Collega un'iscrizione approvata a una chiave, a un autenticatore o a un account recuperabile. Registra l'emittente, il periodo di validità, il metodo di stato e il livello di garanzia. La verificabilità crittografica dimostra chi ha firmato la dichiarazione e se è stata alterata; come osserva W3C, non prova da sola che la dichiarazione sia vera. 6. **Presenta una prova circoscritta.** Il titolare può rivelare direttamente la credenziale o generare una presentazione a divulgazione selettiva o a conoscenza zero. Una costruzione può dimostrare l'appartenenza a un gruppo e derivare un nullificatore specifico per ambito in modo che il verificatore rifiuti una seconda azione senza apprendere un identificatore globale riutilizzabile. 7. **Gestire il ciclo di vita.** Verificare la freschezza e l'ambito, prevenire la ripetizione, elaborare la revoca e il recupero, pubblicare le modifiche alle regole e al software, misurare il falso accettazione e il falso rifiuto, fornire revisione umana e possibilità di ricorso, e definire cosa succede se l'emittente o il servizio chiudono. Il verificatore dovrebbe valutare sia la crittografia che le politiche. Una prova valida potrebbe stabilire che una chiave appartiene all'insieme corrente di credenziali e non ha segnalato due volte sotto una data regola del nullificatore. Non stabilisce che i sensori di registrazione non siano stati compromessi, che gli operatori non abbiano colluso, che ogni persona idonea possa registrarsi, che la credenziale non sia stata noleggiata, o che l'azione stessa sia legale o equa. I metric devono mantenere i loro denominatori. L'accettazione falsa misura i richiedenti o i duplicati accettati in modo errato; il rifiuto falso misura i richiedenti legittimi rifiutati in modo errato; la copertura misura quanto della popolazione prevista può realisticamente iscriversi; il costo dell'attacco stima le risorse marginali necessarie per un'altra credenziale utilizzabile. Una singola percentuale di "accuratezza" può nascondere un piccolo gruppo escluso, un fallimento a bassa frequenza o un attacco economicamente redditizio. ## Esempi svolti ### Errori di iscrizione Supponiamo che 100.000 domande comprendano 90.000 persone uniche e idonee e 10.000 duplicati o bot. Con un tasso di falso rifiuto del 2%, vengono respinte 1.800 persone idonee. Con un tasso di falsa accettazione del 5%, vengono accettate 500 domande non ammesse. Il sistema classifica correttamente 97.700 domande, ossia il 97,7%; tuttavia, questa cifra aggregata non elimina la necessità di rimediare a 1.800 esclusioni ingiuste né di contenere il rischio di 500 credenziali aggiuntive. ### Noleggio di credenziali in un voto ristretto Una votazione tra 8.000 credenziali termina 4.050 a 3.950. Se ogni credenziale può essere affittata per US$ 5, la parte perdente deve controllare altri 101 voti per vincere 4.051 a 4.050, con un costo di US$ 505. L'unicità al momento dell'iscrizione non impedisce trasferimento, coercizione o controllo a pagamento. Uno snapshot blocca la creazione tardiva di account solo se l'attaccante non controllava già le credenziali prima dello snapshot. ### Annullatori delimitati In una costruzione semplificata, un titolare ottiene N = H(person_secret || action_id) e dimostra a conoscenza zero che N è stato ottenuto da una credenziale nel set accettato. Due tentativi con action_id = grant-2026 producono lo stesso N, quindi il secondo viene respinto. L'uso di action_id = forum-2026 produce un N diverso e può ridurre il collegamento tra applicazioni. Questo è un esempio concettuale; gli input dell'hash esatti, i domini e la dichiarazione di prova sono specifici del protocollo, e i metadati possono comunque correlare gli utenti. ### La copertura cambia il risultato Un airdrop ha token 1,000,000 e intende pagare ogni persona idonea in modo uguale. Se 10,000 persone si iscrivono, ciascuna riceve 100 token. Se requisiti di viaggio, dispositivo o documenti escludono 2,000 persone altrimenti idonee, i 8,000 partecipanti iscritti ricevono ciascuno 125 token. Il contratto esegue correttamente il suo registro, ma la distribuzione non è uguale tra la popolazione prevista. La copertura fa quindi parte del modello di sicurezza e correttezza, non semplicemente una metrica di esperienza utente. ## Rischi e controlli ### Iscrizione e unicità - **Falsa accettazione:** documenti falsificati, acquisizioni riutilizzate, media sintetici, gemelli, lacune nei database o attestatori collusi possono creare credenziali aggiuntive. Testare l'intero flusso operativo, non solo un comparatore di laboratorio. - **Falso rifiuto:** errori di corrispondenza e regole probatorie rigide possono escludere persone legittime. Pubblicare prestazioni disaggregate, richiedere una revisione manuale per le corrispondenze di deduplicazione con conseguenze rilevanti e fornire rimedi accessibili. - **Dominio di unicità limitata:** un registro può generalmente deduplicare solo rispetto ai record che può esaminare. Indicare la geografia, gli emittenti, i canali di iscrizione e il periodo di tempo coperto dalla dichiarazione. - **Cattura del verificatore:** corrompere gli operatori o compromettere l'hardware di registrazione può aggirare anche una crittografia robusta. Separare i compiti, verificare l'emissione, alternare gli operatori e limitare l'autorità unilaterale. ### Privacy e protezione dei dati - **Perdita biometrica irrinunciabile:** un volto o un modello dell'iride non può essere ruotato come una password. Minimizzare la raccolta, proteggere i modelli, conservare e cancellare i documenti e ottenere il consenso informato dove richiesto. - **Correlazione tra contesti:** un identificatore stabile, una firma, un annullatore o un modello temporale può collegare l'attività tra applicazioni. Usa la separazione dei domini e presentazioni non collegabili, quindi testa i percorsi dei metadati così come i valori di prova. - **Collusione tra emittente e verificatore:** una prova a conoscenza zero può nascondere attributi al verificatore mentre i registri di emissione identificano ancora il titolare. Documenta la vista di ogni parte, la politica di conservazione e la capacità di combinare i dati. - **Pubblicazione permanente:** mettere dati biometrici grezzi, immagini di documenti o hash personali stabili sulla blockchain rende la cancellazione e la mitigazione dei rischi futuri difficili. Mantieni i dati sensibili di registrazione fuori dai registri pubblici. ### Ciclo di vita delle credenziali - **Vendita, noleggio e coercizione:** una credenziale unica può ancora essere controllata da qualcun altro. Modella i mercati delle credenziali e la coercizione; non affermare la non trasferibilità solo perché un token non può muoversi on-chain. - **Compromissione della chiave o del dispositivo:** il possesso crittografico dimostra il controllo di un segreto, non quale persona lo stia utilizzando. Supportare autenticatori sicuri, segnalazione delle compromissioni e un recupero attentamente delimitato. - **Duplicazione del recupero:** emettere una sostituzione senza invalidare la vecchia credenziale crea due identità utilizzabili; un recupero eccessivamente rigoroso esclude permanentemente il proprietario. Rendere la sostituzione atomica e verificabile. - **Dipendenza dalla revoca:** i controlli di stato possono consentire censura, tracciamento o interruzioni. Limitare l'autorità di revoca, pubblicare motivi e livelli di servizio e supportare ricorsi o migrazione. ### Governance e inclusione - **Punti di strozzatura centralizzati:** un verificatore on-chain non decentralizza sensori proprietari, un emittente, una chiave di aggiornamento o un database biometrico. Mappa l'autorità componente per componente. - **Modifiche alle regole:** gli amministratori possono modificare soglie, documenti accettati o criteri di idoneità dopo la registrazione degli utenti. Utilizzare politiche versionate, periodi di preavviso, valutazioni d'impatto e procedure di rollback. - **Barriere di accesso:** costi, spostamenti, lingua, disabilità, età, documentazione, connettività e requisiti del dispositivo influenzano chi può partecipare. Misurare i tassi di completamento e rifiuto nella popolazione prevista. - **Fallimento istituzionale:** gli emittenti possono cessare l'attività, perdere le chiavi o smettere di mantenere i dati di revoca. Definire prima del lancio percorsi di esportazione, successione, dismissione e nuova registrazione. ### Integrità applicativa ed economica - **Ambito o errori di replay:** un dominio di nullifier riutilizzato può creare collegamenti indesiderati, mentre un dominio omesso o incoerente può permettere azioni ripetute. Collega le prove al verificatore, all'azione, alla rete, al nonce e alla scadenza come richiesto dal protocollo. - **Escalation degli incentivi:** quando un voto, un airdrop o un account diventa più prezioso, attacchi che in precedenza erano poco economici possono diventare redditizi. Rivaluta i controlli rispetto al valore attuale di una credenziale aggiuntiva. - **Condotta umana scorretta:** PoP può limitare la molteplicità dei conti ma non può impedire alle persone verificate di coordinarsi, mentire, fare spam, corrompere o infrangere le regole. Mantieni separati contenuti, frodi e controlli di governance. - **Distribuzione troppo ampia:** l'allocazione di risorse scarse può giustificare l'unicità, mentre la lettura, la parola o i pagamenti ordinari potrebbero non farlo. Richiedere necessità e proporzionalità invece di trasformare PoP in un requisito di accesso universale. ## Comuni idee sbagliate ### "Prova di umanità e unicità rivela un'identità legale" Non necessariamente. Un sistema può dimostrare l'appartenenza a un insieme unico di esseri umani accettato senza rivelare un nome o un identificatore civile. Se raggiunge effettivamente quella privacy dipende dai dati di registrazione, dal design della presentazione, dai metadati e dalle parti che possono colludere. ### "La vitalità, un CAPTCHA o un selfie dimostra l'unicità" Questi controlli possono aumentare il costo dell'automazione o degli attacchi di presentazione, ma non dimostrano che la stessa persona non si sia iscritta tramite un altro dispositivo, documento o account. La deduplicazione è un'affermazione separata. ### Una prova a conoscenza zero rende l'iscrizione affidabile La conoscenza zero può limitare ciò che una presentazione rivela e dimostrare formalmente una dichiarazione sui dati impegnati. Non corregge una dichiarazione falsa dell'emittente, un confrontatore parziale, un sensore compromesso, un operatore corrotto o una politica esclusiva. ### Mettere il registro sulla blockchain rende il sistema decentralizzato La catena può rendere aggiornamenti e regole di verifica verificabili, ma iscrizione, produzione di hardware, corrispondenza, aggiornamenti, revoca e accesso ai dati possono rimanere concentrati. La decentralizzazione deve essere valutata per ciascuna autorità e dipendenza. ### Una persona, una credenziale crea automaticamente consenso o governance equa PoP può fornire un input di resistenza a Sybil o di appartenenza. Non fornisce ordinamento dei blocchi, scelta del fork, finalità, partecipazione informata, segretezza del voto, resistenza alla coercizione o un limite di idoneità equo. Questi richiedono meccanismi separati e scelte di politica. ## Argomenti correlati - [Attacco Sybil](/it/crypto/sybil-attack/) - [Identità decentralizzata](/it/crypto/decentralized-identity/) - [Dimostrazione a conoscenza zero](/it/crypto/zero-knowledge-proof/) - [Token di governance](/it/crypto/governance-token/) - [Lancio aereo](/it/crypto/airdrop/) ## Fonti - [Proof-of-Personhood: Ridemocratizzare le Criptovalute Senza Permessi](https://doi.org/10.1109/EuroSPW.2017.46) - IEEE (accesso: 2026-08-19) - [Identità e persona nella democrazia digitale](https://arxiv.org/abs/2011.02412) - arXiv (accesso: 2026-08-19) - [Credenziali di persona: Intelligenza artificiale e il valore degli strumenti che preservano la privacy per distinguere chi è reale online](https://arxiv.org/abs/2408.07892) - arXiv (accesso: 2026-08-19) - [NIST SP 800-63A-4: Verifica dell'identità e registrazione](https://pages.nist.gov/800-63-4/sp800-63a.html) - NIST (accesso: 2026-08-19) - [Valutazione della tecnologia di riconoscimento facciale: 1:1 Verifica](https://pages.nist.gov/frvt/html/frvt11.html) - NIST (accesso: 2026-08-19) - [Modello di Dati delle Credenziali Verificabili v2.0](https://www.w3.org/TR/vc-data-model-2.0/) - W3C (accesso: 2026-08-19) - [Cos'è Semaphore?](https://docs.semaphore.pse.dev/) - Semaphore (accesso: 2026-08-19) - [World ID Panoramica](https://docs.world.org/world-id/overview) - World (accesso: 2026-08-19) - [Guida alla migrazione World ID 4.0](https://docs.world.org/world-id/4-0-migration) - World (accesso: 2026-08-19) Source: https://wiki.fcontext.com/it/crypto/proof-of-personhood/index.mdx