← Back to home

ZkAlpha

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

Screenshots

ZkAlpha screenshot 1
ZkAlpha screenshot 2
ZkAlpha screenshot 3
ZkAlpha screenshot 4

Problem Statement

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.

Solution

The protocol designWe 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.EngineeringVault (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 datas (secret): to let an anonymous address manipulate the resourcek (nullifier): to mark the status of the resource (transacted/nullified)balancecModel (commitment to a model): to ensure the trade decision is done by the committed modeladdress: to ensure the withdrawal address is the same as the deposit address for legal complianceInterfaceSince 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:transactandfinalizedepositThe relayer receives the resource and inserts the resource node into the treewithdrawThe relayer checks the resource node's balance, returns the resource, and marks the resource nullifiedtransactThe 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.finalizeThe relayer checks the difference between the nodes then nullifies and inserts old and new nodes respectively.We useezklto write circuits. The library allows algebraic circuits to be written in Python (PyTorch modules to.onnxfiles tohalo2circuits, 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.

Hackathon

ETHGlobal Paris

2024

Prizes

  • 🏆

    🧠 1inch — 🥈 Best use of 1inch Contracts

  • 🏆

    🔀 Polygon — Best use of zkEVM

  • 🏆

    🏆 Filecoin — Grand Prize

  • 🏆

    🏊 zkBob — Pool Prize

  • 🏆

    🥉 Neon EVM — Best Use

  • 🏆

    🏊 Neon EVM — Pool Prize

  • 🏆

    🥉 Celo — Best Use

Contributors