En este artículo hablaré sobre cómo intentamos construir un alquiler de scooters descentralizado sobre contratos inteligentes y por qué todavía necesitábamos un servicio centralizado.
¿Cómo empezó todo
En noviembre de 2018 participamos en un hackathon dedicado al Internet de las cosas y blockchain. Nuestro equipo eligió compartir scooter como idea ya que teníamos un scooter del patrocinador de este hackathon. El prototipo parecía una aplicación móvil que permite arrancar un scooter mediante NFC. Desde el punto de vista del marketing, la idea estaba respaldada por una historia sobre un “futuro brillante” con un ecosistema abierto donde cualquiera puede convertirse en inquilino o propietario, todo ello basado en contratos inteligentes.
A nuestros stakeholders les gustó mucho esta idea y decidieron convertirla en un prototipo para exhibir en exposiciones. Después de varias demostraciones exitosas en el Mobile World Congress y Bosch Connected World en 2019, se decidió probar el alquiler de scooters con usuarios reales, empleados de Deutsche Telekom. Entonces comenzamos a desarrollar un MVP completo.
Blockchain con muletas
No creo que valga la pena explicar cuál es la diferencia entre un proyecto que se mostrará en el escenario y uno que será utilizado por personas reales. En seis meses tuvimos que convertir el tosco prototipo en algo adecuado para un piloto. Y entonces entendimos lo que significa "dolor".
Para que nuestro sistema sea descentralizado y abierto, decidimos utilizar 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 crear 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 acciones pendientes o programadas. En nuestro proyecto, esto no nos permitió implementar un servicio de alquiler por minuto, como lo hacen la mayoría de los servicios modernos de uso compartido de automóviles. Por lo tanto, debitamos criptomonedas del usuario después de completar la transacción sin estar seguros de que tuviera suficiente dinero. Este enfoque sólo es aceptable para un piloto interno y, por supuesto, añade problemas al diseñar un proyecto de producción completo.
A todo lo anterior se suma la humedad de la propia plataforma. Por ejemplo, si escribe un contrato inteligente con una lógica diferente a la de los tokens ERC-20, encontrará problemas de manejo de errores. Normalmente, si la entrada es incorrecta o nuestros métodos no funcionan correctamente, recibimos un código de error como 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 una moneda que se debe pagar para transacciones y cálculos: cuantas más operaciones haya en tu código, más pagarás. Entonces, para comprender por qué el código no funciona, primero debe probarlo simulando todos los errores posibles y codificar el gas gastado como un código de error. Pero si cambia su código, este manejo de errores se interrumpirá.
Además, es casi imposible crear una aplicación móvil que funcione honestamente con blockchain sin utilizar 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 verá una aplicación nativa a menos que tenga una billetera criptográfica incorporada, en la que los usuarios tendrán poca confianza (yo no confiaría en ella). Como resultado, también tuvimos que tomar atajos aquí. Los contratos inteligentes se entregaron a la red privada Ethereum y la billetera estaba basada en la nube. Pero a pesar de esto, nuestros usuarios experimentaron todos los "placeres" de los servicios descentralizados en forma de largas esperas para realizar 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 en la manga: Identidad autosoberana
No se puede construir un sistema completamente descentralizado sin una identidad descentralizada. La identidad autosoberana (SSI) es responsable de esta parte, cuya esencia es que usted descarta el proveedor de identidad centralizado (IDP) y distribuye todos los datos y la responsabilidad del mismo a las personas. Ahora el usuario decide qué datos necesita y con quién los compartirá. Toda esta información se encuentra ubicada en el dispositivo del usuario. Pero para el intercambio necesitaremos un sistema descentralizado para almacenar evidencia criptográfica. Todas las implementaciones modernas del concepto SSI utilizan blockchain como almacenamiento.
“¿Qué tiene esto que ver con el as en la manga?” - usted pregunta. Lanzamos el servicio de pruebas internas para nuestros propios empleados en Berlín y Bonn y nos topamos con dificultades en los sindicatos alemanes. En Alemania, las empresas tienen prohibido controlar los movimientos de los empleados y los sindicatos lo controlan. Estas restricciones ponen fin al almacenamiento centralizado de datos de identidad de los usuarios, ya que en este caso conoceríamos la ubicación de los empleados. Al mismo tiempo, no pudimos evitar revisarlos por la posibilidad de que nos robaran los scooters. Pero gracias a Self-Sovereign Identity, nuestros usuarios utilizaron el sistema de forma anónima y el propio scooter verificó su licencia de conducir antes de iniciar el alquiler. Como resultado, almacenamos métricas de usuario anónimas; no teníamos ningún documento ni datos personales: todos estaban contenidos en los dispositivos de los propios conductores. Así, gracias a SSI, la solución al problema de nuestro proyecto estuvo lista incluso antes de que apareciera.
El dispositivo me dio problemas.
No implementamos la identidad auto soberana nosotros mismos, ya que requiere experiencia en criptografía y mucho tiempo. En cambio, aprovechamos el producto de nuestros socios Jolocom e integramos su billetera móvil y sus servicios en nuestra plataforma. Desafortunadamente, este producto tiene un inconveniente importante: el principal lenguaje de desarrollo es Node.js.
Esta pila de tecnología limita en gran medida nuestra elección de hardware integrado en un scooter. Afortunadamente, al comienzo del proyecto elegimos Raspberry Pi Zero y aprovechamos todas las ventajas de una microcomputadora completa. Esto nos permitió ejecutar Node.js voluminosos en el scooter. Además, recibimos monitoreo y acceso remoto a través de VPN utilizando herramientas listas para usar.
en conclusión
A pesar de todo el “dolor” y los problemas, el proyecto se puso en marcha. No todo salió como habíamos planeado, pero realmente era posible montar en scooter alquilándolos.
Sí, cometimos una serie de errores al diseñar la arquitectura que no nos permitieron descentralizar completamente el servicio, pero incluso sin estos errores difícilmente hubiéramos podido crear una plataforma sin servidor. Una cosa es escribir otra criptopirámide y otra muy distinta es escribir un servicio completo en el que sea necesario manejar errores, resolver casos límite y realizar tareas pendientes. Esperemos que las nuevas plataformas que han surgido recientemente sean más flexibles y funcionales.
Fuente: habr.com