Boa tarde, queridos leitores, meu nome é Nikolai Nefedov, sou consultor técnico da IBM. Neste artigo, gostaria de apresentar a plataforma blockchain - Hyperledger Fabric. A plataforma foi projetada para criar aplicativos de negócios no nível corporativo (classe Enterprise). Artigo - para leitores não treinados com um conhecimento básico de tecnologia 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 lançado originalmente pela Digital Assets e IBM. O principal recurso da plataforma Hyperledger Fabric é o 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. Essas vantagens são alcançadas através da separação do serviço de verificação de transações e da formação de novos blocos do registro distribuído, além do uso de uma autoridade de certificação e autorização dos participantes.
Meu artigo faz parte de uma série de artigos sobre o Hyperledger Fabric, no âmbito do qual descrevemos o design de um sistema de contabilidade para estudantes que ingressam 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 no DockerHub. O Hyperledger Fabric também pode ser executado em ambientes Kubernetes.
Para escrever contratos inteligentes (código de código no contexto do Hyperledger Fabric), usamos o Golang (embora o Hyperledger Fabric permita que você use outros idiomas). No nosso caso, o Node.js com o SDK do Hyperledger Fabric correspondente foi usado para desenvolver um aplicativo personalizado.
Os nós executam a lógica de negócios (contrato inteligente) - chaincode, armazenam o estado do registro distribuído (dados do razão) e executam outros serviços do sistema da plataforma. Um nó é apenas uma unidade lógica, nós diferentes podem existir no mesmo servidor físico. Muito mais importante é como os nós são agrupados (domínio confiável) e com quais funções da rede blockchain estão associados.
A arquitetura geral é a seguinte:
Figura 1. Arquitetura geral do Hyperledger Fabric
Aplicativo do usuário (envio de cliente) - um aplicativo com o qual os usuários trabalham com a rede blockchain. Para trabalhar, você deve estar autorizado e ter os direitos apropriados para vários tipos de ações na rede.
Os pares têm vários papéis:
- Endossando Par - um nó que simula a execução de uma transação (executa um código de contrato inteligente). Após verificar e executar o contrato inteligente, o nó retorna os resultados do aplicativo cliente junto com sua assinatura.
- Serviço de pedidos - um serviço distribuído em vários nós, serve para formar novos blocos de um registro distribuído e criar uma sequência de transações. O Ordering Service não adiciona novos blocos ao registro (para melhorar o desempenho, essa função foi transferida para o Committing Peers).
- Confirmando ponto - um nó que contém um registro distribuído e adiciona novos blocos ao registro (que o Serviço de pedidos formou). Todos os pares de confirmação contêm uma cópia local do registro distribuído. O ponto de confirmação, antes de adicionar localmente um novo bloco, verifica a validade de todas as transações dentro do bloco.
Política de Endosso é uma política de validação de transação. Essas políticas determinam o conjunto necessário de nós nos quais um contrato inteligente deve ser executado para que a transação seja reconhecida como válida.
O Distributed Registry - 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 com objetos de registro distribuídos.
WolrldState é um componente de um registro distribuído que armazena os valores atuais (extremos) de todos os objetos em um registro distribuído.
O WorldState é um banco de dados, na versão básica - LevelDB ou mais complexo - CouchDB, que contém pares de valores-chave, por exemplo: Nome - Ivan, Sobrenome - Ivanov, data de registro no sistema - 12/12/21, data de nascimento - 17/12/1961, etc. O WorldState e o registro distribuído devem ser consistentes com todos os membros deste canal.
Como o Hyperledger Fabric é uma rede na qual todos os participantes são conhecidos e autenticados, uma autoridade de certificação dedicada - CA (Autoridade de Certificação) é usada aqui. A CA opera com base no padrão X.509 e na infraestrutura de chave pública - PKI.
Membership Service é um serviço através do qual os participantes verificam a propriedade de um objeto em uma organização ou canal específico.
Uma transação é, na maioria dos casos, um registro de novos dados em um registro distribuído.
Também existem transações para a criação de canais ou contratos inteligentes. A transação é iniciada pelo aplicativo do usuário e termina com um registro no registro distribuído.
Um canal é uma sub-rede fechada que consiste em dois ou mais participantes em uma rede blockchain, projetada para realizar transações confidenciais dentro de um círculo limitado, mas conhecido, de participantes. O canal é definido pelos participantes, seu registro distribuído, contratos inteligentes, Ordering Service, WorldState. Cada membro do canal deve estar autorizado a acessar o canal e ter o direito de realizar vários tipos de transações. A autorização é realizada usando o Serviço de Associação.
Cenário típico de execução de transação
Em seguida, gostaria de falar sobre um cenário típico de execução de transação usando nosso projeto como exemplo.
Como parte de nosso projeto interno, criamos a rede Hyperledger Fabric, projetada para registrar e registrar estudantes que ingressam nas universidades. Nossa rede é composta por duas organizações pertencentes à Universidade A e à Universidade B. Cada organização contém um aplicativo cliente, bem como seu Parceiro Comprometido e Endossado. Também usamos os serviços comuns de Pedidos de Serviços, Serviços de Memebership e Autoridade de Certificação.
1) Iniciação da transação
O aplicativo do usuário, usando o SDK do Hyperledger Fabric, inicia uma solicitação de transação e envia uma solicitação aos nós com contratos inteligentes. A solicitação pode ser para modificação ou leitura de um registro distribuído (Ledger). Se considerarmos um exemplo de nossa configuração de teste de um sistema para estudantes universitários de contabilidade, o aplicativo cliente envia uma solicitação de transação aos nós das universidades A e B, incluídos na política de Endosso do chamado contrato inteligente. O nó A é um nó que está em uma universidade que registra um aluno que está chegando e o nó B é um nó que está em outra universidade. Para que a transação seja armazenada em um registro distribuído, é necessário que todos os nós que, de acordo com a lógica de negócios, devam aprovar a transação, concluam com êxito contratos inteligentes com o mesmo resultado. O nó Um aplicativo de usuário, usando as ferramentas do SDK do Hyperledger Fabric, recebe uma política de Endosso e descobre para quais nós precisamos enviar uma solicitação de transação. Esta é uma solicitação para chamar um contrato inteligente específico (função chaincode) para ler ou gravar certos dados em um registro distribuído. Tecnicamente, o SDK do cliente usa a função correspondente, cuja API passa um objeto com parâmetros de transação e também adiciona a assinatura do cliente e envia esses dados via buffer de protocolo sobre o gRPC aos nós correspondentes (endossando pares).
Figura 2. Iniciação da transação
2) Cumprimento de um contrato inteligente
Os nós (Endossando pares), tendo recebido uma solicitação de transação, verificam a assinatura do cliente e, se tudo estiver em ordem, pegam um objeto com os dados da solicitação e iniciam a simulação da execução do contrato inteligente (função chaincode) com esses dados. Um contrato inteligente é uma lógica comercial de uma transação, um determinado conjunto de condições e instruções (no nosso caso, é a verificação de um aluno, esse é um novo aluno ou ele já está registrado, verificação 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 endosso de pares, dois conjuntos de dados são obtidos - conjunto de leitura e conjunto de gravação. O conjunto de leitura e o conjunto de gravação são os valores novos e originais do WorldState. (novo - no sentido obtido durante a simulação de um contrato inteligente).
Figura 3. Execução de um contrato inteligente
3) Retornando dados para o aplicativo cliente
Após a simulação do contrato inteligente, o Endossando Pares retorna ao aplicativo cliente os dados iniciais e o resultado da simulação, bem como o Conjunto RW, assinado com seu certificado. Nesse estágio, nenhuma alteração é feita no registro distribuído. O aplicativo cliente verifica a assinatura do Par Endossante e também compara os dados de origem da transação que foi enviada e os dados que foram retornados (ou seja, verifica se os dados de origem nos quais a transação foi simulada foram distorcidos). Se a transação era apenas para ler dados do registro, o aplicativo cliente recebe o Conjunto de Leitura necessário e, em geral, conclui a transação com êxito sem alterar o registro distribuído. No caso de uma transação que deveria alterar dados no registro, o aplicativo cliente verifica adicionalmente a implementação da política de Endosso. É possível que o aplicativo cliente não verifique o resultado da Diretiva de Endosso, mas a plataforma Hyperledger Fabric, neste caso, fornece a verificação de diretivas em nós (Comitting Peers) no estágio de adição de uma transação ao registro.
Figura 4. Retornando dados para o aplicativo cliente
4) Enviando conjuntos de RW para pedidos de pares
O aplicativo cliente envia a transação junto com os dados associados ao serviço de pedidos. Isso inclui o conjunto RW, endossando pares e o ID do canal.
Serviço de pedidos - com base no nome, a principal função desse serviço é criar transações de entrada na ordem correta. Assim como a formação de um novo bloco do registro distribuído e a entrega garantida de novos blocos formados 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 (pares comprometidos). 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, portanto, é um cluster de vários nós. O Serviço de pedidos não verifica a validade da transação, simplesmente aceita uma transação com um identificador de canal específico, organiza as transações recebidas em uma determinada ordem e forma a partir deles novos blocos do registro distribuído. Um serviço de pedidos pode servir vários canais simultaneamente. O Serviço de pedidos inclui um cluster Kafka, que suporta a fila de transações correta (inalterada) (consulte a Cláusula 7).
Figura 5. Submetendo conjuntos RW a pedidos de pares
Os blocos formados no Serviço de Pedidos são transmitidos para todos os nós da rede. Cada nó, após receber um novo bloco, verifica sua conformidade com a Política de Endosso, verifica se todos os Pares de Endosso receberam o mesmo resultado (Conjunto de Gravações) como resultado da simulação de um contrato inteligente e também verifica se os valores iniciais foram alterados (isto é - Conjunto de Leitura - dados lidos por um contrato inteligente do WorldState) desde que a transação foi iniciada. Se todas as condições forem atendidas, a transação será marcada como válida; caso contrário, a transação receberá um status inválido.
Figura 6. Enviando blocos formados para Confirmar pares
6) Adicionando um bloco ao registro
Cada nó adiciona uma transação à sua cópia local do registro distribuído e, se a transação for válida, o Conjunto de Gravação é aplicado ao WorldState (estado atual), portanto, novos valores dos objetos que foram afetados pela transação são registrados. Se a transação recebeu um marcador - inválido (por exemplo, duas transações ocorreram com os mesmos objetos no mesmo bloco, uma das transações se mostrará inválida, pois os valores iniciais já foram alterados pela outra transação). Essa transação também é adicionada ao registro distribuído com um token inválido, mas o Conjunto de Gravação dessa transação não se aplica ao estado atual do WorldState e, portanto, não modifica os objetos que participam da transação. Depois disso, é enviada uma notificação ao aplicativo do usuário de que a transação é sempre adicionada ao registro distribuído, bem como o status da transação, ou seja, é válida ou não ...
Figura 7. Adicionando um bloco ao registro
SERVIÇO DE ENCOMENDA
O Ordering Service consiste em um cluster Kafka com os nós ZooKeeper correspondentes e OSN (Ordering Service Nodes), que estão entre os clientes do serviço Ordering e o Kafka Cluster. O Kafka Cluster é uma plataforma de gerenciamento de fluxo (sistema de mensagens) tolerante a falhas e distribuído. Cada canal (tópico) no Kafka é uma sequência imutável de registros que suporta apenas a adição de um novo registro (não é possível excluir um existente). Uma ilustração da estrutura do tópico é fornecida abaixo. É essa propriedade da Kafka que é usada para construir a plataforma blockchain.
extraído de kafka.apache.org
Figura 8. Estrutura do tópico do serviço de pedidos
Links úteis
Youtube - Construindo uma blockchain para negócios com o Projeto Hyperledger
Documentos do Hyperledger Fabric
Malha Hyperledger: um sistema operacional distribuído para blockchains com permissão
Agradecimentos
Expresso minha profunda gratidão pela ajuda na preparação do artigo para meus colegas:
Nikolay Marina
Igor Hapov
Dmitry Gorbachev
Alexander Zemtsov
Ekaterina Kurdenkova
Ekaterina Guseva