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 más 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 cuál de los dos utilizar.

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.

Además, 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 hacía referencia de las debilidades de Hyperledger Fabric para proporcionar un modelo de privacidad de datos consistente con escenarios reales.

-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 está 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 cuál era el problema, recomiendo revisar el flujo transaccional de Fabric en el siguiente link. En todo caso, la exposición del problema se documentó claramente en el siguiente PowerPoint Privacy Enabled Ledgerlos 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.
-Aún 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.

En la actualidad Fabric v1.1 cuenta con otros mecanismos además de los canales. El primero es un 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

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 solventó 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 participantes autorizados luego del “endorsement” y se almacenan en un almacén transitorio 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.

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.

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.

Sobre el Autor

Ricardo Ruano CEO Business Blockchain

Ricardo Ruano

Founder & CEO at Zeyo (Business Blockchain)

Emprendedor experto en Blockchain y banca digital. Pionero en soluciones blockchain empresariales para el mercado latinoamericano.

Lidero un equipo increíble de colaboradores con el cual estamos construyendo la nueva generación de soluciones blockchain

¿Deseas conocer más?

Tokenizacion de activos

Tokenizacion de activos

Tokenizacion de activos ¿Que es la tokenización de activos? Un proceso que permite transformar un activo del mundo real, tangible o intangible, en uno único

Leer más »

Únete a la revolución Blockchain

Estamos listos para impulsar tu negocio

Rellena el formulario y nos
pondremos en contacto.

¡Gracias!