Tela Hyperledger para Dummies

Una plataforma Blockchain para la empresa



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


5) Enviar bloques formados a Comprometerse entre pares

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

Source: https://habr.com/ru/post/444874/


All Articles