Qual vai ser a solução que o Banco Central vai utilizar para garantir a transparência e a confiabilidade da rede e a ao mesmo tempo a privacidade dos usuários?

[aldenio]

          Qual vai ser a solução que o Banco Central vai utilizar para garantir a transparência e a confiabilidade da rede e a ao mesmo tempo a privacidade dos usuários?

Originally posted by @sandrogomes94 in #14 (comment)

Prezado @sandrogomes94,

Ainda não temos essa resposta.
A definição de uma solução capaz de garantir a transparência e a confiabilidade da rede e a ao mesmo tempo a privacidade dos usuários é um dos objetivos fundamentais do projeto Piloto do Real Digital.

obs: Caso a sua dúvida tenha sido respondida, favor fechar a issue.

Na especificação do contrato KeyDictionary do arquivo KeyDictionary.md diz o seguinte:

Contrato que representa a consulta de carteiras de clientes. É um contrato de simulação de um diretório de informações.

Este contrato será usado somente durante o piloto.

E em seguida uma estrutra de dados com algumas informações sensíveis.

struct CustomerData {
  uint256 taxId;      // O CPF do cliente
  uint256 bankNumber; // O código da participante
  uint256 account;    // A conta do cliente
  uint256 branch;     // A agência do cliente   
  address wallet;     // A carteira do cliente
  bool registered;    // Registrado ou não
  address owner;      // A carteira do participante que inseriu o cliente
}

O ponto é, seria bem simples fazer a relação das carteiras e ter acesso a dados sensíveis dos usuarios do real digital.

Deixe-me saber quando houver mais informações.

[aldenio]

Prezado @sandrogomes94 ,

Durante o projeto Piloto do Real Digital, todos os dados que circularam na DLT serão fictícios, não havendo a possibilidade de acesso indevido a qualquer tipo de dado sensível.
O contrato mencionado visa reduzir o custo de implementação do projeto Piloto, um contrato com essas características seria inconcebível num sistema real, dado o arcabouço legal vigente.

obs: Caso a sua dúvida tenha sido respondida, favor fechar a issue.

[ipsBruno]

Senhores, peço desculpas por reabrir esta issue.

Uma das características marcantes da blockchain é sua transparência, assumindo que os participantes (sejam bancos ou IPs) tenham acesso a blockchain, quando se realizam chamadas de requisição como SwapExecuted, é necessário incluir o CNPJ8 dos participantes 1 e 2 (bancos), bem como as wallets que representam os respectivos clientes. Dado este contexto, o que impediria um banco de monitorar a volumetria, a quantidade de clientes e as transações de um banco concorrente? É concebível que um banco possa desenvolver ferramentas de monitoramento similares ao que a ChainAnalysis; CrystalBlockchain oferece hoje, conduzindo análises heurísticas para potencialmente violar o sigilo bancário de outro banco.

Como este desafio está sendo abordado?

[BrunooMoniz]

@ipsBruno A característica de transparência das blockchains públicas não significa falta de privacidade. O trilema entre programabilidade e privacidade também está sendo um desafio nas redes como Ethereum, onde soluções Zero Knowledge estão sendo criadas para dar privacidade mantendo a escalabilidade dos smart contracts.

Até o momento não está implementada nenhuma solução de privacidade no Piloto do Real Digital, então tudo que é validado pelos nós do Bacen/Selic é roteado para todos os nós da rede. Assim, até começarmos a testar as soluções de privacidade (iniciando em setembro/23 e indo até março/24) os nós vão compartilhar e ter visibilidade total de todas as transações, seja de seus clientes ou não. Essas soluções de privacidade são importantes, o Bacen já sinalizou que o ambiente DREX vai ter paridade jurídica, tendo que manter sigilo bancário por exemplo.

Por estar em conformidade com a jurisdição bancária atual, acredito que pode acabar com a insegurança que algums possam ter em relação a algumas funções administrativa do Real Digital (DREX) como congelamento de saldo e cancelamento de conta por exemplo, já que devem seguir os mesmos critérios existente

@sandrogomes94 No próprio exemplo 1 já se verifica uma vulnerabilidade. Observe no código abaixo que o contrato em tese real com as informações sensíveis do usuário estão sendo passados direto no código, o que deveria ser feito de forma isolada para evitar alguma possibilidade de exploração.

async function example1() {
const STR = await ethers.getContractAt(abiSTR, '<Endereço do contrato SRT>');
const enableAccount = await ethers.getContractAt(abiRealDigitalEnableAccount, '<Endereço do contrato RealDigitalEnableAccount>');
const [, participantX, anotherAddressParticipantX ] = await ethers.getSigners();

[thiagodeev]

@sandrogomes94 No próprio exemplo 1 já se verifica uma vulnerabilidade. Observe no código abaixo que o contrato em tese real com as informações sensíveis do usuário estão sendo passados direto no código, o que deveria ser feito de forma isolada para evitar alguma possibilidade de exploração.

async function example1() { const STR = await ethers.getContractAt(abiSTR, '<Endereço do contrato SRT>'); const enableAccount = await ethers.getContractAt(abiRealDigitalEnableAccount, '<Endereço do contrato RealDigitalEnableAccount>'); const [, participantX, anotherAddressParticipantX ] = await ethers.getSigners();

São apenas exemplos, não sendo recomendados pelo BACEN para serem usados em produção. #41 (comment)

@0x5FE

Não vejo vunerabilidade no exemplo1 e como já foi mencionado antes é apenas testes de desenvolvimento

[itxtoledo]

@sandrogomes94 No próprio exemplo 1 já se verifica uma vulnerabilidade. Observe no código abaixo que o contrato em tese real com as informações sensíveis do usuário estão sendo passados direto no código, o que deveria ser feito de forma isolada para evitar alguma possibilidade de exploração.

async function example1() { const STR = await ethers.getContractAt(abiSTR, '<Endereço do contrato SRT>'); const enableAccount = await ethers.getContractAt(abiRealDigitalEnableAccount, '<Endereço do contrato RealDigitalEnableAccount>'); const [, participantX, anotherAddressParticipantX ] = await ethers.getSigners();

Não existe nenhuma falha de segurança, são somente exemplos, o ethers.getSigners só funciona em tempo de execução não havendo outra forma de chamá-lo, então não faz sentido o que você comentou.

Bom, a falha esta ali bem aonde escrevi. A própria forma que o teste foi pensado no exemplo mostra a falha. Uma vez que, se a pessoa implementa da forma que está no teste ela deixa o código vulnerável. Não é uma prática de segurança passar dados que contenham possíveis informações tidas como sensiveis direto no código, como no caso ali e sim isolar o contrato em uma variável de ambiente específica ou outra forma. Mas tranquilo, você esta correto, está tudo certo...

Contratos normalmente são públicos e armazenados na blockchain. por quê o endereço do contrato passado diretamente como parametro para um arquivo de teste seria uma vunerabilidade?

[aldenio]

Dado este contexto, o que impediria um

Prezado @ipsBruno,

Uma das prioridades do projeto piloto RD é a busca por soluções de privacidade que garantam aos usuários do Drex o mesmo grau de privacidade que já existe hoje no sistema financeiro nacional. Várias plataformas e soluções de privacidade estão sendo testadas pela equipe do real digital. Ainda não temos uma definição da solução escolhida.