logo kolokium original

Infraestructuras para Hyperledger Fabric (1)

Este es el primero de una serie de artículos que tratan sobre las infraestructuras para Hyperledger Fabric y los tipos de despliegue que hacen posible el funcionamiento de este tipo de redes, o varias de ellas cuando comparten y gestionan datos en común.

Introducción

Comenzaremos dando una explicación del funcionamiento de los principales elementos de Hyperledger Fabric, con el fin de que podamos entender qué papel y qué importancia tiene cada uno de ellos. 

Con esta explicación previa, abordaremos los posibles despliegues que se pueden hacer usando infraestructuras en la nube y teniendo en cuenta la seguridad y la resiliencia del sistema.

Finalmente, veremos cómo es el ciclo de vida de las redes Hyperledger Fabric y cuáles son los procedimientos necesarios para llevar a cabo distintas operaciones sobre los elementos que las conforman.

Sin embargo, antes de que vayas a hacer un despliegue en la nube o en tus propios servidores, quizás debas considerar algunos aspectos a tener cuenta, tal como te explicamos en nuestro post Top 5 de buenas prácticas para Hyperledger Fabric. 

Despliegue de una red Hyperledger Fabric con la herramienta KolBLM de Kolokium
Despliegue de una red Hyperledger Fabric con la herramienta KolBLM de Kolokium

Qué es una organización en Hyperledger Fabric

Lo más sencillo para entender qué es una organización dentro de Hyperledger Fabric es equipararla al concepto de organización empresarial. Es decir, es una entidad con unos intereses concretos, unas necesidades propias, un personal contratado y, por qué no, unas necesidades de privacidad particulares. Desde luego, no es la definición que nos daría  la RAE, pero todos estos aspectos son necesarios destacarlos dado que pueden tener cierta relación con el funcionamiento de nuestro sistema

Qué es el servicio de ordering en Hyperledger Fabric

De nuevo, vayamos a una definición sencilla. El servicio de ordering se encarga de hacer una validación previa de las transacciones que se quieren incluir en la blockchain. También determina el orden en que se almacenan los bloques  y cuántas transacciones tienen cada uno. Tiene otras funciones relacionadas con la organización y sincronización de los peers. 

Hay que hacer notar que el servicio de ordering no tiene por qué pertenecer a una sola organización, es decir, puede estar participado por más de una organización, formando lo que se llama un “consorcio”. 

Un consorcio tiene unas reglas preestablecidas para la decisión sobre el orden y contenido de los bloques. Son reglas sencillas, del estilo: deben votar todas las organizaciones, sólo una de ellas o la mayoría. 

El servicio de ordering es crucial en este tipo de blockchains, pues son el centro neurálgico de todas las interacciones y el punto principal de gestión del funcionamiento. Sin duda, se trata de uno de los elementos diferenciadores de otras tecnologías de distributed ledger.

Qué es un canal y qué tipo de datos maneja

Pensemos en los canales de Hyperledger Fabric como sistemas de almacenamiento de información separados unos de otros. 

Los chaincodes (que son los smartcontracts de Hyperledger Fabric) se ejecutan sobre un canal determinado, es decir, pueden modificar los datos solo de ese canal. Pero esto no les impide consultar los datos de otro canal a través de un chaincode de aquel que implemente una función de consulta. 

Para que un mismo chaincode pueda gestionar los datos de varios canales, debe ser instalado en todos ellos siendo, por tanto, instancias distintas del mismo programa.

Los chaincodes son los programas desarrollados para realizar todas las funciones y lógica de negocio. Pueden estar desarrollados en distintos lenguajes de programación y se instalan y ejecutan en los nodos (llamados “peers”).

Los peers de Hyperledger Fabric ejecutan un doble papel en el funcionamiento de un canal: por un lado ejecutan los chaincodes cuando alguien los invoca y por otro validan los bloques que vienen aprobados desde el servicio de ordering. Es en este último paso cuando almacenan los bloques en su copia de la blockchain y modifican los datos.

Los elementos de información que gestionan los peers son:

World state

Es la base de datos “tradicional” que gestiona los chaincodes. Son bases de datos NoSQL, que almacenan los datos en formato JSON o key/value. Cada peer tiene y mantiene su propia copia de la world state.

Blockchain

Es la cadena de bloques que ya conocemos: contiene bloques enlazados entre sí y cada bloque contiene un número variable de transacciones. El contenido y el orden de los bloques está organizado por el servicio de ordering mencionado un poco más arriba. Igual que ocurre con la world state, cada peer tiene y mantiene su copia de la blockchain.

Además, los orderers tienen su propia copia de los blockchain de cada canal que gestionan. Sin embargo, ningún orderer tiene acceso a las bases de datos World state, solo los peers y sus chaincodes pueden acceder.

Puedes profundizar más en el funcionamiento de los canales y los peers directamente desde la documentación del proyecto de Hyperledger Fabric

Transacciones en Hyperledger Fabric

Una transacción es una modificación o lectura que se quiere hacer de un dato concreto contenido en la world state. Una transacción debe pasar por una serie de estados hasta que se aprueban:

  • La aplicación del usuario elige qué peers de los que tienen el chaincode instalado van a ejecutar la función deseada.
  • Cade peer ejecuta el código de la llamada y devuelve el resultado firmado con su propia identidad. 
  • La aplicación cliente crea una propuesta de transacción uniendo las firmas de todos los peers a los que ha pedido la ejecución
  • El servicio de ordering recibe esa propuesta de transacción desde la aplicación cliente, comprueba su validez, la añade al bloque que toque en ese momento y lo distribuye entre todos los peers del canal. 
  • Son estos últimos los que hacen la comprobación de integridad del dato que se quiere modificar y comprueba que la transacción es coherente. En caso de estar todo correcto, almacena la transacción como válida y modifica la world state. En caso contrario, no modifica la world state y almacena la transacción como no válida.

Como habrás visto, es un sistema complejo que permite tener un acuerdo de consenso entre todos los elementos, asegurando que la información está distribuida y protegida donde debe estar. En todo momento se mantiene la integridad de los datos aunque estemos en un entorno de ejecución distribuida y, sobre todo, se mantiene la trazabilidad del dato y de dónde ha salido cada transacción.

Quizás uno de los puntos más curiosos del sistema es que la aplicación nunca recibe un resultado correcto o incorrecto sobre la ejecución del chaincode. La aplicación externa solo puede “encargar” la ejecución y hacer una propuesta más tarde, pero durante el proceso no se le devuelve un ACK indicando si todo ha ido bien.

Por lo tanto, es responsabilidad de la aplicación externa saber si todo ha ido bien. En los próximos artículos iremos desgranando más partes del sistema y cómo resolver este punto.

Pensemos en un caso sencillo: una sola organización, con un canal (por lo tanto un servicio de ordering) y un chaincode muy sencillo que se ejecuta sobre dos peers.

  • Una aplicación externa llama al chaincode que está siendo ejecutado en el peer1.
  • El peer1 ejecuta la operación y genera una propuesta, la firma y la envía de vuelta a la aplicación.
  • La aplicación construye una Tx con la propuesta recibida por el peer1 y la firma.
  • La aplicación envía la Tx al servicio de ordering.
  • Como es el único orderer de la red, la transacción es inmediatamente recibida e introducida en un bloque. Este se distribuye firmado también por el orderer a ambos peer.
  • Estos validan la transacción y almacenan el bloque que ha enviado el orderer en su blockchain. En el blockchain se guarda siempre, tanto si válida como si no.

Identidades digitales

Y por último, hablamos de las identidades digitales en Hyperledger Fabric.

Es bien sabido que Hyperledger Fabric es una tecnología blockchain permisionada. Cuando decimos permisionada queremos indicar que no cualquiera puede acceder a cualquier recurso: ni a los bloques de las blockchains de los canales, ni al world state, ni cualquiera puede proponer un cambio de configuración en la red.

Sin embargo, no existe una base de datos centralizada de usuarios, ni un servicio de directorio para esta labor.

Todos los permisos se gestionan en base a los certificados digitales x509 que presenta el elemento que quiere interaccionar con la red:

  • Si un orderer quiere pertenecer a un servicio de ordering, tiene que presentar un certificado x509 que previamente haya sido aprobado.
  • Si un peer va a hacer una propuesta de transacción, debe firmarla con su certificado, y los orderers validarán si ese certificado es válido y tiene los atributos adecuados.
  • Si un programa de un cliente quiere hacer una llamada a un chaincode para usar alguna de sus funciones, debe presentar un certificado de identidad con ciertas características. En este caso, es el chaincode quien puede implementar distintos tipos de validaciones previas a la ejecución del código.

Por lo tanto, es imprescindible tener desplegado un sistema PKI x509 para entregar certificados digitales a cada elemento del sistema.

Además, en diversas operaciones, también se usan certificados x509 para establecer comunicaciones cifradas con TLS.

Para facilitar esta labor, el proyecto Hyperledger Fabric provee un gestor de identidades x509 llamado Hyperledger Fabric CA server, pero su uso no es obligatorio: si sabemos hacer un despliegue de certificados de este tipo, podemos utilizar nuestras propias autoridades certificadoras y certificados para hacer funcionar la red.

Más adelante, veremos cuán importante es gestionar adecuadamente el despliegue de certificados, pues la seguridad de todas las operaciones depende en gran medida de cuán celosos seamos de salvaguardarlo.

Derivado de la idea de identidades digitales, definimos el servicio de membresía (MSP o Membership service provider) como un conjunto de configuraciones y ficheros que define una blockchain Hyperledger Fabric. Estas configuraciones son copiadas en todos los miembros de la red para que sepan cómo deben interactuar con la misma, qué certificados son válidos y algunos otros detalles.


En los próximos artículos discutiremos las siguientes cuestiones:

  • Si el servicio de ordering es tan importante, ¿cómo puedo desplegarlo para que sea resiliente y tolerante a fallos?
  • ¿Puede el servicio de ordering añadir más nodos mientras está funcionando? ¿Pueden ser estos orderers de otras organizaciones?
  • ¿Cuántos peers debo desplegar para tener un servicio a prueba de fallos?
  • ¿Puede un chaincode ejecutarse en peers de distintas organizaciones?
  • ¿Cómo de importante es la autoridad certificadora? ¿Hay que protegerla de alguna forma especial?
  • ¿Qué medidas de ciberseguridad hay que implementar en una Hyperledger Fabric?

Juanma Muñoz
Juanma Muñoz

Últimas Noticias

Categorias

Trabaja con Nosotros

En Kolokium estamos siempre buscando talento, gente inquieta que no le tenga miedo a los retos, si quieres trabajar con tecnologías Blockchain.

INNOVACIÓN

COLABORAMOS EN INICIATIVAS PÚBLICO/PRIVADAS ORIENTADAS A EXPLORAR LAS POSIBILIDADES DE LA TECNOLOGÍA BLOCKCHAIN EN DISTINTOS HÁBITO INDUSTRIALES Y CORPORATIVOS
neotec

PRIOPS

El proyecto PRIOPS ha recibido el apoyo del CDTI por medio de su programa Neotec 2018, en el que se le ha concedido una subvención de 247.618 €

apia

APIA

Plataforma integral para la auditoría inteligente de obra civil basado en la captura y parametrización automática de identidades de obra en el modelo de información BIM y la certificación mediante Blockchain de su producción, financiado por el CDTI y cofinanciado por el FEDER

Consorcio: AZVI, EMERGYA, GRANT THORNTON Y KOLOKIUM
Plazo de ejecución: septiembre de 2018 a diciembre 2020
Presupuesto Total: 2.218.874,00€

k1

K 1

Framework para la generación y despliegue automatizado de smart contracts en arquitecturas distribuidas Ethereum e Hyperledger Fabric. Proyecto financiado con el apoyo

K1_FRAMEWORK PARA LA GENERACIÓN Y DESPLIEGUE AUTOMATIZADO DE SMART CONTRACTS EN LOS BLOCKCHAINS DE ETHEREUM E HYPERLEDGER del CDTI con fondos propios a través de la convocatoria INNOGLOBAL 2017 y apoyado por el Ministerio de Economía, Industria y Competitividad.

Consorcio: KOLOKIUM BLOCKCHAIN TECHNOLOGIES y GRUPO CADENA (Colombia)
Plazo de ejecución: octubre de 2017 a septiembre de 2019
Presupuesto KOLOKIUM: 381.440€

Logos Paravasis

PARAVASIS

PARAVASIS es un proyecto Subvencionado por el CDTI que ha sido apoyado por el Ministerio de Ciencia e Innovación, y que investiga en nuevas tecnologías para que haya una mejora sustancial en la flexibilidad y productividad del proceso de diseño y desarrollo de sistemas industriales complejos favoreciendo la personalización de nuevos productos intensivos en software y considerando además el mejor balance de tiempo, capacidad y coste, así como la seguridad.

Consorcio: Ghenova Digital, DHG, Integrasys, Cotesa, Capgemini Engineering, Optiva Media, Kolokium y Komorebi.

Plazo de ejecución: 01/10/2022 – 30/06/2025

Presupuesto Global: 5.364.425,00 €
Presupuesto Kolokium: 437.163,00 

Logos Valrec

VALREC

El objetivo principal del Proyecto VALREC es la investigación industrial y la demostrar nuevas soluciones avanzadas y de coste efectivo que garanticen un cierre de ciclos más eficiente y trazable (incremento de la confianza de materiales secundarios en el mercado) de grandes volúmenes de recursos materiales de construcción mayoritarios (principalmente hormigón, cerámico y yeso) a lo largo de toda la cadena de suministro de los mismos.
El proyecto VALREC “Soluciones innovadoras para fomentar la VALorización de RCD y la utilización de materiales Recuperados bajo criterios de Economía Circular en la CAM” ha sido subvencionado a través de la Convocatoria 2020 de las ayudas cofinanciadas por el Fondo Europeo de Desarrollo Regional para contribuir a la mejora de la Cooperación Público - Privada en materia de I+D+i mediante el apoyo a Proyectos de Innovación Tecnológica de efecto tractor elaborados por núcleos de innovación abierta en la Comunidad de Madrid, en el marco de la Estrategia Regional de Investigación e Innovación para una Especialización Inteligente (RIS3), dentro del Programa Operativo FEDER de la Comunidad de Madrid para el periodo 2014-2020.
Consorcio: SURGE AMBIENTAL (SURGE), VALORIZA SERVICIOS MEDIOAMBIENTALES (VSM), ADCORE, KOLOKIUM BLOCKCHAIN TECHNOLOGIES, ALLGAIER MOGENSEN, SODIRA IBERIA, SIKA, HORMICRUZ, GREEN BUILDING COUNCIL ESPAÑA (GBCe).
Plazo de ejecución: 17/11/2021 - 17/11/2023
Presupuesto Global: 4.063.243,14 €
Presupuesto Kolokium: 256.700,00 €

KOLBLM

Completa el formulario para descargar​

KOLBI

Completa el formulario para descargar​

KOLFSB

Completa el formulario para descargar