Conceptos Blockchain #1: Cadena de bloques & Trazabilidad

Conceptos básicos y su aplicación a problemáticas de trazabilidad.

 ÍNDICE

1. Introducción
2. Cadena de bloques
3. Trazabilidad en automóviles
4. Conclusiones

1. Introducción

Pocas cosas han despertado más interés en el Sector TIC en los últimos tiempos que la tecnología de Cadena de Bloques o, en su denominación inglesa, “Blockchain”. Surge a partir de un artículo publicado en 2008 sobre Bitcoin (Nakamoto, Satoshi, 24 de mayo de 2009. “Bitcoin: A Peer-to-Peer Electronic Cash”).

No es la primera vez en la historia de la informática que una aplicación crea toda una tecnología, pero también es cierto que las expectativas generadas superan con creces lo que se podía esperar de un artículo científico.

Sin embargo, la gran cantidad de material publicado sobre el tema oscila entre dos (2) extremos:

• La descripción de la revolución que va a suponer la tecnología Blockchain en nuestras vidas y hábitos como ciudadanos o profesionales.
• El detalle del soporte matemático, criptológico y tecnológico en el que se fundamenta Blockchain.

En ninguno de los dos (2) extremos es fácil comprender lo que se encierra bajo la Blockchain. Con esta serie de artículos no pretendemos decir nada que no se haya dicho ya, pero sí modificar el enfoque, facilitando la compresión del lector y utilizando casos de uso concretos para ilustrar los conceptos.

Blockchain persigue dar respuesta al problema de la Gestión de la Confianza en un mundo cada más interconectado, global e impersonal. La idea base es simple: disponer de un sistema de acceso a la información que sea veraz en sí mismo y, por lo tanto, no manipulable, multiusuario, dotado de mecanismos de consenso, replicable y destinado a una finalidad concreta. Se trata de habilitar un sistema de información válido para los participantes directos en un negocio, las entidades que lo regulan, las que lo financian, las que lo aseguran y las que lo auditan. Esto es lo que se denomina Confianza Distribuida.

Para dar respuesta a este reto, Blockchain utiliza tecnologías ampliamente probadas en el mundo de las TIC, como criptografía de clave pública / privada, funciones hash criptográficas, archivos distribuidos y replicados, algoritmos de consenso y proceso descentralizado. Los elementos clave de Blockchain son:

• Cadena de Bloques.
• Red entre iguales (peer to peer).
• Archivos distribuidos y replicados.
• Algoritmos de consenso.
• Firmas criptográficas.
• Contratos inteligentes.

Para la implementación de una aplicación Blockchain las opciones técnicas a menudo son el resultado del modelo de gobernanza elegido para el ecosistema de los participantes. 

Este primer artículo explicaremos el concepto de Cadena de Bloques.

2. Cadena de bloques

Una Blockchain es una estructura de datos soportada en diversos instrumentos (archivos planos, bases de datos, …), que organiza la información en bloques, no necesariamente homogéneos, unidos por un pegamento criptográfico, que garantiza que la información no puede alterarse sin que se detecte. Este pegamento se implementa mediante funciones de hashing.

2. 1. HASH

Un algoritmo hash es una función de una sola vía que genera una cadena de longitud fija a partir de unos determinados datos de entrada, que generalmente, es mucho más pequeña que los datos originales. Las propiedades de este tipo de algoritmos son:

• Los algoritmos hash están diseñados para ser resistentes a colisiones, lo que significa que hay una probabilidad muy baja de que la misma cadena sea el resultado de diferentes datos de entrada.
• El más mínimo cambio en los datos de entrada genera un hash muy distinto.
• La obtención de los datos de entrada a partir del hash resultado es muy compleja (criptoanálisis) y la posibilidad de crear unos datos que generen un determinado hash es aún menor.
• Dos de los algoritmos hash más comunes son el MD5 (Message Digest Algorithm 5) y el SHA (Secure Hash Algorithm).

No vamos a detallar el funcionamiento de los algoritmos de hash (ver https://es.wikipedia.org/wiki/Secure_Hash_Algorithm), pero sí vamos a ejemplificar la extrema sensibilidad que tienen ante cambios en los datos originales:

• Vamos a usar el algoritmo SHA-256 (64 caracteres hexadecimales) que con:
  • Dato de entrada: “Esto es para un artículo de Blockchain”
  • Se obtiene el hash:
    

    “b542920a8f0e628d8ac2a756fbd3c8c2fb5696a0ed11c856a70f349f5b72d849“

• Y con el siguiente (se añade un punto al final):
  • Dato de entrada: “Esto es para un artículo de Blockchain.”
  • Se obtiene el hash:
    

    “e86b8d45702835b50ddf70d530c7836b6f5b298022eda9273b1f69dded733be8”

Como se puede apreciar, no tiene nada que ver con el anterior, lo que lo confirma como un gran detector de cambios.

2. 2. ENCADENAMIENTO

En la siguiente figura se explica el funcionamiento de este pegamento criptográfico:

Se puede observar que para cada Bloque de datos se genera un hash, que se deriva de:

• La propia información que se almacena en el Bloque (sus datos).
• Y del hash del bloque anterior.

Esto supone que la información que se recoge en la Blockchain no puede alterarse sin que se note, porque todos los Bloques y, por lo tanto, toda la información que contienen, están relacionados entre sí (encadenados). Si se cambiara un solo bit en un bloque, la estructura encadenada de hash se volvería inconsistente y por lo tanto evita que su manipulación pase inadvertida. De aquí se deriva la denominación de “Cadena de Bloques”.

2. 3. ARBOL DE MERKLE

Vamos a decir qué es y luego para qué nos vale.

Existe un segundo pegamento criptográfico, mucho más sutil, que facilita darle forma o estructura, a la cadena lineal de datos: es el árbol de Merkle de los códigos hash. Un árbol de Merkle es un árbol binario (dos ramas en cada nodo) en el que en cada nodo tiene un código hash. En la base del árbol se tienen los códigos hash correspondientes a los datos de los bloques, y en los nodos superiores el hash suma de los nodos hijos. De esta manera, en la raiz del árbol se tiene un código que garantiza que la información de los nodos que están por debajo no ha sido alterada.

Un poco de matemáticas. Si construimos un árbol binario completo con N elementos en la base, se tiene:

• La altura del árbol tiende a ser: Log ₂ N
• El número total de nodos es 2N.

Es decir que, si tuviésemos 1.000 elementos en la base, la altura del árbol sería de 12 niveles y el número total de nodos 2.000.

Por el contrario, si tuviésemos 1.000.000 de elementos en la base la altura del árbol sería de 21 niveles y el número total de nodos 2.000.000.

¡Y ahora para qué sirve!

Uno de los usos es que permite aportar una estructura de relación entre nodos (aquí serían bloques funcionales). Esta estructura facilita el que no haya información duplicada en diferentes bloques, quedando ésta sustituida por el “enlace” al nodo que la contiene, directamente o en un item jerárquico superior (ver esquema anterior aplicado a los coches).

Ahora que ya habemos lo que son los hash, los bloques encadenados y los árboles de Merkle, ¿para qué sirve todo esto? Lo vemos con un caso de uso.

3. Trazabilidad en automóviles

Un automóvil actual tiene entre 80 y 100 K piezas elementales pero, en general, no más de 5.000 componentes inventariables (Part Number). Los componentes se integran en subconjuntos, conjuntos y sistemas para llegar a los siete (7) sistemas principales de un automóvil: motor, tren propulsor, llantas, ruedas y frenos, suspensión, dirección, sistemas eléctricos, electrónicos y de confort y carrocería y chasis.

Aunque cada vehículo se puede personalizar mucho, la unidad que finalmente se fabrica tiene un conjunto cerrado de características, que puede ser descrito mediante un archivo p.e. XML que se deriva de la ingeniería del vehículo. Este archivo XML describiría con mucha precisión:

• La composición de subconjuntos, conjuntos y sistemas. Elementos físicos y lógicos.
• Las operaciones que se realizan en la cadena de montaje.

¿Y si aprovechásemos que el vehículo puede ser descrito y referenciado como un árbol binario de componentes y operaciones y asignamos a cada nodo de ese árbol un código hash?:

• De los datos que se requieren de cada componente (nodos de componente).
• Los códigos hash que se derivan de la unión de dos (2) nodos hijos (nodos operativos o mudos).

De esta forma, en cada nodo de la base del árbol se tendría información del: Part Number, Serial Number, Lote, Fabricante, Equipo instalador, Fecha instalación, Operario, Verificaciones de Control de Calidad, …

Conforme se fuera montando el vehículo, se irían rellenando los datos de todos los componentes para, al final por agregación, llegar a la raíz (en realidad, cima) del árbol, donde se tendría el código que identifica, no sólo al vehículo, sino a todos los componentes que lo integran y todas las operaciones realizadas. Las ventajas de disponer de esta información serían muy significativas para todos los participantes en la cadena de valor de un automóvil: fabricante, compradores, proveedores de componentes o servicios, ITV’s, Policía de Tráfico, Agencia Tributaria, …

Pero un vehículo no es un activo estático: pasa revisiones, se avería y se le cambian las piezas, tiene incidentes, se vende a otro titular, paga impuestos, … ¿Cómo compatibilizar la enorme ventaja que aporta la inmutabilidad de los datos de una Blockchain, con la necesidad de cambiar las características del vehículo a lo largo de su vida?

El árbol binario de Merkle que define al vehículo no se puede tocar una vez fabricado y matriculado. Si se permitiera actualizar los datos, se perdería la integridad de la Blockchain, que se volvería inútil. ¿Cuál es la solución? Extender en horizontal el árbol para cambiar un componente. Este último se referiría al componente que ha sustituido que, aunque ya no está incorporado al vehículo, sigue siendo necesario para mantener la integridad del árbol. Gráficamente sería así:

El componente N14.1 sustituye al N14, pero en su hash incorpora el hash del N14 original, lo que le permite referirse a él, pero sin participar en el algoritmo de cálculo de la raiz del árbol binario.

El problema no es tan sencillo, porque pudiera suceder que se eliminen componentes, lo que no es especialmente complicado, o que se creen otros nuevos, lo que supondría la necesidad de habilitar inicialmente nodos mudos o vacíos donde poder conectar estos nuevos componentes.

Por ejemplo, para la gestión de averías en un taller homologado del fabricante, el uso de la Blockchain sería el siguiente (leer el esquema de izquierda a derecha):

1. El vehículo se le entrega al comprador, junto con toda su documentación, que queda recogida en la Blockchain. Además, se crea una estructura de Bloques con los datos de todos los componentes y operaciones realizadas para la fabricación del vehículo.
2. En un momento determinado, el vehículo sufre una avería y es llevado a un taller homologado por el fabricante. El taller lee de la Blockchain los datos de todos los componentes afectados por la avería y pide al proveedor de componentes su suministro.
3. El proveedor comprueba en la Blockchain que, efectivamente son los componentes correspondientes a ese vehículo, pero cambia uno de ellos porque está ya descatalogado y es funcionalmente equivalente, cosa que permite el sistema de calidad.
4. El proveedor envía los componentes al taller y sitúa los mismos “en tránsito”. El taller puede seguir el pedido. Cuando se recibe se anota un albarán en la Blockchain.
5. El taller instala los nuevos componentes, actualizando la Blockchain. El proveedor detecta que se ejecuta el “contrato inteligente” vinculado al pedido y factura al taller.
6. Finalmente, el fabricante envía una encuesta de calidad al dueño del vehículo. La encuesta se recoge de manera anónima en la Blockchain.

4. Conclusiones

Las ventajas que aporta el uso de esta tecnología son muy importantes para todos los participantes:

• Los diferentes dueños saben en todo momento cómo está su vehículo, que las piezas son originales, que los costes están dentro de los estándares, el tiempo de reparación, las facturas recibidas y pagadas, …
• El taller dispone de la composición exacta del vehículo, con la personalización realizada, las piezas que necesita y donde las puede solicitar, el tiempo de tránsito, reparaciones previas realizadas por terceros, …
• El proveedor sabe cuándo se reciben los componentes, cuando se integran, el resultado de las pruebas, las estadísticas de fallos y no calidad de sus componentes, …
• El fabricante tiene información en tiempo real de la situación de su flota, de sus proveedores, de los talleres, de los incidentes y accidentes, …
• La ITV sabría si se ha instalado un componente no homologado o si dos componentes tienen el mismo número de serie o si un vehículo no es el que dicen los documentos presentados.
• La Agencia Tributaria controlaría que se facturan todos los componentes instalados.

Toda esta propuesta sería totalmente aplicable a la industria aeronáutica o naval, con la consideración de que el número de componentes de un avión comercial o de un buque es mucho mayor que en un turismo.

En el próximo artículo trataremos de la Gestión de la Confianza y el Consenso.