Mi sono seduto a leggere i documenti di $SIGN fino a quasi le 2 del mattino e ho avuto un'idea che mi ha fatto fermare per un bel po': forse ciò che stanno cercando di costruire non è solo un protocollo di attestazione, ma un modo per dimostrare titoli di studio, competenze ed esperienze senza dover pubblicare l'intero fascicolo personale online.
Secondo il mio punto di vista, questa è la parte più interessante di Sign 😀
Perché nella vita reale, molte volte l'app non ha bisogno di sapere tutto su di te. Una piattaforma di reclutamento non deve necessariamente vedere l'intera storia accademica, ogni lavoro precedente o l'intero fascicolo personale.
Spesso hanno solo bisogno di sapere che hai effettivamente quel diploma, che possiedi quella competenza, o che hai avuto esperienze lavorative correlate. Se devi ancora esporre l'intero dossier solo per dimostrare una cosa così piccola, allora Web3 in realtà sta ancora risolvendo il problema della fiducia in modo piuttosto rudimentale.
Sign sta cercando di andare nella direzione opposta: fornire solo la parte di prova necessaria, ma mantenere la capacità di verificare e auditare quando necessario. I loro documenti descrivono il Sign Protocol come supporto per attestazioni pubbliche, private e ibride, sottolineando allo stesso tempo la divulgazione selettiva e le prove di preservazione della privacy come parte del livello di evidenza.
Il punto che trovo degno di nota è che Sign non inizia da "identità" nel senso puro, ma da claim che è stato verificato.
Questa è una differenza piuttosto grande. Un sistema di identità può dirti chi sei. Ma in molti flow reali, ciò di cui gli altri hanno bisogno non è "tutto ciò che sei", ma un claim specifico su di te che è stato verificato da qualcuno, secondo quale standard, e se è ancora valido o meno.
Sign entra davvero in questo aspetto con schema + attestazione + query/layer di verifica. Lo schema aiuta a definire come dovrebbe apparire un certo tipo di claim. L'attestazione è un registro firmato che collega quel claim all'issuer e al subject.
Inoltre, il livello di query/verifica aiuta una terza parte a controllare senza dover fidarsi ciecamente del backend dell'app emittente. Per me, questa è una base molto adatta per gestire diplomi, abilità ed esperienze nel modo di "dimostrare solo ciò che deve essere dimostrato".
Penso che il punto più forte di questa tesi risieda nello schema.
Perché se non c'è uno schema, ogni credenziale alla fine rimane solo dati firmati. Potrebbe essere corretta, ma è molto difficile da riutilizzare.
Un'app educativa può definire i diplomi in un formato. Un'altra app di reclutamento può definire l'esperienza in un formato diverso. Un'app di onboarding può avere una logica KYC e abilità in modo distinto. In tal caso, i dati potrebbero essere "verificati", ma non sono realmente portabili.
Lo schema in Sign è il luogo che incapsula il significato del claim: di cosa tratta questo claim, quali campi ha, chi è l'issuer, chi è il subject, può essere revocato o meno, ci sono condizioni di scadenza?
Dal mio punto di vista, questo è ciò che consente a un "diploma universitario", una "credenziale di abilità" o una "prova di esperienza lavorativa" di essere comprese secondo uno standard sufficientemente chiaro affinché altre app possano riutilizzarle senza dover costruire tutto da zero.
Ma il punto in cui trovo Sign davvero interessante è nella divulgazione selettiva.
Questa è la parte che si adatta perfettamente al tema che stai chiedendo. Se una persona deve solo dimostrare di "essere laureata", non è necessario rendere pubblica l'intera trascrizione, il numero di riferimento, la data di nascita, l'indirizzo o altre informazioni sensibili.
Se una persona deve solo dimostrare "di avere l'abilità X" o "di aver lavorato nel settore Y", l'app non ha bisogno di vedere l'intero CV.
I documenti di Sign sottolineano che il protocollo supporta modalità migliorate per la privacy, comprese attestazioni private, attestazioni ibride e, dove appropriato, attestazioni ZK / prove di preservazione della privacy.
Per me, questo è il punto in cui Sign può trovarsi tra due lati apparentemente in conflitto: da un lato la necessità di una verifica abbastanza forte, dall'altro la necessità di non rendere pubblici tutti i documenti personali.
Un altro punto che mi fa considerare questo argomento piuttosto solido è che Sign non si occupa solo di "registrare prove", ma anche di come quelle prove vengano utilizzate successivamente.
Gli schema hooks sono un esempio molto chiaro. Quando un'attestazione viene creata o revocata, la logica dell'app può seguirla. Questo è importante perché i diplomi, le abilità o le esperienze non servono solo a decorare un profilo.
Questi sono spesso input per accesso, assunzioni, idoneità, conformità o diritti di partecipazione a un certo flow.
Se una credenziale di abilità viene revocata, l'app può bloccare l'accesso. Se un diploma è stato verificato secondo standard sufficienti, un'altra app può aprire una classe di funzionalità o workflow appropriati.
Dal mio punto di vista, questo è il momento in cui Sign trasforma "credential verificata" da dati statici a dati che possono essere azionati.
Trovo che la parte di supporto multi-environment di Sign sia molto in linea con la questione dei diplomi e dei profili professionali.
Perché cose come credenziali educative, esperienze lavorative o certificazioni raramente esistono in modo compatto all'interno di una chain.
A volte, le prove originali dovrebbero trovarsi a livello off-chain o in storage decentralizzato a causa della lunghezza dei dati, della loro sensibilità o della necessità di mantenerli privati. I documenti per i costruttori di Sign mostrano che supportano payload completamente on-chain, completamente off-chain con ancore verificabili, e modelli ibridi.
Dal mio punto di vista, questo è un aspetto molto pratico. Un sistema che desidera gestire diplomi, abilità ed esperienze non può semplicemente richiedere che tutto sia pubblico on-chain, altrimenti è praticamente insostenibile.
Sign sembra comprendere questo, quindi standardizzano la logica delle prove più che costringere tutti i dati a essere pubblici in modo assoluto.
Ma non penso nemmeno che si debba dire troppo che Sign ha già risolto questo problema.
Questo è il punto in cui desidero mantenere un certo distacco. Un protocollo con divulgazione selettiva e prove di preservazione della privacy non diventa automaticamente uno standard per le credenziali nel mondo reale. Perché ciò abbia un vero valore, devono esserci almeno tre elementi.
Innanzitutto, la qualità dell'issuer deve essere abbastanza forte. Un diploma vale solo quando l'issuer è affidabile. Una credenziale di abilità ha senso solo quando l'issuer ha realmente l'autorità per rilasciarla.
In secondo luogo, l'adozione dello schema deve essere sufficientemente ampia. Se ogni app definisce "esperienza lavorativa" o "prova di abilità" a modo suo, la portabilità rimane debole.
In terzo luogo, devono esserci flussi di produzione reali in cui il verificatore accetta di leggere solo la parte necessaria delle prove invece di richiedere l'intero dossier.
Dal mio punto di vista, Sign sta costruendo correttamente i primitive affinché ciò accada, ma l'adozione nel mondo reale è la parte decisiva.
Quindi, se mi chiedi se SIGN può aiutare a dimostrare diplomi, abilità, esperienze senza dover rendere pubblici tutti i documenti personali, la risposta è che c'è una possibilità abbastanza chiara.
Non ti offrono solo uno spazio per memorizzare una credenziale. Stanno cercando di creare un livello di prova in cui il claim è definito chiaramente dallo schema, emesso da un issuer sufficientemente affidabile, che può scegliere il livello di pubblicità appropriato, e poi essere interrogato e verificato da un'altra app senza dover esporre l'intero dossier.
Per me, questa è una direzione molto giusta.
Ma il vero valore di questa tesi emergerà solo quando ci saranno molti issuer reali, molte app reali e molti flow reali che accettano il tipo di "dimostrare solo ciò che deve essere dimostrato", invece di richiedere agli utenti di esporre l'intero dossier per ottenere fiducia.