Visão Geral do Hamsa Privacy

Como funciona o Hamsa Privacy

A arquitetura da solução permite que instituições financeiras realizem DVPs privados entre si, mantendo a auditabilidade regulatória e a soberania operacional. O funcionamento é estruturado nos seguintes pilares:

Instâncias dedicadas de Layer 2 para cada instituição

Cada instituição participante opera sua própria instância isolada de Layer 2, compatível com EVM, de forma independente e descentralizada. Essas instâncias podem ser orquestradas por Kubernetes ou Docker Compose, e incluem os seguintes componentes técnicos:

Sequencer: seleciona transações da transaction pool da instância.
Block Finalizer: agrupa as transações selecionadas e estrutura um novo bloco.
Executor: executa as transações do bloco localmente.
Prover: gera uma prova de conhecimento zero (ZK-Proof) que atesta a execução correta e a integridade do bloco.

Layer 1 comum para finalização

A solução utiliza uma Layer 1 comum a todas as instituições participantes, responsável por:

Receber as provas ZK geradas em cada Layer 2
Verificar a validade dessas provas
Efetivar a liquidação interinstitucional
Emitir eventos de emparelhamento (match) para sinalizar quando um DVP pode ser finalizado

Contratos inteligentes de infraestrutura

A arquitetura inclui contratos que coordenam os fluxos entre Layer 1 e Layer 2, habilitando depósitos, saques, custódia temporária e finalização dos DVPs. São eles:

a) DvpMatch (Layer 1)

Registra as chamadas de DVP originadas de diferentes Layer 2. Quando duas chamadas compatíveis são recebidas, um evento é emitido, sinalizando que o DVP pode ser completado.

b) L1TMSC (Layer 1)

Gerencia os saldos dos tokens depositados pelas instituições. Suporta tanto ERC-20 quanto ERC-1155, e atualiza os saldos após a finalização de cada DVP.

c) L1Bridge (Layer 1)

Controla o fluxo de saldos entre Layer 1 e Layer 2 (depósitos e saques).

Importante: a conta de destino em L2 pode ser diferente da conta de origem em L1, e vice-versa. A solução garante que a soma dos saldos depositados por uma instituição em L1 será sempre igual à soma dos recebidos em L2.

d) DvpEscrow (Layer 2)

Executa a custódia temporária dos fundos durante a negociação do DVP. O saldo permanece retido até a verificação da prova em L1.

e) L2TMSC (Layer 2)

Gerencia os saldos de tokens mantidos pelas instituições dentro da sua instância de Layer 2, para ambos os padrões ERC-20 e ERC-1155.

Arquitetura de alto nível da solução

Está ilustrado abaixo:

Fluxos operacionais principais

A arquitetura contempla dois fluxos principais, fundamentais para o funcionamento da solução:

1.1. Fluxo de depósito de fundos (Layer 1 → Layer 2)

a) A instituição inicia um depósito via L1Bridge, especificando a quantidade de tokens e o endereço de destino em Layer 2.

b) Os tokens são travados em L1 e creditados na instância correspondente em L2.

c) O contrato L1TMSC atualiza o saldo da instituição e o contrato L2TMSC registra a entrada de fundos na instância em Layer 2.

1.2. Fluxo de DVP com registro e verificação (Layer 2 → Layer 1)

a) Cada instituição participante inicia uma chamada ao contrato DvpEscrow em sua respectiva Layer 2.

b) A chamada é registrada e, com a execução do bloco, o componente Prover gera a ZK-Proof da operação.

c) A prova e os metadados são enviados à Layer 1 e repassados ao contrato DvpMatch.

d) Quando o DvpMatch identifica chamadas compatíveis de ambas as partes envolvidas, emite um evento em L1, sinalizando que a transação está apta a ser finalizada.

e) A finalização é executada em Layer 1, com transferência de saldos entre as instituições, respeitando as condições originais definidas em L2.

Conclusão

Hamsa Privacy oferece uma estrutura robusta e auditável para execução de DVPs entre instituições em redes permissionadas, utilizando provas ZK como mecanismo de garantia e privacidade. Todos os fluxos são determinísticos, verificáveis, e compatíveis com os requisitos técnicos esperados por reguladores financeiros e bancos centrais.