zkAlpha connects quant traders and liquidity providers w/o revealing the strategy trustlessly through the use of ZKML.

Preprocessing zk-SNARKs allows proving correct executions of a preprocessed circuit without revealing it. This allows parties to grant access to their innovative computation models without revealing them. However, the execution histories of computations can leak information about the computations themselves. Thus, we also use a mixing relayer (similar to Tornado Cash) to reduce information leakage.

Altogether, traders can create a vault corresponding to a committed model (not a verifying key for this hackathon since there are limited projects that provide a recursive-proof solidity verifier). After collecting the funds, they can trade anonymously by interacting with swaps through a mixing relayer. They can only return the funds to the original vault address, which is ensured by our commitment design.

The protocol design

We design the protocol by ourselves. We consider preprocessing zkSNARKs as a circuit commitment scheme and additionally mix the circuit outputs to avoid extraction/distillation of the circuit. It was interesting to work out the details, e.g. the two-step trade (since the trader must be supplying the node), the address commitment for compliance, etc.

Engineering

Vault (solidity, hardhat)

Vault has three modes that indicate its status for LPs and the strategist dictating their ability to deposit, withdraw, and deposit into the relayer. We use the state machine pattern for the implementation. We plan to introduce a slashing mechanism to solve the problem that traders may go offline or conditionally submit model predictions.

Relayer (ezkl, solidity, hardhat)

We use a Merkle tree to handle resource nodes, which are commitments to relevant data. Traders prove ownership of resources by opening the resource nodes in the Merkle tree and opening the resource nodes themselves. They also need to prove the transitions are done correctly.

• A resource node is a commitment to the following data
  • s (secret): to let an anonymous address manipulate the resource
  • k (nullifier): to mark the status of the resource (transacted/nullified)
  • balance
  • cModel (commitment to a model): to ensure the trade decision is done by the committed model
  • address: to ensure the withdrawal address is the same as the deposit address for legal compliance
• Interface
  • Since only the depositor can update the balance by inserting a new resource node and nullifying the traded one, the transaction needs to be split into two operations: transact and finalize
  • deposit
    • The relayer receives the resource and inserts the resource node into the tree
  • withdraw
    • The relayer checks the resource node's balance, returns the resource, and marks the resource nullified
  • transact
    • The relayer checks the resource node's balance, checks the model did the decision, executes the trade, and marks the resource as traded. The trade result is stored and the resource is awaiting finalization.
  • finalize
    • The relayer checks the difference between the nodes then nullifies and inserts old and new nodes respectively.

We use ezkl to write circuits. The library allows algebraic circuits to be written in Python (PyTorch modules to .onnx files to halo2 circuits, with ~20 Einstein summations as basic operations). It also provides a solidity verifier out of the box.

Swap (1inch SDK integration)

We use 1inch to do transactions, which gives a superior trading experience and the best prices.