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
  • Overview
  • Sign Key Pair
  • View Key Pair
  • Root Address
  1. Technical Implementation

Shielded Account

Implementation of a shielded account

Overview

A Shielded Account can be thought of as having a private crypto account counterpart to regular Ethereum accounts. However, unlike public Ethereum accounts which have a single public-private key pair, a shielded account has two such key pairs - Sign and View key pairs along with a Root Address.

For a better user experience, the shielded account keys are derived from the public Ethereum address itself. Meaning, that a user having a seed phrase and/or private key to their wallet can recover the same shielded account. This eliminates the load of handling any additional keys or seed phrases other than your regular Ethereum wallet. You implicitly have a Shielded Account if you have an Ethereum account in wallets (e.g. MetaMask, Rainbow, etc.).

To derive keys, the user signs a fixed message (EIP-712). The obtained signature's (Poseidon) hash acts as the seed ( δ\deltaδ ) for deriving both key pairs of Shielded Account.

σ=ECDS_Sign(M)δ=H(σ)\sigma = \mathtt{ECDS\_Sign}(M) \\ \delta = H(\sigma)σ=ECDS_Sign(M)δ=H(σ)

Sign Key Pair

The sign key allows the holder of the shielded account to authorize transactions from its shielded account. A valid signature is constructed by signing the transaction data with sign private key, sss via the Schnorr signature scheme over the Baby JubJub curve.

Holding a Sign private key gives the holder authority to spend any asset associated with that shielded account. Never share it!

The signing operation is intended to happen in a secure environment.

Sign private key is derived as:

SALT_SIGN = poseidonHash(stringToHex('sign'));

Sign Public key is a point on the curve generated using this sign private key.

View Key Pair

The view key renders the view access to your shielded account - giving anyone holding the ability to read your balance and transaction history. The view private key encrypts the transaction-specific data while performing the transaction. Later, the same data is decrypted to reveal the balance and transaction history by the same key.

View private key is derived as:

const SALT_VIEW = poseidonHash(stringToHex('view'));

View Public key is a point on the curve generated using this view private key.

Root Address

Root address is a poseidon hash of sign public keys and view private key.

poseidonHash([this.signer.publicKey.x, this.signer.publicKey.y, this.viewer.privateKey]),
PreviousCryptographic PrimitivesNextShielded Address

Last updated 9 months ago