Desmontando mitos sobre Blockchain (II)

Mito #2: Blockchain es transparente y anónimo

Desde que el término Blockchain saltó de una pequeña comunidad de usuarios y seguidores de Bitcoin al público en general, los medios de comunicación acuñaron una serie de eslóganes, con los que caracterizaban la nueva tecnología que había despertado una fiebre a nivel mundial. Todo el mundo quería saber sobre Blockchain, lo que provocó que los medios generasen una tsunami de información sobre la tecnología del momento. En muchos casos, la línea sensacionalista de las publicaciones, generaron una serie de ideas y conceptos sobre blockchain, que no son del todo correctos y que se arrastran hasta hoy. 

Algunas de estas ideas, han formado parte del corpus de Blockchain desde que el público en general conoció Blockchain y sus posibilidades. Quizás una de las ideas más extendidas sobre Blockchain, es que es transparente y anónima. Curiosamente son dos características, que a priori parecen incompatibles, ya que el anonimato, es una forma de evitar la transparencia. 

Pero entonces ¿por qué se habla de transparencia y anonimato cuando hablamos de Blockchain? Para explicarlo, vamos a tratar por separado ambos términos.

La transparencia en Blockchain

La RAE define la transparencia como:

Transparente

4 adj. Claro, evidente, que se comprende sin duda ni ambigüedad.

Un adjetivo que podemos dar, para transmitir que algo es claro y evidente. Cuando se asocia este adjetivo con Blockchain, queremos decir, que es una tecnología que nos permite ver de forma clara y evidente, cómo se manipulan los datos que utilizamos en Blockchain. Recordemos que blockchain tiene la capacidad de registrar todas las operaciones que se realizan sobre los datos. 

En el caso de las criptomonedas, por ejemplo la red Bitcoin, mantiene en su blockchain todas las operaciones que se realizan con todos los bitcoins que gestiona la red. Esto es necesario, ya que la blockchain se utiliza como un ledger contable, en el que se apuntan la creación y la transmisión de todas las criptomonedas. Este proceso de registro, de todas las operaciones, permite implementar procesos que evitan el famoso doble gasto. Lo que garantiza, que el sistema sea sólido, sin la necesidad de que nadie tenga el control total. Para entender, por qué es necesario que la red Bitcoin sea transparente, vamos a explicar, de forma sencilla cómo se transfiere la propiedad de un bitcoin. 

Blockchain con transparencia por diseño

Bitcoin utiliza un esquema denominado UTXO (Unspent Transaction Output), el cuál se basa en registrar operaciones, cuyas entradas son otras operaciones válidas en la red. El siguiente esquema muestra 3 transacciones, implementadas con UTXO. 

Vamos a centrarnos en la transacción B. Lo primero que vemos es que tiene un conjunto de INPUTS y OUTPUTs. Los INPUTs son identificadores de transacciones que existen en la blockchain. Los OUTPUTs son salidas, que vamos a generar con esta operación y que una vez se valide y forme parte de la blockchain, se podrán utilizar como INPUTs en otras transacciones.

La transacción B, tiene como INPUT, un OUTPUT de una transacción anterior, como vemos en el ejemplo, este OUTPUT corresponde a 0.1 bitcoins. Por tanto, si utilizamos un como INPUT un OUTPUT de 0.1 bitcoins, podremos realizar transacciones, cómo máximo de este valor. Como OUTPUTs de la transacción, vamos a generar 2 transferencias, una Bob con un valor de 0.0150 bitcoins y otra a Alice, con un valor de 0.0845. La diferencia entre la cantidad de los INPUTs y los OUTPUTs, son los fees que vamos a pagar por la transacción.

Como se puede ver en el diagrama, este esquema permite, que una ves que la transacción B, forme parte de la blockchain, el usuario Bob podría utilizar el OUTPUT de B, como INPUT en C. Es un esquema sencillo, que permite mantener un registro de todas las operaciones que se van realizando. UTXO es una forma eficaz de implementar un proceso descentralizado que impide el doble gasto de un asset.

Para el caso concreto de Bitcoin, es imprescindible la transparencia de las operaciones, para poder construir transacciones que cumplan el esquema UTXO. Por tanto, la transparencia está ligada a la necesidad del proceso de transferencia. Cualquier persona que tenga acceso a la blockchain de bitcoin, puede ver en tiempo real, este tipo de operaciones. Con un poco de paciencia, se pueden rastrear todas las transacciones hasta el bloque en el que se generaron los bitcoins que han participado en todas las transacciones relacionadas con la que estamos analizando.

Desde este punto de vista. Podemos afirmar que Bitcoin es transparente, pero no debemos olvidar, que aunque Bitcoin fue el inicio, Blockchain es un término que engloba a muchas tipos de tecnologías distintas y es aquí donde se desmonta el mito de la transparencia. 

La transparencia nace de la necesidad que tiene la aplicación para tener visibilidad sobre los datos. En el caso de Bitcoin se trata del modelo UTXO que necesita de un sistema transparente, para verificar las entradas y construir salidas, que cumplan con la necesidad de evitar el doble gasto. Sin transparencia no se puede implementar UTXO. Pero si no necesitamos implementar UTXO para nuestra aplicación ¿sigue siendo Blockchain transparente?

Un ejemplo menos transparente

Una vez que hemos visto, la relación entre la aplicación y la transparencia, vamos a desarrollar otro ejemplo de aplicación, que no se base en un modelo UTXO. Por ejemplo, pensemos que en este caso Bob y Alice, pretenden intercambiar información de algún tipo. Quieren utilizar la tecnología blockchain, para poder tener trazabilidad y poder verificar la información que comparten. En este caso, Alice construye una transacción, que estará firmada digitalmente por ella y en la que incluirá el dato que quiere pasar a Bob.

Para no alargar el ejemplo y como tiene simplemente un objetivo didáctico, vamos a suponer que el proceso de validación de las transacciones, únicamente valida que la transacción es correcta, porque está firmada por la dirección de Alice. Sin entrar en discusiones sobre la necesidad de tener un coste por transacción o que se implementa un modelo de consenso basado en Proof of Authority, vamos a simplificar el proceso de validación.

Con este esquema, Alice envía transacciones las cuales van formando parte de la blockchain, momento en el que Bob puede acceder a la blockchain para leer los datos que Alice le está enviando. Bob puede verificar la autenticidad de la transacción comprobando la firma de Alice y capturando el dato que ésta le envía. Un usuario que accediese a la Blockchain, con el propósito de recuperar todas las transacciones que Alice ha enviado a Bob, obtendría algo parecido a este listado.

Transacciones con datos, que Alice ha generado y firmado, cuyo destinatario es Bob. Pero nuestro curioso usuario no tendría el contexto sobre la naturaleza de los datos. En este ejemplo, la blockchain aportaría transparencia sobre las operaciones de escritura que Alice realiza, pero no hay información sobre la aplicación que Bob y Alice están compartiendo. Este es un ejemplo, en el que el concepto de transparencia se va debilitando, aunque estemos utilizando Blockchain.

Pero podríamos añadir un nivel más de opacidad al proceso de compartición de datos entre Alice y Bob. Vamos a suponer que Alice va a encriptar los datos y que utilizará une esquema Diffie-Hellman para compartir la clave de encriptación de los datos. En este supuesto, nuestro usuario curioso, ni siquiera tendría acceso al valor de los datos que Alice está compartiendo con Bob.

Nuestro amigo curioso, solo vería las operaciones, pero no los datos. Aunque esta información puede seguir siendo útil para ciertos análisis, la realidad es que los datos no son accesibles. Por lo que el nivel de transparencia, se queda únicamente en el número de operaciones.

Este es un ejemplo, de cómo podemos controlar el nivel de transparencia, que van a tener las soluciones que implementemos sobre Blockchain. La realidad, es que es una decisión de diseño de la aplicación. Si necesitamos implementar un modelo de transparencia total, para que todos los participantes puedan tener acceso, tanto a nivel de las operaciones, como de los datos implicados en dichas operaciones, podemos decidir dejar toda la información de manera transparente. Pero la decisión anterior, es una opción para cumplir con unos requisitos del caso de uso, nunca una condicionante impuesta por Blockchain.

Hyperledger Fabric para entornos permisionados

Muchas organizaciones, piensan en Blockchain como un sistema, en el que la transparencia es total, algo que puede ir en contra de sus intereses estratégicos. En muchos casos, las organizaciones no pueden compartir datos de manera abierta, tanto por obligaciones regulatorias, como estratégicas. Entender que el nivel de transparencia depende de la necesidad que tengamos, permite a las organizaciones construir casos de uso, que cumplan con sus necesidades reales, tanto a nivel de privacidad de los datos, como de auditoría de los procesos. Blockchain es una herramienta muy poderosa para demostrar la ejecución de los procesos sobre los datos, permitiendo garantizar una trazabilidad de las operaciones. Manteniendo un equilibrio entre la transparencia y la auditoría, las organizaciones pueden construir procesos más confiables de intercambio de información.

De las distintas opciones de tecnologías Blockchain, Hyperledger Fabric es una muy buena opción para implementar modelos de transparencia a la medida de las necesidades del caso de uso. Podemos desarrollar varias estrategías para conseguir el nivel de transparencia necesario, ya que Hyperledger Fabric cuenta con algunas características como ser una tecnología multiledger o implementar el concepto de ledger privados (private data collections).

Una de las opciones más interesantes para construir soluciones, que cumplan con las necesidades de transparencia del caso de uso, es la capacidad que tiene Hyperledger Fabric para gestionar varios ledgers en la misma infraestructura. Gracias a esto, se pueden desarrollar soluciones, en las que la información se puede particionar en distintos ledgers, para incrementar la granularidad de la privacidad y la gobernanza de los datos. 

Veamos un ejemplo. Varias compañías quieren colaborar para trabajar sobre un conjunto de información. La información está formada por varios conjuntos de datos, cada uno de los cuales, tiene sus propios requisitos de transparencia. La siguiente tabla muestra los requisitos que deben cumplir los conjuntos de datos.

Para nuestro ejemplo, sobre el conjunto de datos denominados Datos Rojos, se deben aplicar las siguientes restricciones:

• La organización A puede ejecutar las operaciones de leer y escribir sobre los datos.
• La organización B solo puede leer los datos.
• La organización D solo puede leer los datos.

Es decir, hay que implementar un modelo de acceso a los datos, que cumpla con la siguiente tabla. En Hyperledger Fabric podemos diseñar una modelo de arquitectura multiledger que nos permitiría cumplir con estas restricciones. Podría ser el siguiente:

• Se crea un ledger para gestionar el conjunto de Datos Rojos.
  • Se da permiso de lectura/escritura a la organización A.
  • Se da permiso de lectura a la organización B
  • Se da permiso de lectura a la organización D

• Se crea un ledger para gestionar el conjunto de Datos Azules.
  • Se da permiso de lectura/escritura a la organización B.
  • Se da permiso de lectura a la organización D

• Se crea un ledger para gestionar el conjunto de Datos Naraja.
  • Se da permiso de lectura/escritura a la organización C.
  • Se da permiso de lectura a la organización A
  • Se da permiso de lectura a la organización D

De esta forma, podemos controlar la visibilidad de los distintos conjuntos de datos, entre las organizaciones que participan en nuestro ejemplo. Esta es una forma sencilla de controlar el nivel de transparencia que se implementa en la solución, permitiendo establecer un control sobre la capacidad que cada uno de los participantes tienen para acceder a los distintos conjuntos de datos.

Conseguir desmontar el mito sobre la transparencia en las soluciones Blockchain, sobre todo en los entornos corporativos o de consorcios, es fundamental para comprender el potencial real que la tecnología blockchain tiene para potenciar y transformar los procesos de intercambio de información entre compañías.Muchas organizaciones, piensan en Blockchain como un sistema, en el que la transparencia es total, algo que puede ir en contra de sus intereses estratégicos.

El anonimato en Blockchain

Quizás el mito que más daño está haciendo a Blockchain, es la idea de que por diseño Blockchain es anónimo. Esta idea surge de la percepción que la mayoría de la gente tiene sobre el modelo de criptografía asimétrica. Cuando alguien se acerca al mundo Blockchain, lo que primero a lo que se tiene que enfrentar es al concepto de clave pública y clave privada. No vamos a dedicar tiempo a explicar la teoría sobre la base de la encriptación asimétrica, puedes leer más sobre este tema en post  Criptografía de Curva Elíptica pero quedémonos con la idea de clave privada. Al usuario, lo primero que se dice es que debe generar una clave privada, la cual estará asociada a la clave pública, que hará las veces de identificador único dentro de la red. Esta será su identidad digital dentro de la red blockchain.

La primera cuestión que aparece en la cabeza del usuario, es que puede crear tantas claves privadas como quiera, ya que es él el que las crea y nadie más tiene acceso a dichas claves. Por tanto, sólo él conoce la identidad real que está detrás de todas las claves privadas que está creando. Alice puede crear tantas identidades como quiera, como muestra el siguiente ejemplo.

Mientras, que Alice no comunique la relación entre ella y sus identidades digitales, el anonimato de Alice está garantizado, ya que nadie tiene forma de establecer la relación entre la identidad de la persona Alice y sus identidades digitales. Para nuestro ejemplo, supongamos que Bob también ha generado un conjunto de identidades digitales.

Para que Alice pueda construir una transacción, cuyo destinatario sea Bob, es necesario que éste le diga de “alguna manera” cuál es su identidad digital. Decimos “alguna manera” porque la forma de compartir la identidad digital con otro usuario, está fuera del proceso que estamos implementando en Blockchain. Alice y Bob pueden intercambiar un email o una llamada, en este caso se ha establecido una comunicación fuera de la blockchain. Para nuestro ejemplo, supongamos que Bob le comunica a Alice su identidad #3. Desde el punto de vista de Alice, el esquema sería el siguiente.

Alice conoce a Bob como su clave pública #3 y desconoce la existencia de las otras identidades de Bob. Ahora que Alice conocer la relación entre Bob y su identidad digital #3, puede enviar una transacción, cuyo destinatario sea la identidad digital #3 que conoce de Bob. Pero en este momento, Alice también puede ir a la blockchain y buscar todas las operaciones en las que haya participado, tanto como emisor o receptor, la identidad digital #3 de Bob. 

Cualquier operación que Bob hiciese en el pasado utilizando su identidad digital #3, ha quedado desanonimizada para Alice, ya que ella sabe que detrás de esas operaciones está Bob. Este ejemplo, cuyo propósito es fundamentalmente didáctico, pone sobre la mesa, el problema del anonimato basado en esquemas de clave pública. Hay que entender, que estos esquemas, son interesantes para establecer relaciones de confianza entre partes, pero que si dichas partes pierden la confianza, este tipo de modelos presenta problemas, por ejemplo, que Alice conocerá todas las operaciones que Bob haga con su identidad digital #3. Por tanto, si Bob quiere mantener el anonimato del resto de sus operaciones, deberá utilizar otra de las identidades digitales que ha creado y que Alice desconoce.

Pseudoanonimato de Blockchain

Del ejemplo anterior, hemos aprendido, que aunque partimos de una situación inicial de anonimato de las identidades digitales, con el uso que haríamos a lo largo del tiempo, ese anonimato se puede ir perdiendo, lo que puede suponer un problema en ciertos casos de uso. Lo que significa, no solo que Blockchain no sea anónimo, sino que debemos diseñar procesos que garanticen el anonimato de las identidades si así lo requiere el caso de uso. 

Hay ciertas tecnologías Blockchain que buscan el anonimato desde el diseño, como es el caso de Monero o Zcash, pero como hemos comentado anteriormente, son casos en los que se han construido procesos para garantizar dicho anonimato.

Por lo general, tenemos que entender que los procesos para proteger la identidad en blockchain son pseudoanonimos, ya que podemos garantizar el anonimato frente a cierto conjunto de identidades. Un ejemplo son las redes permisionadas, en las que se pueden implementar proceso pseudoanonimos para proteger las identidades. Pero el precio, es que existe un actor en la red que conoce nuestra identidad. Hyperledger Fabric utiliza un esquema de certificados X509 para la autenticación de los usuarios y la firma de las transacciones. Una CA (Certificate Authority) mantiene el control sobre la gestión de los certificados que se dan a los usuarios. Se pueden implementar procesos pseudoanónimos, en los que los certificados X509 no proveen de información, simplemente son llaves que dan acceso a la blockchain. Es la CA la que mantiene la relación entre identidad digital y usuarios, quedando esta relación fuera de la blockchain. 

Otro aspecto importante, para garantizar el anonimato de ciertos procesos, es que se utilicen múltiples identidades digitales a lo largo del tiempo y que dichas identidades no estén ligadas entre sí. Ya que en caso de que se exponga la relación entre el usuario y una de sus identidades digitales, solo se puedan relacionar las operaciones que dicha identidad digital hizo y no el resto.

Puedes leer más sobre anonimación de datos en el post Anonimizando datos.

El gran reto de garantizar los procesos de privacidad de los datos y la identidad digital, es que debemos entender que una de las soluciones pasa por un modelo dinámico de identidad digital, frente al actual modelo estático, que nos ha traído al punto en el que nos encontramos en estos momentos con respecto a los servicios digitales. Debemos transformar el concepto de identidad digital, para pasar de un mero identificador asociado a nosotros, el correo electrónico por ejemplo. A un modelo en el que el identificador no importa, lo que importa es que podemos demostrar quienes somos. Actualmente existen varias iniciativas que están desarrollando este modelo de identidad digital dinámica, como son los modelos de Identidad Auto-Soberana (SSI).

Conclusión

Blockchain no es sinónimo de transparencia absoluta o de anonimato de los participantes. Es una herramienta para construir esquemas de confianza entre partes, pero dichos esquemas deben ser diseñados, para cumplir con los requerimientos de todas las partes involucradas. Entender las capacidades reales de Blockchain, en función de la tecnología que vayamos a utilizar, ya sean redes públicas o privadas, con permisionado o sin él, es esencial para aprovechar las ventajas que nos ofrece esta tecnología, a la hora de fortalecer la confianza.

Desmontar ciertos mitos que se han construido sobre Blockchain, ayuda a las organizaciones a comprender el potencial real. La transparencia total, no concuerda con las necesidades reales de las organizaciones. Utilizar la tecnología adecuada, permite implementar modelos de transparencia acordes a las necesidades de los casos de uso. Conseguir construir modelos de identidad digital, acordes al cumplimiento normativo o la privacidad de los usuarios, es esencial para cualquier organización que esté pensando en la tecnología Blockchain.

José Juan Mora Pérez – CTO

Leer más:

Mito #1: Blockchain es solo para criptomonedas

Mito #2: Blockchain es transparente y anónimo