Blockchain
Blockchain » Capítulo 5. Aplicaciones prácticas de la tecnología blockchain: casos de uso y limitaciones » Gobernanza de la blockchain: principales desafíos tecnológicos y éticos en la gestión descentralizada de la información
Página 10 de 13
Capítulo 5
Aplicaciones prácticas de la tecnología blockchain: casos de uso y limitaciones
Tras unos primeros años en los que los primeros usuarios de Bitcoin se familiarizaron con su funcionamiento, empezaron a proponerse nuevos casos de uso que, más que basarse en Bitcoin, aprovechaban propiedades intrínsecas de la tecnología subyacente: blockchain. Pero al ritmo que se iban “ampliando” los límites de la tecnología y dando un mayor uso a la misma, se iban detectando problemas. En este capítulo, nos centraremos en estas aplicaciones y sus problemas.
Desde la notarización a la gestión de la Internet de las cosas, pasando por la gestión de la identidad
Durante unos años, únicamente existía Bitcoin. Pero pronto empezaron a surgir cadenas de bloques que variaban algún aspecto de su funcionamiento con respecto a Bitcoin. Estos sistemas se conocen como “cadenas de bloques alternativas”, o simplemente, cadenas alternativas. Una de las primeras cadenas de bloques alternativas en crearse fue Namecoin. Su propósito fue el de crear una versión descentralizada del sistema de gestión de asignaciones de nombres de dominio en Internet33, el conocido DNS (Domain Name System). La motivación de este proyecto fue (y es) evitar el control centralizado de DNS de nivel superior que gestiona la Corporación de Internet para la asignación de nombres y números o ICANN (Internet Corporation for Assigned Names and Numbers). La forma de evitar este control centralizado a través de una cadena de bloques es bastante intuitiva. En lugar de traspasar un valor monetario, el bien transferido en las transacciones del sistema son nombres de dominio. Así, en la cadena de bloques queda registrado quién es el propietario de un dominio concreto. Implementándose encima de un sistema blockchain, también se dotó a esta forma de registro de la funcionalidad de pago, para poder pagar por esa adquisición de dominios, utilizando una moneda nativa de la cadena. Lo importante, en cualquier caso, es que no habría un único propietario de la tabla que asignara un propietario a cada dominio, sino que todos los nodos de Namecoin mantendrían una copia y, por lo tanto, cualquier actualización debería someterse a consenso.
El hecho de que la gestión descentralizada de nombres fuera el primer caso de uso de una cadena de bloques no puramente monetario es significativo, dado que evitar que haya una única entidad que controle quién es el titular de una identidad es algo bastante delicado. Además, el uso de sistemas blockchain también permite evitar la actuación de intermediarios en el proceso de autenticación, con lo que puede ser una pieza importante para cumplir ciertas propiedades de privacidad. Como por ejemplo, que haya una entidad que controle a qué sitios web accede una identidad concreta, algo que pasa con frecuencia en sistemas de Single Sign On34. Lo cual no evita que escribir información de identidad en un medio inmutable y que facilita la trazabilidad sea en sí mismo un riesgo para la privacidad.
En cualquier caso, la gestión descentralizada de la identidad a través de sistemas blockchain es un área bastante activa, en la que existen numerosas iniciativas. Por ejemplo, la W3C, una organización para la estandarización de sistemas y protocolos basados en la World Wide Web, tiene activas dos iniciativas: 1) el modelo de datos y especificación para la identidad descentralizada (Decentralized Identity)35, y 2) el grupo de trabajo para afirmaciones verificables (Verifiable Claims Working Group)36 sobre estas identidades digitales. El primero está directamente relacionado con sistemas descentralizados, principalmente cadenas de bloques, utilizándolos como plataforma de respaldo de los datos de identidad. Estos datos, a su vez, pueden ser atestados en forma de las afirmaciones verificables.
Quizá, el interés suscitado por esta posible aplicación de las cadenas de bloques viene derivado de los procedimientos KYC y AML (véase el capítulo 4). Ambos procedimientos son fundamentales en la industria financiera. El primero, para poder identificar de forma fehaciente a los clientes de las entidades financieras; el segundo, para prevenir usos fraudulentos de los activos que manejan. De hecho, cualquier entidad financiera tiene el requisito legal de implementar sistemas que cumplan estos procedimientos para poder llevar a cabo su actividad. En ambos casos, la trazabilidad que proporcionan las cadenas de bloques, si se dotan de sistemas de identificación robustos, puede utilizarse como palanca para implementar sistemas robustos de KYC y AML. No obstante, como ya hemos comentado, todo esto puede entrar en conflicto con la privacidad de los usuarios, aspecto en el que se enfocan otras normativas, como el reciente RGPD (el Reglamento General de Protección de Datos).
Otra propiedad que rápidamente se aprovechó para diseñar casos de uso es la de inmutabilidad. En concreto, para permitir sistemas de notarización centralizados. Hasta que se propusieron estos sistemas, la única forma de obtener una prueba digital y fehaciente de que una determinada información existía en un instante temporal era por medio de una autoridad de sellado temporal o TSA (Time Stamping Authority). Estas autoridades son entidades con un reloj que debe cumplir unas propiedades estrictas de precisión y que, al recibir un documento, añaden el instante temporal en el que lo han recibido. También incluyen el documento en una firma digital. Por lo tanto, debe haber confianza en que estas autoridades actúen de forma honesta.
Gracias a las cadenas de bloques, es posible crear un equivalente descentralizado. El proceso es simple: en una transacción se incluye un resumen del documento a sellar temporalmente, además de una transferencia “simbólica” (por ejemplo, de bajo importe y entre dos cuentas propiedad del emisor de la transacción), y se envía dicha transacción. Cuando esa transacción sea aceptada por la red, aparecerá en un bloque que incluirá en su cabecera el instante temporal “aproximado” en el que se creó. El matiz de aproximado es importante dado que, aun en el caso de que cada nodo de la red sea capaz de especificar el instante temporal de una manera precisa, al tratarse de una red, es tremendamente complicado que todos los nodos se pongan de acuerdo en el mismo instante temporal. Por eso, las cadenas de bloques suelen manejar rangos aproximados de tiempo y, en cualquier caso, la granularidad con la que se puede demostrar el instante temporal en el que existía dicha información depende de la frecuencia del bloque (por ejemplo, aproximadamente 10 minutos en Bitcoin). El mecanismo específico de escribir la información en la cadena depende del sistema blockchain en concreto. Por ejemplo, en Bitcoin se utiliza el comando OP_RETURN, que permite incluir en la salida de una transacción un comando con unas pocas decenas de bytes arbitrarios (por ejemplo, el resultado de una función resumen). Aunque dicha salida se evaluará como FALSE siempre y, por lo tanto, no podrá gastarse, dichos bytes quedarán registrados para siempre en la cadena.
Como hemos comentado, este es también uno de los primeros casos de uso alternativos que se les dio a los sistemas blockchain. Ejemplos concretos de aplicaciones y sistemas en este campo son Proof of Existence37, OpenTimeStamps38 y Stampery39. Por supuesto, de este caso de uso “básico” se pueden derivar casos de uso más avanzados, como servicios de notarización, certificación, etc.
Otro uso tradicional es el de gestión de activos, de nuevo basándose en la propiedad de inmutabilidad. De hecho, este caso de uso puede verse como una generalización de transferencia de dinero. El envío de dinero representa en realidad la transferencia de propiedad de unas “monedas” de una persona a otra. Pero si la propiedad que se transfiere es sobre cualquier otra cosa (de ahí que este caso de uso se haya asociado a la Internet de las cosas), el razonamiento sigue siendo muy parecido. Por ejemplo, si una empresa de coches compartidos (carsharing) escribe en una blockchain que el propietario actual del coche C es el usuario con dirección D, entonces solo el usuario que controle la clave privada asociada tiene derecho a utilizar el coche. La información de quién es el propietario se almacena por lo tanto de forma descentralizada en la cadena. Y más aún, la propia empresa podría ser descentralizada y sus normas representadas en forma de un contrato inteligente. Estos principios se han utilizado para diseñar sistemas que reflejan, en transacciones de la cadena de bloques, quién es el propietario en un determinado momento de un bien en concreto, ya sea físico o digital.
Quizá el primer concepto que empezó a surgir en este ámbito es el de monedas coloreadas (colored coins). Se dio este nombre a los sistemas que construían el concepto de activo basándose en criptomonedas y su tecnología subyacente (de Bitcoin, principalmente). El nombre se deriva simplemente de que a cada moneda (más precisamente, transacción de poco valor) se le asociaba una metainformación que permitía determinar qué tipo de bien representaba esa moneda. En sistemas derivados de Bitcoin, esta asociación se hacía muchas veces utilizando el comando OP_RETURN en una de las salidas de la transacción. Al tener cada metainformación un significado distinto (por ejemplo, todas las monedas con la etiqueta 0x1234 son coches), se dice que las monedas están coloreadas. Para transferir la propiedad, basta con que el propietario de la colored coin gaste la salida que aparece en la misma transacción junto con la salida incluida en el OP_RETURN (que recordemos que es una salida no gastable porque siempre se evalúa como falso).
Pese a ser un caso de uso totalmente válido, hay, no obstante, matices importantes que conviene destacar. Por un lado, puede que la blockchain subyacente no entienda de la lógica de aplicación. Es decir, que no se preocupe por verificar que una determinada transacción sea válida según las reglas de la colored coin que represente. Esto pasa por ejemplo en Bitcoin, donde a su sistema de consenso solo le preocupa la semántica en términos de bitcoins, no de una u otra colored coin. Esto puede no ser así en otras cadenas de bloques. Por ejemplo, en un contrato inteligente de Ethereum se puede especificar, como parte de un método del contrato, cualquier mecanismo de transferencia de propiedad y el sistema se preocupará de que la ejecución de dicho método (y por lo tanto, del mecanismo de transferencia) sea correcto.
Finalmente, sobre todo en el caso de los sistemas blockchain que no soportan esta semántica, existe la opinión de que este uso de la cadena correspondiente es inapropiado. Se alegan dos motivos: (1) los mecanismos que se suelen utilizar “queman” dinero (por el hecho de que la salida que incluye un OP_RETURN sea no gastable) y (2) crea transacciones que se alejan del fin principal del sistema blockchain en cuestión y, por lo tanto, hacen que sea más difícil conseguir un “hueco” en un bloque. Este hecho crea demanda por dicho espacio y produce una subida de las tasas recomendadas para que una transacción sea aceptada.
Propuestas para la integración y trasvase de información entre plataformas blockchain: transición hacia la web 3.0
Inicialmente solo existía Bitcoin, pero pronto surgieron cadenas de bloques alternativas. Aunque las primeras eran poco más que mínimas variaciones de Bitcoin, con el tiempo estas cadenas alternativas han ido aportando diferencias importantes. En el capítulo 3 hemos hablado de Ethereum, que permite realizar cómputos arbitrarios sobre la cadena, y de Ripple en el capítulo 4, especialmente pensado para intercambio de divisas.
Lo cierto es que, conforme el ecosistema va siendo más rico y aunque cada sistema blockchain se centre en un caso de uso, no es raro que surjan contextos en los que como parte de una operación en una blockchain, pudiera tener sentido hacer una operación en otro. Por ejemplo, si un usuario tiene cuentas en Bitcoin y en Ethereum, ¿sería posible que ejecutara un contrato inteligente en Ethereum, pero pagando con bitcoins?
Una respuesta afirmativa a esta pregunta consiste en utilizar lo que se conoce como verificación de pago simplificado o SPV (Simplified Payment Verification). Básicamente, un proceso SPV permite verificar que un pago ha tenido lugar sin necesidad de tener una copia completa de la cadena. En concreto, solo es necesario incluir una prueba de que la salida correspondiente al pago se ha incluido en un bloque y una lista de cabeceras de bloque que lo incluyan. No obstante, esta ganancia viene a costa de perder seguridad, ya que al no utilizar una copia completa de la cadena, no siempre es posible detectar determinados ataques. La ventaja es que son procesos más ligeros y que pueden implementarse dentro de una cadena de bloques, por ejemplo, como parte de un smart contract en Ethereum.
Supongamos que existe un contrato inteligente en Ethereum que permite verificar pruebas SPV relativas a transacciones de Bitcoin. Entonces, si un usuario A tiene bitcoins y quiere pagar a un usuario B (que también tiene al menos una dirección en Bitcoin) por ejecutar una operación en Ethereum, lo que tiene que hacer A es pagar en bitcoins a una de las direcciones de B en Bitcoin y, desde Ethereum, construir la prueba SPV y enviarla al contrato que verifica y ejecuta la operación indicada por A. Este proceso, explicado de forma muy resumida y que incluye periodos adicionales de espera como mecanismo de protección ante reorganizaciones de la cadena, es la base de lo que se conoce como pegged sidechains40, algo así como cadenas pinzadas. De hecho, hay sistemas que implementan este tipo de operaciones, como BTCRelay41.
Protocolo de Atomic Swaps*
Otra forma de intercambiar valor entre cadenas, en este caso sin SPV, son los intercambios atómicos o atomic swaps. Estos intercambios atómicos siguen un ingenioso protocolo introducido en un foro de Bitcoin por el usuario TierNolan42 que utiliza transacciones temporizadas para evitar comportamientos deshonestos. Este protocolo, que permite que un usuario A con mA criptomonedas en una cadena cA las intercambie con mB monedas que un usuario B tiene en otra cadena cB es como sigue (figura 11).
El usuario A, en posesión de un secreto (por ejemplo, una contraseña) s, prepara una transacción en cA, moviendo mA monedas de una de sus cuentas a la cuenta especificada por B en cA. Llamaremos a esta transacción Transacción 1. Hay dos posibles opciones de gastar la Transacción 1:
Proporcionando un valor s, tal que el resumen de s valga V, y una firma digital emitida desde una dirección de B. Esta será la opción utilizada en caso de que todo vaya correctamente.
Proporcionando una firma digital doble, firmada tanto por A como por B. Esta será la opción utilizada en caso de que haya que dar marcha atrás.
A no publica aún la Transacción 1.
A prepara una transacción temporizada, es decir, que no se pueda ejecutar hasta un momento concreto para devolver las mA monedas a una cuenta de A. Esto se puede hacer en muchas cadenas de bloques especificando a partir de qué número de bloque es aceptable la operación. Por ejemplo, 288 bloques después del actual. Llamaremos a esta transacción, Transacción 2.
A manda la Transacción 2 a B.
B devuelve la Transacción 2 firmada. De esta forma, en caso de que algo vaya mal, A solo tendrá que esperar el tiempo necesario (288 bloques) para recuperar sus monedas.
B realiza un proceso similar. Crea una transacción moviendo, en la cadena cB, mB monedas de una de sus cuentas a una cuenta especificada por A en cB. Llamaremos a esta transacción Transacción 3. Es posible gastar la Transacción 3 de dos formas:
Proporcionando un valor s tal que el resumen de s valga V, y una firma digital emitida desde una dirección de A.
Proporcionando una firma digital doble: firmada tanto por A como por B.
B no publica aún la Transacción 3.
B prepara una transacción temporizada, devolviendo las mB monedas a una de sus direcciones. El plazo en este caso debe ser menor que el plazo de la Transacción 2. Por ejemplo, 144 bloques después del actual. Llamaremos a esta transacción, Transacción 4. B envía la transacción a A.
A envía la Transacción 4 firmada de vuelta. A partir de este momento, B tiene la certeza de que podrá recuperar sus monedas si algo va mal, pasados 144 bloques.
Una vez se han intercambiado las transacciones temporizadas (la Transacción 2 y la Transacción 4), que hacen de seguro por si algo funciona mal, A y B pueden publicar las transacciones que permiten hacer el intercambio atómico per se (la Transacción 1 y la Transacción 3).
En este paso 7, A publica la Transacción 1 en la cadena de bloques cA. Esto significa que, siguiendo el script de bloqueo de la Transacción 1, correspondiente al caso 1.a), en el momento en el que el secreto s caiga en manos de B, este podrá gastar las mA monedas de cA especificadas en la Transacción 1, enviándolas a una dirección de cA bajo su control.
B publica la Transacción 3 en la cadena de bloques cB. Como A conoce el secreto s, a partir de este momento, A puede gastar las mB monedas de cB especificadas en la Transacción 3, enviándolas a una dirección de cB bajo su control.
Una vez A detecta que B ha publicado la Transacción 3 en cB, crea una nueva transacción, que llamaremos Transacción 5, en la que envía las mB monedas de cB de la Transacción 3 a una dirección de cB bajo su control. Pero lo importante es que, para desbloquear estas monedas, debe incluir el secreto s dentro de la Transacción 5. Además, este secreto debe cumplir la condición de que su resumen valga V o, de lo contrario, la Transacción 5 sería inválida.
Como A conoce el valor s adecuado, la Transacción 5 se acepta.
B está continuamente monitorizando la cadena cB, por lo que en el momento en el que la Transacción 5 se difunde, el valor s llega a conocimiento de B. Es fundamental para B que actúe antes de que venza el plazo especificado en la Transacción 2 ya que, de lo contrario, A podrá recuperar también sus mA monedas de cA.
Dado que en el paso anterior, A ha desvelado el secreto s, ahora B también puede crear una transacción para mover las mA monedas de cA incluidas en la Transacción 1. Llamaremos a esta nueva transacción Transacción 6.
Para terminar, B envía la Transacción 6 a la cadena de bloques cA. Nótese que esta transacción debe ser válida, ya que la Transacción 5 lo era, y ambas dependían del mismo secreto s. Por lo tanto, la Transacción 6 es aceptada en la cadena cA, y las mA monedas de cA pasan a una dirección de cA controlada por B.
Estas operaciones y otras similares permiten intercambiar valores entre cadenas de bloques distintas, lo cual da mucha flexibilidad, evita tener que “casarse” con una cadena en concreto y permite crear aplicaciones mucho más ricas en funcionalidad. No obstante, sigue habiendo un problema: ¿cómo conectamos una blockchain con el mundo exterior? Es decir, ¿es posible tener en cuenta datos de la web tradicional para tomar decisiones en una transacción dentro de una blockchain?
Figura 11
Protocolo por el que un usuario A con mA criptomonedas en una cadena cA las intercambia con mB monedas que un usuario B tiene en otra cadena cB.
Este es un problema relevante, especialmente teniendo en cuenta que gran parte de la información del mundo real de la que dependemos se encuentra en la web tradicional. Y no es tan sencillo como hacer una consulta a una API43 (Application Programming Interface) desde, por ejemplo, un contrato inteligente. Esto es debido a que, para evitar poner en peligro la capacidad de consenso de los sistemas blockchain, cada operación de lectura (dentro de la blockchain o fuera), siempre debe devolver lo mismo.
Supongamos que es posible hacer consultas al exterior. Entonces, en un instante t1, un nodo ejecuta un contrato para leer un valor de una web dinámica y actúa en consecuencia; posteriormente, en un instante t2, otro nodo intenta validar la ejecución del contrato efectuada por el primer nodo pero, al hacer la consulta a la web, recibe otro valor distinto. Lógicamente, el segundo nodo no puede fiarse del resultado obtenido por el primer nodo, por lo que rechaza la transacción pese a que fue generada honestamente.
Para evitar esta casuística, una aproximación común es utilizar el concepto de oráculos (ya mencionado en el capítulo 4), que son entidades en las que se confía para traer datos del exterior. Por ejemplo, una forma de implementar un oráculo es escribiendo en un contrato inteligente una clave pública bien conocida o certificada de algún modo. Para proporcionar datos fiables procedentes de dicha fuente, alguien tendrá que ejecutar dicho contrato inteligente, proporcionando una firma digital sobre dichos datos, y que es emitida con la clave privada asociada a la clave pública certificada previamente. Dada la confianza depositada en la clave pública inicialmente, podemos tomar dicho valor como verídico.
Aunque es cierto que esta confianza choca con la filosofía de los sistemas blockchain (principalmente en el caso de ser públicos), no parece posible hacerlo de otra forma. En cualquier caso, existen servicios que implementan esta funcionalidad de una forma bastante fiable (haciendo uso de sistemas criptográficos), como es el caso de Oraclize44.
Riesgos y problemas en plataformas blockchain
En esta sección vamos a comentar algunos de los riesgos y problemas más importantes relacionados con la tecnología blockchain.
Privacidad
Como ya hemos comentado, la gestión de la identidad es un aspecto fundamental dentro de cualquier plataforma blockchain. Esto es así porque es imprescindible conocer quién ejecuta cada acción para saber si tiene derecho a hacerlo en términos que entienda la lógica del protocolo de consenso subyacente: si tiene fondos suficientes, si tiene permisos para ejecutar una función determinada, etc. La práctica común, heredada de Bitcoin, es utilizar las direcciones (recordemos que, en jerga blockchain, una dirección es una codificación de una clave pública) para determinar la validez de una operación. Ello tiene mucho sentido dado que el único capaz de demostrar ser el propietario de una dirección será quien controle la clave privada asociada a esa clave pública. Pero en un sistema en el que todos tienen acceso a todo, el hecho de apuntar junto a cada acción que se ejecuta la dirección de quien la ejecuta, tiene un efecto colateral importante: todos serán capaces de asociar la dirección con la acción.
A priori, esto podría no parecer muy grave. Al fin y al cabo, estas direcciones son valores binarios que poco sentido tienen para un humano. Además, lo normal (al menos en las blockchains públicas) es que cada usuario pueda crear tantas direcciones como quiera, con lo que, en teoría, podría utilizar una dirección distinta para cada operación. Sobre el primer aspecto, el problema es que no solo debemos preocuparnos por adversarios de carne y hueso, sino también por programas capaces de procesar y clasificar información binaria. Además, sobre el segundo aspecto, no es difícil dar con buenas heurísticas que minimicen el efecto de usar múltiples direcciones por usuario. Un ejemplo muy claro es Bitcoin: si una transacción en Bitcoin tiene varias entradas, es bastante probable que las direcciones de cada una de esas entradas pertenezcan todas a la misma persona. Parece bastante lógico, al fin y al cabo, dado que podemos equiparar una transacción con varias entradas en Bitcoin a una persona que utiliza varios billetes para hacer una compra en una tienda física. Esto es, aunque se utilicen varios billetes (entradas) en una misma compra (transacción), el propietario de todos los billetes (claves asociadas a las direcciones en las entradas) es el mismo. Por supuesto, hay excepciones, como cuando un amigo le presta un billete a otro para completar el pago. Pero normalmente son eso, excepciones. Heurísticas de este estilo han sido aplicadas sobre Bitcoin y otras criptomonedas (Karame et al., 2013) para ser capaces de determinar qué direcciones pertenecen a una misma persona. Su efectividad es a veces asombrosa.
Dicho esto, en el aspecto del anonimato de las transacciones (concepto directamente relacionado con la privacidad del sistema), es justo puntualizar que no es lo mismo analizar este asunto desde una perspectiva de privacidad de la información que desde una perspectiva legal. En el primer caso, ya hemos argumentado que, en muchas blockchains, es posible “desanonimizar” con una tasa de acierto bastante elevada las identidades que hay detrás de una transacción seudónima. Se entiende por “desanonimizar” el hecho de diferenciar si cualquier par de acciones distintas las lleva a cabo una misma persona o no, independientemente de si utiliza direcciones distintas. No obstante, desde el punto de vista legal, situándonos por ejemplo en el contexto de la prevención de blanqueo de dinero o los requisitos de sistemas de KYC, probablemente no sea suficiente con saber con un alto porcentaje de certeza que dos operaciones han sido ejecutadas por la misma entidad; más bien, sería necesario tener una certeza total y, además, saber cuál es la identidad real detrás de esa entidad; es decir, un identificador seudónimo no es suficiente.
Por último, conviene señalar que este no es un problema recientemente descubierto, sino que se sabe desde hace años. De hecho, ya hay muchas alternativas que intentan resolver este problema. Por un lado, pronto surgieron servicios de mezcla (mixing), a través de los cuales se reenviaban bitcoins múltiples veces entre direcciones no relacionadas entre sí, terminando en una dirección nueva del usuario de origen, lo cual permitía desacoplar las direcciones de origen y destino (ambas del mismo usuario). Por otro lado, existen propuestas para mejorar la privacidad de forma nativa. Así, en Bitcoin tenemos lo que se conoce como transacciones confidenciales (confidential transactions), que permiten ocultar las cantidades implicadas en cada entrada y salida de una transacción; pero también hay criptomonedas creadas desde cero con la privacidad en mente, como ZCash o Monero. ZCash es una criptomoneda basada parcialmente en Bitcoin que permite hacer transacciones totalmente anónimas utilizando primitivas criptográficas conocidas como “pruebas de conocimiento nulo” (zero knowledge proofs). Por su parte, Monero combina las confidential transactions con otra primitiva criptográfica conocida como firmas en anillo (capítulo 1), lo que permite ocultar el firmante de una transacción entre un conjunto de posibles firmantes.
Escalabilidad
Otra problemática importante es la de la escalabilidad. Podemos hablar de escalabilidad principalmente en dos sentidos: en cuanto a coste computacional y a coste de almacenamiento. El problema de la escalabilidad computacional se hace evidente cuando se leen noticias que comparan el consumo energético de Bitcoin con el de algunos países o el de un porcentaje del consumo mundial. Desde el punto de vista computacional, un sistema que consuma tal cantidad de potencia de cálculo, y por tanto de energía, no parece ser un sistema eficiente. El problema es que este coste es intrínseco al funcionamiento de Bitcoin: para que sea seguro, el mecanismo de prueba de trabajo requiere que se gaste potencia computacional. De hecho, el sistema será más seguro cuanta más potencia de cálculo se dedique a dicha tarea, siempre y cuando dicha potencia no se concentre en unos pocos participantes de la red. Precisamente esta cuestión es la que ha fomentado la búsqueda de nuevos sistemas de consenso, como el Proof of Stake (PoS) que ya mencionamos en el capítulo 4; o Proof of Elapsed Time, basado en procesadores seguros de Intel. Además, también están los que se han venido a conocer como algoritmos de tipo Proof of Authority, que vienen siendo derivados de los tradicionales sistemas de consenso bizantino, conocidos en la literatura académica desde los años ochenta (Lamport et al., 1982).
La otra vertiente de la problemática sobre la escalabilidad la encontramos en los requisitos de almacenamiento. Realmente, una cadena de bloques es una estructura de datos en la que cada bloque va enlazado inequívocamente al bloque precedente de forma que, además, es necesario tener el bloque precedente para poder comprobar la validez del siguiente. Y así desde el bloque más reciente hasta el bloque inicial o génesis. Como hemos mencionado en el capítulo 2, la cadena de bloques de Bitcoin completa, a marzo de 2019, ocupa aproximadamente 254 GB. Es cierto que se pueden hacer compromisos, por ejemplo, borrando transacciones poco interesantes para el usuario de un cliente Bitcoin; no obstante, esto viene siempre a costa de pérdida de seguridad. También se está investigando en esta línea. Por ejemplo, el protocolo CODA busca utilizar de nuevo un tipo especial de pruebas de conocimiento nulo de forma recursiva para conseguir una blockchain de tamaño constante.
En cualquier caso, es importante tener claras las implicaciones de esta falta de escalabilidad en términos de potencia computacional y almacenamiento requeridos, ya que no es suficiente con añadir más recursos. Sobre el aspecto de potencia computacional, el hecho de que esté siendo tan costoso energéticamente impide de facto a muchos usuarios participar en el proceso de consenso, a no ser que adquieran hardware especializado (algo que no está al alcance de cualquiera). Hacerlo implicará que pierdan dinero para pagar la energía necesaria para llevar a cabo la tarea, ya que, con una probabilidad altísima, nunca conseguirán minar un bloque y conseguir su recompensa. Sobre los requisitos de almacenamiento, de nuevo, no todo el mundo puede dedicar 254 GB (cifra que, además, solo puede crecer) de su espacio de almacenamiento para albergar una copia de la cadena de bloques completa. En ambos casos, esto conduce a que haya pocos que sean capaces de llevar a cabo estas tareas, lo que significa que no se consigue el nivel de descentralización que se perseguía inicialmente. Todo ello restringe, claramente, el tipo de dispositivos en los que se puede ejecutar un cliente completo de un sistema blockchain.
Rendimiento
Otra problemática es el rendimiento o throughput. En la mayoría de las blockchains no se puede alcanzar más de unas decenas o centenas de operaciones por segundo. Este es un límite difícil de eliminar, ya que está relacionado con la frecuencia de bloque. Por ejemplo, en Bitcoin, se producen de promedio, como ya hemos mencionado, un bloque cada 10 minutos. Además, cada bloque tiene un tamaño máximo; hasta finales de 2017 este límite era de 1 MB, desde entonces el límite es algo más complicado de calcular, pero pueden llegar a ocupar bastante más. Esto implica que también hay un límite máximo de transacciones por bloque: las que caben en él. Por hacer unas cuentas rápidas, pongamos que son 4.000 transacciones las que caben en un bloque (aproximadamente 250 bytes por transacción). Como se produce un bloque aproximadamente cada 10 minutos, se podrán publicar como máximo 4.000 transacciones cada 10 minutos, o cerca de 7 transacciones por segundo. Esto no es competitivo con el número de transacciones que soportan los sistemas bancarios actuales, que son del orden de varios miles por segundo.
De nuevo, esta es un área en la que se está trabajando. Desde hace ya unos años se propuso la Lightning Network, que proporciona mecanismos para hacer transacciones off-chain, es decir, transacciones que no necesitan ser escritas en la cadena de bloques salvo en determinadas ocasiones. Estas transacciones son, por tanto, prácticamente instantáneas y también menos costosas en cuanto a las tasas que llevan asociadas. Algunas cadenas de bloques ya han empezado a introducir medidas para soportarlas, como Litecoin y Bitcoin.
Gestión de claves
La mayoría de las operaciones en una cadena de bloques requieren, como hemos mencionado en varias ocasiones, de una firma digital. A su vez, una firma digital requiere un par de claves: una pública y una privada (ver capítulo 1), siendo además imprescindible almacenar de forma segura las claves privadas. Esto trae consigo la problemática de la gestión de claves que siempre ha existido en criptografía. En el caso de las cadenas de bloques y, especialmente, en el de las criptomonedas, existe el agravante de que estas claves privadas dan acceso directo a un valor (en forma de dinero electrónico, de bienes digitales, etc.). Es decir, quien controla la clave privada, controla el valor asociado; y en el sentido contrario, quien pierde una clave privada, pierde el control del valor asociado. En el caso de blockchains públicas, perder el control en este caso es un hecho irreversible, ya que no hay una autoridad central que pueda decidir revertir una operación45.
¿Cómo hacer para almacenar las claves privadas de forma segura y usable? La máxima seguridad requiere almacenar las claves en un dispositivo específicamente diseñado para tal fin, sin conectividad a Internet y guardado a buen recaudo. Las billeteras especialmente diseñadas para actuar como tal (no necesariamente sin conectividad) son las conocidas como hardware wallets (billeteras hardware), como Trezor46. A las wallets sin conectividad se las conoce con el término de cold wallets (billeteras frías). No obstante, en términos de usabilidad, probablemente estas no siempre sean prácticas para operaciones cotidianas, ya que sería demasiado incómodo. Por otro lado, si simplemente guardamos las claves criptográficas en un fichero, en nuestro móvil o portátil, corremos el riesgo de que nos lo roben o lo perdamos, lo que implicaría perder el control de las criptomonedas asociadas. También podemos cifrar el fichero con las claves, pero entonces estamos simplemente trasladando el mismo problema a la clave con la que ciframos el fichero. Otra opción puede ser utilizar un servicio en línea específicamente diseñado para ello, como Coinbase47. En este caso, es normal que no tengamos las claves en ningún momento, sino que sea el servicio quien las controla, asociando simplemente un balance a nuestro usuario. Quizá un punto intermedio son aplicaciones que han sido creadas específicamente para gestionar claves. En este caso, es el usuario quien debe asegurarse de conocer bien los mecanismos de copias de seguridad que proporciona cada aplicación; así como de las buenas prácticas para evitar accesos no deseados a estas aplicaciones. Un ejemplo de este tipo de billeteras es MyEtherWallet48, una aplicación web (por lo tanto, accesible desde cualquier navegador) que permite generar claves en el propio navegador, sin enviarlas a ningún servidor, y mantenerlas cifradas en el ordenador del usuario. O las billeteras que normalmente ofrecen los equipos de desarrollo oficiales de cualquier sistema blockchain y se ejecutan como una aplicación de escritorio más. Ejemplos de esto son Bitcoin Core49, de Bitcoin, o Mist50, de Ethereum.
Por otro lado, en casos en los que es imprescindible asociar una identidad real a una clave, ¿qué procedimientos son necesarios y qué protocolos se pueden usar para ello? Una blockchain pública no es a priori compatible con las infraestructuras de clave pública tradicionales, como certificados electrónicos (tradicionalmente del tipo X.509), en las que disponemos de una o varias autoridades certificadoras que garantizan, en cierto grado, la identidad real asociada a un par de claves. El simple hecho de ser autoridades parece algo incompatible con un sistema descentralizado. En el caso de cadenas de bloques privadas, las infraestructuras de clave pública existentes son más apropiadas, pero ello no hace que sea un asunto sencillo: es necesario mantener listas actualizadas de los miembros del sistema, revocar las claves comprometidas o caducadas, etc. Todas estas tareas son delicadas y complejas, de forma que no se alcanza una solución idónea para la gestión de la identidad digital en el ecosistema blockchain.
Inmutabilidad
Una de las propiedades estrella de las cadenas de bloques es que, una vez que algo se escribe en ellas (en realidad, después de que se incluyan algunos bloques adicionales), es imposible borrarlo en la práctica. Esto es lo que se conoce como la inmutabilidad de las cadenas de bloques, y que se deriva de la estructura en cadena y de la robustez de los algoritmos de consenso.
No obstante, esta inmutabilidad también puede crear problemas, principalmente en blockchains públicas. Desde situaciones derivadas de fallos no intencionados, como equivocarse al poner la dirección de destino de un pago; hasta usos claramente indeseables, como incluir fotos pedófilas en la cadena de bloques. En el primer caso, una vez escrita la transacción con el destinatario incorrecto, dado que no hay un banco o similar que controle la cadena de bloques, la única opción sería pedirle a dicha persona que te devolviera el dinero. Para ello, primero debe existir tal persona ya que es perfectamente posible enviar dinero a direcciones inexistentes (es decir, cuya clave privada aún no se ha generado); e incluso en caso de existir, y de tener la suerte de conocerla, dicha persona tendría que devolver el dinero por decisión propia. En resumidas cuentas, parece complicado. En el ejemplo de contenido ilegal, como el pedófilo, es perfectamente posible, ya que hay maneras de escribir información arbitraria en la cadena de bloques. De hecho, hay estudios que desgraciadamente afirman la existencia de este preciso ejemplo51. Y de nuevo, una vez escrito dicho contenido, la propiedad de inmutabilidad implica que no se puede borrar. Del mismo modo, también podrían utilizarse para guardar para siempre una copia de un determinado malware, etc.
Igual que con las otras problemáticas ya mencionadas anteriormente, también han surgido propuestas en este aspecto. Cabe destacar una propuesta de un modelo de cadena de bloques editable o redactable blockchain52. Explicado de manera muy breve, este modelo se basa en una primitiva criptográfica conocida como “resúmenes camaleón” en los que quien esté en posesión de una clave criptográfica privada es capaz de encontrar colisiones en estas funciones resumen camaleón (recordemos del capítulo 1 que encontrar una colisión en una función resumen criptográfica segura es algo computacionalmente imposible). Utilizando estas funciones resumen camaleón, quien posea la clave privada para calcular colisiones puede cambiar la historia de la cadena de bloques encontrando una colisión para el puntero resumen de un bloque al bloque anterior. Por supuesto, quien controle dicha clave privada tiene mucho poder y debe ser confiable. Esto hace que este modelo sea difícil de compatibilizar con cadenas de bloques públicas.
Gobernanza de la blockchain: principales desafíos tecnológicos y éticos en la gestión descentralizada de la información
Desde un punto de vista técnico, la descentralización es un medio para conseguir determinadas propiedades de seguridad, como protección ante censura o ataques de denegación de servicio. En definitiva, la disponibilidad y perdurabilidad de la información. Por otra parte, tiene cierto aire romántico, ya que todos los participantes del sistema son, a priori, iguales. La cuestión es que, pese a que esta igualdad es muy deseable e incluso necesaria, conseguir una plataforma sin asunciones de confianza puede llegar a complicar bastante determinadas tareas.
Por ejemplo, en un entorno centralizado, desplegar una nueva versión de un sistema o un protocolo es algo delicado, pero que, con buena coordinación, se puede llevar a cabo de forma eficiente. Casos que vienen rápido a la mente son las actualizaciones del sistema operativo de un teléfono móvil, por ejemplo. Incluso casos algo más descentralizados, como los estándares de la IETF (Internet Engineering Task Force) o como los protocolos de seguridad de la capa de transporte o TLS (Transport Layer Security). En estos escenarios, basta con que la organización de referencia cree una nueva versión del sistema/protocolo en cuestión y siga los pasos establecidos para el despliegue de la misma.
Podría pensarse que el proceso sería el mismo en un entorno descentralizado, pero hay una diferencia fundamental: no existe una autoridad que pueda dar instrucciones al resto del mundo. Por supuesto, suele haber organizaciones o asociaciones que se convierten en referentes, pero sus decisiones o recomendaciones no son ni mucho menos incontestables. Además, como no podía ser de otro modo, en el caso de sistemas blockchain, el consenso es crucial. Por un lado, ya sabemos que cuanto mayor sea la proporción de nodos honestos frente a nodos deshonestos, más estable será el estado de la red (y esto vale tanto para sistemas con consenso de tipo prueba de trabajo, como de prueba de interés, o cualquier otro tipo).
Por otro lado, en este tipo de sistemas, las normas definidas en el proceso de consenso a partir de las cuales se decide qué transacciones son válidas parten de la definición del protocolo. Combinando estos dos aspectos podemos empezar a vislumbrar la problemática: si, ante una nueva versión del protocolo, un porcentaje elevado de los participantes de la red se opone a aplicarla (algo totalmente posible ya que no hay una autoridad que tome la decisión por todos), el sistema puede verse en la situación de que, en caso de aplicarse dicha actualización, haya una porción del sistema que la acepte y otra que la rechace. Esto significa que, potencialmente, un porcentaje de los nodos verán unas transacciones como válidas, y el porcentaje complementario las verá como inválidas. En la práctica, esto significará que se han creado de facto dos redes, cada una con una versión parecida, pero distinta, del protocolo original. Y lo peor de todo es que la tolerancia ante actores deshonestos se reduce proporcionalmente en ambas redes.
En la práctica, hay distinción entre los tipos de actualizaciones. Una actualización se conoce como “bifurcación blanda” (soft fork) si los cambios que introduce son retrocompatibles. Es decir, un nodo que no se actualice podrá seguir generando transacciones válidas, aunque probablemente no entienda un subconjunto de las transacciones nuevas. Por otro lado, una actualización se conoce como “bifurcación dura” (hard fork) si no es así. Es decir, cualquier nodo que no se actualice dejará de ser capaz de emitir transacciones que sean aceptadas por el resto de la red. Por lo tanto, una hard fork es mucho más peligrosa ya que de no haber un acuerdo muy amplio, se corre el riesgo de crear dos redes totalmente incompatibles.
Históricamente, ha habido bifurcaciones de ambos tipos en las cadenas principales. Las hard forks más conocidas se han utilizado para crear nuevas criptomonedas, como Bitcoin Cash53, que se bifurcó de Bitcoin para aumentar el tamaño máximo del bloque. De hecho, el historial del cambio de límite de tamaño de los bloques en Bitcoin es un buen ejemplo de los problemas de gobernanza en redes descentralizadas. Algo tan, en principio, sencillo como aumentar el tamaño máximo de los bloques del protocolo ha generado un debate que ha durado años y que ha tenido como consecuencia la creación de varias cadenas alternativas a Bitcoin. Incluso ha habido casos en los que la versión “oficial” de Bitcoin parecía que recibía menos soporte que una alternativa (el famoso fork de Segwit2x54, al que llegaron a respaldar actores importantes del ecosistema, como granjas de minado, casas de intercambio e incluso quienes llegaron a ser desarrolladores principales del Bitcoin “oficial”).
Otro ejemplo de hard fork —de distinta naturaleza pero igualmente relevante— fue el que se llevó a cabo en Ethereum para resolver el hack a TheDAO, un contrato inteligente que pretendía usarse como vehículo de financiación descentralizada (DAO son las siglas de Decentralized Autonomous Organization, esto es, organización autónoma descentralizada) para proyectos basados en Ethereum. Después de una de las mayores rondas de financiación hasta la fecha, alguien descubrió una vulnerabilidad en el código de TheDAO a través de la cual podía desviar los fondos recaudados a una dirección de su elección. Aunque el ataque se paró, el atacante consiguió robar una cantidad sustancial de ether. Para recuperarlo, una parte importante de la comunidad (entre ellos, Vitalik Buterin, uno de los fundadores de Ethereum) decidió desplegar una actualización en la que se devolvía la cantidad robada a sus dueños originales. Como hemos dicho, pese a que los principales referentes en el ecosistema respaldaban esta opción, hubo muchos a quienes no les parecía correcto, porque pensaban que debía prevalecer la propiedad de inmutabilidad, o porque consideraban que “el código es ley” y, si algo estaba escrito de una forma en código y alguien lo había conseguido utilizar en su provecho, debería mantenerse así. En cualquier caso, la crítica principal era que abrir esta vía de actuación podía poner de manifiesto que Ethereum no era tan descentralizado como se suponía. El resultado final fue que tuvo lugar la bifurcación dura, y se creó una versión alternativa de Ethereum en la que, pese a tener la misma funcionalidad, el histórico de transacciones era diferente. Esta versión pasó a llamarse Ethereum Classic, y hoy en día sigue siendo una de las criptomonedas principales.
Para concluir, cabe mencionar que, como no puede ser de otra forma, hay sistemas blockchain que incluyen mecanismos para agilizar la gobernanza. Por ejemplo, en Tezos55 el proceso de votación sobre posibles nuevas versiones del protocolo se hace sobre la propia blockchain (en jerga, se dice que se hace on-chain), mientras que en Bitcoin o Ethereum, este proceso debe hacerse por otros medios (es decir, off-chain).