Hyperledger Fabric

Hyperledger Fabric, que es una plataforma de blockchain empresarial modular

diseñada para su uso en entornos empresariales. Hyperledger Fabric permite a
las organizaciones construir aplicaciones blockchain personalizables y seguras

Componentes Principales de Hyperledger Fabric

1. Peers (Nodos Peer)

Ledger (Libro Mayor): Cada peer mantiene una copia del ledger, que
consta de dos partes: la blockchain y el estado mundial (world state). La
blockchain almacena todas las transacciones en bloques, mientras que el
estado mundial es una base de datos que contiene el estado actual de
todos los activos.

Chaincode (Contrato Inteligente): Es el código ejecutable que define las

reglas y lógica de negocio para las transacciones. Los chaincodes son
similares a los contratos inteligentes en otras plataformas de blockchain.

2. Orderer (Nodo de Ordenación)

El ordener es responsable de ordenar las transacciones en bloques y

distribuir estos bloques a los peers. Esto garantiza que todos los peers
mantengan un ledger coherente y ordenado.

3. Membership Service Provider (MSP)

El MSP gestiona las identidades de los participantes en la red blockchain.

Proporciona autenticación y autorización utilizando certificados digitales.

Hyperledger Fabric 1
 4. Channel (Canal)

Los canales permiten a las organizaciones compartir una blockchain

privada dentro de la red. Cada canal tiene su propio ledger y permite
transacciones privadas y confidenciales entre los miembros del canal.

5. Certificate Authority (CA)

La CA emite y gestiona los certificados de identidad para los nodos y

usuarios en la red. Es una parte crítica del MSP.

6. Endorsement Policy (Política de Endoso)

Define qué firmas son necesarias para validar una transacción. Por
ejemplo, una política puede requerir que al menos tres organizaciones
diferentes endosen una transacción antes de que sea válida.

Arquitectura Detallada
1. Cliente

Es la aplicación que interactúa con la red blockchain. El cliente envía

transacciones a los nodos peer para su validación y posteriormente al
nodo de ordenación para su inclusión en la blockchain.

2. Proceso de Transacción

Propuesta de Transacción: El cliente envía una propuesta de transacción

a uno o más nodos peer.

Endoso de Transacción: Los peers que reciben la propuesta ejecutan el

chaincode en sus respectivas copias del ledger y generan una respuesta
llamada "transacción endosada".

Envio al Nodo de Ordenación: Las transacciones endosadas se envían al

nodo de ordenación, que las agrupa en bloques.

Distribución del Bloque: El nodo de ordenación distribuye los bloques a

todos los nodos peer en el canal.

Validación y Completación: Cada nodo peer valida el bloque recibido y lo

agrega a su copia del ledger.

Flujo de una Transacción

Hyperledger Fabric 2
 1. Propuesta de Transacción

El cliente envía una propuesta de transacción al peer (o peers) que tiene el

chaincode correspondiente. La propuesta incluye el chaincode y los
parámetros de la transacción.

2. Endoso de Transacción

Los peers ejecutan el chaincode con los parámetros proporcionados y

devuelven una respuesta (lectura y escritura del estado mundial) al
cliente. Estas respuestas deben cumplir con la política de endoso definida
para la transacción.

3. Ordenación de Transacciones

El cliente envía las transacciones endosadas al nodo de ordenación. El

nodo de ordenación recibe transacciones de múltiples clientes y las
agrupa en bloques.

4. Distribución y Validación de Bloques

El nodo de ordenación distribuye el bloque de transacciones a todos los

peers del canal. Los peers validan las transacciones en el bloque y aplican
los cambios al estado mundial.

5. Actualización del Ledger

Una vez validadas, las transacciones son confirmadas y los cambios se

reflejan en el ledger de cada peer. Este proceso asegura que todos los
peers tengan una copia sincronizada y consistente del ledger.

Resumen Visual de la Arquitectura

Hyperledger Fabric 3
 En Hyperledger Fabric, una transacción comienza cuando un cliente envía una
propuesta de transacción a los nodos de la red. Estos nodos, conocidos como
peers, ejecutan la transacción propuesta contra el chaincode (contrato inteligente)
para generar un conjunto de resultados, que incluye un valor de respuesta, un
conjunto de lectura y un conjunto de escritura. Estos últimos son pares clave-
valor que representan el activo a crear o actualizar1.
Los peers que respaldan la transacción, llamados endorsing peers, verifican que
la propuesta de transacción sea válida y esté bien formada. También se aseguran
de que el cliente esté autorizado para realizar la operación propuesta en el canal.
Una vez que los endorsing peers han ejecutado y respaldado la transacción, la
propuesta se envía al servicio de ordenamiento, que agrupa las transacciones
respaldadas en bloques. Luego, estos bloques se distribuyen a todos los peers en
el canal, donde se aplican las transacciones al libro mayor, actualizando el estado
del sistema

Características Clave
Modularidad: Los componentes de Hyperledger Fabric (como el MSP, el
ordener y los peers) son modulares y se pueden configurar y actualizar
independientemente.

Confidencialidad: Los canales permiten transacciones privadas entre un

subconjunto de participantes.

Escalabilidad: La red puede escalar mediante la adición de más nodos peer y

orderer.

Seguridad: Utiliza criptografía avanzada para asegurar la autenticidad y la

integridad de las transacciones.

La arquitectura de Hyperledger Fabric proporciona una infraestructura robusta y

flexible para el desarrollo de aplicaciones blockchain empresariales, facilitando la
implementación de soluciones seguras, privadas y eficientes.

Peers
Un elemento fundamental de una red de blockchain de Hyperledger Fabric es el
conjunto de nodos pares (peers). Los pares son fundamentales porque gestionan

Hyperledger Fabric 4
 los libros de contabilidad (ledgers) y los contratos inteligentes (smart contracts). A
partir de Hyperledger Fabric v2.4, los peers también gestionan las propuestas de
transacción y los endosos ejecutando el Fabric Gateway service.

Recuerde que un libro de contabilidad (ledger) registra de manera inmutable

todas las transacciones generadas por contratos inteligentes (que en Hyperledger
Fabric están contenidos en chaincode) y endosadas por las organizaciones
requeridas. Los contratos inteligentes y los libros de contabilidad (ledgers)
encapsulan los procesos e información, respectivamente, que son compartidos
por los peers del canal. Estos aspectos de los peers los convierten en un buen
punto de partida para comprender una red de Fabric.

Una red de blockchain de Fabric (arriba) está compuesta por pares (peers, nodos
no ordenadores), cada uno de los cuales almacena y gestiona copias de libros de
contabilidad (ledgers) y contratos inteligentes (smart contracts). En este ejemplo,
la red de Fabric N consiste en los pares P1, P2 y P3, cada uno de los cuales
mantiene su propia instancia del libro de contabilidad distribuido L1. P1, P2 y P3
invocan el mismo chaincode, S1, para acceder a sus respectivas copias del libro
de contabilidad distribuido.

Los peers son un elemento flexible y redundante que puede ser creado, iniciado,
detenido, reconfigurado y eliminado. Los pares exponen un conjunto de APIs que
permiten a las aplicaciones de cliente interactuar con los servicios que
proporcionan los pares, en particular el servicio Fabric Gateway.

Hyperledger Fabric 5
 Terminología de Chaincode
Fabric implementa contratos inteligentes a través de un tipo de lógica llamada
chaincode, que es código que accede al libro de contabilidad (ledger), y que se
escribe utilizando las APIs de chaincode.

Libros de contabilidad (ledgers) y Chaincode

Ahora veamos un poco más detenidamente un peer. Podemos ver que es el peer
el que alberga tanto el libro de contabilidad como el chaincode, además de
servicios como Fabric Gateway. Más precisamente, el peer aloja instancias del
libro de contabilidad y del chaincode, ya que la cadena de bloques requiere
réplicas consistentes de datos y contratos inteligentes en todos los peers de un
canal. Este diseño proporciona una redundancia deliberada en una red de Fabric,
evitando puntos únicos de fallo y proporcionando libros de contabilidad
consistentes y actuales.

Un peer aloja instancias de libros de contabilidad (ledgers) e instancias de

chaincode (arriba). En este ejemplo, P1 aloja una instancia del libro de
contabilidad L1 y una instancia del chaincode S1. Puede haber muchos libros de
contabilidad y chaincodes alojados en cualquier peer individual.

Dado que un peer es un anfitrión para libros de contabilidad (ledgers),

chaincodes y servicios, las aplicaciones de cliente y los administradores deben

Hyperledger Fabric 6
 interactuar con un peer para acceder a estos recursos. Es por eso que los peers
se consideran los bloques de construcción fundamentales de una red de Fabric.

Múltiples Libros de Contabilidad (Ledgers)

Un peer es capaz de alojar más de un libro de contabilidad, lo cual es útil porque
permite un diseño de sistema flexible donde un único peer puede pertenecer a
múltiples canales en una red de Fabric. En la configuración más simple, un peer
aloja un solo libro de contabilidad y, por lo tanto, pertenece a un solo canal. Pero
no es raro que un peer aloje múltiples libros de contabilidad porque pertenece a
múltiples canales.

Un peer que aloja múltiples libros de contabilidad (ledgers) (arriba). Los peers
alojan uno o más libros de contabilidad y los chaincodes que acceden a ellos. En
este ejemplo, el par P1 aloja los libros de contabilidad L1 y L2. El libro de
contabilidad L1 se accede utilizando el chaincode S1; el libro de contabilidad L2
puede ser accedido utilizando tanto el chaincode S1 como el S2.
Los chaincodes instalados en un peer pueden consultar o actualizar (escribir en)
un libro de contabilidad. Tenga en cuenta que los peers también alojan
chaincodes de sistema especiales que están relacionados con la configuración
general de la red de Fabric.

Múltiples Chaincodes

Hyperledger Fabric 7
 Un chaincode se instancia en un único canal. Cada canal (y libro de contabilidad)
puede tener múltiples chaincodes que interactúan con él.

Un ejemplo de un peer que aloja múltiples chaincodes (arriba). Cada libro de

contabilidad puede tener muchos chaincodes que lo acceden. En este ejemplo, el
par P1 aloja los libros de contabilidad L1 y L2, donde L1 es accedido por los
chaincodes S1 y S2, y L2 es accedido por S1 y S3. S1 puede acceder tanto a L1
como a L2.

Fabric Gateway service (Servicio de Puerta de Enlace de Fabric)

A partir de Hyperledger Fabric v2.4, el servicio de Puerta de Enlace de Fabric se
instala y habilita de forma predeterminada en cada par. El servicio de puerta de
enlace, en contraposición a la aplicación de cliente (en Fabric v2.3 y versiones
anteriores), gestiona propuestas de transacción y endosos en el par. Los SDK de
Puerta de Enlace para Go, Node y Java incorporan este modelo centrado en el par
de procesamiento de transacciones, lo que permite un desarrollo de aplicaciones
simplificado. Las aplicaciones de cliente desarrolladas con SDK de Fabric v2.3 o
anteriores seguirán ejecutándose en Fabric v2.4.

Aplicaciones y Peers
Ahora vamos a mostrar cómo las aplicaciones de cliente interactúan con los
peers, y más específicamente, con el servicio de Puerta de Enlace de Fabric

Hyperledger Fabric 8
 (Fabric Gateway Service) que se ejecuta en los peers, para acceder al libro de
contabilidad (ledger). Las consultas de libro de contabilidad implican un diálogo
simple entre una aplicación y un peer, mientras que las actualizaciones de libro de
contabilidad (escrituras) implican pasos adicionales.

Una aplicación de cliente se conecta al servicio de Puerta de Enlace de Fabric en

un peer para acceder a los libros de contabilidad (ledgers) y los chaincodes. A
partir de Fabric v2.4, los SDK de Puerta de Enlace (v1.x) facilitan esto para los
programadores. Las APIs permiten a las aplicaciones, a través de la puerta de
enlace, enviar propuestas de transacción (que invocan chaincode), solicitar
endosos, recibir eventos y enviar transacciones endosadas al servicio de
ordenación.

A través de una conexión de peer en la puerta de enlace, las aplicaciones pueden

ejecutar chaincodes para consultar o actualizar el libro de contabilidad. El
resultado de una transacción de consulta de libro de contabilidad se devuelve con
un procesamiento simple, mientras que una actualización de libro de contabilidad
(escritura) implica un flujo de trabajo más complejo entre aplicaciones, peers y
ordenadores. Investigemos este proceso de actualización de libro de contabilidad
en detalle.
Los peers, en conjunto con los ordenadores (orderes), se aseguran de que el libro
de contabilidad (ledger) se mantenga consistente y actualizado en cada peer de
un canal. La siguiente secuencia, en tres fases, describe cómo las interacciones
entre una aplicación de cliente, el servicio de puerta de enlace que se ejecuta en
un peer, los nodos ordenadores y peers adicionales actualizan el libro de
contabilidad.

Atención: Las tres fases de transacción que siguen explican los métodos internos
de cómo Fabric gestiona las transacciones. Los SDK de Puerta de Enlace de
Fabric implementan estas fases sin problemas; los desarrolladores solo necesitan
usar un SDK de Puerta de Enlace (1.x).

Fase 1 - Propuesta de Transacción y Endoso

Transaction Proposal and Endorsement

Hyperledger Fabric 9
 La fase 1 de una actualización de libro de contabilidad (ledger) (escritura) consiste
en la presentación, ejecución y endoso de la propuesta de transacción:
a) Propuesta de transacción — La aplicación de cliente (A1) envía una propuesta
de transacción firmada conectándose al servicio de puerta de enlace en P1. A1
debe delegar la selección de organizaciones de endoso al servicio de puerta de
enlace o identificar explícitamente las organizaciones requeridas para el endoso.

b) Ejecución de la transacción — El servicio de puerta de enlace selecciona P1, u

otro peer en su organización, para ejecutar la transacción. El peer seleccionado
ejecuta el chaincode (S1) especificado en la propuesta, genera una respuesta de
propuesta (que contiene el conjunto de lectura-escritura). El peer seleccionado
firma la respuesta de propuesta y la devuelve a la puerta de enlace.
c) Endoso de la transacción — La puerta de enlace repite la ejecución de la
transacción (b) para cada organización requerida por las políticas de endoso del
chaincode (contrato inteligente). El servicio de puerta de enlace recopila las
respuestas de propuestas firmadas y crea un sobre de transacción, que devuelve
al cliente (SDK) para su firma.

Fase 2 - Presentación de Transacciones y Ordenación

Transaction Submission and Ordering

La fase 2 de una actualización de libro de contabilidad (ledger) consiste en la

presentación de transacciones y su ordenación en bloques:
a) Presentación de transacciones — El cliente (SDK) envía el sobre de
transacción firmado al servicio de puerta de enlace. La puerta de enlace envía el
sobre a un nodo de ordenación y devuelve un mensaje de éxito al cliente.
b) Ordenación de transacciones — El nodo de ordenación (O1) verifica la firma, y
el servicio de ordenación ordena la transacción, y la empaqueta con otras
transacciones ordenadas en bloques. El servicio de ordenación luego distribuye el
bloque a todos los pares en el canal para su validación y compromiso con el libro
de contabilidad (ledger).

Fase 3 - Validación de Transacciones y Compromiso

Hyperledger Fabric 10
 Transaction Validation and Commitment

La fase 3 de una actualización de libro de contabilidad (ledger) consiste en la

validación de transacciones, el compromiso del libro de contabilidad y un evento
de compromiso ( ledger commitment and a commit event:):

a) Validación de transacciones — Cada peer verifica que la firma del cliente en el

sobre de transacción coincida con la firma en la propuesta de transacción
original. Cada peer también verifica que todos los conjuntos de lectura-escritura y
las respuestas de estado sean equivalentes (es decir, que los endosos de todos
los pares coincidan) y que los endosos satisfagan las políticas de endoso. Luego,
cada peer marca cada transacción como válida o inválida para el compromiso con
el libro de contabilidad.
b) Compromiso de transacciones — Cada peer compromete el bloque de
transacciones ordenadas en el libro de contabilidad (ledger) del canal (L1). El
compromiso es una actualización inmutable del libro de contabilidad del canal. El
estado mundial (esencialmente, la suma de todas las transacciones válidas) del
canal se actualiza solo con los resultados de las transacciones válidas.
c) Evento de compromiso — Cada peer que se compromete con el libro de
contabilidad envía al cliente un evento de estado de compromiso con prueba de la
actualización del libro de contabilidad.
Nota: Los SDK de Fabric v2.3, que incorporan funcionalidades de propuesta de
transacción y endoso en la aplicación de cliente, siguen siendo compatibles en
Fabric v2.4. Consulte el tema Aplicaciones y Pares v2.3 para obtener más
detalles.

Peers y Canales
Vale la pena dedicar tiempo a comprender cómo interactúan entre sí los peers y
las aplicaciones en un canal, un mecanismo mediante el cual los componentes
dentro de una red blockchain de Fabric se comunican y realizan transacciones de
forma privada.

Los componentes del canal incluyen nodos peers, nodos orders y aplicaciones, y
al unirse a un canal, acuerdan colaborar para gestionar y compartir copias

Hyperledger Fabric 11
 idénticas del libro de contabilidad (ledger) de forma colectiva. Conceptualmente,
se pueden comparar los canales con grupos de amigos; una persona puede tener
varios grupos de amigos, y cada grupo participa en diferentes actividades. Estos
grupos pueden ser completamente separados (un grupo de amigos del trabajo en
comparación con un grupo de amigos del hobby), o puede haber cierta
membresía cruzada entre ellos. Sin embargo, cada grupo de amigos es una
entidad propia, con reglas específicas (o expectativas) que establecen y
mantienen la membresía.

La membresía en un canal funciona de la misma manera que en otros grupos;

cualquier par puede pertenecer a varios canales y mantener un libro de
contabilidad y chaincodes específicos para cada canal. O un par puede
pertenecer a un solo canal, y por lo tanto, tener solo un conjunto de reglas que
seguir.

Los canales permiten que un conjunto específico de aplicaciones y peers (y

organizaciones) se comuniquen entre sí en una red blockchain de Fabric. En el
ejemplo anterior, la aplicación A se comunica con los peers P1 y P2, a través del
servicio de puerta de enlace, en el canal C. El canal es una vía para las
comunicaciones entre aplicaciones y peers específicos.
Observamos que los canales no existen de la misma manera que los pares, es
más preciso pensar en un canal como una estructura lógica formada por una
colección de peers físicos. Es vital entender este punto: los peers proporcionan el
punto de control para el acceso y la gestión de los canales.

Hyperledger Fabric 12
 Los peers y las organizaciones
Ahora que comprendes los pares y su relación con los libros contables, los
chaincodes y los canales, podrás ver cómo múltiples organizaciones se unen para
formar una red blockchain.
Las redes blockchain de Fabric son administradas por una colección de
organizaciones en lugar de una sola organización. Los pares son fundamentales
para la construcción de este tipo de red distribuida porque son propiedad de —y
son los puntos de conexión de red para— estas organizaciones.

El ejemplo anterior muestra organizaciones y sus peers en una red blockchain de

Fabric. Vemos cuatro organizaciones que contribuyen con un total de ocho peers
para formar una red.
El canal C conecta cinco de estos pares en la red N: P1, P3, P5, P7 y P8. Los otros
pares propiedad de estas organizaciones no se han unido al canal C, pero
típicamente se unen a al menos otro canal. Las aplicaciones desarrolladas por una
organización se conectan a los pares, a través del servicio Gateway de Fabric, en
la misma organización, así como a los pares en otras organizaciones en un canal.

Es importante notar lo que sucede durante la formación de una red blockchain de

Fabric. La red es tanto formada como administrada por las múltiples
organizaciones que contribuyen recursos a ella. Los peers son los recursos de los
que estamos hablando en este tema, pero las organizaciones también

Hyperledger Fabric 13
 proporcionan otros recursos, como chaincode y nodos de servicio de
ordenamiento. Aquí hay un principio en acción: la red literalmente no existe sin
que las organizaciones contribuyan con sus recursos individuales a la red
colectiva. Además, la red crece a medida que las organizaciones colaboradoras
proporcionan recursos, aumentando la resiliencia y seguridad de la red.

Puedes ver que (aparte del servicio de ordenamiento, hasta cierto punto) no hay
recursos centralizados; en el diagrama anterior, la red N no existiría si las
organizaciones no contribuyeran con sus pares y otros recursos. Además, la red
no depende de ninguna organización individual; continúa existiendo a pesar de las
salidas siempre que su membresía cumpla con los requisitos autodefinidos de la
red. Esto está en el corazón de lo que significa que una red sea descentralizada;
todas las organizaciones miembro comparten y contribuyen de manera equitativa.

Las aplicaciones utilizadas por las organizaciones, como en el diagrama anterior,

pueden ser iguales o diferentes, porque cada organización puede decidir cómo
desea utilizar los datos en el libro contable. Por lo tanto, tanto la lógica de
aplicación como la de presentación pueden variar entre organizaciones, aunque
todos los pares alojen una copia equivalente del libro contable.

Peers and Orderers

Hemos visto que los peers forman la base de una red blockchain de Fabric,
alojando libros contables y contratos inteligentes que pueden ser consultados y
actualizados por aplicaciones conectadas a peers. El mecanismo por el cual las
aplicaciones y los peers interactúan entre sí para mantener el libro contable
actualizado y consistente a través de un canal es mediado por nodos especiales
llamados ordenadores. Es a estos nodos ordenadores a los que ahora dirigimos
nuestra atención.
Una transacción de actualización del libro contable es diferente de una
transacción de consulta porque un solo peer no puede, por sí solo, actualizar el
libro contable; eso requiere el consentimiento de otros peers en la red, un proceso
conocido como consenso. Cuando los pares necesarios para aprobar la
transacción lo hacen, y la transacción se compromete en el libro contable, el
servicio de puerta de enlace notifica a las aplicaciones que el libro contable ha
sido actualizado. Los pares y los ordenadores trabajan juntos para gestionar el
consenso.

Hyperledger Fabric 14
 Los ordenadores y las tres fases
Anteriormente, en el tema de Aplicaciones y Peers, vimos cómo una aplicación
cliente que solicita una actualización del libro contable inicia un proceso de tres
fases que, con la ayuda del servicio de puerta de enlace de Fabric, asegura que
todos los peers en una red de Fabric mantengan copias del libro contable actuales
y consistentes. Como se describió, también están involucrados los ordenadores;
las siguientes secciones examinan más de cerca el proceso de tres fases desde la
perspectiva de los nodos ordenadores y los pares (es decir, el servicio de
ordenación y el servicio de puerta de enlace).

Fase 1: Propuesta de Transacción

Propuesta de Transacción

La Fase 1 del flujo de trabajo de transacciones implica una interacción entre una
aplicación cliente, peers y orders. En la Fase 1, la aplicación cliente inicia una
solicitud al servicio de puerta de enlace de Fabric para evaluar una propuesta de
transacción.
El peer objetivo, seleccionado por la aplicación cliente, ejecuta la transacción
invocando el chaincode; este paso puede describirse como la simulación de la
transacción, ya que ejecuta la transacción sin ningún efecto en el libro contable.
Luego, el peer devuelve su resultado de transacción al cliente.
El servicio de puerta de enlace también reenvía la propuesta de transacción a los
peers que respaldan requeridos (según las políticas de respaldo), que también
ejecutan la transacción y devuelven sus resultados al peer. El servicio de puerta
de enlace recopila todas las respuestas y, si satisfacen colectivamente las
políticas de respaldo, envía la transacción al servicio de ordenación.

Si la transacción propuesta escribiría en una colección de datos privados (como

datos transitorios), la aplicación cliente debe especificar explícitamente las
organizaciones requeridas para el respaldo.
Es importante destacar que un peer respalda una respuesta de propuesta
agregando su firma digital y firmando todo el payload utilizando su clave privada.

Hyperledger Fabric 15
 Este respaldo puede utilizarse posteriormente para demostrar que el par de esta
organización generó una respuesta particular.

Fase 2: Ordenación de Transacciones

Phase 2: Transaction Ordering

La segunda fase del flujo de trabajo de transacciones es la fase de ordenación y

empaquetado. El servicio de ordenación (que se ejecuta en nodos ordenadores)
recibe transacciones que contienen respuestas de propuestas firmadas y
respaldadas, de una o más aplicaciones a través del servicio de puerta de enlace,
y ordena y empaqueta las transacciones en bloques. Estos son los bloques (que
también están ordenados) — que consisten en transacciones respaldadas y
ordenadas — que componen un libro de contabilidad de blockchain de Fabric.

Fase 3: Validación y Compromiso

Validation and Commitment

La tercera y última fase del flujo de trabajo de transacciones es la distribución de

las transacciones ordenadas de los orders a los peers. Luego, cada par valida
cada transacción, en el orden correcto, y se asegura de que cada transacción
haya sido respaldada consistentemente por todas las organizaciones requeridas.
Solo entonces el par compromete el bloque en su copia del libro de contabilidad
del canal.

Hyperledger Fabric 16
 Un nodo ordenante distribuye bloques ordenados a los peers para su validación y
compromiso. En el ejemplo anterior, el nodo ordenante O1 distribuye el bloque B2
a los peers P1 y P2. El peer P1 procesa el bloque B2, resultando en un nuevo
bloque agregado al ledger L1 en P1. Paralelamente, el peer P2 procesa el bloque
B2, resultando en un nuevo bloque agregado al ledger L1 en P2. Una vez
completado, el ledger L1 ha sido actualizado consistentemente en los peers P1 y
P2, y el servicio de gateway informa a las aplicaciones relevantes que la
transacción ha sido comprometida.
La fase 3 comienza con el nodo ordenante distribuyendo bloques a todos los
peers conectados a él. Los peers están conectados a los nodos ordenantes en
canales de tal manera que, cuando se genera un nuevo bloque, todos los peers
conectados al nodo ordenante recibirán una copia del nuevo bloque. Cada peer
procesará este bloque de manera independiente, pero exactamente de la misma
forma que cualquier otro peer en el canal. De esta manera, veremos que el ledger
puede mantenerse consistente.
También vale la pena notar que no todos los peers necesitan estar conectados a
un nodo ordenante: los peers pueden distribuir bloques a otros peers utilizando el
protocolo gossip, quienes también pueden procesarlos de manera independiente.
Al recibir un bloque, un peer procesará cada transacción en la secuencia
especificada en el bloque. Para cada transacción, el peer verificará que la
transacción haya sido respaldada por las organizaciones requeridas de acuerdo
con las políticas de respaldo para el chaincode que generó la transacción. Por
ejemplo, algunas transacciones pueden necesitar ser respaldadas por una sola
organización, mientras que otras pueden requerir múltiples respaldos para ser

Hyperledger Fabric 17
 válidas. Este proceso de validación verifica que todas las organizaciones
relevantes hayan generado el mismo resultado.

Si una transacción ha sido correctamente respaldada, el peer intentará aplicarla al

ledger. Para hacer esto, un peer debe realizar una verificación de consistencia del
ledger para confirmar que el estado actual del ledger es compatible con el estado
del ledger cuando se generó la actualización propuesta. Esto no siempre es
posible, incluso cuando la transacción ha sido completamente respaldada. Por
ejemplo, otra transacción puede haber actualizado el mismo activo en el ledger de
tal manera que la actualización de la transacción ya no sea válida y, por lo tanto,
no pueda aplicarse. De esta manera, el ledger se mantiene consistente en cada
peer del canal porque todos siguen las mismas reglas de validación.
Finalmente, cada vez que un bloque se compromete al ledger de un peer, ese
peer genera un evento. Los eventos de bloque incluyen el contenido completo del
bloque, mientras que los eventos de transacciones del bloque incluyen solo
información resumida, como si cada transacción en el bloque ha sido validada o
invalidada. Los eventos de chaincode, que la ejecución del chaincode ha
producido, también pueden ser publicados en este momento. Las aplicaciones
pueden registrarse para estos tipos de eventos para recibir notificaciones. La
notificación del evento de compromiso concluye la tercera y última fase del flujo
de trabajo de la transacción.

Resumen de la Fase 3
En resumen, la fase 3 ve los bloques de transacciones, que son generados por el
orderer, validados y aplicados consistentemente al ledger. El orden estricto de las
transacciones en bloques permite que cada peer valide que las actualizaciones de
las transacciones se apliquen consistentemente a lo largo del canal.

Ordenadores y Consenso
Todo este proceso de flujo de trabajo de transacciones se denomina consenso,
porque los peers deben llegar colectivamente a un acuerdo sobre el orden y el
contenido de las transacciones, con la mediación de los ordenadores. El consenso
es un proceso de varios pasos y las actualizaciones del ledger solo ocurren
cuando el proceso se completa con éxito, lo cual puede suceder en momentos
ligeramente diferentes en diferentes peers. Piensa en los ordenadores como

Hyperledger Fabric 18
 nodos que secuencian y distribuyen las actualizaciones propuestas del ledger
para que los peers las respalden y las agreguen al ledger.

Resumen de los Peers

¡Eso es todo! Hemos terminado nuestro recorrido detallado por los peers y sus
interacciones con otros componentes de Fabric, incluyendo aplicaciones cliente,
chaincodes y ordenadores. Hemos visto que los peers son, en muchos sentidos,
el elemento más fundamental de la arquitectura de Hyperledger Fabric: forman la
red, alojan los chaincodes y el ledger, manejan las propuestas y respuestas de
transacciones, y mantienen el ledger actualizado y consistente con transacciones
validadas y respaldadas.

Ledger

Libro mayor - Libro contable

El ledger es un concepto fundamental en Hyperledger Fabric; almacena

información factual importante sobre objetos de negocio; tanto el valor actual de
los atributos de los objetos, como el historial de transacciones que resultaron en
estos valores actuales.

¿Qué es un Libro Mayor?

What is a Ledger?

Un libro mayor contiene el estado actual de un negocio como un registro de

transacciones. Los primeros libros mayores europeos y chinos datan de hace casi
1000 años, y los sumerios tenían libros de piedra hace 4000 años, pero
comencemos con un ejemplo más actual.

Probablemente estés acostumbrado a ver tu cuenta bancaria. Lo más importante

para ti es el saldo disponible: es lo que puedes gastar en el momento actual. Si
quieres ver cómo se derivó tu saldo, puedes revisar las transacciones de créditos

Hyperledger Fabric 19
 y débitos que lo determinaron. Este es un ejemplo de la vida real de un libro
mayor: un estado (tu saldo bancario) y un conjunto de transacciones ordenadas
(créditos y débitos) que lo determinan. Hyperledger Fabric se inspira en estas
mismas dos preocupaciones: presentar el valor actual de un conjunto de estados
de libros mayores y capturar la historia de las transacciones que determinaron
estos estados.

Libros Mayores, Hechos y Estados

Un libro mayor no almacena literalmente objetos comerciales; en cambio,
almacena hechos sobre esos objetos. Cuando decimos "almacenamos un objeto
comercial en un libro mayor", lo que realmente queremos decir es que estamos
registrando los hechos sobre el estado actual de un objeto y los hechos sobre la
historia de las transacciones que llevaron al estado actual. En un mundo cada vez
más digital, puede sentirse como si estuviéramos viendo un objeto en lugar de
hechos sobre un objeto. En el caso de un objeto digital, es probable que viva en
un almacén de datos externo; los hechos que almacenamos en el libro mayor nos
permiten identificar su ubicación junto con otra información clave sobre él.
Si bien los hechos sobre el estado actual de un objeto comercial pueden cambiar,
la historia de los hechos sobre él es inmutable; se puede agregar más, pero no se
puede cambiar retrospectivamente. Veremos cómo pensar en una cadena de
bloques como una historia inmutable de hechos sobre objetos comerciales es una
forma simple pero poderosa de entenderla.
¡Veamos ahora más de cerca la estructura del libro mayor de Hyperledger Fabric!

El Libro Mayor

The Ledger

En Hyperledger Fabric, un libro mayor consta de dos partes distintas, aunque

relacionadas: un estado del mundo y una cadena de bloques (world state and a
blockchain). Cada una de estas partes representa un conjunto de hechos sobre
un conjunto de objetos comerciales.

Hyperledger Fabric 20
 En primer lugar, está el estado del mundo (world state), una base de datos que
contiene los valores actuales de un conjunto de estados del libro mayor. El estado
del mundo facilita que un programa acceda directamente al valor actual de un
estado en lugar de tener que calcularlo al recorrer todo el registro de
transacciones. Los estados del libro mayor se expresan, por defecto, como pares
clave-valor, y veremos más adelante cómo Hyperledger Fabric proporciona
flexibilidad en este sentido. El estado del mundo puede cambiar con frecuencia,
ya que los estados pueden crearse, actualizarse y eliminarse.
En segundo lugar, está la cadena de bloques (blockchain), un registro de
transacciones que registra todos los cambios que han resultado en el estado del
mundo actual. Las transacciones se recopilan dentro de bloques que se agregan a
la cadena de bloques, lo que le permite comprender la historia de los cambios que
han dado lugar al estado del mundo actual. La estructura de datos de la cadena
de bloques es muy diferente al estado del mundo porque, una vez escrita, no se
puede modificar; es inmutable.

En esencia, un registro (o ledger) L en Hyperledger Fabric está compuesto por

dos componentes principales: la cadena de bloques B y el estado del mundo W.
La cadena de bloques B registra todas las transacciones que han tenido lugar en
la red, mientras que el estado del mundo W representa el estado actual de todos
los datos o activos en la red. Podemos decir que el estado del mundo W es
determinado por la cadena de bloques B, ya que cada cambio en el estado del
mundo está respaldado por una transacción registrada en la cadena de bloques.

Hyperledger Fabric 21
 Aunque hablamos de un "registro", en realidad hay múltiples copias del mismo en
la red de Hyperledger Fabric. Estas copias se mantienen consistentes entre sí a
través de un proceso llamado consenso, donde todos los nodos de la red
acuerdan y validan los cambios que se realizan en el registro. Este tipo de registro
distribuido se asocia comúnmente con la tecnología de registros distribuidos
(DLT), donde hay una única entidad lógica de registro, pero múltiples copias
físicas distribuidas a lo largo de la red.
Ahora profundizaremos en las estructuras de datos del estado del mundo y la
cadena de bloques para comprender mejor cómo funcionan en Hyperledger
Fabric.

El estado del mundo

World State

El estado del mundo (World State) en Hyperledger Fabric almacena el valor actual
de los atributos de un objeto comercial como un estado único del registro. Esto es
útil porque los programas generalmente requieren el valor actual de un objeto;
sería engorroso recorrer toda la cadena de bloques para calcular el valor actual
de un objeto; simplemente se obtiene directamente del estado del mundo.

Hyperledger Fabric 22
 Un estado del mundo (World State) de un libro mayor contiene dos estados. El
primer estado es: clave=CAR1 y valor=Audi. El segundo estado tiene un valor más
complejo: clave=CAR2 y valor={modelo:BMW, color=rojo, propietario=Jane}.
Ambos estados están en la versión 0.

Un estado del libro mayor registra un conjunto de hechos sobre un objeto

comercial particular. Nuestro ejemplo muestra estados del libro mayor para dos
automóviles, CAR1 y CAR2, cada uno con una clave y un valor. Un programa de
aplicación puede invocar un contrato inteligente que utiliza API de libro mayor
simples para obtener, poner y eliminar estados. Observa cómo el valor de un
estado puede ser simple (Audi…) o compuesto (tipo:BMW…). El estado del mundo
a menudo se consulta para recuperar objetos con ciertos atributos, por ejemplo,
para encontrar todos los BMW rojos.
El estado del mundo se implementa como una base de datos. Esto tiene mucho
sentido porque una base de datos proporciona un conjunto completo de
operadores para el almacenamiento y recuperación eficientes de estados.
Veremos más adelante que Hyperledger Fabric puede configurarse para utilizar
diferentes bases de datos de estado del mundo para satisfacer las necesidades
de diferentes tipos de valores de estado y los patrones de acceso requeridos por
las aplicaciones, por ejemplo, en consultas complejas.
Las aplicaciones envían transacciones que capturan cambios en el estado del
mundo, y estas transacciones terminan siendo confirmadas en la cadena de
bloques del libro mayor. Las aplicaciones están aisladas de los detalles de este
mecanismo de consenso por el SDK de Hyperledger Fabric y la puerta de enlace
del peer; simplemente solicitan la invocación de un contrato inteligente y se les
notifica cuando la transacción ha sido incluida en la cadena de bloques (ya sea
válida o no válida). El punto clave de diseño es que solo las transacciones
firmadas por el conjunto requerido de organizaciones avaladoras provocarán una
actualización del estado del mundo. Si una transacción no está firmada por
suficientes avaladores (endorsers), no resultará en un cambio del estado del
mundo.
También notarás que un estado tiene un número de versión, y en el diagrama
anterior, los estados CAR1 y CAR2 están en sus versiones iniciales, 0. El número
de versión es para uso interno de Hyperledger Fabric y se incrementa cada vez
que cambia el estado. La versión se verifica cada vez que se actualiza el estado

Hyperledger Fabric 23
 para asegurarse de que los estados actuales coincidan con la versión en el
momento del aval. Esto garantiza que el estado del mundo esté cambiando según
lo esperado; que no haya habido una actualización concurrente.
Finalmente, cuando se crea un libro mayor por primera vez, el estado del mundo
está vacío. Debido a que cualquier transacción que represente un cambio válido
en el estado del mundo se registra en la cadena de bloques, significa que el
estado del mundo se puede regenerar a partir de la cadena de bloques en
cualquier momento. Esto puede ser muy conveniente, por ejemplo, el estado del
mundo se genera automáticamente cuando se crea un peer. Además, si un peer
falla anormalmente, el estado del mundo se puede regenerar al reiniciar el peer,
antes de que se acepten transacciones.

Blockchain
Ahora cambiemos nuestra atención del estado del mundo a la cadena de bloques.
Mientras que el estado del mundo contiene un conjunto de hechos relacionados
con el estado actual de un conjunto de objetos comerciales, la cadena de bloques
es un registro histórico de los hechos sobre cómo estos objetos llegaron a sus
estados actuales. La cadena de bloques ha registrado cada versión anterior de
cada estado del libro mayor y cómo ha sido cambiado.

La cadena de bloques está estructurada como un registro secuencial de bloques

interconectados, donde cada bloque contiene una secuencia de transacciones,
cada transacción representando una consulta o actualización al estado del
mundo. El mecanismo exacto por el cual se ordenan las transacciones se discute
en otros lugares; lo importante es que el ordenamiento de bloques, así como el
ordenamiento de transacciones dentro de los bloques, se establece cuando los
bloques son creados por un componente de Hyperledger Fabric llamado servicio
de ordenamiento.

El encabezado de cada bloque incluye un hash de las transacciones del bloque,

así como un hash del encabezado del bloque anterior. De esta manera, todas las
transacciones en el libro mayor están secuenciadas y vinculadas
criptográficamente entre sí. Este hash y vínculo hacen que los datos del libro
mayor sean muy seguros. Incluso si un nodo que aloja el libro mayor fuera
manipulado, no podría convencer a todos los demás nodos de que tiene la cadena

Hyperledger Fabric 24
 de bloques "correcta" porque el libro mayor está distribuido en una red de nodos
independientes.
La cadena de bloques siempre se implementa como un archivo, en contraste con
el estado del mundo, que utiliza una base de datos. Esta es una elección de
diseño sensata ya que la estructura de datos de la cadena de bloques está muy
sesgada hacia un conjunto muy pequeño de operaciones simples. Agregar al final
de la cadena de bloques es la operación principal, y la consulta es actualmente
una operación relativamente poco frecuente.
Echemos un vistazo a la estructura de una cadena de bloques un poco más en
detalle.

Una cadena de bloques B contiene bloques B0, B1, B2, B3. B0 es el primer bloque
en la cadena de bloques, el bloque génesis.

En el diagrama anterior, podemos ver que el bloque B2 tiene una data de bloque
D2 que contiene todas sus transacciones: T5, T6, T7.
Lo más importante es que B2 tiene un encabezado de bloque H2, que contiene un
hash criptográfico de todas las transacciones en D2, así como un hash de H1. De
esta manera, los bloques están vinculados de manera inextricable e inmutable
entre sí, ¡lo que el término cadena de bloques captura de manera tan precisa!

Finalmente, como puedes ver en el diagrama, el primer bloque en la cadena de

bloques se llama bloque génesis. Es el punto de partida para el libro mayor,

Hyperledger Fabric 25
 aunque no contiene ninguna transacción de usuario. En su lugar, contiene una
transacción de configuración que contiene el estado inicial del canal de red (no
mostrado). Discutimos el bloque génesis con más detalle cuando tratamos sobre
la red de cadena de bloques y los canales en la documentación.

Blocks
Vamos a echar un vistazo más de cerca a la estructura de un bloque. Consta de
tres secciones

1.- Encabezado del Bloque

Block Header

Esta sección comprende tres campos, escritos cuando se crea un bloque.

Número de Bloque: (Block number) Un entero que comienza en 0 (el bloque

génesis) y aumenta en 1 por cada nuevo bloque agregado a la cadena de
bloques.

Hash Actual del Bloque: (Current Block Hash) El hash de todas las
transacciones contenidas en el bloque actual.

Hash del Encabezado del Bloque Anterior: (Previous Block Header Hash) El
hash del encabezado del bloque anterior.

Estos campos se derivan internamente mediante el hash criptográfico de los

datos del bloque. Aseguran que cada bloque esté inextricablemente vinculado a
su vecino, lo que conduce a un libro mayor inmutable.

Hyperledger Fabric 26
 Detalles del Encabezado del Bloque. El encabezado H2 del bloque B2 consta del
número de bloque 2, el hash CH2 de los datos del bloque actual D2 y el hash del
encabezado del bloque anterior H1.

2.- Datos del Bloque

Block Data

Esta sección contiene una lista de transacciones dispuestas en orden. Se escribe

cuando el bloque es creado por el servicio de ordenación. Estas transacciones
tienen una estructura rica pero directa, que describiremos más adelante en este
tema.

3.- Metadatos del Bloque

Block Metadata

Esta sección contiene el certificado y la firma del creador del bloque que se utiliza
para verificar el bloque por los nodos de la red. Posteriormente, el comisor del
bloque agrega un indicador válido/inválido para cada transacción en un mapa de
bits que también reside en los metadatos del bloque, así como un hash de las

Hyperledger Fabric 27
 actualizaciones de estado acumulativas hasta e incluyendo ese bloque, para
detectar una bifurcación de estado. A diferencia de los campos de datos y
encabezado del bloque, esta sección no es una entrada para el cálculo del hash
del bloque.

Transactions
Las transacciones representan las acciones fundamentales dentro de una red
blockchain, capturando los cambios en el estado del mundo del libro mayor. Aquí
tienes un resumen de la estructura detallada de los datos del bloque, que alberga
las transacciones dentro de un bloque.

Detalles de la transacción. La transacción T4 en los datos del bloque D1 del

bloque B1 consta de un encabezado de transacción, H4, una firma de transacción,
S4, una propuesta de transacción, P4, una respuesta de transacción, R4, y una
lista de avales, E4.
En el ejemplo anterior, podemos ver los siguientes campos:

Encabezado (Header): Esta sección, ilustrada por H4, captura metadatos

esenciales sobre la transacción, como el nombre del chaincode relevante y
su versión.

Firma (Signature): Esta sección, ilustrada por S4, contiene una firma
criptográfica creada por la aplicación cliente. Este campo se utiliza para

Hyperledger Fabric 28
 verificar que los detalles de la transacción no han sido manipulados, ya
que requiere la clave privada de la aplicación para generarlo.

Propuesta (Proposal): Este campo, ilustrado por P4, codifica los

parámetros de entrada proporcionados por una aplicación al contrato
inteligente que crea la actualización propuesta del libro mayor. Cuando se
ejecuta el contrato inteligente, esta propuesta proporciona un conjunto de
parámetros de entrada que, combinados con el estado del mundo actual,
determinan el nuevo estado del mundo.

Respuesta (Response): Esta sección, ilustrada por R4, captura los valores
antes y después del estado del mundo, como un conjunto de lectura y
escritura (RW-set). Es el resultado de un contrato inteligente y, si la
transacción se valida correctamente, se aplicará al libro mayor para
actualizar el estado del mundo.

Aval (Endorsements): Como se muestra en E4, esta es una lista de

respuestas de transacción firmadas de cada organización requerida
suficientes para satisfacer la política de aval. Notarás que, mientras que
solo se incluye una respuesta de transacción en la transacción, hay
múltiples avales. Eso se debe a que cada aval codifica efectivamente la
respuesta de transacción particular de su organización, lo que significa
que no es necesario incluir ninguna respuesta de transacción que no
coincida con suficientes avales, ya que será rechazada como inválida y no
actualizará el estado del mundo.
Eso concluye los principales campos de la transacción; hay otros, pero estos son
los esenciales que necesitas entender para tener una comprensión sólida de la
estructura de datos del libro mayor.

Opciones de bases de datos del estado del mundo

El estado del mundo se implementa físicamente como una base de datos para
proporcionar un almacenamiento y recuperación simples y eficientes de los
estados del libro mayor. Como hemos visto, los estados del libro mayor pueden
tener valores simples o compuestos, y para dar cabida a esto, la implementación
de la base de datos del estado del mundo puede variar, permitiendo que estos

Hyperledger Fabric 29
 valores se implementen de manera eficiente. Las opciones para la base de datos
del estado del mundo actualmente incluyen LevelDB y CouchDB.
LevelDB es el predeterminado y es particularmente apropiado cuando los estados
del libro mayor son pares clave-valor simples. Una base de datos LevelDB está
ubicada junto con el nodo par: está incrustada dentro del mismo proceso del
sistema operativo.
CouchDB es una opción especialmente adecuada cuando los estados del libro
mayor están estructurados como documentos JSON porque CouchDB admite las
consultas ricas y la actualización de tipos de datos más complejos que a menudo
se encuentran en transacciones comerciales. En cuanto a la implementación,
CouchDB se ejecuta en un proceso de sistema operativo separado, pero aún hay
una relación de 1:1 entre un nodo par y una instancia de CouchDB. Todo esto es
invisible para un contrato inteligente. Consulta CouchDB como la StateDatabase
para obtener más información sobre CouchDB.
En LevelDB y CouchDB, vemos un aspecto importante de Hyperledger Fabric: es
enchufable. La base de datos del estado del mundo podría ser un almacén de
datos relacional, o un almacén de gráficos, o una base de datos temporal. Esto
proporciona una gran flexibilidad en los tipos de estados del libro mayor a los que
se puede acceder de manera eficiente, lo que permite que Hyperledger Fabric
aborde muchos problemas diferentes.

Ejemplo de Libro Mayor: Transferencia Básica de Activos

Example Ledger: Basic Asset Transfer

Al finalizar este tema sobre el libro mayor, echemos un vistazo a un ejemplo de

libro mayor. Si has ejecutado la aplicación de muestra de transferencia básica de
activos, entonces has creado este libro mayor.
La aplicación de muestra básica crea un conjunto de 6 activos, cada uno con una
identidad única; un color, tamaño, propietario y valor tasado diferentes. Esto es lo
que parece el libro mayor después de que se hayan creado los primeros cuatro
activos.

Hyperledger Fabric 30
 El libro mayor, L, comprende un estado del mundo, W, y una cadena de bloques,
B. W contiene cuatro estados con las claves: ASSET1, ASSET2, ASSET3 y
ASSET4. B contiene dos bloques, 0 y 1. El bloque 1 contiene cuatro transacciones:
T1, T2, T3 y T4.
Podemos ver que el estado del mundo contiene estados que corresponden a
ASSET1, ASSET2, ASSET3 y ASSET4. ASSET1 tiene un valor que indica que es de
color azul con tamaño 5, actualmente propiedad de Tomoko, y podemos ver
estados y valores similares para los otros autos. Además, podemos ver que todos
los estados de los autos tienen el número de versión 0, lo que indica que este es
su número de versión inicial: no han sido actualizados desde que fueron creados.
También podemos ver que la cadena de bloques contiene dos bloques. El bloque
0 es el bloque de génesis, aunque no contiene ninguna transacción relacionada
con los autos. Sin embargo, el bloque 1 contiene transacciones T1, T2, T3, T4 y
estas corresponden a transacciones que crearon los estados iniciales para
ASSET1 a ASSET4 en el estado del mundo. Podemos ver que el bloque 1 está
vinculado al bloque 0.
No hemos mostrado los otros campos en los bloques o transacciones,
específicamente encabezados y hash. Si estás interesado en los detalles precisos
de estos, encontrarás un tema de referencia dedicado en otra parte de la
documentación. Te proporciona un ejemplo completo de un bloque entero con sus
transacciones en detalle glorioso, pero por ahora, has logrado una sólida
comprensión conceptual de un libro mayor de Hyperledger Fabric. ¡Bien hecho!

Hyperledger Fabric 31