Hacia el aprendizaje federado consciente de la reputación basado en blockchain

---

Dirección en papel: https://www.researchgate.net/profile/Muhammad-Habib-Ur-Rehman/publication/339297228_Towards_Blockchain-Based_Reputation-Aware_Federated_Learning/links/5e83b797299bf130796db972/Towards-Blockchain-Based-Reputation -Aware-Federated-Le arning.pdf

---

APRENDIZAJE FEDERADO DE GRANO FINO

A. Declaración del problema

​Existen algunas limitaciones en los esquemas clásicos de aprendizaje federado: (1) Heterogeneidad de dispositivos y servidores. (2) Alta dimensionalidad de datos y actualizaciones de modelos. (3) Hay desviaciones en los datos, algoritmos, fuentes de datos, preprocesamiento de datos y entrenamiento de modelos. (4) Centralización de la formación de modelos. (5) Punto único de falla y omisión. Además, los esquemas tradicionales de aprendizaje federado introducen actualizaciones de modelos globales centralizados, lo que es beneficioso para el desarrollo de aplicaciones de granularidad gruesa. Por ejemplo, se puede realizar la detección de actividades generales de usuarios de teléfonos móviles. Sin embargo, de hecho, cada usuario tiene diferentes patrones de comportamiento, como la longitud de la zancada, la velocidad al caminar, la postura sentada, el modelo de carrera, etc., por lo que se requiere una personalización personalizada. Como se muestra en la Fig. 1 , FL de grano fino logra una mayor flexibilidad y disponibilidad de conocimiento.

B. Definición

El artículo redefine FL clásico como FL detallado, que realiza un proceso de aprendizaje colaborativo que preserva la privacidad en las tres capas (es decir, borde, niebla y nube) de una red MEC (Mobile Edge Computing). Incluye principalmente tres entidades: (1) propietarios de datos (dispositivos de borde), (2) árbitros de datos (nodos de niebla), (3) propietarios de modelos (servidores en la nube). La figura 2 ilustra el proceso de ejecución de FL detallado en la red MEC. Dado un $Una\; colección\; de\; N$ dispositivos$D=\{1,...,N\}$ , uno que contiene$Un\; conjunto\; de\; n$ nodos de niebla$F=\{1,...,n\}$ y un conjunto de modelos$L=\{1,...,n\}$ , cualquier dispositivo$D_{}$Debe ser lo mismo que $F_{}$están asociados y pueden ejecutar $L_{}$。

Paso_1 (Modelo Bootstrapping): $D_{}$Descarga periódica de global $L_{}$actualice y suponga que $D_{}$Disponer de los recursos suficientes para llevar a cabo las tareas de aprendizaje.
Paso_2 (Inicialización de tareas globales): el servidor de la nube envía periódicamente el modelo actualizado al nodo de niebla $F_{}$. Además, el servidor en la nube delega la tarea de aprendizaje (p. ej., hiperparámetros, tasa de aprendizaje, precisión deseada, SGD optimizado/semioptimizado) a todos los $F_{}$。
Paso_3 (Inicialización de tareas locales): $F_{}$Envíe regularmente el modelo actualizado al $D_{}$. Además, $F_{}$Vincular las tareas de aprendizaje a sus modelos locales $L_{}$fósforo. En el caso de actualización, $L_{}$Ejecute Step_5 , de lo contrario, selecciona el candidato $D_{}$y delegar la tarea de aprendizaje a todos $D_{}$.
Paso_4 (Agregación de modelo local): El servidor en la nube solicita múltiples $F_{}$para actualizar $L_{}$parámetros, por lo tanto, el retraso de la red MEC y el arranque tardío harán que la actualización del modelo en el proceso de FL detallado no esté sincronizada. Por lo tanto, después de implementar su modelo local $L_{}$antes, $D_{}$Necesita hacer coincidir los parámetros del modelo de los tres modelos (**modelo propio, modelo de nodo de niebla, modelo de servidor???)**. En el caso de actualización del modelo, $D_{}$Recopile datos de sensores y aplicaciones y pase $L_{}$Ejecutar una tarea de aprendizaje dada $D_{}$actualizar su local $L_{}$modelo, aplicar técnicas de preservación de la privacidad a las actualizaciones del modelo y enviarlas a sus $F_{}$Hacer agregación local. $F_{}$Ejecuta el algoritmo de agregación del modelo local y actualiza su modelo local L i L_i en consecuencia$L_{}$Después de agregar la información privada, los parámetros del modelo actualizado se envían al servidor de la nube.
Paso_5 (Agregación de modelo global): el servidor en la nube ejecuta el esquema de agregación de modelo global y actualiza el $L_{}$. sera $L_{}$La actualización de se propaga a todos los $F_{}$。
Paso_6 (Solicitudes de actualización de modelo global): $D_{}$Genere periódicamente actualizaciones de los modelos globales para actualizar sus $L_{}$.
Paso_7 (Actualizaciones del modelo global): el servidor en la nube envía periódicamente los parámetros del modelo actualizado a todos los $D_{}$Suma $F_{}$。

C. Requisitos

Con base en los objetivos y problemas de FL de grano fino en sistemas MEC y las deficiencias del trabajo de investigación relacionado, en esta subsección se definen algunos requisitos básicos, como se muestra en la Fig. 3 .

Personalización: los propietarios de datos comparten L i L_i local$L_{}$Actualizado para mejorar los modelos de aprendizaje colaborativo en nodos de niebla y servidores en la nube. Sin embargo, el local $L_{}$Se requiere que sea personalizado y resistente a los ataques de envenenamiento de datos y modelos.
Descentralización: entre datos, dueños de datos, $F_{}$Y la centralización de los servidores en la nube conduce al modelo FL de datos y sesgo que no son de IID. Por lo tanto, se requiere descentralización entre todos los participantes involucrados en el proceso de FL de grano fino.
FL de grano fino: el modelo FL clásico proporciona predicciones de grano grueso, a través de las cuales se pueden hacer predicciones en todos los $D_{}$Actualización global centralizada $L_{}$. Sin embargo, en esencia, los conjuntos de datos se pueden particionar verticalmente para obtener mejores conocimientos. MEC admite la gestión de datos de varios niveles, por lo que puede facilitar $D_{}$、$F_{}$y partición de datos vertical a nivel de nube. Los conjuntos de datos particionados en varios niveles producen un entrenamiento FL más detallado.
Incentivación: Se necesitan nuevos incentivos para contratar $D_{}$.
Confianza: Múltiples propietarios de datos, árbitros de datos y propietarios de modelos deben proporcionar un entorno seguro, confiable y que preserve la privacidad.
Monitoreo activo: debido a la energía limitada de la batería y las restricciones de movilidad, $D_{}$La participación en el entorno del MEC es volátil. Por lo tanto, se necesitan sistemas FL de granularidad fina para monitorear continuamente a los participantes eliminados para garantizar una recopilación de datos de alta calidad.
Heterogeneidad y conciencia del contexto: FL de grano fino necesita lidiar con MEC debido a $D_{}$、$F_{}$, tipo de datos, fuente de datos y $L_{}$y posible heterogeneidad. Además, $D_{}$Suma $F_{}$Debe ser capaz de razonar sobre diferentes situaciones y establecer el contexto correcto en el que ejecutar $L_{}$.
Comunicación y eficiencia de ancho de banda: D i D_i adyacente$D_{}$Bajo el mismo entorno, con las mismas tareas de aprendizaje, se producen las mismas actualizaciones del modelo. Por lo tanto, se requieren técnicas sofisticadas de reducción de datos, compresión de modelos y agregación de modelos adaptativos. Además, $F_{}$Se debe garantizar una latencia mínima para mejorar la eficiencia de la comunicación.
Sincronización de modelo de grano fino: $D_{}$Suma $F_{}$Las variaciones en los recursos en FL conducen a la pérdida de participantes y variaciones en el tiempo de ejecución, lo que da como resultado diferentes entornos de FL detallados. Por lo tanto, un sistema FL detallado debe minimizar el retraso en todas las rutas de comunicación para garantizar la máxima sincronización de las tres capas en el sistema MEC.

---

REPUTACIÓN CON CONSCIENCIA DE FL BASADA EN BLOCKCHAIN

malicioso, incorrecto $D_{}$La existencia de puede convertirse en el principal cuello de botella para cumplir con el requisito de FL de grano fino, sin embargo, con respecto a $D_{}$La información de reputación a priori puede superar este cuello de botella. El sistema de reputación de FL detallado basado en blockchain se muestra en la Fig.4 .

El acceso a la información de reputación se proporciona a todos los participantes del sistema FL a través de DApps front-end que utilizan la tecnología de contrato inteligente y cadena de bloques pública de Ethereum para calcular y determinar agregados confiables de puntajes de reputación. $D_{}$Puede solicitar, acceder y comparar desde el servidor en la nube y $F_{}$Los parámetros del modelo fuera de la cadena se evalúan, se evalúa su rendimiento y se codifican y almacenan en un almacenamiento descentralizado (como IPFS) en la red MEC. Informan el hash de la puntuación de reputación a un contrato inteligente en cadena. El contrato inteligente agrega y calcula cada $F_{}$y la reputación del servidor en la nube. Del mismo modo, $F_{}$Connected D se puede emparejar en función de la riqueza de datos, la conciencia del contexto, la capacidad de proporcionar actualizaciones de modelos no redundantes representativas en un entorno heterogéneo, la proporción de participantes eliminados, la calidad de las actualizaciones de modelos, los cambios estadísticos en las actualizaciones de modelos, etc. i D_i$D_{}$Clasificación de Rendimiento. De manera similar, el servidor en la nube puede evaluar D i D_i de acuerdo con el entusiasmo de participar en el proceso de desarrollo del modelo colaborativo, la voluntad de compartir actualizaciones del modelo, la frecuencia de las actualizaciones del modelo y otros parámetros de rendimiento.$D_{}$Suma $F_{}$Haz una calificación.