ダークプール実装解剖

Renegade — MPC Dark Pool with Collaborative ZK-SNARKs

Repository Architecture

renegade/
├── crates/
│   ├── circuits/           # ZK circuits + colzkSNARK (most important)
│   │   ├── src/
│   │   │   ├── zk_circuits/
│   │   │   │   ├── valid_commitments.rs
│   │   │   │   ├── valid_reblind.rs
│   │   │   │   ├── valid_commitments_match.rs
│   │   │   │   ├── valid_match_settle.rs
│   │   │   │   ├── valid_wallet_create.rs
│   │   │   │   ├── valid_wallet_update.rs
│   │   │   │   └── valid_offline_fee_settlement.rs
│   │   │   └── mpc_circuits/   # collaborative proving
│   ├── workers/            # actor model: MPC handshake / proof gen / matching engine
│   │   ├── handshake_manager/  # relayer-to-relayer MPC coordination
│   │   ├── proof_manager/      # async proof generation
│   │   └── matching_engine/    # order book + match execution
│   ├── state/              # Raft-like cluster state (fail-stop intra-cluster)
│   ├── darkpool-client/    # RPC client to Stylus on-chain contract
│   ├── system-primitives/  # Wallet, Order types (shared off/on-chain)
│   ├── core/               # core business logic + handshake protocols
│   └── api/                # REST + WebSocket API endpoints
└── contracts/              # Arbitrum Stylus (same Rust code → WASM)

7 ZK Circuits (NP Statements)

• 1
  VALID COMMITMENTS

  Proves wallet state is well-formed. Inputs: wallet (private), commitment (public). Ensures balances non-negative, orders well-formed, fee valid.
• 2
  VALID REBLIND

  Re-randomization preserves wallet state. Allows relayer to update nullifiers/commitments without revealing wallet contents. Critical for forward secrecy.
• 3
  VALID COMMITMENTS MATCH

  Proves two wallets' orders are compatible (price overlap, same token pair). Runs collaboratively via MPC — neither party sees the other's wallet.
• 4
  VALID MATCH SETTLE

  Settlement arithmetic is correct: asset balances update consistently, fees deducted, no new money created.
• 5
  VALID WALLET CREATE

  New wallet has valid initial state. Zero balances or deposited balances match on-chain event.
• 6
  VALID WALLET UPDATE

  Wallet update (deposit/withdraw/order placement) is authorized by user's private key and preserves conservation of assets.
• 7
  VALID OFFLINE FEE SETTLEMENT

  Relayer fee payment correct without live on-chain call. Allows async fee settlement in background.

MPC Handshake Flow (Counterparty Matching)

Penumbra — Fully Shielded L1 with Batch Auction DEX

Repository Architecture

penumbra/
├── crates/
│   ├── core/
│   │   ├── component/
│   │   │   ├── shielded-pool/   # ABCI handler for spend/output/notes
│   │   │   ├── dex/             # Batch auction DEX logic
│   │   │   ├── stake/           # Delegation + governance
│   │   │   └── fee/             # Transaction fee handling
│   │   └── crypto/
│   │       ├── decaf377/        # cofactor-clear Edwards curve
│   │       ├── poseidon377/     # Poseidon hash over BLS12-377
│   │       └── pedersen/        # Pedersen commitments (multi-asset)
│   ├── bin/
│   │   ├── pd/                  # Full node binary
│   │   ├── pcli/                # CLI wallet
│   │   └── pclientd/            # View server daemon
│   └── cnidarium-component/     # Custom state framework (replaces Cosmos SDK store)
└── proto/                       # gRPC definitions

7 ZK Circuits

• 1
  Spend

  Note existence + Merkle inclusion proof + nullifier consistency. Core privacy primitive — equivalent to Zcash Sapling Spend.
• 2
  Output

  New commitment + balance preservation. Creates a new private note from a spend.
• 3
  Swap

  DEX order submission with hidden amounts. Commits to trading pair and reserves without revealing trade size or direction to validators.
• 4
  SwapClaim

  Receive output tokens after batch match. Proves you submitted a valid swap and claims the correct output at the batch clearing price.
• 5
  DelegatorVote

  Governance anti-double-vote. Delegates can vote without revealing stake size. Nullifier prevents double-voting.
• 6
  UndelegateClaim

  Staking exit. Claims unbonded tokens after unbonding period. Proves delegation was valid and unbonding period elapsed.
• 7
  Nullifier Derivation

  Deterministic nullifier from spend key + note commitment. Prevents double-spend without revealing which note was spent.

Batch Auction DEX Design (FBA-Style)

Multi-Asset Privacy

Penumbra uses separate Pedersen generators per asset. Each asset type has its own generator point on decaf377. This prevents cross-asset correlation attacks while allowing homomorphic balance checks.

// Commitment to amount v of asset a:
// C = v * G_a + r * H
// where G_a is asset-specific generator, H is blinding generator
// Different assets use different G_a — cannot aggregate across assets

Privacy Pools / RAILGUN / ZKBob — Compliance-Oriented Codebases

Privacy Pools / 0xbow

privacy-pools-core/
├── packages/
│   ├── circuits/    # Circom 2.x + snarkjs setup artifacts
│   │   ├── withdraw.circom
│   │   └── ptau/   # Groth16 trusted setup files
│   ├── contracts/   # Solidity
│   │   ├── Entrypoint.sol      # deposit/withdraw router
│   │   ├── PrivacyPool.sol     # per-asset shielded pool
│   │   ├── State.sol           # commitment Merkle tree
│   │   ├── ASPManager.sol      # manages ASP roots
│   │   └── Verifier.sol        # Groth16 on-chain verifier
│   ├── relayer/     # minimal gasless relayer
│   └── sdk/         # TypeScript (dapp integration)

state_tree = MerkleTree(
  all deposit commitments  // full set
)
asp_tree = MerkleTree(
  approved-only commitments // curated subset
)

// Withdrawal proof requires inclusion in BOTH:
withdrawal_proof {
  private: note, secret, path_in_state_tree, path_in_asp_tree
  public:  state_root, asp_root, nullifier
}

// Semantics:
// "I am SOMEONE in the clean subset"
// (NOT who exactly — subset membership, not identity)

RAILGUN

// [1-10 inputs] × [1-10 outputs] = 100 combinations
// But only valid: inputs ≥ 1, outputs ≥ 1 → 54 circuits
// Each circuit is pre-compiled + trusted-setup'd
// Allows gas-optimal proof for exact tx shape

// Example:
circuit_1_1.zkey   // 1 input, 1 output
circuit_2_3.zkey   // 2 inputs, 3 outputs
// ...
circuit_10_1.zkey  // 10 inputs, 1 output

// Public inputs:
txidMerkleRoot         // full Tx Merkle Tree root
blocklistTxidMerkleRoot // blacklist Tx root
blindedCommitment       // hidden commitment

// Circuit proves:
// 1. My Tx IS in the full tree (I am valid user)
// 2. My Tx is NOT in the blacklist tree (I am clean)

// Key: prover does NOT reveal which Tx is theirs
// Semantics: "I can prove I'm not on the blacklist"
// without revealing what I did

Private DeFi Cookbook (Railgun-Community/cookbook)

Pre-built recipes for using any DeFi protocol privately via RAILGUN. Gas paid by Broadcaster (relayer) via RAILGUN internal tokens.

// Example: private Uniswap V3 swap
const recipe = new UniswapV3SwapRecipe(
  tokenIn, tokenOut, amount,
  slippage, deadline
);
const shieldedTx = await railgun.generateShieldedTransaction(recipe);
// → Broadcaster pays gas, receives tip in RAILGUN tokens
// → No on-chain link between user's wallet and UniswapV3 call

ZKBob

// Every Note includes DUAL encryption:
Note = {
  amount:       encrypted_to_recipient_key,
  audit_log:    encrypted_to_pk_cm,  // ← audit trail
  nullifier:    ...,
  commitment:   ...
}

// Flow:
// Regulator subpoenas exchange
// Exchange → CM → decrypts audit_log for specific Notes
// → reveals specific tx details for that user
// Key: CM can decrypt ALL tx but is trusted not to do so

// ZKBob: 1 universal circuit handles all tx types
// vs RAILGUN: 54 specialized circuits

// Universal circuit inputs:
{
  type: deposit | transfer | withdrawal,
  inputs: Note[],     // max configurable
  outputs: Note[],    // max configurable
  fee: amount,
  cm_audit_log: ...,  // always included
}
// Simpler audit, higher circuit complexity

反構造化コントロール

ZKBob enforces withdrawal limits per period on-chain to prevent structuring (breaking large amounts into small transactions to evade detection). This is a circuit-level constraint, not just policy.

Compliance Mechanism Comparison

Aztec 3 — プログラム可能なプライベートスマートコントラクト L2

Private Kernel Circuit — 5 Phases

Every private transaction runs through this pipeline on the user's device (PXE). Each phase is a separate proof, recursively accumulated.

Gate Counts (Typical 2-Private-Call TX)

Noir Language — Writing Private Contracts

// Noir: Rust-like DSL for ZK circuits
// Used for: application contracts, protocol circuits, standalone ZK programs

// Example: private order struct in Noir
struct PrivateOrder {
    amount:     u64,          // private
    price:      u64,          // private
    direction:  bool,         // private (true=buy)
    commitment: Field,        // public output
    nullifier:  Field,        // public output (when consumed)
}

// Private function (runs in PXE, no sequencer visibility)
#[aztec(private)]
fn submit_order(
    order: PrivateOrder,
    context: &mut PrivateContext
) -> Field {
    // Hash order to commitment
    let commitment = pedersen_hash([order.amount, order.price, order.direction]);
    // Emit note to private state
    context.emit_note(OrderNote { commitment, owner: context.msg_sender() });
    commitment
}

// Public matching function (sequencer executes, visible on-chain)
#[aztec(public)]
fn match_orders(
    buyer_nullifier: Field,
    seller_nullifier: Field,
    clearing_price: u64,
) {
    // Verify nullifiers not already used
    assert(!storage.nullifiers.contains(buyer_nullifier));
    assert(!storage.nullifiers.contains(seller_nullifier));
    // ... settlement logic
}

自前ダークプールの構築 — 実装ガイド

Key Decision Flowchart

Recommended Stack by Goal

Step-by-Step Implementation Guide

Phase 1: Define Adversary Model (Week 1-2)

Phase 2: Choose Matching Mechanism (Week 2-3)

Phase 3: Circuit Development (Month 1-4)

# Minimum viable circuit set for a dark pool:

1. DEPOSIT CIRCUIT
   Input:  amount (private), asset (public), nonce (private)
   Output: commitment (public), nullifier_key (private)
   Proves: commitment = hash(amount, asset, nonce)

2. ORDER CIRCUIT (submit)
   Input:  price, size, direction (all private), wallet_commitment (public)
   Output: order_commitment (public), order_nullifier_hint (private)
   Proves: wallet has sufficient balance for order; order params valid

3. MATCH CIRCUIT (collaborative, run via MPC)
   Input:  buyer_order (private-shared), seller_order (private-shared)
   Output: match_exists (public), clearing_price (public if FBA)
   Proves: orders overlap (price_buy >= price_sell, same asset pair)

4. SETTLE CIRCUIT
   Input:  match_proof, buyer_wallet, seller_wallet (all private)
   Output: new_buyer_commitment, new_seller_commitment (public)
           buyer_nullifier, seller_nullifier (public)
   Proves: balances updated correctly, conservation holds

5. WITHDRAW CIRCUIT
   Input:  note (private), nullifier_key (private)
   Output: nullifier (public), amount (public)
   Proves: note valid, not previously spent

# Timeline estimate:
# - Groth16 + Circom: 2-3 months (simpler tooling, less expressive)
# - PLONK + Rust:     3-5 months (more expressive, heavier)
# - Noir + UltraHONK: 2-4 months (easiest DX if using Aztec)

Phase 4: MPC Layer (Month 3-5, if needed)

# For MPC-based matching (Renegade pattern):

# Option A: Use mpc-stark (Renegade's fork)
git clone https://github.com/renegade-fi/mpc-stark
# Implements: SPDZ preprocessing, Beaver triples, authenticated shares
# Interface: MpcFabric::new() → share values → compute circuits jointly

# Option B: MP-SPDZ (academic reference)
git clone https://github.com/data61/MP-SPDZ
# Full SPDZ, MASCOT, LOWGEAR protocols
# More protocols but heavier — good for research

# Minimum MPC design for dark pool:
# - Preprocessing phase: generate Beaver triples offline
# - Online phase: share order values, compute match predicate jointly
# - Output: both parties learn match result (and proof) but not each other's order

Phase 5: Trusted Setup (Groth16 only)

# snarkjs ceremony workflow:
# Phase 1 (powers of tau — universal):
snarkjs powersoftau new bn128 20 pot20_0000.ptau
snarkjs powersoftau contribute pot20_0000.ptau pot20_0001.ptau --name="contributor1"
# ... repeat with many contributors
snarkjs powersoftau prepare phase2 pot20_final.ptau pot20_final_pp.ptau

# Phase 2 (circuit-specific):
snarkjs groth16 setup order_circuit.r1cs pot20_final_pp.ptau order_0000.zkey
snarkjs zkey contribute order_0000.zkey order_0001.zkey --name="contributor1"
snarkjs zkey beacon order_0001.zkey order_final.zkey [beacon_hash] 10
snarkjs zkey export verificationkey order_final.zkey verification_key.json

# Export Solidity verifier:
snarkjs zkey export solidityverifier order_final.zkey verifier.sol

Phase 6: Security Audit Checklist

Phase 7: Launch Strategy

Gas Cost Benchmarks (Reference)