Get best of the week

Desarrolle software para el alquiler descentralizado de scooters. ¿Quién dijo que sería fácil?

En este artículo hablaré sobre cómo tratamos de construir un alquiler de scooter descentralizado con contratos inteligentes y por qué todavía necesitábamos un servicio centralizado.



Cómo todo empezó


En noviembre de 2018, participamos en un hackathon dedicado a Internet de las cosas y blockchain. Nuestro equipo eligió compartir scooter como una idea, ya que teníamos un scooter del patrocinador de este hackathon. El prototipo parecía una aplicación móvil que le permite ejecutar un scooter a través de NFC. Desde el punto de vista del marketing, la idea se vio reforzada por una historia sobre un "futuro brillante" con un ecosistema abierto donde todos pueden convertirse en inquilinos o propietarios, todo basado en contratos inteligentes.

A nuestros grupos de interés les gustó mucho esta idea, y decidieron convertirla en un prototipo para la demostración en exposiciones. Después de varios shows exitosos en Mobile World Congress y Bosch Connected World en 2019, se decidió probar el alquiler de scooters en usuarios reales, empleados de Deutsche Telekom. Así que comenzamos a desarrollar un MVP completo.

Blockchain de muletas


Creo que no vale la pena explicar cuál es la diferencia entre un proyecto para mostrar en el escenario y el que usarán personas reales. Durante seis meses tuvimos que convertir el prototipo crudo en algo adecuado para el piloto. Y luego nos dimos cuenta de lo que significa "dolor".

Para que nuestro sistema sea descentralizado y abierto, decidimos usar contratos inteligentes de Ethereum. La elección recayó en esta plataforma de servicios en línea descentralizados debido a su popularidad y la capacidad de construir una aplicación sin servidor. Planeamos implementar nuestro proyecto de la siguiente manera.



Pero, desafortunadamente, un contrato inteligente es un código ejecutado por una máquina virtual en el momento de una transacción, y no puede reemplazar a un servidor completo. Por ejemplo, un contrato inteligente no puede realizar actividades pendientes o programadas. En nuestro proyecto, esto no nos permitió implementar el servicio de alquiler por minuto, como lo hace la mayoría de los autos compartidos modernos. Por lo tanto, dedujimos la criptomoneda del usuario después de que se completó la operación sin la certeza de que tiene suficiente dinero. Este enfoque es aceptable solo para el piloto interno y, por supuesto, se suma a los problemas al diseñar un proyecto de producción completo.

A todo lo anterior, se agrega la humedad de la plataforma en sí. Por ejemplo, escribir un contrato inteligente con una lógica distinta a los tokens ERC-20 conducirá a un problema de manejo de errores. Por lo general, con una entrada incorrecta o una operación incorrecta de nuestros métodos, obtenemos un código de error en respuesta. En el caso de Ethereum, no podemos obtener nada más que la cantidad de gas gastado para realizar esta función. El gas es la moneda que necesita para pagar las transacciones y los cálculos: cuantas más transacciones haya en su código, más pagará. Por lo tanto, para comprender por qué el código no funciona, primero lo prueba, simula todos los posibles errores y codifica el gas gastado como un código de error. Pero si cambia su código, este manejo de errores se romperá.

Además, es casi imposible crear una aplicación móvil que funcione con blockchain honestamente, sin usar una clave almacenada en algún lugar de la nube. Aunque existen billeteras honestas, no proporcionan interfaces para firmar transacciones externas. Esto significa que no podrá ver la aplicación nativa si no tiene una billetera criptográfica incorporada, en la cual los usuarios tendrán poca confianza (no confiaría). Como resultado, aquí también tuvimos que cortar una esquina. Se entregaron contratos inteligentes a la red privada de Ethereum, y la billetera estaba turbia. Pero a pesar de esto, nuestros usuarios sintieron todos los "encantos" de los servicios descentralizados en la forma de una larga espera para las transacciones varias veces por sesión de alquiler.

Todo esto nos lleva a esta arquitectura. De acuerdo, es muy diferente de lo que planeamos.



As bajo la manga: identidad auto soberana


No se puede construir un sistema totalmente descentralizado sin identificación descentralizada. La identidad auto soberana (SSI) es responsable de esta parte, cuya esencia es que usted descarta un proveedor de identidad centralizado (IDP) y distribuye a las personas todos los datos y la responsabilidad de ellos. Ahora el usuario decide qué datos necesita y con quién los compartirá. Toda esta información está en el dispositivo del usuario. Pero para compartir, necesitamos un sistema descentralizado de almacenamiento de evidencia criptográfica. Todas las implementaciones modernas del concepto SSI usan blockchain como almacenamiento.

"¿Qué tiene el as bajo la manga?" - usted pregunta. Lanzamos el servicio para una prueba interna en nuestros propios empleados en Berlín y Bonn, y enfrentamos dificultades frente a los sindicatos alemanes. En Alemania, las compañías tienen prohibido monitorear los movimientos de los empleados, y los sindicatos controlan esto. Estas restricciones ponen fin al almacenamiento centralizado de datos de identidad del usuario, ya que en este caso hubiéramos sabido la ubicación de los empleados. Al mismo tiempo, no pudimos verificarlos debido a la posibilidad de secuestrar scooters. Pero gracias a Self-Sovereign Identity, nuestros usuarios utilizaron el sistema de forma anónima, y ​​el propio scooter verificó la disponibilidad de una licencia de conducir antes de comenzar el alquiler. Como resultado, mantuvimos métricas anónimas de los usuarios, no teníamos ningún documento o datos personales: todos estaban almacenados en los dispositivos de los propios controladores.Por lo tanto, gracias a SSI, la solución al problema en nuestro proyecto estaba lista incluso antes de que apareciera.

El dispositivo arrojó problemas


No implementamos la identidad auto soberana por nuestra cuenta, ya que esto requiere experiencia en criptografía y mucho tiempo. En cambio, aprovechamos el producto de nuestros socios Jolocom e integramos su billetera móvil y servicios en nuestra plataforma. Desafortunadamente, este producto tiene un inconveniente importante: el lenguaje de desarrollo principal es Node.js.

Tal pila tecnológica nos limita mucho en la elección del hierro integrado en un scooter. Afortunadamente, al comienzo del proyecto, nuestra elección recayó en el Raspberry Pi Zero, y aprovechamos el microordenador completo. Esto nos permitió ejecutar el voluminoso Node.js en un scooter. Además, obtuvimos monitoreo y acceso remoto a través de VPN usando herramientas listas para usar.

Finalmente


A pesar de todo el "dolor" y los problemas, se lanzó el proyecto. No todo funcionó como lo planeamos, pero era realmente posible conducir scooters alquilándolos.

Sí, cometimos una serie de errores en el diseño de la arquitectura, lo que no nos permitió hacer que el servicio fuera completamente descentralizado, pero incluso sin estos errores difícilmente hubiéramos podido crear una plataforma sin servidor. Una cosa es escribir otra pirámide criptográfica y otra muy distinta es un servicio completo en el que necesita manejar errores, resolver casos límite y realizar tareas pendientes. Esperemos que las nuevas plataformas aparecidas recientemente sean más flexibles y funcionales.

More articles:


All Articles