El Hackathon de IOTA tuvo lugar del 17 al 19 de noviembre en Gdansk, Polonia. Los desarrolladores de software de toda Europa se reunieron para poner a prueba la Plataforma IOTA con varios casos de uso. El evento fue patrocinado por IOTA, Baltic Data Science (blockchain y big data service), Datarella (blockchain y big data consultancy) y Bright Inventions (desarrollo de aplicaciones móviles). Cuatro equipos de desarrolladores y expertos en software se formaron alrededor de varios casos de uso y compitieron por 4.200 IOTA en premios.
Este artículo describe las lecciones aprendidas por el equipo de «Freedom Pass», que entrenó Kira Nezu de Datarella. El equipo se ubicó segundo en la competencia.
- La tareaAl equipo se unió Bogdan Vacusta, que trajo un desafío de la vida real del Consejo de Londres al Hackathon de IOTA. Los Consejos de Londres emiten «Pases de Libertad» para los residentes discapacitados que les permiten usar el transporte público dentro de la ciudad de forma gratuita. Antes de la emisión de un Freedom Pass, se debe obtener un certificado médico para demostrar la discapacidad.
Desafortunadamente, los estafadores han sido exitosos obteniendo certificados de médicos para residentes saludables de Londres. Nadie sabe a ciencia cierta cuántos Freedom Passes se han emitido bajo falsas pretensiones, pero es probable que la cifra sea de miles. Los Consejos de Londres no tienen procedimientos para verificar si un certificado ha sido falsificado. Una simple alerta, cuando un médico ha emitido un número inusualmente alto de certificados sería un gran paso para detectar fraudes con éxito. Este paso solo podría ahorrar al público decenas de millones de libras por año con la ayuda de IOTA.
La tarea del equipo era construir una Prueba de concepto (PoC) para prevenir el fraude. Entonces, ¿cómo se puede utilizar IOTA para la detección de fraude? - La solución
El equipo decidió crear una transacción del médico al solicitante, certificando así la discapacidad del solicitante en el la Tangle de IOTA. Si se produce una anomalía en el número de certificados emitidos por un médico, el sistema alerta a los Consejos de Londres.En un escenario ideal, el médico emitiría esta certificación digital desde una aplicación (móvil o basada en la web), firmando la transacción con su clave privada (esta medida realmente ayudaría a prevenir el fraude). Dado el corto espacio de tiempo en el Hackathon de IOTA (menos de 24 h), el equipo eligió crear datos de muestra y llevar a cabo la transacción en nombre del médico para el PoC. Una base de datos local se alimentaría con los detalles del médico y del solicitante, para identificarlos. Entonces, el sistema para PoC debía incluir los siguientes componentes: - Un formulario de entrada para los datos del médico y el solicitante
- Una interfaz para la Tangle de IOTA
- Una base de datos con datos de médicos y solicitantes
- Un backend que analiza los datos
- Una interfaz para los Consejos de Londres con una lista de alertas
- El procesoAsí es como funciona:1. Ingresando los datos:Los datos del médico y del solicitante se ingresan a través de una interfaz de usuario basada en web (el equipo llenó la base de datos escribiendo un método JavaScript que escribió los datos falsos directamente en la base de datos, por lo que esta UI, aunque funcional, no era necesaria para el PoC. (Puede obtener más información sobre esto en la parte 2 de las lecciones aprendidas):
2. Certificación:Los datos se escriben en la base de datos local. Simultáneamente, una transacción, que simboliza el certificado de discapacidad, del médico al solicitante está escrita inmutablemente en la Tangle de IOTA. La identificación de la transacción, a su vez, se escribe en la base de datos local, lo que agrega la capacidad de probar que la certificación ha tenido lugar.
3. Análisis e Informes:
El backend analiza los datos y alerta a los funcionarios en caso de anomalías. es decir. (Si un médico ha emitido inusualmente muchos certificados dentro de un marco de tiempo determinado).
- Lo que aprendimos
Completamos nuestro objetivo dentro del marco de tiempo a pesar de tener problemas debido al trabajo con un sistema inmaduro en el camino. Al final, logramos crear una Prueba de concepto perfectamente adecuada para el ajuste del Hackathon de IOTA.Nos encontramos con algunos problemas en el camino que deben ser abordados por el equipo de IOTA para mejorar el sistema y hacerlo apto para casos de uso futuros:Velocidad de las transacciones: en el testnet de IOTA experimentamos largos tiempos de espera al confirmar las transacciones. Las transacciones enviadas confirmadas en ~ 1 minuto, la lectura de las transacciones tomó aproximadamente ~ 3-5 minutos o más dependiendo de la cantidad de datos. Este puede ser un problema de testnet independiente del mainnet.La documentación no estaba actualizada, faltaba información y la documentación existente era a veces engañosa (es decir, las propiedades marcadas como opcionales son realmente necesarias, no es obvio que una función de reproducción repetida crea una transacción completamente nueva, enviando un mensaje en lugar de una transacción al remitente) no está documentado en la Tangle…)
Las versiones no se programan con antelación, si se ejecuta una actualización durante el desarrollo, los desarrolladores deben adaptarse rápidamente para adaptarse a los cambios. Una hoja de ruta de IOTA para los lanzamientos sería muy útil.El SDK de Node.js se basa en «devoluciones de llamada» (un estándar de tecnología antiguo), no en «promesas» (estándar de tecnología actual).
La API puede ser mal utilizada fácilmente. Los valores y las propiedades que no deberían pasarse pueden pasar sin ningún mensaje de error. A la API le faltan mensajes de error descriptivos, lo que deja a los desarrolladores a la sombra cuando se trata de detectar errores.
Entonces, ¿por qué IOTA?
De vuelta, uno podría argumentar que esta tarea podría haberse hecho con una base de datos regular por completo. Si bien esto es cierto, una base de datos es mucho más fácil de atacar por piratas informáticos que una cadena de bloques o un enredo. Además, este tipo de sistema podría haberse configurado en un sistema de cadena de bloques a. Ethereum, ¿por qué usar IOTA? Bueno, los desafíos que los sistemas de cadena de bloques están luchando por superar son el rendimiento y la escalabilidad. Debido al tamaño de los bloques, los tiempos de transacción aumentan constantemente, lo que hace que los sistemas sean menos utilizables para los escenarios en los que las transacciones deben ocurrir casi al instante.IOTA ayuda a resolver los problemas de rendimiento y velocidad de las transacciones. El equipo está de acuerdo en que es probable que IOTA Tangle y enfoques similares de cadenas «sin bloque» sean más factibles para permitir la escalabilidad en el futuro. Además, una aplicación que usa IOTA puede transferirse fácilmente a casos de uso relacionados.
Conclusión
¿Recomendaría el equipo usar IOTA para la prevención de fraude?La respuesta es Sí, si el objetivo a largo plazo es desarrollar aún más IOTA en general. La respuesta es No, si el sistema se debe utilizar en un entorno productivo en este punto, ya que todavía es inmaduro. Los sistemas alternativos que actualmente son más maduros y podrían usarse para la tarea incluyen Hyperledger Fabric, Sovrin y Ethereum. Estos sistemas blockchain plantean problemas de escalabilidad en el futuro, mientras que el desarrollo aquí también está en curso.
La aplicación IOTA «Freedom Pass» es muy escalable y transferible a casos de uso relacionados. Sin embargo, IOTA debe llevar a cabo mejoras masivas con respecto al rendimiento a.a. velocidad y documentación, así como para API y SDK / node.js. Si los problemas anteriores se mejoran continuamente, el equipo recomienda a IOTA para desarrollar aún más este tipo de sistema para el público. IOTA promete potencial futuro para el público para la reconciliación de datos, la reducción de la duplicación, auditabilidad, autenticación.
Equipo «Freedom Pass» en el Hackathon de IOTA en Gdansk (de izquierda a derecha): Michał Łukasiewicz, Kira Nezu, Bogdan Vacusta, Jonatan Bergqvist, Victor Naumik, Rafal Hofman, Artem GoncharenkoFuente: http://datarella.com/iota-hackathon-lessons-learned-fraud-detection-part-1/
