Vai al contenuto

Prova di umanità e unicità

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.

Aggiornato

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

Fonti

Navigazione

Cerca nella wiki...