Guia do Desenvolvedor

Este documento detalha a arquitetura e as práticas de desenvolvimento para nossa solução de privacidade construída em uma blockchain Layer-2, utilizando mecanismos Delivery vs Payment (DvP). É destinado a desenvolvedores que estão integrando com nossa plataforma, focando nos conceitos chave, exemplos de código e melhores práticas.

1. Visão Geral & Arquitetura

Nossa solução permite transações seguras e privadas entre bancos em um ambiente Layer-2. O princípio fundamental é facilitar o DvP – garantindo a entrega de ativos (e.g., tokens) antes da execução do pagamento, minimizando o risco para todas as partes envolvidas.

Componentes Chave:

  • Layer 1 (L1): A blockchain subjacente (e.g., Besu). Usada principalmente para liquidação e validação de prova.
  • Layer 2 (L2): Nossa solução Layer-2, fornecendo velocidade de transação e privacidade aumentadas. É onde a maioria das operações DvP ocorrem.
  • Smart Contracts: Os smart contracts chave incluem:
    • L1-TMSC: Gerencia saldos de tokens na L1 para fins de liquidação. Registra o saldo total do banco por tipo de token.
    • L2-TMSC: Contrato de token ERC1155 gerenciando tokens bridgeados da L1. Registra saldos de usuário por tipo de token. Usado para conceder tokens após a ponte (bridging).
    • DvpEscrow: O smart contract principal responsável por coordenar transações DvP, garantindo que tanto a entrega quanto o pagamento ocorram conforme o pretendido.

Fluxo de Trabalho:

  1. Bridging: Os ativos são bloqueados em uma conta de liquidação do banco na L1 (gerenciada pelo L1-TMSC) após o bridging.
  2. Mintagem de Tokens: Um nó bancário correspondente na L2 recebe um evento criptografado para cunhar tokens dentro do smart contract L2-TMSC para o endereço de cliente especificado.
  3. Execução DvP: As transações DvP são orquestradas usando o smart contract DvpEscrow, garantindo que os ativos sejam entregues antes do pagamento ser liberado.
  4. Liquidação: Periodicamente, a liquidação ocorre na L1 para reconciliar saldos entre bancos registrados no L1-TMSC.

2. Conceitos Chave: DvP e Geração de Hash

A base da nossa solução é o Delivery vs Payment (DvP), que garante que a entrega de um ativo ocorra antes do pagamento ser liberado. Isso minimiza o risco contrapartidário e garante confiança em transações entre bancos.

Geração de Hash para Bundle & Chunk Hashes:

Para garantir a integridade dos dados e o processamento eficiente dentro do fluxo de trabalho DvP, utilizamos um mecanismo de hashing para criar chunk e bundle hashes. Este trecho de código demonstra como esses hashes são gerados:

const p = require('poseidon-lite');
const crypto = require("crypto");


async function generateHash() {
	let chunkHash1 = "0x"+ crypto.randomBytes(32).toString("hex");
	let chunkHash2 = "0x" + crypto.randomBytes(32).toString("hex");
	
	console.log("chunkHash1", chunkHash1)
	console.log("chunkHash2", chunkHash2)
	
	let hash= p.poseidon3([chunkHash1, chunkHash2, 0]);
	let bundleHash= "0x" + hash.toString(16).padStart(64,"0")
	
	console.log("bundleHash: ", bundleHash)
	
	return [chunkHash1, chunkHash2, bundleHash];
}

Explicação:

  • poseidon-lite: Esta biblioteca fornece uma função de hash Poseidon rápida e eficiente.
  • crypto: O módulo crypto integrado do Node.js é usado para gerar strings hexadecimais aleatórias representando os chunk hashes.
  • generateHash(): Esta função gera três chunks aleatórios e os combina usando Poseidon para criar um bundle hash. O bundle hash serve como um identificador único para os dados da transação.

3. Integrando com DvP

Você pode integrar com nosso sistema DVP através de dois métodos principais:

  1. Serviços Backend: Chame o smart contract L2-dvp-escrow diretamente dos seus serviços backend (e.g., usando Java, Go ou JavaScript).
  2. Smart Contracts de Negócios: Integre a funcionalidade DvP dentro dos seus próprios smart contracts de negócios.

Exemplo: Agendamento de um DvP via Serviço Backend

const DvpEscrow = await ethers.getContractFactory("DvpEscrow");\
const escrow = await DvpEscrow\.attach(demo\_config.l2\_escrow\_address).connect(safra\_user\_wallet);
let tx = await escrow\.scheduleBurnMintAndGenerate(scheduleRequest);
await waitTxReceipt(tx.hash, bank1RpcUrl);
Estrutura ScheduleRequest2:

EstruturaScheduleRequest2:

struct BurnRequest {
    address tokenScAddress;
    uint256 tokenType;
    address account;
    uint256 amount;
}

struct MintRequest {
    address tokenScAddress;
    uint256 tokenType;
    address account;
    uint256 amount;
}

struct BurnSettleRequest {
    address tokenScAddress;
    uint256 tokenType;
    address account;
    uint256 amount;
    address toBankAddress;
}

struct ScheduleRequest2 {
    uint256 index;
    uint256 chunkHash;
	uint256 bundleHash;
	uint256 expireTime;

	BurnRequest[] burnRequests;
	MintRequest[] mintRequests;
	BurnSettleRequest[] burnSettleRequests;
}

4. Gerenciamento de Tokens (L2-TMSC)

O smart contract L2-TMSC gerencia todos os tokens bridgeados da L1. Você pode interagir com ele para:

  • Mintar Tokens: Use a função mint() para injetar tokens em endereços de teste durante POC ou testes.
const L2Tmsc = await ethers.getContractFactory("L2TMSC");\
const l2Tmsc = await L2Tmsc.attach(demo\_config.l2\_tmsc\_address).connect(safra\_admin\_wallet);
let tx = await l2Tmsc.mint(user\_address, demo\_config.l1\_erc1155\_address, demo\_config.loanTpftId, amount);
await waitTxReceipt(tx.hash, bank1Provider.provider)
Controle de Acesso: A funcionalidade de mint e burn é controlada por controle de acesso. Por padrão, está desabilitada. Habilite-a usando l2Tmsc.updateAdmin().

5. Bridging Tokens da L1 para L2

Use o seguinte código para depositar tokens ERC20 da L1 para L2:

const l1Bridge = await hre.ethers.getContractAt("L1Bridge", bridge_address);
const encode =await encryptEvent(bank_user_address,erc20_address,0,amount,rsa_pk)

6. Verificação de Saldo (L1-TMSC)

Você pode verificar saldos do banco usando

l1Tmsc.balanceOfBank(address bank\_settlement, address token\_address, uint256 token\_type