Hyperledger Fabric — Conceptos y Tipos de Nodos
Si quieres puedes ver nuestros post anteriores:
Nota: Esta guía está basada en la documentación oficial de Hyperledger Fabric, cursos oficiales, plataformas de cursos online y nuestra propia experiencia.
Antes de ver conceptos nuevos, vamos a resumir muy rápidamente cuales son las principales características de Fabric que vimos en el post anterior.
Fabric está enfocado al desarrollo de proyectos Blockchain del mundo empresarial y su arquitectura se diseño teniendo esto en mente.
Es un DLT (Distributed Ledger Technology) con las siguientes características:
- Red permisionada.
- Transacciones confidenciales (privadas).
- No utiliza criptomoneda.
- Es programable mediante sus chaincodes.
Además, existen otros conceptos que también son clave entender y conocer:
- Asset: Representa cualquier activo del mundo real.
- Chaincode: Definen la estructura de los assets (en formato JSON o binario) y se usan para programar las diferentes funciones o transacciones que se pueden realizar sobre estos. Cuando un chaincode se ejecuta añade información al ledger.
- Ledger: Es donde se almacenan todas las transacciones y estados de los assets. Diferenciamos dos partes: Transaction Log y WorldState.
- Transaction Log: Guarda un registro de todas las transacciones que se producen en el canal.
- WorldState o StateDB: Guarda un listado del estado de los assets en cada momento.
Diseño y componentes
Como es una red permisionada, todos los miembros de la red tienen que ser conocidos y para ello se les proporciona a cada uno un certificado X.509. Estos certificados no son únicamente expedidos a los usuarios, si no a todos los participantes de la red: usuarios, nodos, orderers, aplicaciones … En el próximo post entraremos más en detalle en que es la identidad dentro de Fabric y como se consiguen estos certificados.
Lo que se busca en Fabric es la creación de consorcios y es por ello que cada miembro u organización es una entidad legal diferente e independiente. Como consecuencia, cada organización puede y debe emitir sus propios certificados a cada participante o pieza de la arquitectura de su red. Es por esta misma razón que una red de Fabric puede tener uno o más MSPs. Si aún no conoces el término MSP también lo definiremos en el siguiente post.
Tipos de Nodos
Los miembros u organizaciones tienen diferentes tipos de nodos. Normalmente en las redes públicas como Bitcoin o Ethereum todos los nodos son iguales, sin embargo, en Fabric hay diferentes tipos y cada uno tiene una función diferente dentro del flujo de las transacciones:
- Orderers: Responsables de la distribución de los bloques.
- Peers: Mantienen los datos del ledger sincronizados en la red.
- Clients: Inician las transacciones.
Definimos a los nodos como aquellos elementos que se comunica entre sí. Todos necesitan tener un certificado válido para poder comunicarse con el resto de la red y de los participantes. Pero veamos estos elementos en mayor detalle y expliquemos un poco en que consiste cada uno. Además, en post posteriores definiremos en mayor detalle algunos de ellos.
Orderer
Es el encargado de la comunicación. Se encarga de mantener la consistencia entre los diferentes nodos de la red y la asegura mediante:
- El mecanismo de consenso
- Asegurando el orden de las transacciones
Es por ello el encargado de recibir las transacciones, formar los bloques con estas transacciones y garantizar el envío de forma atómica a cada uno de los anchor peers de las organizaciones a las que le corresponda.
Como ya comentamos en el anterior post, existen varias formas de implementar este orderer u orderers:
- SOLO: Existe únicamente un nodo de este tipo. Solo se utiliza para la fase de desarrollo precisamente por que si el fallará se caería toda la red.
- KAFKA: Mediante esta implementación, que sí se puede usar en producción, se forma un cluster de nodos de tipo orderer, por lo que conseguimos mayor concurrencia, escalabilidad y tolerancia a fallos. Sus dos principales pegas son que es difícil de implementar y que está desarrollado por una empresa externa.
- RAFT: Desde la última versión apareció este nuevo protocolo de implementación del ordering service. También es un cluster de nodos pero esta vez es más sencillo de implementar y además está soportado por el equipo de Fabric.
Peer nodes
Cada peer node mantiene su propia copia del ledger. Como ya hemos visto existen dos partes dentro de este ledger: el Transaction Log y el State DB.
Cada organización o miembro tendrá que desplegar cuantos necesite en función de la escalabilidad y rendimiento de la red o del canal al que pertenezcan.
Tenemos tipos diferentes de peers:
- Anchor peer: Son los únicos que son conocidos por elementos fuera de su organización. Cada organización debe tener al menos un nodo de este tipo.
- Leader peer: Son los encargados de recibir los bloques del orderer. Estos peers se pueden escoger de forma estática o de forma dinámica. Un apunte importante es que estos leaders se escogen a nivel de canal, por lo que un mismo nodo podría ser el leader en diferentes canales. Una vez que recibe el bloque se encarga de distribuirlo al resto de peers de su organización.
- Regular peer: Son los nodos más básicos, mantienen el ledger actualizado y se sincronizan con el resto de peers.
- Endorsing peers: Son los encargados de recibir las transacciones de los clientes o aplicaciones. Se encargan de simular la ejecución de la transacción pero sin dejar registro de la misma en el WorldState o StateDB. En caso de que la simulación se haya producido satisfactoriamente, entonces se manda al ordering service para que se encargue de juntarlas y transmitirlas al resto de la red. Esta simulación se produce por varias razones: Para evitar un ataque intencionado de un cliente contra la red y para evitar errores de configuración, ya sean del chaincode o de la red.
Client nodes
Entendemos como clientes aquellos nodos que envían las transacciones. Podemos encontrarnos con varios tipos de clientes: Usuarios finales, APIs, Back-ends…
Su función principal es la de generar una solicitud de transacción contra un endorsing peer. Hay que tener en cuenta que cada chaincode lleva asociado un endorsment policy. Estas son políticas que se definen a la hora de desplegar el chaincode en el canal. Las aplicaciones deberán conocer, mediante el connection profile, las direcciones de los endorsing peers a los que deben enviar estas solicitudes de transacciones. Estos endorsment policies son opcionales pero siempre habrá uno por defecto, que será, cualquier endorsement peer de la organización.
Finalmente, cuando el cliente recibe la respuesta de todos los endorsing peers o tiene el número suficiente de respuestas válidas se las envía al orderer para que siga el flujo de transacción.
tecnologías como Blockchain. Teniendo Hyperledger, Ethereum y Quorum como punta de flecha para enfrentarnos a nuevos proyectos. Puedes encontrar más artículos tecnológicos en nuestro blog.
Si has encontrado algún error, tienes alguna sugerencia o algo no te cuadra no dudes en ponerlo en los comentarios. Por otro lado, si te ha gustado este post no olvides de darle a 👏 !!
