En aquest article parlaré de com vam intentar construir el lloguer descentralitzat de patinets amb contractes intel·ligents i per què encara necessitàvem un servei centralitzat.
Com va començar tot
El novembre de 2018 vam participar en un hackathon dedicat a Internet de les coses i blockchain. El nostre equip va triar compartir patinets com a idea, ja que teníem un patinet del patrocinador d'aquest hackathon. El prototip semblava una aplicació mòbil que permet posar en marxa un patinet mitjançant NFC. Des del punt de vista del màrqueting, la idea es recolzava en una història sobre un "futur brillant" amb un ecosistema obert on qualsevol pot convertir-se en llogater o propietari, tot basat en contractes intel·ligents.
A les nostres parts interessades els va agradar molt aquesta idea i van decidir convertir-la en un prototip per mostrar-lo a les exposicions. Després de diverses demostracions reeixides al Mobile World Congress i al Bosch Connected World el 2019, es va decidir provar el lloguer de patinets amb usuaris reals, empleats de Deutsche Telekom. Així que vam començar a desenvolupar un MVP de ple dret.
Blockchain amb crosses
No crec que valgui la pena explicar quina diferència hi ha entre un projecte que es mostrarà a l'escenari i un que serà utilitzat per gent real. En sis mesos vam haver de convertir el prototip cru en quelcom adequat per a un pilot. I llavors vam entendre què significa "dolor".
Per tal de descentralitzar i obrir el nostre sistema, vam decidir utilitzar contractes intel·ligents d'Ethereum. L'elecció va recaure en aquesta plataforma de serveis en línia descentralitzats per la seva popularitat i la capacitat de crear una aplicació sense servidor. Teníem previst implementar el nostre projecte de la següent manera.
Però, malauradament, un contracte intel·ligent és un codi executat per una màquina virtual en el moment d'una transacció i no pot substituir un servidor complet. Per exemple, un contracte intel·ligent no pot realitzar accions pendents o programades. En el nostre projecte, això no ens va permetre implantar un servei de lloguer per minut, com ho fan la majoria dels serveis de cotxe compartit moderns. Per tant, vam carregar la criptomoneda de l'usuari després de completar la transacció sense estar segurs que tenia prou diners. Aquest enfocament només és acceptable per a un pilot intern i, per descomptat, afegeix problemes a l'hora de dissenyar un projecte de producció complet.
A tot l'anterior s'afegeix la humitat de la pròpia plataforma. Per exemple, si escriviu un contracte intel·ligent amb una lògica diferent de les fitxes ERC-20, trobareu problemes de gestió d'errors. Normalment, si l'entrada és incorrecta o els nostres mètodes no funcionen correctament, rebem un codi d'error en resposta. En el cas d'Ethereum, no podem obtenir res més que la quantitat de gas gastat per realitzar aquesta funció. El gas és una moneda que s'ha de pagar per transaccions i càlculs: com més operacions en el teu codi, més pagaràs. Per tant, per entendre per què el codi no funciona, primer el proveu simulant tots els errors possibles i codifiqueu el gas gastat com a codi d'error. Però si canvieu el codi, aquest tractament d'errors es trencarà.
A més, és gairebé impossible crear una aplicació mòbil que funcioni amb la cadena de blocs de manera honesta, sense utilitzar una clau emmagatzemada en algun lloc del núvol. Tot i que existeixen carteres honestes, no proporcionen interfícies per signar transaccions externes. Això vol dir que no veureu una aplicació nativa tret que tingui una cartera criptogràfica integrada, en la qual els usuaris tindran poca confiança (no hi confiaria). Com a resultat, també hem hagut de tallar un racó aquí. Els contractes intel·ligents es van lliurar a la xarxa privada Ethereum i la cartera estava basada en núvol. Però malgrat això, els nostres usuaris van experimentar totes les "delícies" dels serveis descentralitzats en forma de llargues esperes de transaccions diverses vegades per sessió de lloguer.
Tot això ens porta a aquesta arquitectura. D'acord, és molt diferent del que teníem previst.
As al forat: identitat autosobirana
No podeu construir un sistema completament descentralitzat sense una identitat descentralitzada. La identitat autosobirana (SSI) és responsable d'aquesta part, l'essència de la qual és que llenceu el proveïdor d'identitat centralitzat (IDP) i distribuïu totes les dades i la responsabilitat a la gent. Ara l'usuari decideix quines dades necessita i amb qui les compartirà. Tota aquesta informació es troba al dispositiu de l'usuari. Però per a l'intercanvi necessitarem un sistema descentralitzat per emmagatzemar proves criptogràfiques. Totes les implementacions modernes del concepte SSI utilitzen blockchain com a emmagatzematge.
"Què té a veure això amb l'as al forat?" - demanes. Vam posar en marxa el servei de proves internes als nostres propis empleats a Berlín i Bonn, i vam trobar dificultats en forma de sindicats alemanys. A Alemanya, les empreses tenen prohibit controlar els moviments dels empleats i els sindicats ho controlen. Aquestes restriccions posen fi a l'emmagatzematge centralitzat de les dades d'identitat dels usuaris, ja que en aquest cas sabríem la ubicació dels empleats. Al mateix temps, no vam poder evitar revisar-los per la possibilitat que ens robessin patinets. Però gràcies a Self-Sovereign Identity, els nostres usuaris van utilitzar el sistema de manera anònima i el patinet mateix va comprovar el seu carnet de conduir abans de començar el lloguer. Com a resultat, vam emmagatzemar mètriques d'usuari anònimes; no teníem documents ni dades personals: totes estaven contingudes als dispositius dels mateixos controladors. Així, gràcies a SSI, la solució al problema del nostre projecte estava preparada fins i tot abans que aparegués.
El dispositiu em va donar problemes
No hem implementat la identitat autosobirana nosaltres mateixos, ja que requereix experiència en criptografia i molt de temps. En canvi, vam aprofitar el producte dels nostres socis Jolocom i vam integrar la seva cartera mòbil i els seus serveis a la nostra plataforma. Malauradament, aquest producte té un inconvenient important: el llenguatge de desenvolupament principal és Node.js.
Aquesta pila de tecnologia limita molt la nostra selecció de maquinari integrat en un scooter. Afortunadament, al principi del projecte, vam triar el Raspberry Pi Zero i vam aprofitar tots els avantatges d'un microordinador complet. Això ens va permetre executar Node.js voluminós al patinet. A més, vam rebre seguiment i accés remot mitjançant VPN mitjançant eines ja fetes.
en conclusió
Malgrat tot el "dolor" i problemes, el projecte es va posar en marxa. No tot va funcionar com havíem previst, però realment era possible anar amb patinets llogant-los.
Sí, vam cometre una sèrie d'errors a l'hora de dissenyar l'arquitectura que no ens van permetre descentralitzar completament el servei, però fins i tot sense aquests errors difícilment hauríem pogut crear una plataforma sense servidor. Una cosa és escriure una altra cripto-piràmide i una altra molt diferent és escriure un servei complet en el qual cal gestionar errors, resoldre casos límit i realitzar tasques pendents. Esperem que les noves plataformes que han sorgit recentment siguin més flexibles i funcionals.
Font: www.habr.com