Uma plataforma Blockchain para a empresa
Boa tarde, queridos leitores, meu nome é Nikolai Nefedov, sou um especialista técnico da IBM, neste artigo gostaria de apresentar a plataforma blockchain - Hyperledger Fabric. A plataforma destina-se à construção de aplicativos de negócios de nível empresarial (classe Enterprise). O nível do artigo é para leitores despreparados com conhecimentos básicos de tecnologias de TI.
O Hyperledger Fabric é um projeto de código aberto, uma das ramificações do projeto de código aberto Hyperledger, um consórcio da Linux Foundation. O Hyperledger Fabric foi originalmente lançado pela Digital Assets e pela IBM. A principal característica da plataforma Hyperledger Fabric é seu foco em aplicativos corporativos. Portanto, a plataforma foi desenvolvida levando em consideração a alta velocidade das transações e seu baixo custo, bem como a identificação de todos os participantes. Esses benefícios são obtidos separando o serviço de verificação de transações e formando novos blocos do registro distribuído, bem como usando uma autoridade certificadora e autorizando participantes.
Meu artigo faz parte de uma série de artigos sobre Hyperledger Fabric em que descrevemos o projeto de um sistema de cadastro de alunos ingressantes em uma universidade.
Arquitetura geral do Hyperledger Fabric
O Hyperledger Fabric é uma rede blockchain distribuída que consiste em vários componentes funcionais instalados nos nós da rede. Os componentes do Hyperledger Fabric são contêineres do Docker que podem ser baixados gratuitamente do DockerHub. O Hyperledger Fabric também pode ser executado em um ambiente Kubernetes.
Para escrever contratos inteligentes (chaincode no contexto do Hyperledger Fabric), usamos Golang (embora o Hyperledger Fabric permita que você use outros idiomas). Para desenvolver um aplicativo personalizado, em nosso caso, Node.js foi usado com o Hyperledger Fabric SDK correspondente.
Os nós executam a lógica de negócios (contrato inteligente) – chaincode, armazenam o estado do registro distribuído (dados do ledger) e executam outros serviços do sistema da plataforma. Um nó é apenas uma unidade lógica, diferentes nós podem existir no mesmo servidor físico. Muito mais importante é como os nós são agrupados (domínio confiável) e a quais funções da rede blockchain eles estão associados.
A arquitetura geral é assim:
Figura 1. Arquitetura geral do Hyperledger Fabric
O aplicativo do usuário (cliente de envio) é um aplicativo com o qual os usuários trabalham com a rede blockchain. Para funcionar, você precisa obter autorização e ter os direitos apropriados para vários tipos de ações na rede.
Peers (nós) vêm em várias funções:
- Endorsing Peer é um nó que simula a execução de uma transação (executa o código do contrato inteligente). Depois de validar e executar o contrato inteligente, o nó retorna os resultados da execução para o aplicativo cliente junto com sua assinatura.
- Ordering Service é um serviço distribuído em vários nós, é usado para formar novos blocos do ledger distribuído e criar uma sequência para executar transações. O Serviço de Solicitação não adiciona novos blocos ao registro (Movido para Commit Peers para melhor desempenho).
- Committed Peer - um nó que contém um registro distribuído e adiciona novos blocos ao registro (que foram formados pelo Ordering Service). Todos os pares de confirmação contêm uma cópia local do registro distribuído. O Committed Peer, antes de adicionar um novo bloco localmente, verifica todas as transações dentro do bloco quanto à validade.
A política de endosso é uma política para verificar a validade de uma transação. Essas políticas definem o conjunto necessário de nós nos quais o contrato inteligente deve ser executado para que a transação seja reconhecida como válida.
O registro distribuído - Lerger - consiste em duas partes: WolrldState (também chamado State DataBase) e BlockChain.
BlockChain é uma cadeia de blocos que armazena registros de todas as alterações que ocorreram nos objetos do livro-razão distribuído.
WolrldState é um componente de registro distribuído que armazena os valores atuais (extremos) de todos os objetos de registro distribuídos.
WorldState é um banco de dados, na versão básica - LevelDB ou mais complexo - CouchDB, que contém pares chave-valor, por exemplo: Nome - Ivan, Sobrenome - Ivanov, data de registro no sistema - 12.12.21/17.12.1961/XNUMX, data de nascimento - XNUMX/XNUMX/XNUMX, etc. WorldState e o ledger distribuído devem ser consistentes em todos os membros de um determinado canal.
Como o Hyperledger Fabric é uma rede na qual todos os participantes são conhecidos e autenticados, uma autoridade de certificação dedicada é usada aqui - CA (Autoridade de Certificação). A CA opera com base no padrão X.509 e na infra-estrutura de chave pública - PKI.
Membership Service é um serviço através do qual os membros verificam se um objeto pertence a uma determinada organização ou canal.
Uma transação é, na maioria dos casos, um registro de novos dados em um ledger distribuído.
Existem também transações para a criação de canais ou contratos inteligentes. A transação é iniciada pelo aplicativo do usuário e termina com uma gravação no ledger distribuído.
Canal (Channel) é uma sub-rede fechada composta por dois ou mais participantes na rede blockchain, projetada para conduzir transações confidenciais dentro de um círculo limitado, mas conhecido, de participantes. O canal é determinado pelos participantes, seu ledger distribuído, contratos inteligentes, Ordering Service, WorldState. Cada membro do canal deve ser autorizado a acessar o canal e ter o direito de realizar vários tipos de transações. A autorização é realizada usando o Membership Service.
Cenário típico de execução de transação
A seguir, gostaria de falar sobre um cenário típico de execução de uma transação usando o exemplo do nosso projeto.
Como parte de nosso projeto interno, criamos uma rede Hyperledger Fabric, destinada a registrar e registrar os alunos que ingressam nas universidades. Nossa rede consiste em duas organizações, de propriedade da Universidade A e da Universidade B. Cada organização contém um aplicativo cliente, bem como seu próprio Par de Compromisso e Endossamento. Também utilizamos os serviços comuns de Ordering Service, Membership Service e Certification Authority.
1) Iniciação da transação
O aplicativo do usuário, usando o Hyperledger Fabric SDK, inicia uma solicitação de transação e envia a solicitação para nós com contratos inteligentes. A solicitação pode ser para alterar ou ler de um ledger distribuído (Ledger). Se considerarmos um exemplo de nossa configuração de teste do sistema de contabilidade para estudantes universitários, o aplicativo cliente envia uma solicitação de transação para os nós das universidades A e B, que estão incluídos na política de Endosso do chamado contrato inteligente. O nó A é um nó localizado na universidade que registra um aluno ingressante e o nó B é um nó localizado em outra universidade. Para que uma transação seja salva em um ledger distribuído, é necessário que todos os nós que, de acordo com a lógica de negócios, devem aprovar a transação, executem contratos inteligentes com o mesmo resultado. O aplicativo do usuário do nó A, usando as ferramentas Hyperledger Fabric SDK, recebe a política de endosso (política de aprovação) e descobre para quais nós enviar uma solicitação de transação. Esta é uma solicitação para chamar (invocar) um determinado contrato inteligente (função chaincode) para ler ou gravar determinados dados no registro distribuído. Tecnicamente, o SDK do cliente usa a função correspondente, cuja API recebe um objeto com parâmetros de transação e também adiciona uma assinatura do cliente e envia esses dados via buffer de protocolo sobre gRPC para os nós apropriados (pontos de endosso).
Figura 2. Iniciação da Transação
2) Execução de contrato inteligente
Nós (Endorsing Peers), tendo recebido uma solicitação para realizar uma transação, verificam a assinatura do cliente e, se tudo estiver em ordem, pegam um objeto com os dados da solicitação e executam uma simulação da execução de um contrato inteligente (função chaincode) com esses dados. Um contrato inteligente é a lógica de negócios de uma transação, um determinado conjunto de condições e instruções (no nosso caso, é um cheque estudantil, é um aluno novo ou já está matriculado, cheque de idade etc.). Para executar um contrato inteligente, você também precisará de dados do WorldState. Como resultado da simulação do contrato inteligente no ponto de endosso, são obtidos dois conjuntos de dados - conjunto de leitura e conjunto de gravação. Read Set e Write Set são os valores originais e novos de WorldState. (novo - no sentido obtido pela simulação de um contrato inteligente).
Figura 3. Execução do contrato inteligente
3) Retornando dados para o aplicativo cliente
Após a simulação do smart contract, os Endorsing Peers devolvem à aplicação cliente os dados iniciais e o resultado da simulação, bem como o RW Set assinado pelo seu certificado. Nesta fase, não há alterações no livro razão distribuído. A aplicação cliente verifica a assinatura do Endorsing Peer, e também compara os dados originais da transação que foi enviada e os dados que retornaram (ou seja, verifica se os dados originais sobre os quais a transação foi simulada foram corrompidos). Se a transação for apenas para leitura de dados do registro, o aplicativo cliente receberá o conjunto de leitura necessário e, com isso, a transação geralmente será concluída com êxito sem alterar o registro distribuído. No caso de uma transação que deva alterar os dados no registro, o aplicativo cliente verifica adicionalmente se a política de Endosso foi implementada. É possível que o aplicativo cliente não verifique o resultado da execução da política de endosso, mas a plataforma Hyperledger Fabric, neste caso, fornece a verificação das políticas nos nós (commit peers) no estágio de adicionar uma transação ao registro.
Figura 4. Retornando dados para a aplicação cliente
4) Envio de conjuntos RW para Ordenar Peers
O aplicativo cliente envia a transação junto com os dados relacionados ao serviço de Pedidos. Isso inclui o conjunto de RW, assinaturas de pares endossantes e o ID do canal.
Serviço de pedidos - Com base no nome, a principal função desse serviço é criar as transações de entrada na ordem correta. Assim como a formação de um novo bloco do registro distribuído e a entrega garantida dos novos blocos gerados a todos os nós Commiting, garantindo assim a consistência dos dados em todos os nós que contêm o registro distribuído (commiting peers). Ao mesmo tempo, o próprio serviço de pedidos não altera o registro de forma alguma. O serviço de pedidos é um componente vital do sistema, por isso é um cluster de vários nós. O Serviço de Pedidos não verifica a validade da transação, ele simplesmente aceita uma transação com um ID de canal específico, organiza as transações recebidas em um pedido específico e forma novos blocos do livro-razão distribuído a partir delas. Um Serviço de Pedidos pode atender vários canais ao mesmo tempo. O Ordering Service inclui um cluster Kafka, que mantém a fila de transações correta (inalterada) (consulte o ponto 7).
Figura 5. Envio de conjuntos RW para Ordering Peers
5) Enviando os blocos gerados para o Committed Peer
Os blocos formados no Serviço de Pedido são transmitidos para todos os nós da rede. Cada nó, tendo recebido um novo bloco, verifica a conformidade com a Política de Endossamento, verifica se todos os Pares de Endossamento receberam o mesmo resultado (Write Set) como resultado da simulação do contrato inteligente e também verifica se os valores originais foram alterado (ou seja, - Read Set - dados lidos pelo contrato inteligente do WorldState) desde o início da transação. Se todas as condições forem atendidas, a transação é marcada como válida, caso contrário, a transação recebe o status de não válida.
Figura 6. Enviando os blocos gerados para o Committed Peer
6) Adicionando um bloco ao registro
Cada nó adiciona uma transação à sua cópia local do ledger distribuído e, se a transação for válida, o Write Set é aplicado ao WorldState (estado atual), respectivamente, novos valores de objetos que foram afetados pela transação são gravados . Se uma transação recebeu um token que não era válido (por exemplo, houve duas transações com os mesmos objetos dentro do mesmo bloco, então uma das transações não será válida, pois os valores originais já foram alterados por outra transação ). Esta transação também é adicionada ao ledger distribuído com um marcador inválido, mas o Write Set desta transação não se aplica ao estado atual do WorldState e, portanto, não altera os objetos participantes da transação. Após isso, é enviada uma notificação para a aplicação do usuário informando que a transação foi adicionada ao ledger distribuído para sempre, assim como o status da transação, ou seja, se ela é válida ou não...
Figura 7. Adicionando um bloco ao registro
PEDIDO DE SERVIÇO
O Ordering Service consiste em um cluster Kafka com nós ZooKeeper correspondentes e um Ordering Service Nodes (OSN) que fica entre os clientes do serviço Ordering e o Kafka Cluster. O cluster Kafka é uma plataforma de gerenciamento de fluxo (mensagem) distribuída e tolerante a falhas. Cada canal (tópico) no Kafka é uma sequência imutável de registros que suporta apenas a adição de um novo registro (excluir um existente não é possível). Uma ilustração da estrutura do tópico é dada abaixo. É essa propriedade de Kafka que é usada para construir a plataforma blockchain.
retirado de kafka.apache.org
- Figura 8. Estrutura do Tópico do Serviço de Pedido*
Links Úteis
Agradecimentos
Expresso minha profunda gratidão aos meus colegas pela ajuda na preparação do artigo:
Nikolai Marina
Igor Khapov
Dmitry Gorbachev
Alexandre Zemtsov
Ekaterina Guseva
Fonte: habr.com