Una plataforma Blockchain para la empresa
Buenas tardes, queridos lectores, mi nombre es Nikolai Nefedov, soy especialista técnico de IBM, en este artículo me gustaría presentarles la plataforma blockchain - Hyperledger Fabric. La plataforma está diseñada para crear aplicaciones comerciales de nivel empresarial (clase Enterprise). El nivel del artículo es para lectores no preparados con conocimientos básicos de tecnologías de la información.
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 las 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. Estos beneficios se logran separando el servicio de verificación de transacciones y formando nuevos bloques del registro distribuido, así como utilizando una autoridad de certificación y autorizando a los participantes.
Mi artículo es parte de una serie de artículos sobre Hyperledger Fabric en los que describimos el proyecto de un sistema para registrar estudiantes que ingresan a una universidad.
Arquitectura general de Hyperledger Fabric
Hyperledger Fabric es una red blockchain distribuida que consta de varios componentes funcionales que se instalan en los nodos de la red. Los componentes de Hyperledger Fabric son contenedores de Docker que se pueden descargar libremente desde DockerHub. Hyperledger Fabric también se puede ejecutar en un entorno de Kubernetes.
Para escribir contratos inteligentes (código de cadena en el contexto de Hyperledger Fabric), usamos Golang (aunque Hyperledger Fabric le permite usar otros lenguajes). Para desarrollar una aplicación a medida, en nuestro caso, se utilizó Node.js con el correspondiente SDK de Hyperledger Fabric.
Los nodos ejecutan la lógica comercial (contrato inteligente): código de cadena, almacenan el estado del registro distribuido (datos del libro mayor) 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 se ve así:
Imagen 1. Arquitectura general de Hyperledger Fabric
La aplicación de usuario (cliente de envío) es una aplicación con la que los usuarios trabajan con la red blockchain. Para trabajar, debe pasar por la autorización y tener los derechos apropiados para varios tipos de acciones en la red.
Los pares (nodos) vienen en varios roles:
- Endorsing Peer es un nodo que simula la ejecución de una transacción (ejecuta el código del contrato inteligente). Después de validar y ejecutar el contrato inteligente, el nodo devuelve los resultados de la ejecución a la aplicación cliente junto con su firma.
- Ordering Service es un servicio distribuido en varios nodos, se utiliza para formar nuevos bloques del libro mayor distribuido y crear una secuencia para ejecutar transacciones. El Servicio de pedidos no agrega nuevos bloques al registro (Movido a Committing Peers para un mejor rendimiento).
- Committing Peer: un nodo que contiene un registro distribuido y agrega nuevos bloques al registro (que fueron formados por el servicio de pedidos). Todos los compañeros de compromiso contienen una copia local del libro mayor distribuido. El par de compromiso, antes de agregar un nuevo bloque localmente, verifica la validez de todas las transacciones dentro del bloque.
La política de respaldo es una política para verificar la validez de una transacción. Estas políticas definen el conjunto necesario de nodos en los que se debe ejecutar el contrato inteligente para que la transacción se reconozca como válida.
El 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 en los objetos del libro mayor distribuido.
WolrldState es un componente de registro distribuido que almacena los valores actuales (extremos) de todos los objetos de registro distribuidos.
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/17.12.1961/XNUMX, fecha de nacimiento - XNUMX/XNUMX/XNUMX, etc. WorldState y el libro mayor distribuido deben ser coherentes en todos los miembros de un canal determinado.
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 del estándar X.509 y la infraestructura de clave pública - PKI.
Membership Service es un servicio a través del cual los miembros verifican que un objeto pertenece a una organización o canal en particular.
Una transacción es, en la mayoría de los casos, un registro de nuevos datos en un libro mayor distribuido.
También existen transacciones para la creación de canales o contratos inteligentes. La transacción es iniciada por la aplicación del usuario y finaliza con una escritura en el libro mayor distribuido.
Canal (Channel) es una subred cerrada que consta de dos o más participantes en la red blockchain, diseñada para realizar transacciones confidenciales dentro de un círculo de participantes limitado pero conocido. El canal está determinado por los participantes, su libro mayor 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 mediante 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 para ejecutar una transacción usando el ejemplo de nuestro proyecto.
Como parte de nuestro proyecto interno, hemos creado una 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, propiedad de la Universidad A y la Universidad B. Cada organización contiene una aplicación de cliente, así como su propio Compromiso y aprobación. También utilizamos los servicios comunes de Servicio de Pedidos, Servicio de Membresía y Autoridad de Certificación.
1) Inicio de transacción
La aplicación de usuario, utilizando el SDK de Hyperledger Fabric, inicia una solicitud de transacción y envía la solicitud a los nodos con contratos inteligentes. La solicitud puede ser para cambiar o leer de un libro mayor distribuido (Ledger). Si consideramos un ejemplo de nuestra configuración de prueba del sistema para la contabilidad de estudiantes universitarios, entonces la aplicación 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 se encuentra en la universidad que registra un estudiante entrante y el nodo B es un nodo que se encuentra en otra universidad. Para que una transacción se guarde en un libro mayor distribuido, es necesario que todos los nodos que, de acuerdo con la lógica comercial, deben aprobar la transacción, ejecuten con éxito contratos inteligentes con el mismo resultado. La aplicación de usuario del nodo A, utilizando las herramientas del SDK de Hyperledger Fabric, recibe la política de endoso (política de aprobación) y averigua a qué nodos enviar una solicitud de transacción. Esta es una solicitud para llamar (invocar) un determinado contrato inteligente (función de código de cadena) para leer o escribir ciertos datos en el libro mayor distribuido. Técnicamente, el SDK del cliente usa la función correspondiente, cuya API pasa un objeto con parámetros de transacción, y también agrega una 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 (aprobadores del mismo nivel).
Imagen 2. Inicio de transacción
2) Ejecución de contrato inteligente
Los nodos (Endorsing Peers), al recibir una solicitud para realizar una transacción, verifican la firma del cliente y si todo está en orden, luego toman un objeto con los datos de la solicitud y ejecutan una simulación de la ejecución de un contrato inteligente (función de código de cadena) con estos datos. Un contrato inteligente es la lógica comercial de una transacción, un determinado conjunto de condiciones e instrucciones (en nuestro caso, se trata de un cheque de estudiante, 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 par de respaldo, se obtienen dos conjuntos de datos: conjunto de lectura y conjunto de escritura. Read Set y Write Set son los valores originales y nuevos de WorldState. (nuevo - en el sentido obtenido al simular un contrato inteligente).
Imagen 3. Ejecución de contrato inteligente
3) Devolver datos a la aplicación cliente
Luego de la simulación del contrato inteligente, los Endorsing Peers devuelven a la aplicación cliente los datos iniciales y el resultado de la simulación, así como el RW Set firmado por su certificado. En esta etapa, no hay cambios en el libro mayor distribuido. La aplicación cliente verifica la firma del par que respalda y también compara los datos de la transacción original que se envió y los datos que se devolvieron (es decir, verifica si los datos originales en los que se simuló la transacción se han dañado). Si la transacción fue solo para leer datos del registro, entonces la aplicación del cliente recibe el conjunto de lectura necesario, y en este la transacción generalmente se completa con éxito sin cambiar el registro distribuido. En el caso de una transacción que deba cambiar los datos en el registro, la aplicación cliente verifica adicionalmente si se ha implementado la política de endoso. Es posible que la aplicación cliente no verifique el resultado de la ejecución de la Política de respaldo, pero la plataforma Hyperledger Fabric en este caso prevé verificar las políticas en los nodos (Comitting Peers) en la etapa de agregar una transacción al registro.
Imagen 4. Devolviendo datos a la aplicación cliente
4) Envío de conjuntos de RW a pares de pedidos
La aplicación cliente envía la transacción junto con los datos relacionados al servicio de pedidos. Esto incluye el conjunto de RW, las firmas de los pares de respaldo y la identificación del canal.
Servicio de pedidos: según el nombre, la función principal de este servicio es generar 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 generados 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í mismo no cambia el registro de ninguna manera. El servicio de pedidos es un componente vital del sistema, por lo que es un grupo de varios nodos. El servicio de pedidos no verifica la validez de la transacción, simplemente acepta una transacción con un ID de canal específico, organiza las transacciones entrantes en un orden específico y forma nuevos bloques del libro mayor distribuido a partir de ellas. Un servicio de pedidos puede atender varios canales al mismo tiempo. El servicio de pedidos incluye un clúster de Kafka, que mantiene la cola de transacciones correcta (sin cambios) (consulte el punto 7).
Imagen 5. Envío de conjuntos de RW a pares de pedidos
5) Envío de los bloques generados al Compromiso del Par
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 que cumpla 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 la simulación del contrato inteligente, y también verifica si los valores originales tienen cambiado (es decir, - Conjunto de lectura - datos leídos por el contrato inteligente de WorldState) desde el inicio de la transacción. Si se cumplen todas las condiciones, la transacción se marca como válida, de lo contrario, la transacción recibe el estado de no válida.
Imagen 6. Envío de bloques generados al Comprometimiento del Par
6) Agregar un bloque al registro
Cada nodo agrega una transacción a su copia local del libro mayor distribuido, y si la transacción es válida, se aplica Write Set al WorldState (estado actual), respectivamente, se escriben nuevos valores de los objetos que se vieron afectados por la transacción. . Si una transacción recibió un token que no era válido (por ejemplo, hubo dos transacciones con los mismos objetos dentro del mismo bloque, entonces una de las transacciones no será válida, ya que los valores originales ya fueron cambiados por otra transacción ). Esta transacción también se agrega al libro mayor distribuido con un marcador no válido, pero el conjunto de escritura de esta transacción no se aplica al estado actual de WorldState y, en consecuencia, no cambia los objetos que participan en la transacción. Después de eso, se envía una notificación a la aplicación del usuario de que la transacción se agregó al libro mayor distribuido para siempre, así como el estado de la transacción, es decir, si es válida o no ...
Imagen 7. Agregando un bloque al registro
SERVICIO DE PEDIDOS
El servicio de pedidos consta de un clúster de Kafka con los nodos de ZooKeeper correspondientes y un nodo de servicio de pedidos (OSN) que se encuentra entre los clientes del servicio de pedidos y el clúster de Kafka. El clúster de Kafka es una plataforma de administración de flujo (mensaje) 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 utiliza para construir la plataforma blockchain.
tomado de kafka.apache.org
- Imagen 8. Estructura del tema del servicio de pedidos*
Enlaces útiles
Agradecimientos
Expreso mi profundo agradecimiento a mis colegas por su ayuda en la preparación del artículo:
puerto deportivo nikolai
Igor Japov
Dmitri Gorbachov
Alejandro Zemtsov
Ekaterina Guseva
Fuente: habr.com