Rede Blockchain

Este tópico descreverá, em nível conceitual, como a Hyperledger Fabric permite que as organizações colaborem na formação de redes blockchain. Se você é um arquiteto, administrador ou desenvolvedor, pode usar este tópico para obter um entendimento sólido dos principais componentes da estrutura e dos processos em uma rede de blockchain Hyperledger Fabric. Este tópico usará uma atividade prática de exemplo, que apresenta todos os principais componentes em uma rede blockchain.

Depois de ler este tópico e entender o conceito de políticas, você terá um sólido entendimento das decisões que as organizações precisam tomar para estabelecer as políticas que controlam uma rede implantada na Hyperledger Fabric. Você também entenderá como as organizações gerenciam a evolução da rede usando políticas declarativas – um recurso importante da Hyperledger Fabric. Em poucas palavras, você entenderá os principais componentes técnicos do Hyperledger Fabric e as decisões que as organizações precisam tomar sobre eles.

O que é uma rede blockchain?

Uma rede blockchain é uma infraestrutura técnica que fornece serviços de livro-razão e contrato inteligente (chaincode) para os aplicativos. Inicialmente, os contratos inteligentes são usados para gerar transações que são subsequentemente distribuídas para todos os nós da rede onde são gravados de maneira imutável em sua cópia do livro-razão. Os usuários dos aplicativos podem ser usuários finais ou administradores da rede blockchain.

Na maioria dos casos, várias organizações se reúnem como um consórcio para formar a rede e determinar suas permissões por meio de um conjunto de políticas que são acordadas pelo consórcio quando a rede é configurada. Além disso, as políticas de rede podem mudar com o tempo, dependendo do acordo das organizações no consórcio, como descobriremos quando discutirmos o conceito de política de alteração.

Rede de exemplo

Antes de começarmos, vamos mostrar o que pretendemos fazer! Aqui está um diagrama representando o estado final da nossa rede de exemplo.

Não se preocupe, pois isso pode parecer complicado! À medida que discutimos este tópico, construiremos a rede peça por peça, para que você veja como as organizações R1, R2, R3 e R4 contribuem com infraestrutura para ajudar a rede a se formar. Essa infraestrutura implementa a rede blockchain e é governada por políticas acordadas pelas organizações que formam a rede – por exemplo, quem pode adicionar novas organizações. Você descobrirá como os aplicativos consomem os serviços de livro-razão e contrato inteligente fornecidos pela rede blockchain.

Quatro organizações, R1, R2, R3 e R4, decidiram em conjunto formalizar um contrato onde irão configurar e explorar uma rede Hyperledger Fabric. O R4 foi designado para ser o criador da rede – ele tem a capacidade de configurar a versão inicial da rede. O R4 não tem intenção de realizar transações comerciais na rede. R1 e R2 precisam de uma comunicação privada dentro da rede geral, assim como R2 e R3. A organização R1 possui um aplicativo cliente que pode executar transações comerciais no canal C1. A organização R2 possui um aplicativo cliente que pode executar um trabalho semelhante nos canais C1 e C2. A organização R3 tem um aplicativo cliente que pode fazer isso no canal C2. O nó P1 mantém uma cópia do livro-razão L1 associada a C1. O nó P2 mantém uma cópia do razão L1 associada ao C1 e uma cópia do razão L2 associada ao C2. O nó P3 mantém uma cópia do razão L2 associada a C2. A rede é governada de acordo com as regras da política especificada na configuração de rede NC4, a rede está sob o controle das organizações R1 e R4. O canal C1 é governado de acordo com as regras da política especificada na configuração de canal CC1; o canal está sob o controle das organizações R1 e R2. O canal C2 é governado de acordo com as regras da política especificada na configuração do canal CC2; o canal está sob o controle das organizações R2 e R3. Há um serviço de ordem O4 que atua como um ponto de administração de rede para N e usa o canal do sistema. O serviço de ordem também suporta os canais de aplicativos C1 e C2, para fins de ordem de transações dos blocos para distribuição. Cada uma das quatro organizações possui uma Autoridade de Certificação preferida.

Criando uma Rede

Vamos começar do inicio, criando a base para a rede:

A rede é formada quando um ordenador é iniciado. Em nossa rede de exemplo, N, o serviço de ordens, é um único nó, O4, e é configurado de acordo com uma configuração de rede NC4, que concede direitos administrativos à organização R4. No nível da rede, a Autoridade de Certificação CA4 é usada para distribuir identidades aos administradores e nós de rede da organização R4.

Podemos ver que a primeira coisa que define uma rede, N, é um serviço de ordens, O4. É útil pensar no serviço de ordens como o ponto inicial de administração da rede. Conforme combinado anteriormente, o O4 é inicialmente configurado e iniciado por um administrador na organização R4 e hospedado no R4. A configuração NC4 contém as políticas que descrevem o conjunto inicial de recursos administrativos para a rede. Inicialmente, isso é definido para conceder apenas direitos a R4 na rede. Isso vai mudar, como veremos mais adiante, mas por enquanto R4 é o único membro da rede.

Autoridades de Certificação

Você também pode ver a autoridade de certificação CA4, usada para emitir certificados para administradores e para os nós da rede. O CA4 desempenha um papel fundamental em nossa rede porque distribui certificados X.509 que podem ser usados para identificar componentes como os pertencentes à organização R4. Os certificados emitidos pelas CAs também podem ser usados para assinar transações para indicar que uma organização endossa o resultado da transação – uma condição prévia para que ela seja aceita no livro-razão. Vamos examinar esses dois aspectos de uma autoridade de certificação com mais detalhes.

Em primeiro lugar, diferentes componentes da rede blockchain usam certificados para se identificarem como pertencentes a uma organização específica. É por isso que geralmente há mais de uma CA suportando uma rede blockchain – organizações diferentes costumam usar CAs diferentes. Nós vamos usar quatro CAs em nossa rede, um para cada organização. De fato, as CAs são tão importantes que o Hyperledger Fabric fornece uma integrada (chamada Fabric-CA) para ajudá-lo a avançar, embora, na prática, as organizações escolham usar sua própria CA.

O mapeamento de certificados para organizações membros é realizado por meio de uma estrutura chamada Serviço Provedor de Associação (MSP). A configuração da rede NC4 usa um MSP nomeado para identificar as propriedades dos certificados dispensados pelo CA4 que associam os titulares de certificado à organização R4. O NC4 pode usar esse MSP nas suas políticas para conceder aos atores do R4 direitos específicos sobre os recursos de rede. Um exemplo dessa política é identificar os administradores no R4 que podem adicionar novas organizações membros à rede. Não mostramos MSPs nesses diagramas, pois eles gerariam confusão, mas são muito importantes.

Em segundo lugar, veremos mais adiante como os certificados emitidos pelas CAs estão no centro do processo de geração e validação da transação. Especificamente, os certificados X.509 são usados no aplicativo cliente solicitador da transação e no contrato inteligente da resposta de transação para assinar digitalmente transações. Posteriormente, os nós da rede que hospedam cópias do livro-razão verificam se as assinaturas da transação são válidas antes de aceitar as transações no livro-razão.

Vamos recapitular, a estrutura básica de nossa rede blockchain de exemplo. Há um recurso, a rede N, acessada por um conjunto de usuários definidos por uma autoridade de certificação CA4, que possui um conjunto de direitos sobre os recursos na rede N, conforme descrito pelas políticas contidas em uma configuração de rede NC4. Tudo isso se torna real quando configuramos e iniciamos o nó de serviço de ordens O4.

Adicionando Administradores de Rede

O NC4 foi configurado inicialmente para permitir apenas aos usuários R4 direitos administrativos na rede. Nesta próxima fase, permitiremos que os usuários da organização R1 administrem a rede. Vamos ver como a rede evolui:

A organização R4 atualiza a configuração da rede para tornar a organização R1 um administrador. Após esse ponto, R1 e R4 têm direitos iguais sobre a configuração de rede.

Vemos a adição de uma nova organização R1 como administrador – R1 e R4 agora têm direitos iguais sobre a rede. Também podemos ver que a autoridade de certificação CA1 foi adicionada – ela pode ser usada para identificar os usuários da organização R1. Após esse ponto, os usuários de R1 e R4 podem administrar a rede.

Embora o nó de ordens, O4, esteja sendo executado na infraestrutura do R4, o R1 possui direitos administrativos compartilhados, desde que possa obter acesso à rede. Isso significa que R1 ou R4 pode atualizar a configuração de rede NC4 para permitir à organização R2 um subconjunto de operações de rede. Dessa maneira, mesmo que o R4 esteja executando o serviço de ordens e o R1 possua direitos administrativos completos, o R2 possui direitos limitados para criar novos consórcios.

Na sua forma mais simples, o serviço de ordens é um único nó na rede, e é isso que você pode ver no exemplo. Os serviços de ordens geralmente são com vários nós e podem ser configurados para ter nós diferentes em diferentes organizações. Por exemplo, podemos executar o O4 no R4 e conectá-lo ao O2, um nó de ordem separado na organização R1. Dessa forma, teríamos uma estrutura de administração de vários sites e várias organizações.

Discutiremos o serviço de ordens um pouco mais adiante neste tópico, mas, por enquanto, apenas pense no serviço de ordens como um ponto de administração que fornece acesso controlado à rede a diferentes organizações.

Definindo um Consórcio

Embora a rede agora possa ser administrada por R1 e R4, muito pouco pode ser feito. A primeira coisa que precisamos fazer é definir um consórcio. Essa palavra significa literalmente «um grupo com um destino compartilhado», por isso é uma escolha apropriada para um conjunto de organizações em uma rede blockchain.

Vamos ver como um consórcio é definido:

Um administrador de rede define um consórcio X1 que contém dois membros, as organizações R1 e R2. Essa definição de consórcio é armazenada na configuração de rede NC4 e será usada no próximo estágio de desenvolvimento da rede. CA1 e CA2 são as respectivas autoridades de certificação dessas organizações.

Devido à maneira como o NC4 está configurado, apenas R1 ou R4 podem criar novos consórcios. Este diagrama mostra a adição de um novo consórcio, X1, que define R1 e R2 como suas organizações constituintes. Também podemos ver que o CA2 foi adicionado para identificar usuários do R2. Observe que um consórcio pode ter qualquer número de membros da organização – acabamos de mostrar dois, pois é a configuração mais simples.

Por que os consórcios são importantes? Podemos ver que um consórcio define o conjunto de organizações na rede que compartilham a necessidade de transacionar entre si – nesse caso, R1 e R2. Realmente faz sentido agrupar organizações se elas têm um objetivo comum, e é exatamente isso que está acontecendo.

A rede, embora iniciada por uma única organização, agora é controlada por um conjunto maior de organizações. Poderíamos ter começado dessa maneira, com R1, R2 e R4 tendo controle compartilhado, mas essa estrutura facilita a compreensão.

Agora vamos usar o consórcio X1 para criar uma parte realmente importante de uma blockchain na Hyperledger Fabric – um canal.

Criando um Canal para um Consórcio

Então, vamos criar essa parte essencial da rede blockchain Fabric – um canal. Um canal é o mecanismo de comunicação principal pelo qual os membros de um consórcio podem se comunicar. Pode haver vários canais em uma rede, mas, por enquanto, começaremos com um.

Vamos ver como o primeiro canal foi adicionado à rede:

O canal C1 foi criado para R1 e R2 usando a definição de consórcio X1. O canal é governado por uma configuração de canal CC1, completamente separada da configuração de rede. CC1 é gerenciado por R1 e R2 que têm direitos iguais sobre C1. R4 não tem nenhum direito no CC1.

O canal C1 fornece um mecanismo de comunicação privado para o consórcio X1. Podemos ver que o canal C1 foi conectado ao serviço de ordens O4, mas que nada mais está anexado a ele. No próximo estágio do desenvolvimento da rede, conectaremos componentes como aplicativos clientes e nós de mesmo nível. Mas, neste ponto, um canal representa o potencial para conectividade futura.

Embora o canal C1 faça parte da rede N, ele é bastante distinto dela. Observe também que as organizações R3 e R4 não estão neste canal – é para processamento de transações entre R1 e R2. Na etapa anterior, vimos como o R4 poderia conceder permissão ao R1 para criar novos consórcios. É útil mencionar que o R4 também permitiu ao R1 criar canais! Neste diagrama, poderia ter sido a organização R1 ou R4 que criou um canal C1. Novamente, observe que um canal pode ter qualquer número de organizações conectadas a ele – mostramos dois pois é a configuração mais simples.

Novamente, observe como o canal C1 possui uma configuração completamente separada, CC1, na configuração de rede NC4. O CC1 contém as políticas que governam os direitos que R1 e R2 têm sobre o canal C1 – e, como vimos, R3 e R4 não têm permissões nesse canal. R3 e R4 podem interagir apenas com C1 se forem adicionados por R1 ou R2 à política apropriada na configuração de canal CC1. Um exemplo é definir quem pode adicionar uma nova organização ao canal. Especificamente, observe que R4 não pode se adicionar ao canal C1 – deve e só pode ser autorizado por R1 ou R2.

Por que os canais são tão importantes? Os canais são úteis porque fornecem um mecanismo para comunicações e dados privados entre os membros de um consórcio. Os canais fornecem privacidade em relação a outros canais e da rede. A Hyperledger Fabric é poderosa nesse sentido, pois permite que as organizações compartilhem a infraestrutura e a mantenham privadas ao mesmo tempo. Não há contradição aqui – diferentes consórcios na rede precisarão compartilhar informações e processos diferentes de maneira apropriada, e os canais fornecem um mecanismo eficiente para fazer isso. Os canais fornecem um compartilhamento eficiente da infraestrutura, mantendo a privacidade dos dados e das comunicações.

Também podemos ver que, uma vez que um canal foi criado, ele é, em um sentido muito real, «livre da rede». Somente as organizações especificadas explicitamente em uma configuração de canal têm controle sobre ela, deste momento em diante para o futuro. Da mesma forma, quaisquer atualizações na configuração de rede NC4 a partir de agora não terão efeito direto na configuração de canal CC1, por exemplo, se a definição do consórcio X1 for alterada, ela não afetará os membros do canal C1. Os canais são, portanto, úteis porque permitem comunicações privadas entre as organizações que constituem o canal. Além disso, os dados em um canal são completamente isolados do restante da rede, incluindo outros canais.

Além disso, há também um canal de sistema especial definido para uso pelo serviço de ordens. Ele se comporta exatamente da mesma maneira que um canal comum, às vezes chamado de canais de aplicativos por esse motivo. Normalmente, não precisamos nos preocupar com esse canal, mas discutiremos um pouco mais sobre isso mais adiante neste tópico.

Pares e Livros-Razão

Agora vamos começar a usar o canal para conectar a rede blockchain e os componentes organizacionais. No próximo estágio do desenvolvimento da rede, podemos ver que nossa rede N acaba de adquirir dois novos componentes, a saber, um nó do ponto P1 e uma instância de livro-razão, L1.

Um nó P1 se juntou ao canal C1. P1 hospeda fisicamente uma cópia do livro-razão L1. P1 e O4 podem se comunicar usando o canal C1.

Nós pares são os componentes de rede onde as cópias do livro-razão da blockchain estão hospedadas! Por fim, estamos começando a ver alguns componentes reconhecíveis da blockchain! O objetivo de P1 na rede é puramente hospedar uma cópia do livro-razão L1 para que outros acessem. Podemos pensar em L1 como sendo fisicamente hospedado em P1, mas logicamente hospedado no canal C1. Veremos essa ideia mais claramente quando se adiciona mais pares ao canal.

Uma parte essencial da configuração do P1 é uma identidade X.509 emitida por CA1 que associa P1 à organização R1. Uma vez iniciado o P1, ele pode ingressar no canal C1 usando o ordenador O4. Quando o O4 recebe essa solicitação de associação, ele usa a configuração de canal CC1 para determinar as permissões de P1 nesse canal. Por exemplo, CC1 determina se P1 pode ler e/ou gravar informações no livro-razão L1.

Observe como os pares são unidos aos canais pelas organizações que os possuem e, embora tenhamos adicionado apenas um par, veremos como pode haver vários nós pares em vários canais da rede. Veremos os diferentes papéis que eles podem assumir um pouco mais adiante.

Aplicativos Clientes e código de Contrato Inteligente

Agora que o canal C1 possui um livro-razão, podemos começar a conectar aplicativos clientes para consumir alguns dos serviços fornecidos pelo cavalo de força do livro-razão, o nó par!

Observe como a rede cresceu:

Um contrato inteligente S5 foi instalado no P1. O aplicativo cliente A1 na organização R1 pode usar S5 para acessar o razão via nó P1 do mesmo nível. A1, P1 e O4 estão todos unidos ao canal C1, ou seja, todos podem fazer uso dos recursos de comunicação fornecidos por esse canal.

No próximo estágio de desenvolvimento da rede, podemos ver que o aplicativo cliente A1 pode usar o canal C1 para conectar-se a recursos de rede específicos – nesse caso, A1 pode conectar-se ao nó de ponto P1 e ao nó de ordem O4. Novamente, veja como os canais são centrais para a comunicação entre os componentes de rede e organização. Assim como pares e ordens, um aplicativo cliente terá uma identidade que o associa a uma organização. No nosso exemplo, o aplicativo cliente A1 está associado à organização R1, e, embora esteja fora da rede blockchain Fabric, está conectado a ela através do canal C1.

Agora pode parecer que A1 pode acessar o livro-razão L1 diretamente via P1, mas na verdade, todo o acesso é gerenciado através de um programa especial chamado contrato inteligente (chainconde), S5. Pense no S5 como definidor de todos os padrões de acesso comuns ao livro-razão; S5 fornece um conjunto bem definido de maneiras pelas quais o livro-razão L1 pode ser consultado ou atualizado. Em suma, o aplicativo cliente A1 precisa passar pelo contrato inteligente S5 para acessar o livro-razão L1!

Contratos inteligentes podem ser criados por desenvolvedores de aplicativos de cada organização para implementar um processo de negócios compartilhado pelos membros do consórcio. Contratos inteligentes são usados para ajudar a gerar transações que podem ser posteriormente distribuídas para todos os nós da rede. Discutiremos essa idéia um pouco mais tarde, será mais fácil entender quando a rede for maior. Por enquanto, o importante é entender que, para chegar a esse ponto, duas operações devem ter sido executadas no contrato inteligente; ele deve ter sido instalado nos nós pares e definido em um canal.

Os usuários da Hyperledger Fabric geralmente usam os termos contrato inteligente e código de chamada de forma intercambiável. Em geral, um contrato inteligente define a lógica da transação que controla o ciclo de vida de um objeto de negócios contido no estado global. Em seguida, é empacotado em um chaincode que é implantado em uma rede blockchain. Pense nos contratos inteligentes como transações de controle, enquanto o chaincode governa como os contratos inteligentes são compactados para implantação.

Instalando um Pacote Chaincode

Após o desenvolvimento de um contrato inteligente S5, um administrador da organização R1 deve criar um pacote de código de código e instalar no nó par P1. Esta é uma operação direta. Uma vez concluído, P1 tem pleno conhecimento de S5. Especificamente, P1 pode ver a lógica de implementação de S5 – o código do programa que ele usa para acessar o razão L1. Comparamos isso com a interface de S5, que apenas descreve as entradas e saídas do S5, sem levar em consideração sua implementação.

Quando uma organização possui vários pares em um canal, pode escolher os pares nos quais instala os contratos inteligentes, ele não precisa instalar um contrato inteligente em todos os pares.

Definindo um chaincode

Embora um chaincode seja instalado nos nós pares de uma organização individual, ele é governado e operado no escopo do canal. Cada organização precisa aprovar as definições do chaincode, um conjunto de parâmetros que estabelecem como um o código do chaincode será usado em um canal. A organização deve aprovar uma definição de chaincode para usar o contrato inteligente instalado para consultar o livro-razão e endossar as transações. Em nosso exemplo, que possui apenas um único nó P1, um administrador da organização R1 deve aprovar uma definição de código de código para S5.

Um número suficiente de organizações precisa aprovar uma definição de chaincode (maioria, por padrão) antes que a definição do chaincode possa ser confirmada no canal e usada para interagir com o livro-razão do canal. Como o canal possui apenas um membro, o administrador do R1 pode confirmar a definição do código do chaincode S5 no canal C1. Depois que a definição foi confirmada, o S5 agora pode ser invocado pelo aplicativo cliente A1!

Observe que, embora todos os componentes no canal agora possam acessar o S5, eles não podem ver a lógica do programa. Isso permanece privado para os nós que o instalaram, no nosso exemplo, isso significa P1. Conceitualmente, isso significa que é a interface do contrato inteligente que é definido e aceito em um canal, em contraste com a implementação do contrato inteligente instalado. Para reforçar essa ideia, a instalação de um contrato inteligente mostra como pensamos que ele é fisicamente hospedado em um nó, enquanto um contrato inteligente que foi definido em um canal mostra como o consideramos logicamente hospedado no canal.

Política de endosso

A informação mais importante fornecida na definição do chaincode é a política de endosso. Ele descreve quais organizações devem aprovar transações antes de serem aceitas por outras organizações na sua cópia do livro-razão. Em nossa rede de amostra, as transações só podem ser aceitas no razão L1 se R1 ou R2 as endossarem.

O registro da definição do chaincode no canal, coloca a política de endosso no livro-razão do canal, permitindo que seja acessado por qualquer membro do canal. Você pode ler mais sobre políticas de endosso no tópico do fluxo de transações.

Invocando um Contrato Inteligente

Depois que um contrato inteligente é instalado em um nó par e definido em um canal, ele pode ser invocado por um aplicativo cliente. Os aplicativos clientes fazem isso enviando propostas de transação aos nós das organizações especificadas na política de aprovação de contrato inteligente. A proposta de transação serve como entrada para o contrato inteligente, que a utiliza para gerar uma resposta de transação endossada, que é retornada pelo nó para o aplicativo cliente.

São essas respostas de transações que são empacotadas junto com a proposta de transação para formar uma transação totalmente endossada, que pode ser distribuída para toda a rede. Veremos isso com mais detalhes posteriormente. Por enquanto, basta entender como os aplicativos invocam contratos inteligentes para gerar transações endossadas.

Nesta fase do desenvolvimento da rede, podemos ver que a organização R1 está participando na rede por completo. Suas aplicações – começando com A1 – podem acessar o razão L1 por meio do contrato inteligente S5, para gerar transações que serão endossadas por R1 e, portanto, aceitas no razão porque estão em conformidade com a política de endosso.

Rede concluída

Lembre-se de que nosso objetivo era criar um canal para o consórcio X1 – organizações R1 e R2. Nesta próxima fase do desenvolvimento da rede, a organização R2 adiciona sua infraestrutura à rede.

Vamos ver como a rede evoluiu:

A rede cresceu através da adição de infraestrutura da organização R2. Especificamente, o R2 adicionou o nó par P2, que hospeda uma cópia do livro-razão L1 e o chaincode S5. R2 aprova a mesma definição do chaincode que R1. P2 também se juntou ao canal C1, assim como o aplicativo A2. A2 e P2 são identificados usando certificados de CA2. Tudo isso significa que os aplicativos A1 e A2 podem chamar S5 em C1 usando o nó par P1 ou P2.

Podemos ver que a organização R2 adicionou um nó par P2, no canal C1. P2 também hospeda uma cópia do livro-razão L1 e do contrato inteligente S5. Podemos ver que o R2 também adicionou o aplicativo cliente A2, que pode se conectar à rede via o canal C1. Para conseguir isso, um administrador na organização R2 criou o nó par P2 e o associou ao canal C1, da mesma maneira que o administrador em R1. O administrador também precisa aprovar a mesma definição do chaincode que R1.

Criamos nossa primeira rede operacional! Nesta fase do desenvolvimento da rede, temos um canal no qual as organizações R1 e R2 podem realizar transações completas entre si. Especificamente, isso significa que os aplicativos A1 e A2 podem gerar transações usando o contrato inteligente S5 e o livro-razão L1 no canal C1.

Gerando e aceitando Transações

Ao contrário dos nós pares, que sempre hospedam uma cópia do livro-razão, vemos que existem dois tipos diferentes de nós pares, aqueles que hospedam os contratos inteligentes e aqueles que não. Em nossa rede, todos os pares hospedam uma cópia do contrato inteligente, mas em redes maiores, haverá muito mais nós que não hospedam uma cópia do contrato inteligente. Um par só pode executar um contrato inteligente se estiver instalado nele, mas pode saber sobre a interface de um contrato inteligente ao estar conectado a um canal.

Você não deve pensar em nós pares que não possuem contratos inteligentes instalados como sendo de alguma forma inferiores. É mais o caso dos nós pares com contratos inteligentes terem um poder especial – para ajudar a gerar transações. Observe que todos os nós pares podem validar e subsequentemente aceitar ou rejeitar transações em sua cópia do livro-razão L1. No entanto, apenas nós pares com um contrato inteligente instalado podem participar do processo de aprovação da transação, que é central para a geração de transações válidas.

Não precisamos nos preocupar com os detalhes exatos de como as transações são geradas, distribuídas e aceitas neste tópico – é suficiente entender que temos uma rede blockchain em que as organizações R1 e R2 podem compartilhar informações e processos como transações de captura-de-livro-razão. Aprenderemos muito mais sobre transações, livros-razão, contratos inteligentes em outros tópicos.

Tipos de pares

No Hyperledger Fabric, como todos os pares são iguais, eles podem assumir várias funções, dependendo de como a rede está configurada. Agora temos entendimento suficiente de uma topologia de rede típica para descrever essas funções.

• Pares de Confirmação. Todo nó par em um canal é um ponto de confirmação. Ele recebe blocos de transações geradas, que são posteriormente validadas antes de serem confirmadas na cópia local do livro-razão como uma operação de adição.

• Pares de Endosso. Todo nó com um contrato inteligente pode ser um nó endossante se tiver um contrato inteligente instalado. No entanto, para realmente ser um par endossante, o contrato inteligente no par deve ser usado por um aplicativo cliente para gerar uma resposta de transação assinada digitalmente. O termo endossando pares é uma referência explícita a esse fato.

  Uma política de endosso para um contrato inteligente identifica as organizações cujo parceiro deve assinar digitalmente uma transação gerada antes que ela possa ser aceita na cópia do livro-razão de um parceiro.

Esses são os dois principais tipos de pares, existem outras duas funções que um nó pode adotar:

• Par Líder. Quando uma organização possui vários pares em um canal, é um nó líder que assume a responsabilidade de distribuir transações do ordenador para os outros pares confirmadores da organização. Um nó pode optar por participar da liderança de forma estática ou dinâmica.

  Portanto, é útil pensar em dois conjuntos de pares da perspectiva da liderança – aqueles que têm seleção estática de líderes e aqueles com seleção dinâmica de líderes. Para o conjunto estático, zero ou mais pares podem ser configurados como líderes. Para o conjunto dinâmico, um par será eleito líder pelo conjunto. Além disso, no conjunto dinâmico, se um colega líder falhar, os colegas restantes reelegerão um líder.

  Isso significa que os pares de uma organização podem ter um ou mais líderes conectados ao serviço de ordens. Isso pode ajudar a melhorar a resiliência e a escalabilidade em grandes redes que processam grandes volumes de transações.

• Nó Âncora. Se um ponto precisar se comunicar com um ponto em outra organização, ele poderá usar um dos nós âncora definidos na configuração do canal para essa organização. Uma organização pode ter zero ou mais pares âncoras definidos para ela e um par âncora pode ajudar com muitos cenários diferentes de comunicação entre organizações.

Observe que um par pode ser um par de confirmação, par de endosso, um par líder e um par âncora ao mesmo tempo! Somente o ponto de ancoragem é opcional – para todos os fins práticos, sempre haverá um líder e pelo menos um endossante e pelo menos um confirmador.

Adicionando organizações e pares ao canal

Quando R2 ingressa no canal, a organização deve instalar o contrato inteligente S5 em seu nó par, P2. Isso é óbvio – se os aplicativos A1 ou A2 desejam usar S5 no nó par P2 para gerar transações, ele deve estar presente primeiro. Instalação é o mecanismo pelo qual isso acontece. Nesse ponto, o nó P2 possui uma cópia física do contrato inteligente e do livro-razão, como P1 e ele pode gerar e aceitar transações em sua cópia do livro-razão L1.

O R2 deve aprovar a mesma definição de chaincode aprovada pelo R1 para usar o contrato inteligente S5. Como a definição de chaincode já foi confirmada no canal pela organização R1, o R2 pode usá-lo assim que a organização aprovar a definição do chaincode e instalar o pacote. A transação de confirmação precisa acontecer apenas uma vez. Uma nova organização pode usar o chaincode assim que aprovar os parâmetros do código acordado por outros membros do canal. Como a aprovação de um chaincode ocorre no nível da organização, o R2 pode aprovar a definição de código uma vez e unir vários pares ao canal com o chaincode instalado. No entanto, se o R2 quisesse alterar a definição do código, R1 e R2 precisariam aprovar uma nova definição para sua organização e, em seguida, uma das organizações precisaria confirmar a definição no canal.

Em nossa rede, podemos ver que o canal C1 conecta dois aplicativos clientes, dois nós pares e um serviço de ordens. Como existe apenas um canal, existe apenas um registro lógico com o qual esses componentes interagem. Os nós pares P1 e P2 têm cópias idênticas do livro-razão L1. As cópias do contrato inteligente S5 geralmente serão implementadas de forma idêntica usando a mesma linguagem de programação, caso não sejam, devem ser semanticamente equivalentes.

Podemos ver que a adição cuidadosa de pares à rede pode ajudar a aumentar o rendimento, a estabilidade e a resiliência. Por exemplo, mais pares em uma rede permitirão que mais aplicativos se conectem a ela, e vários pares em uma organização fornecerão resiliência extra no caso de interrupções planejadas ou não planejadas.

Tudo isso significa que é possível configurar topologias sofisticadas que suportam uma variedade de objetivos operacionais – não há limite teórico para o tamanho da rede. Além disso, o mecanismo técnico pelo qual os pares das
organizações se descobrem e se comunicam com eficiência – o protocolo gossip – acomodará um grande número de nós pares nessa topologias.

O uso cuidadoso das políticas de rede e canal permite que até redes grandes sejam bem governadas. As organizações são livres para adicionar nós pares à rede, desde que estejam em conformidade com as políticas acordadas pela rede. As políticas de rede e canal criam o equilíbrio entre autonomia e controle, que caracteriza uma rede descentralizada.

Simplificando o vocabulário visual

Agora, vamos simplificar o vocabulário visual usado para representar nossa rede blockchain de exemplo. À medida que o tamanho da rede aumenta, as linhas inicialmente usadas para nos ajudar a entender os canais se tornarão complicadas. Imagine o quão complicado seria o nosso diagrama se adicionássemos ao par outro aplicativo, ou cliente, ou outro canal?

É isso que vamos fazer em um minuto. Antes de fazer, vamos simplificar o vocabulário visual. Aqui está uma representação simplificada da rede que desenvolvemos até agora:

O diagrama mostra os fatos relacionados ao canal C1 na rede N da seguinte maneira: Os aplicativos clientes A1 e A2 podem usar o canal C1 para comunicação com os pares P1 e P2 e o ordem O4. Os nós de pares P1 e P2 podem usar os serviços de comunicação do canal C1. O serviço de ordens O4 pode fazer uso dos serviços de comunicação do canal C1. A configuração do canal CC1 se aplica ao canal C1.

Observe que o diagrama da rede foi simplificado substituindo as linhas de canal por pontos de conexão, mostrados como círculos azuis que incluem o número do canal. Nenhuma informação foi perdida. Essa representação é mais escalável porque elimina linhas de cruzamento. Isso nos permite representar mais claramente redes maiores. Conseguimos essa simplificação focando nos pontos de conexão entre componentes e um canal, e não no próprio canal.

Adicionando outra definição de consórcio

Nesta próxima fase do desenvolvimento da rede, apresentamos a organização R3. Vamos dar às organizações R2 e R3 um canal de aplicativo separado, que permite que elas realizem transações entre si. Esse canal de aplicativo será completamente separado do definido anteriormente, para que as transações R2 e R3 possam ser mantidas privadas entre eles.

Vamos voltar ao nível da rede e definir um novo consórcio, X2, para R2 e R3:

Um administrador de rede da organização R1 ou R4 adicionou uma nova definição de consórcio, X2, que inclui as organizações R2 e R3. Isso será usado para definir um novo canal para o X2.

Observe que a rede agora tem dois consórcios definidos: X1 para organizações R1 e R2 e X2 para organizações R2 e R3. O Consortium X2 foi introduzido para poder criar um novo canal para R2 e R3.

Um novo canal só pode ser criado pelas organizações especificamente identificadas na política de configuração de rede, NC4, como possuindo os direitos apropriados para fazê-lo, ou seja, R1 ou R4. Este é um exemplo de política que separa as organizações que podem gerenciar recursos no nível da rede e aquelas que podem gerenciar recursos no nível do canal. Ver essas políticas em ação nos ajuda a entender por que a Hyperledger Fabric possui uma sofisticada estrutura em camadas de políticas.

Na prática, a definição de consórcio X2 foi adicionada à configuração de rede NC4. Discutimos a mecânica exata dessa operação em outras partes da documentação.

Adicionando um novo canal

Agora vamos usar essa nova definição de consórcio, X2, para criar um novo canal, C2. Para ajudar a reforçar sua compreensão da notação de canal mais simples, usamos os dois estilos visuais – o canal C1 é representado com pontos finais circulares azuis, enquanto o canal C2 é representado com linhas de conexão vermelhas:

Um novo canal C2 foi criado para R2 e R3 usando a definição de consórcio X2. O canal possui uma configuração de canal CC2, completamente separada da configuração de rede NC4 e a configuração de canal CC1. O canal C2 é gerenciado por R2 e R3 que têm direitos iguais sobre C2, conforme definido por uma política no CC2. R1 e R4 não têm direitos definidos no CC2.

O canal C2 fornece um mecanismo de comunicação privado para o consórcio X2. Mais uma vez, observe como as organizações unidas em um consórcio são as que formam os canais. A configuração do canal CC2 agora contém as políticas que governam os recursos do canal, atribuindo direitos de gerenciamento às organizações R2 e R3 pelo canal C2. É gerenciado exclusivamente por R2 e R3, R1 e R4 não têm poder no canal C2. Por exemplo, a configuração do canal CC2 pode ser atualizada posteriormente para adicionar organizações para apoiar o crescimento da rede, mas isso só pode ser feito pelo R2 ou pelo R3.

Observe como as configurações de canal CC1 e CC2 permanecem completamente separadas uma da outra e completamente separadas da configuração de rede, NC4. Mais uma vez, estamos vendo a natureza descentralizada de uma rede Hyperledger Fabric, depois que o canal C2 é criado, ele é gerenciado pelas organizações R2 e R3 independentemente de outros elementos da rede. As políticas de canal sempre permanecem separadas umas das outras e só podem ser alteradas pelas organizações autorizadas a fazê-lo no canal.

À medida que a rede e os canais evoluem, o mesmo ocorre com as configurações de rede e canal. Há um processo pelo qual isso é realizado de maneira controlada – envolvendo transações de configuração que capturam a alteração nessas configurações. Toda mudança de configuração resulta em uma nova transação no bloco de configuração sendo gerada, e logo mais nesse tópico veremos como esses blocos são validados e aceitos para criar configurações atualizadas de rede e canal, respectivamente.

Configurações de rede e canal

Em toda a nossa rede de exemplo, vemos a importância das configurações de rede e canal. Essas configurações são importantes porque encapsulam as políticas acordadas pelos membros da rede, que fornecem uma referência compartilhada para controlar o acesso aos recursos da rede. As configurações de rede e canal também contêm fatos sobre a composição da rede e do canal, como o nome dos consórcios e suas organizações.

Por exemplo, quando a rede é formada pela primeira vez usando o nó de serviço de ordem O4, seu comportamento é governado pela configuração de rede NC4. A configuração inicial do NC4 contém apenas políticas que permitem à organização R4 gerenciar recursos de rede. O NC4 é atualizado posteriormente para permitir também que o R1 gerencie os recursos da rede. Depois que essa alteração é feita, qualquer administrador da organização R1 ou R4 que se conecta ao O4 terá direitos de gerenciamento de rede, pois é isso que a política na configuração de rede NC4 permite. Internamente, cada nó no serviço de ordens registra cada canal na configuração de rede, para que haja um registro de cada canal criado, no nível da rede.

Isso significa que, embora o pedido do nó de ordem O4 seja o ator que criou os consórcios X1 e X2 e os canais C1 e C2, a inteligência da rede está contida na configuração de rede NC4 que O4 está obedecendo. Desde que o O4 se comporte como um bom ator e implemente corretamente as políticas definidas no NC4 sempre que estiver lidando com recursos de rede, nossa rede se comportará como todas as organizações concordaram. De muitas maneiras, o NC4 pode ser considerado mais importante que o O4 porque, em última análise, controla o acesso à rede.

Os mesmos princípios se aplicam às configurações de canal em relação aos pares. Em nossa rede, P1 e P2 são igualmente bons atores. Quando os nós de pares P1 e P2 estão interagindo com os aplicativos clientes A1 ou A2, cada um deles usa as políticas definidas na configuração de canal CC1 para controlar o acesso aos recursos do canal C1.

Por exemplo, se A1 quiser acessar o chaincode do contrato inteligente S5 nos nós pares P1 ou P2, cada nó usará sua cópia do CC1 para determinar as operações que A1 pode executar. Por exemplo, A1 pode ter permissão para ler ou gravar dados do livro-razão L1 de acordo com as políticas definidas em CC1. Veremos mais adiante o mesmo padrão para os atores no canal e sua configuração de canal CC2. Novamente, podemos ver que, embora os pares e aplicativos sejam atores críticos na rede, seu comportamento em um canal é ditado mais pela política de configuração do canal do que por qualquer outro fator.

Por fim, é útil entender como as configurações de rede e canal são fisicamente realizadas. Podemos ver que as configurações de rede e canal são logicamente singulares – há uma para a rede e uma para cada canal. Isso é importante, todo componente que acessa a rede ou o canal deve ter um entendimento compartilhado das permissões concedidas as diferentes organizações.

Embora exista logicamente uma única configuração, ela é replicada e mantida consistente por todos os nós que formam a rede ou canal. Por exemplo, em nossa rede os nós pares P1 e P2 têm uma cópia da configuração do canal CC1 e, quando a rede estiver totalmente concluída, os nós pares P2 e P3 terão uma cópia da configuração do canal CC2. Da mesma forma, o nó de serviço de ordem O4 possui uma cópia da configuração de rede, mas em uma configuração de vários nós, cada nó de serviço de ordem terá sua própria cópia da configuração de rede.

As configurações de rede e canal são mantidas consistentes usando a mesma tecnologia blockchain usada para transações do usuário – mas para transações de configuração. Para alterar uma configuração de rede ou canal, um administrador deve enviar uma transação de configuração para alterar a configuração de rede ou canal. Ele deve ser assinado pelas organizações identificadas na política apropriada como responsáveis ​​pela alteração da configuração. Essa política é chamada de mod_policy e discutiremos mais tarde.

De fato, os nós do serviço de ordens operam um mini-blockchain, conectado via canal do sistema que mencionamos anteriormente. Usando o canal do sistema, os nós do serviço de ordens distribuem as transações de configuração de rede. Essas transações são usadas para manter cooperativamente uma cópia consistente da configuração de rede em cada nó do serviço de ordens. De maneira semelhante, os nós pares nível em um canal de aplicativo podem distribuir transações de configuração de canal. Da mesma forma, essas transações são usadas para manter uma cópia consistente da configuração do canal em cada nó do mesmo nível.

Esse equilíbrio entre objetos logicamente singulares, por serem fisicamente distribuídos, é um padrão comum no Hyperledger Fabric. Objetos como configurações de rede, logicamente únicos, acabam sendo replicados fisicamente entre um conjunto de nós de serviços de ordens, por exemplo. Também o vemos com configurações de canais, livros-razão e, até certo ponto, contratos inteligentes que são instalados em vários locais, mas cujas interfaces existem logicamente no nível do canal. É um padrão que você vê repetidas vezes no Hyperledger Fabric e permite que o Hyperledger Fabric seja descentralizado e, ao mesmo tempo, gerenciável.

Adicionando outro nó par

Agora que a organização R3 pode participar totalmente do canal C2, vamos adicionar seus componentes de infraestrutura ao canal. Ao invés de fazer isso um componente por vez, adicionaremos um nó par, sua cópia local de um livro-razão, um contrato inteligente e um aplicativo cliente de uma só vez!

Vamos ver a rede com os componentes da organização R3 adicionados:

O diagrama mostra os fatos relacionados aos canais C1 e C2 na rede N da seguinte maneira: Os aplicativos clientes A1 e A2 podem usar o canal C1 para comunicação com os pares P1 e P2 e solicitar o serviço O4; o aplicativo cliente A3 pode usar o canal C2 para comunicação com o ponto P3 e o serviço de ordens O4. O serviço de ordens O4 pode fazer uso dos serviços de comunicação dos canais C1 e C2. A configuração do canal CC1 se aplica ao canal C1, CC2 se aplica ao canal C2.

Antes de tudo, observe que, como o nó P3 está conectado ao canal C2, ele possui um livro-razão diferente – L2 – para os nós pares usando o canal C1. O razão L2 é efetivamente definido no canal C2. O livro-razão L1 é completamente separado, está no escopo do canal C1. Isso faz sentido – o objetivo do canal C2 é fornecer comunicações privadas entre os membros do consórcio X2, e o livro-razão L2 é o armazenamento privado para suas transações.

De maneira semelhante, o contrato inteligente S6, instalado no nó par P3 e definido no canal C2, é usado para fornecer acesso controlado ao livro-razão L2. O aplicativo A3 agora pode usar o canal C2 para chamar os serviços fornecidos pelo contrato inteligente S6 para gerar transações que podem ser aceitas em todas as cópias do livro-razão L2 na rede.

Neste momento, temos uma única rede que possui dois canais completamente separados definidos dentro dela. Esses canais fornecem recursos gerenciados de forma independente para as organizações negociarem entre si. Novamente, isso é descentralização no trabalho, nós têm um equilíbrio entre controle e autonomia. Isso é alcançado por meio de políticas aplicadas a canais controlados e afetando diferentes organizações.

Juntando um par a vários canais

Nesta fase final do desenvolvimento da rede, vamos voltar nosso foco para a organização R2. Podemos explorar o fato de o R2 ser um membro dos consórcios X1 e X2 juntando-o a vários canais:

O diagrama mostra os fatos relacionados aos canais C1 e C2 na rede N da seguinte maneira: O aplicativo cliente A1 pode usar o canal C1 para comunicação com os pares P1 e P2 e solicitar o serviço O4; o aplicativo cliente A2 pode usar o canal C1 para comunicação com os pares P1 e P2 e o canal C2 para comunicação com os pares P2 e P3 e solicitar o serviço O4; o aplicativo cliente A3 pode usar o canal C2 para comunicação com os pares P3 e P2 e solicitar o serviço O4. O serviço de ordens O4 pode fazer uso dos serviços de comunicação dos canais C1 e C2. A configuração do canal CC1 se aplica ao canal C1, CC2 se aplica ao canal C2.

Podemos ver que o R2 é uma organização especial na rede, porque é a única organização que é membro de dois canais de aplicativos! É capaz de negociar com a organização R1 no canal C1, enquanto, ao mesmo tempo, também pode negociar com a organização R3 em um canal diferente, C2.

Observe como o nó P2 possui o contrato inteligente S5 instalado para o canal C1 e o contrato inteligente S6 instalado para o canal C2. O nó P2 é um membro de ambos os canais ao mesmo tempo, por meio de contratos inteligentes diferentes para diferentes livros-razão.

Este é um conceito muito poderoso – os canais fornecem um mecanismo para a separação de organizações e um mecanismo para colaboração entre organizações. Enquanto isso, essa infraestrutura é fornecida e compartilhada entre um conjunto de organizações independentes.

Também é importante observar que o comportamento do nó P2 é controlado de maneira muito diferente, dependendo do canal no qual ele está transacionando. Especificamente, as políticas contidas na configuração de canal CC1 ditam as operações disponíveis para P2 quando transacionando no canal C1, enquanto as políticas na configuração de canal CC2 controlam o comportamento de P2 no canal C2.

Novamente, isso é desejável – R2 e R1 concordaram com as regras do canal C1, enquanto R2 e R3 concordaram com as regras do canal C2. Essas regras foram capturadas nas respectivas políticas de canal – elas podem e devem ser usadas por todos os componentes de um canal para impor o comportamento correto, conforme acordado.

Da mesma forma, podemos ver que o aplicativo cliente A2 agora pode fazer transações nos canais C1 e C2. Da mesma forma, ele também será regido pelas políticas nas configurações de canal apropriadas. Como um aparte, observe que o aplicativo cliente A2 e o nó P2 estão usando um vocabulário visual misto – linhas e conexões. Você pode ver que eles são equivalentes, eles são sinônimos visuais.

O serviço de ordem

O leitor atento pode perceber que o nó do serviço de ordens parece ser um componente centralizado, foi usado para criar a rede inicialmente e se conecta a todos os canais da rede. Embora tenhamos adicionado R1 e R4 à política de configuração de rede NC4 que controla o ordenador, o nó estava sendo executado na infraestrutura do R4. Em um mundo de descentralização, isso parece errado!

Não se preocupe! Nosso exemplo de rede mostrou a configuração mais simples do serviço de ordens para ajudá-lo a entender a ideia de um ponto de administração de rede. De fato, o serviço de ordens também pode ser completamente descentralizado! Mencionamos anteriormente que um serviço de ordens pode ser composto por muitos nós pertencentes a diferentes organizações, então vamos ver como isso seria feito em nossa rede de exemplo.

Vamos dar uma olhada em uma configuração de nós de serviços de ordens mais realista:

Um serviço de ordem de múltiplas organizações. O serviço de ordens compreende os nós de serviço O1 e O4. O1 é fornecido pela organização R1 e o nó O4 é fornecido pela organização R4. A configuração de rede NC4 define permissões de recursos de rede para os atores de ambas as organizações R1 e R4.

Podemos ver que esse serviço de ordens é totalmente descentralizado – é executado na organização R1 e na organização R4. A política de configuração de rede, NC4, permite direitos iguais R1 e R4 sobre os recursos da rede. Aplicativos cliente e nós de mesmo nível das organizações R1 e R4 podem gerenciar recursos de rede conectando-se ao nó O1 ou O4, porque ambos os nós se comportam da mesma maneira, conforme definido pelas políticas na configuração de rede C4. Na prática, os atores de uma organização específica tendem a usar a infraestrutura fornecida por sua organização de origem, mas esse nem sempre é o caso.

Distribuição de transação descentralizada

Além de ser o ponto de gerenciamento da rede, o serviço de ordens também oferece outro recurso importante – é o ponto de distribuição das transações. O serviço de ordens é o componente que reúne transações endossadas de aplicativos e as ordena em blocos de transações, que são subsequentemente distribuídos para todos os nós do canal. Em cada um desses nós confirmados, as transações são registradas, válidas ou inválidas, e sua cópia local do livro-razão é atualizada adequadamente.

Observe como o nó de serviço de ordens O4 desempenha uma função muito diferente para o canal C1 do que para a rede N. Ao atuar no nível do canal, a função de O4 é coletar transações e distribuir blocos dentro do canal C1. Isso é feito de acordo com as políticas definidas na configuração de canal CC1. Por outro lado, ao atuar no nível da rede, a função da O4 é fornecer um ponto de gerenciamento para os recursos da rede, de acordo com as políticas definidas na configuração de rede NC4. Observe novamente como essas funções são definidas por políticas diferentes nas configurações de canal e rede, respectivamente. Isso deve reforçar a importância da configuração de política declarativa da Hyperledger Fabric. As políticas definem e são usadas para controlar os comportamentos acordados por cada membro de um consórcio.

Podemos ver que o serviço de ordens, como os outros componentes da Hyperledger Fabric, é um componente totalmente descentralizado. Seja atuando como um ponto de gerenciamento de rede ou como um distribuidor de blocos em um canal, seus nós podem ser distribuídos conforme necessário pelas várias organizações em uma rede.

Mudança de política

Ao longo de nossa exploração da rede de exemplo, vimos a importância das políticas para controlar o comportamento dos atores no sistema. Discutimos apenas algumas das políticas disponíveis, mas há muitas que podem ser definidas declarativamente para controlar todos os aspectos do comportamento. Essas políticas individuais são discutidas em outras partes da documentação.

Mais importante ainda, o Hyperledger Fabric fornece uma política exclusivamente poderosa que permite que os administradores de rede e canal gerenciem a própria alteração de política! A filosofia subjacente é que a mudança de política é uma constante, se ela ocorre dentro ou entre organizações ou se é imposta por reguladores externos. Por exemplo, novas organizações podem ingressar em um canal ou organizações existentes e podem ter suas permissões aumentadas ou diminuídas. Vamos investigar um pouco mais como a política de mudança é implementada no Hyperledger Fabric.

O ponto principal do entendimento é que a mudança de política é gerenciada por uma política dentro da própria política. A política de modificação, ou mod_policy, é uma política de primeira classe em uma configuração de rede ou canal que gerencia alterações. Vamos dar dois breves exemplos de como já usamos o mod_policy para gerenciar alterações em nossa rede!

O primeiro exemplo foi quando a rede foi configurada inicialmente. No momento, apenas a organização R4 tinha permissão para gerenciar a rede. Na prática, isso foi conseguido tornando R4 a única organização definida na configuração de rede NC4 com permissões para recursos de rede. Além disso, o mod_policy para NC4 mencionou apenas a organização R4 – somente R4 foi autorizado a alterar essa configuração.

Em seguida, desenvolvemos a rede N para também permitir que a organização R1 administre. O R4 fez isso adicionando R1 às políticas para criação de canal e criação de consórcio. Devido a essa alteração, R1 conseguiu definir os consórcios X1 e X2 e criar os canais C1 e C2. R1 tinha direitos administrativos iguais sobre as políticas de canal e consórcio na configuração de rede.

R4, no entanto, poderia conceder ainda mais poder sobre a configuração de rede ao R1! O R4 poderia adicionar R1 ao mod_policy, para que o R1 também pudesse gerenciar a alteração da política de rede.

Este segundo poder é muito mais poderoso que o primeiro, porque o R1 agora possui controle total sobre a configuração de rede NC4! Isso significa que o R1 pode, em princípio, remover os direitos de gerenciamento do R4 da rede. Na prática, o R4 configuraria o mod_policy de forma que o R4 também precisasse aprovar a alteração ou que todas as organizações no mod_policy precisassem aprová-la. Há muita flexibilidade para tornar o mod_policy tão sofisticado quanto necessário para suportar qualquer processo de mudança necessário.

Esse é o mod_policy no trabalho – permitiu a evolução graciosa de uma configuração básica para uma sofisticada. O tempo todo isso ocorreu com o acordo de toda organização envolvida. O mod_policy se comporta como todas as outras políticas dentro de uma configuração de rede ou canal, define um conjunto de organizações que têm permissão para alterar o próprio mod_policy.

Nós apenas arranhamos a superfície do poder das políticas e do mod_policy em particular nesta subseção. Isso é discutido muito mais detalhadamente no tópico da política, mas por enquanto vamos voltar à nossa rede concluída!

Rede totalmente formada

Vamos recapitular a aparência da nossa rede usando um vocabulário visual consistente. Reorganizamos um pouco usando nossa sintaxe visual mais compacta, pois ela acomoda melhor topologias maiores:

Neste diagrama, vemos que a rede blockchain da Fabric consiste em dois canais de aplicativos e um canal de pedidos. As organizações R1 e R4 são responsáveis pelo canal de pedidos, R1 e R2 são responsáveis pelo canal de aplicativos azul, enquanto R2 e R3 são responsáveis pelo canal de aplicativos vermelho. Os aplicativos clientes A1 são um elemento da organização R1 e CA1 é sua autoridade de certificação. Observe que o ponto P2 da organização R2 pode usar os recursos de comunicação do canal de aplicativo azul e vermelho. Cada canal de aplicativo possui sua própria configuração de canal, neste caso, CC1 e CC2. A configuração do canal do sistema faz parte da configuração de rede, NC4.

Estamos no final de nossa jornada conceitual para construir uma rede blockchain Hyperledger Fabric de exemplo. Criamos uma rede de quatro organizações com dois canais e três nós pares, com dois contratos inteligentes e um serviço de ordens. É suportado por quatro autoridades de certificação. Ele fornece serviços de contrato inteligente e de livro-razão para três aplicativos clientes, que podem interagir com ele pelos dois canais. Reserve um momento para examinar os detalhes da rede no diagrama e sinta-se à vontade para ler novamente o tópico para reforçar seu conhecimento ou vá para um tópico mais detalhado.

Resumo dos componentes de rede

Aqui está um rápido resumo dos componentes de rede que discutimos:

• Livro-Razão. Um por canal. Composto pelo Blockchain e pelo Estado Global
• Contrato Inteligente (ou chaincode)
• Nós Pares
• Serviço de Ordens
• Canal
• Autoridade de Certificação

Resumo da rede

Neste tópico, vimos como diferentes organizações compartilham sua infraestrutura para fornecer uma rede blockchain integrada Hyperledger Fabric. Vimos como a infraestrutura coletiva pode ser organizada em canais que fornecem mecanismos de comunicação privados gerenciados de forma independente. Vimos os atores como, aplicativos clientes, administradores, pares e ordens são identificados como de diferentes organizações pelo uso de certificados de suas respectivas autoridades de certificação. E, por sua vez, vimos a importância da política para definir as permissões acordadas que esses atores organizacionais têm sobre os recursos de rede e canal.