Si analizza ora come `e stata implementata l’interazione tra l’applicazione web e la serratura smart, simulata utilizzando un Raspberry Pi 3, facendo uso del protocollo Whisper per l’invio dei messaggi contenenti i comandi per il controllo della serratura stessa.
Come gi`a spiegato in sezione 1.4, Whisper per poter inviare un messaggio richiede che questo venga prima crittografato utilizzando una chiave simme- trica condivisa o la chiave pubblica del destinatario. In questo caso si `e scelto di utilizzare la crittografia simmetrica, in quanto diversamente sarebbe stato necessario prevedere anche un meccanismo per lo scambio delle chiavi pub- bliche tra l’utente e la serratura. Quindi sia l’applicazione web che il software Node.js eseguito dal Raspberry, non appena vengono caricati, generano una chiave crittografica per Whisper a partire da una password condivisa, ovvero “ethertravel”.
1 w e b 3 . shh . g e n e r a t e S y m K e y F r o m P a s s w o r d (" e t h e r t r a v e l ", f u n c t i o n( error , k e y I d ) {
2 s y m K e y I d = k e y I d ; 3 }) ;
Fatto ci`o l’applicazione web `e gi`a in grado di inviare messaggi, e per farlo `e sufficiente che invochi la seguente funzione sendWhisper.
1 f u n c t i o n s e n d W h i s p e r ( s t r u c t u r e I D , m e s s a g e ) {
2 w e b 3 . p e r s o n a l . s i g n ( e n c o d e T o H e x ( J S O N . s t r i n g i f y ( m e s s a g e ) ) ,
App . u s e r A c c o u n t , f u n c t i o n( error , s i g n a t u r e ) {
3 if(! e r r o r ) {
5 c o n t e n t : e n c o d e T o H e x ( J S O N . s t r i n g i f y ( m e s s a g e ) ) , 6 s i g n a t u r e : s i g n a t u r e 7 } 8 let p o s t D a t a = { 9 ttl : 7 , 10 t o p i c : g e t T o p i c ( s t r u c t u r e I D ) , 11 p o w T a r g e t : 2.01 , 12 p o w T i m e : 100 , 13 p a y l o a d : e n c o d e T o H e x ( J S O N . s t r i n g i f y ( msg ) ) 14 }; 15 16 p o s t D a t a . s y m K e y I D = s y m K e y I d ; 17 w e b 3 . shh . p o s t ( p o s t D a t a , f u n c t i o n() { 18 c o n s o l e . log (" M e s s a g e s e n t ") ; 19 }) ; 20 } e l s e { 21 c o n s o l e . e r r o r ( e r r o r ) ; 22 } 23 }) ; 24 }
Passato un messaggio in ingresso, questo viene fatto firmare digitalmente all’utente utilizzando la chiave privata del suo account Ethereum e la firma risultante viene allegata al messaggio originale. Il tutto viene poi inserito all’interno di un envelope che aggiunge una serie di attributi tra cui il topic, ovvero l’oggetto del messaggio, che sar`a fondamentale in fase di ricezione. Come oggetto si scelto di impostare l’identificatore della struttura a cui si sta tentando di accedere, in questo modo ogni serratura smart considerer`a soltanto i messaggi effettivamente riguardanti la struttura di appartenenza.
Inizialmente la serratura smart dovr`a essere necessariamente configurata: a tale scopo `e stato previsto un file chiamato settings.json, contenente tutti i parametri da configurare affinch´e l’applicazione sappia a che struttura appartiene la serratura e possa cos`ı mettersi in ascolto dei relativi messaggi in arrivo. 1 { 2 " url ": " h t t p : / / 1 9 2 . 1 6 8 . 1 . 2 0 0 : 8 5 4 5 " , 3 " c o n t r a c t A d d r e s s ": "0 x 3 4 C a E a d 1 6 3 2 2 5 5 d 0 5 F D C 4 9 2 0 5 5 8 7 9 c F 2 9 7 1 3 2 2 9 a " , 4 " s t r u c t u r e I D ": 0 5 }
I tre parametri di configurazione da impostare sono:
• url: l’indirizzo di un’istanza Geth con API Whisper abilitate; • contractAddress: l’indirizzo Ethereum dello smart contract;
• structureID: l’identificatore univoco della struttura a cui la serratura si riferisce.
Completata la configurazione iniziale, il software del dispositivo IOT `e pronto per restare in ascolto di messaggi Whisper in arrivo, aventi come topic lo structureID specificato.
1 w e b 3 j s . shh . g e n e r a t e S y m K e y F r o m P a s s w o r d (" e t h e r t r a v e l ", 2 f u n c t i o n( error , k e y I d ) { 3 4 let f i l t e r = { 5 t o p i c s : [ g e t T o p i c ( s t r u c t u r e I D ) ] , 6 s y m K e y I D : k e y I d 7 }; 8 s t a r t L i s t e n ( f i l t e r ) ; 9 }) ; 10 11 a s y n c f u n c t i o n s t a r t L i s t e n ( f i l t e r ) { 12 13 var m s g F i l t e r = a w a i t w e b 3 j s . shh . n e w M e s s a g e F i l t e r ( f i l t e r ) ; 14 15 m s g F i l t e r . w a t c h (f u n c t i o n( error , r e s u l t ) { 16 if (! e r r o r ) { 17 let m e s s a g e = d e c o d e F r o m H e x ( r e s u l t . p a y l o a d ) ; 18 let g u e s t A d d r e s s = c o n t r a c t . g e t C u r r e n t G u e s t ( s t r u c t u r e I D ) ; 19 let res = c o n t r a c t . g e t S t r u c t u r e D e t a i l s ( s t r u c t u r e I D ) ; 20 let o w n e r A d d r e s s = res [ 0 ] ; 21 w e b 3 j s . p e r s o n a l . e c R e c o v e r ( m e s s a g e . content , 22 m e s s a g e . s i g n a t u r e , f u n c t i o n( er , a d d r e s s ) { 23 var a l l o w e d = ( a d d r e s s == g u e s t A d d r e s s 24 || a d d r e s s == o w n e r A d d r e s s ) ; 25 var c o m m a n d = d e c o d e F r o m H e x ( m e s s a g e . c o n t e n t ) ; 26 if( a l l o w e d && c o m m a n d == " o p e n ") { 27 LED . w r i t e S y n c (1) ; 28 } e l s e if( a l l o w e d && c o m m a n d == " c l o s e ") { 29 LED . w r i t e S y n c (0) ; 30 } 31 }) ; 32 } 33 }) ; 34 }
Ricevuto un messaggio, il software interroga lo smart contract richiaman- do le funzioni getCurrentGuest e getStructureDetails, per ottenere gli indirizzi pubblici di coloro che hanno i permessi necessari per poter impartire comandi alla serratura, ovvero gli indirizzi del proprietario dell’appartamen- to e dell’eventuale cliente che vi sta soggiornando in quel preciso momento. Dopodich´e, richiamando la funzione ecRecover, ricalcola a partire dalla fir- ma allegata al messaggio, l’indirizzo Ethereum pubblico del mittente, che
verr`a confrontato con quelli restituiti dalla blockchain. Soltanto se il mitten- te del messaggio corrisponder`a a una delle due entit`a autorizzate, la serratura verr`a aperta o chiusa secondo quanto richiesto nel messaggio. L’apertura e la chiusura viene simulata attraverso l’accensione e lo spegnimento di un led collegato al Raspberry Pi.
Valutazione
In questo capitolo si fornir`a una valutazione del lavoro svolto andando a verificare se sono stati raggiunti tutti gli obiettivi che questa tesi si prefissava. Nella prima parte si valuter`a l’applicazione realizzata e in particolare i limiti della tecnologia blockchain che sono emersi durante lo sviluppo del progetto. Nella seconda parte si discuter`a invece come `e stata svolta la validazione dell’applicazione.
5.1
Valutazione dell’applicazione
Gli obiettivi di questa tesi sono stati raggiunti con successo, l’applicazione web decentralizzata realizzata risulta infatti soddisfare tutti i requisiti che erano stati definiti durante la fase iniziale di analisi. La sua progettazione e realizzazione hanno richiesto lo studio di diverse tecnologie innovative e un’analisi per capire come integrarle tra loro per riuscire a concretizzare il risultato atteso.
La piattaforma web per l’affitto di case vacanza implementata pu`o rite- nersi quindi soddisfacente, in quanto realizza tutte le funzionalit`a previste in modo totalmente trasparente per l’utente finale rispetto a un sito web tradi- zionale, se non fosse che per il suo funzionamento `e richiesta l’installazione dell’estensione Metamask o l’utilizzo di un browser specifico come Mist per poter gestire il wallet Ethereum e inviare le transazioni alla blockchain.
Questo progetto ha permesso inoltre di evidenziare i limiti che, ad oggi, le tecnologie utilizzate per la realizzazione di applicazioni decentralizzate come questa, ancora presentano. Tra i limiti pi`u importanti si evidenziano:
• scalabilit`a limitata: tra i pi`u grandi vantaggi che si ottengono svi- luppando un’applicazione decentralizzata vi `e la mancata necessit`a di dover costruire, configurare e manutenere un’infrastruttura sulla quale
rilasciare ed eseguire l’applicazione stessa, in quanto si sfrutta l’infra- struttura della rete preesistente scelta. Questa caratteristica pu`o per`o risultare anche un enorme limite, infatti il livello massimo di scalabilit`a dell’applicazione sar`a determinato dalla capacit`a massima della block- chain scelta. In particolare, Ethereum in questo momento `e in grado di gestire un throughput di circa 15 transazioni al secondo. Se si conside- ra che sulla sola piattaforma Booking vengono ogni giorno fatte oltre 1.500.000 prenotazioni1, `e semplice verificare che una singola applica-
zione con questo genere di volumi sarebbe gi`a in grado di saturare e congestionare l’intera rete. La blockchain di Ethereum non `e quindi ancora pronta ad ospitare applicazioni reali con un consistente numero di utenti senza che non si verifichino gravi stalli della rete, come gi`a successo nel dicembre 2017 con il rilascio dell’applicazione CryptoKit- ties [19] che nel giro di pochi giorni divent`o virale. A tal proposito la roadmap di Ethereum prevede gi`a aggiornamenti per aumentare in futuro il numero di transazioni al secondo che potr`a essere in grado di gestire. La scalabilit`a delle blockchain resta comunque uno dei temi pi`u dibattuti e su cui si stanno concentrando la maggior parte degli sforzi della ricerca;
• impossibilit`a di aggiornare facilmente gli smart contract: dal momento che il codice sorgente degli smart contract `e memorizzato all’interno della blockchain, questo diventa immutabile e permanen- te, rendendo di fatto impossibile aggiornare direttamente il contenuto di uno smart contract gi`a pubblicato. Questo non impedisce in ma- niera assoluta l’aggiornamento di un’applicazione decentralizzata, ma lo complica notevolmente, costringendo gli sviluppatori a ricorrere a diversi stratagemmi pi`u articolati che comportano la creazione di un nuovo contratto che dovr`a interagire in qualche modo con il precedente, divenendo di fatto una specie di strato di secondo livello;
• impossibilit`a di comunicare con l’esterno: uno smart contract non pu`o interagire con servizi offerti dal mondo esterno come email o notifiche sms. Se si desidera realizzare un’applicazione decentralizzata in grado di fornire anche questo tipo di funzionalit`a allora `e necessario prevedere l’utilizzo di un server centrale che realizzi questi servizi in risposta ad eventi scatenati dallo smart contract per i quali rimane costantemente in ascolto. Inoltre, `e da notare che uno smart contract pu`o fornire risposte o scatenare eventi soltanto a seguito di richieste effettuate da un client, in quanto la sua esecuzione non pu`o essere
programmata per eseguire compiti periodici o avviare per primo una comunicazione;
• impossibilit`a di memorizzare dati sensibili o confidenziali: la scelta di utilizzare una blockchain pubblica come Ethereum consente da una parte di poter offrire all’utente una completa trasparenza sul- l’intero funzionamento dell’applicazione, dall’altra impedisce per`o di poter raccogliere dati sensibili o confidenziali in quanto memorizzan- doli nella blockchain verrebbero esposti pubblicamente. Una possibile soluzione potrebbe essere quella di ricorrere alla crittografia, cifrando i dati prima di inviarli alla blockchain. Questo non impedirebbe per`o ad un eventuale attaccante di provare a violare la crittografia cercando di individuare la chiave utilizzata attraverso un attacco brute-force, che per quanto lento e dispendioso possa essere in base all’algoritmo scelto, pu`o comunque non risultare un deterrente sufficiente in base al valore delle informazioni che l’attaccante sta cercando di carpire;
• tempi di attesa: la validazione delle transazioni, realizzata attraver- so il processo di mining, richiede sempre un certo periodo di tempo, dipendente dal livello di congestione della rete in un dato momento e dal gas price configurato dall’utente. Dal momento che la blockchain di Ethereum genera un nuovo blocco mediamente ogni 14 secondi, l’utente dovr`a attendere circa 10-20 secondi per vedere la propria transazione approvata (sia essa un trasferimento di Ether o l’invocazione di un metodo di uno smart contract che ne provoca un aggiornamento dello stato). Oggigiorno gli utenti hanno aspettative molto elevate quando navigano sul web e si aspettano che tutte le pagine e tutti i servizi vengano sempre erogati in modo praticamente istantaneo. L’attesa ne- cessaria per il mining presente nelle applicazioni web decentralizzate pu`o quindi compromettere parzialmente l’esperienza utente.
Risulta quindi chiaro che la blockchain non pu`o essere impiegata in qua- lunque contesto e che presenta, ad oggi, ancora diversi problemi dovuti alla scarsa maturit`a della tecnologia.