En este artículo, hablaré sobre cómo intentamos construir un sistema de alquiler descentralizado de scooters basado en contratos inteligentes y por qué aún necesitábamos un servicio centralizado.
Cómo todo comenzó
En noviembre de 2018, participamos en un hackatón dedicado a Internet de las Cosas y blockchain. Nuestra idea como equipo fue elegir el scooter-sharing, ya que contábamos con un scooter proporcionado por el patrocinador del hackatón. El prototipo parecía una aplicación móvil que permitía poner en marcha el scooter a través de NFC. Desde el punto de vista del marketing, la idea se sustentaba en un relato sobre el 'futuro brillante' con un ecosistema abierto, donde cualquiera pudiera ser arrendatario o arrendador, todo ello basado en contratos inteligentes.
Esta idea gustó mucho a nuestros interesados, y decidieron convertirla en un prototipo para demostrar en ferias. Después de varias presentaciones exitosas en el Mobile World Congress y en Bosch Connected World en 2019, se tomó la decisión de probar el alquiler de scooters con usuarios reales, empleados de Deutsche Telekom. Así comenzamos el desarrollo de un MVP completo.
Blockchain con muletas
Creo que no es necesario explicar la diferencia entre un proyecto para mostrar en el escenario y uno que será utilizado por personas reales. En seis meses teníamos que transformar un prototipo crudo en algo adecuado para un piloto. Y aquí nos dimos cuenta de lo que significa el 'dolor'.
Para hacer nuestro sistema descentralizado y abierto, decidimos utilizar contratos inteligentes de Ethereum. Elegimos esta plataforma de servicios online descentralizados debido a su popularidad y la posibilidad de construir una aplicación sin servidor. Planeamos implementar nuestro proyecto de la siguiente manera.
Pero, desafortunadamente, un contrato inteligente es un código que se ejecuta en una máquina virtual en el momento de la transacción, y no puede reemplazar un completo servidor. Por ejemplo, un contrato inteligente no puede ejecutar acciones retrasadas o programadas. En nuestro proyecto, esto no permitió implementar un servicio de alquiler por minutos, como lo hacen la mayoría de los servicios de car-sharing modernos. Por lo tanto, descontábamos criptomonedas del usuario después de finalizar la operación, sin la certeza de que tuviera suficientes fondos. Este enfoque es aceptable solo para un piloto interno y, sin duda, agrega problemas a la hora de diseñar un proyecto completo para producción.
A todo lo anterior se suma la humedad de la propia plataforma. Por ejemplo, al escribir un contrato inteligente con una lógica diferente a la de los tokens ERC-20, te enfrentarás al problema de la gestión de errores. Normalmente, con una entrada incorrecta o un mal funcionamiento de nuestros métodos, recibimos un código de error como respuesta. En el caso de Ethereum, no podemos obtener nada más que la cantidad de gas gastada en la ejecución de esta función. El gas es la moneda que se debe pagar por transacciones y cálculos: cuanto más operaciones hay en tu código, más pagarás. Por lo tanto, para entender por qué el código no funciona, primero lo pruebas simulando todos los errores posibles, y codificas el gas gastado como el código de error. Pero si cambias tu código, este manejo de errores se romperá.
Además de esto, prácticamente es imposible crear una aplicación móvil que funcione con blockchain de manera justa, sin utilizar una clave almacenada en algún lugar en la nube. Aunque existen billeteras honestas, no proporcionan interfaces para firmar transacciones externas. Esto significa que no verás una aplicación nativa a menos que incluya una billetera criptográfica, en la que los usuarios tendrán poca confianza (yo no confiaría). Como resultado, aquí también tuvimos que tomar atajos. Los contratos inteligentes se entregaban en la red privada de Ethereum, y la billetera era en la nube. Pero a pesar de esto, nuestros usuarios experimentaron todas las “delicias" de los servicios descentralizados, con largas esperas en transacciones varias veces durante la sesión de alquiler.
Todo esto nos lleva a esta arquitectura. coincides en que es muy diferente de lo que planeamos.
As bajo la manga: Identidad Auto-Soberana
No se puede construir un sistema completamente descentralizado sin una identificación descentralizada. Esta parte está a cargo de la Identidad Auto-Soberana (SSI), cuyo principio es que se elimina al proveedor centralizado de identidad (IDP) y se otorgan a las personas todos los datos y la responsabilidad sobre ellos. Ahora el usuario decide qué datos necesita y con quién los compartirá. Toda esta información se almacena en el dispositivo del usuario. Pero para el intercambio necesitaremos un sistema descentralizado de almacenamiento de pruebas criptográficas. Todas las implementaciones modernas del concepto SSI utilizan blockchain como almacenamiento.
“¿Y qué tiene que ver el as en la manga?” —preguntarán ustedes. Lanzamos el servicio para una prueba interna con nuestros propios empleados en Berlín y Bonn, y nos encontramos con dificultades debido a los sindicatos alemanes. En Alemania, las empresas tienen prohibido seguir los movimientos de los empleados, y los sindicatos supervisan esto. Estas restricciones ponen fin al almacenamiento centralizado de datos de identificación de los usuarios, ya que de ser así, tendríamos conocimiento de la ubicación de los empleados. Al mismo tiempo, no podíamos no verificar los movimientos debido al riesgo de robo de scooters. Pero gracias a la Identidad Auto-Soberana, nuestros usuarios utilizaron el sistema de forma anónima, y el propio scooter verificaba la validez de sus licencias de conducir antes de comenzar el alquiler. Como resultado, teníamos métricas de usuarios anonimadas, y no poseíamos documentos ni datos personales: toda esta información estaba en los dispositivos de los propios conductores. Así, gracias a SSI, la solución al problema en nuestro proyecto estaba lista antes de que surgiera.
El dispositivo presentó problemas
No implementamos la Identidad Auto-Soberana por nuestra cuenta, ya que esto requiere experiencia en criptografía y mucho tiempo. En cambio, utilizamos el producto de nuestros socios Jolocom e integramos su billetera móvil y servicios en nuestra plataforma. Desafortunadamente, este producto tiene una desventaja considerable: el principal lenguaje de desarrollo es Node.js.
Este stack tecnológico nos limita mucho en la elección del hardware integrado en el scooter. Afortunadamente, desde el principio del proyecto elegimos Raspberry Pi Zero y aprovechamos todas las ventajas de un microordenador completo. Esto nos permitió ejecutar Node.js en el scooter. Además, obtuvimos monitoreo y acceso remoto a través de vpn, utilizando herramientas preexistentes.
En conclusión
A pesar de todos los problemas y dificultades, el proyecto fue lanzado. No todo funcionó como habíamos planeado, pero realmente se podía montar en los scooters alquilados.
Sí, cometimos una serie de errores en el diseño de la arquitectura que nos impidieron hacer el servicio completamente descentralizado, pero incluso sin esos errores, difícilmente habríamos podido crear una plataforma sin servidor. Una cosa es escribir otra pirámide de criptomonedas y otra muy distinta es construir un servicio completo que maneje errores, resuelva casos límite y ejecute tareas diferidas. Esperemos que las nuevas plataformas que han surgido recientemente sean más flexibles y funcionales.
Fuente: habr.com
