Cloud Híbrida
Ciberseguridad & NaaS
AI & Data
IoT y Conectividad
Business Applications
Intelligent Workplace
Consultoría y Servicios Profesionales
Pequeña y Mediana Empresa
Sanidad y Social
Industria
Retail
Turismo y Ocio
Transporte y Logística
Energía y Utilities
Haciendo más fácil lo que parece difícil: la trazabilidad con blockchain de la cadena de suministro
13 de marzo de 2018
Discusiones sobre la tecnología de la cadena de bloques tienen una presencia cada vez mayor en nuestro entorno. Los nuevos casos de uso van acaparando cada vez más páginas de medios generalistas y muchos tienen la sensación de que quien no haya comenzado a definirlos parece que llega tarde. Sin embargo, muy poco tiempo después de que las organizaciones se lancen a invertir parte de sus recursos en ver cómo Blockchain puede ayudarles en determinados procesos de su negocio, comienzan las preguntas.
Una de las típicas cuestiones que se formulan quienes empiezan a considerar la posibilidad de implantar la tecnología es la de tomar la decisión sobre optar por cadenas de bloques públicas o privadas. En el caso de que optemos por apoyarnos en una cadena de bloques pública, ¿tendremos capacidad para estimar correctamente el volumen de transacciones que realizaremos mientras dure el proyecto? ¿Qué implicaciones puede tener el incremento de las comisiones y la volatilidad de la divisa? Si, por contra, optamos por una cadena de bloques privada en la que tengamos más control sobre quién opera con ella, ¿qué tecnología podremos desplegar si tampoco tenemos muy claro para qué la vamos a necesitar? ¿Qué costes tienen las distintas alternativas y qué conllevan?
Ante tantas preguntas, lo mejor es tocar la tecnología. En el Lab de ElevenPaths tenemos como lema que si algo lo oyes, lo olvidas. Si lo ves, lo recuerdas. Pero, en cambio, si lo haces, lo terminas aprendiendo. Con este fin, una de las herramientas que más nos ha ayudado a explicar las posibilidades que ofrece una cadena de bloques permisionada es el proyecto de Multichain.
Un caso de uso: el seguimiento de la cadena de suministro
Imaginemos un caso de cadena de suministro que implica a dos o más organizaciones. En este caso, no podemos confiar en que el registro de todas las operaciones se realice de manera individual dado que la mera existencia de información falsificada o borrada podría tener consecuencias negativas para el resto de actores de la cadena. Sin embargo, sigue siendo fundamental que todos se pongan de acuerdo en ver qué operaciones han tenido lugar para evitar controversias.
Para resolver este problema, necesitamos una base de datos compartida en la que se escriban todos los registros. Cada registro acompañado de un sello de tiempo y una prueba de su procedencia. La solución estándar pasa por crear un intermediario de confianza, cuya función consiste en recopilar y almacenar los registros de forma centralizada. Pero las cadenas de bloques ofrecen un enfoque diferente, dando a las organizaciones una forma de gestionar conjuntamente este archivo, a la vez que impiden que los participantes individuales (o pequeños grupos de ellos) lo corrompan.
En este sentido, nuestra cadena de bloques tendrá el objetivo de realizar la trazabilidad, por ejemplo, de las camisetas creadas por un fabricante hasta que llegan al pequeño comercio para su venta. En este caso tendremos, por tanto, distintos actores:
Figura 1. Parámetros de configuración de 11pathschain.
Para facilitar que un tercero se pueda conectar a nuestra cadena de bloques, deberá instalarse el software de multichain y conectarse a nuestro nodo siguiendo los pasos que ya nos muestra el cliente al arrancar el nodo original.
Sin embargo, no perdamos de vista que estamos trabajando con una cadena de bloques permisionada. Si hemos seguido las instrucciones como hasta hora las nuevas máquinas que se vayan a conectar a nosotros todavía no tienen ningún permiso, ni tan siquiera para conectarse. De hecho, al arrancar el comando anterior en un segundo servidor, el nodo se descargará las reglas del juego de esta nueva blockchain, pero todavía no podrá conectarse.
Figura 2. Inicialización del daemon.
Tras asignar ese permiso, el nuevo servidor ya podrá conectarse para sincronizarse con el resto de la cadena de bloques y, además, podrá recibir y enviar assets en ella. A partir de ahora, desde cualquiera de los nodos conectados a la red, podremos interactuar con la cadena desde la interfaz de línea de comandos y pedirle información, sobre, por ejemplo, qué direcciones tienen permiso de conexión. Esto lo podemos hacer utilizando el comando listpermissions connect.
Figura 4. Listado de permisos de conexión a la cadena 11pathschain.
La emisión de nuevos assets
Para generar la representación en la cadena de bloques de nuestras camisetas recién fabricadas, tendremos que emitir (issue) estos nuevos activos. Hay que tener en cuenta que no todo el mundo debe tener permisos de emisión (en nuestro caso, solamente será el fabricante) y además que esas camisetas recién generadas tendrá que tener permisos de recepción (receive). Esto nos obligará a definir claramente cuáles son los roles que adquirirá cada participante.
Figura 5. Proceso de creación de camisetas en nuestra cadena de bloques. Una vez que las hemos emitido, podremos consultar el saldo de la dirección. En este caso usaremos el comando
getmultibalances, que nos muestra el balance de las direcciones del nodo en el que lo estemos ejecutando y que en este caso solamente incluyen las 1000 camisetas recién emitidas, pero que podrían incluir también otros tipos de assets.
Figura 6. Balance de camisetas por dirección.
Una vez las hemos emitido, ¿cómo podría funcionar el sistema cuando llegue el primer distribuidor a recoger el primer lote de 200 camisetas? El fabricante tendrá que emitir una operación de envío (sendasset) en la que especificará la dirección del distribuidor/destinatario, el tipo de asset y la cantidad a enviar.
Figura 7. Envío de assets a otro operador de la cadena.
En este punto, solo nos quedaría verificar en el nodo del distribuidor la cantidad de camisetas recibidas por parte del fabricante. Este proceso de envío de assets se replicará tantas veces como actores tenga nuestra cadena de suministro con la garantía de que cada operación va a quedar sellada con su correspondiente marca de tiempo en la cadena de bloques que creemos y que estará replicada en todos los nodos que formen parte de la red que la sostiene.
Aunque para un caso real la definición de actores y flujos es fundamental, las opciones de configuración de Multichain son ya de por sí bastante amplias (incluyendo otras opciones que son necesarias como
issuemore o
sendassetfrom) y nos permiten escenificar el funcionamiento de una blockchain permisionada y visibilizar las posibilidades de la tecnología. Esperamos que este ejemplo os haya ayudado a entenderlas pero la pregunta importante sigue ahí presente y la debes responder por tu cuenta: ¿de verdad sabes si Blockchain puede ayudarte en algo?
Ante tantas preguntas, lo mejor es tocar la tecnología. En el Lab de ElevenPaths tenemos como lema que si algo lo oyes, lo olvidas. Si lo ves, lo recuerdas. Pero, en cambio, si lo haces, lo terminas aprendiendo. Con este fin, una de las herramientas que más nos ha ayudado a explicar las posibilidades que ofrece una cadena de bloques permisionada es el proyecto de Multichain.
Un caso de uso: el seguimiento de la cadena de suministro
Imaginemos un caso de cadena de suministro que implica a dos o más organizaciones. En este caso, no podemos confiar en que el registro de todas las operaciones se realice de manera individual dado que la mera existencia de información falsificada o borrada podría tener consecuencias negativas para el resto de actores de la cadena. Sin embargo, sigue siendo fundamental que todos se pongan de acuerdo en ver qué operaciones han tenido lugar para evitar controversias.
Para resolver este problema, necesitamos una base de datos compartida en la que se escriban todos los registros. Cada registro acompañado de un sello de tiempo y una prueba de su procedencia. La solución estándar pasa por crear un intermediario de confianza, cuya función consiste en recopilar y almacenar los registros de forma centralizada. Pero las cadenas de bloques ofrecen un enfoque diferente, dando a las organizaciones una forma de gestionar conjuntamente este archivo, a la vez que impiden que los participantes individuales (o pequeños grupos de ellos) lo corrompan.
En este sentido, nuestra cadena de bloques tendrá el objetivo de realizar la trazabilidad, por ejemplo, de las camisetas creadas por un fabricante hasta que llegan al pequeño comercio para su venta. En este caso tendremos, por tanto, distintos actores:
- El fabricante de las camisetas, que, además de producir las camisetas físicamente, emitirá un nuevo token digital que representará en nuestra cadena a las camisetas.
- Los distintos actores que formen parte de la cadena de distribución de las camisetas, que irán dejando constancia en la blockchain cada vez que traspasen los activos al siguiente actor en la cadena de suministro.
Dado este supuesto, ¿cómo podríamos utilizar Multichain para implementar una sencilla prueba de concepto?
Configuración y permisionado básico
En primer lugar, crearemos nuestra cadena de bloques que se llamará 11pathschain:
ElevenPaths@server1$ multichain-util create 11pathschain
Esto nos generará un fichero params.dat donde indicaremos qué parámetros por defecto queremos para nuestra nueva cadena. Entre ellos podremos configurar distintos aspectos relativos al permisionado de la cadena, es decir, qué permisos estarán activados por defecto, o aspectos relacionados con el protocolo en sí mismo como el tiempo medio que transcurre entre bloques y el tamaño máximo de los mismos.
ElevenPaths@server1$ gedit ~/.multichain/11pathschain/params.dat
Figura 1. Parámetros de configuración de 11pathschain.
Sin embargo, solo hemos configurado las reglas del juego. Ahora tenemos que arrancar el primer nodo de la red inicializando el daemon:
ElevenPaths@server1$ multichaind 11pathschain –daemon
Para facilitar que un tercero se pueda conectar a nuestra cadena de bloques, deberá instalarse el software de multichain y conectarse a nuestro nodo siguiendo los pasos que ya nos muestra el cliente al arrancar el nodo original.
ElevenPaths@server2$ multichaind 11pathschain@XX.XX.XX.XX:2681
Sin embargo, no perdamos de vista que estamos trabajando con una cadena de bloques permisionada. Si hemos seguido las instrucciones como hasta hora las nuevas máquinas que se vayan a conectar a nosotros todavía no tienen ningún permiso, ni tan siquiera para conectarse. De hecho, al arrancar el comando anterior en un segundo servidor, el nodo se descargará las reglas del juego de esta nueva blockchain, pero todavía no podrá conectarse.
Figura 2. Inicialización del daemon.
Para conseguirlo, tendrá que solicitar al administrador de nuestra blockchain permisionada el permiso de conexión. En Multichain esto se hace empleando el comando grant para asignar uno o varios permisos. Por tanto, una vez que el administrador del server1 haya recibido la petición, tendrá que ejecutar un comando como el que sigue:
ElevenPaths@server1$ multichain-cli 11pathschain grant [direccion_blockchain_server2] connect,send,receive
Figura 3. Concediendo permisos a una dirección
Tras asignar ese permiso, el nuevo servidor ya podrá conectarse para sincronizarse con el resto de la cadena de bloques y, además, podrá recibir y enviar assets en ella. A partir de ahora, desde cualquiera de los nodos conectados a la red, podremos interactuar con la cadena desde la interfaz de línea de comandos y pedirle información, sobre, por ejemplo, qué direcciones tienen permiso de conexión. Esto lo podemos hacer utilizando el comando listpermissions connect.
Figura 4. Listado de permisos de conexión a la cadena 11pathschain.
La emisión de nuevos assets
Para generar la representación en la cadena de bloques de nuestras camisetas recién fabricadas, tendremos que emitir (issue) estos nuevos activos. Hay que tener en cuenta que no todo el mundo debe tener permisos de emisión (en nuestro caso, solamente será el fabricante) y además que esas camisetas recién generadas tendrá que tener permisos de recepción (receive). Esto nos obligará a definir claramente cuáles son los roles que adquirirá cada participante.
Figura 5. Proceso de creación de camisetas en nuestra cadena de bloques. Una vez que las hemos emitido, podremos consultar el saldo de la dirección. En este caso usaremos el comando
getmultibalances, que nos muestra el balance de las direcciones del nodo en el que lo estemos ejecutando y que en este caso solamente incluyen las 1000 camisetas recién emitidas, pero que podrían incluir también otros tipos de assets.
Figura 6. Balance de camisetas por dirección.
Una vez las hemos emitido, ¿cómo podría funcionar el sistema cuando llegue el primer distribuidor a recoger el primer lote de 200 camisetas? El fabricante tendrá que emitir una operación de envío (sendasset) en la que especificará la dirección del distribuidor/destinatario, el tipo de asset y la cantidad a enviar.
Figura 7. Envío de assets a otro operador de la cadena.
En este punto, solo nos quedaría verificar en el nodo del distribuidor la cantidad de camisetas recibidas por parte del fabricante. Este proceso de envío de assets se replicará tantas veces como actores tenga nuestra cadena de suministro con la garantía de que cada operación va a quedar sellada con su correspondiente marca de tiempo en la cadena de bloques que creemos y que estará replicada en todos los nodos que formen parte de la red que la sostiene.
Félix Brezo
Equipo de Innovación y Laboratorio de ElevenPaths
Yaiza Rubio
Equipo de Innovación y Laboratorio de ElevenPaths
