Protecting whales against censorship and MEV with trustless dark pools  Silur@EthZurich --- ## Agenda - Problem formulation - Prior work, aztec and friends - On dark pools - SEC vs Dark pools - Trust model - Escrow phase - Matching - Settlement - ZkEVM? --- ## The problem - Large token movements create hysteria on markets - "Large" can actually way small on low-liquidity ERC20 token markets - Investors get nagged, even censorsed in ERC20 pools, especially with low TLV/Volume and forced to OTC - Team members cannot exit without panic - MEV --- ## But we already have token privacy solutions - They do allow amazing token wrapping and mixing.... - ...But do not hide the initial "open" transaction - Such privacy contracts are blacklisted, watched, censored - In most cases, private sale phase token investments will require you to use a new wallet. - "Indication of intent" is key --- ## Challenges with fully on-chain privacy - Known contract instances of existing privacy solutions create the same hysteria as plain token movement - Account-based privacy is only possible iff the "kickoff" transaction happens offchain - This is very hard to address with the DEX model --- ## Enter dark pools - In fiat markets, dark pools are exchanges where the orderbook is not public - Identities and order sizes of participants only become visible when they have no market impact anymore... sounds like a commitment protocol :) - Traditionally, the service is trusted as matchmaking correctness is entirely up to the backend - This is also the reason dark pools received a bad reputation, such services did tend to cheat a lot. ---  <small>source: ia.cr/2020/662</small> --- - Formally allowed (and regulated) by "Regulation National Market System", no more tornado-cash style drama - Fiat dark pool data enters the Consolidated Tape, but only as OTC - Easy to start the "kick-off" transaction offchain --- ## Addressing the trust issues with ZK - On traditional markets all control on asset movement happens behind curtains, lots of HFT, price discovery, arbitrage happening - ZK tech allows us to address these trust issues, and create an untrusted dark liquidity pool --- ## Prior works on crypto dark pool DeepOcean https://arxiv.org/pdf/1910.02359.pdf - [X] Accountability of the matchmaking service - [ ] Has no specifics on asset commitment and settlement at all - [ ] Not compatible with DeFi models and decentralized markets --- Rialto - indication of intent with the kickoff balance range proof --- Renegade.fi, Kicking-The-Bucket, ia.cr/2022/923 and other MPC-based solutions - [X] Completely trusless & Decentralized 🎉 - [!] all require a separate p2p messaging layer to operate :( --- ## Proposed Instantiation Threat model: - Operator is honest-but-curious - Operator does not know the exact liquidity of the CLOB - Alice and Bob cannot learn each others order sizes prior settlement - Early aborts induce a reimbrusement - Operator cannot learn neither parties exact order sizes - We operate on 256 bit integers --- ## Main components - Escrow system to reimbruse aborts - CREATE2 fund movements - Yao's "millionaire protocol" - Lindell'17 two-party ecdsa - Collaborative ZK at settlement - ERC4337 account abstraction - ZK as a glue for correctness of each step :) ---  <aside class="notes"> H here is a poseidon hash proof contains that they belong to different groups and their settlement nullifiers are not used up </aside> ---  ---  <aside class="notes"> r_s is a settlement commitment, n_s is it's nullifier code includes an escrow safety flag where etiher side can prove no funds in the address after a timeout to receive all their funds +1 ETH from the endparty </aside> --- ## What about ZkEVM? - assuming a fully compatible ZkEVM, the escrow protocol can be omitted as we can prove balances better. - shift from the current "optimistic abort" protocol to a really preventive trust model --- ## Thanks for your attention  <small>Special thanks to **Tristan Litre** and **Adam Gagol** for useful insights and literature!</small>