In questo articolo parlerò di come abbiamo cercato di costruire un servizio di noleggio scooter decentralizzato basato su smart contract e perché abbiamo comunque avuto 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 il car sharing di scooter, poiché avevamo uno scooter fornito dallo sponsor di questo hackathon. Il prototipo appariva come un'app mobile che consentiva di avviare lo scooter tramite NFC. Dal punto di vista del marketing, l'idea era sostenuta da un racconto su un 'futuro luminoso' con un ecosistema aperto, dove chiunque può diventare affittuario o locatore, il tutto basato su smart contract.
Questa idea è piaciuta molto ai nostri stakeholder e hanno deciso di trasformarla in un prototipo per dimostrazioni in fiere. Dopo diverse presentazioni di successo 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
Credo non sia necessario spiegare la differenza tra un progetto per una dimostrazione sul palco e uno che sarà utilizzato da persone reali. Nei sei mesi successivi dovevamo trasformare un prototipo grezzo in qualcosa di adatto per un pilota. Ed è qui che abbiamo compreso cosa significhi 'dolore'.
Per rendere il nostro sistema decentralizzato e aperto, abbiamo deciso di utilizzare gli smart contract di Ethereum. La scelta è ricaduta su questa piattaforma di servizi online decentralizzati per la sua popolarità e la possibilità di costruire un'applicazione senza server. Pianificavamo di attuare il nostro progetto nel seguente modo.
Ma, sfortunatamente, lo smart contract è un codice eseguito da una macchina virtuale al momento della transazione e non può sostituire un vero e proprio un server. Ad esempio, uno smart contract non può eseguire azioni ritardate o programmate. Nel nostro progetto, ciò ha impedito di realizzare un servizio di noleggio a minuti, come fanno la maggior parte dei moderni car sharing. Pertanto, addebitavamo la criptovaluta all'utente al termine dell'operazione senza avere la certezza che avesse un saldo sufficiente. Questo approccio è accettabile solo per un pilota interno e, senza dubbio, genera problemi durante la progettazione di un progetto di produzione completo.
A tutto ciò si aggiunge l'instabilità della piattaforma stessa. Ad esempio, scrivendo uno smart contract con logiche diverse dai token ERC-20, ci si imbatte in problemi di gestione degli errori. Di solito, con un input errato o un malfunzionamento dei nostri metodi, riceviamo un codice di errore in risposta. Nel caso di Ethereum, non possiamo ottenere nulla se non la quantità di gas spesa per eseguire quella funzione. Il gas è la valuta da pagare per transazioni e calcoli: più operazioni ci sono nel tuo codice, più pagherai. Pertanto, per capire perché il codice non funziona, è necessario testarlo simulando tutti gli errori possibili e hardcodare il gas speso come codice di errore. Ma se modifichi il tuo codice, questa gestione degli errori smetterà di funzionare.
Inoltre, è praticamente impossibile creare un'app mobile che funzioni con la blockchain in modo onesto, senza utilizzare una chiave memorizzata da qualche parte nel cloud. Anche se esistono portafogli onesti, questi non forniscono interfacce per firmare transazioni esterne. Questo significa che non potrai avere un'app nativa se non include un portafoglio crypto, di cui gli utenti avranno poca fiducia (anch'io non mi fiderei). Di conseguenza, qui abbiamo dovuto tagliare degli angoli. Gli smart contract venivano consegnati a una rete privata Ethereum, mentre il portafoglio era nel cloud. Ma nonostante questo, i nostri utenti hanno percepito tutte le 'delizie' dei servizi decentralizzati sotto forma di attese prolungate delle transazioni più volte durante una sessione di noleggio.
Tutto ciò ci porta a un'architettura del genere. Dite la verità, è molto diversa da ciò che avevamo pianificato.
L'asso nella manica: Identità Sovrana
Non è possibile costruire un sistema completamente decentralizzato senza un'identificazione decentralizzata. Questa parte è gestita dall'Identity Autonoma (SSI), il cui principio fondamentale è che si abbandona un fornitore di identità centralizzato (IDP) e si restituiscono al popolo tutti i dati e la responsabilità per essi. Ora l'utente decide quali dati gli servono e con chi condividerli. Tutte queste informazioni risiedono sul dispositivo dell'utente. Ma per lo scambio ci servirà un sistema decentralizzato di archiviazione di prove crittografiche. Tutte le implementazioni moderne del concetto di SSI utilizzano la blockchain come archivio.
“Cosa c'entra il re di denari?” — direte voi. Il servizio lo abbiamo lanciato per un test interno con i nostri dipendenti a Berlino e Bonn, e ci sono sorte difficoltà a causa dei sindacati tedeschi. In Germania le aziende non possono monitorare i movimenti dei dipendenti, e i sindacati controllano questo aspetto. Queste restrizioni pongono un veto sull'archiviazione centralizzata dei dati delle identità degli utenti, poiché in questo caso conosceremmo la posizione dei dipendenti. D'altra parte, non potevamo non controllarli a causa della possibilità di furti di scooter. Ma grazie all'Identity Autonoma, i nostri utenti hanno utilizzato il sistema in modo anonimo, e lo scooter controllava autonomamente la validità della patente prima di avviare l'affitto. Di conseguenza, abbiamo conservato metriche anonime degli utenti, senza alcun documento o dato personale: tutti erano contenuti sui dispositivi dei conducenti stessi. Così, grazie a SSI, la soluzione del problema nel nostro progetto era pronta ancor prima che si presentasse.
Il dispositivo ha sollevato problemi
Non abbiamo implementato autonomamente l'Identity Autonoma, poiché richiede competenze in crittografia e molto tempo. Invece, abbiamo utilizzato il prodotto dei nostri partner Jolocom e integrato il loro portafoglio mobile e servizi nella nostra piattaforma. Sfortunatamente, questo prodotto ha un grave svantaggio: il linguaggio principale di sviluppo è Node.js.
Questo stack tecnologico limita molto la nostra scelta dell'hardware integrato nello scooter. Fortunatamente, all'inizio del progetto abbiamo scelto Raspberry Pi Zero, e abbiamo sfruttato tutti i vantaggi di un microcomputer completo. Questo ci ha permesso di far girare Node.js ingombrante sullo scooter. Inoltre, abbiamo ottenuto monitoraggio e accesso remoto tramite vpn, utilizzando strumenti pronti.
In conclusione
Nonostante tutto il “dolore” e i problemi, il progetto è stato avviato. Non tutto funzionava come avevamo pianificato, ma era davvero possibile utilizzare gli scooter prendendoli in affitto.
Sì, abbiamo commesso diversi errori nella progettazione dell'architettura, che non ci hanno permesso di rendere il servizio completamente decentralizzato, ma anche senza questi errori è probabile che non saremmo riusciti a creare una piattaforma serverless. È una cosa scrivere un'altra piramide crypto e un'altra è un servizio completo, in cui bisogna gestire gli errori, risolvere casi limite e gestire attività programmate. Speriamo che le nuove piattaforme emerse di recente siano più flessibili e funzionali.
Fonte: habr.com
