Configurando uma rede Hyperledger Fabric com vários clusters: um guia completo

A tecnologia blockchain virou um divisor de águas em muitos setores, oferecendo recursos descentralizados e imutáveis de manutenção de registos que resolvem problemas antigos na área de integridade e confiança dos dados.

Entre as muitas estruturas de blockchain disponíveis, o Hyperledger Fabric surgiu como uma das principais implementações de blockchain autorizadas, especialmente apreciada pela sua modularidade, flexibilidade e preparação para empresas.

Este guia detalhado aprofunda-se no complexo processo de criação de uma configuração multicluster do Hyperledger Fabric, construindo uma rede Hyperledger Fabric multicluster e multiorganização.

Ao distribuir os componentes da rede entre diferentes clusters e organizações, isso proporciona melhor tolerância a falhas, capacidades de escalabilidade e autonomia organizacional.

Cada etapa foi cuidadosamente detalhada para fornecer profundidade técnica e insights práticos para a implementação.

Antes de começar a implementação, é essencial entender os fundamentos arquitetónicos apresentados neste guia de arquitetura do Hyperledger Fabric.

O design multi-cluster é um design sofisticado para implantação de rede blockchain que combina colaboração com independência organizacional.

Neste modelo arquitetónico, lidamos com duas organizações diferentes, cada uma com a sua própria Autoridade Certificadora, responsável por gerir identidades criptográficas e garantir uma autenticação segura.

Essas organizações funcionam de forma independente, com os seus recursos a correr em diferentes clusters Kubernetes Hyperledger Fabric.

Essa separação oferece vantagens importantes, como tolerância a falhas, isolamento de recursos e o facto de que cada organização pode manter o controlo sobre a sua infraestrutura.

A configuração do cluster é feita de forma que cada organização hospede o seu próprio grupo de pares e Autoridade Certificadora nos seus próprios ambientes dedicados.

Essa escolha de design garante que não haja disputa por recursos e também permite que as organizações dimensionem a sua infraestrutura com base nas suas necessidades específicas, sem afetar outros participantes da rede.

O serviço de encomendas, que funciona como mecanismo de consenso para a rede, está estrategicamente distribuído por uma organização diferente.

Ao colocar dois ordenadores em clusters separados, a arquitetura tem redundância e alta disponibilidade.

Se um solicitante tiver problemas, a rede continua a funcionar através do outro solicitante, para que nunca pare de funcionar.

A implementação usa ferramentas cuidadosamente selecionadas que facilitam a implantação de sistemas complexos e adicionam recursos de gestão robustos.

O EKS simplifica a implementação, gestão e dimensionamento de clusters Kubernetes na infraestrutura da Amazon Web Services, fornecendo uma plataforma confiável e comprovada para hospedar componentes de rede Fabric.

A natureza gerenciada do EKS significa que ele reduz a sobrecarga associada à operação do sistema, ao mesmo tempo em que oferece confiabilidade de nível empresarial.

Hlf-Operator representa um operador Kubernetes especializado, projetado especificamente para gerenciar a implantação da rede Hyperledger Fabric e as operações contínuas das redes Hyperledger Fabric.

Este operador abstrai muitas das tarefas complexas de implementação e gestão associadas às redes Fabric e oferece um conjunto de opções de configuração declarativas que facilitam muito a administração da rede e reduzem o potencial de erros de configuração.

Com a compreensão da arquitetura e das ferramentas identificadas, o processo de implementação segue uma sequência estruturada de etapas que se complementam para criar uma rede totalmente funcional.

Passo 1: Configurar o cluster EKS

A primeira fase da implementação envolve a criação dos clusters Kubernetes onde os componentes da rede Fabric residirão.

Esta etapa fundamental envolve um planeamento cuidadoso para garantir que os clusters sejam configurados adequadamente para cargas de trabalho de blockchain.

A configuração do cluster começa com a definição dos parâmetros que vão controlar o comportamento e a capacidade do cluster.

Esses parâmetros incluem:

• •Tipos de instância escolhidos com base nas características esperadas da carga de trabalho
• •Número de instâncias necessárias para lidar com os volumes de transações esperados
• •Zonas de disponibilidade escolhidas para maximizar a resiliência e minimizar a latência

Usando o eksctl, uma ferramenta de linha de comando especial que foi projetada para o gerenciamento de clusters EKS, os clusters são criados de acordo com as especificações definidas.

Essa ferramenta automatiza grande parte da complexidade associada ao provisionamento de clusters, garantindo que as melhores práticas sejam seguidas.

Após a criação dos clusters, são gerados ficheiros kubeconfig para permitir o acesso seguro aos clusters recém-criados.

Esses ficheiros de configuração incluem as credenciais de autenticação e as informações de conexão necessárias para as próximas etapas da implementação.

Passo 2: Instalar o Hlf-Operator e o Istio

Com os clusters em funcionamento, a próxima etapa é a instalação das ferramentas de gestão que serão usadas para facilitar a implementação dos componentes do Fabric e a comunicação entre serviços.

A instalação do Hlf-Operator começa com a adição do repositório Helm que contém os gráficos do operador.

Assim que o repositório estiver disponível, o operador é instalado em ambos os clusters, fornecendo as definições de recursos personalizados e controladores necessários para a gestão dos componentes Fabric.

Segue-se a instalação do Istio, trazendo os recursos da malha de serviços para os clusters.

O Istio permite algumas capacidades avançadas de gestão de tráfego, equilíbrio de carga e observabilidade que são bastante úteis em redes blockchain distribuídas, onde é muito importante ter uma comunicação fiável entre os componentes.

A configuração do Sistema de Nomes de Domínio define a estrutura de nomenclatura que permite uma comunicação fácil entre os componentes de rede distribuídos por diferentes clusters.

A configuração do DNS requer a criação de uma zona hospedada no AWS Route 53 para que o domínio seja associado à rede Fabric.

Dentro desta zona hospedada, são configurados registos individuais para cada componente do serviço que mapeia os nomes de domínio legíveis por humanos para o ponto final do cluster.

Para cada par, autoridade certificadora e solicitante, é definido um registo CNAME que aponta para o URL externo do cluster apropriado.

Essa configuração permite que os componentes de um cluster encontrem e se comuniquem com componentes de outros clusters usando nomes de domínio consistentes e previsíveis.

Estrutura dos registos DNS:

• •Para a primeira organização, são criados registos para a Autoridade Certificadora e pares
• •A segunda organização precisa ter o seu próprio conjunto de registos
• •A organização solicitante precisa de registos para a sua Autoridade Certificadora e vários solicitantes que apontam para os respetivos pontos finais do cluster

Com a infraestrutura e a rede em funcionamento, a implementação dos componentes reais do Fabric começa com as autoridades certificadoras e os pares de cada organização.

As autoridades certificadoras são as âncoras de confiança das suas respetivas organizações e emitem as identidades criptográficas que os participantes utilizam para autenticar e autorizar ações dentro da rede.

Cada organização implementa a sua CA com base em especificações que incluem credenciais de inscrição, configuração TLS e outros parâmetros de segurança.

Parceiros são os nós de processamento de transações dentro de cada organização.

Esses componentes mantêm cópias do livro-razão, executam o chaincode e endossam transações com base nas políticas de endosso da rede.

Implementação por pares - Para implementar uma CA, são especificados os requisitos de armazenamento, alocações de recursos e configurações de conectividade.

Para a primeira organização:

• •A CA é implementada primeiro e, em seguida, os nós pares
• •Os ficheiros de configuração especificam os parâmetros específicos para cada um dos componentes, tais como identidades de inicialização, classes de armazenamento e tipos de serviço
• •Após a aplicação dessas configurações, os componentes são monitorados até que estejam em um estado pronto

A segunda organização tem um padrão de implementação semelhante, com a sua CA e os seus pares configurados de acordo com os requisitos específicos da organização.

Embora o processo geral seja semelhante ao da primeira organização, alguns valores de configuração diferem para representar as configurações separadas do cluster e do domínio.

A organização solicitante tem um papel especial na rede, pois fornece o mecanismo de consenso usado para sequenciar transações e criar blocos a serem distribuídos aos pares.

A criação da CA do solicitante cria a autoridade certificadora que será responsável pela emissão de identidades para os nós solicitantes.

Esta CA é independente das CAs da organização e reforça a separação entre o pedido de serviços e a aprovação de transações.

O primeiro ordenador é implementado com a configuração que especifica:

• •A sua ligação à CA do solicitante
• •Requisitos de armazenamento
• •Configurações do bloco Genesis

Este ordenador é a primeira âncora para o serviço de ordenação.

A implementação do segundo ordenador adiciona um nível extra de complexidade devido à localização deste ordenador num cluster separado.

São feitas alterações específicas:

• •Referências do host CA para apontar para o domínio CA do solicitante
• •O host CA é adicionado à solicitação de assinatura do certificado
• •Os certificados TLS da CA são copiados da configuração do primeiro solicitante

Esses ajustes são feitos para permitir que o segundo solicitante autentique e comunique corretamente com a autoridade certificadora do serviço de pedidos.

Após os ajustes de configuração, o segundo ordenador é implementado e monitorado até ficar operacional.

Nesta fase, a rede tem um conjunto completo de componentes de infraestrutura essenciais, com todas as CAs, pares e ordenadores em funcionamento e acessíveis.

Os canais no Hyperledger Fabric oferecem vias de comunicação privadas entre participantes específicos da rede, permitindo fluxos de transações confidenciais e partilha seletiva de dados.

A criação do canal começa com o registo e a inscrição das identidades administrativas de cada organização e da organização solicitante.

Essas identidades têm os privilégios necessários para realizar operações de gestão de canais.

O processo de registo requer:

• •Conecte-se à CA relevante
• •Criar contas de utilizador com atributos administrativos

Após o registo, a inscrição cria os materiais criptográficos para cada uma das identidades (certificados de assinatura e chaves privadas).

Depois que todas as identidades administrativas estiverem prontas, elas são compiladas num segredo do Kubernetes, que será usado como referência durante as operações do canal.

Este segredo reúne os materiais criptográficos necessários para a governança do canal.

O canal principal é inicializado com especificações que definem:

• •Organizações participantes
• •Os responsáveis pelos pedidos são responsáveis pelo canal
• •Políticas que regem as operações e modificações do canal

Este processo de inicialização cria o bloco génesis para o canal e cria a configuração para o canal.

Os colegas de ambas as organizações entram no canal referenciando a configuração do canal principal e contribuindo com as credenciais da sua organização.

Este processo de adesão torna o canal visível para os pares e permite que eles recebam blocos que contêm transações do canal.

Os canais de seguidores são criados para cada organização para estabelecer a ligação entre pares e o canal.

Essas configurações têm informações sobre qual par deve seguir qual canal e completam a configuração da participação na cadeia.

Chaincode, a implementação do contrato inteligente no Hyperledger Fabric, é a lógica de negócios que descreve o processamento de transações e a gestão do estado na blockchain.

O ciclo de vida do chaincode começa com a empacotamento do chaincode como um artefacto implantável.

Nesta implementação, o chaincode é implementado como um serviço que requer:

• •A criação de uma imagem Docker contendo o chaincode
• •A preparação de metadados de conexão que descrevem como os pares devem se conectar ao serviço chaincode

Para a primeira organização:

• •O chaincode empacotado é instalado no par, tornando o pacote chaincode disponível para implementação
• •É preparado um ficheiro de configuração de ligação que inclui o endereço e os detalhes da ligação TLS para o serviço chaincode
• •O chaincode é então implementado como um serviço Kubernetes no cluster da organização, tornando-o acessível aos pares da organização

Depois que a definição do chaincode for implementada, a organização aprova a definição do chaincode, indicando que está pronta para usar essa versão do chaincode no canal.

Depois que todas as organizações aprovarem a definição do chaincode, ele é enviado para o canal, o que o torna ativo e pronto para ser chamado.

Este processo de compromisso cria o contentor chaincode e torna-o a implementação oficial para o canal.

A segunda organização passa por um processo de instalação semelhante e instala o mesmo pacote de chaincode nos seus pares e implementa o serviço de chaincode no seu cluster.

Após a instalação e implementação, o chaincode está pronto para ser usado em toda a rede.

Com todos os componentes implementados e configurados, a verificação garante que a rede funciona como pretendido e pode processar transações corretamente.

O teste de transações envolve iniciar transações de amostra que exercitam a lógica do chaincode.

Estas transações são:

• •Enviado aos pares, que simulam a execução da transação e devolvem endossos à transação
• •Enviado para o serviço de ordenação, que os sequencia em blocos e os envia para todos os membros do canal

O processamento bem-sucedido das transações garante que:

• •A comunicação ponto a ponto funciona corretamente
• •As políticas de endosso são devidamente aplicadas
• •O serviço de encomendas sequencia as transações de forma adequada
• •As alterações de estado são refletidas corretamente em todos os pares

Criar uma rede Hyperledger Fabric com vários clusters e várias organizações envolve um planeamento cuidadoso, uma configuração meticulosa e a coordenação de muitos componentes e ferramentas.

O processo inclui:

• •Construir infraestruturas isoladas, mas conectadas
• •Implementar elementos especializados de blockchain
• •Configurar canais de comunicação seguros
• •Teste o funcionamento adequado através do teste de transações

Esta abordagem à arquitetura oferece as seguintes vantagens:

• •Melhoria da tolerância a falhas através da distribuição de componentes pela rede
• •Melhoria da escalabilidade através da separação dos recursos organizacionais
• •Maior controlo organizacional sobre a infraestrutura e as operações
• •Maior flexibilidade para adaptar a rede à medida que os requisitos evoluem

A infraestrutura de blockchain resultante é uma base robusta que pode ser usada para uma variedade de casos de uso em todos os setores, desde rastreamento da cadeia de abastecimento até liquidações financeiras e gestão de registos de saúde.

A natureza autorizada do Hyperledger Fabric, juntamente com a arquitetura multicluster, oferece uma plataforma que equilibra a transparência e a imutabilidade da blockchain com os requisitos de privacidade e controlo das aplicações empresariais.

Existem várias melhorias que podem ser feitas para aperfeiçoar ainda mais o processo de implementação e expandir as capacidades da arquitetura de rede.

A automação é uma oportunidade significativa para melhorias.

O desenvolvimento de scripts e modelos de infraestrutura como código pode ser usado para:

• •Simplifique o processo de configuração
• •Minimize a quantidade de etapas de configuração manual
• •Tenta minimizar a possibilidade de erros humanos

Essa automação permitiria que a rede fosse implantada de forma mais repetitiva e estivesse disponível para organizações com diferentes níveis de familiaridade com blockchain.

Aumentar o suporte para implantações multicloud tornaria a rede mais resiliente e flexível.

Implementar diferentes organizações em diferentes provedores de nuvem, como implementar uma organização na AWS, outra no Google Cloud Platform e uma terceira no Microsoft Azure, garantiria que não houvesse dependências entre nuvens individuais, mas a organização poderia aproveitar seus ambientes de nuvem favoritos enquanto ainda participava de uma rede blockchain unificada.

Essas melhorias se baseariam na base sólida formada pela implementação atual, ampliando os recursos da rede e tornando-a ainda mais adequada para implementações empresariais de produção.