Binance Labs Fellow: HOPR, un Protocollo di Privacy Incentivato per la Messaggistica
Oggi vogliamo introdurre il prossimo Binance Fellow, Dr. Sebastian Bürgel di Validity Labs e il suo progetto HOPR.
Scritto da Flora Sun, Direttrice di Binance Labs
HOPR è uno schema mixnet incentivato e decentralizzato. Usando la crittografia ‘onion’ di Chaum, HOPR protegge sia il messaggio cifrato che i metadati ad esso associati, come informazioni del mittente/ricevente, dimensioni del messaggio, indirizzo IP usato, ecc. Inoltre, HOPR crede che l’adozione di massa e la portata di una soluzione decentralizzata e un’infrastruttura per proteggere la privacy necessita di incentivi economici. Di conseguenza, i relayer in HOPR vengono compensati attraverso un meccanismo d’incentivazione integrato.
Sebastian ha ricevuto il suo dottorato da ETH Zürich ed è co-fondatore di Validity Labs, ente che ha contribuito all’ecosistema blockchain attraverso i suoi impegni in campo educativo e di sviluppo dal 2015. Per scoprire di più su di lui e su HOPR, ecco un Q&A fatto poco fa:
***
Flora: Puoi dirci di più sull’origine di HOPR?
Sebastian: Validity Labs sta da tempo insegnando e sviluppando nell’ecosistema della blockchain e delle applicazioni decentralizzate. Abbiamo visto sempre più la mancanza di una tecnologia interamente decentralizzata per costruire applicazioni veramente decentralizzate. Abbiamo visto diverse blockchain per applicazioni finanziarie ma le applicazioni più interessanti non sono finanziarie.
Pensandoci bene - quali sono le app che usi più spesso: quelle di messaggistica o quelle per il mobile banking? Dopo aver esaminato il settore abbiamo visto che vari progetti stavano usando il protocollo Whisper di Ethereum applicandolo a cose per cui non era stato progettato. Oltre ai casi d’uso a livello applicativo come la messaggistica, osserviamo anche la necessità di privacy a livello dell’implementazione del protocollo, ovvero inviare una transazione su blockchain, gestire nodi di staking in sistemi PoS o canali di pagamento dovrebbero avvenire un modo tale da preservare la privacy al livello di base. Così abbiamo realizzato che c’è un grande pezzo mancante nello spazio Ethereum e più in generale nelle applicazioni decentralizzate verso un web3.0, un protocollo di privacy decentralizzato per la messaggistica.
Flora: Puoi descrivere cos’è HOPR?
Sebastian: HOPR trasmette messaggi da mittente a ricevente attraverso salti intermedi che in tal modo proteggono la privacy. Dato che gestire un nodo relay ha dei costi maggiori di zero (hardware, energia, traffico e a volte spese per servizi legali) introduciamo l’incentivazione che spinge gli utenti a configurare un nodo relay e partecipare nel network. Messaggi, fondi e responsabilità di consegna del messaggio ‘saltano’ da un nodo all’altro. In termini tecnici, HOPR è uno schema mixnet decentralizzato con incentivi per gli operatori di nodi relay.
Flora: Perché si chiama HOPR?
Sebastian: HOPR utilizza uno schema basato su onion-routing, ispirato da mixnet di Chaum come The Onion Router (TOR). In HOPR trasmettiamo un messaggio da mittente a ricevente, attraverso nodi relay che garantiscono la privacy oltre alla più comune cifratura end-to-end. Questi nodi relay vengono anche chiamati “hop” - un messaggio qualsiasi potrebbe rimbalzare tra tre hop prima di raggiungere il suo destinatario, da qui il nome HOPR per descrivere come il protocollo opera a un livello inferiore.
Flora: In che modo HOPR si differenzia da altri protocolli di privacy per la messaggistica?
Sebastian: La differenza principale rispetto ad altri protocolli per la protezione della privacy in applicazioni di messaggistica è che HOPR introduce un meccanismo d’incentivazione per gli operatori di nodi relay senza distruggere la privacy del livello di messaggio. In aggiunta a questo fornisce:
1. Un regime di contabilità basato su token / registro tra participanti al network.
2. Maggiori garanzie di anonimato rispetto a TOR tramite il formato pacchetto SPHINX
https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
3. Decentralizzazione completa - senza punti di fiducia centrali in contrasto a, per esempio, TOR che si basa su custodi centralizzati.
Flora: Puoi descrivere l’architettura tecnica di HOPR?
Sebastian: HOPR è composto da un livello di messaggio (trasmettere il messaggio) e un livello di pagamento (incentivare i relayer):
1. Livello di messaggio:
a. Il messaggio viene decriptato, bypassando nodi sul suo percorso
b. I nodi modificano l’header per renderlo leggibile al nodo successivo
c. Il nodo successivo controlla l’integrità dell’header, estra le informazioni e le inoltra al nodo/hop successivo
2. Livello di pagamento:
a. I nodi usano canali di pagamento (personalizzati) per la contabilità tra loro
b. L’esecuzione del protocollo tra Alice e Bob è completamente indipendente da quella tra Bob e Charlie
c. Per ottenere denaro, i nodi devono dimostrare di aver inoltrato il pacchetto
d. Il nodo successivo accetta il pacchetto solo se questo contiene una certa somma di denaro e un header corretto che rispetta la struttura del pacchetto, altrimenti abbandona il pacchetto.
e. Segue il principio “scambio equo ottimista”: i partecipanti sono in grado di individuare scorrettezze e dichiararle on-chain
3. Scoperta dei peer:
a. Servizio di directory decentralizzato - i nodi usano un protocollo di scoperta dei peer ispirato da BRAHMS
http://webee.technion.ac.il/~idish/ftp/brahms_tr.pdf
b. I nodi utilizzano WebRTC con server di signaling decentralizzati per bypassare NAT / firewall
Flora: Quali sono alcuni dei compromessi di progettazione fatti per HOPR?
Sebastian: In genere cerchiamo di costruire sulle spalle di giganti usando tecnologie che riducono il tempo necessario per rilasciare, sono comuni nell’ecosistema blockchain e aumentano l’utilità di una vasta gamma di altri progetti. La tech stack per la nostra prima implementazione, presentata come demo a EthCC a Parigi, è stata sviluppata su JavaScript / NodeJS e libp2p, usati da un grande numero di progetti nel settore della blockchain.
Sebastian: A un livello di architettura più profondo, abbiamo:
1. Protocol stack:
a. Network -> stabilire bitstream tra nodi
b. Libp2p -> stabilire overlay network, ovvero determinare quali protocolli i nodi parlano/comprendono, routing del traffico
c. HOPR -> mixnet, connessione a una blockchain che elabora la contabilità, scoperta di possibili percorsi -> conosciuto anche come relay PKI
d. Livello di sincronizzazione: fornire cronologia delle chat, consegnare chiavi, archiviare messaggi
e. Livello di applicazione: ad es., status.im / matrix.org / ratchet scheme …
2. Dimensione di pacchetto fissa per migliori garanzie di privacy assicurando che i pacchetti non possono essere rintracciati da un forte avversario passivo globale
3. A seconda dei requisiti di privacy dell’applicazione la latenza potrebbe essere inferiore a un secondo. Per altre applicazioni potrebbero essere accettabili latenze maggiori al fine di fornire una privacy ancora migliore.
Flora: Quali sono alcune funzionalità che hanno richiesto molto più tempo di quanto previsto e perché?
Sebastian: Durante la nostra fase di progettazione abbiamo osservato molta considerazione e supporto per libp2p nella comunità e abbiamo scelto di costruire su questa. Tuttavia, durante l’implementazione, abbiamo scoperto un numero di incompatibilità o funzioni mancanti in libp2p nei confronti delle quali abbiamo contribuito attivamente per poter proseguire con HOPR. Queste scoperte che arrivano durante la programmazione supponendo che la tech stack sia perfetta portano a ritardi nelle tempistiche complessive ma sono in un certo senso inevitabili in un ecosistema così giovane e in rapida progressione.
Flora: Quali sono alcune funzioni rese disponibili fin dall’inizio e perché?
Sebastian: Abbiamo deciso di presentare una prima PoC il prima possibile per scoprire cosa fosse rilevante per la comunità. Alla fine, HOPR non è utile di per sé ma solo se sfruttato da più progetti possibile. Di conseguenza abbiamo optato per i seguenti requisiti MVP:
1. Funzionalità mixnet
2. Versione beta di un relay PKI
3. Livello di pagamento senza risoluzione di dispute on-chain
4. CLI chat client
Flora: Che tipo di aiuto ti servirebbe dalla comunità degli sviluppatori?
Sebastian: HOPR è già open source. Saremmo felici di collaboratori che scrivono codice, riesaminano codice, fanno test, ci aiutano a lavorare sulla documentazione e ci spiegano i punti in cui potremmo fare meglio. Alla fine, HOPR viene costruito per la comunità degli sviluppatori quindi un primo feedback è cruciale per noi.
Flora: Che tipo di aiuto ti servirebbe dalla comunità dei non-sviluppatori?
Sebastian: Dato che HOPR vuol essere la parte mancante tra il livello p2p e il livello di sincronizzazione, stiamo cercando progetti/applicazioni decentralizzate che vogliono offrire ai loro utenti ulteriore privacy usando HOPR. Stiamo cercando attivamente progetti che vogliono sviluppare applicazioni decentralizzate e sono interessati alla privacy anche a livello di network. Inoltre, vorremmo effettuare un’analisi più dettagliata sui modi in cui HOPR può essere integrato in tali progetti e cosa deve essere sviluppato per riuscire a integrare HOPR nel modo più indolore possibile.
Flora: Cosa speri di ottenere con la Binance Fellowship?
Sebastian: Apprezziamo soprattutto l’opportunità di presentare HOPR al mondo, nello specifico a utenti interessati, fornitori di servizi staking, progetti che vogliono usare HOPR e sviluppatori. Infine, stiamo portando avanti questo progetto per la comunità e speriamo di ricevere feedback e critiche costruttive.
Flora: Su cosa pensi di lavorare durante la Fellowship?
Sebastian: Durante i 3 mesi della Binance Labs Fellowship, stiamo lavorando principalmente su tre obiettivi:
1. Private Key Infrastructure (PKI) che migliora l’affidabilità della comunicazione nel network HOPR
2. Architettura per il meccanismo di risoluzione dispute a gruppi che consente un sistema di risoluzione scalabile (ad es. un nodo connesso non risponde)
3. Documentazione e test che permettono a collaboratori esterni di testare più facilmente HOPR per i loro scopi
Flora: Vuoi condividere una storia interessante su HOPR e la sua comunità?
Sebastian: Siamo rimasti positivamente sorpresi dopo aver presentato la demo a EthCC quando abbiamo visto i primi sviluppatori esterni dare un’occhiata a HOPR e persino contribuire codice. Probabilmente questo dimostra il potere dello sviluppo open source nella realtà!
***
E’ tutto, gente! Se vuoi saperne di più su HOPR e contribuire alla codebase, puoi visitare la pagina Github del progetto. HOPR sta facendo crowdfunding su Gitcoin e puoi sostenere il progetto insieme a noi qui.