In questo articolo parlerò di come abbiamo cercato di costruire un noleggio decentralizzato di scooter basato su smart contract e perché avevamo comunque bisogno di un servizio centralizzato.
Come è iniziato tutto
Nel novembre 2018 abbiamo partecipato a un hackathon dedicato all'Internet delle cose e alla blockchain. Come idea, il nostro team ha scelto lo scooter sharing, poiché avevamo uno scooter fornito da uno sponsor di questo hackathon. Il prototipo era un'app mobile che permetteva di avviare lo scooter tramite NFC. Dal punto di vista del marketing, l'idea era sostenuta da una narrazione sul "futuro luminoso" con un ecosistema aperto, in cui chiunque poteva diventare affittuario o locatore, il tutto basato su smart contract.
Quest'idea è piaciuta molto ai nostri stakeholder, e hanno deciso di trasformarla in un prototipo da dimostrare alle fiere. Dopo diversi successi al Mobile World Congress e al Bosch Connected World nel 2019, è stata presa la decisione di testare il noleggio di scooter con utenti reali, dipendenti di Deutsche Telekom. Così abbiamo iniziato a sviluppare un MVP completo.
Blockchain su stampelle
Penso che non sia necessario spiegare la differenza tra un progetto concepito per essere mostrato sul palco e uno che sarà utilizzato da persone reali. In sei mesi dovevamo trasformare un prototipo grezzo in qualcosa di adatto per un pilota. E qui ci siamo resi conto di cosa significasse "dolore".
Per rendere il nostro sistema decentralizzato e aperto, abbiamo deciso di utilizzare smart contract Ethereum. La scelta è caduta su questa piattaforma di servizi online decentralizzati per la sua popolarità e la possibilità di costruire un'applicazione senza server. Avevamo in mente di realizzare il nostro progetto nel seguente modo.
Ma, sfortunatamente, uno smart contract è codice eseguito da una macchina virtuale al momento della transazione, e non può sostituire un completo server. Ad esempio, un contratto smart non può eseguire azioni ritardate o programmati. Nel nostro progetto, ciò ha impedito di implementare un servizio di noleggio a minuti, come fanno la maggior parte dei car sharing moderni. Pertanto, addebitavamo criptovaluta all'utente dopo il completamento dell'operazione senza essere certi che avesse una quantità sufficiente di denaro. Questo approccio è accettabile solo per un pilota interno e, senza dubbio, aggiunge problemi nella progettazione di un progetto di produzione completo.
A ciò si aggiunge l'umidità della piattaforma stessa. Ad esempio, scrivendo un contratto smart con una logica diversa dai token ERC-20, ci si imbatte in problemi di gestione degli errori. Di solito, in caso di input non valido o malfunzionamento dei nostri metodi, riceviamo un codice di errore in risposta. Nel caso di Ethereum, non possiamo ottenere nulla tranne la quantità di gas spesa per eseguire questa funzione. Il gas è la valuta che deve essere pagata per transazioni e calcoli: più operazioni ci sono nel tuo codice, più pagherai. Pertanto, per capire perché il codice non funziona, prima lo testi, simulando tutti i possibili errori, e hardcodificando il gas speso come codice di errore. Ma se modifichi il tuo codice, questa gestione degli errori si romperà.
Inoltre, è praticamente impossibile creare un'app mobile che funzioni correttamente con il blockchain, senza utilizzare una chiave che è conservata da qualche parte nel cloud. Anche se i portafogli onesti esistono, non forniscono interfacce per firmare transazioni esterne. Questo significa che non vedrai un'app nativa se non include un portafoglio crittografico, a cui gli utenti non si affideranno molto (io non mi fiderei). Di conseguenza, anche qui abbiamo dovuto tagliare l'angolo. I contratti smart venivano consegnati in una rete privata Ethereum, mentre il portafoglio era basato sul cloud. Ma nonostante ciò, i nostri utenti hanno vissuto tutte le “delizie" dei servizi decentralizzati in forma di lunghi tempi di attesa per le transazioni più volte durante la sessione di noleggio.
Tutto ciò ci porta a un'architettura come questa. Concordate, è molto diversa da ciò che avevamo pianificato.
Asso nella manica: Identità decentralizzata
Non è possibile costruire un sistema completamente decentralizzato senza un'identificazione decentralizzata. Questa parte è gestita dall'Identità Auto-Sovrana (SSI), il cui concetto principale è che si elimina il fornitore di identità centralizzato (IDP) e si assegna a ciascun individuo i propri dati e la responsabilità di essi. Ora l'utente decide da solo quali dati gli servono e con chi li condivide. Tutte queste informazioni sono memorizzate sul dispositivo dell'utente. Tuttavia, per lo scambio avremo bisogno di un sistema di archiviazione decentralizzato per le prove crittografiche. Tutte le implementazioni moderne del concetto di SSI utilizzano la blockchain come archivio.
"Che c'entra il jolly?" — vi chiederete. Il servizio è stato lanciato per un test interno con i nostri stessi dipendenti a Berlino e Bonn, e ci siamo trovati di fronte a difficoltà dovute ai sindacati tedeschi. In Germania, alle aziende è vietato monitorare i movimenti dei dipendenti, e questo è sotto il controllo dei sindacati. Queste restrizioni pongono un veto all'archiviazione centralizzata dei dati di identificazione degli utenti, poiché in questo caso ci sarebbe nota la posizione dei dipendenti. Allo stesso tempo, non potevamo evitarne il controllo a causa del rischio di furti di scooter. Ma grazie all'Identità Auto-Sovrana, i nostri utenti utilizzavano il sistema in forma anonima, e lo scooter verificava la presenza della patente di guida direttamente prima dell'inizio del noleggio. Di conseguenza, conservavamo metriche degli utenti anonimizzate, senza documenti personali né dati sensibili: tutti erano custoditi sui dispositivi stessi dei conducenti. Così, grazie a SSI, la soluzione al problema nel nostro progetto era pronta già prima della sua apparizione.
Il dispositivo ha sollevato problemi
Non abbiamo implementato autonomamente l'Identità Auto-Sovrana, poiché ciò richiede competenze in crittografia e molto tempo. Invece, abbiamo utilizzato il prodotto dei nostri partner Jolocom e integrato il loro wallet mobile e i servizi nella nostra piattaforma. Purtroppo, questo prodotto presenta un notevole svantaggio: il linguaggio principale di sviluppo è Node.js.
Questo stack tecnologico ci limita notevolmente nella scelta dell'hardware integrato nello scooter. Per fortuna, all'inizio del progetto abbiamo scelto Raspberry Pi Zero e abbiamo sfruttato tutti i vantaggi di un vero microcomputer. Questo ci ha permesso di avviare un ingombrante Node.js sullo scooter. Inoltre, abbiamo ottenuto monitoraggio e accesso remoto tramite vpn, utilizzando strumenti già pronti.
In conclusione
Nonostante tutto il dolore e i problemi, il progetto è stato avviato. Non tutto ha funzionato come avevamo pianificato, ma sugli scooter era davvero possibile fare un giro, prendendoli in affitto.
Sì, abbiamo commesso una serie di errori nella 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 l'ennesima criptopiramide e un'altra completamente diversa è un servizio completo, in cui è necessario gestire errori, risolvere casi borderline e svolgere attività pianificate. Speriamo che le nuove piattaforme recentemente emerse siano più flessibili e funzionali.
Fonte: habr.com
