Blockchain

Blockchain


Blockchain » Capítulo 2. Desde la criptomoneda a la blockchain: introducción de la tecnología Bitcoin » Limitaciones de Bitcoin: problemas de seguridad, de escalabilidad y de gobernanza

Página 7 de 13

La blockchain de Bitcoin, pues, ofrece un medio de persistencia de información de gran interés para el despliegue de nuevos protocolos de comunicación y de gestión de la información. El reto aquí consiste en saber conjugar la capa de confianza de blockchain con la pila de protocolos de los actuales sistemas de información y comunicación. Este ejercicio, por otro lado, debe efectuarse siguiendo el espíritu de los procesos de estandarización llevados a cabos en el dominio de la Internet desde sus inicios (Hardjono et al., 2018), para de este modo configurar soluciones eficaces y eficientes que aprovechen las propiedades de la blockchain.

Limitaciones de Bitcoin: problemas de seguridad, de escalabilidad y de gobernanza

Sin ningún género de duda, Bitcoin supone un auténtico hito en la configuración de un entorno de compartición de información sin necesidad de que exista confianza expresa en un agente central (Narayanan y Clark, 2017). Por un lado, Bitcoin define una plataforma, un protocolo y una red de colaboración que van más allá del mero y simple intercambio financiero. Esa triple alianza configura una estructura de datos que es el embrión del fenómeno blockchain actual. Por otro lado, en el caso de Bitcoin, la potencia que se le presupone a este fenómeno adolece de una serie de características que en muchos casos se tornan en disfunciones estructurales que obstaculizan su papel como motor de la transformación digital.

El primer reparo que podemos observar respecto a la adopción de la infraestructura Bitcoin reside en su autoría anónima. Aunque esto no ha sido óbice para su expansión, el hecho de que no se sepa quién o quiénes están detrás de la figura de Satoshi Nakamoto no abona la confianza. Si no conocemos quién o quiénes están detrás del artículo seminal, si no tenemos información sobre la forma en la que se llevó a cabo el primer prototipo de la red Bitcoin, si no contamos con elementos suficientes para determinar y cuestionar los intereses de Satoshi Nakamoto, ¿por qué hemos de confiar en esta tecnología?20. Según Nakamoto, hemos de confiar precisamente porque no está basada en la “confianza”, sino en la criptografía.

Lo cierto es que es fácil encontrar ejemplos donde la criptografía no ha conseguido dar respuesta a las expectativas de sus usuarios. Así, en los últimos años podemos hallar ejemplos de errores en la implementación de protocolos criptográficos, robos de credenciales en plataformas digitales, incluso fallas graves de seguridad en dispositivos hardware resistentes a la manipulación. En el caso particular de Bitcoin existen tres sucesos muy significativos que ponen bajo cuarentena la sentencia de Nakamoto (Campbell-Verduyn, 2017):

1. La ramificación (fork) involuntaria de marzo de 2013. La actualización del software al realizar la transición desde la versión 0.7 a la 0.8 del núcleo del software de Bitcoin implicó la sustitución del motor de base de datos Berkeley DB por Level DB, que permitía sincronizar de forma más rápida. En un momento dado, tras la actualización del software, se generó un bloque de gran tamaño que no era compatible con la política de acceso bloqueado de Berkeley DB. Así, este bloque sí que era aceptado como válido por los nodos con la versión 0.8 de Bitcoin, pero era rechazado por los nodos que mantenían la versión anterior del software. Como resultado, se produjo una bifurcación en la cadena, con la singularidad de que los nodos mineros que tenía la versión 0.7 instalada tenían mayor capacidad de cómputo, lo que hizo que su rama de la cadena creciera más rápido. La gestión de este problema pone de relieve los sistemas de gobernanza que operan en Bitcoin. Después de muchas conversaciones y discusiones a través de foros abiertos y de correo, prevaleció el criterio de recomendar instalar la versión 0.7 en todos los nodos de la red Bitcoin. La forma en que se encauzó la toma de decisión puso de relieve la posición de privilegio del grupo de programadores encargados del mantenimiento del núcleo del software, así como la capacidad de influencia de operadores de granjas de minado como BTCGuild y Slush. Esto es, el suceso deja entrever una recentralización en la red Bitcoin.

2. La caída de la casa de cambio Mt. Gox en 2014. Mt. Gox fue una empresa intermediaria que operaba convirtiendo bitcoins en moneda fiat (es decir, en dólares, euros o cualquier otra divisa que cuenta con el respaldo del Banco Central correspondiente). Para ello, Mt. Gox tenía desplegada toda una infraestructura fuera de la cadena (off-chain), que fue atacada exitosamente en 2011 en primera instancia y de modo mucho más efectivo en 2014. El ataque en cuestión permitió la sustracción de un volumen considerable de criptomonedas de clientes de Mt. Gox. Tras el incidente de 2014, los responsables de la empresa intentaron culpabilizar a la infraestructura Bitcoin del robo de criptomoneda. La información que se pudo recabar directamente desde la blockchain y desde los diversos foros de discusión en redes sociales y listas de correo, unida a las pesquisas realizadas por el FBI norteamericano, permitió señalar a la plataforma de Mt. Gox y a la gestión de sus dirigentes como la verdadera fuente del problema de seguridad. De nuevo los mecanismos de gobernanza se establecen desde fuera de la blockchain, como consecuencia de la colaboración activa entre los usuarios y supervisores de la tecnología.

3. El caso de Silk Road. Bitcoin y Tor21 suelen asociarse al mercado negro en muy buena medida como consecuencia de la actividad de Silk Road. Esta plataforma se presentó en 2011 como una opción para el libre intercambio de bienes sin tener que rendir cuentas a Estado o autoridad alguna. Con el tiempo, se demostró que el tipo de bien y de actividad a la que estaba dando cobijo Silk Road era de índole delictiva. Los pagos en Silk Road se producían en bitcoins, pero la interacción con sus usuarios se realizaba a través de servidores y servicios que estaban ubicados fuera de la blockchain. La protección de esa infraestructura era de alta complejidad, pues involucraba el uso de técnicas avanzadas de cortafuegos, enrutadores de tráfico y ocultación del origen de las comunicaciones mediante Tor. Esta complejidad tenía por meta evitar la trazabilidad de las operaciones y de los usuarios por parte de las autoridades y fuerzas de seguridad. Lo cierto es que los propios usuarios de Silk Road tenían dificultades para realizar transacciones y la compleja red de comunicaciones presentaba ciertas debilidades en puntos concretos que habilitaron las tareas de investigación del FBI. Como resultado de todo este trabajo, el FBI logró dar con los responsables de Silk Road.

La principal conclusión que hemos de extraer de las tres disfunciones señaladas en Bitcoin es que la blockchain por sí sola no soluciona todos los problemas que existen en los sistemas de información y de comunicación. En su haber, blockchain permite impulsar modificaciones orientadas a crear soluciones más robustas, pero tal proceso exige pensar muy en profundidad qué tipo de imbricación ha de tener la blockchain en la actual infraestructura TIC. En esa reflexión hemos de considerar de modo muy sosegado dos cuestiones capitales: la escalabilidad y la sostenibilidad de la tecnología.

La “escalabilidad” de Bitcoin afecta al tamaño en memoria secundaria (el disco duro de nuestro ordenador) que ocupa la blockchain. En la medida que la blockchain es un registro de actividad en el que se añade información y no se borra, y teniendo en cuenta que el número de usuarios y la actividad irá creciendo a lo largo de los próximos años, el número de bloques y el espacio que ocupan en disco duro puede resultar prohibitivo22. De hecho, en el momento de redacción de este libro, el tamaño de la blockchain de Bitcoin es de 254 GB, tamaño que no es ni mucho menos manejable si estamos trabajando con dispositivos con poca capacidad de almacenamiento y con restricciones en términos de consumo energético. Es cierto que en estos escenarios se pueden buscar opciones apoyadas en clientes ligeros de Bitcoin en tales dispositivos y un nodo central con un cliente que cuente con una réplica completa de las transacciones de Bitcoin, pero lo cierto es que este tipo de restricciones han de ser bien tenidas en cuenta a la hora de diseñar arquitecturas de sistemas basadas en algún tipo de blockchain.

En lo relativo a la “sostenibilidad”, hemos dicho que el recurso limitado que Bitcoin utiliza como patrón-dinero es la energía. La búsqueda de colisiones en estos momentos se realiza fundamentalmente en las denominadas granjas de minado e involucra un gasto energético muy elevado. De hecho, a finales de 2017 existían 159 países cuyo consumo energético estaba por debajo del consumo de energía involucrado en la generación de bitcoins. Eso por lo que respecta al consumo global de Bitcoin, pero además es de tener en cuenta que el reparto de la capacidad de cómputo no es homogéneo, pues existen granjas de minado que sobrepasan con creces la capacidad de cómputo del resto de mineros del ecosistema Bitcoin. Es particularmente relevante el caso de GHash.IO, empresa que surgió a mediados de 2013 como agrupación de grupos de mineros y que a mediados de 2014 alcanzó una capacidad de cómputo del 51% de la capacidad total de la red. En ese caso los responsables de GHash.IO emitieron un comunicado señalando que no pensaban utilizar esa situación de privilegio para subvertir la blockchain.

Efectivamente, recordemos que el minado de un bloque en la blockchain de Bitcoin requiere encontrar un nonce tal que se consiga un resumen de la cabecera del bloque con un número determinado de ceros a la izquierda. Si existiera un nodo con una capacidad de cómputo mayor que la mitad de la capacidad, eso significaría que ese nodo podría utilizar la misma cantidad de criptomoneda para realizar más de un pago (algo que atenta contra los principios del dinero electrónico). Para ello, a la hora de realizar un pago, el nodo en cuestión crea una transacción para el destinatario correspondiente. Tras ello, envía por difusión la transacción y empieza a minar bloques en privado haciendo crecer la blockchain en una rama distinta de la cadena activa. Si el nodo malicioso consigue minar n bloques antes de que se confirme la transacción real, entonces habrá conseguido utilizar varias veces la misma criptomoneda. En caso de que esto no ocurra de forma general, el resto de nodos eventualmente acabarán detectando todos los intentos de doble gasto, algo que pondría en peligro la confianza en la infraestructura Bitcoin.

Este ataque, llamado “por mayoría” o “ataque del 51%”, afecta, pues, sobre todo a la credibilidad de Bitcoin. Las características de la red P2P y la naturaleza criptográfica de la estructura de datos de Bitcoin no hace posible el borrado de información de forma trivial, pero el descrédito que este ataque depararía es más que suficiente para dejar inservible a Bitcoin.

No obstante, esta no es la única vulnerabilidad del modelo de consenso de Bitcoin. A la hora de explicar la creación de los bloques de datos, vimos que las diversas transacciones eran seleccionadas por los mineros desde la memoria temporal (Narayanan et al., 2016). Por defecto, en el proceso de selección se priorizan las transacciones en función del remanente que los emisores han dejado como pago para los mineros. Asimismo, cuando se decide sobre qué bloque se debe continuar minando, el criterio de decisión por defecto apunta a escoger la cadena de bloques más larga (la que tiene más altura). Si existen dos cadenas con la misma altura, se escoge aquella que se vio primero. Por último, otro comportamiento por defecto atañe al criterio que se sigue una vez se ha minado un bloque. Aquí la pauta base es informar de la creación inmediatamente después de la creación del bloque, esto es, se enviará el mensaje de difusión a los nodos vecinos sin dilación. Modificaciones sobre estos comportamientos, así como otras pautas de decisión básicas, hacen factible cribar ciertas transacciones y establecer colusiones entre nodos en la red con objeto de perjudicar a usuarios y/o nodos concretos, o de buscar beneficio particular cuando sea posible.

Ir a la siguiente página

Report Page