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.
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?
