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
  1. Technical Implementation
  2. Core Architecture

Shielded Transaction

The shielded or private transactions in Labyrinth are performed by spending the user's notes in multiple JoinSplits while hiding all sensitive transaction details like the identity of the sender/receiver and values involved.

This is achieved by generating a zero-knowledge proof on the client side which proves that all the computations of the transaction were performed correctly. It proves that:

  1. Spent notes' commitments are at some indices in the Merkle tree and it knows the same.

  2. Spent notes' commitments are calculated correctly.

  3. The signatures produced by a spent notes' owner's private key by signing the transaction are valid.

  4. The revealed nullifiers of the spent notes are calculated correctly.

  5. The commitments of the new notes are calculated correctly.

  6. The total value remains conserved i.e. values of spent notes and newly created notes (adjusted with any external deposit/withdrawal value) are equal.

The generated proof π\piπ is sent in the payload of the transaction, which is later verified by an on-chain verifier. States are modified e.g. commitments are inserted into tree and nullifiers are marked only if this verification succeeds, concluding the transaction.

PreviousJoinSplitsNextProtocol Interoperability

Last updated 10 months ago

šŸ”µ
šŸ›”ļø