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

JoinSplits

PreviousMerkle TreeNextShielded Transaction

Last updated 1 year ago

zkFi protocol transactions are specifically based on JoinSplit . On the overview, in a JoinSplit a number of existing notes are spent and new notes are created such that the total value remains conserved.

When a user spends his notes in a transaction, the so-called nullifiers of those notes need to be revealed. A nullifier is a unique element that is cryptographically bound to a note and can only be calculated with the knowledge of a note's properties i.e. by its owner. The spent notes' nullifiers are marked in the application to prevent notes with already marked nullifiers from being spent again. A fresh set of new notes is created such that the total value is conserved in the state of application. The bearer of the newly created notes, however, may change in transaction. In case of an external deposit/withdrawal of some value, the equivalent value is added/subtracted from newly created notes. Only the commitments of newly created notes are publicly shown during the transaction and are inserted into a Merkle tree data structure holding commitments of all notes ever created.

The figure above represents notes involved in a JoinSplit. These transactions can be broadly divided into three types.

  • Deposit: Deposit transaction where a non-zero external amount VinV_{in}Vin​ sent with transaction payload and equally valued one or more notes (N3N_3N3​ and N4N_4N4​) are created. Any spent notes’ (N1N_1N1​ and N2N_2N2​) value or any external withdraw amount VoutV_{out}Vout​ are zero.

  • Withdraw: Withdraw transaction where non-zero value notes (N1N_1N1​ and N2N_2N2​) are spent to withdraw some non-zero value VoutV_{out}Vout​ less than or equal to the sum of values of spent notes. Any change value left is accounted for by the creation of one or more notes (N3N_3N3​ and N4N_4N4​) for the user.

  • Transfer: Transfer transaction where no external value is revealed (i.e. VinV_{in}Vin​ = VoutV_{out}Vout​ = 0). Some notes (N1N_1N1​ and N2N_2N2​) are spent to create some new notes (N3N_3N3​ and N4N_4N4​) such that values remain conserved. However, the bearer of some note (N3N_3N3​ in the figure) may change, which in effect represents a fully private peer-to-peer transfer of value.

πŸ”΅
πŸ”€
transactions from ZCash
JoinSplit