💻
Developer Guide
  • Wallet SDK
    • Wallet Overview
    • Getting Started
      • 1. Start the RAILGUN Privacy Engine
      • 2. Build a persistent store for artifact downloads
      • 3. Load a Groth16 prover for each platform
      • 4. Add networks and RPC providers
      • 5. Set up a debug logger
    • Private Wallets
      • RAILGUN Wallets
      • View-Only Wallets
      • Encryption Keys
    • Private Balances
      • Balance and Sync Callbacks
      • Updating Balances
      • QuickSync
    • Transactions
      • Shielding
        • Shield ERC-20 tokens
        • Shield base token
        • Shield NFTs
      • Private Transfers
        • Private ERC-20 Transfers
        • Private NFT Transfers
      • Cross-Contract Calls
      • Unshielding
        • Unshield ERC-20 tokens
        • Unshield base token
        • Unshield NFTs
      • UX: Private Transactions
    • Broadcasters
  • Cookbook SDK
    • Cookbook Overview
    • Recipe Guide: Write a zkApp
      • "Step" — A smart contract call
      • "Recipe" — Steps in series
      • "Combo Meal" — 2+ Recipes
    • Use your zkApp privately
  • Engine SDK
    • Engine Overview
  • ZK Account Abstraction
    • Account Abstraction Overview
    • Getting started with the contracts
    • Wallets
    • State Structure
    • Example Primitives
Powered by GitBook
On this page
  1. ZK Account Abstraction

State Structure

PreviousWalletsNextExample Primitives

Last updated 1 year ago

Core state is maintained using 2 data structures in the contract:

  1. An accumulator, in this case an incremental Merkle Tree.

  2. A nullifier boolean mapping.

These values can be accessed through the , , and variables respectively.

New state objects (UTXOs) are appended to the Merkle Tree and emitted in contract events. Consumed state is invalidated by adding adding the nullifier to the mapping ensuring that old state can't be used twice without compromising privacy.

The contract maintains a mapping of the current and historical Merkle Tree roots so that proofs can be created against the Merkle Tree.

The RAILGUN contract verifies a a set of transaction circuits (JoinSplit with varying input and output UTXO counts) which are the only circuits allowed to write state changes.

External contracts have two primary means of adding functionality on top of the private state:

  1. Using the Merkle Tree + nullifier set to generate read-only proofs.

  2. Using the RAILGUN JoinSplit circuit with the adapt fields to add additional verification to state transitions.

These 2 ways of interacting with the core RAILGUN contracts can be combined to enable a number of use cases. Some examples are contained in the next section.

Commitments
merkleRoot
rootHistory
nullifiers