Unha plataforma Blockchain para a empresa
Boas tardes, queridos lectores, chámome Nikolai Nefedov, son un especialista técnico de IBM, neste artigo gustaríame presentarvos a plataforma blockchain - Hyperledger Fabric. A plataforma está pensada para crear aplicacións empresariais a nivel empresarial (clase Enterprise). O nivel do artigo é para lectores non preparados con coñecementos básicos das tecnoloxías informáticas.
Hyperledger Fabric é un proxecto de código aberto, unha das ramas do proxecto de código aberto Hyperledger, un consorcio da Fundación Linux. Hyperledger Fabric foi lanzado orixinalmente por Digital Assets e IBM. A principal característica da plataforma Hyperledger Fabric é o seu foco nas aplicacións corporativas. Por iso, a plataforma desenvolveuse tendo en conta a alta velocidade das transaccións e o seu baixo custo, así como a identificación de todos os participantes. Estes beneficios conséguense separando o servizo de verificación de transaccións e formando novos bloques do rexistro distribuído, así como empregando unha autoridade de certificación e autorizando aos participantes.
O meu artigo forma parte dunha serie de artigos sobre Hyperledger Fabric nos que describimos o proxecto dun sistema de rexistro de estudantes que ingresan nunha universidade.
Arquitectura xeral de Hyperledger Fabric
Hyperledger Fabric é unha rede de cadeas de bloques distribuída que consta de varios compoñentes funcionais que se instalan nos nodos da rede. Os compoñentes de Hyperledger Fabric son contedores Docker que se poden descargar libremente desde DockerHub. Hyperledger Fabric tamén se pode executar nun ambiente Kubernetes.
Para escribir contratos intelixentes (chaincode no contexto de Hyperledger Fabric), usamos Golang (aínda que Hyperledger Fabric permítelle usar outros idiomas). Para desenvolver unha aplicación personalizada, no noso caso, utilizouse Node.js co SDK de Hyperledger Fabric correspondente.
Os nodos executan a lóxica empresarial (contrato intelixente): código de cadea, almacena o estado do rexistro distribuído (datos do libro maior) e executa outros servizos do sistema da plataforma. Un nodo é só unha unidade lóxica, poden existir distintos nodos no mesmo servidor físico. Moito máis importante é como se agrupan os nodos (dominio de confianza) e con que funcións da rede blockchain están asociados.
A arquitectura xeral é así:
Imaxe 1. Arquitectura xeral de Hyperledger Fabric
A aplicación de usuario (Submitting Client) é unha aplicación coa que os usuarios traballan coa rede blockchain. Para funcionar, cómpre pasar pola autorización e ter os dereitos axeitados para varios tipos de accións na rede.
Os pares (nodos) teñen varios roles:
- Endorsing Peer é un nodo que simula a execución dunha transacción (executa o código de contrato intelixente). Despois de validar e executar o contrato intelixente, o nodo devolve os resultados de execución á aplicación cliente xunto coa súa sinatura.
- O servizo de pedidos é un servizo distribuído en varios nodos, úsase para formar novos bloques do libro maior distribuído e crear unha secuencia para executar transaccións. O servizo de pedidos non engade novos bloques ao rexistro (moveuse a Committing Peers para un mellor rendemento).
- Committing Peer - un nodo que contén un rexistro distribuído e engade novos bloques ao rexistro (que foron formados polo Servizo de pedidos). Todos os pares comprometidos conteñen unha copia local do libro maior distribuído. O Committing Peer, antes de engadir un novo bloque localmente, verifica a validez de todas as transaccións dentro do bloque.
A política de aval é unha política para comprobar a validez dunha transacción. Estas políticas definen o conxunto necesario de nodos nos que se debe executar o contrato intelixente para que a transacción sexa recoñecida como válida.
O Rexistro Distribuido - Lerger - consta de dúas partes: WolrldState (tamén chamada Base de Datos Estatal) e BlockChain.
BlockChain é unha cadea de bloques que almacena rexistros de todos os cambios que se produciron nos obxectos de contas distribuídas.
WolrldState é un compoñente de rexistro distribuído que almacena os valores actuais (extremos) de todos os obxectos de rexistro distribuídos.
WorldState é unha base de datos, na versión básica - LevelDB ou máis complexa - CouchDB, que contén pares clave-valor, por exemplo: Nome - Ivan, Apelido - Ivanov, data de rexistro no sistema - 12.12.21/17.12.1961/XNUMX, data de nacemento - XNUMX/XNUMX/XNUMX, etc. WorldState e o libro maior distribuído deben ser coherentes en todos os membros dunha determinada canle.
Dado que Hyperledger Fabric é unha rede na que todos os participantes son coñecidos e autenticados, aquí úsase unha autoridade de certificación dedicada: CA (Autoridade de certificación). CA funciona sobre a base do estándar X.509 e da infraestrutura de chave pública - PKI.
O servizo de adhesión é un servizo mediante o cal os membros verifican que un obxecto pertence a unha organización ou canle en particular.
Unha transacción é, na maioría dos casos, un rexistro de novos datos nun libro maior distribuído.
Tamén hai transaccións para a creación de canles ou contratos intelixentes. A transacción é iniciada pola aplicación do usuario e remata cunha escritura no libro maior distribuído.
A canle (Canle) é unha subrede pechada formada por dous ou máis participantes na rede blockchain, deseñada para realizar transaccións confidenciais dentro dun círculo limitado, pero coñecido, de participantes. A canle está determinada polos participantes, o seu libro maior distribuído, contratos intelixentes, servizo de pedidos, WorldState. Cada membro da canle debe estar autorizado para acceder á canle e ter dereito a realizar varios tipos de transaccións. A autorización realízase mediante o Servizo de Socios.
Escenario típico de execución de transaccións
A continuación, gustaríame falar dun escenario típico para executar unha transacción usando o exemplo do noso proxecto.
Como parte do noso proxecto interno, creamos unha rede Hyperledger Fabric, que está deseñada para rexistrar e rexistrar os estudantes que ingresan nas universidades. A nosa rede está formada por dúas organizacións, propiedade da Universidade A e da Universidade B. Cada organización contén unha aplicación cliente, así como o seu propio Compromiso e Endorsing Peer. Tamén utilizamos os servizos comúns do servizo de pedidos, do servizo de adhesión e da autoridade de certificación.
1) Inicio da transacción
A aplicación do usuario, que utiliza o SDK de Hyperledger Fabric, inicia unha solicitude de transacción e envía a solicitude a nós con contratos intelixentes. A solicitude pode ser para cambiar ou ler desde un libro maior distribuído (Ledger). Se consideramos un exemplo da nosa configuración de proba do sistema de contabilidade para estudantes universitarios, entón a aplicación cliente envía unha solicitude de transacción aos nodos das universidades A e B, que están incluídos na política de aval do chamado contrato intelixente. O nodo A é un nodo que se atopa na universidade que rexistra un estudante entrante e o nodo B é un nodo que se atopa noutra universidade. Para que unha transacción se garde nun libro maior distribuído, é necesario que todos os nodos que, segundo a lóxica empresarial, deben aprobar a transacción, executen con éxito contratos intelixentes co mesmo resultado. A aplicación de usuario do nodo A, mediante as ferramentas Hyperledger Fabric SDK, recibe a política de aprobación (política de aprobación) e descobre a que nodos enviar unha solicitude de transacción. Esta é unha solicitude para chamar (invocar) un determinado contrato intelixente (función de código de cadea) para ler ou escribir determinados datos no libro maior distribuído. Tecnicamente, o SDK do cliente usa a función correspondente, cuxa API se lle pasa un obxecto con parámetros de transacción, e tamén engade unha sinatura do cliente e envía estes datos a través do búfer de protocolo a través de gRPC aos nodos apropiados (pares de aprobación).
Imaxe 2. Inicio da transacción
2) Execución de contratos intelixentes
Nodos (Endorsing Peers), despois de recibir unha solicitude para realizar unha transacción, comproban a sinatura do cliente e se todo está en orde, toman un obxecto cos datos da solicitude e executan unha simulación da execución dun contrato intelixente (función de código de cadea). con estes datos. Un contrato intelixente é a lóxica empresarial dunha transacción, un determinado conxunto de condicións e instrucións (no noso caso, trátase dun cheque de estudante, é un estudante novo ou xa está rexistrado, comproba de idade, etc.). Para executar un contrato intelixente, tamén necesitará datos de WorldState. Como resultado da simulación de contrato intelixente no par Endorsing, obtéñense dous conxuntos de datos: conxunto de lectura e conxunto de escritura. Read Set e Write Set son os valores orixinais e novos de WorldState. (novo - no sentido obtido simulando un contrato intelixente).
Imaxe 3. Execución do contrato intelixente
3) Devolver os datos á aplicación cliente
Despois da simulación do contrato intelixente, Endorsing Peers devolve á aplicación cliente os datos iniciais e o resultado da simulación, así como o conxunto RW asinado polo seu certificado. Nesta fase, non hai cambios no libro maior distribuído. A aplicación cliente verifica a sinatura do Endorsing Peer e tamén compara os datos orixinais da transacción que se enviaron e os datos devoltos (é dicir, comproba se os datos orixinais nos que se simulou a transacción foron corrompidos). Se a transacción foi só para ler datos do rexistro, entón a aplicación cliente recibe o conxunto de lectura necesario e, neste caso, a transacción adoita completarse con éxito sen cambiar o rexistro distribuído. No caso dunha transacción que debería modificar os datos do rexistro, a aplicación cliente verifica adicionalmente se se implementou a política de aval. É posible que a aplicación cliente non comprobe o resultado da execución da política de aval, pero a plataforma Hyperledger Fabric neste caso prevé comprobar as políticas nos nodos (Comitting Peers) na fase de engadir unha transacción ao rexistro.
Imaxe 4. Devolver datos á aplicación cliente
4) Envío de conxuntos RW a Peers de orde
A aplicación cliente envía a transacción xunto cos datos relacionados ao servizo de pedidos. Isto inclúe o conxunto RW, as sinaturas dos compañeiros de apoio e o ID da canle.
Servizo de pedidos: segundo o nome, a función principal deste servizo é crear transaccións entrantes na orde correcta. Así como a formación dun novo bloque do rexistro distribuído e a entrega garantida de novos bloques xerados a todos os nodos de Committing, garantindo así a coherencia dos datos en todos os nodos que conteñen o rexistro distribuído (Committing peers). Ao mesmo tempo, o propio servizo de Pedidos non modifica o rexistro de ningún xeito. O servizo de pedidos é un compoñente vital do sistema, polo que é un clúster de varios nodos. O Servizo de Pedidos non verifica a validez da transacción, simplemente acepta unha transacción cun ID de canle específico, organiza as transaccións entrantes nunha orde específica e forma novos bloques do libro maior distribuído a partir delas. Un servizo de pedidos pode servir varias canles ao mesmo tempo. O servizo de pedidos inclúe un clúster de Kafka, que mantén a cola de transaccións correcta (sen cambios) (ver punto 7).
Imaxe 5. Envío de conxuntos RW a Peers de orde
5) Envío dos bloques xerados ao Committing Peer
Os bloques formados no Servizo de Pedidos son transmitidos a todos os nodos da rede. Cada nodo, despois de recibir un novo bloque, comproba o cumprimento da Política de Endorsing, comproba que todos os Endorsing Peers recibiron o mesmo resultado (Write Set) como resultado da simulación de contrato intelixente e tamén comproba se os valores orixinais cambiaron (é dicir, Read Set - datos lidos polo contrato intelixente de WorldState) desde o inicio da transacción. Se se cumpren todas as condicións, a transacción márcase como válida, se non, a transacción recibe o estado de non válida.
Imaxe 6. Envío de bloques xerados ao Committing Peer
6) Engadir un bloque ao rexistro
Cada nodo engade unha transacción á súa copia local do libro maior distribuído e, se a transacción é válida, aplícase Write Set ao WorldState (estado actual), respectivamente, escríbense novos valores dos obxectos afectados pola transacción. . Se unha transacción recibiu un token que non é válido (por exemplo, houbo dúas transaccións cos mesmos obxectos dentro do mesmo bloque, entón unha das transaccións non será válida, xa que os valores orixinais xa foron modificados por outra transacción). ). Esta transacción tamén se engade ao libro maior distribuído cun marcador non válido, pero o conxunto de escritura desta transacción non se aplica ao estado actual do WorldState e, en consecuencia, non cambia os obxectos que participan na transacción. Despois diso, envíase unha notificación á aplicación do usuario de que a transacción se engadiu ao libro maior distribuído para sempre, así como o estado da transacción, é dicir, se é válida ou non...
Imaxe 7. Engadindo un bloque ao rexistro
SERVIZO DE PEDIDOS
O servizo de pedidos consiste nun clúster de Kafka cos nodos ZooKeeper correspondentes e uns nodos de servizo de pedidos (OSN) que se sitúan entre os clientes do servizo de pedidos e o clúster de Kafka. Kafka cluster é unha plataforma de xestión de fluxos (mensaxes) distribuída e tolerante a fallos. Cada canle (tema) en Kafka é unha secuencia inmutable de rexistros que só admite engadir un novo rexistro (non é posible eliminar un existente). A continuación ofrécese unha ilustración da estrutura do tema. É esta propiedade de Kafka a que se usa para construír a plataforma blockchain.
tirado de kafka.apache.org
- Imaxe 8. Estrutura do tema do servizo de pedidos*
Ligazóns útiles
Agradecementos
Expreso o meu profundo agradecemento aos meus compañeiros pola súa axuda na preparación do artigo:
Nikolai Marina
Igor Khapov
Dmitri Gorbachov
Alexander Zemtsov
Ekaterina Guseva
Fonte: www.habr.com