Fundamentos de Blockchain¶
La tecnología Blockchain se ha puesto muy en auge en los últimos años, especialmente ligada al campo de las criptomonedas. En este documento veremos las características principales de esta tecnología, sus ventajas y sus principales aplicaciones actualmente, en especial aquéllas ligadas al campo de la inteligencia artificial.
1. Fundamentos de la tecnología Blockchain¶
La traducción literal de Blockchain es cadena de bloques, y podemos entenderlo como una tecnología que permite realizar una implementación distribuida de un sistema, formado por distintos bloques independientes e interconectados o enlazados.
Si buscamos una definición formal en Internet, por ejemplo, en Wikipedia, podemos ver que esta cadena de bloques es una lista de registros en continuo crecimiento, llamados bloques, que están vinculados y asegurados mediante criptografía.
La idea principal es que cada uno de esos bloques contiene cierta información, y que esa información es INMUTABLE. En el momento en que algo altere o corrompa la información de uno de los bloques, la cadena se rompe y la operación se anula. Esto aporta unos mecanismos de seguridad y transparencia que son parte de la filosofía de Blockchain. ¿Qué hace una entidad financiera con nuestros datos? Es algo desconocido, opaco. Sin embargo, sabemos que los datos que aportamos a una cadena de Blockchain no van a alterarse, o la operación entera que hayamos iniciado se anulará.
Veremos a continuación algunos de los aspectos relevantes que hacen posible esta tecnología Blockchain, incluyendo mecanismos de encriptación, computación distribuida, etc.
1.1. Los orígenes de Blockchain¶
A pesar de que los fundamentos teóricos de Blockchain se comenzaron a gestar en la década de los 80 del siglo pasado, no fue hasta 2008-2009 cuando comenzó su desarrollo a nivel práctico, con las primeras nociones de un sistema monetario peer to peer, y la primera criptomoneda Bitcoin. La idea inicial, planteada por un personaje anónimo auto-denominado Satoshi Nakamoto, era que dos personas pudieran enviarse dinero entre ellas sin que tuviera que intervenir una institución financiera. Así, se ideó una moneda ficticia que se pudiera intercambiar en estas transacciones entre particulares y que, como cualquier moneda, tuviera un valor al cambio en el mercado. Inicialmente no se sabía bien cuál iba a ser ese valor, qué repercusión tendría en la vida de las personas. Así, por ejemplo, hubo personas que pagaron 10.000 bitcoins por un par de pizzas. El valor de esa transacción, años después, habría podido rondar los 160 millones de dólares, aunque el valor de Bitcoin ha ido fluctuando mucho a lo largo de los años.
Por tanto, a partir de la idea de realizar una transacción monetaria entre particulares surge la necesidad de la tecnología que permita dicha transacción mediante la descentralización del sistema financiero global. Una tecnología distribuida, que permita que las transacciones entre particulares se almacenen en los diferentes nodos de la red, y se puedan enlazar una tras otra, formando una cadena. Cada uno de los bloques de la cadena contendrá como información una o más transacciones entre particulares, y éstas se irán acumulando en sucesivos bloques.
A medida que se generan nuevas transacciones, se agrupan en bloques y se enlazan en la cadena, y dicha cadena es compartida por distintos nodos de la red, de forma que todos tienen una copia de la misma, y se puede detectar cualquier alteración en cualquier nodo, por parte del resto.
Aquí podemos encontrar una traducción al castellano del artículo original de Satoshi Nakamoto que definía las características y especificaciones de la tecnología para hacer funcionar Bitcoin.
1.2. Componentes de un bloque¶
¿Qué contiene cada bloque de una cadena en Blockchain?
Por un lado, se dispone de una cabecera con información general del bloque:
- Una referencia al bloque previo de la cadena, para poder mantener la cadena enlazada. Más adelante veremos cómo se enlazan estos bloques. El único bloque que no tiene una referencia al bloque previo es el bloque génesis, que inicia la cadena en cuestión.
- Un número llamado nonce, vinculado a la tarea de minado de bloques, que explicaremos más adelante.
- Un timestamp o fecha de creación del bloque
- Una codificación hash de las transacciones que contiene, de forma que se pueda después verificar que no se ha alterado el contenido de las mismas
En el contenido del bloque estarán las transacciones agrupadas que lo forman. Cada transacción recoge un evento del sistema. Por ejemplo, una transferencia de dinero digital de un individuo A a otro B.
El tamaño medio de un bloque puede variar. Bitcoin por ejemplo admite en torno a 1MB de datos, pero otras cadenas pueden tener otras especificaciones de tamaño distintas. En esta web podemos obtener algunas estadísticas en cuanto a tamaños de bloques y número de transacciones incluidas.
1.3. Los sistemas distribuidos y la arquitectura peer to peer¶
Un sistema distribuido, en general, es un paradigma de computación en el que dos o más nodos cooperan para conseguir un objetivo común. Están modelados de forma que, para el usuario final, sólo se percibe una única plataforma. Por ejemplo, el buscador Google se asienta sobre múltiples nodos distribuidos por todo el mundo para hacer las búsquedas, pero el usuario sólo percibe un buscador general.
En un sistema distribuido hay cuatro parámetros clave: consistencia, disponibilidad, latencia y tolerancia a fallos o cortes. La conjetura de Brewer, demostrada en el año 2002, afirma que en un sistema distribuido no se pueden cumplir a la vez la consistencia, la disponibilidad y la tolerancia a fallos. Supongamos un caso simple con dos nodos. Habrá consistencia si los dos tienen la misma información, habrá disponibilidad si los dos nodos están en funcionamiento con la última versión de los datos y habrá tolerancia a fallos si, a pesar de algún fallo en la comunicación de los nodos, el sistema sigue funcionando. Pero supongamos que la conexión entre los dos nodos se corta, y una nueva actualización llega a uno de los dos nodos, pero no al otro. Si el nodo acepta la actualización, ya no habrá consistencia. Si la rechaza, ya no habrá disponibilidad. Uno de los dos parámetros es inalcanzable en este caso. Además, el teorema PACELC indica que hay una compensación entre la latencia y la consistencia: si queremos que la consistencia sea alta, deberemos admitir tiempos de latencia elevados para que todos los nodos actualicen la información.
Con la tecnología Blockchain pasamos de utilizar una arquitectura cliente-servidor propia de grandes organizaciones a un sistema distribuido basado en una arquitectura peer to peer. En una arquitectura cliente-servidor, un solo servidor (o unos pocos de ellos) contienen toda la información, y son un punto crítico en el sistema ya que, si fallan, o si alguien accede y manipula la información, los clientes conectados al servidor pueden dejar de funcionar o ver alterados sus datos. En cambio, en una arquitectura peer to peer todos los elementos intervinientes en el proceso tienen una responsabilidad equiparable en el proceso, todos son eslabones del sistema y, si alguno cae, el resto de elementos pueden redistribuirse el trabajo y el proceso. En Blockchain no hay una entidad central que controle el proceso, ni siquiera una tercera parte de confianza que lo pueda validar. Todos los nodos son co-responsables del funcionamiento del sistema, lo que supone un ahorro en los costes que, de otro modo, supondría mantener esa entidad coordinadora.
Respecto a la conjetura de Brewer mencionada antes, en la tecnología Blockchain se sacrifica la consistencia en favor de la disponibilidad y la tolerancia a fallos. Así, dicha consistencia no se alcanza al mismo tiempo que los otros dos parámetros, sino que se alarga más en el tiempo, a partir de las validaciones que harán los distintos nodos de la red. La latencia, unida a estas validaciones, harán que la consistencia se demore más en el tiempo.
Distribuido vs descentralizado
Existe cierta confusión entre dos términos que, aparentemente, guardan mucha similitud. Para algunos autores, sin embargo, existen algunas diferencias sutiles entre un sistema distribuido y uno descentralizado. Conceptualmente, un sistema distribuido es aquel en el que no todas las operaciones se hacen en el mismo lugar (se distribuyen entre los nodos que lo forman), mientras que un sistema descentralizado es aquél en que no hay una entidad que controle todo el proceso. Aunque algunos autores recalcan ciertos matices que los diferencian, para el campo que nos ocupa (Blockchain) podemos admitir los dos términos como complementarios.
1.4. El libro mayor inmutable¶
Un libro mayor (ledger en inglés) es el registro de todas las transacciones que se realizan dentro de un sistema. ¿Qué ocurriría en un sistema centralizado si hacemos una operación y, con el tiempo, el resultado se altera? No tendríamos forma de demostrar que eso que está guardado ahora no se corresponde con lo que nosotros hicimos en su día.
En cambio, en un sistema distribuido como Blockchain, las operaciones que hacemos quedan registradas en muchos nodos distribuidos por todo el mundo. El hecho de que uno se altere no comportará ningún riesgo, ya que la información quedará alterada/corrompida, pero habrá otros muchos nodos que puedan confirmar la información original.
Partiendo del ejemplo de Bitcoin anterior, todos los nodos de la red tendrán una copia de las transacciones realizadas:
2. Cómo se encriptan los datos: los sistemas de criptografía¶
La información de las transacciones que hay contenidas en una cadena de bloques no deben ser visibles por cualquiera, sino sólo por aquellas personas involucradas en la transacción. Además, debemos asegurarnos de la integridad de los bloques, es decir, que el contenido de un bloque no se ha visto alterado o corrompido. Para ello, se requiere algún sistema para proteger esos datos y que, por un lado, sólo las personas autorizadas puedan consultarlos y, por otro, podamos comprobar que los datos no han sido alterados. La criptografía es un mecanismo que proporciona varios servicios:
- Confidencialidad: asegurar que sólo las entidades implicadas pueden acceder a la información
- Integridad: asegurar que la información sólo puede ser modificada por las entidades autorizadas
- Autenticación: saber en todo momento la identidad de una entidad o la validez de un mensaje
Mediante la criptografía podemos codificar la información de las transacciones para que sólo las partes implicadas puedan consultarlas, y también podremos proteger los datos contenidos en los bloques para que nadie externo pueda modificarlos sin ser detectado. Veremos a continuación, de forma breve, cuáles son los tipos principales de criptografía que se aplican en el proceso de Blockchain.
2.1. Cómo se conectan los bloques: el hashing¶
Las funciones hash son un sistema de cifrado de una vía (permiten codificar la información, pero no descodificarla), que normalmente se utilizan para garantizar la integridad de los datos: se toman los datos a codificar, se les aplica la función de hash y se obtiene con ello una huella digital que representa a los datos. De este modo, si los datos originales cambian, se tiene una huella digital diferente, y se detectará entonces que han sido alterados.
Por ejemplo, la criptomoneda Bitcoin emplea un algoritmo llamado SHA256 para codificar sus transacciones en cadenas de 256 bits. Con esto lo que conseguimos es transformar la información original de la transacción (o conjunto de transacciones) en una especie de huella digital o fingerprint, que codifica la información original y la identifica. Así, cada bloque de la cadena recibirá el identificador hash del bloque previo (información codificada del bloque previo) y generará el identificador hash propio que lo identificará respecto al resto de bloques (la probabilidad de que dos bloques tengan el mismo hash es muy, muy baja). Esta información se irá pasando de un bloque al siguiente:
¿Qué información se utiliza para generar el hash de un bloque? Los datos que contiene un bloque, y que hemos comentado anteriormente: los datos de las transacciones que almacena, el timestamp o tiempo de creación del bloque, etc. En el momento en que un bloque vea alterado su hash, al no guardar ya correspondencia con el hash previo del bloque siguiente, la cadena se romperá en ese punto, al alterarse la información.
Existen diferentes mecanismos de cifrado hash, y cada uno genera una cadena de longitud determinada. Así, la función SHA256 empleada en Bitcoin genera una cadena de 256 bits (64 bytes). En esta web podemos probar a codificar distintos textos de entrada utilizando distintos algoritmos de hash, para entender mejor a qué nos referimos. Es importante recalcar que, para una misma entrada, se obtendra siempre el mismo hash, y que cualquier cambio mínimo que hagamos en la entrada alterará el hash por completo, como se puede probar en esa web.
2.2. Criptografía asimétrica. Sistemas de doble clave¶
La criptografía asimétrica es un mecanismo de encriptación o codificación que consiste en que cada individuo dispone de dos claves, una pública (conocida por todos) y otra privada (conocida sólo por el propio individuo). Así, se utiliza una clave para cifrar y otra para descrifrar o verificar la información, dependiendo de lo que queramos hacer: o bien cifrar los datos o bien certificar nuestra identidad. Los datos cifrados con la clave privada sólo se pueden descrifrar con la pública, y viceversa. Veamos dos ejemplos:
- Si un individuo quiere certificar su identidad (lo que se conoce como firma digital), lo que hace es codificar los datos con su clave privada de forma que, usando su clave pública, cualquiera podrá determinar que esos datos fueron codificados por el propio individuo en cuestión.
- Si lo que pretendemos, en cambio, es proteger o encriptar una información para enviarla a un destinatario, la codificaremos empleando la clave pública de dicho destinatario, para que sólo él pueda descifrarla empleando su clave privada.
Existen distintos sistemas de cifrado asimétrico, como el sistema RSA o el ECDSA, empleados en distintos tipos de Blockchain tanto para certificar identidad como para proteger los datos que enviamos.
2.3. Criptografía simétrica¶
A diferencia de la criptografía asimétrica, en la criptografía simétrica se utiliza una misma clave para codificar y descodificar la información. Normalmente se emplea una clave de longitud determinada (128, 192, 256 bits...) para cifrar un bloque de datos, de modo que sólo con esa misma clave se puede descifrar. Averiguar la clave sin tenerla es una tarea muy costosa (habría que emplear algoritmos de fuerza bruta que probasen todas las posibilidades) lo que le da a este sistema de cifrado una buena seguridad.
El sistema AES (Advanced Encryption Standard) es un sistema de codificación simétrica por bloques. Se emplea en Blockchain junto con el sistema asimétrico, para que cada individuo o entidad pueda cifrar su clave privada y, de este modo, no sea directamente accesible por el resto de individuos.
3. Funcionamiento de Blockchain¶
Ahora que ya hemos visto algunas nociones básicas sobre qué son los bloques, qué contenido contienen, cómo se enlazan y distribuyen por la red, vamos a analizar algunos aspectos algo más complejos del proceso que conforma la tecnología de Blockchain, para terminar de entender cómo funciona.
3.1. Cómo se construyen los bloques: el minado¶
El concepto de minado es un término que probablemente hayamos oído más de una vez, también asociado a las criptomonedas. Sin embargo, es un concepto asociado a la tecnología Blockchain en general. El minado de Blockchain es un proceso que puede realizar muchos cálculos por segundo y consumir muchos recursos en nuestro ordenador (y en nuestro sistema eléctrico). Pero... ¿para qué se utiliza?
A la hora de generar el código hash de un bloque, el sistema debe asegurarse de que dicho código sea válido y, en ocasiones, cumpla con una serie de requisitos determinados. Así, los hash para transacciones de ciertas criptomonedas se tienen que identificar por un patrón determinado de inicio. ¿Cómo podemos generar un hash "aleatorio" que comience con un patrón definido? Aquí es donde entra en juego el proceso de minado.
La idea es que, para generar el hash de un bloque, se tenga en cuenta la información contenida en el propio bloque: tiempo de creación, datos de las transacciones... ¿Cómo asegurar que, uniendo todo esto, el hash que obtengamos tenga un patrón determinado? Tenemos que añadir un dato más en este conjunto, un dato habitualmente llamado Nonce, que también forma parte del bloque. Es un valor arbitrario que se va generando hasta que, combinado con el resto de datos del bloque, genere un hash válido. En esto consiste fundamentalmente la minería, en ir probando diferentes valores de Nonce hasta generar un número de hash acorde a las especificaciones. Es lo que se denomina resolver un puzzle criptográfico.
Esto contribuye aún más a la inmutabilidad de los datos: si procuramos que los hash tengan un patrón determinado (por ejemplo, que comiencen con cinco ceros), cualquier cambio en la información alterará el hash y hará que no comience con ese patrón, detectando fácilmente el error.
Actualmente la minería de Blockchain (y, en concreto, la de criptomonedas) tiene una recompensa: cada bloque minado aporta una compensación económica a quien lo ha conseguido minar. Por este motivo están proliferando tantos "mineros" por todo el mundo, para ser parte del sistema y beneficiarse de las recompensas que éste proporciona. Esta minería puede hacerse de forma individual, o bien en granjas mineras (propiedades de una empresa), o también mediante mining pools, agrupaciones de individuos/nodos para lograr una mayor capacidad de procesamiento, repartiéndose el rango de nonces posibles para competir contra las granjas, y repartiéndose la recompensa de forma proporcional a la potencia aportada. Basta con descargar el software correspondiente para unirse al pool. En webs como esta podemos ver cuáles son las principales granjas o pools de minado en los bloques de los últimos N días o años.
En esta web podemos hacer unas pruebas básicas de cómo funciona el proceso, generando bloques minados con un prefijo determinado.

3.1.1. Limitaciones del nonce¶
El valor del Nonce es un entero de 32 bits sin signo, con lo que sus valores varían entre 0 y algo más de 4 mil millones. Esto permite generar algo más de 4 mil millones de hashes distintos para un bloque. Teniendo en cuenta que el hash es de 256 bits, la probabilidad de que uno de esos 4 mil millones de hashes encaje con el patrón que estamos buscando es muy baja.
¿Qué ocurre si ninguno de los 4 mil millones de nonces que generamos produce un hash válido? Aquí entra el juego el timestamp del bloque. Como se va actualizando cada segundo (hasta que se termine de crear el bloque), esto permitirá buscar en otra ventana diferente de los posibles hashes, permitiendo tener otra oportunidad nueva de encontrar un hash válido.
3.1.2. Hardware para minado¶
Como hemos comentado, el proceso de minado consume muchos recursos de computación y eléctricos. Es necesario disponer de un hardware potente para aumentar la capacidad de procesamiento. En este sentido, conviene distinguir entre tres dispositivos hardware relevantes:
- La CPU (Central Processing Unit) es el procesador elemental que tiene todo ordenador. Puede tener más o menos núcleos, pero ofrece una capacidad de cómputo y procesamiento paralelo limitada a la hora de minar bloques, ya que su objetivo es realizar tareas de propósito general.
- La GPU (Graphics Processing Unit) son procesadores gráficos con más capacidad de cómputo. Está especializada en operaciones matriciales (procesamiento gráfico, e incluso trabajo con vectores de datos en sistemas de machine/deep learning. Son apropiados para minar bloques en la mayoría de cadenas (incluso se pueden disponer en paralelo en distintas arquitecturas).
- Los dispositivos ASIC (Application-Specific Integration Circuit), que desde 2014 han proporcionado una capacidad de minado muy superior a los anteriores. Son las que se utilizan, por ejemplo, para el minado de Bitcoins (para las que ya no se admiten otros tipos de dispositivos). Están diseñados específicamente para una tarea (por ejemplo, generar hash usando SHA-256), y realizan los cálculos a nivel físico, sólo con pasar la electricidad por el dispositivo. No hay componentes lógicos (código incrustado) que se tenga que ejecutar, lo que hace que el rendimiento sea superior, multiplicando por mil el rendimiento de las GPU aunque, eso sí, orientados a una tarea muy concreta.
- Alternativamente, se puede acudir al cloud mining para delegar en una arquitectura en la nube el proceso de minado.
La velocidad de procesamiento del hardware, aplicado a Blockchain se mide en hashes por segundo H/S, es decir, cuántos códigos hash se pueden generar en un segundo. Una CPU normal puede tener un rendimiento de unas decenas de millones de hashes por segundo (MH/s), las GPU pueden llegar al GH/s, y los dispositivos ASIC a los 1.000 GH/s.
3.2. Funcionamiento de una transacción en Blockchain¶
Vamos a unir las piezas que hemos visto hasta ahora para intentar comprender mejor cómo funcionan las transacciones en Blockchain. Revisaremos inicialmente algunos conceptos que hay que tener presentes para entender mejor el funcionamiento.
3.2.1. Claves, wallets y direcciones¶
Cuando pasamos a formar parte de una cadena de bloques, debemos disponer (o se nos asigna) una pareja de claves privada y pública con las que, como hemos visto, podemos firmar nuestras transacciones y verificar la integridad de los datos. Además, normalmente las transacciones de un usuario se almacenan en un monedero virtual o wallet, asociado a una dirección. Estas direcciones son secuencias alfanuméricas vinculadas de algún modo a la clave pública del usuario. En algunas cadenas la propia clave pública hace de dirección y en otras, para no exponerla tanto, lo que se hace es convertir la clave pública en otra a través de un hash, que hace de dirección. Si una persona quiere recibir transacciones de una cadena, deberá tener una dirección disponible, asociada a su wallet o monedero virtual.
Yendo un nivel más allá (aunque no lo veremos en este documento), puede darse el caso de que un usuario necesite más de una dirección (por ejemplo, para que sea más difícil de rastrear los pagos que recibe). En este caso, sería más difícil almacenar todas las direcciones asociadas al usuario, con el riesgo de que se pueda perder alguna de ellas. En este caso, se hace uso de lo que se llaman monederos jerárquicos deterministas (en inglés, Hierarchical Deterministic Wallets o HD Wallets). Consisten en monederos que contienen una semilla que genera una secuencia predefinida de códigos. De este modo, sólo es necesario guardar la semilla, y con ella, generar siempre la misma secuencia de valores, que desembocará en la misma secuencia de direcciones generadas.
3.2.2. Pasos en la transacción¶
Partiendo de los conceptos previos, el funcionamiento de una transacción generalmente es el siguiente:
- Uno de los nodos de la red comienza la transacción. Ésta contiene tanto la operación a realizar (por ejemplo, enviar dinero a otro nodo), como la dirección del destinatario y la clave pública del emisor (esta última, para verificar que es quien realiza la transacción).
- Esta transacción es firmada con la clave privada del nodo emisor.
- La transacción firmada se envía a otros nodos de la red, empleando algún protocolo de diseminación. En redes P2P es habitual el protocolo Gossip, entre otros. Estos otros nodos validan que la transacción sea correcta (entre otras cosas, comprueban con la clave pública del emisor que, efectivamente, es el autor de la transacción, verifican que hay fondos disponibles en el caso de transacciones monetarias, etc).
- Una vez la transacción es validada, los nodos mineros tratan de encajarla en un nuevo bloque. Cuando uno de los mineros resuelve el puzzle de encontrar una clave hash adecuada para el bloque, se considera el bloque formado, y la transacción confirmada.
- Las transacciones y código que contenga el bloque (como, por ejemplo, los smart contracts que veremos más adelante) son ejecutados una vez se confirma el bloque, y dicho bloque se añade al final de la cadena. Esta información es propagada y compartida por todos los nodos de la red, que mantienen así actualizada la cadena.
3.2.3. Ejemplo¶
En esta web podemos simular el proceso de codificación de transacciones.
- En la pestaña Keys podemos generar una clave privada aleatoria, y su correspondiente clave pública asociada.
- En la pestaña Signature podemos simular el proceso de firma de un mensaje o transacción: escribimos el texto del mensaje y, usando la clave privada de la pestaña anterior, podemos firmar (Sign) el mensaje, obteniendo la firma o signature. Con la opción de Verify podemos verificar, usando la clave pública asociada, que efectivamente el mensaje ha sido firmado por la clave privada original.
- En la pestaña Transaction simulamos la codificación de una transacción: indicamos la cantidad a transferir, junto con las claves públicas del emisor y el receptor, e indicamos la clave privada con que queremos firmar o codificar la transacción. Nuevamente, podemos verificar después con la clave pública del emisor que la transacción ha sido firmada por dicho emisor.
- En la pestaña Blockchain podemos simular varios procesos de transacciones en una cadena, para ver cómo se acumulan en bloques.
3.2.4. Almacenamiento temporal de transacciones: el mempool¶
Hemos visto que un bloque está formado por un conjunto de transacciones. Hasta que se conforma un bloque, las transacciones pendientes se almacenan en una memoria temporal en los nodos de la red, una zona llamada mempool.
Una de las tareas de los mineros es elegir qué transacciones añadir en un bloque. En algunos casos, cada transacción tiene una comisión o tasa asociada, que va destinada al minero que la añada en un bloque. Por tanto, parte del tiempo de minado se emplea en esta selección de transacciones.
Si, pasado un cierto tiempo, una transacción almacenada en el mempool no ha sido asignada a ningún bloque, dicha transacción se anula o libera. En el caso de una transacción monetaria, el dinero vuelve a su emisor.
3.3. Los protocolos de consenso¶
En un sistema distribuido como es Blockchain, puede que haya más de un nodo que, al mismo tiempo, genere un hash válido para un bloque de transacciones. También puede ocurrir que alguien malintencionado altere los contenidos de una cadena en un nodo determinado para modificar un bloque. En cualquiera de estos casos, ¿cómo elegir el bloque correcto? Aquí entran en juego los protocolos de consenso. Básicamente consisten en estrategias descentralizadas en las que los nodos de la red deben llegar a un acuerdo sobre qué bloque elegir y cuál(es) descartar.
3.3.1. El problema de la tolerancia a faltas bizantinas¶
Un sistema distribuido debe ser tolerante a fallos en las comunicaciones. Esto viene ilustrado por el problema de los generales bizantinos, un problema clásico de la computación distribuida. El problema original data de 1982, y habla de un grupo de generales que debe guiar a diferentes tropas de la armada bizantina en el ataque a una ciudad. La única forma que tienen de comunicarse las tropas es a través de mensajes, y necesitan coordinarse para atacar a la vez. Esto presenta dos problemas:
- Puede que algunos generales "traidores" no estén de acuerdo con el resto, y envíen mensajes confusos para evitar la coordinación
- Los mensajeros pueden ser capturados, evitando así que el mensaje llegue a tiempo
Se necesita un mecanismo que permita llegar al acuerdo entre los generales, a pesar de estos dos inconvenientes. Llevado al terreno de la computación, en un sistema distribuido habrá nodos que se comporten correctamente, y otros que tengan un comportamiento aleatorio o no deseado, y el sistema en su conjunto debe poder seguir ofreciendo una respuesta correcta. Los algoritmos que resuelven este problema se basan en tomar la decisión o acción adoptada por la mayoría de participantes.
3.3.2. Principales protocolos de consenso¶
Los protocolos de consenso en sistemas distribuidos deben hacer frente a dos problemas:
- Qué hacer cuando un nodo malicioso quiere añadir o alterar un bloque
- Qué hacer cuando se mina un mismo bloque a la vez en distintos puntos de la cadena
En el caso de una alteración puntual de un bloque en un nodo, la detección es sencilla: si el resto de nodos que contienen esa información la contrastan entre sí, y acuerdan que el nodo afectado no tiene la misma información, esta información quedará automáticamente descartada y reemplazada por la correcta. Si lo que se añade es un bloque nuevo malicioso, la validación posterior que harán de él otros nodos de la red lo descartará.
En el supuesto de que más de un nodo mine a la vez un mismo bloque (con diferente hash), se debe establecer cuál de los bloques prevalecerá. Aquí se pueden aplicar distintas políticas o protocolos de consenso. Algunos de los más habituales en Blockchain son los siguientes:
-
Prueba de trabajo (PoW, Proof of Work): se aplica en aquellos sistemas Blockchain donde los códigos hash de los bloques deben seguir un patrón determinado (por ejemplo, comenzar por un número determinado de ceros). El hecho de que un nodo haya encontrado un valor de Nonce adecuado para codificar un bloque siguiendo ese patrón demuestra que ha empleado un tiempo de trabajo considerable en ello y que, por tanto, la generación del bloque es válida. Es lo que se denomina resolver un puzzle criptográfico, y se aplica en criptomonedas como Bitcoin. La principal desventaja que tiene esta técnica es el elevado consumo de recursos que implica pero, a cambio, evita problemas de suplantación de identidad, donde un nodo malintencionado quiera replicarse en la red para imponer su criterio.
-
Prueba de participación (PoS, Proof of Stake): como alternativa a la estrategia anterior, con un consumo de recursos muchísimo menor, en estos protocolos se bloquean temporalmente los fondos de quien está involucrado en el proceso de validación o generación de bloques hasta que dicha validación se considere correcta. Así, alguien que quiera introducir un valor equivocado en la red verá comprometidos sus fondos, que no le serán devueltos. Esta estrategia se aplica en criptomonedas más recientes, como Ethereum.
-
Existen otros protocolos alternativos, como la prueba de actividad (PoA), prueba de cobertura (PoC), etc, aunque no están de momento tan extendidas como las dos anteriores.
Puede ocurrir, no obstante, que en algunos casos se generen bloques igualmente válidos en diferentes partes de la red. En estos casos se suele considerar válido el bloque que pertenece a la cadena más larga, descartándose el resto. Así, las dos o más cadenas en conflicto seguirán generando bloques, y al final prevalecerá la que antes consiga añadir más bloques, y quede como cadena más larga. También entran en juego otros parámetros, como la latencia o la rapidez con la que se transmita un bloque u otro. El bloque asimilado por la mayoría de nodos sería el que prevaleciera (problema de los generales bizantinos).
En una cadena se pueden aplicar uno o varios de estos protocolos para resolver los conflictos. En el caso de ataques malintencionados para corromper datos o introducir datos erróneos, los protocolos de PoW o PoS, entre otros, suelen ser bastante disuasorios. En los casos de simultaneidad en la generación de bloques, aplicar medidas como la prevalencia de la cadena más larga y el voto de la mayoría ayudan a resolver los conflictos.
3.3.3. Los bloques huérfanos¶
En el caso de que dos o más nodos minen un bloque a la vez, uno de esos bloques será el que prevalezca (aplicando las políticas vistas antes) y el resto se desengancharán de la cadena donde están, pasando a ser bloques huérfanos. Dependiendo del momento, ha sido más o menos sencillo minar nuevos bloques y ha habido más o menos gente interesada en este minado. Por ejemplo, en estos últimos años la dificultad para minar nuevos bloques ha aumentado, y eso dificulta que haya dos o más coincidencias en el minado de un bloque, disminuyendo el número de bloques huérfanos.
Cuando un bloque se identifica como huérfano, el minero (o mineros) responsables de su minado pierden la gratificación que hubieran obtenido, ya que el bloque que ha prevalecido ha sido otro. Notar que los bloques pueden tener distintas transacciones, y un tiempo de minado más o menos similar (cada minero habrá elegido qué transacciones incluir en el bloque). Las transacciones del bloque huérfano vuelven a estar disponibles en la mempool para añadirse a un nuevo bloque.
3.3.4. El ataque del 51% y el problema del doble gasto¶
El ataque del 51% es una situación hipotética que se plantea en una cadena de bloques, y que puede referirse a dos cosas:
- Ya hemos visto que los protocolos de consenso se basan en la decisión de la mayoría a la hora de mantener o actualizar una cadena de bloques. ¿Qué ocurriría si algún usuario malintencionado logra hacerse con el control de más de la mitad de los nodos de la red? Esta es una situación hipotética que es muy difícil que se dé, sobre todo en redes blockchain grandes y, por tanto, consolidadas.
- Otra alternativa a este ataque consistiría en que una granja minera o un pool con la suficiente potencia se conectara a la red en un instante T, obtuviera una copia de la cadena y, de forma offline, se dedicara a generar nuevos bloques a una velocidad mayor que sus competidores. Al volverse a conectar a la red, se podría dar el caso de que esa cadena, de longitud más larga, prevaleciera sobre la original, alterando las nuevas transacciones que se hubieran producido desde ese instante T. En este caso, el 51% hace referencia al hash rate, a la tasa con que el grupo produce un nuevo hash respecto a los otros. Este grupo tendría poder de decidir qué transacciones entran en los nuevos bloques. Es también raro que se dé este caso, especialmente en cadenas con una potencia de cómputo elevada como Bitcoin donde los atacantes tendrían que tener equipos muchísimo más potentes que el resto de mineros.
La segunda opción va ligada también al problema del doble gasto: ocurre cuando, en alguna de las transacciones ya validada en los bloques de la antigua cadena, un usuario ya ha hecho un gasto del dinero recibido en esa transacción. Como ya hemos visto, esa transacción luego volvería al mempool al descartarse su bloque correspondiente y, al añadirse de nuevo en otro bloque, se podría incurrir en un nuevo gasto de esa misma transacción.
Por lo general, Blockchain es un sistema bastante seguro, y el problema del doble gasto en transacciones y procesos normales está controlado: no se puede utilizar una misma transacción dos veces diferentes en dos bloques diferentes. Sin embargo, en situaciones como este ataque del 51% podría darse el caso de que sí. En general, cuantos más bloques tenga por delante el bloque donde se encuentra una transacción, más seguro será que esa transacción no se pierda.
3.4. Tipos de cadenas¶
Existen varios tipos de cadenas que podemos formar con la tecnología Blockchain. Atendiendo a su visibilidad, podemos distinguir entre:
- Cadenas públicas: son las más habituales, en las que cualquier nodo puede formar parte de la red, y no es propiedad de nadie en particular. Todos los usuarios mantienen una copia del libro mayor, y se emplean mecanismos de consenso para llegar a acuerdos sobre los nuevos bloques que entran en la cadena. Bitcoin o Ethereum son ejemplos de cadenas públicas.
- Cadenas privadas: están abiertas a un grupo reducido de individuos u organizaciones, que comparten el libro mayor entre ellos. Un ejemplo es Quorum.
Atendiendo a su arquitectura, podemos distinguir entre:
- Cadenas monocapa o monolíticas: existe una única cadena base, donde se realizan todas las operaciones (minados, validaciones, transacciones...). Es la estructura habitual en muchas cadenas actuales, como Bitcoin o Ethereum.
- Cadenas multicapa, en las que, a partir de una cadena base, se ramifican distintas cadenas encargadas de distintas operaciones. Así, por ejemplo, las transacciones no tienen por qué ejecutarse en la cadena base, sino que se derivan a una cadena secundaria que se encarga de gestionarlas. Lo mismo podría ocurrir con el minado, o la validación de datos.
- Un subtipo concreto de esta arquitectura son las llamadas cadenas de 2 capas, que se presentan como una solución a los problemas de privacidad y escalabilidad en las cadenas monocapa tradicionales. Así, en la capa principal se llevan operaciones básicas de consenso y definición de bloques, y la segunda capa es la que ejecuta las transacciones.
3.5. Cambios en las cadenas originales¶
Como hemos comentado anteriormente, los datos que se almacenan en una cadena son inmutables, y las políticas que rigen el funcionamiento de una cadena están establecidas desde el inicio. Pero... ¿qué ocurre si, durante el funcionamiento de una cadena la comunidad se da cuenta de que algo no va bien o es mejorable? Por ejemplo, hemos comentado con anterioridad que el tamaño medio de un bloque está en torno a 1MB. ¿Qué ocurriría si, en una determinada cadena, la comunidad determina que ese tamaño es insuficiente o demasiado grande? Habría que cambiar la política de funcionamiento de la cadena, y para ello existen dos estrategias:
- Soft Fork, que podríamos traducir de forma libre como cambio suave. Consiste en introducir una pequeña actualización en la cadena que mantenga la compatibilidad con la versión previa. Así, los nodos participantes pueden elegir incorporar la actualización o no, y en este último caso pueden seguir formando parte de la cadena aunque, quizá, con algunas limitaciones en su uso. Aplicado al ejemplo del tamaño del bloque, ¿qué ocurriría si 1MB no es suficiente y queremos almacenar más datos?. Podríamos añadir en el contenido del bloque una dirección a un espacio adicional de memoria donde se almacene el resto de la información. Esto hará que los nuevos bloques sigan siendo compatibles con los antiguos.
- Hard Fork, que podríamos traducir de forma libre como cambio profundo. Consistiría en cambiar completamente la política de la cadena, y empezar una nueva cadena desde cero, desechando la cadena original. En el ejemplo anterior, consistiría en crear una nueva cadena con un tamaño máximo de bloque de 2MB, por ejemplo, y seguir funcionando a partir de ahí.
4. Las criptomonedas¶
Las criptomonedas son, a día de hoy, la principal aplicación práctica de la tecnología Blockchain. Básicamente son protocolos que trabajan sobre esta tecnología para diferentes fines, y que permiten que los participantes se comuniquen entre sí. Muchas criptomonedas permiten realizar transacciones monetarias virtuales entre particulares, como por ejemplo Bitcoin. Otras, en cambio, están pensadas para ejecutar código de forma distribuida, como es el caso de Ethereum. Y, de este modo, podemos encontrar diversos propósitos.
Como ya hemos visto en las primeras secciones de este documento, la primera criptomoneda que surgió, y gracias a la cual se desarrolló la tecnología blockchain, fue Bitcoin, en el año 2008. Más adelante aparecieron otras muchas, cada una con su finalidad y su relevancia. Podemos hacernos una idea global de su actualidad en páginas especializadas, como ésta. Por tanto, la tecnología que permite el uso de criptomonedas es Blockchain, pero luego cada criptomoneda define su propio protocolo de funcionamiento, algoritmos de encriptación, etc: el de Bitcoin, el de Ethereum, etc. Además, cada protocolo (Bitcoin, Ethereum, Neo, etc) tiene asociada una moneda virtual; así, la moneda de Bitcoin se llama igual (Bitcoin), la de Ethereum se llama Ether, etc. Las monedas permitirán la interacción entre los usuarios que utilizan el protocolo en cuestión, como veremos con algunos ejemplos.
4.1. Bitcoin¶
Como hemos comentado, Bitcoin fue la primera criptomoneda que se ideó, por parte de la identidad anónima Satoshi Nakamoto, y que originó el desarrollo de toda la tecnología Blockchain posterior. Se emplea para transacciones entre pares sin intervención de una entidad financiera intermedia, facilitando así la transparencia y seguridad, y eliminando algunas de las trabas que supone un sistema centralizado (opacidad, cobro de comisiones, etc). Aquí podemos acceder al repositorio GitHub de Bitcoin, que permite el funcionamiento de la criptomoneda en el sistema.
4.1.1. Politicas de Bitcoin¶
Veremos a continuación cuáles son las políticas o principios fundamentales sobre los que se sustenta Bitcoin en su funcionamiento. Es importante recalcar que estas políticas o principios están preestablecidos en la definición del protocolo y, por tanto, no puede haber ninguna entidad que arbitrariamente pueda cambiarlos a su antojo durante el funcionamiento de la criptomoneda.
El halving
Uno de estos principios es el de halving o reducción a la mitad, según el cual la cantidad de dinero que se gana por minar un bloque se reduce a la mitad cada 210.000 bloques generados. Así, al inicio del proceso en 2009 la recompensa por cada bloque minado era de 50BTC, y en 2012 se redujo a 25BTC. Esto provocará que la cantidad de Bitcoins que se pongan en circulación será cada vez menor, y llegará un momento (se estima que en torno al año 2140) en que la recompensa por el minado de nuevos bloques sea ya 0.
¿Tendrá sentido seguir minando Bitcoins si la recompensa va a ser muy pequeña, o incluso 0? En las transacciones se puede incluir (de hecho, se suele incluir) una pequeña tasa o comisión para recompensar al minero que conforme un nuevo bloque. Esto también permitirá un marco de competencia, donde cada transacción lleve implícita su comisión y habrá, por así decirlo, transacciones más "baratas" que otras. Los mineros complementarán su (baja) recompensa de minar bloques con el extra de las tasas añadidas a cada transacción del bloque minado. Además, como hemos visto antes, los mineros también pueden elegir qué transacciones añadir al bloque que van a minar, en función de la tasa que ofrezca cada una.
La frecuencia de nuevos bloques
La frecuencia de bloque indica cada cuánto tiempo se mina un nuevo bloque en una criptomoneda. En el caso de Bitcoin esa frecuencia es de en torno a los 10 minutos en promedio, mientras que otras criptomonedas, con algoritmos de minado menos rigurosos, ofrecen tiempos menores. Así, por ejemplo, Ethereum, cuyo protocolo de consenso es Proof of Stake, produce nuevos bloques cada 15 segundos aproximadamente. En esta página podemos examinar una criptomoneda en concreto, y ver hace cuánto tiempo se ha minado cada uno de sus bloques. Por ejemplo,aquí tenemos los datos relativos a Bitcoin. Para cada bloque minado aparece la fecha, el usuario que lo minó, etc.

El patrón del hash
Como hemos comentado en el apartado de minado, para ciertos protocolos, como es el caso de Bitcoin, se exige que los códigos hash de los bloques comiencen por un patrón determinado, por un número de ceros inicial (leading zeros). Inicialmente esta cantidad de ceros fue baja, pero a medida que se fueron minando más y más bloques, se fue aumentando esta cantidad para restringir más el número de bloques asociados a la criptomoneda. Así, se ha pasado de un patrón de cuatro o cinco ceros a patrones de 18 o más ceros, dificultando más la labor del minado.
4.1.2. Funcionamiento de una transacción Bitcoin¶
¿Cómo funciona una transacción Bitcoin realmente? Vamos a introducir este aspecto con un ejemplo. Supongamos que en la cadena de Bitcoin existen una serie de transacciones destinadas a un usuario Juan:
Emisor | Destinatario | Cantidad |
---|---|---|
Ana | Juan | 0.3 BTC |
Gabriel | Juan | 0.25 BTC |
Susana | Juan | 0.1 BTC |
Pedro | Juan | 0.6 BTC |
Imaginemos que, en un momento determinado, Juan quiere adquirir cierto producto por 0.83 BTC. ¿Cómo podría hacerlo? En el ámbito de las criptomonedas no existe el concepto de saldo propiamente dicho. Es decir, aunque tenemos un wallet disponible con nuestras transacciones, no podemos acumular las cantidades de las transacciones anteriores y decir que Juan tiene 1.25 BTC. Lo que tenemos es una serie de UTXOs (Unspent Transaction Output), de transacciones no gastadas de las que podemos hacer uso. Por tanto, lo que tendremos que hacer es transformar unas transacciones en otras. Así, para poder comprar el producto por 0.83 BTC, Juan tendría que agrupar transacciones por un valor igual a ése (o superior), y reemplazar las viejas transacciones por la(s) nueva(s). Por ejemplo, podría tomar la segunda y cuarta transacción de la tabla y reemplazarlas por dos nuevas transacciones:
- Una de 0.83 BTC a la tienda donde se encuentra el producto a comprar
- Otra con el resto (0.02 BTC) de vuelta a Juan
De este modo, el registro de transacciones para Juan quedaría actualizado así:
Emisor | Destinatario | Cantidad |
---|---|---|
Ana | Juan | 0.3 BTC |
Susana | Juan | 0.1 BTC |
Juan | Juan | 0.02 BTC |
Podemos comprobar el funcionamiento real de este proceso en la página oficial de Blockchain, con el explorador de transacciones.

En el caso de que la suma del valor de salida (0.83 + 0.02 en el caso anterior) sea inferior al valor de entrada (0.6 + 0.25), la diferencia se transforma automáticamente en tasa de la transacción, una gratificación adicional que se añade a la transacción para que los mineros la elijan por encima de otras.
4.2. Ethereum¶
Ethereum es otra criptomoneda, cuya moneda asociada se llama Ether, ideada en este caso por el programador ruso Vitalik Buterin en 2013. Inicialmente, Buterin pretendía definir un lenguaje de programación que permitiera crear programas en Bitcoin pero, ante la imposibilidad de hacerlo, definió su propia criptomoneda con ese propósito. Es decir, Ethereum es básicamente una plataforma para que, quien quiera, pueda crear y ejecutar programas utilizando la tecnología Blockchain. Esto permitirá utilizar toda la potencia computacional de los ordenadores de la red para ejecutar aplicaciones de forma distribuida.
4.2.1. Los smart contracts¶
Un smart contract (contrato inteligente) es un programa que se ejecuta en una cadena de bloques. Normalmente contienen cierta lógica interna y algunos datos que manipular, y la lógica se ejecuta automáticamente si se cumplen ciertos criterios especificados en el smart contract.
Existen varios lenguajes de programación directamente vinculados a la tecnología Blockchain. Así, por ejemplo, el lenguaje Bitcoin Script permite definir transacciones en la cadena Bitcoin. Por su parte, el lenguaje de programación para Ethereum se llama Solidity. A diferencia del lenguaje anterior, Solidity es un lenguaje Turing completo, es decir, permite construir cualquier algoritmo con las instrucciones de que dispone (Bitcoin script no lo es, porque carece de bucles, por ejemplo).
En una cadena Ethereum, por tanto, cada nodo de la red tendrá disponibles todos los smart contracts de la cadena (además de otras transacciones que pueda haber), junto con el estado actual de cada uno.
¿Qué ocurre si un programa tiene código malicioso, como un virus o un malware que quiere acceder a los ficheros locales? ¿O si contiene un código poco eficiente que hace que el ordenador se ralentice ejecutándolo? En primer lugar, Ethereum se ejecuta sobre una máquina virtual propia, con lo que la ejecución del código está encapsulada y no tiene acceso al exterior de esa máquina virtual. En segundo lugar, en lo relativo a la eficiencia, cada operación que se realiza en un smart contract tiene asociado un coste, en una unidad llamada Gas (haciendo un símil con la gasolina o combustible necesario para ejecutar el programa). Así, operaciones simples, como una operación aritmética, consumen poco Gas, y otras más complejas necesitarán más. Si un programa no es eficiente y realiza demasiadas operaciones, al desarrollador le va a suponer un gasto excesivo en Gas.
4.2.2. Los tokens y las ICOs¶
Algunas criptomonedas se fundamentan en un concepto adicional, el de ICO (Initial Coin Offering). Es un concepto análogo a las IPOs (Initial Public Offerings), donde las empresas ponen a la venta acciones para que futuros accionistas las adquieran y así la empresa amplíe el capital disponible para su funcionamiento. En el caso de las ICOs, se trasladan todos estos conceptos a un sistema virtual descentralizado. En este caso, los usuarios que quieran participar del funcionamiento de la empresa lo que adquieren son tokens, una especie de moneda asociada, con la que pueden, por ejemplo, adquirir servicios ofrecidos por esa empresa. Se intercambia el dinero de la criptomoneda en sí (por ejemplo, Ether en el caso de Ethereum) por una cantidad de tokens determinada. A diferencia de las IPO clásicas, en una ICO los nuevos usuarios no adquieren una parte del control de la empresa; sólo acceso a sus servicios, o incluso la posibilidad de almacenar los tokens esperando un futuro aumento de su precio para venderlos y ganar dinero.
Los tokens son elementos a menudo vinculados a los smart contracts, y por tanto, no todas las criptomonedas los generan. En webs como la que hemos comentado antes podemos ver tanto la situación actual de la criptomoneda en general (el protocolo) como de los diferentes tokens asociados. Como usuarios, tendríamos la opción de invertir tanto en el protocolo general (Ethereum, por ejemplo) como en un token en particular (por ejemplo, el token Tronix (TRX) de Ethereum). Aquí, por ejemplo, podemos ver qué proyectos se están financiando con ICOs actualmente y en un futuro próximo.
4.3. Otras criptomonedas¶
Para terminar este apartado vamos a analizar brevemente algunas otras criptomonedas existentes y sus principales usos.
- Ripple: criptomoneda lanzada en 2012, y que ha tenido una gran repercusión en el sector bancario y algunas empresas, que la han adoptado como forma válida de pago. Su moneda asociada es XRP, se emplea como moneda de cambio: podemos intercambiar moneda real, o determinados servicios. A diferencia de Bitcoin, su forma de minado no consume tantos recursos energéticos ni de cómputo.
- Litecoin: versión simplificada y más eficiente de Bitcoin, lanzada en 2011
- Stellar: criptomoneda para intercambio multidivisa, lanzada en 2014
- Neo: criptomoneda lanzada en 2014 para permitir una red de aplicaciones descentralizadas, al estilo de Ethereum, pero ofreciendo una amplia gama de lenguajes disponibles.
5. Limitaciones actuales de Blockchain¶
Algunas de las principales limitaciones que podemos encontrar hoy en la tecnología Blockchain son las siguientes:
- Es una tecnología relativamente inmadura, lo que implica problemas de estandarización o regulación. De hecho, no se dispone aún de ningún estándar oficial, aunque instituciones como IEEE o ISO están recopilando información para confeccionarlo, para darle aún más soporte.
- Presenta ciertos problemas de privacidad, derivados de la transparencia que se quiere ofrecer. El hecho de que las transacciones sean públicas y accesibles por cualquiera provoca que se pueda tener acceso a ciertos datos personales, algo que no es viable en sistemas financieros, legales o médicos. Ligado a esto, una tecnología denominada de conocimiento cero (zero-knowledge) se está vinculando a Blockchain para construir bloques que permitan omitir esta información delicada.
- La interoperabilidad, tanto entre distintas cadenas como con instituciones, que habitualmente tienen sus datos almacenados en otros sistemas, y resulta difícil sincronizar o compatibilizar esa información con la que se almacena en los bloques.
Además, hay que tener en cuenta que no todo tiene que ser descentralizado o distribuido. Dependiendo de los requerimientos del sistema a desarrollar, es posible que nos interese implementar un sistema tradicional centralizado. Por ejemplo, sistemas donde las actualizaciones sean frecuentes y críticas, o donde el rendimiento en el acceso a los datos actualizados sea crucial, interesará centralizar ese acceso para hacerlo más rápido y evitar tiempos de latencia adicionales propagando las actualizaciones por todos los nodos de la red.