Buenas tardes, queridos lectores, mi nombre es Nikolai Nefedov, soy consultor técnico en IBM, en este artículo me gustaría presentarles la plataforma blockchain: Hyperledger Fabric. La plataforma está diseñada para crear aplicaciones empresariales a nivel empresarial (clase empresarial). Nivel de artículo: para lectores no capacitados con conocimientos básicos de tecnología de TI.
Hyperledger Fabric es un proyecto de código abierto, una de las ramas del proyecto de código abierto Hyperledger, un consorcio de la Fundación Linux. Hyperledger Fabric fue lanzado originalmente por Digital Assets e IBM. La característica principal de la plataforma Hyperledger Fabric es su enfoque en aplicaciones corporativas. Por lo tanto, la plataforma se desarrolló teniendo en cuenta la alta velocidad de las transacciones y su bajo costo, así como la identificación de todos los participantes. Estas ventajas se logran mediante la separación del servicio de verificación de transacciones y la formación de nuevos bloques del registro distribuido, así como el uso de una autoridad de certificación y la autorización de los participantes.
Mi artículo es parte de una serie de artículos sobre Hyperledger Fabric en el marco del cual describimos el diseño de un sistema de contabilidad para los estudiantes que ingresan a la universidad.
Arquitectura general de la tela Hyperledger
Hyperledger Fabric es una red de blockchain distribuida que consta de varios componentes funcionales que se instalan en los nodos de la red. Los componentes de Hyperledger Fabric son contenedores Docker que se pueden descargar libremente desde DockerHub. Hyperledger Fabric también se puede ejecutar en entornos Kubernetes.
Para escribir contratos inteligentes (chaincode en el contexto de Hyperledger Fabric) utilizamos Golang (aunque Hyperledger Fabric le permite usar otros idiomas). En nuestro caso, Node.js con el correspondiente SDK de Hyperledger Fabric se utilizó para desarrollar una aplicación personalizada.
Los nodos ejecutan lógica de negocios (contrato inteligente): chaincode, almacenan el estado del registro distribuido (datos contables) y ejecutan otros servicios del sistema de la plataforma. Un nodo es solo una unidad lógica, pueden existir diferentes nodos en el mismo servidor físico. Mucho más importante es cómo se agrupan los nodos (dominio de confianza) y con qué funciones de la red blockchain están asociados.
La arquitectura general es la siguiente:
Imagen 1. Arquitectura general del tejido Hyperledger
Aplicación de usuario (Submitting Client): una aplicación con la que los usuarios trabajan con la red blockchain. Para trabajar, debe estar autorizado y tener los derechos apropiados para varios tipos de acciones en la red.
Los compañeros tienen varios roles:
- Endorsing Peer: un nodo que simula la ejecución de una transacción (ejecuta un código de contrato inteligente). Después de verificar y ejecutar el contrato inteligente, el nodo devuelve los resultados de la aplicación del cliente junto con su firma.
- Servicio de pedidos: un servicio distribuido en varios nodos, sirve para formar nuevos bloques de un registro distribuido y crear una secuencia de transacciones. El Servicio de pedidos no agrega nuevos bloques al registro (para mejorar el rendimiento, esta función se ha movido a Comprometer pares).
- Par de confirmación: un nodo que contiene un registro distribuido y agrega nuevos bloques al registro (que formó el Servicio de pedidos). Todos los pares comprometidos contienen una copia local del registro distribuido. El par que se compromete, antes de agregar localmente un nuevo bloque, verifica la validez de todas las transacciones dentro del bloque.
La Política de respaldo es una política de validación de transacciones. Estas políticas determinan el conjunto necesario de nodos en los que se debe ejecutar un contrato inteligente para que la transacción se reconozca como válida.
Registro distribuido - Lerger - consta de dos partes: WolrldState (también llamado - State DataBase) y BlockChain.
BlockChain es una cadena de bloques que almacena registros de todos los cambios que se han producido con objetos de registro distribuidos.
WolrldState es un componente de un registro distribuido que almacena los valores actuales (extremos) de todos los objetos en un registro distribuido.
WorldState es una base de datos, en la versión básica - LevelDB o más compleja - CouchDB, que contiene pares clave-valor, por ejemplo: Nombre - Ivan, Apellido - Ivanov, fecha de registro en el sistema - 12/12/21, fecha de nacimiento - 17/12/1961, etc. WorldState y el registro distribuido deben ser coherentes con todos los miembros de este canal.
Dado que Hyperledger Fabric es una red en la que todos los participantes son conocidos y autenticados, aquí se utiliza una autoridad de certificación dedicada: CA (Autoridad de certificación). CA opera sobre la base de la infraestructura de clave pública y estándar X.509: PKI.
El Servicio de Membresía es un servicio a través del cual los participantes verifican la propiedad de un objeto en una organización o canal en particular.
Una transacción es, en la mayoría de los casos, un registro de datos nuevos en un registro distribuido.
También hay transacciones para crear canales o contratos inteligentes. La aplicación de usuario inicia la transacción y finaliza con un registro en el registro distribuido.
Un canal es una subred cerrada que consta de dos o más participantes en una red blockchain, diseñada para realizar transacciones confidenciales dentro de un círculo limitado pero conocido de participantes. El canal está definido por los participantes, su registro distribuido, contratos inteligentes, Servicio de pedidos, WorldState. Cada miembro del canal debe estar autorizado para acceder al canal y tener derecho a realizar varios tipos de transacciones. La autorización se realiza utilizando el Servicio de Membresía.
Escenario típico de ejecución de transacciones
A continuación, me gustaría hablar sobre un escenario típico de ejecución de transacción utilizando nuestro proyecto como ejemplo.
Como parte de nuestro proyecto interno, creamos la red Hyperledger Fabric, que está diseñada para registrar y registrar a los estudiantes que ingresan a las universidades. Nuestra red consta de dos organizaciones que pertenecen a la Universidad A y a la Universidad B. Cada organización contiene una aplicación de cliente, así como su Par de Compromiso y Endoso. También utilizamos los servicios comunes Servicio de pedidos, Servicio de memebership y Autoridad de certificación.
1) Iniciación de transacción
La aplicación de usuario, utilizando el SDK de Hyperledger Fabric, inicia una solicitud de transacción y envía una solicitud a los nodos con contratos inteligentes. La solicitud puede ser para modificación o lectura de un registro distribuido (Ledger). Si consideramos un ejemplo de nuestra configuración de prueba de un sistema para estudiantes universitarios de contabilidad, la aplicación del cliente envía una solicitud de transacción a los nodos de las universidades A y B, que están incluidos en la política de aprobación del contrato inteligente llamado. El nodo A es un nodo que está en una universidad que registra a un estudiante entrante, y el nodo B es un nodo que está en otra universidad. Para que una transacción se almacene en un registro distribuido, es necesario que todos los nodos que, de acuerdo con la lógica empresarial, deben aprobar la transacción, ejecuten con éxito contratos inteligentes con el mismo resultado. La aplicación de usuario del nodo A, que utiliza las herramientas del SDK de Hyperledger Fabric, recibe una política de aprobación y descubre a qué nodos deben enviar una solicitud de transacción. Esta es una solicitud para invocar un contrato inteligente específico (función chaincode) para leer o escribir ciertos datos en un registro distribuido. Técnicamente, el SDK del cliente utiliza la función correspondiente, la API de la cual pasa un objeto con parámetros de transacción, y también agrega la firma del cliente y envía estos datos a través del búfer de protocolo a través de gRPC a los nodos correspondientes (homólogos de respaldo).
Cuadro 2. Iniciación de la transacción
2) Cumplimiento de un contrato inteligente
Los nodos (Endorsing Peers), después de recibir una solicitud de transacción, verifican la firma del cliente y, si todo está en orden, toman un objeto con los datos de la solicitud e inician la simulación de la ejecución del contrato inteligente (función chaincode) con estos datos. Un contrato inteligente es una lógica comercial de una transacción, un cierto conjunto de condiciones e instrucciones (en nuestro caso, es la verificación de un estudiante, este es un estudiante nuevo o ya está registrado, verificación de edad, etc.). Para ejecutar un contrato inteligente, también necesitará datos de WorldState. Como resultado de la simulación del contrato inteligente en el endoso par, se obtienen dos conjuntos de datos: conjunto de lectura y conjunto de escritura. El conjunto de lectura y el conjunto de escritura son los valores originales y nuevos de WorldState. (nuevo: en el sentido obtenido durante la simulación de un contrato inteligente).
Cuadro 3. Ejecución de un contrato inteligente
3) Devolución de datos a la aplicación del cliente
Después de la simulación del contrato inteligente, Endorsing Peers devuelve los datos iniciales y el resultado de la simulación, así como el RW Set, firmado con su certificado, a la aplicación del cliente. En esta etapa, no se realizan cambios en el registro distribuido. La aplicación del cliente verifica la firma del Endorsing Peer y también compara los datos de origen de la transacción que se envió y los datos que se devolvieron (es decir, verifica si los datos de origen en los que se simuló la transacción estaban distorsionados). Si la transacción fue solo para leer datos del registro, entonces la aplicación cliente recibe el conjunto de lectura necesario y esto generalmente completa la transacción con éxito sin cambiar el registro distribuido. En el caso de una transacción que se supone que cambia los datos en el registro, la aplicación del cliente verifica adicionalmente la implementación de la política de aprobación. Es posible que la aplicación cliente no verifique el resultado de la Política de aprobación, pero la plataforma Hyperledger Fabric en este caso proporciona políticas de verificación en los nodos (Comitting Peers) en la etapa de agregar una transacción al registro.
Imagen 4. Devolución de datos a la aplicación cliente
4) Envío de conjuntos RW a pares de pedidos
La aplicación cliente envía la transacción junto con los datos asociados al servicio de pedidos. Esto incluye el conjunto RW, los pares de respaldo y la ID del canal.
Servicio de pedidos: según el nombre, la función principal de este servicio es crear transacciones entrantes en el orden correcto. Además de la formación de un nuevo bloque del registro distribuido y la entrega garantizada de nuevos bloques formados a todos los nodos de Compromiso, asegurando así la consistencia de los datos en todos los nodos que contienen el registro distribuido (pares de Compromiso). Al mismo tiempo, el servicio de pedidos en sí no cambia el registro. Ordering Service es un componente vital del sistema, por lo que es un clúster de varios nodos. El Servicio de pedidos no verifica la validez de la transacción, simplemente acepta una transacción con un identificador de canal específico, organiza las transacciones entrantes en un cierto orden y forma nuevos bloques del registro distribuido a partir de ellas. Un servicio de pedidos puede servir varios canales simultáneamente. El Servicio de pedidos incluye un clúster de Kafka, que admite la cola de transacciones correcta (sin cambios) (ver Cláusula 7).
Imagen 5. Envío de conjuntos RW a pares de pedidos
Los bloques formados en el Servicio de pedidos se transmiten a todos los nodos de la red. Cada nodo, después de haber recibido un nuevo bloque, verifica su cumplimiento con la Política de aprobación, verifica que todos los Pares de aprobación hayan recibido el mismo resultado (Conjunto de escritura) como resultado de simular un contrato inteligente, y también verifica si los valores iniciales han cambiado (es decir, Conjunto de lectura) datos leídos por un contrato inteligente de WorldState) desde que se inició la transacción. Si se cumplen todas las condiciones, la transacción se marca como válida; de lo contrario, la transacción recibe un estado que no es válido.
Imagen 6. Envío de bloques formados a Comprometerse entre pares
6) Agregar un bloque al registro
Cada nodo agrega una transacción a su copia local del registro distribuido, y si la transacción es válida, el conjunto de escritura se aplica a WorldState (estado actual), en consecuencia, se registran nuevos valores de los objetos que fueron afectados por la transacción. Si la transacción recibió un marcador, no válido (por ejemplo, dos transacciones ocurrieron con los mismos objetos dentro del mismo bloque, entonces una de las transacciones resultará inválida, ya que los valores iniciales ya han sido cambiados por la otra transacción). Esta transacción también se agrega al registro distribuido con un token que no es válido, pero el conjunto de escritura de esta transacción no se aplica al estado actual de WorldState y, en consecuencia, no modifica los objetos que participan en la transacción. Después de esto, se envía una notificación a la aplicación del usuario de que la transacción se agrega para siempre al registro distribuido, así como el estado de la transacción, es decir, si es válida o no ...
Imagen 7. Agregar un bloque al registro
SERVICIO DE PEDIDO
El servicio de pedidos consta de un clúster de Kafka con los nodos ZooKeeper correspondientes y los nodos del servicio de pedidos (OSN), que se encuentran entre los clientes del servicio de pedidos y el clúster de Kafka. Kafka Cluster es una plataforma de administración de flujo (mensajería) distribuida y tolerante a fallas. Cada canal (tema) en Kafka es una secuencia inmutable de registros que solo admite agregar un nuevo registro (no es posible eliminar uno existente). A continuación se muestra una ilustración de la estructura del tema. Es esta propiedad de Kafka la que se usa para construir la plataforma blockchain.
tomado de kafka.apache.org
Imagen 8. Estructura del tema del servicio de pedidos
Enlaces utiles
Youtube - Construyendo una blockchain para negocios con el Proyecto Hyperledger
Documentos de tela de Hyperledger
Hyperledger fabric: un sistema operativo distribuido para blockchains con permiso
Agradecimientos
Expreso mi profunda gratitud por la ayuda en la preparación del artículo a mis colegas:
Nikolay Marina
Igor Hapov
Dmitry Gorbachev
Alexander Zemtsov
Ekaterina Kurdenkova
Ekaterina Guseva