Hyperledger Fabric

¿Qué es Hyperledger Fabric?

Hyperledger Fabric es una implementación de un framework blockchain y uno de los proyectos dentro de Hyperledger. Se caracteriza por tener una arquitectura modular y altos niveles de confidencialidad, resiliencia, flexibilidad y escalabilidad. Como otras plataformas blockchain, tiene un registro compartido, transacciones y smart contracts, que reciben el nombre de chaincode en el caso de Hyperledger Fabric. A diferencia de Ethereum, Hyperledger Fabric es una blockchain permisionada y los participantes de la red deben unirse a través del Membership Service Provider (MSP) o Proveedor de Servicio de Membresía.

Membership Service Provider (MSP)

El MSP es un componente que define las reglas para validar, autenticar y permitir el acceso a la red a una identidad o participante. El MSP usa Certificate Authority (CA) y el interfaz por defecto es Fabric-CA API. Este componente es fácilmente reemplazable lo que hace a Hyperledger Fabric muy flexible a la hora de usar un mecanismo de identificación u otro.

Roles

Hay tres tipos de roles en una red de Fabric:

  • Clients (clientes): son aplicaciones que actúan en nombre de una persona a la hora de proponer transacciones, es decir, permite a los usuarios finales la comunicación con la blockchain.
  • Peers: mantienen el estado de la red y una copia del registro. Dentro de este rol existen dos tipos de peers:
    • Endorsers (“avalista” o “patrocinador”): simulan y avalan transacciones propuestas.
    • Committers (“grabadores”): verifican las propuestas de transacciones y validan el resultado de las transacciones antes de grabarlas en la blockchain.
  • Ordering Service (servicio de ordenación): recibe las transacciones propuestas, las ordena dentro de un bloque que lo transmite a los commiters.

Flujo de transacciones

A continuación, se explica cual es el flujo de las transacciones y como se llega a consenso para indicar que transacciones y en que orden se graban en la blockchain:

1. Propuesta de transacciones

Una transacción se inicia con una aplicación Cliente que envía una propuesta de transacción a una serie de nodos Endorsers.

fabric1

2. Simulación y respaldo de transacciones

Cada uno de los endorsers que ha recibido la propuesta de transacción simula la transacción con el estado actual del registro pero si hacer ningún cambio sobre éste, y genera un paquete denominado RW Set que contiene lista de Reads and Writes (lecturas y escrituras) generados por la transacción simulada. El RW Set es firmado por el Endorser y devuelto a la aplicación cliente.

fabric2.png

3. Ordenación de transacciones

La aplicación cliente envía entonces la transacción firmada por el Endorser y el RW Set al Ordering Service el cual es común para toda la red.

fabric3 (2).png

El Ordering Service ordena las transacciones en un bloque que envía a todos los Committers. Hyperledger Fabric incluye a día de hoy tres mecanismos de ordenación: SOLO, Kafka y SBFT (Simplified Byzantine Fault Tolerance). No entraremos en detalle aunque se cabe decir que SOLO está pensado para utilizar durante la etapa de desarrollo.

fabric4 (1).png

4. Validación y grabado

Los Committers comprueban entonces que los RW Sets recibidos aún son válidos generan la misma lista de Reads and Writes. Sin una transacción resulta invalida durante este proceso será incluida en el bloque pero marcada como inválida y no modifica el estado del registro.

Por último, los Committers informan a los Clientes de si la transacción ha sido ejecutada con éxito o no.

fabric5 (1).png

Canales

Los canales es uno de los mecanismos de privacidad en Hyperledger Fabric y permite tener diferentes blockchains en la misma red de forma que solo los participantes de un canal pueden conocer los detalles de las transacciones que ocurren en dicho canal.
Imagina una red con tres participantes P1, P2 y P3. Dentro de dicha red podríamos tener cuatro canales:

  • Un canal formado por los tres participantes
  • Un canal formado por P1 y P2
  • Un canal formado por P2 y P3
  • Un canal formado por P1 y P3

fabric6 (1)

Cada canal tendrá sus propios Smart contracts y su blockchain.

Base de datos de estado

Hyperledger Fabric guarda el estado actual en una base de datos que puede ser recreada en cualquier momento a partir de la cadena de transacciones almacenadas en la cadena de bloques. Es una forma eficiente de acceder al estado del registro (world state) a través de una tabla de clave-valor. Actualmente Hyperledger usa por defecto LevelDB como base de datos que puede ser reemplazado por CouchDB. Mientras LevelDB almacena una lista de clave-valor como decíamos, CouchDB almacena objetos JSON y presenta una interfaz mucho más potente.

En el próximo artículo…

Y esto es suficiente a nivel teórico por ahora. En el próximo artículo aprenderemos a configurar una red de Hyperledger Fabric y construiremos un pequeño ejemplo práctico.

¡Saludos y hasta el próximo artículo!

Anuncios

WordPress.com.

Subir ↑

A %d blogueros les gusta esto: