Real Digital e a utilização de Hyperledger Besu na AWS

Introdução

Uma CBDC (Central Bank Digital Currency – CBDC) refere-se a uma moeda digital emitida e controlada por um banco central. É uma representação digital da moeda nacional, como o Real, o Dólar ou o Euro, e é emitida por uma autoridade central, como um banco central ou autoridade monetária. Atualmente, de acordo CBDC Tracker, em Julho de 2023, 15 países estão em fase piloto, 24 em Prova de Conceito e mais de 80 países estão pesquisando a utilização de CBDC como Reino Unido, Austrália, Alemanha e Estados Unidos.

As iniciativas sobre a emissão de uma moeda digital pelo Banco Central do Brasil (BCB) tiveram início em agosto de 2020 e, desde então, o BCB tem acompanhado de perto a utilização da tecnologia de registro distribuído (Distributed Ledger Tecnology – DLT) para a realização de transações financeiras. Nesse contexto, o BCB criou a iniciativa do Real Digital (RD), projeto que visa a criação de uma nova representação da moeda corrente no Brasil afim de facilitar as operações inter-bancárias e acelerar novos casos de uso do Sistema Financeiro Nacional (SFN).

Em Abril de 2023, o BCB iniciou o Piloto Real Digital (RD) e uma das diretrizes consiste na utilização da tecnologia Hyperledger Besu como plataforma tecnológica de registros distribuídos (DLT). Entre as vantagens citadas pelo BCB para a escolha da Hyperledger Besu estão a compatibilidade com Ethereum Virtual Machine (EVM), suporte à privacidade de transações, código aberto, diversos fornecedores de TI no Brasil e no exterior, e possuir projetos em produção.

O objetivo deste blog é apresentar um breve resumo sobre os conceitos relacionados ao Real Digital e demonstrar os componentes necessários utilizar o Hyperledger Besu em um ambiente resiliente e escalável na AWS.

As fases da iniciativa Real Digital

O Real Digital será a versão digital da moeda brasileira, Real, inclusive tendo o mesmo valor. Entre os benefícios do Real Digital podemos citar:

• Facilitar transações transfronteiriças;
• Simplificar a liquidação interbancária;
• Reduzir custos, por exemplo na criação do papel moeda;
• Incentivar a concorrência entre instituições financeiras;
• Fomentar a inovação com o objetivo de criar novos usos para a moeda em sua estrutura digital.

O BCB definiu que o Real Digital será focado no mercado atacadista, o que significa que não se destina a ser um método de pagamento puro ao consumidor final, mas sim distribuído ao público por meio de bancos, fintechs e outras instituições que fazem parte do Sistema de Pagamentos Brasileiro (SPB). Desta forma teremos o Real Digital como a moeda digital distribuída pelo BCB às instituições financeiras, usada principalmente nas transações entre bancos, e o Real Tokenizado como moedas digitais distribuídas a população pelas instituições financeiras.

O cronograma do Real Digital define a implementação do mesmo até o final de 2024, passando por diversas fases. Uma destas é a fase de testes de tecnologia, a qual se encontra agora: o Piloto do Real Digital (Piloto RD). Mais detalhes podem ser encontrados na página oficial do Piloto RD e também no site oficial do BCB sobre o Real Digital.

O Hyperledger Besu

Antes de definirmos o Hyperledger Besu é importante introduzir o conceito de blockchain. De maneira simplificada, uma cadeia de blocos (blockchain) consiste em uma estrutura de armazenamento onde os dados são gravados em blocos. Cada bloco possui uma lista de transações, uma visão total do estado atual das informações e uma referência ao bloco anterior, formando um encadeamento de dados. Essa estrutura garante a imutabilidade dos dados, pois uma alteração quebraria a referência entre os blocos.

O Hyperledger Besu é uma plataforma de blockchain desenvolvida como parte da iniciativa Hyperledger Foundation e da Linux Foundation. Sendo um cliente Ethereum (utiliza as funcionalidades de uma rede Ethereum), o Besu foi projetado para atender às necessidades de empresas que desejam implementar soluções blockchain de forma pública (Ethereum Mainnet) ou privada.

A possibilidade de implementar privacidade em uma rede privada, aliada aos padrões de código aberto da rede Ethereum, levaram o Banco Central a selecionar o Hyperledger Besu como a plataforma de DLT para o Real Digital em Abril de 2023.

Componentes centrais do Hyperledger Besu

O Hyperledger Besu é composto por diversos componentes. Entre eles temos os nós Completos (Fullnode) e nós de Arquivamento (Archive), os protocolos de interação com a rede blockchain (JSON-RPC e Websocket), os mecanismos de consenso, além da possibilidade de uso de plug-ins para gerenciamento de transações e privacidade.

Figura 1 – Diagrama de Componentes do Hyperledger Besu

Para facilitar o entendimento da arquitetura proposta na próxima sessão, vamos definir alguns destes componentes:

• Nós (Nodes): Os nós membro são conectados entre si com o objetivo de propor novas transações e armazenar as informações da cadeia, podendo esta ser parcial ou completa. Os nós da rede Besu são divididos em 4 funções:
  • RPC: recebe as chamadas API JSON-RPC, WebSocket ou GraphQL e envia para os nós membro processarem.
  • Membro: gerencia as transações e propõe a escrita de novos blocos.
  • Validador: validam os novos blocos que são propostos pelos membros, confirmando as transações.
  • Bootnodes: propagam as informações sobre outros nós da rede. Eles são opcionais, porém recomendados, uma vez que é mais simples termos nós sendo descobertos de forma dinâmica do que estática.
  • Dependendo do modo de sincronização e da quantidade de informações armazenadas, cada nó também é classificado como:
    • Full node: armazena todo o estado atual da cadeia de blocos, porém não possui todas as informações das transações que estão em blocos mais antigos (por exemplo o saldo de uma conta em um determinado mês ou ano). Utilizado principalmente para serviços transacionais.
    • Archive Node: armazena todos os estados atuais desde a criação da cadeia de blocos. É utilizado para consultas histórias, serviços como explorador de blocos, provedores de carteiras digitais ou serviço analítico.
  • RPC (Operações no Ledger): é um protocolo utilizado para fazer chamadas de API em uma rede Besu. As aplicações interagem com a rede submetendo transações através de chamadas JSON-RPC ou Websocket. Ferramentas de desenvolvimento como web3js, Truffle e Remix simplificam a criação de contratos inteligentes (smart contracts) e aplicações distribuídas (dAppS). Esses smart contracts são softwares que implementam regras de negócio para as transações que serão gravadas na cadeia de blocos (blockchain), e são executados pelos membros da rede.
  • Tessera (Privacidade e gerenciamento de transações): o Hyperledger Besu necessita de um componente externo para gerenciamento de chaves e privacidade. Cada membro necessita do seu próprio gerenciador de transações e privacidade. Um exemplo desses tipos de componente é o Tessera, que possui duas funcionalidades principais:
    • Gerenciador de Transações (Transaction Manager): ler e distribuir de forma privada os dados de uma transação entre os nós/clientes da rede.
    • Enclave: gerenciar e utilizar as chaves públicas dos nós da rede, criptografando e descriptografando as informações.
  • Modo de Consenso: em redes privadas, o Hyperledger Besu suporta os protocolos de consenso QBFT, IBFT 2.0 e Clique. Estes protocolos se baseam em Proof of Authority (PoA). São usados quando os participantes de uma rede privada se conhecem e há um nível de confiança entre eles. No protocolo QBFT, por exemplo, um grupo de nós validadores são responsáveis por validar as transações feitas pelos outros membros. Além disso, são os validadores que autorizam a adição de novos membros na rede. Mais detalhes na documentação do Besu.
  • Ethereum Virtual Machine: máquina virtual Ethereum (baseada em Java) que possibilita a implementação e execução de softwares (smart contracts).

Além destes componentes, o Hyperledger Besu utiliza algumas tecnologias e mecanismos cujo objetivo é aumentar a disponibilidade e velocidade das transações, garantindo a resiliência da cadeia de blocos. Podemos citar alguns desses mecanismos:

• peer to peer network (p2p) é utilizado no Hyperledger Besu para descobrimento dos nós, sincronização do estado da cadeia e propagação de novas transações. Dessa forma a adição ou remoção de novos membros pode ser feita de forma simplificada (sem a necessidade de configuração manual), aumentando a escalabilidade da rede.
• Armazenamento distribuído da cadeia de blocos (blockchain Ethereum). A cadeia de blocos consiste em listas de transações ordenadas armazenadas em blocos, onde cada bloco possui um cabeçalho com um hash referenciando o bloco anterior, formando uma cadeia. Esse cabeçalho é usado para verificar a integridade de forma criptográfica, ou seja, garantir a imutabilidade dos dados, pois uma alteração nas transações causaria a mudança do hash do bloco, o que quebraria toda a cadeia. O cabeçalho de cada bloco também referencia o estado global (world state), que é um mapeamento do estado atual de cada conta, facilitando a leitura da posição atual(valor) de uma determinada conta. Cada nó do Hyperledger Besu, possui copias dos blocos, garantindo a confiabilidade da rede. Você pode ler mais detalhes sobre o armazenamento, estrutura de dados e algorítmos utilizados no Ethereum aqui e no paper do Dr. Gavin Wood, co-fundador do Ethereum.
• Sincronização de dados é utilizado em casos de perda de um nó ou entrada de novos nós, garantindo que o estado atual das contas e todos os dados da cadeia não sejam perdidos. Dependendo do mecanismo de sincronismo e o tipo de nó (Full Node ou Archive Node), todos os blocos desde a criação da cadeia, ou apenas o estado atual será copiado para o novo nó. A quantidade de transações, CPU, IO de disco do novo membro e o sincronismo utilizado(full sync, fast sync e snapshot sync) influenciam o tempo necessário para que um novo nó entre na rede.

Arquitetura Hyperledger Besu na AWS

Até agora vimos como funciona o Hyperledger Besu, em modos gerais. Agora vamos nos aprofundar em como implementá-lo usando uma infraestrutura robusta e resiliente para a execução dos nós. A arquitetura de exemplo, apresentada neste blogpost, considera a implementação dos nós do Hyperledger Besu em containers, garantindo a escalabilidade horizontal da rede, além de considerar o uso de serviços gerenciados, simplificando a gestão do ambiente.

Figura 2 – Arquitetura sugerida do Hyperledger Besu na AWS

Os serviços AWS utilizados são:

• Amazon Elastic Kubernetes Services (Amazon EKS): utilizando uma plataforma gerenciada de containers, é possível implementar o Hyperledger Besu de forma escalável e eficiente através de ferramentas nativas de Kubernetes como o Karpenter. Cada Pod (controlado por StatefulSets) representa um nó do Hyperledger Besu, tendo seu próprio disco de forma independente.

• Amazon Elastic Block Storage (Amazon EBS): utilizado para realizar a persistencia dos dados relacionados as transações, vinculados aos pods através do conceito de persistent volume (PVC). Se um nó falhar, ele pode ser provisionado novamente e o volume persistente (PVC) é anexado sem a perda de dados. Essa arquitetura garante a velocidade das transações. Ao utilizar discos io2 Block Express é possível entregar até 256,000 IOPs por disco.
• AWS Key Management Service (AWS KMS): é utilizado para criação da chave inicial que será utilizada na criação das chaves dos nós. Posteriormente, pode ser usado para a gestão de chaves privadas (carteiras digitais), inclusive integrado com serviços de computação digital como o AWS Nitro Enclaves.
• AWS Secrets Manager: armazena os endereços que cada membro utiliza para comunicação, e as chaves públicas e privadas que os gerenciadores de transação, como o Tessera, utilizam para criptografar as transações.
• Amazon Managed Service for Prometheus: utilizado para coletar métricas do cluster Kubernetes, que serão usadas para escalar os clusters. Também armazena métricas do Hyperledger Besu, usadas para escalar os nós do Hyperledger Besu.
• Amazon Managed Service for Grafana: utilizado para criação de dashboards de monitoramento da infraestrutura de Kubernetes e do Hyperledger Besu.

Para implementar esta arquitetura, siga os passos descritos no repositório do aws-samples (descrito na sessão de Artefatos).

A Resiliência do ambiente Hyperledger Besu na AWS

A nuvem AWS está disponível em 31 diferentes Regiões, conta com 99 Zonas de Disponibilidade, e mais de 450 pontos de presença. Uma Região AWS é uma localização geográfica no mundo aonde existem clusters de datacenters AWS. Cada grupo lógico de datacenters é chamado de Zona de Disponbilidade (AZ), de forma que uma região é composta por múltiplas Zonas de Disponibilidade. Cada AZ tem independência do seu fornecimento de energia, acesso físico, infraestrutura de refrigeração, e está conectada através de links redundantes de alta velocidade e baixa latência, possibilitando cenários de replicação síncrona entre AZs. As Regiões AWS atendem às mais altas demandas de segurança, conformidade e proteção de dados. Mais detalhes podem ser obtidos neste link.

A AWS implementa o Modelo de Responsabilidade Compartilhada, onde a AWS tem responsabilidade sobre a gestão da nuvem e os clientes da gestão do que colocam na nuvem. Ao utilizar serviços gerenciados, como o Amazon EKS e o Amazon Managed Service for Prometheus, os clientes deixam de se preocupar com a gestão de infraestrutura e conceitos básicos, como patch de segurança de sistema operacional, e podem focar nas aplicações que implementam nestes serviços. Isso reduz o custo e aumenta a eficiência operacional, agiliza a adequação a conformidades como ISO27001, ISO9001, LGPD, e PCI-DSS, assim como traz altos níveis de serviço (SLA, na sigla em inglês). O Amazon EKS entrega um SLA de 99,95% enquanto o Amazon Managed Service for Prometheus entrega um SLA de 99,9%, por exemplo. Além disso, a AWS é aderente à mais de 143 padrões de segurança e certificações de conformidade, ajudando clientes à se adequarem às mais diferentes demandas ao redor do mundo. Mais detalhes na página sobre conformidade na AWS.

Na arquitetura de referência acima, em conjunto com o Amazon EKS utilizamos o Karpenter, um projeto de código aberto que gerencia o escalonamento dos nós do cluster Kubernetes. Sempre que novos Pods (nós Besu) precisarem ser provisionados o Scheduler do Kubernetes checará se o cluster possui capacidade computacional para o provisionamento, caso não possua, o Karpenter provisionará novas instâncias do Amazon Elastic Compute Service (Amazon EC2) e as adicionará automaticamente ao cluster, aumentando a capacidade computacional. Além disso, o Karpenter selecionará a opção de menor custo entre as família e tamanho de instância com base na capacidade requerida pelos novos Pods, podendo inclusive provisionar instâncias Spot (levará em conta a disponibilidade e o menor custo). Com o Karpenter, a rede Besu poderá aumentar sua quantidade de nós facilmente, enquanto controla os custos evitando um cluster Kubernetes (ou instâncias EC2) super-provisionado (desperdício de recursos).

O Amazon EKS utiliza as zonas de disponibilidade da AWS para executar os nós de maneira distribuída e consequentemente os Pods também devem ser distribuídos entre estes nós do cluster Kubernetes. Para alcançar tal efeito recomenda-se a utilização de topologySpreadConstraint. Por exemplo, utilizando o protocolo de consenso QBFT (citado acima) é necessário que ao menos 2/3 dos validadores aprovem uma transação antes que a mesma seja válida. Supondo uma rede com 6 validadores, é preciso garantir que esses validadores estejam distribuídos em 3 zonas de disponibilidade (2, 2, 2), para que mesmo que uma zona de disponibilidade venha a falhar, ainda é possível ter uma quantidade de validadores maior ou igual a 2/3 (2/3 de 6 = 4, logo precisamos de ao menos 4 validadores). Por outro lado, uma rede com 5 validadores distribuídos em 3 zonas de disponibilidade (1, 2, 2) não seria um cenário ideal, pois se a zona de disponibilidade com 2 validadores falhar, não teremos ao menos 2/3 dos validadores disponíveis, impossibilitando a criação de novos blocos com transações (2/3 de 5 = 3.33, logo precisamos de ao menos 4). O mesmo ocorreria se dividirmos 4 validadores entre duas ou três Zonas de disponibilidade. Portanto, é importante planejar a rede Besu de forma que pelo menos 2/3 dos validadores estejam sempre disponíveis.

Artefatos

Para facilitar o entendimento e acelerar a adoção, compartilhamos no Github AWS Samples o código fonte para implementação da arquitetura apresentada utilizando Terraform como opção de Infraestrutura como Código.

Conclusão

O mercado financeiro está em constante movimento para implementação de melhorias e aumento dos serviços prestados à população, como o projeto Real Digital. Através da utilização de tecnologias de DLT é possível otimizar diversos processos do mercado financeiro atual, ao mesmo tempo que é gerado novos casos de uso através da tokenização de ativos. Construir soluções robustas e escaláveis utilizando recursos de nuvem, garantem a confiabilidade e a segurança dos usuários e instituições em um mundo tokenizado. Neste blogpost apresentamos uma possível arquitetura para alcançar esses objetivos.

Sobre os Autores

Gustavo Carreira é Arquiteto de Soluções sênior na AWS, trabalhando na indústria de FSI. Sua experiência profissional com mais de 10 anos de experiência em Arquitetura e 7 anos com banco de dados relacional e infraestrutura. Atualmente ajuda os clientes na definição e planejamento de diversas soluções corporativas.

Joao Melo é Arquiteto de Soluções atendendo clientes Enterprise com foco em mercado financeiro. Com mais de 10 anos de experiência, João iniciou sua carreira como desenvolvedor Java e .NET, e posteriormente se especializou em infraestrutura como Engenheiro de Sistemas na Cisco Systems. Formado pela FEI, é entusiasta de Containers, DeFi, Sistemas de Pagamento e apaixonado por cinema e jogos.

Leonardo Roque é Arquiteto de Soluções na AWS atendendo clientes Enterprise com foco em mercado financeiro. Com mais de 12 anos de experiência atuando com desenvolvimento e arquitetura, formado em Ciência da Computação, com MBA em arquitetura de software e especializado em arquitetura de sistemas distribuídos, Leonardo é entusiasta de Containers, Severless, DevOps e apaixonado por esportes