Computación Evolutiva Descentralizada de Modelo Híbrido usando Blockchain y Prueba de Trabajo de Optimización Harvey D. Bastidas C. 1
Tabla de Contenido Introducción Marco Teórico Computación Evolutiva Distribuida Redes Descentralizadas Blockchain Trabajos Previos Prueba de Trabajo Criptográfica Pruebas de Trabajo Útil Propuesta : Prueba de Trabajo de Optimización Plataforma de Software Experimentos de Validación Trabajo Futuro y Conclusiones 2
Introducción Que propone el proyecto? Realizar trazabilidad de un proceso de optimización con algoritmos evolutivos en una arquitectura descentralizada. Se propone una nueva prueba de trabajo útil basada en optimización con Algoritmos Evolutivos (EA). Se usa un incremento en desempeño en una optimización con EA en lugar del desafío criptográfico usado por Bitcoin. 3
Marco Teórico Computación Evolutiva Computación Evolutiva Distribuida Redes Descentralizadas Blockchain 4
Computación Evolutiva Optimización con algoritmos evolutivos Computación Evolutiva (EC): Técnicas para buscar parámetros óptimos de modelos matemáticos. Algoritmos Evolutivos (EA): Inspirados en la evolución biológica, usan reproducción, mutación y cruce en cada iteración. Los parámetros se representan como genes (ej: Sinapsis de una red neuronal). El conjunto de genes constituyen un genoma (ej: Neuronas y sinapsis en red neuronal). El estado de optimización es una población de genomas (ej: Conjunto de redes neuronales) El estado cambia en cada iteración del EA. 5 Ejemplos de gen, genoma y población
Computación Evolutiva Distribuída Escalabilidad de Algoritmos evolutivos Los EA permiten procesamiento distribuido (dea) El modelo de Islas y modelos híbridos permiten optimización en arquitectura descentralizada. En el modelo de islas, se migran los mejores especímenes entre optimizadores. En una red descentralizada, la configuración de tiempo puede ser diferente en cada nodo. Patron Arquitectural Descentralizado o P2P. Un dea en una arquitectura descentralizada no podría tener trazabilidad por el problema del tiempo (número variable de saltos). 6
Redes Descentralizadas Que son y que ventajas tienen? En redes centralizadas, los clientes consume servicios de servidores. En redes descentralizadas, los clientes consumen servicios de cualquier nodo. Comunicación entre nodos por flooding controlado (TTL y/o Sequence Number Controlled Flooding). Proveen tolerancia a fallas y escalabilidad. Los relojes de los nodos pueden no estar sincronizados. Es difícil establecer el orden de eventos (trazabilidad) ya que el número de saltos es variable. Para esto se propone el uso de un blockchain. 7
Blockchain Trazabilidad en redes descentralizadas Bitcoin es una red descentralizada para transacciones financieras donde ocurre el problema de double spending. El Blockchain y la prueba de trabajo implementan un un servicio de timestamping (marca de tiempo) distribuido. Se establece un consenso en el orden de las transacciones almacenadas. Las transacciones se almacenan en bloques enlazados criptográficamente. El blockchain provee trazabilidad de las transacciones, el orden en el que se ejecutan y los saldos en las cuentas (direcciones de Bitcoin) En caso de fragmentación se usa la cadena mas larga. 8 Fuente: Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto, 2008
Trabajos Previos Prueba de Trabajo Criptográfica Pruebas de Trabajo Útil 9
Prueba de Trabajo Criptográfica Control de tiempo de bloque Fuente: Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto, 2008 La generación de una prueba de trabajo (PoW) se basa en resolver un desafío de dificultad variable para controlar el tiempo de bloque. El desafío es encontrar un hash (SHA-256) que tenga un número de ceros al inicio, de un bloque que incluye un contador (nonce), la dificultad es el número de ceros. La dificultad del desafío sirve para controlar el tiempo que se tarda en encontrar una nueva PoW. Los nodos aceptan por consenso el orden de las transacciones de un bloque con una PoW válida, solucionando el problema del double spending. La generación de una PoW tiene un consumo eléctrico gastado en un cálculo inútil. 10
Pruebas de Trabajo Útil (upow) Control de tiempo de bloque con trabajo útil Deben ser fáciles de validar, pero difíciles de producir, así controlan el tiempo de bloque y pueden ser validadas con bajo costo computacional. Existen varios problemas que pueden ser usados para producir una prueba de trabajo útil, como vectores ortogonales, 3SUM y problemas que se reducen a ellos. Las upow encontradas no son función del contenido de los bloques y no protegen al blockchain contra reuso. Mitigar el problema del reuso, las upow son un hash de un bloque que contenga una solución válida. Algunas de las pruebas de trabajo usan un conjunto de problemas y datos (problem board), generando un bloque con la solución de uno de ellos. 11 Fuente: Proofs of Useful Work, Marshall Ball et al., 2017
Propuesta Prueba de Trabajo Útil usando Optimización con dec 12
Contexto Porque es importante la descentralización y trazabilidad? Modelo de islas o modelos híbridos para computación evolutiva (dec) distribuida. Servicio de timestamping distribuido usando blockchain. Las redes descentralizadas tienen la ventaja de la escalabilidad y tolerancia a fallos. La trazabilidad permite hacer depuración de la implementación de un algoritmo evolutivo en una red descentralizada. Permite establecer el orden de las acciones de los dispositivos que participan en optimización descentralizada (ej: eventos de seguridad o creación de nuevos usuarios). Permite, usar los registros de eventos, para cobrar por servicios prestados y consumidos por los dispositivos participantes. 13
Prueba de Trabajo de Optimización (OPoW) Control de tiempo de bloque con trabajo de optimización Fuente: Proofs of Useful Work, Marshall Ball et al., 2017 La OPoW usa como desafío, alcanzar un incremento en el desempeño en la optimización de un modelo matemático. La OPoW se usa para controlar el tiempo de bloque como otros upow. La OPoW es un hash de un bloque que contenga los parámetros de un modelo con un incremento ( performance) en desempeño respecto al anterior bloque. La magnitud de performance determina la dificultad del desafío y sirve para controlar el tiempo que se tarda en encontrar una nueva PoW. Los nodos aceptan por consenso el orden de las transacciones de un bloque con una OPoW válida. El bloque puede contener cualquier información, en la implementación actual es usado para almacenar las solicitudes a los nodos y sus respuestas (event log). 14
Prueba de Trabajo de Optimización Usabilidad y Seguridad Debido a que una solución está en cada bloque, y no es función del él, se podrían re-usar las soluciones encontradas. En OPoW se puede usar adicionalmente un desafío similar al de Bitcoin, lo que permitiría adicionar seguridad contra modificaciones del blockchain. Se puede usar performance y adicionalmente los ceros iniciales del hash del bloque como dificultad dependiendo de la seguridad requerida. La implementación actual solo usa performance, sin protección contra cambios en el blockchain. Como trabajo futuro se puede implementar el número de ceros iniciales como medida de seguridad adicional si una aplicación lo requiere. 15 Fuente: Proofs of Useful Work, Marshall Ball et al., 2017
Plataforma de Sofware Proceso de Diseño Componentes Funcionamiento Caso de Aplicación Uso de la Plataforma 16
Diseño de Plataforma de Software Proceso de Diseño Se diseñó una plataforma para optimización descentralizada con EC. Permite evaluación de datos externos en el modelo que es optimizado. Se definieron requerimientos funcionales y no funcionales desde un caso de uso. Arquitectura de Nodos Se usó una metodología basada en Attribute- Driven Design (escalabilidad, trazabilidad y tolerancia a fallas). Se definieron los componentes de la plataforma. Se seleccionaron los patrones arquitecturales para satisfacer los atributos seleccionados para cada componente. Arquitectura de Plataforma 17
Componentes de Plataforma de Software Nodos, Optimizadores, Evaluadores y Clientes Nodos: Generan la OPoW como hash de bloque de registro de eventos que contenga nuevo óptimo. Blockchain es una tabla de SQLite. Patrón arquitectural descentralizado y MVC. Almacenan datos de optimización y evaluaciones. Realizan autenticación, autorización y registro de eventos (solicitudes y respuestas) de otros componentes. Optimizadores: Realizan optimización, envían a nodos los parámetros óptimos. Evaluadores: Usan el último estado de optimización para evaluar datos de los clientes. Arquitectura de Nodos Cientes: Envían datos a los nodos para ser evaluados por los evaluadores. Arquitectura de Plataforma 18
Funcionamiento de Plataforma de Software Interacción entre Componentes Los optimizadores, evaluadores y clientes usan un REST API para enviar solicitudes a los nodos. Los optimizadores buscan constantemente los mejores parámetros. Cuando encuentran parámetros optimizados, los envían a cualquier nodo. Los evaluadores traen de los nodos los parámetros optimizados y las evaluaciones pendientes. Cuando los evaluadores han realizado una evaluación, envían el resultado a los nodos. Los clientes envían solicitudes de evaluación que quedan como pendientes en los nodos hasta que un evaluador haya enviado una respuesta. Funcionamiento de la Plataforma 19
Caso de Aplicación Ejemplo de optimización de una red neuronal para Forex trading Automatización de toma de decisiones de clientes usando una red neuronal que está en optimización en una red descentralizada. Un grupo de dispositivos optimizan continuamente la red neuronal usando algoritmos evolutivos (NEAT). La red neuronal toma información del mercado y la orden actual para generar la mejor acción a tomar (buy/sell/nop). Parámetros Optimizados Los evaluadores descargan las mejores redes neuronales (topología y pesos) y en ellas evalúan entradas enviadas por clientes. Todas las solicitudes (y respuestas) de optimizadores, evaluadores y optimizadores se almacenan en un Blockchain. En una applicación comercial, el blockchain serviría para cobrar por los servicios consumidos. Acción a Tomar Market Info 20
Nodos Los nodos usan un patrón arquitectural MVC, usan flooding controlado para enviar los registros de eventos a otros nodos y realizan autenticación, autorización y registro de requests. Cada API endpoint es una ruta, un método HTTP (POST,GET,DELETE) y sus parámetros. Ej: GET /evaluations/<id>, para descargar una evaluación o: POST /flood, para hacer flooding. Existe un método en el controlador para implementar el funcionamiento de cada API endpoint. Ej: EvaluationsController.getItem(id). Las respuestas del controlador a las solicitudes se hace usando unas plantillas llamadas vistas en las que se insertan los datos a retornar. Ej: el formato JSON-RPC v2.0. Se usa un modelo para representar los objetos a acceder en la base de datos independientemente del motor de BD usando ActiveQuery. 21 Arquitectura de Nodos
Nodos y Optimizadores Los bloques, evaluaciones, parámetros optimizados, usuarios, autorizaciones y registro de eventos son tablas en una base de datos (SQLite) en los nodos con métodos para: Obtener una lista de metadatos de elementos: GetList(), endpoint: GET /tabla Obtener un elemento con dado su id: GetItem(), endpoint: GET /tabla/<id> Crear un elemento: CreateItem,() endpoint: POST /tabla Borrar un elemento: DeleteItem(), endpoint: DELETE /tabla/<id> Los optimizadores realizan las siguientes solicitudes entre iteraciones del algoritmo evolutivo: Obtienen una lista de bloques para seleccionar el último. Obtienen el último bloque y de el extraen el id de los parámetros mas optimizados. Descargan los parámetros mas optimizados (si no los está usando ya) para usarlos en la siguiente iteración. Si encuentran un nuevo óptimo, lo envían a un nodo y si supera performance, el nodo crea un nuevo bloque. 22
Uso de la Plataforma Como usa un desarrollador la plataforma para escalabilidad de un EA Se deben instalar los nodos desde https://github.com/harveybc/singularity y configurarlos vía Web o CLI. Para cada nodo se deben configurar sus nodos vecinos para flooding y los usuarios (si se requiere más de uno). En sistemas operativos multi-tarea se puede instalar un optimizador (algoritmo evolutivo) y un nodo en el mismo dispositivo. Los desarrolladores deben modificar el código fuente de un EA (optimizador) que se encuentre funcionando correctamente. Estos cambios se muestran en el video y se implementó un ejemplo con NEAT. Entre iteraciones del EA, se deben hacer requests que descargan los mejores parámetros desde un nodo para reemplazarlos por los peores de la población (migración). 23 Navegador Web con manual de instalación en Github e interfaz de configuración de vecinos de red para flooding
Experimentos de Validación Descripción de Experimentos Resultados 24
Experimentos de Validación Validación de atributos de calidad provistos por descentralización Topología usada, cada dispositivo es un nodo y un optimizador Escalabilidad: Al adicionar optimizadores a una red, su capacidad computacional dedicada a optimización debería incrementarse respecto a unsolo dispositivo. Tolerancia a Fallas: El remover cualquier nodo, la optimización en otros dispositivos de la red no se debe detener y al reconectarse, se deben usar los parámetros más óptimos encontrados hasta el momento. Rechazo de resultados inválidos: El intento de introducir un resultado inválido debería ser futil debido a que los optimizadores validan los parámetros antes de usarlos. 25
Resultados de Experimentos Descripción de los experimentos Se usó: performance = capital_final / capital_inicial El promedio de ejecutar 10 veces la medición para cada etapa es Avg.Performance. Escalabilidad: Al realizar la optimización con 6 equipos se logró un mayor incremento en el desempeño que con uno. Stage Avg. Performance Control 1 2.95 2.91 2 3.11 3.24 Table 3 Invalid Result Rejection Experiment Results Stage Number of Optimizers Avg. Performance 1 6 3.28 2 1 0.76 Table 1 - Scalability Experiment Results Rechazo de resultado inválido: Al enviar un resultado inválido a un nodo (etapa 2), los optimizadores no lo usaron sino el mejor conocido hasta entonces, sin afectar significativamente el desempeño alcanzado. Stage Time [minutes] 3 Optimizers Group 2 Optimizers Group 1 Optimizer 1 30 2.48 2.48 2.48 2 60 2.61 2.53 2.48 3 90 2.96 2.96 2.96 Table 2 Fault-tolerance Experiment Results Tolerancia a fallas: Al fragmentar la red en 3 grupos, cada uno progresó independientemente(etapa 2) y al reconectarse se usaron los parámetros más optimizados hasta el momento (etapa 3). 26
Trabajo Futuro y Conclusiones Trabajo Futuro Conclusiones 27
Conclusiones Es posible usar una prueba de trabajo de optimización para controlar el tiempo de bloque de un blockchain en una red descentralizada. Se puede usar el blockchain para almacenar en los nodos eventos de aplicación (autenticaciones, evaluaciones) y el estado de optimización para que los optimizadores puedan usar los parámetros mas optimizados encontrados hasta el momento. La plataforma implementada permite a un desarrollador usar un REST API entre iteraciones de un algoritmo genético para sincronizar su estado de optimización con otros optimizadores, proveyendo además registro de eventos, autenticación y autorización en una arquitectura descentralizada. El problema de la modificación del blockchain puede ser mitigado requiriendo una prueba de trabajo criptográfica similar a la de Bitcoin pero de menor dificultad en adición a que se requiera que el bloque contenga parámetros con un incremento suficiente en desempeño. 28
Trabajo Futuro Implementar una prueba de trabajo criptográfica adicional a la OPoW para obtener seguridad respecto a re-uso de la prueba de trabajo. Implementar un problema-board para usar múltiples problemas de optimización para la generación de prueba de trabajo como se hace en algunas upow Comparar diferentes funciones de migración para verificar como influyen en el desempeño de la optimización. Comparar diferentes configuraciones de las generaciones (iteraciones de EA) que se saltan entre migraciones. Probar diferentes algoritmos evolutivos y técnicas de optimización multi-nivel como CoDeepNEAT. 29
30 Gracias por su Atención