pedrosgmagalhaes/drex_smartcontracts

Use Case: Zero Knowledge: Data Protection Layers

Opened this issue · 4 comments

pedrosgmagalhaes commented

Use Case: Zero Knowledge: Data Protection Layers

Objective:

The main objective of this use case is to implement a solution based on the Zero Knowledge Protocol (ZKP) to enhance data protection in Digital Real transactions. The protocol aims to authenticate information provided in transactions, without the need to reveal sensitive data among participants.

Rationale:

With the increasing digitalization of financial transactions, ensuring the privacy of user data has become a challenge, especially with open blockchains, which, although transparent, conflict with banking secrecy rules and data protection legislation. Therefore, a Zero Knowledge protocol can ensure the privacy and security of user data. This protocol allows, for example, a party to prove that they have a bank balance for a transaction without the need to provide their data and bank balance, or the actual identity verification, without revealing confidential personal information.

Expected Behavior:

The Zero Knowledge protocol should allow the verification of information without the need to reveal confidential details:

  1. Authentication: The protocol should authenticate the information provided in the transactions without the need to reveal sensitive data among the participants of the negotiations.

  2. Compatibility: The protocol should be compatible with the Digital Real's Distributed Ledger Technology (DLT) and should offer privacy for applications of public blockchains compatible with the Ethereum network.

  3. Adaptability: The protocol should be able to adapt to the different use cases of the Digital Real, facilitating a wide range of financial and non-financial operations.

Security Considerations:

The implementation of a Zero Knowledge protocol involves several security considerations:

  1. Personal Data Protection: The protocol should be designed to ensure that no confidential personal information is revealed during transactions.

  2. Protection Against Forgery: The protocol should be resistant to forgery attempts, ensuring that only verified information is accepted during transactions.

  3. Compatibility: The protocol should be compatible with the existing blockchain framework, without compromising the network security or the privacy of the users.

  4. Extensive Testing: Before implementation, the protocol should be extensively tested under a variety of conditions to ensure its robustness and reliability.

Please note that this is a high-level overview of the proposed use case, and the specific implementation details may vary based on the technical requirements and restrictions of the Central Bank. Always follow security best practices and consult security experts when implementing such a system.

pedrosgmagalhaes commented

  1. Awesome zero knowledge proofs (zkp):
    A curated list of awesome things related to learning zero knowledge proofs
    Link: https://lnkd.in/gzbVCgzu

  2. Zero Knowledge Proofs: An illustrated primer
    Link: https://lnkd.in/gQazbGs8

  3. Demystifying zero-knowledge proof
    Link: https://lnkd.in/gkYQ3F5G

  4. Introduction to SNARKs/STARKs
    Link: https://lnkd.in/gXu23-YW

  5. On Interactive Proofs and Zero-Knowledge
    Link: https://lnkd.in/gaq5ggN4

  6. ZK Basics Cheatsheet
    Link: https://lnkd.in/gjymvDnw

  7. A Non-Mathematical Introduction to Zero Knowledge Proof
    Link: https://lnkd.in/g-DGBcu8

  8. The ‘zk’ in zkLink — Zero Knowledge Proofs
    Link: https://lnkd.in/gQSQ9-bf

  9. What are Zero Knowledge Proofs?
    Link: https://lnkd.in/gyrP_-x3

liobrasil commented

@pedrosgmagalhaes basically here the idea is to allow participant to transfer BRL with confidentiality ? ZKP will be implemented on the application level (like in tornado cash for example) and not on infra level (like in zk rollup for example). IMO, ZKP can only be used for anonymous transfer. Any thoughts on that @krzysztof-cywinski ?
I know some ZKP expert that can help on a conceptual level about what can be done or not...

  • 👍1
krzysztof-cywinski commented

From what I've seen in the docs they want to use something that pretty much resembles TornadoCash.
A good explanation of the mechanic can be found here: https://betterprogramming.pub/understanding-zero-knowledge-proofs-through-the-source-code-of-tornado-cash-41d335c5475f
This has to be implemented both on the application layer and on the contract layer. This can be done by a separate contract (or set of contracts) from the RealDigital main contracts.
I think that's the article they based the official presentation on. The images are exactly the same (no attribution, though 👎).
You can see the BCB ZKP spec from page 8 forward here: https://www.bcb.gov.br/conteudo/eventos/Documents/moedas_digitais/tokenizacao/WorkTOK-TECH_3A_A_APRESENTACAO_Caminhos_para_um_Real_Digital.pdf
There are also some code samples, but I didn't dive into this yet.

krzysztof-cywinski commented

The challenge here might be volume. Since each bank has its own RealTokenizado (or at least I assume it does, because the bank is a participant as stated in RT docs. Correct me if I'm wrong here), a customer of a bank can only do swaps with other customers of the same bank in this manner, because they need to be exchanging the same token. This could leak privacy for large volume transactions. Such transactions would have to be sliced into smaller chunks to maintain privacy as large volumes would probably stand out both on the input and the output side and could link the sender to the receiver.