Blockchain archivos - Términos y Condiciones

La fuerza imparable (RGPD) contra el objeto inamovible (Blockchain)

Jorge Morell Ramos — Wed, 27 Feb 2019 10:51:06 +0000

Síguenos en | Cuenta la leyenda que el origen de la palabra “contradicción” en chino proviene de una historia en la que un comerciante estaba tratando de vender una lanza y un escudo. Cada vez que al comerciante le preguntaban cómo de buena era su lanza, éste aseguraba que podía atravesar cualquier escudo. A su vez, cuando le preguntaban lo bueno que era su escudo respondía que podía detener los ataques de cualquier lanza. Entonces un día alguien le preguntó qué pasaría si arrojaba su lanza contra su escudo. El vendedor no supo qué contestar y eso dio origen a la palabra. Esta historia no es más que otra versión de la famosa paradoja de la fuerza imparable contra el objeto inamovible, un problema de lógica clásica que no intenta reflejar una realidad sino jugar con la teoría de esa realidad. Curiosamente, la llegada de uno de los cambios normativos más importantes de los últimos 20 años en Europa, el Reglamento General de Protección de Datos (en adelante RGPD), se asemeja a una fuerza imparable que todo el mundo debe aplicar (incluso más allá de la Unión Europea). Por otro lado, hace 10 años nace un tipo de tecnología que se aleja muy considerablemente de los esquema conocidos y que entre sus características básicas presenta la inmutabilidad de los cambios que recopila. Obviamente estamos hablando de blockchain, o lo que es lo mismo, un objeto aparentemente inamovible. Esta fuerza imparable (el RGPD) y ese objeto inamovible (blockchain) están chocando de pleno desde la aplicabilidad del primero el pasado 25 de mayo de 2018. De hecho, prometedores proyectos han cerrado por ello. Y ese choque está ocurriendo en materias aparentemente irreconciliables: 1) el derecho de supresión frente a la inmutabilidad de la cadena; 2) la identificación clara y centralizada de responsables, encargados e interesados frente a un sistema completamente descentralizado; 3) el cifrado de la información personal subida a la cadena de bloques o 4) la prohibición (con límites) de decisiones únicamente automatizadas frente a “contratos inteligentes” autoejecutables e irrevocables. ¿Pero es esa fuerza tan imparable como dice y ese objeto tan inamovible como aparenta? A lo largo de este post vamos a intentar a explicar en detalle las problemáticas que están surgiendo entre uno y otro elemento, así como las posibles soluciones (presentes y futuras) que puedan permitirnos superar esta paradoja.

La batalla original entre la fuerza imparable y el objeto inamovible

1.- ¿Qué es el RGPD?

La protección de los datos personales siempre ha sido un objetivo político a conseguir en la Unión Europea. Por ello se consagró en el artículo 8 de la Carta de los Derechos Fundamentales de la Unión Europea. En la actualidad los datos personales se han convertido en un activo cada vez más valioso para muchas empresas, ofreciendo sus servicios a coste cero para luego recopilar información personal que pueda monetizarse, mayormente mediante anuncios. Dichos modelo de negocio nos permite acceder de forma gratuita a multitud de servicios de gran calidad, pero generan también numerosas situaciones donde las empresas hacen un uso indebido de los datos personales. Algo que por desgracia comienza a ser muy común y condiciona nuestro derecho a la protección de datos personales. Con la intención de salvaguardar ese derecho fundamental y mejorar muchos de los puntos débiles de la ya derogada Directiva 95/46/CE, por ejemplo la falta de homogeneidad en la libre circulación de datos en Europa, llegó el RGPD. De esta forma el Reglamento General de Protección de datos o RGPD, aplicable desde el 25 de mayo de 2018, establece las nuevas normas relativas a la protección de las personas físicas en lo que respecta al tratamiento de sus datos personales y la libre circulación de estos datos. El RGPD supone numerosos avances en la gestión de datos personales en la Unión Europea e incluso más allá, ya que su ámbito de aplicación material y territorial es muy amplio. Además, está pensado para esta nueva economía del dato que se ha creado en la última década, creando nuevas obligaciones a los proveedores y generando nuevos derechos para sus usuarios. Además, convierte en norma los conceptos de privacidad desde el diseño y por defecto. Algo que como veremos resulta muy importante para nuestra paradoja. Por todo ello, el RGPD se convierte en esta fuerza imparable que toda organización que gestione información personal, el petróleo de nuestros días, debe tener en consideración. Ahora bien, el RGPD se redactó bajo un modelo tradicional y centralizado en cuanto a la gestión de los datos. Es decir, un mundo en el que los datos personales serían tratados por unos responsables y encargados (relativamente) fáciles de identificar y con una estructura suficientemente jerarquizada. Con lo que no contaba el legislador, si bien tuvo la oportunidad de saber sobre ello ya que blockchain nace en 2009 junto a bitcoin, es que en nuestros días la gestión de datos personales también se iba a producir en entornos absolutamente descentralizados y mayormente automatizados. O lo que es lo mismo, entornos en los que identificar a responsables, encargados o interesados iba a ser una tarea altamente compleja. He aquí la cadena de bloques y el desafío que plantea al RGPD y buena parte de sus principios.

2.- ¿Qué es Blockchain?

Una vez presentada nuestra fuerza imparable, el RGPD, vamos con el otro protagonista de esta historia: el objeto inamovible o blockchain. Una buena introducción al tema puede ser el siguiente vídeo de la Universidad de Deusto:

Sea como sea, ¿cómo puede definirse blockchain? Si nos ponemos técnicos, una blockchain o cadena de bloques sería una base de datos en la que la información contenida se agrupa en bloques a los que se les añaden metainformaciones relativas a otro bloque de la cadena anterior en una línea temporal. De esa manera, y gracias a técnicas criptográficas, la información contenida en un bloque solo puede ser rechazada o editada modificando todos los bloques posteriores. Si lo bajamos al suelo, blockchain no es más que una base de datos especial. En esa base de datos hay una hoja de cálculo que se ha duplicado miles o millones de veces en una red de ordenadores. Esa red de ordenadores actualiza de forma regular y simultánea esa hoja de cálculo cada vez que hay un cambio en la misma. Añadido un cambio, el mismo no puede ser editado o borrado, solo rectificado con otro cambio posterior. Como esa misma base de datos existe en centenares de miles o millones de ordenadores a la vez (también llamados nodos), no hay una localización central para su gestión, lo que dificulta muy considerablemente su hackeo, facilita su verificación y distribuye la confianza sobre la veracidad de esos datos en todos los ordenadores de la red y no en una ubicación central. Ahora bien, también rompe con el modelo tradicional de bases de datos centralizadas. Quien tenga más curiosidad sobre ello, puede ampliar información en este post nuestro sobre el tema. Dicho esto, en una blockchain un bloque será la estructura de datos utilizada para agrupar transacciones (por ej. un pago con criptomonedas). Cada vez que un bloque es completado el mismo es añadido a la cadena. Además de las transacciones, los bloques incluyen otros elementos, como el hash del bloque anterior (una especie de huella dactilar en versión digital del mismo) y una marca de tiempo (día, hora, fecha). Volveremos a varios de estos conceptos y términos a lo largo del texto. Por ahora basta que nos quedemos con la idea de que blockchain es una base de datos descentralizada (que por tanto puede contener datos personales) y entre cuyas características se incluye la inmutabilidad de lo escrito en la misma. Como seguro que muchos ya saben, blockchain se está usando en múltiples sectores económicos. En los sectores inmobiliario, del comercio, financiero, del transporte, seguros o logística, entre otros. La idea es que una sola base de datos con una única versión de los datos anotados puede simplificar mucho la vida a las empresas y entidades, en especial a la hora de coordinar y validar sus actividades en cualquier parte del mundo. Evitando con ello la interoperabilidad entre múltiples bases de datos e intermediarios. Muy resumidamente, he ahí nuestro objeto inamovible.

2.1.- Tipo de nodos y de cadenas

Antes de seguir con este enfrentamiento épico, sería bueno perfilar toda una serie de cuestiones sobre el funcionamiento de blockchain. La cadena de bloques tiene como característica básica ser una tecnología para bases de datos descentralizadas. Eso permite que un gran número de participantes (conocidos o no, enemistados o no), pueda almacenar de forma sincronizada copias de la misma información. Datos que únicamente pueden ser añadidos pero no eliminados. Ahora bien, eso puede matizarse mucho en función de la tecnología y el tipo de blockchain utilizado. Ello nos lleva a hablar de tipos de blockchain y nodos. En este caso, de acuerdo a la clasificación establecida por el European Union Blockchain Observatory and Forum. Comencemos con los nodos. En términos generales, una blockchain consiste en un servidor compuesto por un grupo de nodos (ordenadores) que almacenan copias sincronizadas de la misma información. Normalmente hay dos tipos de nodos: A) Nodos de validación: son específicos de una red y además de realizar operaciones de validación deben resolver un conjunto de problemas criptográficos antes de poder incorporar un nuevo bloque a la cadena. Por tanto, para crear un nuevo bloque válido deben seguir las reglas exactas especificadas por el algoritmo de consenso de la cadena. Para ello ponen a disposición de la red su poder computacional (capacidad de CPU y sobre todo GPU), con los gastos energéticos y a nivel de infraestructura que ello comporta. Por realizar esa tarea reciben una compensación. A esa acción se le llama minería, siendo los nodos validadores los mineros. De ese modo, el primer nodo validador que consigue resolver el problema criptográfico planteado recibe una pequeña comisión por ello. B) Nodos de participación: son los que almacenan copias sincronizadas de la información. En función de la tecnología específica de la cadena, los nodos almacenarán toda la información de la cadena o solo una parte (para así evitar que ser parte de la cadena le deje a uno sin espacio libre en el disco duro). Si un usuario se conecta a un nodo de participación puede añadir datos a la cadena, pero esa transacción deberá ser validada por un nodo de validación. Dicho esto, vamos a por los diferentes tipos de cadenas de bloques. Inicialmente solo se hablaba de BLOCKCHAIN PÚBLICAS, con permisos y sin permisos. Las blockchain públicas sin permisos serían como Bitcoin o Ethereum. Las mismas se caracterizan por no exigir a los usuarios el cumplimiento de ningún requisito para unirse a ella. Es decir, cualquiera puede convertirse en un nodo o parte de la red. Por eso normalmente se dice que son cadenas sin permisos. Para hacerlo simplemente hay que instalar el software cliente (software que casi siempre es de código abierto) y descargar una copia completa de la cadena de bloques. A partir de ese momento ya eres un nodo completo que puede participar en el proceso de almacenamiento y/o agregación de información (participación o validación). Asimismo, el contenido de una blockchain pública es transparente y visible para todos los usuarios (y en algunos casos no usuarios), ya que habitualmente no se exigen permisos o invitaciones para poder acceder y participar. Por otro lado tenemos las blockchain públicas con permisos. O lo que es lo mismo, en éstas cualquiera puede ser un nodo de participación y ver todos los datos, pero solo los usuarios aprobados previamente pueden ser nodos de validación y añadir datos a la cadena. Sería por ejemplo el caso de Alastria, entre otros.

Comparativa sobre las características más comunes de una blockchain pública y una privada

Por otro lado, existen las BLOCKCHAIN PRIVADAS (como por ejemplo WeTrade o Enerchain, entre otras) que se caracterizan por ser de carácter cerrado. Es decir, se requiere una invitación previa. Ésta puede ser validada personalmente por quién crea la red, un grupo limitado de creadores o por ciertas reglas que estén preestablecidas. De este modo, un grupo reducido está autorizado a acceder, comprobar y añadir transacciones a la cadena de bloques. Este grupo también está en posición de decidir qué nuevos usuarios podrán incorporarse a la red y bajo qué requisitos. En este tipo de redes, los nodos de validación son nodos de confianza y leales, situación que reduce los procesos requeridos para su funcionamiento del mismo modo que reduce el riesgo de sufrir ciberataques y brechas de seguridad. Eso se debe a que estos nodos son preestablecidos y elegidos previa y expresamente. Por tanto, no necesitan ninguna comisión para realizar las tareas de validación. El proceso de validación de transacciones es más rápido que el de las redes públicas, y a su vez consumen menos energía. De esta forma, podríamos decir que las blockchain públicas son como Internet (abierta a todo el mundo), las blockchain públicas con permisos serían como una gran extranet (tienen un punto de partida privado pero están abiertas al exterior en gran parte) y las blockchain privadas son como una intranet (solo para los que tengan permiso para entrar). Señalar también que otra posible clasificación es la que habla de blockchain públicas al 100%, blockchain privadas al 100% y blockchain permisionadas (una mezcla entre la versión pública y privada). En cualquier caso, nosotros seguiremos la clasificación inicialmente comentada.

3.- La tensión entre blockchain y el RGPD

3.1.- Los escenarios

Conocidos nuestros protagonistas y sus características, es hora de comenzar a profundizar en la problemática. Para empezar, es importante recordar que el cumplimiento del RGPD no tiene que ver con la tecnología blockchain en sí, sino en cómo se utiliza la misma. Es decir, al igual que no hay un Internet o un algoritmo compatible con el RGPD, no existe una tecnología de cadena de bloques compatible con el reglamento. Como bien dice el informe del European Union Blockchain Observatory and Forum, solo hay casos de uso y aplicaciones que podrían llegar a ser compatibles. De esta manera, debemos entender que la interacción entre blockchain y el RGPD debe realizarse caso por caso, analizando dónde aparecen los datos personales, cómo se tratan y quiénes son los responsables de dicho tratamiento. De los tres escenarios más comunes comentados (blockchain públicas sin permisos, blockchain públicas con permisos y blockchain privadas), ya avanzamos que son éstas últimas las que de inicio mejor van a llevarse con el RGPD. Los escenarios serían: A) Las cadenas privadas suelen estar operadas por empresas, consorcios o entidades gubernamentales, lo que facilita aplicar el contenido del RGPD. Dichas entidades están en posición de definir los roles de sus participantes y los flujos de información. Además, pueden imponer reglas estrictas de tratamiento de los datos personales al asegurarse de que todos los participantes de la red se vinculen con un conjunto de términos y condiciones. Sin embargo, también presentan desafíos. Es decir, solo porque los miembros de la entidad estén vinculados a unos términos y condiciones no significa que todos tengan una razón legítima para ver los datos de cada uno de ellos. B) En cuanto a las cadenas públicas con permisos, son una de las formas más comunes de operar, y se sitúan en un punto intermedio a la hora de hacerlas compatibles con el RGPD. C) Finalmente, las cadenas públicas sin permisos presentan sin duda los mayores desafíos respecto al cumplimiento de RGPD, debido a su naturaleza extremadamente distribuida.

3.2.- Los puntos de tensión

Dicho esto, veamos dónde chocan nuestra fuerza imparable (el RGPD) y el objeto inamovible (blockchain), teniendo en cuentas los diferentes escenarios y particularidades de cada uno. Como decíamos al inicio, hay 4 materias aparentemente irreconciliables: 1) la identificación clara y centralizada de responsables, encargados e interesados frente a un sistema altamente descentralizado; 2) minimizar los riesgos para los interesados al subir datos a la cadena, de modo que deba recurrirse al cifrado de la información personal subida (si es que llega a subirse); 3) el ejercicio de derechos, y en especial el derecho de supresión teniendo en cuenta la inmutabilidad de la cadena; y 4) la prohibición (con límites) de decisiones individuales automatizadas en el caso de “contratos inteligentes” autoejecutables e irrevocables, ejecutados en la cadena. ¡Comencemos con el primero!

El RGPD (Hulk) intentando dejar clara su irresistible fuerza, blockchain (the Blob) ríe alegremente

3.2.1.- Quién es el responsable

En el RGPD la accountability o el principio de responsabilidad pro activa viene regulado en los artículo 5.2 y 24, además del considerando 74. No es un concepto precisamente nuevo, ya la OECD hablaba del mismo en los Códigos de conducta o Guías de protección de la privacidad y flujo transfronterizo de datos personales, por allá 1980. El GT 29, el actual EDPB, lo definió como un principio por el que los responsables del tratamiento ponen en marcha procedimientos y medidas eficaces para garantizar el cumplimiento de los principios y obligaciones establecidos en la normativa sobre privacidad, y poder así demostrar ante las autoridades el cumplimiento de la misma. O lo que es lo mismo, no simplemente cumplas, sino que demuestra que cumples. En el RGPD el principio de privacidad pro activa tiene gran importancia. En un modelo tradicional cliente – proveedor, es relativamente fácil identificar a las diferentes partes (responsable, encargado, interesado y demás) y hacerlo cumplir (importante resaltar lo de “relativamente”). Pero cuando el RGPD y su principio de privacidad pro activa entran en contacto con blockchain, los roces pueden ser significativos a la hora de identificar a las partes. Así las cosas, en las cadenas privadas y en las públicas con permisos es donde mejor encaja el modelo tradicional. De hecho, el informe de la agencia de protección de datos francesa (CNIL) sobre blockchain y el RGPD, recomienda que en los consorcios de blockchain se identifique al responsable o corresponsables tan pronto como sea posible en el proyecto. Es decir, la CNIL habla respecto a la existencia de corresponsabilidad, entendiéndola en este caso como un grupo de entidades o de personas que decidan realizar un tratamiento de datos personales utilizando blockchain. Sin embargo ,entiende que eso no será aplicable si se crea una persona jurídica en representación de todos los participantes, y la misma asume ser el responsable del tratamiento a todos los efectos. Igualmente cuando se designe a uno de los participantes como responsable del tratamiento. Por otro lado, en las blockchain públicas sin permisos, donde la idea es reemplazar el modelo tradicional de cliente – proveedor por uno basado en el tratamiento colectivo de datos a través de un protocolo compartido, la cuestión de cómo identificar a un responsable es mucho más compleja. Comencemos por, ¿quién no debería ser considerado responsable en esos casos? Sin duda, los desarrolladores de protocolos que crean y mantienen la tecnología de cadena de bloques de código abierto, como es el caso por ejemplo de bitcoin. ¿Razón? Son voluntarios que trabajan en un proyecto de código abierto y, en muchos casos, no reciben una compensación directa por sus esfuerzos. En esencia, simplemente crean una herramienta útil y ni siquiera informan de cómo se debe utilizar. Lo contrario sería como decir que Tim Berners-Lee es el responsable de todo lo que sucede en la World Wide Web. También sería deseable que los actores que ejecutan el protocolo de la cadena de bloques en sus ordenadores para actuar como nodos de validación o de participación en redes públicas sin permisos, no fueran considerados responsables del tratamiento. Pero aquí la cuestión no es tan pacífica. Por un lado, se puede argumentar que los nodos no determinan la finalidad ni los medios del tratamiento, ya que realmente: 1) están ejecutando el protocolo con la esperanza de ganar una recompensa; 2) para contribuir a la estabilidad de la red 3) o como una forma de acceder a los datos que son relevantes para ellos sin depender de intermediarios externos. De hecho, la CNIL señala en su informe que los mineros no sería responsables ya que simplemente validan transacciones y no delimitan las finalidades ni los medios para su tratamiento. Otros argumentan lo contrario, ya que a través de la acción de descargar y ejecutar activamente el software, los nodos determinan la finalidad y los medios del tratamiento. Además, apuntan que cuando se lanza una nueva versión de un protocolo, los nodos son libres de ejecutarlo o no, y a través de este acto influyen en cómo evoluciona la plataforma. Llegados a este punto, ¿qué pasa con los usuarios de la red que firman y envían transacciones a la cadena vía un nodo? Si envían datos personales como parte de una actividad comercial, lo más probable sería considerarlos como responsables del tratamiento. Esto incluiría entidades que operan software así como productos o servicios que publican datos personales en una cadena de bloques. Sin embargo, si envían sus propios datos personales para su uso personal, como la compraventa de criptos, seguramente estaríamos ante la excepción del artículo 2.2 c) RGPD de tratamiento de datos para uso doméstico. En este sentido, la CNIL entiende que podrán ser responsables del tratamiento todos aquellos que introduzcan datos personales en la blockchain siempre y cuando quien los introduzca sea una persona física y el tratamiento de datos personales esté relacionado con una actividad profesional o comercial. O bien, que quién los introduzca sea una persona jurídica. ¿Y el encargado del tratamiento, quién es? La CNIL entiende que podremos delimitar al encargado del tratamiento solo en supuestos concretos, por ejemplo:

Los desarrolladores de smart contracts que tengan acceso a datos personales de los usuarios de sus smart contracts.

Los desarrolladores o validadores de transacciones, como son los mineros en las blockchain privadas o en las públicas con permisos, y bajo un protocolo de consenso de prueba de trabajo, cuando validan transacciones que contengan datos personales.

En esos casos sería necesario que los mismos cumplan con las obligaciones impuestas a los encargados del tratamiento en el artículo 28 RGPD. Ahora bien, la CNIL reconoce que esta obligación deviene prácticamente imposible en blockchains públicas sin permisos.

Superman vs Capitán Marvel (Shazam), otro caso de fuerza imparable contra un objeto inamovible

3.2.2.- La anonimización de los datos

El segundo punto de tensión es relativo a cómo los datos personales deberían ser anonimizados cuando se suben a una cadena de bloques. Es decir, cómo se minimizan los riesgos de los interesados cuando el tratamiento se realiza en blockchain. El RGPD se aplica al tratamiento de datos personales a menos que éstos se hayan anonimizado. Por tanto, no se aplica a datos anónimos. Sin embargo, el listón para lo que se califica como anónimo es muy alto. La técnica de anonimización no solo debe ser lo suficientemente buena para que sea imposible identificar a una persona física, sino que también el proceso debe ser irreversible. Es decir, no debería ser posible reconstituir los datos originales del dato anonimizado. Cualquier técnica que no cumpla con este estándar se consideraría “semi anónima”, y no anónima. Pero claro, los datos seudonimizados sí que están sujetos a las obligaciones del RGPD. Dada la inmutabilidad de los datos en la mayoría de las redes de blockchain, la comunidad entiende que almacenar datos personales en una cadena de bloques, sin ningún tipo de cifrado, es una mala idea. Recomendación aplicable tanto a las redes públicas como a las privadas, y sus diferentes variantes. A ello se suma el principio de privacidad desde el diseño, como señala el art. 25 RGPD. La CNIL dice que de acuerdo al mismo el responsable del tratamiento debe pensarse muy mucho si el tratamiento de los datos mediante blockchain es la tecnología más apropiada. Al fin y al cabo, en la cadena de bloques se dan dos circunstancias que sí o sí pueden implicar el tratamiento de datos: 1) una solicitud a millones de mineros para validar la transacción 2) la actualización de la cadena al añadir un nuevo bloque para todos los participantes. Eso genera un problema extra, dice la CNIL: que se produzcan transferencias internacionales de datos a terceros países y fuera de la UE. Algo que puede ocurrir muy fácilmente. Ese problema es más controlable en blockchains privadas o públicas con permisos, al poder aplicar cláusulas contractuales estándar, normas corporativas vinculantes, códigos de conducta o certificaciones. Pero cuando pasamos a una blockchain pública sin permisos, no hay límite a esas transferencias internacionales. Lo que genera nuestra segundo punto de tensión: cómo subimos datos personales a una blockchain minimizando los riesgos para los interesados, especialmente teniendo en cuenta características de la tecnología como su inmutabilidad o descentralización. Normalmente se habla de solucionar estos problemas mediante técnicas de ofuscación, cifrado o agregación para el tratamiento de datos personales. Y ya sea en un caso o en otro, el informe del European Union Blockchain Observatory and Forum dice que deben evaluarse dos riesgos cuando se adoptan algunas de estas técnicas: A) Riesgo de reversión: cuando a pesar de la técnica criptográfica utilizada, es posible revertir el proceso y reconstituir los datos originales. Por ejemplo, mediante el descifrado de fuerza bruta. B) Riesgo de vinculación: cuando cabe la posibilidad de vincular datos cifrados a una persona mediante el examen de los patrones de uso o contexto, o por comparación con otras piezas de información. Vamos a detenernos en cada una de las técnicas y comentar varias de sus particularidades. Recordemos que lo deseado es poder convertir los datos personales subidos a la cadena en totalmente anónimos, eliminando así de la ecuación a la fuerza irresistible conocida como RGPD. O si no fuera posible, minimizar su impacto. I.- Ofuscación de direcciones personales Vaya por delante que según el Diccionario de la Real Academia, “ofuscar” significa “oscurecer y hacer sombra” (entre otras acepciones). ¿Por qué puede resultar útil aquí? Ocurre que normalmente una cadena de bloques usa el sistema de “clave pública/privada” como un medio para proporcionar o derivar direcciones de los remitentes y receptores de las transacciones. Esa clave pública sería como el número de un apartado de correos. Yo puedo enviar información a ese buzón, pero solo el dueño de la clave privada puede abrirlo y obtener la información. Esa clave pública consiste en una larga cadena de caracteres aleatorios, de modo que en principio no hay forma de descubrir nada a partir de la misma. Dado que en algunas blockchains públicas las direcciones de los remitentes y receptores de las transacciones pueden ser vistas por todos, según el RGPD dichas direcciones serían datos seudonimizados, especialmente en los casos en que existe un claro riesgo de vinculación. Por ejemplo, cuando tengo mi clave pública visible en la bio de mi Twitter personal. De hecho, dice la CNIL que como las claves públicas son un elemento clave del funcionamiento de blockchain, son un dato que no puede minimizarse más y que su periodo de conservación está en línea con la existencia de la propia cadena. Es decir, si alguien usa la misma dirección para varias transacciones, entonces comienzan a surgir patrones. Estos patrones, quizás combinados con otros tipos de información, pueden usarse para identificar indirectamente a los individuos. Y estas técnicas ya se utilizan. En este contexto surge la ofuscación, que es por ejemplo el proceso que intenta modificar un programa para hacer más compleja su comprensión. La ofuscación perfecta es imposible, porque tarde o temprano hay que decirle al ordenador lo que tiene que hacer, pero pueden darse suficientes “rodeos” para confundir a quién esté analizando nuestro programa (ya sea un humano o una herramienta automática). Las técnicas de ofuscación normalmente se utilizan para: eliminar comentarios, espacios en blanco y saltos de línea; modificar los nombres de variables y funciones para que no proporcionen información sobre su objetivo; complicar artificialmente el control de flujo de un programa; alterar la distribución del código dentro de un proyecto o hacer que el código del programa se modifique a sí mismo antes de ejecutarse. Lógicamente estas técnicas pueden ayudar a anonimizar los datos personales de cara a su posible escritura en una blockchain. Por tanto, ¿cuáles son las técnicas de ofuscación más comunes? Una de ellas es la denominada servicio de direccionamiento indirecto de terceros. La misma consiste en pedir a un tercero que agregue muchas transacciones de blockchain y las publique en la cadena utilizando su clave pública propia. Es decir, lo que a veces sucede cuando alguien le pide a una plataforma de comercio electrónico que compre criptos en su nombre. La transacción individual de la persona generalmente no se revela en la cadena de bloques pública. Por tanto, esta primera técnica implica encubrir el significado de una comunicación haciéndola mucho más difícil de interpretar. Otra técnica son las llamadas firmas de anillo, mediante la cual múltiples partes firman una transacción determinada de manera que alguien externo puede estar seguro de que una de las partes es el firmante legítimo, pero no sabe cuál. Un ejemplo de firma de anillo podría ser usada para proporcionar una firma anónima de un funcionario de alto rango de un gobierno, sin revelar qué funcionario firmó el mensaje. Las firmas de anillo son adecuadas ya que su anonimato no puede ser revocado y porque el grupo para una firma de anillo puede ser improvisado (no requiere ninguna configuración previa). Sea como sea, las técnicas de ofuscación de direcciones se pueden implementar de muchas maneras, y será a la luz del RGPD que deberá examinarse caso por caso. II.- Cifrado de datos personales La criptografía es una materia muy técnica, pero simplificando, vamos a hablar de dos técnicas que son relevantes para el RGPD (dejamos otras más avanzadas para algo más adelante en el post): A) Cifrado reversible: El cifrado reversible implica mezclar una pieza de datos de tal manera que sus contenidos no puedan ser entendidos. Solo la persona en posesión de la clave de cifrado puede descifrarla. Existen varios tipos de cifrado reversible, como el cifrado simétrico (donde se usa la misma clave) para encriptación y descifrado y el asimétrica (donde se utilizan diferentes claves). Para quien quiera profundizar sobre la materia, ahí va un vídeo interesante: B) Hashing (cifrado no reversible): Las cadenas de bloques hacen un gran uso de hashes. ¿Pero qué son? Un hash criptográfico es una técnica matemática que permite generar una cadena de caracteres alfanuméricos de longitud fija y única a partir de cualquier conjunto de datos digitales. No hay límite en cuanto al tamaño del archivo que puede dar lugar al hash. Por tanto, cuando se ejecute la función siempre se obtendrá una frase de texto única de cierta longitud fija. Y lo que es más importante, si cambia incluso el dato más pequeño, el hash será radicalmente diferente. Lo que dejará claro que los datos subyacentes se modificaron. Por ello se dice que los hash son como huellas digitales, ya que no hay dos iguales. Ahí va otro vídeo interesante sobre la materia: ¿Para qué usa blockchain un hash? Entre otras cosas, para asegurar el estado actual de la cadena. De ese modo, la huella hace de sello para cerrar la cadena cada vez que un nuevo bloque es incorporado. Además, también sirve para referenciar de forma única datos que se mantinen fuera de la cadena. Hecha esta introducción al mundo de la criptografía, se nos plantea la siguiente pregunta ¿los datos personales cifrados mediante una técnica reversible, siguen siendo datos personales a la luz del RGPD? Pues aunque parezca mentira, sí. Ya que por muy sólido que sea el cifrado empleado en los datos, mientras la llave para revertirlo siga existiendo, pues no podemos hablar de dato anónimo. Si a eso le sumamos que la tecnología no deja de mejorar, y que cifrados seguros hace años ya no lo son, no hay técnica de cifrado reversible que sea completamente segura. ¿Y el hashing? Hemos dicho que es una técnica no reversible, ¿nos soluciona eso el problema? Pues estamos todavía en tierra de nadie en esta cuestión. Ahora mismo la mejor respuesta a la cuestión de si un dato personal hasheado es o no un dato personal (y por tanto aplicable el RGPD) sería: depende. ¿Y de qué depende? De si el tiempo y la tecnología identifican posibles riesgos de reversabilidad o vinculación. En cuanto al riesgo de reversibilidad, el Grupo de Trabajo del Artículo 29 ya dijo que un ataque de fuerza bruta podría revertir un hash si los datos originales son conocidos y no muy grandes. Este riesgo se intenta mitigar mediante el uso de técnicas llamadas “salting” (salteado) o “peppering” (pimentado), que implican agregar información adicional a los datos para hacerlos lo suficientemente grandes como para que un ataque de fuerza bruta no pueda tener éxito. La diferencia entre saltear o pimentar es que al saltear el creador del hash almacena fuera de la cadena la información salteada y el hash. Mientras tanto, pimentar implica que la información pimentada se almacena de forma secreta, o que ni tan siquiera se almacena. El otro riesgo del que hablábamos es el de vinculación. Es decir, hay situaciones en las que el análisis de patrones hace posible descubrir información sobre un individuo en particular. Por ejemplo, cuando un usuario determinado realiza una transacción, lo que permite analizar el tiempo y la frecuencia de la misma. En esos casos, podría descubrir todo el comportamiento de la transacción al enterarme de la fecha y hora específicas en que ésta se ha completado. En resumen, si el hashing de un dato personal implica el riesgo de reversión o de vinculación es algo que deberá analizarse caso por caso. Y todo ello sin saber qué postura acabarán adoptando las autoridades de protección de datos, el EDPB o los tribunales. Sin duda que para conocer si un dato personal hasheado está o no sujeto a la normativa, será de ayuda la Opinión 5/2014 del Grupo de Trabajo del Artículo 29 en la que señalan los tres aspectos clave que deben analizarse para verificar que la anonimización es correcta: Singularización: ¿es posible extraer de un conjunto de datos algunos registros que identifiquen a una persona física? Vinculabilidad: ¿es posible vincular como mínimo dos registros de un único interesado o grupo de interesados? Inferencia: ¿es posible deducir con una probabilidad significativa el valor de un atributo a partir de los valores de un conjunto de otros atributos? Como decíamos, sin duda dependerá del caso concreto. En todo caso, y antes de avanzar con las técnicas de agregación, destacar que la comunidad blockchain trabaja en múltiples técnicas que en el futuro podrían permitir implementar enfoques de anonimización de datos aún más sólidos. Un ejemplo de ellas son las Zero-knowledge proofs (ZKP) o Pruebas de Conocimiento Cero, técnicas criptográficas avanzadas que permiten a alguien presentar pruebas de una declaración sin revelar los datos que subyacen a la misma. Por ejemplo, alguien puede presentar pruebas de que tiene más de 18 años sin revelar su edad real. Las aplicaciones ZKP son muy prometedoras en lo que respecta a la privacidad desde el diseño y la soberanía de los datos personales. Aunque todavía necesitan rodaje. Sea como sea, el sistema basado en blockchain más prometedor y que utiliza pruebas de conocimiento cero es ZCash, que también fue la primera criptomoneda en implementar zk-SNARK. Desde entonces, otros sistemas basados en blockchain también han incorporado pruebas de conocimiento cero en sus soluciones para permitir que las transacciones se verifiquen mientras se protege la privacidad del usuario / transacción. Probablemente el más conocido de los cuales es Ethereum, que implementó zk-SNARK como parte de la actualización de Bizancio (el llamado protocolo AZTEC). Por otro lado, otra técnica avanzada en camino es la llamada encriptación homomórfica. Aquí estamos ante un método criptográfico que permite a alguien solicitar que servidores privados realicen cálculos distribuidos. Si bien los datos subyacentes de estos cálculos nunca se revelan ni se comparten en la cadena de bloques, es en teoría posible obtener una prueba criptográfica de que el resultado agregado de esos cálculos es correcto. De esa forma, es por ejemplo posible cifrar datos, enviarlos a la nube y operar sobre estos datos sin descifrarlos. La nube no tiene la menor idea del contenido de los datos sobre los que está operando, no vé ningún resultado intermedio. La totalidad de los datos permanecen cifrados durante todo el tiempo. De manera que obtienes el resultado cifrado y solamente tú puedes descifrarlo. En eso consiste el cifrado homomórfico. III.- Agregación de datos personales Finalmente llegamos a las técnicas de agregación. Las mismas se pueden utilizar junto a las de ofuscación y encriptación. Por ejemplo, una gran cantidad de datos de interesados podrían ser agregados en una única firma digital que luego fuera incorporada a la cadena. Esa firma serviría luego como la prueba de la existencia de cada uno de los datos sumados. Estas técnicas de agregación dependen de estructuras llamadas Árbol de Merkle, que involucran funciones de hashing haciendo que el proceso sea aún más robusto y potencialmente anónimo. Muy resumidamente: un árbol de Merkle es una estructura jerárquica que se compone de un hash de hashes. Para crearla, se cogen todas las transacciones del bloque y se calculan sus hashes, una por una. A continuación, los hashes resultantes se juntan por parejas y se calcula el hash de la pareja. Esta operación se repite sucesivamente hasta que solo queda un único hash de todo, la raíz de Merkle.

Un ejemplo de árbol de Merkle

Además de contribuir a la inmutabilidad en Blockchain, los árboles de Merkle también permiten reducir el tamaño de la cadena de bloques a través de la operación conocida como “poda de bloques”. Sea como sea, se confía mucho en el potencial de estas técnicas de agregación a efectos de anonimizar datos personales. En ese sentido, se considera que las blockchain privadas son las más adecuadas para registrar transacciones individuales. Pero al ser relativamente pequeñas y estar muy distribuidas, es poco probable que puedan tener un impacto económico importante. A menos que puedan interoperar entre ellas. ¿Cómo conseguir esa interoperabilidad? Mediante la creación de puentes entre las cadenas privadas y públicas. Y ahí las técnicas de agregación de datos pueden facilitar que se comparta información anónima en una blockchain pública sin permisos. La opinión del CNIL sobre todo esto es que: 1) si se van a subir datos personales a blockchain se apliquen antes los principios de privacidad desde el diseño y por defecto; 2) si al final no queda más remedio que usar la cadena de bloques, adoptar soluciones que procesen los datos fuera de la cadena; 3) si no queda más remedio que subir el dato a la cadena, que se haga en forma de “commitment” criptográfico, o que se suba el hash generado al aplicar la técnica de hashing al dato o el ciphertext del dato; 4) si nada de eso es posible, la finalidad del tratamiento está justificada y la evaluación de impacto dice que el riesgo residual es aceptable, entonces se puede subir el dato personal en claro o simplemente hasheado. En toda esta cuestión al CNIL también le preocupa lo relativo a las medidas de seguridad aplicadas. Por ejemplo, sugiere que se evalúe el número mínimo de mineros necesario para desestabilizar más del 50% de la cadena. También le preocupa el potencial fallo del algoritmo, de sus vulnerabilidades o la confidencialidad de la cadena, si la misma no es pública. En cualquier caso, las diferentes técnicas comentadas deberán analizarse supuesto por supuesto y a la luz del RGDP. A efectos de ver si la fuerza irresistible es compatible con el objeto inamovible cuando no queda otro remedio que subir datos personales a una cadena de bloques.

3.2.3.- El ejercicio de derechos y otras cuestiones

Además de identificar a las partes y minimizar el impacto sobre la información personal, hay otros puntos de tensión entre el RGPD y blockchain. Tanto a nivel de principios y obligaciones de la norma, como del ejercicio de derechos. Un primer problema es la base de legitimación al tratar datos en una red descentralizada por completo. Es decir, una cadena pública sin permisos. En esos entornos no siempre es fácil determinar bajo qué bases legales se tratan los datos personales. Por ejemplo, el consentimiento en una cadena pública sin permisos, ¿a quién se lo da un usuario cuando como hemos visto no está claro quién es el responsable de la misma? Se argumenta que al elegir una red descentralizada al completo, el usuario ya está dando su consentimiento de facto. Sin embargo, al RGPD no le entusiasma la idea de una consentimiento que no sea expreso. ¿Recurrimos a la idea de la acción afirmativa en ese sentido? ¿Pero en favor de quién? Algo parecido se plantea cuando el usuario realiza una transacción, ya que podría intentar argumentarse un tratamiento basado en una relación contractual. Sin embargo, nuevamente nos cojea quién hay del otro lado y la parte informativa de esa contratación. Nadie por ahora plantea la posibilidad del interés legítimo como base de legitimación, pero dada la particular naturaleza de la cadena de bloques (un sistema transparente, descentralizado, inmutable y sin intermediarios), quizá tenga mucha lógica plantearse bases de legitimación en esa línea. Al fin y al cabo, todos los participantes en la cadena tienen un interés legítimo en que el sistema haga realidad las características que tan particularmente la definen. Por tanto, y en el caso de las blockchain públicas sin permisos, su estructura tan poco centralizada hace muy difícil aplicar el RGPD. Otra cosa es en cadenas privadas o públicas con permisos, donde seguramente sí sería posible identificar una entidad que opera el producto o servicio y actúa como intermediario entre los usuarios individuales y la cadena de bloques.

Otro choque de una fuerza irresistible (el martillo de Thor) contra un objeto inamovible (el escudo del Capitán América)

En este sentido, la CNIL dice que el derecho a la información de los interesados no plantea problema alguno en blockchain. Respecto a la minimización de los datos personales, como ya hemos comentado, la CNIL afirma que debemos minimizar los datos personales de tal forma que el único dato personal en la blockchain sea la clave pública. Y asimismo, admite como periodo de conservación de una clave pública el periodo de vida de la propia cadena. En cuanto al ejercicio de derechos como el de supresión o rectificación, la naturaleza de blockchain no se lleva nada bien con esos derechos. Incluso en una cadena privada o con permisos puede haber dificultades para su ejercicio si la misma no se ha diseñado para ello Sin embargo, debe tenerse en cuenta que el RGPD no define qué constituye un borrado o supresión del dato. En este contexto, la CNIL reconoce que es técnicamente imposible cumplir con el derecho de supresión en blockchain. Ahora bien, si lo almacenado en la cadena es un commitment, el hasheado del dato o el ciphertext obtenido mediante determinados algoritmos, el responsable del tratamiento podría hacer el dato prácticamente inaccesible y acercarse a la idea de supresión. Por ejemplo, si se destruye la clave secreta para la función de hash, no sería posible probar qué información o dato fue objeto de hash. Por tanto, ese hash subido a la cadena deja de ser un riesgo de confidencialidad y se “cumple” con el derecho supresión. La CNIL es consciente que este mecanismo no es lo que en principio debe entenderse por supresión, pero es lo que más se aproxima a ese derecho (a no ser que la cadena en particular haya sido diseñada con esa idea desde el inicio). En cuanto al derecho de rectificación, dice que el dato almacenado en el bloque no puede modificarse. Pero que como puede generarse otro bloque con el dato actualizado, aunque la transacción original sigue en la cadena, podría entenderse que la nueva cancela la primera. Otros dos derechos que pueden plantear problemas a la hora de su ejercicio son el relativo a las decisiones individuales automatizadas (que ahora comentaremos) y el del artículo 18 RGPD o la limitación del tratamiento. En este caso dice que debe realizarse un estudio detallado y por adelantado en cuanto al ejercicio de este derecho. Respecto al derecho de acceso (y el de portabilidad), la CNIL considera que no debería haber incompatibilidades para su ejercicio. Pero la verdad es que como no siempre será fácil saber quién es el responsable del tratamiento, y por tanto a quién dirigirse, aquí también tenemos el problema de a quién recurrir para obtener la información si no hay un responsable identificado. De hecho, incluso si el interesado pudiera identificar y comunicarse con un nodo específico, el nodo no sería necesariamente capaz de responder estas preguntas. Dos últimos apuntes, ya mencionados a lo largo del texto, son los relativos a la territorialidad del tratamiento de los datos. Como sabemos, existen obligaciones relativas al lugar donde se puede llevar a cabo el tratamiento. O lo que es lo mismos, las transferencias internacionales de datos personales a terceros países. El RGPD especifica que los datos personales generalmente solo pueden transferirse a terceros países si estos se consideran “adecuados”, es decir, si se considera que brindan la misma protección que la de la Unión Europea. De lo contrario, el responsable puede introducir las garantías adecuadas de que los datos se tratarán de manera consistente y de conformidad total con el RGPD. Como ya hemos dicho, esto puede ser muy problemático en una blockchain pública sin permisos e incluso en una privada que no cuente con las debidas autorizaciones. Finalmente, está la cuestión de la protección de datos desde el diseño y por defecto, y es hay problemas muy serios sobre la forma en que se diseñan y gobiernan las cadenas de bloques (por si no se ha notado hasta ahora) :p El RGPD establece que el responsable del tratamiento aplicará, tanto en el momento de determinar los medios de tratamiento como en el momento del propio tratamiento, medidas técnicas y organizativas apropiadas para aplicar de forma efectiva los principios de protección de datos, a fin de cumplir los requisitos del RGPD y proteger los derechos de los interesados. Eso sería el principio de protección de datos desde el diseño y por defecto. Pero claro, dado que la tecnología blockchain está algo verde todavía y que es desarrollada por comunidades de código abierto de todas las partes del mundo, la forma en que se integra hasta ahora la protección de datos personales puede dejar algo que desear. La buena noticia es que la tecnología está todavía en una etapa de construcción, y por tanto seguro que alguno de los proyectos presentes o futuros podrá incorporar el espíritu y el contenido del RGPD.

3.2.4.- Decisiones individuales automatizadas y smart contracts

Por si no hubiera suficientes preguntas hasta ahora, se plantea también qué pasa con los creadores de los contratos inteligentes. Como ya hemos mencionado, y muy simplificadamente, los contratos inteligentes son software que se puede implementar en blockchain y ser ejecutados independientemente de su (s) creador (es). Un tema importante es que este software solo se ejecuta cuando lo autoriza un nodo de la red, por lo que hay un debate sobre si este software debe ser visto como operado por su creador, por el nodo que lo ejecuta o por ambos. Otra cuestión relacionada con los contratos inteligentes y blockchain es la tratada por la CNIL brevemente y más en detalle por Michèle Finck en su trabajo “Smart Contracts as a Form of Solely Automated Processing Under the GDPR“, relativa a si cuando se usan contratos inteligentes en blockchain, y los mismos contienen información personal, podemos encontrarnos en el escenario del art. 22 RGPD. Es decir, que una de las partes de ese contrato sea objeto de una decisión basada únicamente en el tratamiento automatizado y que la misma produzca efectos jurídicos en el interesado o le afecte significativamente de modo similar. Una primera cuestión respecto al tratamiento automatizado de datos personales es que el interesado debe poder solicitar al responsable de los datos si los mismos se están utilizando para la toma de decisiones automatizadas. Por ello el RGPD estipula que los interesados tienen derecho a ser informados de si se está llevando a cabo dicho tratamiento y, a su vez, tienen derecho a solicitar la intervención humana o impugnar una decisión. Hay quienes creen que esta disposición del art. 22 RGPD podría tener un efecto negativo en la forma en que las personas usan los contratos inteligentes, ya que este tipo de contratos destacan por su potencial para introducir automatización radical en muchos casos. Sin embargo, surge la duda de cómo se podría cuadrar esa automatización radical con lo dispuesto en el RGPD, ya que si los desarrolladores de los mismos tienen que introducir medidas para permitir la intervención humana, la confianza que los participantes depositan en ellos podría reducirse drásticamente. La CNIL ha indicado que si una decisión exclusivamente automatizada surge de un contrato inteligente, la misma es necesaria para su desempeño, dado que permite el cumplimiento de la esencia misma del contrato. Es decir, es la razón por la cual las partes concluyeron el contrato. Ahora bien, el interesado debería poder obtener una intervención humana para expresar su punto de vista y disputar la decisión del contrato una vez que el mismo se haya ejecutado. Eso significa que el responsable del tratamiento debería proporcionar la posibilidad de una intervención humana que permita al interesado impugnar la decisión incluso si el contrato ya se ha realizado. Además, al margen de lo que se haya registrado en blockchain. La realidad es que el trabajo de Michèle Finck deja bastante claro que los contratos inteligentes no serán automáticamente legales conforme al art. 22 RGPD, pero sí puede ser diseñados (volvemos a la privacidad desde el diseño) para ser compatibles con sus requisitos. Michèle Finck considera que si bien eso requerirá un esfuerzo especial y, en algunos casos, un alejamiento de la motivación original en el uso de los smart contracts, los esfuerzos necesarios se superpondrán en parte con el desarrollo continuo de contratos inteligentes más sofisticados. Por ello cree que hay razones para considerar que el futuro de los contratos inteligentes no será el de la automatización total, sino que nos aprovecharemos de los beneficios de la ejecución automatizada y, al mismo tiempo, garantizaremos que eso ocurra de una manera compatible con con el mundo real y el RGPD.

4.- Diferentes escenarios y posibles soluciones

Vista la versión larga de los diferentes escenarios y sus particulares tensiones, veamos ahora la versión corta de esta lucha entre nuestra fuerza irresistible y el objeto inamovible. Comencemos por la base de datos corriente y moliente, la centralizada. El modelo tradicional y donde el RGPD se mueve como pez en el agua. En este caso hay poco que explicar ya que es la situación común (todavía no estamos en blockchain :p).

La típica base de datos centralizada | El RGPD likes this!

Veamos los tres escenarios particulares: BLOCKCHAIN PRIVADA

¿Quién es el probable responsable?

El consorcio de empresas creador, alguna de las mismas o una fundación. Sin descartar la corresponsabilidad en determinados casos (con los usuarios de la plataforma, por ejemplo) o que el consorcio actúe como responsable y encargado en determinadas circunstancias (cuando un servicio externo los contrate para operar sobre la cadena).

¿Quiénes son los probables encargados?

Los mineros/nodos y proveedores de servicios que operen en la misma, que a su vez podrían ser responsables en algunos casos.

¿Subimos datos a la cadena?

Teniendo en cuenta el tipo de blockchain, seguramente se podría hacer. Pero haría falta ver el caso particular, no olvidar la privacidad desde el diseño, la minimización de los datos o las medidas de seguridad adecuadas. Sin olvidar la opción preferente de cargar datos off-chain (es decir, fuera de la cadena).

¿Se pueden ejercer todos los derechos?

Debido al tipo de cadena, seguramente sí. Pero estará condicionada por su diseño, al final del día.

¿Podemos controlar las decisiones individuales automatizadas de los contratos inteligentes?

Debido al tipo de cadena, seguramente sí.

¿Hay transferencias internacionales de datos?

Es posible, pero deberían ser manejables con cláusulas contractuales tipo, códigos de conducta, certificaciones o normas corporativas vinculantes.

Una cadena de bloques privada: solo los usuarios aprobados pueden participar

BLOCKCHAIN PÚBLICA CON PERMISOS

¿Quién es el probable responsable?

El consorcio de empresas creador, alguna de las mismas o una fundación. En todo caso, y como el informe del Bundesblock señala, se recomienda explorar la idea de las “normas vinculantes de la cadena” para una blockchain que cumpla con determinados criterios. Tampoco debe descartarse la idea de que el interesado pudiera ser responsable de sus propios datos.

¿Quiénes son los probables encargados?

Algunos de los mineros/nodos y proveedores de servicios que operen en la misma, que a su vez podrían ser responsables en algunos casos.

¿Subimos datos a la cadena?

¿Se pueden ejercer todos los derechos?

Debido al tipo de cadena, es probable. Pero debería verse el caso particular. De todos modos, y dado el tipo de cadena, podría valorarse la imposición de forks (una bifurcación en el desarrollo de la cadena) para el cumplimiento de algunas obligaciones del RGPD.

¿Podemos controlar las decisiones individuales automatizadas de los contratos inteligentes?

Debido al tipo de cadena, es probable. Pero debería verse el caso particular.

¿Hay transferencias internacionales de datos?

Es posible, pero deberían ser manejables con cláusulas contractuales tipo, códigos de conducta, certificaciones o normas corporativas vinculantes.

Una cadena de bloques pública con permisos: los usuarios que realizan transacciones son conocidos

BLOCKCHAIN PÚBLICA SIN PERMISOS

¿Quién es el probable responsable?

Difícil determinarlo. Se descarta en principio que sean los nodos (se trate de los de participación o validación), más si son entendidos como simple infraestructura de la cadena (tipo router de Internet). Tampoco lo serían los desarrolladores de la cadena. En todo caso, los servicios que funcionen sobre la misma sí podrían serlo (en su relación particular). La diferencia entre actividad personal o profesional, en el caso de los participantes, podría determinar su vinculación y consideración como responsable. Tampoco se descarta que unas “normas vinculantes de la cadena” facilitaran la creación de cierta corresponsabilidad entre todos los participantes. Al menos a efectos de facilitar cierto ejercicio de derechos. De la misma forma, tampoco debe descartarse la idea de que el interesado que realiza una transacción pudiera ser responsable de sus propios datos.

¿Quiénes son los probables encargados?

Los servicios o aplicaciones que operen sobre la cadena podrían llegar a serlo en determinadas circunstancias. En el resto de casos es difícil determinarlo y dependería mucho del caso particular.

¿Subimos datos a la cadena?

Si aplicamos el diseño desde la privacidad, mejor que no. Si no queda más remedio, valorar mucho el caso y la técnica aplicada para el cifrado. De todos modos, priorizar subir datos off-chain.

¿Se pueden ejercer todos los derechos?

No, no todos. Las propiedades de la cadena condicionan sin duda el ejercicio del derecho de supresión, rectificación, acceso, oposición y limitación del tratamiento. El más sencillo de ejercer sería el de portabilidad. En este caso los forks también podrían ser una alternativa, pero no podrían imponerse. Valorar muy detenidamente todas las opciones sobre la anonimización de la información y el ejercicio de derechos.

¿Podemos controlar las decisiones individuales automatizadas de los contratos inteligentes?

Debido al tipo de cadena, se presenta difícil por lo indicado en el apartado correspondiente. En todo caso, dependería también del diseño del smart contract en sí.

¿Hay transferencias internacionales de datos?

Sin duda, ilimitadas e incontrolables seguramente. Lo que nos lleva de nuevo a la privacidad desde el diseño y almacenar datos fuera de la cadena.

Una cadena de bloques pública y sin permisos: cualquiera puede enviar una transacción

5.- Conclusiones

Visto lo anterior, parece quedar claro que cuanto más nos alejamos del blockchain y sus propiedades (transparencia, inmutabilidad, descentralización y desintermediación), más fácil es hacer respirable la convivencia entre la cadena de bloques y el RGPD. Ahora bien, cuando abrazamos con todo su esplendor a blockchain y su tecnología, los roces entre la fuerza irresistible y el objeto inamovible sin duda saltan a la vista. Así las cosas, ¿qué hacemos? Lo primero será ir viendo cómo estas tensiones comentadas van siendo resueltas por el EDPB, los tribunales, entidades gubernamentales y legisladores. Ahora bien, no podemos decir que blockchain y RGPD sean incompatibles e irreconciliables. Pero sí que la convivencia entre uno y otro debe ser medida caso a caso y con mucha paciencia. Especialmente en estos primeros tiempos. De todos modos, y para proyectos actuales, será bueno tener en cuenta una serie de pautas básicas: 1.- ¿Realmente necesitamos blockchain? Responder bien esta primera pregunta puede resolver multitud de dolores de cabeza. Si la respuesta fuera sí, el proyecto necesita valorar qué tipo de datos se necesitan, quién puede consultarlos, con qué finalidad se trataran, sobre qué base legal o durante cuánto tiempo. Si podemos dar respuesta a esas preguntas sobre el papel, y teniendo en cuenta la privacidad desde el diseño y por defecto del RGPD, entonces quizá nos podamos plantear la viabilidad de utilizar la tecnología blockchain para el tratamiento de los datos.

¿Seguro que necesitas blockchain?

2.- ¿Realmente necesitamos almacenar datos personales en blockchain? Si la respuesta fuera afirmativa, debemos comenzar a pensar en las muchas técnicas comentadas a lo largo del artículo que pueden facilitar subir el dato a la cadena, o todavía mejor, mantenerlo fuera. Por ejemplo, imaginemos una blockchain pública con permisos creada con la finalidad de ayudar a los solicitantes de empleo a proporcionar una prueba de su formación académica e informes escolares a posibles empresarios. Ya que su informe escolar contiene datos personales, no se puede almacenar en la cadena de bloques, ni con criptografía reversible. En su lugar, la plataforma podría usar técnicas de hash y agregación para generar una firma digital, de un solo uso, de su informe escolar y almacenar esa firma en la cadena de bloques, junto con una marca de tiempo y la firma criptográfica de la institución que generó el informe. Posteriormente, como solicitante de empleo, mostrará el informe de la escuela al empresario, completamente fuera de la cadena de bloques. Él, a su vez, podrá confirmar que el informe es genuino al ubicar la firma y su marca de tiempo en la blockchain. Ése sería un ejemplo muy concreto, pero es que en este entorno sí o sí hace falta ir al caso por caso y sus detalles. 3.- Ser lo más claro y transparente posible con los usuarios y seguir innovando. Si al final se va a usar blockchain, no debe olvidarse lo importante que resulta el deber información en favor de los interesados. Por ejemplo para que sepan qué está sucediendo con sus datos. 4.- La comunidad (tecnológica y legal) seguirá innovando. Hay muchos desarrolladores trabajando en técnicas y mejoras que, entre otras, permitan que los datos se eliminen de blockchain cuando ya no sean necesarios. Este trabajo generalmente se realiza con la idea de mejorar el rendimiento al reducir el tamaño de la cadena, pero las llamadas técnicas de poda también podrían emplearse teóricamente para cumplir con el RGPD. Por no hablar de los avances en criptografía, algunos ya mencionados, pero que van todavía más allá de lo comentado. Por ejemplo, algunos proyectos están explorando el uso de los llamados hashes de camaleón. En ese caso, el hash contiene una trampilla que permite suprimir los datos. Si un bloque asociado con el hash necesita ser cambiado, esta trampilla puede ser usada para abrir ese bloque, hacer los cambios y regenerarlo. Aunque esta funcionalidad no se puede agregar de forma retroactiva, esta técnica podría ser útil en casos de uso específicos. Cientos de desarrolladores de todo el mundo están trabajando actualmente en estas técnicas y en otras por lo que podemos tener la esperanza de que los estándares aceptados y las mejores prácticas surgirán dentro de los próximos años. Por tanto, sí, el RGPD quizá sea una fuerza irresistible, al igual que blockchain (en su estado más puro) se acerca al mítico objeto inamovible. Y si bien su convivencia sea hoy compleja, el futuro de ambos parece muy prometedor. De modo que parecen estar destinados a entenderse. En verdad, ya la solución a la propia paradoja vaticina lo que va a ocurrir: que ambos elementos seguirán existiendo. Al fin y al cabo, toda fuerza imparable es también un objeto inamovible.

La entrada La fuerza imparable (RGPD) contra el objeto inamovible (Blockchain) se publicó primero en Términos y Condiciones.

Cómo gestionan tus datos personales los exchanges de criptomonedas

Jorge Morell Ramos — Tue, 02 Jan 2018 08:18:08 +0000

Síguenos en |

Blockchain fue una las tecnologías estrella del 2017 y sin duda lo será este año. De hecho, el fenómeno de bitcoin llegó incluso hasta las cenas de Navidad. Por tanto, parece que el intercambio de criptomonedas estará a la orden del día en 2018. Lo que nos lleva al mundo de los exchanges.

Para la compraventa de esas nuevas “monedas digitales” se utilizan plataformas de intermediación denominadas “exchanges”. Muchas de ellas son entidades financieras reguladas y por ello requieren verificar la identidad del usuario que crea una cuenta. Especialmente si para realizar las primeras operaciones mediante criptomonedas se usa dinero fiat como puedan ser los euros.

Con ello se intenta evitar que estas plataformas se usen para el blanqueo de capitales y cumplir de esa forma con la normativa aplicable. Pero sea como sea, uno acaba proporcionando a los exchanges una muy considerable cantidad de información personal.

Por tanto, parece buena idea echarle un ojo a las políticas de privacidad de las principales plataformas de intermediación para comprar y vender el nuevo dinero digital. Al menos, para hacerse una pequeña idea de lo que pueden hacer los exchanges con esa información personal.

Creado por: designwebjae

Dicho esto, vamos allá:

Coinbase

Recopila información automatizada como la IP, el sistema operativo, operador de móvil e información de navegación relacionada. A su vez, cuando creas cuenta recopila tu nombre, email, dirección, cuenta de Skype, teléfono e información bancaria. Si realizas operaciones con criptomonedas puede obtener tu fecha de nacimiento, identificador fiscal o documentación nacional tipo DNI. Además, complementa esos datos con información crediticia de terceros o servicios para verificar tu identidad.

Si vinculas tus perfiles de Facebook o Twitter a tu cuenta también obtiene la información relacionada. Y curiosamente dice que no almacena la información personal de menores de 13 años (parece que si eres mayor de 13 no habría inconveniente :p). Sea como sea, almacena esa información un mínimo de 5 años.

La información será usada para: prestar el servicio, verificar tu identidad, resolver disputas, detectar fraude o prevenirlo, personalizar el servicio y dirigirte publicidad.

Los usuarios europeos consienten que su información personal sea transferida a Estados Unidos y analizada allí para verificar su identidad y prevenir fraudes.

Más información en su Política de Privacidad.

Kraken

Recoge información automatizada como la IP, sistema operativo, operador de móvil e información de navegación relacionada. A su vez, cuando creas cuenta, recopila tu nombre, e-mail, dirección, teléfono, género, ocupación e información bancaria. Si realizas operaciones con criptomonedas puede obtener tu fecha de nacimiento, identificador fiscal o documentación nacional tipo DNI. Además, complementa esos datos con información crediticia de terceros o servicios para verificar tu identidad.

Si lo consientes, pueden recopilar la geolocalización exacta de cuando usas el servicio. No se indica el tiempo que almacena los datos

La información será usada para: prestar el servicio, verificar tu identidad, resolver disputas, detectar fraude o prevenirlo, personalizar el servicio, combinar tu información con la de terceros para “entender mejor tus necesidades” y dirigirte publicidad.

Los usuarios europeos consienten que su información personal sea transferida a Estados Unidos y analizada allí para verificar su identidad y prevenir fraudes. Y todavía bajo Safe Harbor. :p

Más información en su Política de Privacidad.

Bitfinex

Recopila información como la IP, sistema operativo, operador de móvil y múltiple información de navegación relacionada. A su vez, cuando creas una cuenta recopila tu nombre, e-mail, dirección, teléfono e información bancaria, entre otra. Si realizas operaciones con criptomonedas puede obtener tu fecha de nacimiento, identificador fiscal o documentación nacional tipo DNI. En circunstancias excepcionales, puede recopilar, usar o compartir información personal sin nuestro consentimiento (no se dan mayores detalles).

Si se usa Tor o cualquier otro sistema de proxy para conectarse al servicio de forma anónima, puede bloquearse el acceso al usuario. No se indica el tiempo que almacena los datos.

La información será usada para: prestar el servicio, verificar tu identidad, resolver disputas, detectar fraude o prevenirlo, personalizar el servicio, gestionar pagos, realizar encuestas y dirigirte publicidad.

Consientes que la información personal pueda ser transferida a países extranjeros con menor nivel de protección. En todo caso, para ejercer nuestros derechos debemos contactar con la central en China.

Más información en su Política de Privacidad.

Binance

Procesa información como la IP, el sistema operativo, idioma, fecha, hora, software y hardware usado y múltiple información de navegación relacionada. Si bien no lo indica expresamente, lo lógico es que también recopile tu nombre, e-mail, dirección, teléfono, operaciones de compra y venta, datos identificativos e información bancaria, entre otra.

No se indica el tiempo que almacena los datos y muy genéricamente se detallan algunos de los usos que se harán de los mismos.

Dice que los datos pueden ser transferidos a cualquier servidor operado por Binance sin tener en cuenta la jurisdicción. En teoría están en localizados en Hong Kong y operan desde Japón y Corea del Sur, pero la verdad es que no queda nada claro mediante la información de la web dónde están ubicados.

Más información en su Política de Privacidad.

Coinmama

Recopila información automatizada como la IP, sistema operativo, país, idioma, enlaces de entrada y salida, la derivada de cookies e información de navegación relacionada. Al crear una cuenta recopila datos como nombre, foto de perfil, documento nacional de identidad, email, fecha de nacimiento o tu información bancaria.

Sí indica que almacena los datos un mínimo de 5 años, de acuerdo a las obligaciones legales pertinentes.

La información será usada para: prestar el servicio, personalizar la experiencia, analizar el uso de la web, mejorar la atención al cliente, verificar tu identidad, enviar emails relacionados sobre el servicio, tus operaciones o productos relacionados y realizar promociones/encuestas.

Nada dice sobre dónde almacena la información personal ni a los países a los que podría transferirse.

Más información en su Política de Privacidad.

Gemini

Señala que de acuerdo a la sección 326 de la Patriot Act norteamericana debe recopilar y verificar la información de cada usuario que abra una cuenta. Por ello puede llegar a recoger datos como el nombre completo, email, teléfono, fecha de nacimiento, documento de identidad nacional, dirección, información financiera y cualquier otro dato requerido por su equipo de compliance. Sin olvidar información generada automáticamente a nivel de geolocalización, dispositivo usado y usos del servicio.

Es la única de las analizadas que expresamente indica que para usar el servicio debes ser mayor de 18 años (las otras lo hacen normalmente en las Condiciones del Servicio, pero tampoco me parece mala idea hacer la mención en la Política de Privacidad).

La información será usada para: dar el servicio y prestar ayuda cuando sea necesario, optimizar el servicio, realizar tareas para la detección y prevención de fraudes (incluyendo a terceros con las que se compartan los datos), marketing o crear informes agregados y anonimizados.

Señalan que las transacciones en blockchain no son completamente anónimas al usar bitcoin o ether, por ejemplo. Por tanto es posible que se pueda hacer un match entre la dirección pública del usuario y otros datos suyos. En todo caso, no dicen dónde y por cuánto tiempo almacenan la información personal (más allá de un genérico “hasta que cierres tu cuenta”).

Más información en su Política de Privacidad.

Conclusión

Resulta un poco decepcionante cómo informan los exchanges sobre la gestión de la información personal, más teniendo en cuenta lo mucho que pueden llegar a recopilar.

Todos los textos en inglés, no muy actualizados, poco precisos y genéricos, no es fácil saber dónde están los servicios a efectos de ejercer derechos y es muy habitual la transferencia internacional de datos (normalmente a EE.UU., China o lugar cercano).

Gemini sería el mejor, se nota que es un exchange muy nuevo y con textos legales pensados para el servicio en sí. Mientras que Binance sería el peor con diferencia, muy genérico y casi imposible localizar su ubicación real.

Habrá que seguir de cerca este fenómeno de los exchanges y su privacidad, ya que sin duda las criptomonedas y su intercambio será uno de los temas de 2018.

¡Feliz cripto año!

—–

Seguir a @jorge_morell

La entrada Cómo gestionan tus datos personales los exchanges de criptomonedas se publicó primero en Términos y Condiciones.

Cómo crear un smart contract mediante términos y condiciones

Jorge Morell Ramos — Wed, 21 Sep 2016 12:04:29 +0000

Síguenos en |

Smart Contracts: teoría, práctica y cuestiones legales

Los smart contracts o contratos inteligentes son quizá uno de los términos más de moda en las nuevas vertientes tecnológicas de sectores tan diversos como Legaltech, del que ya hablamos largo y tendido, Fintech (proyectos relacionados con la “nueva” industria financiera) o Insurtech (proyectos relacionados con el “nuevo” sector de los seguros).

Pero, ¿por qué la tendencia de los smart contracts es capaz de unir a sectores tan diversos? A mi parecer, por verlo como el instrumento legal que si llega a convertirse en algo común, puede seriamente alterar el día a día de las transacciones comerciales. Es decir, dado que el contrato inteligente consiste en software, muchas de las ventajas asociadas al mismo como son su rapidez, predecibilidad y automatización, podrían acabar llegando a estas áreas a gran escala.

Ahora bien, si los contratos inteligentes son el elemento legal que une a industrias tan variadas, el elemento tecnológico que permite los actuales smart contracts, y une a todavía más sectores, sería blockchain o la cadena de bloques. Es decir, la tecnología bajo la que funcionan monedas como bitcoin o ether. De hecho, en algunos ámbitos se está empezando a considerar a blockchain como uno de los desarrollos más revolucionarios de Internet.

En resumen, de esta algo críptica introducción, debemos quedarnos con 2 términos alrededor de los cuales hablaremos en este largo post y sus bloques teórico, práctico y legal. Para ello veremos la mucha teoría relacionada con los contratos inteligentes, cómo hacer uno (incluso mortales como nosotros :p) y finalmente los aspectos legales más a destacar. No va a ser un viaje breve, y aunque he intentado simplificarlo al máximo (eliminando incluso términos importantes para facilitar la comprensión de lo básico), tampoco será sencillo. Pero vamos allá.

Comencemos con lo dicho, pues. Dos términos son los que nos interesa memorizar y alrededor de los que gira toda esta historia. Hablamos de Smart Contract y Blockchain.

“A gentle introduction to smart contracts”, por Marcus Swanepoel

1.- Vayamos al origen, ¿qué es un smart contract?

Un smart contract o contrato inteligente se refiere al uso de código informático para articular, verificar y ejecutar un acuerdo entre las partes. Mientras que un contrato habitual está redactado mediante lenguaje natural, los términos de un contrato inteligente se expresan en código informático, como si de un script se tratara. De ahí que digamos que es software.

El smart contract es luego ejecutado por un ordenador, de acuerdo a los términos e inputs establecidos en el mismo. De esa forma, el contrato inteligente hace cumplir sus propios términos. Eso significa que un contrato inteligente estará habitualmente lleno de instrucciones y condiciones propias del código informático. Esas instrucciones seguirán el patrón típico de: “Si esto ocurre, haz eso. Pero si no ocurre, haz esto otro”.

Luego, una vez iniciada la ejecución del contrato, las partes dejan de tener control sobre su cumplimiento (pero más sobre esto en el tercer bloque).

Por tanto, un contrato inteligente es un programa informático con instrucciones condicionales que uno (o múltiples) ordenadores verifican y ejecutan para asegurar su fiabilidad.

Suena novedoso y futurista, ¿verdad? Sin embargo, y como en tantas otras ocasiones, el smart contract no es un concepto nuevo.

El término en sí fue acuñado por el jurista y criptógrafo húngaro Nick Szabo a principios de los años 90. Si bien ya había hablado de ellos antes (en 1996 en Smart Contracts: Building Blocks for Digital Markets y no mucho más tarde en Formalizing and Securing Relationships on Public Networks), para muchos es un breve paper escrito en 1997, y denominado The Idea of Smart Contracts, el que da comienzo a todo.

Allí Szabo comienza hablando sobre cómo la formalización de nuestras relaciones mediante contratos proporciona el marco adecuado para un nivel de seguridad ideal.

Para Szabo la máquina expendedora de refrescos es seguramente el contrato inteligente original: un dispositivo diseñado para trasmitir la propiedad de un bien (el refresco) a cambio del input adecuado (las monedas). Como la máquina controla el bien, al estar asegurado en su interior, es capaz de hacer cumplir los términos del contrato.

Sin embargo, Szabo argumenta que su idea de smart contract va más allá de la máquina de refrescos. Para él sería posible incrustar un contrato en cualquier objeto de valor que sea controlado por medios digitales. “Propiedad inteligente” la llega a denominar en su glosario. En cualquier caso, el punto de partida es siempre un sistema de seguridad maduro para el bien/servicio a proteger. Luego, el continuo refinamiento de ese sistema de seguridad lo acabará aproximando a la lógica propia de los contratos (menciona un ejemplo muy bueno sobre vehículos). Y en ese refinamiento basado en la seguridad criptográfica del bien a proteger, es donde nace el contrato inteligente.

“Nick Szabo: Block Size Increase a ‘Huge Security Risk’ “, por The Cointelegraph

1.1.- Por tanto, ¿qué podría hacer alguien con un smart contract?

Ahora ya sabemos que hoy en día un contrato inteligente es un contrato que se auto-ejecuta de acuerdo a lo que las partes han establecido en su código. Que sus términos están escritos en un lenguaje que puede ser interpretado y ejecutado por un ordenador. Y que ese ordenador adopta la figura de algo así como un administrador y ejecutor del contrato.

¿Qué podríamos hacer de acuerdo a esa definición? Pues el cielo es el límite, a decir verdad. En teoría, podría programarse:

1) Poner en marcha una opción de compra de acciones a un precio fijo durante un periodo de tiempo concreto, con el simple envío de un mensaje.

2) Se podría verificar y pagar una apuesta deportiva una vez que se comprueba automáticamente el resultado en Internet.

3) Se podría comprobar el inicio y finalización de un periodo de desistimiento en una compra online, a partir del tracking del pedido.

4) Verificar las votaciones en una encuesta sobre si Juego de Tronos es mejor que Star Wars. :p

Y así hasta el infinito.

Como puede apreciarse, una gran particularidad de los contratos inteligentes es que la necesidad de intermediarios humanos de confianza desaparece por completo. No por ser la intermediación innecesaria, sino ya que su papel lo adopta el ordenador que verifica y ejecuta el código.

Todo ello suena atractivo, en verdad. Ahora bien, si el concepto tiene casi 20 años y el potencial es tan enorme, ¿cómo es que hasta hace muy poco nadie hablaba de smart contracts?

La verdad es que hasta desarrollos muy recientes, los smart contracts han sido mayormente una hermosa teoría. Si bien hay ejemplos de contratos inteligentes entre nosotros, los sistemas de DRM o Digital Rights Management para gestionar licencias sobre contenido digital son uno de los más visibles, llevarlos a la práctica tal y como hemos comentado era misión casi imposible.

Resulta que los contratos inteligentes han estado sujetos a 3 importantes limitaciones desde su concepción:

A) Para empezar, ¿cómo podía controlar el smart contract los activos reales a efectos de hacer cumplir el acuerdo? La máquina de refrescos tiene control físico sobre el bien ya que está sellado en su interior. ¿Pero cómo podría hacer el código informático lo mismo sobre activos como el dinero o acciones?

B) El dinero en su formato digital, al igual que las reservas de los bancos, está sujeto a una estricta regulación, del mismo modo que su uso por particulares. ¿Cómo realizar pues contratos que incluyan transacciones económicas? Que además son las más habituales con diferencia.

C) Por último, ¿qué ordenador obtendría el voto de confianza suficiente como para ejecutar los términos del acuerdo? Debería ser un ordenador en el que ambas partes pudieran confiar. Es decir, las partes no solo deben estar de acuerdo en el código de los términos, sino en el ordenador que lo interpretará y lo ejecutará. Además, el ordenador debería ser verificable por las partes para evitar el engaño, manipulación o acceso no autorizado.

Esas limitaciones han hecho que durante todos estos años se haya hecho muy poquito con smart contracts. Pero, ¿y entonces?

1.2.- Entonces llegó Bitcoin (y con él, Blockchain)

El asunto de los contratos inteligentes da un gran vuelco con la llegada de Bitcoin por allá un 3 de enero de 2009 (aunque no se apreciarán sus implicaciones hasta años después).

Simplificadamente, Bitcoin es un sistema de pago y un activo o moneda digital (ya sé que hay debate sobre si es moneda o no, pero para facilitar el tema la denominaremos así), inventado por el misterioso Satoshi Nakamoto (para los fans de las conspiraciones, hay teorías sobre que Nick Szabo es en realidad Nakamoto).

El usuario de Bitcoin dispone de un monedero personal, lo que le permite enviar y recibir bitcoins con él. Lo que hace que para la mayoría de usuarios Bitcoin sea igual a “Dinero de Internet”.

Sin embargo, lo verdaderamente interesante para los contratos inteligentes, y quizá la verdadera revolución, es la tecnología que permite la existencia de Bitcoin.

En ese sentido, Bitcoin como sistema de pago descentralizado permite transacciones que ocurren directamente entre los usuarios y sin necesidad de intermediarios. Esas transacciones las verifica la propia red de ordenadores sobre la que se mueve Bitcoin y son registradas en una base de datos llamada cadena de bloques o blockchain.

He aquí nuestro segundo gran concepto.

1.3.- ¿Qué es blockchain?

“Blockchain and Smart Contracts”, por Mike Smolenski

Blockchain, o la cadena de bloques en su versión en castellano, es una base de datos autorizada y distribuida que permite “anotar” datos de todo tipo que no pueden ser revisados o alterados.

En su analogía más poética, blockchain es un libro que en principio tiene páginas infinitas y en el que puede escribirse casi cualquier cosa (desde una canción a un programa informático). Ahora bien, lo escrito no puede modificarse aunque sí consultarse en cualquier momento. De hecho, está accesible a todo el mundo. Y en verdad, que haya millones de ojos observando lo escrito en el libro, es lo que hace materialmente imposible que lo escrito pueda manipularse.

En plan un poco más técnico ahora.

La particularidad de esa base de datos que es blockchain es la forma en la que se mantiene y actualiza, ya que ello le otorga un alto nivel de confianza. Como blockchain no está controlado por una persona, entidad u organización, no hay nadie que tenga control final sobre la misma y su contenido.

La pregunta lógica es, ¿quién mantiene, actualiza y asegura blockchain, pues? Todos los ordenadores que forman parte de la cadena (que pueden ser unos cientos o millones).

De ese modo, cada ordenador que integra blockchain mantiene siempre una copia de todas las “anotaciones” realizadas. Cada copia se mantiene sincronizada con las restantes. En caso de discrepancia entre las copias existentes, por consenso matemático se da mayor puntuación a la versión más común. Entonces, esa copia será la compartida entre la red de ordenadores y en la que se seguirá “anotando”.

O lo que es lo mismo, para alterar con éxito una blockchain se debería atacar y modificar simultáneamente el 51% de la misma (para que así el consenso matemático diera prioridad a la base de datos más común, que en este caso sería la alterada). Sin embargo, eso es algo materialmente imposible en las blockchain sobre las que funcionan monedas como bitcoin o ether, dado su tamaño.

Por otro lado, como blockchain se constituye como una base de datos “append-only” (es decir, que solo permite escribir y recuperar datos antiguos, pero no borrar o modificar los datos), nunca puede eliminarse lo allí escrito. Además, como cada anotación en la cadena se asegura con un proceso criptográfico, la propia cadena puede así detectar y rechazar cualquier intento de distribuir una copia alterada de las transacciones registradas.

Por lo tanto, el carácter constantemente sincronizado, distribuido y autorizado de blockchain garantizan que únicamente exista 1 registro de las transacciones anotadas. Eso por ejemplo evita que una persona pueda gastar 1 mismo bitcoin en múltiples transacciones a la vez. Solventando así el llamado “Problema del Doble Gasto” en sistemas con monedas digitales.

Por si fuera poco, las blockchain sobre las que funcionan monedas como bitcoin o ether son públicas, pudiendo uno ver (con matices) todas las transacciones que se han realizado. A lo que debemos sumar que la tecnología es código abierto, lo que facilita saber qué hace o no el software en todo momento. Es decir, máxima transparencia.

Todo ello es lo que convierte a blockchain en una tecnología tan interesante, ya que proporciona un sistema para crear bases de datos cuyas anotaciones serán altamente fiables, al ser tan improbable su manipulación. Anotaciones que pueden ir del simple texto a código informático (código que puede ejecutar la propia blockchain).

Como cierre de este punto, una reciente TED Talk muy interesante sobre blockchain y su gran potencial:

1.4.- Pero, ¿cómo afecta blockchain a los contratos inteligentes?

El paciente lector que haya llegado hasta aquí (¡casi la mitad del post!), dirá: “Todo esto está muy bien y tengo el cerebro medio frito, ¿pero cómo encaja con los smart contracts?” Buena pregunta.

Ahora ya sabemos que blockchain es una tecnología. Eso significa que no hay una única cadena de bloques. De hecho, puede haber infinitas (si alguien quiere crear la suya propia, puede recurrir a servicios como Chain o Slock.it).

Usando la tecnología de blockchain pueden crearse sistemas de pagos (y sus correspondientes monedas) como Bitcoin, Ethereum o Ripple, seguramente las tres más populares. Pero no es imprescindible.

De hecho, ni tan siquiera el carácter público, auditable y 100% distribuido de blockchain es imprescindible. Es decir, el sector financiero está trabajando en blockchains privadas y semi-controladas (lo que hace que se cuestione si esos proyectos usan en realidad la cadena de bloques). Además, se trabaja en side-chains (en Bitcoin), que serían como cadenas laterales a la principal que permitirán innovar sin necesidad de empezar desde cero y pudiendo nutrirse de la cadena principal (para contratos inteligentes es probable que sean útiles).

Dicho esto, de las 3 cadenas de bloques más populares, Ethereum sea seguramente la más pensada para contratos inteligentes. Es decir, si bien la blockchain sobre la que se sostiene Bitcoin permite realizar smart contracts, el proceso allí es más complejo.

Y fue esa complejidad de la cadena de Bitcoin la que hizo que en 2013 el desarrollador y criptógrafo ruso Vitalik Buterin propusiera la creación de una cadena de bloques alternativa a Bitcoin. Una mucho más pensada para el desarrollo de aplicaciones como por ej. los contratos inteligentes. Nace así Ethereum y la actual fiebre por los smart contracts.

Pero volviendo al nexo entre smart contracts y blockchain, hemos comentado que el concepto de smart contract tiene casi dos décadas y que aún así se ha utilizado escasamente debido a tres grandes limitaciones: 1) la dificultad del código informático para afectar a activos reales; 2) la estricta regulación en cuanto al movimiento de activos como el dinero y 3) la dificultad de encontrar un ordenador en el que confiar al ejecutar el contrato inteligente.

Pues bien, blockchain como tecnología resuelve por completo o en buena parte esas tres limitaciones. Ethereum, llamada por algunos como la blockchain 2.0, lo hace todavía un poco más fácil. ¿Pero cómo solventa blockchain esas limitaciones?

En cuanto al primer límite, blockchain permite la existencia de activos completamente digitales como dinero, acciones, bonos, registros y demás que puedan ser controlados por el código informático del contrato inteligente. La cadena de bloques no controla el activo propiamente, pero sí la clave criptográfica que puede asociarse al mismo. Y como esa clave no podrá alterarse, sabemos que ese bitcoin es ése y no otro. Además, la tremenda digitalización de la economía y la sociedad, junto a la llegada del Internet de las Cosas (que permite conectar a Internet hasta la mesa en la que comemos), elimina el problema incluso en relación a los objetos físicos.

En relación a la segunda limitación, obviamente la estricta regulación sobre el uso del dinero sigue existiendo. Pero blockchain ha generado la creación de nuevos sistemas de pago y monedas que en la práctica están operando al margen de cualquier regulación presente. Por tanto, al crear una carretera alternativa, se ha reducido muy considerablemente la influencia de esa regulación.

Por último, la tercera limitación también es solventada por completo gracias a la cadena de bloques. El ordenador sobre el que ejecutar el código del smart contract es la propia blockchain. Es decir, no 1 ordenador especial que puede ser hackeado, sino los cientos de miles de ordenadores sincronizados que garantizan que el contrato no podrá ser modificado y que se ejecutará cómo se le ha indicado. El consenso matemático se convierte en confianza matemática que no requiere a terceros intermediarios humanos ni a ordenadores de poco fiar.

El código (informático) se convierte en más ley que nunca.

Como curiosidad, ¿hay proyectos que ya usan blockchain en el ámbito legal? Por mencionar unos pocos: 1) Blockai y su registro de propiedad intelectual para fotógrafos/dibujantes; 2) Ujo para que los músicos puedan cobrar directamente de sus fans y resolver a la vez el tema licencias mediante contratos inteligentes; 3) NevTrace y su registro de refugiados para crisis migratorias o 4) Suecia y sus pruebas para un registro de la propiedad sobre blockchain.

Por tanto, combinar smarts contracts y blockchain es lo que puede convertir a uno en el instrumento legal del futuro, y al otro en la tecnología que puede obligar a rehacer muchos de los esquemas conocidos.

2.- ¿Qué tal si pasamos a la práctica?

“SmartContract”, potente servicio para crear contratos inteligentes mediante interfaz gráfica y sin necesidad de programar

Presentada la extensa teoría, lo interesante sería ponerse manos a la obra.

Ahora bien, si los contratos inteligentes son software, ¿hace falta saber programar para crearlos? No, pero definitivamente puede ayudar. Especialmente ahora, que todo está muy verde. Además, si uno sabe programar sus propios contratos, el nivel de control será máximo. Aunque esto puede generar problemas que luego comentaremos en el tercer bloque.

Por tanto, ¿por dónde comenzar?

Tal y como se explica en A Lawyer’s Introduction to Smart Contracts, el contrato inteligente es simplemente un componente dentro del sistema. Por tanto, el smart contract sería el componente final de la infraestructura que permite crearlos y operarlos. El módulo de esa infraestructura que permite su creación sería la Plataforma de Smart Contracts (en adelante SCP). Por otro lado, luego disponemos de un componente que puede añadirse sobre el SCP y facilitarnos mucho la vida, sería el Sistema de Gestión de Smart Contracts (en adelante SCMS).

Es decir, la plataforma de smart contracts o SCP serían por ejemplo la blockchain de Bitcoin o Ethereum. Así como cualquier otra blockchain que permita interpretar, ejecutar e incluso almacenar los contratos inteligentes creados sobre ella.

Quien quiera trabajar directamente sobre esta capa necesitará tener ciertos conocimientos de programación para crear sus smart contracts. Si quiere hacerlo sobre la blockchain de Ethereum aquí tiene un tutorial para iniciarse. Si prefiere la de Bitcoin, aquí un comienzo.

Por su parte, los SCMS son una superestructura que se sitúa encima del SCP que permiten usar los smart contracts como si fueran un servicio más. De esa forma, se podría disponer de forma gráfica y fácilmente usable de: una base de datos de los contactos que han suscrito smart contracts, de un calendario en el que programar su inicio y final, de un editor para crear borradores de los contratos o de un lugar en el que almacenarlos y comprobar su registro de actividad. Y lo dicho, todo ello con una interfaz gráfica y sin necesidad de programar.

Por tanto, mientras blockchain serían los cimientos, el SCP sería el mobiliario y el SCMS la fachada, el embaldosado y la pintura de la casa.

Si no sabemos o no queremos programar un smart contract y todos sus aspectos, lo que nos interesa es un SCMS. Ya que es lo más parecido que vamos a encontrar a un “Smart Contract as a Service”.

¿Existen muchos así? No demasiados, por ahora. Codius podría encajar pero requiere conocimientos de programación. El navegador/monedero Mist de Ethereum permite algo así pero muy simple. De los más útiles, potentes y sencillos que he visto es el que encabeza este apartado: SmartContract. Una empresa norteamericana que proporciona la opción de crear diferentes tipos de contratos inteligentes sobre las blockchain de Bitcoin y Ethereum, además de programar bonos inteligentes o la realización de pagos según la geoposición de un bien. Todo ello sin necesidad de saber programar.

Algunos de los contratos inteligentes que permite crear “SmartContract”

Si alguien quiere probar el servicio, hoy por hoy es gratuito, le recomiendo hacerlo sobre la plataforma de pruebas (que está algo más escondida que la normal). Así se puede experimentar más libremente.

¿Cuál ha sido el objetivo al crear nuestro smart contract? Experimentar con el concepto y hacerlo con un contrato inteligente no relacionado con pagos, que normalmente es el modelo más habitual. Por tanto, nuestra intención era usar únicamente el smart contract para la verificación, el intercambio y/o el suministro de información.

2.1.- Usar los cambios en términos y condiciones para crear un contrato

Hemos comentado que los contratos inteligentes son código informático basado en la idea de “Si ocurre esto, haz eso”. Por tanto, el contrato necesita una fuente externa de información para comprobar regularmente si ese algo ocurre o no. Esa fuente puede ser por ejemplo los resultados de búsqueda de Google, a través de un rango de SEO inteligente. Por ejemplo, “Cuando una web alcance la primera página de Google, realiza el pago”. Ésa es una opción proporcionada por el servicio través del contrato “Service Level”, por ejemplo.

Pero quizá las mejores fuentes externas a las que recurrir, para verificar o ejecutar un contrato inteligente, sean las basadas en formatos de texto que puedan ser interpretados fácilmente por un programa informático. Ya que así se podrá recurrir a datos mucho más precisos. Pero no nos referimos a formatos como PDF, sino a fuentes en formato Javascript JSON.

En este sentido, la información recopilada por nuestro Boletín de Términos y Condiciones respecto a todos los textos que monitoriza, se almacena en formato JSON. Eso significa que respecto a cada modificación detectada, datos como el nombre del servicio, el tipo de documento, la fecha del cambio o el porcentaje de texto alterado, se almacenan en un formato que luego puede ser leído y verificado por un programa informático. En este caso ese programa informático será nuestro smart contract.

Algunos de los datos que pueden usarse de un documento monitorizado por el Boletín de Términos y Condiciones para crear un contrato inteligente

¿Qué queremos que haga nuestro contrato inteligente? Dado que los términos y condiciones cambian muy habitualmente, y que esos cambios no siempre se comunican, planteamos un esquema en el que un servicio pueda configurar mediante contratos inteligentes su deber de información e incluso la reaceptación de las condiciones cuando éstas son modificadas. Todo ello en función del porcentaje de cambio del documento monitorizado. Lo que además de cumplir con la ley, automatizar una obligación legal y reducir costes en su cumplimiento, puede ofrecer el extra de transparencia y fiabilidad que la cadena de bloques proporciona.

O lo que es lo mismo, los términos y condiciones siempre incluyen una cláusula relativa a la eventual modificación de los textos. Esas modificaciones muchas veces son menores, pero en otras ocasiones son sustanciales y aún así no se comunican al usuario ni se requiere nuevamente el consentimiento del usuario. Parte del problema es que raramente se define el concepto “cambio sustancial”. Pues bien, nuestra propuesta/experimento es que esa cláusula se solucione mediante un smart contract.

El proceso seguido para ello, a una escala muy pequeña y experimental, ha sido el siguiente.

2.2.- ¡Creemos un contrato inteligente!

En primer lugar creamos una falsa Política de Privacidad y comenzamos a monitorizarla con el Boletín de Términos y Condiciones. En el texto de la Política, en lenguaje natural, establecemos que cuando se dé un cambio sustancial de las condiciones, avisaremos de ello mediante correo electrónico, un aviso en la web y se volverá a solicitar el consentimiento del usuario. Además, indicamos que “cambio sustancial” equivaldrá a una modificación igual o superior al 15% del texto (para hacer la prueba era la forma más objetiva de intentar valorar algo así).

A continuación, creamos un perfil de prueba en “SmartContract“, le damos a “Creat Contract”, elegimos la opción “Bitcoin Oracle” y hacemos clic en “Create Oracle”. Nos interesa esta opción por la posibilidad de establecer condiciones que evalúen si un valor sube, se mantiene o baja.

Entonces podemos comenzar a “redactar” las cláusulas inteligentes de nuestro contrato inteligente (ver imagen inferior). También deberemos luego añadir una descripción al contrato, adjuntar los archivos que deseemos (en nuestro experimento una copia completa en formato PDF de la Política de Privacidad), para finalmente firmar y enviar el contrato. En esta fase el contrato se puede ir trabajando y guardando en nuestro perfil, en plan editor.

Campos a completar en nuestra cláusula inteligente

En nuestra cláusula inteligente o smart term, vamos a elegir la opción de monitorizar comportamiento (“performance monitoring”), ya que queremos saber cuándo se producen cambios sustanciales en nuestra Política de Privacidad. Es decir, si la modificación es igual o superior al 15% del texto. Cuando eso ocurra en el periodo de tiempo establecido, además de dejar constancia en la cadena de bloques y aportar a nuestros usuarios la máxima transparencia sobre nuestra forma de actuación, podríamos vincular y automatizar ese resultado a las acciones indicadas en la cláusula escrita en la Política. Es decir, el envío de un email, el aviso en la web y la solicitud de nuevo de consentimiento. Y todo ello en función del resultado de este contrato inteligente.

Por tanto, vamos a crear dos cláusulas inteligentes. Para comenzar, en “IF the API location” colocamos la versión JSON de nuestra Política de Privacidad. Para esta primera cláusula seleccionamos la opción “HAS a value equal to 15″. A continuación, hacemos clic en “Data Path” y seleccionamos “variationPercentage” en la ventana que se mostrará con todos lo datos disponibles para ese documento. Finalmente, elegimos una fecha de expiración y añadimos un nuevo “Smart Term”. En esta segunda cláusula repetiremos el proceso anterior, pero en el segundo campo ahora debemos seleccionar “HAS a value more than 15”.

Rellenamos el campo “Description”, adjuntamos los archivos que consideremos y firmamos y enviamos el contrato a alguna alma cándida con la que hacer el experimento todavía más social (no tiene porque ser usuario del servicio). Debería mostrarse algo tal que así:

Smart contract hecho, firmado y enviado. Es tan inamovible que no puedo ni corregir el error de su título :p xD

Ahora, mientras el contrato está en progreso, simplemente es cuestión de hacer modificaciones (o no) en la fuente externa que el smart contract está regularmente monitorizando, es decir, nuestra falsa Política de Privacidad. De ese modo, añadiendo y eliminando texto del documento monitorizado podremos forzar el cumplimiento o incumplimiento de nuestro contrato inteligente.

Y con esto y un dolor de cabeza :p, tenemos un contrato inteligente.

Todo lo comentado en este segundo apartado es la versión práctica de la teoría indicada en el primer bloque. Por lo tanto, aquí hemos creado un smart contract sobre blockchain (con todas sus implicaciones). Si bien el experimento es extremadamente simple e incompleto, creo que puede ayudar a comprender el concepto de los contratos inteligentes en la realidad. A su vez, demuestra la existencia de servicios potentes y sencillos que ya permiten el uso de este nuevo instrumento legal sin necesidad de saber programar. Por tanto, algo que ya podemos usar como abogados, pero que nuestros clientes también pueden usar.

Dicho esto, ¡adelante con las pruebas! Ya que este mini experimento a duras penas rasca la cáscara.

Por cierto, si alguien quiere usar el Boletín de Términos y Condiciones como una fuente externa para sus contratos inteligentes, o incluso monitorizar un texto creado expresamente (como el usado en este ejemplo), adelante con los ya disponibles o que se ponga en contacto con nosotros para un caso especial.

Finalmente, vamos a ver algunas pinceladas legales de todo lo comentado.

3.- ¿Y de lo legal qué hay?

Llegados a este punto, deberíamos tener una pequeña idea sobre qué es un smart contract desde un punto de vista técnico, para qué puede usarse y cómo podría crearse. Ahora bien, ¿legalmente qué ocurre?

Hay ya varios buenos artículos sobre las vertientes legales de los contratos inteligentes, dos buenos ejemplos son el ya citado a A Lawyer’s Introduction to Smart Contracts o Smart contracts: aproximación al concepto y problemática legal básica. Por tanto, como esto ya está quedando muy largo :p, simplemente haré una reseña de algunas problemáticas que me parecen llamativas, con fuentes de consulta extra.

Vamos allá:

1.- Si bien es habitual oír hablar de contratos inteligentes como instrumentos que no son ni contratos ni inteligentes, la verdad es que pueden perfectamente bien acoger todos los elementos propios de un contrato y llegar a “pensar” por sí mismos. Es cierto que muchos smart contract no son más que un simple redireccionamiento de un importe desde una cuenta a otra, sin más. Pero puede construirse un contrato inteligente puro, como algunos lo denominan, y que sea un contrato perfectamente legal, en forma y fondo. Por tanto, depende un poco del uso.

2.- Sobre su inteligencia, ciertamente la mayoría de smart contract son autómatas que bajo un principio de neutralidad absoluto simplemente hacen lo que se les indica. Pero hay desarrollos en ese ámbito que los llevarán a más. Desde la inclusión de IA en su redacción y cumplimiento a experimentos tan complejos y curiosos como los DAO u Organizaciones Autónomas Descentralizadas. ¿Qué es un DAO? Muy resumidamente, un smart contract de smart contracts. O como dicen algunos, cuando un bot dirige la empresa. Su concepción y desarrollo es muy interesante, al igual que sus defectos y consecuencias legales (el mayor DAO del mundo fue hackeado hace unos meses).

3.- Un último apunte sobre su inteligencia, me parece interesante la idea de que con el tiempo un smart contract pueda “representarme legalmente”. Es decir, un contrato inteligente puede perfectamente identificar a un usuario, controlar determinados bienes digitales del mismo y contratar o no servicios en función de las instrucciones programadas. Por tanto, es cuestión de tiempo que alguien cree su “representante digital”.

4.- La redacción, corrección e interpretación de los contratos inteligentes será una tarea más compleja, sobretodo al inicio. Para empezar, por no estar escritos en lenguaje natural. Por otro lado, al ser tan veloces y automáticos en su ejecución, será importante analizar bien su falta de errores en el código (un debug legal será necesario). Todo ello sin olvidar que quizá incluyan código de tercero desconocido o no auditado. En todo caso, los contratos de lenguaje natural no desaparecerán, simplemente convivirán unos y otros o incluso se mezclarán (nuestro ejemplo era así). Después de todo, la flexibilidad del lenguaje natural será muchas veces buscada por las partes.

5.- Que los contratos inteligentes se ejecuten y almacenen sobre una red distribuida como blockchain es un problema en materia de ley y jurisdicción aplicable (si las partes no la indican en el clausulado). Sobretodo en esos contratos en los que las partes no sean identificables e incluso se cifre el contenido del contrato. Es decir, si el contrato se verifica, ejecuta y almacena en millones de ordenadores a la vez, está en todos sitios y en ninguno simultáneamente. ¿Qué jurisdicción aplicamos si las partes no han dicho nada?

6.- Que los contratos inteligentes se almacenen en blockchain, sin posibilidad de modificación y con un nivel de transparencia máximo, puede generar problemas en materia de privacidad y confidencialidad de la información. De hecho, eso está potenciando la creación de cadenas de bloques privadas. ¿Y qué ocurrirá con el derecho al olvido en una cadena de bloques? ¿No habrá cierto choque entre lo establecido en el nuevo Reglamento Europeo de Protección de Datos y lo que permite la tecnología? Seguramente por eso se trabaja ya en blockchains (privados) editables.

7.- Lo lógico es que sistemas como el usado en el ejemplo sean la forma habitual de realizar contratos inteligentes. En ese caso, los términos y condiciones del servicio pueden ayudar en materia de legislación y jurisdicción aplicable. Por tanto, lo razonable es que esos servicios sean también el principal foco de regulación por parte de los gobiernos. Y es que no olvidemos que estos servicios tendrán acceso a miles de contratos, a la información personal y confidencial que puedan contener y se encargarán de su custodia. ¿Deberán velar por la legalidad de su objeto? ¿Impedir quizá que se cifren ante un eventual contratiempo? ¿Y hará falta algún conocimiento legal para suministrar plantillas de smart contracts? Al fin y al cabo son un programa informático que hoy por hoy crean mayormente los programadores, no los abogados, pero con una connotación legal importante. De hecho, ya hay mercados para comprar y vender smart contracts.

8.- Finalmente, servicios como el usado y otros similares tienen el potencial para propiciar que unas pocas personas afecten seriamente a grandes negocios altamente regulados, como por ejemplo las apuestas deportivas, loterías o préstamos. Es decir, si puedo hacer plantillas de smart contracts fácilmente replicables y a gran escala, es cuestión de tiempo que alguien acabe montando desde su casa una alternativa a Bet365 o cualquier otro de esos servicios. Pero obviamente sin cumplir los muchos requisitos necesarios para ese tipo de negocios.

En resumen, la parte legal de los contratos inteligentes va a presentar retos nuevos interesantes. En cualquier caso, hasta aquí llega mi primer contacto con ellos o “Los contratos inteligentes son para el verano”. :p

Para mí ha sido un buen ejercicio para aprender con cierto detalle todo lo que rodea a esta nueva área de conocimiento. A su vez, este mega este post pretende (con los tecnicismos justos) poner en orden muchas de esas ideas y que más gente pueda tener acceso al mismo. Ya que lo aquí explicado es simplemente la punta del iceberg y hay mucho por explorar.

Y si bien es cierto que el mundillo smart contract y blockchain está en fase de burbuja total, con el tiempo se relajará y las revoluciones darán paso a las aplicaciones reales. Pero es innegable que la tecnología y sus usos tienen un gran potencial que ya está presente y disponible. Incluso para simples mortales. ;D

¡Feliz contrato inteligente!
—–

Seguir a @jorge_morell

La entrada Cómo crear un smart contract mediante términos y condiciones se publicó primero en Términos y Condiciones.

How to create a smart contract using terms and conditions

Jorge Morell Ramos — Wed, 21 Sep 2016 12:04:29 +0000

Síguenos en |

Translated by: Bárbara Román Méndez

Smart Contracts: theory, practice and legals aspects

Smart contracts are probably one of the most trendy terms on the new technological initiatives developed by sectors as diverse as Legaltech, which we already covered thoroughly, Fintech (projects related to the new financial industry) or Insurtech (projects related to the new Insurance sector).

The thing is, why the concept of smart contract can join together sectors so different? My idea is that the smart contract is seen as a legal tool that if it ends up being commonly used, it could seriously alter the way we trade daily. In other words, taking into account that the smart contract is software, many of the advantages associated with it (for example, promptness, predictability and automation), could end up reaching these areas on a large scale.

However, if smart contracts are the legal instrument that joins such diverse industries, there is a technological element that allows today’s smart contracts and connects even more sectors. We are talking about blockchain. What’s that? Well, the technology under which currencies such as bitcoin or ether work nowadays. In fact, some people are starting to consider blockchain as one of the most revolutionary achievements coming from the Internet.

In summary, out of this somewhat cryptic introduction we should focus on to two terms. This long post will be all about them from a theoretical, practical and legal perspective. This way, we’ll talk about plenty of theory related to smart contracts, how to make one (even mortals such us :p) and some legal aspects worth mentioning. The trip won’t be short, and although I’ve tried to simplify the content as much as possible (getting rid of important concepts in order to get a better understanding of the basics), it won’t be easy. Having said that, let’s go!

As we said, all this story revolves around two terms that we should try to memorise. We are talking about Smart Contract and Blokchain.

“A gentle introduction to smart contracts”, by Marcus Swanepoel

1.- Back to the origin, what is a smart contract?

A smart contract is the use of computer code in order to articulate, verify and execute an agreement between parties. While a regular contract uses natural language, the terms of a smart contract use computer code, like the one from a script. That’s why we say that a smart contract is software.

Once the smart contract is written, a computer executes it according to the terms and inputs established in the contract. This way the smart contract auto-fulfills its own terms or conditions. For this reason, a smart contract will usually use instructions and conditions typical of computer code. And these instructions will follow the usual pattern of: “If this happens, do that. But if it does not happen, then do this instead”.

Then, once the execution of the contract begins, both parties lose the control over its compliance (we’ll come back to this when talking about the legal aspects).

Therefore, a smart contract is a computer program with conditional instructions that one (or more) computers verify and execute in order to assure its liability.

It sounds new and futuristic, doesn’t it? However, as in so many other instances, the smart contract is not a new concept.

The term itself was coined by the Hungarian jurist and cryptographer Nick Szabo during the 90’s. Even though he had already talked about them earlier (in 1996 on Smart Contracts: Building Blocks for Digital Markets and shortly after that in Formalizing and Securing Relationships on Public Networks), a brief paper written in 1997 and called The Idea of Smart Contracts is considered as the stepping stone on the concept of smart contracts.

On this paper, Szabo starts talking about how when we formalise our relationships through contracts, we establish the appropriate setting for an ideal level of security.

According to Szabo, the vending machine is probably the original smart contract: a device designed to transmit the property of a good (the can) in exchange for the appropriate input (the coins). Taking into account that the machine controls the goods, because they are sealed inside, the device is capable to enforce the terms of the contract.

Nevertheless, Szabo states that his idea of smart contract goes beyond the vending machine. According to him, it would be possible to embed the contract into any valuable object that is digitally controlled. He even calls it “Smart property” on his glossary. In any case, the starting point is always a mature security system that is required to protect the good or the service. Then, the continuous refinement of the safety system will bring it closer to the typical logic of the contracts (he gives a very good example about vehicles). Finally, during this refinement process based on the cryptographic security of the good is where the smart contract will be born.

“Nick Szabo: Block Size Increase a ‘Huge Security Risk’ “, by The Cointelegraph

1.1.- Therefore, what could you do with a smart contract?

Now we know that nowadays a smart contract is a contract that self-executes according to what both parties agreed on within the code; that its terms are written in a language that can be interpreted and executed by a computer; and also that such computer becomes the administrator and executor of that contract.

According to that definition, what could we do? There are no limits to it, to be honest. Theoretically, it could be programmed in order to:

1) Start up an option to purchase shares at a fixed price during a specific period of time just by just sending a message.

2) Verify and pay sports betting once checked the result in internet.

3) Check the beginning and end of a waiver period when shopping online, following the tracking of an order.

4) Verify the votes on a survey to find out if Game of Thrones is better than Star Wars? :p

And so on.

As we can observe, a distinctive feature of smart contracts is that the need for reliable human intermediaries is completely gone. Not because the mediation is unnecessary but because its role is taken by the computer that verifies and executes the code.

All this sounds really attractive. However, if the concept is almost 20 years old and its potential is so big, how is that no one has talked about smart contracts until recently?

The truth is that until recent achievements, smart contracts have mostly been great in theory. Even though we do have some examples of smart contracts, the DRM systems or Digital Rights Management necessary to manage licenses on digital content are among the most visible systems and as we mentioned earlier putting those into practice was almost impossible.

Smart contracts have been subject to 3 important limitations since their origin.

A) To begin with, how could the smart contract control the real assets in order to make someone fulfill the agreement? The soda vending machine has a physical control over the good since it is locked inside the machine itself. But how could the computer code do the same to control assets such as money or shares?

B) The money in its digital format, the same as the money reserves banks have, is subject to a very strict regulation, just like its use by people in general. Then how to make contracts that include economic transactions? Which by the way, are the most common used ones by far.

C) Last, which computer would receive a vote of confidence so as to execute the terms of the agreement? It should be a computer in which both parties could place their trust in. That is to say, the parties should not only agree on the term code, but also on the computer that will interpret and execute it. Besides, the computer should be verifiable by the parties in order to avoid fraud, manipulation or unauthorized access.

It is due to these limitations that very little has been done with smart contracts during the last few years. But, then?

1.2.- Then Bitcoin arrived llegó Bitcoin (and Blockchain with it)

The issue about smart contracts had a big turnaround with the arrival of Bitcoin on January 3, 2009 (even though its real significance will be fully valued years after).

To somewhat simplify, Bitcoin is a payment system and digital money or assets (I know there is some argument whether it is currency or not, but to make things easier will called like this, invented by the mysterious Satoshi Nakamoto (for those who love conspiracies, there are theories stating that Nick Szabo is actually Nakamoto).

The user of Bitcoin has a personal wallet, which allows him/her to send and receive bitcoins. All this makes most users believe that Bitcoin is the same as “Internet Money”.

Nevertheless, what is really interesting for smart contracts, and probably the true revolution, is the technology that makes Bitcoin possible.

In this sense, Bitcoin as a decentralized payment system allows transactions that take place among users without a need for intermediaries. Those transactions are verified by the network itself where Bitcoin moves and are registered in a database called blockchain.

Here is our second big concept.

1.3.- What is blockchain?

“Blockchain and Smart Contracts”, by Mike Smolenski

Blockchain, or the chain of blocks in its Spanish version, is an authorized and distributed database which allows appending all kind of data that can´t be reviewed or altered later on.

In its most poetic analogy, blockchain is a book with essentially endless pages and in which almost anything can be written (from a song to a computer program). However, whatever is written can´t be modified, although it can be looked up at any time. In fact, it is accessible to everyone. And indeed, the fact that there are millions of eyes observing what has been written in the book, almost makes it materially impossible for anybody to manipulate whatever is written.

Getting a bit more technical now.

What is particular to this database called blockchain is the way it is kept and updated, as this grants it a high level of trust. Since blockchain is not controlled by one single person, entity or organization, there is no one that has final control over it and its content.

So, the logical thing to ask is: Who maintains, updates and ensures blockchain then? All computers that are part of the chain (which can be up to hundreds or millions)

That way, each computer that is part of the blockchain always keeps a copy of all the annotations made. Each copy is maintained synchronized with the other copies. In case of discrepancy between the existing copies, the most common version is given the highest score by mathematical consensus . Then, that copy will be the one shared within the computer network and where additional annotations will be entered.

Or in other words, in order to successfully alter a blockchain 51% of it should be attacked and modified simultaneously (so that the mathematical consensus gives priority to the most common database, which in this case would be the altered one). However, this is something materially impossible for blockchains on which cryptocurrencies such as bitcoin or ether run, given their size.

On the other hand, as blockchain is constituted as an append-only database (t. i., it allows only to write and retrieve old data, but not to delete or alter any of them), whatever has been written there can never be deleted. In addition, since each annotation in the chain is secured by a cryptographic process, the chain itself is able to thus detect and reject any attempt to distribute an altered copy of the registered transactions.

Therefore, the constantly synchronized, distributed and authorized character of blockchain guarantees that there is only one record of the annotated transactions. That for example prevents a person from spending the same bitcoin in various transactions at the same time, and thus solving the so-called double-spending problem in systems with digital currencies.

As if that were not enough, those blockchains on which currencies like bitcoin or ether run are public, all transactions that have been made are visible (with nuances) to anybody. Also, we have to add that this is an open-source technology, which makes it easier to know what the software is doing or not at all times. That is, transparency at its best.

All this is what makes blockchain such an interesting technology, as it provides a system to create databases whose annotations will be highly reliable, as their manipulation is so unlikely to happen. These annotations can go from basic text to computer code (a code that the blockchain itself can execute).

As a closing point of this chapter, a very interesting and recently held TED talk on blockchain and its great potential:

1.4.- But how does blockchain affect smart contracts?

The patient reader who has reached this point, almost half of the post!, will surely say: “That’s all good and well and I have my brain half fried, but how is this all going to work with the smart contracts?” That is a good question.

By now, we already know that blockchain is a technology. That means there is not just one single chain of blocks. In fact, there can be endless chains. (if anybody wants to create his/her own one, s/he can fall back on services such as Chain or Slock.it)

By using the blockchain technology we can create payment systems (and their equivalent currencies), such as Bitcoin, Ethereum or Ripple, probably the three most popular ones. But it is not essential.

In fact, not even the public, auditable and 100% distributed characteristics of blockchain are necessary. That is, the financial sector is working on private and semi-controlled blockchains (which raises the question of whether these projects really use the chain of blocks). In addition, side-chains are also used (in Bitcoin), which are like lateral chains to the main one that allow innovation without having to start all over again and that can be nourished from the main chain (probably they are useful for smart contracts).

Having said that, out of the 3 most popular blockchains, Ethereum is probably the one that fits best for smart contracts. That is, although the blockchain on which Bitcoins sustains allows to make smart contracts, the process there is more complex.

It was that complexity of the Bitcoin chain that made that the Russian developer and cryptographer Vitalik Buterin suggested the creation of a blockchain other than Bitcoin in 2013. One that would have very much in mind the development of applications such as for instance the smart contracts. This is how Ethereum and the current enthusiasm for smart contracts originated.

But getting back to the nexus between smart contracts and blockchain, we have commented that the concept of the smart contract has existed for almost two decades now and yet has been barely used due to three major limitations: 1) the difficulty of the computer code to influence real assets; 2) the strict regulation concerning the movement of assets such as money and 3) the difficulty to find a trustworthy computer when executing the smart contract.

Well, blockchain as a technology solves completely or for the most part these three limitations. Ethereum, also referred to by some people as the blockkchain 2.0, makes this even a bit easier. But how does blockchain get around these limitations?

As far as the first limitation is concerned, blockchain allows the existence of fully digital assets, such as money, stocks, bonds, records and other that can be controlled by the smart contract computer code. The blockchain doesn´t have control over the asset itself, but over the cryptographic key that can be associated to it. And since that key cannot be altered, we know that bitcoin is that one and not another one. In addition, the huge digitalization of the economy and society, together with the arrival of the Internet of Things (which allows internet connection to the table where we eat), eliminates the problem even those related to physical objects.

As for the second limitation, obviously the strict regulation on the use of money still exists. But blockchain has generated the creation of new payment systems and currencies that in practice are operating regardless of any current regulation. Therefore, by creating an alternative road, the influence of this regulation has been considerably reduced.

Finally, the third limitation is also completely solved thanks to the blockchain. The computer on which to execute the smart contract code is the blockchain itself. That means, not just any specific computer that can be hacked, but hundreds of thousands of synchronized computers that guarantee that the contract cannot be modified and that it will be executed as instructed. The mathematical consensus becomes mathematical confidence with no need for third-party human intermediaries nor unreliable computers.

The (computer) code becomes more legal than ever.

Just as a curiosity, are there any projects already using blockchain in a legal environment? To only mention a few: 1) Blockai and its records of intellectual property for photographers and cartoonists; 2) Ujo enabling musicians to charge their fans directly and resolving at the same time the issue of licences through smart contracts; 3) NevTrace and its record of refugees for migratory crisis or 4) Sweden and their testings for a property record on blockchain.

Therefore, the combination of smart contracts and blockchain is what can make the first one the legal instrument of the future and the second one the technology that can force to redo many of the known schemes.

2.- Let’s go from theory to practice!

“Smart Contract”, powerful service in order to create smart contracts through graphic interface and without a need for programming

After presenting all the theory, it’s time to get our hands dirty.

However, if smart contracts are software, do we need to know how to program in order to create them? No we don´t, but it can definitely help. Especially now that we are still on very early stages. Besides, if one knows how to program his/her own contracts, we will have maximum control. Even though this could create problems that we will address later on in the third section.

Therefore, where should we start from?

As explained in A Lawyer´s Introduction to Smart Contracts, the smart contract is just another component within the system. For that reason, the smart contract would be the final infrastructure component that allows to create and operate such contracts. The module such infrastructure has, which permits its creation would be the Smart Contracts Platform (from now on SCP). On the other hand, we also have another component that could be added to the SCP and make our life much easier, which is the Smart Contracts Management System (from now on SCMS).

In other words, the platform for smart contracts or SCP would be for instance the blockchain of Bitcoin or Ethereum. As well as any other blockchain that allows to interpret, execute even store smart contracts created within it.

Whoever wants to work directly on this layer will need to have some knowledge on programming in order to be able to create his/her own smart contracts. If you wish to do it on the blockchain of Ethereum, for that purpose below we include a tutorial to get started. If you prefer Bitcoin click here to start.

Meanwhile, SCMS are a superstructure placed above the SCP that allow us to use smart contracts just as if they were another service. This way, we could have at hand in a graphic way, also very easy to use the following: a database of the signed smart contracts, a calendar in which to program the beginning and the end, an editor to create drafts of the contracts or a place to store and check the activity records. As said before, all with a graphic interface and without a need for programming.

Thus, blockchain would be the foundations of a house, whereas the SCP would be the furniture and the SCMS the facade, the tiling and the paint.

If we don´t know how to or don´t want to program a smart contract and all its aspects, we might be more interested in a SCMS because it is the closest we can get to a “Smart Contract as a Service”.

Are there many like it? Not too many by now. Codius could fit but it requires some knowledge on programming. The browser/wallet Mist from Ethereum allows something similar but very simple. The Smart Contract presented in this section is one of the most useful, powerful and easy to use ones I have ever seen. An American company that allows to create different types of smart contracts on the blockchain of Bitcoin and Ethereum, besides programming smart coupons and making payments according to the geographical area of a good. All of this without the need to program.

Some smart contracts “Smart Contract” permits to create

If someone wishes to try out the service, it is now free, I suggest that you do it on the test platform (which is more hidden than the regular one). That way one can experiment with it more freely.

What was the main goal when creating our smart contract? To experiment with the concept and to do it with a smart contract not related to payments, which is the most common type. Therefore, our intention was to use the smart contract just for verification, exchange and/or information supply.

2.1.- Using the changes in terms and conditions to create a contract

We have already mentioned that the smart contracts are computer coding based on the idea “If this happens try this. But if it does not happen, then try that”. Therefore the contract requires an external source of information in order to check regularly if “this” happens or not. That source might well be for instance the results of a Google search, through an SEO smart rank. For example, “When a website gets on the first page of Google, make the payment”. This option is provided by the service through the contract “Service Level”, for example.

But maybe the best external sources in order to verify and execute a smart contract are those that are based on text formats that can easily be interpreted by a computer program. This way we will be able to rely on more precise data. We are not referring to formats such as PDF, but sources in Javascript JSON format.

In this sense, the information gathered in our Tracker of Terms and Conditions regarding all the texts that are monitored, is stored in JSON format. This means that in relation to every modification detected, data such as the name of the service, the type of document, the date of the change or the percentage of modified text, are being stored in a format that later on can be read and verified by a computer program. In this case, this computer program will be our smart contract

Some data that can be used from a document tracked by the Tracker of Terms and Conditions to create a smart contract

What do we want our smart contract to do? Since the terms and conditions change very often and since those changes are not always reported, we suggest a scheme in which to configure through smart contracts its obligation to inform and even the acceptance of the conditions when they are modified. All this according to the percentage of change in the monitorized document. Which besides obeying the law, automating a legal obligation and reducing the costs of its compliance, can also offer an extra in transparency and liability which the blockchain provides.

In other words, terms and conditions always include a term related to an eventual modification of the texts. Those modifications are tiny many times but other times they are substantial and even then the user is not notified nor his consent required again. Part of the problem is that the concept “substantial change” is barely defined. Well, our proposal/experiment is to have that term solved through a smart contract.

The process followed to achieve this, at a small and experimental scale, has been the following:

2.2.- Let’s do a smart contract!

First of all, we create a false Privacy Policy and we start monitoring it with the Terms and Conditions Bulletin. In the wording of the Policy we will establish in natural language that whenever a substantial change in the conditions occurs, we will notify this via email, a notice on the web and also the user will be asked for consent again. Also, we point out that a “substantial change” will mean an alteration of at least 15% or more of the text (as for the test, this was the most objective way to try to assess something like this).

Next, we create a test profile in “SmartContract”, we click on “Create Contract”, choose the option “Bitcoin Oracle” and click on “Create Oracle”. We are interested in this option because of the possibility of establishing conditions that can assess whether a value rises, stays the same or falls.

Then, we can start “drafting” the smart terms of our smart contract (see image below). We must also add a description to the contract, attach the files we want (in our experiment a full copy in PDF format of the Privacy Policy), and finally sign and send the contract. At this stage, the contract can be saved in our profile while we are working on it, like in editing mode.

Fields to be completed in our smart term

In our smart term we will choose the option of monitoring performance, since we want to know when substantial changes in our Privacy Policy occur, t. i., whether the alteration is equal to or higher than 15% of the text. Whenever this happens within the established period of time, in addition to recording this in the blockchain and providing our users with a maximum of transparency about our way of acting, we could also link and automate this result to the actions stated in the written term in the Policy. That is, the sending of an email, the notice of the web and the request for consent. And all this depending on the result of this smart contract.

So, we are going to create two smart terms. To begin with, in “IF the API location” we put the JSON version of our Privacy Policy. For this first term we choose the option “HAS a value equal to 15”. Then, we click on “Data Path” and select “variationPercentage” in the window that will be displayed with all available data for that document. Finally, we select an expiration date and add a new “Smart Term”. In this second term we will repeat the previous process, but for the second field now we have to choose “HAS a value more than 15”.

We fill out the field “Description”, attach the files we deem necessary, sign and send the contract to some gentle soul who can make the experiment even more social (it does not have to be a user of the service). It should show something like this:

Smart contract done, signed and sent. It’s so fixed that I can’t even correct the mistake from the title :p xD

Now that the contract is in progress, we just need (or not) to make changes on the external source the smart contract is regularly monitoring, t. i., our false Privacy Policy. This way, by adding or deleting text of the monitored document, we can force the compliance or breach of our smart contract.

And with this and a headache :p, we do have a smart contract.

Everything mentioned in this second section is the practical version of the theory described in the first section. Therefore, here we have created a smart contract on blockchain (with all its implications). Although the experiment is extremely simple and incomplete, I think it helps to understand the concept of smart contracts in reality. It proves at the same time the existence of powerful and easy services that already permit the use of this new legal instrument with no need of programming knowledge. In other words, something we can already use as lawyers, and our clients as well.

That said, let´s go ahead with the tests! Since this little experiment barely scratches the surface.

By the way, if somebody wants to use the Terms and Conditions Bulletin as an external source for her/his smart contracts or even monitor a specifically created text (like the one used in this example), please go ahead and feel free to use those already available. Or else contact us for any specific case.

Finally, we are going to look roughly at some legal outlines on the previously discussed.

3.- Finally, what about the legal part?

We should have by now some idea about what a smart contract is from a technical point of view, what it can be used for and how it could be created. However, what happens legally speaking?

There are already several good articles on the legal aspects of smart contracts, two good examples are the already mentioned A lawyer´s Introduction to Smart contracts or Smart contracts: an approach to the concept and basic legal matters (in Spanish). As all this is already getting a bit too long :p, I merely will comment on a few issues that strike me, with extra reference sources.

There we go:

1.- Although it is very common to hear of smart contracts as instruments that are neither contracts nor smart, the truth is that they can perfectly well accommodate all the inherent parts of a contract and even come to “think” for themselves. It is true that many smart contracts are no more than a simple redirection of an amount from one account to another, nothing else. But we can create a pure smart contract, as some people call it, a contract that is perfectly legal, both in form and substance. Therefore, it all depends a little bit on the use of it.

2.- As for its intelligence, most of the smart contracts are truly robots that under the principle of absolute neutrality simply do as instructed. But there are some developments in that area that will lead them to more. From the inclusion of AI in its writing and compliance to such complex and curious experiments as the DAO or Decentralized Autonomous Organizations. What is a DAO? Very briefly, a smart contract of smart contracts. Or, as some say, when a bot runs the company. Its conception and development are very interesting, as well as its defects and legal consequences (the biggest DAO was hacked a few months ago).

3.- One last remark on its intelligence, I find the idea that over time a smart contract can “represent me legally” interesting. In other words, a smart contract can perfectly identify a user, control certain digital goods of this user and contract or not services depending on the programmed instructions. Therefore, it is only a matter of time before somebody creates his “digital representative”.

4.- The wording, correction and interpretation of smart contracts will be a more complex task, especially at the beginning. First of all, because they are not written in natural language. Secondly, due to the fact that they are so fast and automatic in its execution, it will be important to analyze in depth their lack of errors in the code (a legal debug will be necessary). Apart from this we have to keep in mind that they may include third-party unknown or unaudited code. In any case, natural language contracts will not disappear, they will simply live together or even get mixed (our example was like that). After all, the flexibility of natural language will very often be sought by both parties.

5.- The fact that smart contracts are executed and stored on a distributed network like blockchain is a problem in terms of the applicable law and jurisdiction (if the parties don´t indicate it in the contractual terms). Especially in those contracts in which the parties are not identifiable or even the content of the contract is encrypted. That means, if the contract is verified, executed and stored in millions of computers at the same time, it is everywhere and nowhere simultaneously. What jurisdiction is applicable if the parties have not said anything?

6.- The fact that smart contracts are stored on blockchain, with no possibility for them to be altered and with a maximum level of transparency, can lead to problems in regards to privacy and confidentiality of information. In fact, this is boosting the creation of new private blockchains. And what will occur with the right to be forgotten in a blockchain? Isn´t there going to be some kind of clash between the established in the new European Data Protection Regulation and what technology permits? Probably that´s why we are already working on (private) editable blockchains.

7.- The logical thing is that systems like the one used in the example will be the usual way of creating smart contracts. In that case, the terms and conditions of the service can be of help in regards to applicable legislation and jurisdiction. Therefore, it is also reasonable to assume that these services will be the main focus when it comes to regulation by the governments. We can´t forget that these services will have access to thousands of contracts, to the personal and confidential information they might include and that they will be in charge of their custody. Should they look after the legality of their object? Maybe prevent them from encrypting against any possible setback? Will any legal knowledge be necessary in order to provide templates of smart contracts? They are a computer program after all, that nowadays are mostly created by programmers, not by lawyers, but there is a strong legal connotation to it. In fact, there are already markets to buy and sell smart contracts.

8.- Finally, services like the one used and other similar services have the potential to foster that a few people seriously affect big businesses that are highly regulated, such as sports betting, lotteries or loans. That means, if we can create easily replicable templates of smart contracts on a big scale, it is just a matter of time before somebody ends up creating from his home place an alternative to Bet365 or any other service like these. But obviously without meeting the many necessary requisites for this type of businesses.

Summing up, the legal part of smart contracts is going to pose new interesting challenges. In any case, so far my first contact with them or “Smart contracts are for the summer”. :p

This has been good practice to me, in order to learn in some detail everything surrounding this new area of knowledge. At the same time, this mega post aims (just with the right amount of technical terms) to put in order many of those ideas with the intention that more people can have access to it. As what has been explained here is just the tip of the iceberg and there is still much more to explore.

Although it is true that all that is happening around smart contracts and blockchain is still in its initial bubble stage, over time it will ease down and the revolutions will give room to real applications. But it is undeniable that the technology and its uses have a great potential already present and available. Even for mere mortals. ;D

Happy smart contract!

—–

Seguir a @jorge_morell

La entrada How to create a smart contract using terms and conditions se publicó primero en Términos y Condiciones.