I progetti dell’hackathon di Midnight dimostrano l’uso di dati web privati e la verifica delle credenziali

Due progetti presentati dopo Hack Buenos Aires hanno mostrato come le applicazioni di Midnight possano lavorare con informazioni del mondo reale limitando al contempo l’esposizione dei dati privati. Uno collega a contratti Compact dati HTTPS provati crittograficamente, mentre KEEP utilizza credenziali mobili che restano sotto il controllo del titolare.

By SongMarketCap

Cardano News - I progetti dell’hackathon di Midnight dimostrano l’uso di dati web privati e la verifica delle credenziali

Gli sviluppatori dell’hackathon di Midnight a Buenos Aires hanno presentato due prototipi funzionanti incentrati sulla privacy, costruiti attorno a dati esterni e credenziali digitali.

Il primo combina le attestazioni ZK Fetch e Reclaim con Midnight Compact per stabilire l’origine dei dati web. KEEP adotta un approccio diverso tramite Ward, un’applicazione mobile progettata per emettere e convalidare credenziali senza trasferire l’intero record personale del titolare.

ZK Fetch porta dati web provati in Compact

Il primo progetto affronta un problema comune quando gli smart contract si basano su informazioni recuperate da API esterne.

HTTPS protegge la comunicazione tra un client e un server, ma il contratto che riceve tali informazioni non fa parte della connessione originale. Gli sviluppatori hanno quindi utilizzato ZK Fetch e Reclaim Protocol per creare prove crittografiche che l’interazione HTTPS sia avvenuta con la sorgente dichiarata.

Il sistema di prova di Reclaim e Midnight Compact non erano direttamente compatibili, quindi il team ha aggiunto tra loro uno strato di notai. I notai verificano la prova e la firmano, mentre un’implementazione di firme Schnorr all’interno di Compact richiede la conferma di almeno due notai prima che le informazioni possano essere accettate come input del contratto.

L’architettura è stata dimostrata con dati di Strava. Due account hanno inviato risultati di corsa di circa 3,5 chilometri e 15 chilometri, permettendo all’applicazione di determinare un vincitore senza rendere pubblico l’insieme di dati più ampio.

Il team ha dichiarato che il processo di prova esterna ha richiesto circa tre o quattro secondi, seguiti dal tempo normale necessario per una transazione su Midnight. L’implementazione Compact rimane un MVP ed è prevista per ulteriori refactoring.

KEEP archivia le credenziali sul dispositivo del titolare

KEEP applica la privacy alle credenziali emesse da istituzioni come università, scuole o enti pubblici.

La sua applicazione mobile Ward supporta sia il ruolo di titolare sia quello di verificatore. Invece di distribuire i record personali su più sistemi, la credenziale rimane sul telefono dell’utente e il titolare può rivelare solo le informazioni necessarie per una verifica specifica.

Il sistema utilizza un albero di Merkle per la divulgazione selettiva, consentendo di rivelare un elemento di una credenziale preservando l’integrità crittografica. Gli sviluppatori hanno inoltre incorporato le firme Schnorr e Capacity Exchange per transazioni sponsorizzate destinate a ridurre la complessità della blockchain visibile agli utenti finali.

Nella demo, un telefono fungeva da verificatore e mostrava una sfida QR, mentre un secondo telefono deteneva la credenziale. Dopo che il titolare ha scansionato la sfida, il processo è passato attraverso Midnight e ha restituito la conferma che la credenziale era valida.

Il team ha riportato un tempo di elaborazione di circa 20 secondi. Il verificatore ha ricevuto il risultato senza ricevere il record completo della credenziale del titolare.

Due prototipi per la privacy affrontano problemi di dati differenti

I due progetti affrontano fonti di informazione differenti.

L’implementazione ZK Fetch si concentra su dati provenienti da servizi web esistenti, offrendo ai contratti Compact un metodo per stabilire che un’affermazione esterna provenga dalla sorgente HTTPS prevista.

KEEP si concentra su credenziali emesse direttamente agli individui, consentendo al titolare di conservare localmente il record e di divulgare solo ciò di cui un verificatore ha bisogno.

Entrambi restano implementazioni a livello di hackathon. Il team di KEEP ha affermato che il suo sviluppo di 24 ore non poteva essere reso completamente decentralizzato e utilizza attualmente un nodo di Capacity Exchange che è centralizzato in una certa misura. Secondo gli sviluppatori, quel nodo non possiede la chiave del titolare necessaria per firmare la transazione Midnight dell’utente.

Le dimostrazioni lasciano Midnight con due prototipi funzionanti distinti: uno può introdurre in un contratto Compact informazioni HTTPS provate, mentre l’altro può emettere una credenziale su un dispositivo mobile e confermare un’affermazione senza consegnare al verificatore l’intero record personale.