Privacidad de datos en blockchain: Hyperledger Fabric
Vengo evaluando y usando varios protocolos blockchain hace ya rato. Y sin duda una de los temas que mas mi inquieta es como estos protocolos manejan la privacidad de datos y como ese modelo es capaz de aplicarse a escenarios reales.
Hace un año exactamente me encontré con la necesidad de evaluar Hyperledger Fabric versus Corda R3 pues había que decidir cual de los dos usar.
Tengo que decir que el junio del 2017 era un poco distinto al de hoy: En latino-américa no había el interés en blockchain como el de hoy . Varios protocolos blockchain aun en versiones beta con muy poca información técnica y menos en español, y una escasez tremenda de casos de uso de blockchain en la empresa. Ademas que Estados Unidos se retiraba del Acuerdo de París contra el cambio climático y se iniciaban formalmente las negociaciones del Brexit y puede que algunos de ustedes ni siquiera habría escuchado de esa palabra rara que parece tener origen asiático llamada blockchain.
La evaluación me tomo un par de meses, en julio Richard Gendal Brow quien es Head of Technology at R3CEV, es decir la gente que desarrolla Corda R3, público este artículo en el cual hacia referencia de las debilidades de Hyperledger Fabric para proporcionar un modelo de privacidad de datos consistente con escenarios reales.
Los puntos expuestos eran los siguientes:
Debido al diseño de Fabric y su modelo de consenso que utiliza canales que son una especie de mini-blockchains donde un conjunto cerrado de pares participa transacionando criptoactivos, toda la información en un canal inevitablemente se mezcla con toda la demás información en ese canal. No había una manera fácil de extraer solo algunas piezas, con historia y procedencia.
En su lugar Corda utiliza una arquitectura totalmente diferente basada en “estados” individuales que representan hechos compartidos específicos, cada uno de los cuales puede evolucionar independientemente.
Es decir al agregar un nuevo participante a un canal de Fabric este podría mirar toda la historia de ese canal, ya que esta esta disponible para todos los miembros de ese canal, al igual que suceden con slack o telegram.
El problema que había era que Fabric 1.0 lograba privacidad a través de canales, pero no dentro de los canales.
Para entender técnicamente cual era el problema recomiendo revisar el flujo transaccional de Fabric en el siguiente link. En todo caso la exposición del problema se documento claramente en el siguiente power point Privacy Enabled Ledger
los issues eran:
- El set de lectura/escritura y los datos confidenciales de un “transacion proposal” son visibles en la cadena de bloques.
- El Ordering Service no analiza la transacción, pero tiene acceso a la transacción, incluido el set de lectura/escritura (el libro del Orderer almacena bloques con las transacciones)
- Todos los pares en un canal tienen acceso a los datos de la transacción.
Aun más, otro problema mayor que encontré era la dificultad para compartir un criptoactivo entre estos canales asegurando su historia, y procedencia. En concreto un ejemplo ello sería el siguiente: En una red blockchain de Hyperledger Fabric puedes usar esa infraestructura para diseñar múltiples canales cada uno de los cuales pueden involucrar diferentes conjuntos de participantes y criptoactivos. Si diseñas un canal para desarrollar la relación entre los participantes A, B y C, considerando que t1 es propiedad de C, y necesitas otro canal en el cual desarrollas una relación entre los participantes A, C y D en el cual necesitas transaccionar t1, resulta muy difícil llevar t1 del primer canal al segundo asegurando procedencia de t1 y su propiedad sobre C. En general hacer eso representaba una gran esfuerzo.
¿Pero que sucede con Fabric a la fecha de hoy?
En la actualidad Fabric v1.1 cuenta con otros mecanismos ademas de los canales. El primero es una mecanismo de privacidad de datos que evita que ciertas claves de datos sean enviadas al ordering service para distribuirlas a todos los pares vía goosip (osea pasando el chisme entre vecinos de la red).
El otro es un mecanismo de cifrado necesario para dividir los datos privados en porciones que se cifran según las reglas de visibilidad, para permitir leer y ver las partes relevantes de los datos solo a las partes involucradas.
Estas características se implementaron en la tarea FAB-1151 y se marcaron como resuelta el 08 de Marzo del 2018 a las 12:18 y se liberaron con la versión v1.1 de Hyperledger Fabric.
El documento Hyperledger Fabric — Private Channel Data (version2) muestra a profundidad como se solvento el problema e incluye comentarios de los desarrolladores. Es un google doc donde puedes revisar el historial de ediciones, notas, etc.
La solución fue:
- Los datos privados se comparten con los particpantes autorizados luego del “endorsement” y se almacenan en un almacen transitoria de cada participante.
- Datos de canales públicos y hashes de datos privados son incluidos en una transacción y distribuidos a todos los participantes.
- Tras la validación/confirmación, los datos privados se mueven a la base de datos de estado privado y al almacenamiento privado del conjunto de escritura.
Solo para ejemplificar el siguiente gráfico muestra como se manejan la privacidad de datos particionando los estados. Se usan diferentes particiones de almacenamiento para las colecciones de estados privados entre el participante 1 y participante 2.
Nota: Algo que sin duda me resulta genial de los proyectos Hyperledger es tener la posibilidad de acceder al jira, documentos internos, fuentes, interactuar con los mantainers (desarrolladores principales), participar en las sesiones, etc. En el caso de hoy puedo ver resuelto un requerimiento que para mi en ese entonces era imprescindible, pero tuve que esperar, tampoco demasiado, he visto como en otros proyectos privados con otras tecnologías se han tardado más en cosas menores.
