💻
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
  • Read Only Proofs
  • Conditional Transactions
  1. ZK Account Abstraction

Example Primitives

PreviousState Structure

Last updated 2 years ago

Read Only Proofs

Read only proofs can either take a snapshot of the RAILGUN contract state at a particular point in time by saving the current Merkle root or allow proofs to be generated against the current contract state by checking if the proof is generated against a current or historical Merkle root.

SNARK validation will need to occur within your own smart contract, but you will pull the state data from the RAILGUN core contracts allowing you to prove arbitrary details over the RAILGUN state.

Semaphores

A basic proof of membership can be built on top of the RAILGUN account state with Read Only Proofs. A membership set can be constructed for eg. holders of an NFT within their RAILGUN private balance, or holders of a particular ERC20 token for NFT or token weighted voting.

The basic checks required for this construction are:

  • Proof is generated against a current or historical Merkle root (or the snapshotted Merkle root if snapshots are being used)

  • The UTXO is part of the Merkle Tree and the contents of the UTXO match your application parameters (eg. is an NFT from a certain collection or is a balance of a certain ERC20)

  • The global nullifier hasn't been seen by the RAILGUN contract

  • The application nullifier hasn't been seen by your application contract

Limitations

Snapshots of the nullifier set can't be taken in the current architecture. Spending a UTXO after a snapshot is taken will result in not being able to generate a proof for that UTXO.

For this reason it is preferable to generate proofs against the current state instead of a snapshot where possible. For private NFT voting you can avoid using snapshots by using the NFT ID in the application nullifier to prevent double-voting instead, but in private ERC20 voting snapshots are unavoidable.

Conditional Transactions

Transactions can have additional validation rules attached to them by an external contract enabled by the adapt field. You will need to set 2 values on the transaction proof generated by a RAILGUN wallet to enable this: adaptContract and adaptParams. Setting the adaptContract field locks the transaction to only being valid if the address specified in adaptContract is msg.sender (see ). The adaptParams field is a 32 byte field bound to the SNARK proof but isn't validated by the core RAILGUN contract letting you implement your own validation rules, likely a hash of the contract.

uses a multicall contract that allows arbitrary contract calls to be bound to RAILGUN transactions through this method. You can see how this is implemented .

Atomic Swaps

Conditional payments can be used to implement an atomic swap protocol. You can include the commitment hash for a UTXO in the adaptParams field. Your atomic swap settlement contract will need to accept a bundle of 2 (or more) transactions and validate that the UTXO commitment hash for each transaction is paid into by another transaction in the submitted bundle.

here
Cookbook
here