Neste artigo falarei de como tentamos construír un aluguer de scooters descentralizado en contratos intelixentes e por que aínda necesitabamos un servizo centralizado.
Como todo comezou
En novembro de 2018, participamos nun hackathon dedicado á Internet das Cousas e á cadea de bloques. O noso equipo escolleu compartir scooters como idea xa que tiñamos un scooter do patrocinador deste hackathon. O prototipo parecía unha aplicación móbil que permite iniciar un scooter a través de NFC. Desde o punto de vista do marketing, a idea foi apoiada nunha historia sobre un "futuro brillante" cun ecosistema aberto onde calquera pode converterse en arrendatario ou propietario, todo iso baseado en contratos intelixentes.
Aos nosos interesados gustoulles moito esta idea e decidiron convertela nun prototipo para exhibir en exposicións. Despois de varias demostracións exitosas no Mobile World Congress e Bosch Connected World en 2019, decidiuse probar o aluguer de scooters con usuarios reais, empregados de Deutsche Telekom. Entón comezamos a desenvolver un MVP completo.
Blockchain en muletas
Non creo que valga a pena explicar cal é a diferenza entre un proxecto que se mostrará no escenario e outro que será utilizado por persoas reais. En seis meses tivemos que converter o bruto prototipo en algo apto para un piloto. E entón entendemos o que significa "dor".
Para que o noso sistema sexa descentralizado e aberto, decidimos usar contratos intelixentes de Ethereum. A elección recaeu nesta plataforma de servizos en liña descentralizados pola súa popularidade e a capacidade de construír unha aplicación sen servidor. Planeamos implementar o noso proxecto do seguinte xeito.
Pero, desafortunadamente, un contrato intelixente é un código executado por unha máquina virtual no momento dunha transacción e non pode substituír un servidor completo. Por exemplo, un contrato intelixente non pode realizar accións pendentes ou programadas. No noso proxecto, isto non nos permitiu implantar un servizo de aluguer por minuto, como fan a maioría dos modernos servizos de coche compartido. Polo tanto, cargamos a criptomoneda do usuario despois de completar a transacción sen estar seguros de que tiña diñeiro suficiente. Este enfoque só é aceptable para un piloto interno e, por suposto, engade problemas ao deseñar un proxecto de produción completo.
A todo o anterior súmase a humidade da propia plataforma. Por exemplo, se escribes un contrato intelixente cunha lóxica diferente dos tokens ERC-20, atoparás problemas de manexo de erros. Normalmente, se a entrada é incorrecta ou os nosos métodos non funcionan correctamente, recibimos un código de erro como resposta. No caso de Ethereum, non podemos obter outra cousa que a cantidade de gas gastado para realizar esta función. O gas é unha moeda que hai que pagar por transaccións e cálculos: cantas máis operacións teña o teu código, máis pagarás. Entón, para entender por que o código non funciona, primeiro probalo simulando todos os posibles erros e codifica o gas gastado como código de erro. Pero se cambias o teu código, este tratamento de erros romperase.
Ademais, é case imposible crear unha aplicación móbil que funcione coa cadea de bloques de forma honesta, sen utilizar unha chave almacenada nalgún lugar da nube. Aínda que existen carteiras honestas, non proporcionan interfaces para asinar transaccións externas. Isto significa que non verá unha aplicación nativa a non ser que teña unha carteira criptográfica integrada, na que os usuarios terán pouca confianza (non confiaría nela). Como resultado, tamén tivemos que cortar unha esquina aquí. Os contratos intelixentes entregáronse á rede privada de Ethereum e a carteira estaba baseada na nube. Pero a pesar diso, os nosos usuarios experimentaron todas as "delicias" dos servizos descentralizados en forma de longas esperas de transaccións varias veces por sesión de aluguer.
Todo isto lévanos a esta arquitectura. De acordo, é moi diferente do que planeabamos.
Ace in the hole: Identidade autosoberana
Non se pode construír un sistema completamente descentralizado sen unha identidade descentralizada. A identidade autosoberana (SSI) é a responsable desta parte, cuxa esencia é que tiras ao provedor de identidade centralizado (IDP) e distribúes todos os datos e a responsabilidade por iso entre as persoas. Agora o usuario decide que datos necesita e con quen os compartirá. Toda esta información atópase no dispositivo do usuario. Pero para o intercambio necesitaremos un sistema descentralizado para almacenar probas criptográficas. Todas as implementacións modernas do concepto SSI usan blockchain como almacenamento.
"Que ten que ver isto co as no burato?" -preguntas. Lanzamos o servizo de probas internas dos nosos propios empregados en Berlín e Bonn, e atopamos dificultades en forma de sindicatos alemáns. En Alemaña, as empresas teñen prohibido controlar os movementos dos empregados, e os sindicatos controlan isto. Estas restricións poñen fin ao almacenamento centralizado dos datos de identidade dos usuarios, xa que neste caso coñeceriamos a localización dos empregados. Ao mesmo tempo, non puidemos evitar revisalas pola posibilidade de que nos roubaran patinetes. Pero grazas á Self-Sovereign Identity, os nosos usuarios utilizaron o sistema de forma anónima e o propio scooter comprobou o seu carné de conducir antes de iniciar o aluguer. Como resultado, almacenamos métricas de usuarios anónimas; non tiñamos ningún documento nin datos persoais: todos estaban contidos nos dispositivos dos propios controladores. Así, grazas a SSI, a solución ao problema do noso proxecto estaba lista antes de que aparecese.
O dispositivo deume problemas
Non implementamos nós mesmos a identidade autosoberana, xa que require experiencia en criptografía e moito tempo. Pola contra, aproveitamos o produto dos nosos socios Jolocom e integramos a súa carteira móbil e os seus servizos na nosa plataforma. Desafortunadamente, este produto ten un inconveniente importante: a principal linguaxe de desenvolvemento é Node.js.
Esta pila de tecnoloxía limita moito a nosa elección de hardware integrado nun scooter. Afortunadamente, ao comezo do proxecto, escollemos o Raspberry Pi Zero e aproveitamos todas as vantaxes dun microordenador completo. Isto permitiunos executar Node.js voluminoso no scooter. Ademais, recibimos seguimento e acceso remoto a través de VPN usando ferramentas preparadas.
En conclusión
A pesar de toda a "dor" e os problemas, o proxecto púxose en marcha. Non todo funcionou como tiñamos previsto, pero era realmente posible montar scooters alugándoos.
Si, cometemos unha serie de erros ao deseñar a arquitectura que non nos permitiron descentralizar o servizo por completo, pero aínda sen estes erros dificilmente sería posible crear unha plataforma sen servidor. Unha cousa é escribir outra cripto-pirámide e outra moi distinta é escribir un servizo completo no que necesites xestionar erros, resolver casos límite e realizar tarefas pendentes. Agardemos que as novas plataformas xurdidas recentemente sexan máis flexibles e funcionais.
Fonte: www.habr.com