In questo articolo parlerò di come abbiamo provato a costruire un noleggio di scooter decentralizzato con contratti intelligenti e perché avevamo ancora bisogno di un servizio centralizzato.
Come tutto ebbe inizio
Nel novembre 2018 abbiamo preso parte ad un hackathon dedicato all'Internet of Things e alla blockchain. Il nostro team ha scelto come idea lo scooter sharing poiché avevamo uno scooter dallo sponsor di questo hackathon. Il prototipo sembrava un'applicazione mobile che permettesse di avviare uno scooter tramite NFC. Da un punto di vista del marketing, l’idea è stata supportata da una storia su un “futuro luminoso” con un ecosistema aperto in cui chiunque può diventare inquilino o proprietario, il tutto sulla base di contratti intelligenti.
Questa idea è piaciuta molto ai nostri stakeholder e hanno deciso di trasformarla in un prototipo da esporre alle mostre. Dopo diverse dimostrazioni di successo al Mobile World Congress e al Bosch Connected World nel 2019, si è deciso di testare il noleggio scooter con utenti reali, dipendenti di Deutsche Telekom. Quindi abbiamo iniziato a sviluppare un MVP a tutti gli effetti.
Blockchain con le stampelle
Non credo valga la pena spiegare quale sia la differenza tra un progetto da mostrare sul palco e uno che verrà utilizzato da persone reali. In sei mesi abbiamo dovuto trasformare il prototipo grezzo in qualcosa di adatto per un pilota. E poi abbiamo capito cosa vuol dire “dolore”.
Per rendere il nostro sistema decentralizzato e aperto, abbiamo deciso di utilizzare i contratti intelligenti di Ethereum. La scelta è caduta su questa piattaforma di servizi online decentralizzati per la sua popolarità e la capacità di creare un'applicazione serverless. Abbiamo pianificato di implementare il nostro progetto come segue.
Ma, sfortunatamente, un contratto intelligente è un codice eseguito da una macchina virtuale al momento di una transazione e non può sostituire un server a tutti gli effetti. Ad esempio, uno smart contract non può eseguire azioni in sospeso o pianificate. Nel nostro progetto questo non ci ha permesso di implementare un servizio di noleggio al minuto, come fanno la maggior parte dei moderni servizi di car sharing. Pertanto, abbiamo addebitato la criptovaluta all'utente dopo aver completato la transazione senza essere sicuri che avesse abbastanza soldi. Questo approccio è accettabile solo per un progetto pilota interno e, ovviamente, aggiunge problemi durante la progettazione di un progetto di produzione completo.
A tutto quanto sopra va aggiunta l'umidità della piattaforma stessa. Ad esempio, se scrivi uno smart contract con logica diversa dai token ERC-20, incontrerai problemi di gestione degli errori. Di solito, se l'input non è corretto o i nostri metodi non funzionano correttamente, riceviamo in risposta un codice di errore. Nel caso di Ethereum non possiamo ottenere altro che la quantità di gas spesa per svolgere questa funzione. Il gas è una valuta che deve essere pagata per transazioni e calcoli: più operazioni compirai nel tuo codice, più pagherai. Quindi, per capire perché il codice non funziona, devi prima testarlo simulando tutti i possibili errori e codificare il gas consumato come codice di errore. Ma se modifichi il codice, questa gestione degli errori si interromperà.
Inoltre, è quasi impossibile creare un'applicazione mobile che funzioni onestamente con la blockchain, senza utilizzare una chiave archiviata da qualche parte nel cloud. Sebbene esistano portafogli onesti, non forniscono interfacce per la firma di transazioni esterne. Ciò significa che non vedrai un'applicazione nativa a meno che non abbia un portafoglio crittografico integrato, di cui gli utenti avranno poca fiducia (non mi fiderei). Di conseguenza, anche qui abbiamo dovuto prendere una scorciatoia. I contratti intelligenti venivano consegnati alla rete privata Ethereum e il portafoglio era basato su cloud. Ma nonostante ciò, i nostri utenti hanno sperimentato tutte le “delizie” dei servizi decentralizzati sotto forma di lunghe attese per le transazioni più volte per sessione di noleggio.
Tutto ciò ci porta a questa architettura. D'accordo, è molto diverso da quello che avevamo pianificato.
Asso nella manica: identità auto-sovrana
Non è possibile costruire un sistema completamente decentralizzato senza un’identità decentralizzata. Di questa parte è responsabile la Self-Sovereign Identity (SSI), la cui essenza è che si elimina il fornitore di identità centralizzato (IDP) e si distribuiscono tutti i dati e la relativa responsabilità alle persone. Ora l'utente decide di quali dati ha bisogno e con chi condividerli. Tutte queste informazioni si trovano sul dispositivo dell'utente. Ma per lo scambio avremo bisogno di un sistema decentralizzato per l’archiviazione delle prove crittografiche. Tutte le moderne implementazioni del concetto SSI utilizzano la blockchain come spazio di archiviazione.
"Cosa c'entra questo con l'asso nella manica?" - tu chiedi. Abbiamo lanciato il servizio di test interni sui nostri dipendenti a Berlino e Bonn e abbiamo incontrato difficoltà da parte dei sindacati tedeschi. In Germania, alle aziende è vietato monitorare i movimenti dei dipendenti e i sindacati lo controllano. Queste restrizioni mettono fine all’archiviazione centralizzata dei dati sull’identità degli utenti, poiché in questo caso conosceremmo l’ubicazione dei dipendenti. Allo stesso tempo non potevamo fare a meno di controllarli perché c’era la possibilità che gli scooter venissero rubati. Ma grazie alla Self-Sovereign Identity, i nostri utenti hanno utilizzato il sistema in modo anonimo e lo scooter stesso ha controllato la patente di guida prima di iniziare il noleggio. Di conseguenza, archiviavamo metriche utente anonime; non avevamo documenti o dati personali: erano tutti contenuti sui dispositivi degli autisti stessi. Pertanto, grazie a SSI, la soluzione al problema nel nostro progetto era pronta ancor prima che apparisse.
Il dispositivo mi ha dato problemi
Non abbiamo implementato noi stessi l’identità auto-sovrana, poiché richiede esperienza in crittografia e molto tempo. Invece, abbiamo approfittato del prodotto dei nostri partner Jolocom e abbiamo integrato il loro portafoglio mobile e i loro servizi nella nostra piattaforma. Sfortunatamente, questo prodotto presenta uno svantaggio significativo: il linguaggio di sviluppo principale è Node.js.
Questo stack tecnologico limita notevolmente la nostra scelta di hardware integrato in uno scooter. Fortunatamente, all'inizio del progetto, abbiamo scelto il Raspberry Pi Zero e abbiamo sfruttato tutti i vantaggi di un microcomputer a tutti gli effetti. Questo ci ha permesso di eseguire ingombranti Node.js sullo scooter. Inoltre, abbiamo ricevuto monitoraggio e accesso remoto tramite VPN utilizzando strumenti già pronti.
insomma
Nonostante tutto il “dolore” e i problemi, il progetto è stato avviato. Non tutto ha funzionato come avevamo previsto, ma è stato davvero possibile guidare gli scooter noleggiandoli.
Sì, abbiamo commesso una serie di errori durante la progettazione dell'architettura che non ci hanno permesso di rendere il servizio completamente decentralizzato, ma anche senza questi errori difficilmente saremmo riusciti a creare una piattaforma serverless. Una cosa è scrivere un'altra cripto-piramide, un'altra è scrivere un servizio completo in cui è necessario gestire gli errori, risolvere casi limite ed eseguire attività in sospeso. Speriamo che le nuove piattaforme emerse di recente siano più flessibili e funzionali.
Fonte: habr.com