Esta es la segunda entrega en nuestras publicaciones sobre las experiencias del equipo «Freedom Pass» durante el Hackathon de IOTA. En la primera publicación (que se encuentra aquí), Kira preparó el escenario y explicó los problemas actuales del London Freedom Pass. En esta publicación, vamos a ser un poco más detallados con respecto a cómo construimos el proyecto.
DESCARGO DE RESPONSABILIDAD: Aunque el proyecto se llama «Detección de fraude», el enfoque tecnológico está muy centrado en IOTA y no en las metodologías de aprendizaje automático o en la ciencia de datos, como comúnmente se asociaría con la detección y prevención del fraude.
Después de que redujimos el alcance lo suficiente como para que pudiéramos lograrlo durante un hackathon, comenzamos a familiarizarnos con la Tangle de IOTA. Seguimos este tutorial (http://balticdatascience.com/2017/11/01/iota-hello-world/) para hacer una transacción simple, escrita solo unas semanas antes pero ya con algunas modificaciones requeridas. Después de habernos familiarizado con los conceptos generales de Tangle (acelerados en gran medida por una presentación y preguntas y respuestas de Chris Dukakis de IOTA), nos conectamos a un nodo testnet y comenzamos a emitir transacciones.
Antes de entrar en los detalles del proyecto, haré un breve comentario sobre la decisión de ejecutar un nodo completo, la Implementación de Referencia de IOTA (IRI) o conectarse a nodos preexistentes. En resumen, para ejecutar el IRI, se necesita un entorno de ejecución de Java completo, que es una de las razones por las que IOTA no se puede ejecutar en un dispositivo de IoT en este momento. Cada nodo conectado a la Tangle expone una API HTTP a través de la cual se pueden emitir transacciones. Para configurar una instancia del IRI, uno tiene que adquirir las direcciones de los nodos ya conectados en la Tangle. La forma recomendada de hacerlo es preguntando a las personas en el canal slack #nodesharing. Debido a las restricciones anteriores y nuestros requisitos a tiempo, no pensamos que sería necesario ejecutar nuestro propio nodo.
Volver a la tarea de resolver el problema del fraude en el proceso de solicitud del Freedom Pass en los distritos de Londres. Nos conformamos con la biblioteca de JavaScript, ya que hace mucho trabajo pesado en la parte superior de la API y es, con mucho, la biblioteca mejor documentada. (El equipo ganador usó la biblioteca de Python en su mayor parte indocumentada y aún así logró interactuar bastante bien con la Tangle). El iota.lib.js implementa tanto la API estándar, como algunas funcionalidades útiles como la firma, la conversión de unidades y la lectura de la Tangle. En nuestro proyecto, nos habíamos propuesto proporcionar las siguientes interacciones entre la Tangle y nuestros usuarios:
- Registrar una semilla de Doctor en la Tangle.
- Registre al solicitante como una semilla en la Tangle.
- Realice una transacción para cada certificado entre el Doctor emisor y el Solicitante.
- Verificar que un certificado fue registrado en la Tangle entre un Doctor y un Solicitante.
- Lea la información de la Tangle sobre las transacciones salientes de todos los médicos.Dada la funcionalidad anterior, ¿cómo podríamos aprovechar la biblioteca IOTA existente de la mejor manera posible? Bueno, dado que los contratos inteligentes o la mayoría de los tipos de transacciones avanzadas no son realmente posibles en IOTA (todavía), necesitaremos algo de procesamiento, almacenamiento y UI fuera de la Tangle.
Para esto, implementamos un back-end y algunos paquetes para procesar la información de las aplicaciones. El lado del servidor fue escrito usando Node.JS y el marco expreso. Para modelar la lógica y la estructura de la base de datos, usamos MongoDB y moongose. El MongoDB contenía un simple almacén de clave-valor, guardando la información relevante del solicitante. Uno podría imaginar que se podría actualizar a un modelo de gráfico para reflejar mejor la estructura de la Tangle y para poder analizar de manera más eficiente las conexiones entre médicos y solicitantes, sin embargo, eso estuvo fuera de alcance durante las ~ 24 horas de codificación que teníamos.
Para que el usuario pueda interactuar fácilmente con la Tangle, creamos una pequeña interfaz web. Permite al usuario ingresar información sobre una aplicación, como el número de seguro nacional de un Solicitante, el código postal del Médico y del Solicitante, los números de teléfono, etc. En esta etapa, deben ocurrir cuatro cosas:
- La información se guarda en la colección MongoDB.
- Las semillas para el Solicitante y el Doctor se crean en base a un agregado de información de identificación.
- Se generan nuevos tokens de prueba y se envían a la cuenta del Doctor.
- Se emite una transacción IOTA del Doctor al Solicitante.
Para guardar la información en una colección MongoDB, un controlador crea una instancia y devuelve un nuevo modelo que contiene los datos recién ingresados. Lo pasa al servidor.js que maneja las solicitudes HTTP del cliente.
No existe una API de IOTA dedicada para generar semillas, pero proporcionan un comando de línea de comando para generar una semilla aleatoria. Hicimos nuestras semillas relacionables con la información privada mediante la concatenación de la clave privada con el número de seguro nacional para los solicitantes y la identificación del médico para los médicos. Después de generar la semilla, se crea una nueva dirección para cada nueva transacción.
Para que las funciones de iota.lib.js sean un poco más utilizables, incluimos la estructura existente de callbacks en Promises. Esto permitió que nuestro código se vuelva un poco más asíncrono de lo que es, out-of-the-box ‘.
Aquí hay una descripción general de la arquitectura:
Una vez que se emitieron los datos y las transacciones, el siguiente paso fue proporcionar una forma de ver las aplicaciones y certificados existentes. Así que creamos una segunda página de la IU para listar todas las aplicaciones con información relevante leída de la colección MongoDB.
Sin embargo, esto no brinda una excelente manera de encontrar el tipo principal de fraude que estábamos considerando, es decir, los solicitantes que reutilizan información sobre los médicos. Esto hace que parezca que un solo médico emitió una cantidad irrazonable de certificados. Un caso bastante fácil de atrapar, uno podría pensar, pero considerando que es un proceso completamente analógico hecho en papel en diferentes distritos por diferentes administradores, se resume en una cantidad bastante grande de aplicaciones falsificadas. Este es el tipo de fraude en el que nos enfocamos en nuestro procesamiento.
Entonces, ¿cómo podemos, de una manera fácil de usar, señalar los casos que deberían investigarse? Elegimos la opción más simple y creamos una segunda vista de la IU en la que se incluye a cada Doctor en el sistema junto con la cantidad de certificados que supuestamente emitieron. La lista está ordenada por el número de certificados emitidos. Aquí uno podría imaginar hacerlo un poco más inteligente al incluir la fecha en que se emitió el certificado y crear una métrica más diferenciada de certificados por unidad de tiempo, pero esta vez no estaba dentro del alcance. Si un médico emitió más de 10 certificados, se destacaron en rojo. Una forma muy simple pero potencialmente eficiente de comunicarle al usuario que algo necesita ser investigado. Por supuesto, el número 10 era completamente arbitrario y podría haber sido elegido de manera diferente. De hecho, para decidir ese número, uno debería, primero que nada, analizar datos históricos.
En resumen, Team Freedom se divirtió mucho y aprendió muchísimo sobre IOTA, la ideación, la cooperación y la creación en un corto período de tiempo. Logramos crear una Prueba de concepto que funcione para saber cómo se puede usar IOTA para la emisión segura de certificados médicos a fin de prevenir y detectar fraudes. La aplicación del Freedom Pass se realizó para que fuera más fácil comprender lo que se estaba haciendo y por qué. Pero eso de ninguna manera significa que la estructura base no se puede usar para otros fines, de hecho, se escribió específicamente para ser lo suficientemente general como para que también sea interesante en otras áreas.
¿Es esta la única forma en que el problema podría haberse resuelto? No. ¿Era la forma más fácil de resolverlo? Absolutamente no. Sin embargo, creemos que solo mediante la experimentación y la utilización de una de las pocas soluciones de contabilidad distribuida escalables y resistentes al futuro podemos lograr aplicabilidad. En general, casi no hay una aplicación de contabilidad distribuida que no podría haberse realizado sin el uso de un libro mayor distribuido, pero habría incurrido en grandes costos financieros, organizacionales o de confianza. IOTA es una solución muy rentable y escalable, pero con la advertencia de que todavía está en pañales.
Fuente: http://datarella.com/iota-hackathon-lessons-learned-fraud-detection-part-2/
