Labyrinth
WhitepaperResearchGet Private Access
  • 🔭Labyrinth Overview
    • Introduction
    • Why Labyrinth?
    • Who can use Labyrinth?
    • Reward and Fee in Labyrinth
    • Compliance
  • ⭐Use Labyrinth web App
    • How to use the Labyrinth app?
  • 📦Labyrinth SDK
    • ❓What is Labyrinth SDK?
    • ⚒️Quickstart
      • Setup Environment
      • Initialization
      • Private Transactions
      • Balance And Transaction History
      • Protocol Integration
    • 1️⃣Getting Started
    • 🔐Shielded Account
    • 📈Transaction
    • ▶️Initializing SDK
    • 💰Balances And History
    • 📤Sending Transaction
    • 🔌Integrating with DeFi Protocols
    • Labyrinth fee structure
  • Compliance Solution
    • Overview of Compliance
    • How Compliance Works
  • 💻CLI
    • ▶️Running SeDe CLI
  • Technical Implementation
    • Cryptographic Primitives
    • Shielded Account
    • Shielded Address
    • Account Abstraction
    • 🔵Core Architecture
      • 💵Note
      • 🌲Merkle Tree
      • 🔀JoinSplits
      • 🛡️Shielded Transaction
    • 🔄Protocol Interoperability
  • Resource and support
    • Roadmap
    • FAQs
    • Whitepaper
    • Selective De-Anonymization Compliance Paper
  • Contact and socials
    • Labyrinth Website
    • Twitter
    • Discord
    • Contact Us
Powered by GitBook
On this page
  • Selective De-Anonymization (SeDe) Network:
  • Network Components:
  1. Compliance Solution

How Compliance Works

Detail the inner workings of the compliance network, including selective de-anonymization.

PreviousOverview of ComplianceNextRunning SeDe CLI

Last updated 10 months ago

Selective De-Anonymization (SeDe) Network:

Labyrinth introduces the SeDe Network to strike a balance between privacy preservation and compliance. SeDe allows for the de-anonymization of illicit transactions through the recursive traversal of subgraphs of linked transactions. It achieves this without centralizing control and decision-making. It operates as follows:

a. Balancing Privacy: SeDe aims to balance privacy-preserving features by allowing for the de-anonymization of illicit transactions. It recognizes that privacy should not be absolute and that certain transactions need to be traceable for regulatory purposes.

b. Multiple Entities: SeDe distributes the responsibility for de-anonymization among multiple entities, ensuring that no single entity has complete control over this process. This prevents potential abuse of power.

c. Threshold Encryption: SeDe uses threshold encryption schemes to protect user data while allowing for controlled de-anonymization when required. This ensures that sensitive information remains confidential until a legitimate need for de-anonymization arises.

d. Zero-Knowledge Proofs (ZKPs): Zero-knowledge proofs are employed to prove the correctness of transactions without revealing sensitive data. This enables the verification of compliance without exposing transaction details.

Network Components:

  • Users (U): Users of the privacy-preserving application, which can be either honest users seeking privacy or malicious actors.

  • Guardians (G): A set of entities responsible for gatekeeping transaction de-anonymization. A minimum quorum of guardians is required to grant de-anonymization permission.

  • Revoker (R): An entity with the ability to de-anonymize transactions but requires permission from guardians.

  1. Accountable Anonymity: Users must adhere to compliance constraints during transactions, ensuring that any attempt to act maliciously will result in the loss of anonymity.

  2. Accountable De-Anonymization: The revoker cannot de-anonymize transactions without publicly requesting permission from guardians. Guardians, even when colluding, cannot reveal transaction data without cooperation from the revoker.

  3. Non-Fabrication: Honest users can prove their innocence if falsely accused of involvement in illicit transactions.

  4. Implementation: SeDe is implemented using threshold encryption schemes and Zero-Knowledge Proofs (ZKPs). Users are constrained to include double-layered encryptions of newly created notes in transaction payloads, and they must provide proofs that the encryptions were performed correctly.

  5. The decryption of Illicit Transactions: When de-anonymization is required, the revoker initiates the process by signing a de-anonymization request and submitting it to guardians. Guardians verify the request's legitimacy, and if approved, the revoker can decrypt the transaction data. The revoker recursively traces linked illicit transactions until a subgraph of all transactions originating from illicit sources is revealed.

Overview of SeDe