ZK9: Building a trustless dark pool using ZK - Silur
14 Apr 2023 · 25:35
Independent researcher Silur presents a design for a trustless dark pool built with zero-knowledge proofs at ZK Summit 9 in Lisbon. The talk proposes a non-AMM decentralized exchange modeled on classical dark pools, argues why that approach became more attractive after the Tornado Cash sanctions, and walks through a trustless implementation combining several different ZK protocols.
Speakers
Topics
Transcript
foreign [Music] okay hi everyone thanks for the kind invitation for this talk I brought you something of a personal pain point in my work as an independent researcher and developer I research at the wig nurse Institute of physics mainly Quantum Computing and post Quantum cryptography but this one the originating idea comes as my from my work as an independent developer namely um private investor privacy that's non-existent on on chain especially so for the agenda I'll formally like present the problem that I encountered
way sadly often in the industry how prior work has been trying to address their problem why I think that didn't really work out the way it was supposed to then go a little deeper into the Fiat world where I brought the original idea from so how dark pools work for like decades in the Fiat bird and how I generalize the original idea gluing together the components with zero knowledge cryptography so the main problem that I personally encountered this disappointingly many times is that private investors in token sales are super exposed either because
the liquidity is so small that if you raise funds with the friends family and fools model basically everyone from the tokens team can call you when you are selling your tokens or if if the project is the other way around and it has super good liquidity PR and coverage in the industry then basically Bots are viewing you just like every time vitalik moves either on chain back Shield alert goes up and on Twitter and everybody knows that someone's exiting this and that token and it creates history on the market like you can't really complete your order even on a decks you can't complete your original order on the price you started it
because either you are an exposed person onto the project you are a developer who just want to exit or an investor or a super large liquidity person there so investors get exposed and enact personally or just on Twitter and I think that's not really an ethical stuff to do in the industry and of course there is still the threat of minor extract table value attacks front running sandwiching when such thing happens and we already have token privacy Solutions right Aztec protocol ZK sync but the problem there I encountered is that in threat modeling it's the same so
if someone asked me and it did happen that hey is this person doing ZK sync or doing Aztec protocol wrapping because he wants to exit and you can check it really easily either just go on either scan yeah it's the wrapping contract if you want to wrap to zero knowledge transaction It's that or if it's not the the flagged one that's on ether's kind of someone deployed their own version of tornado cache or the casing for the Privacy solution you can still check by the code that hey the main investor is sending funds to a contract that has code that's seemingly similar to some privacy solution so it's still a red flag it's not uniform like you are interacting with the contract that's
supposed to bring some privacy it's the same issue back Shield will just change the code and they will look for such interest on chain so how I personally formalized is that the kickoff transaction where you make the initial commitment that from here I'm trying to sell my tokens or interact with the chain in a way that I'm trying to hide my privacy the very first transaction either has to happen on chain or has to be the last otherwise you are exposed to to the environment for uh for Market history this way so enter dark pools in traditional Fiat
markets it's like an age-old a decade old technology it's basically a central limit order book where the actual order book is Secret but only from you identities of people who provide liquidity to the other book are eventually revealed so it's not money laundering where it's hidden forever but they are only revealed when it's it has no Market impact anymore so you can't front run it you can't go hysteria mode when you see that Goldman Sachs is dumping a huge amount of stocks when the deal is closed with the order price or the limit price they negotiated with the counterparty so it's an OTC trade kind
of it enters the Consolidated tape as an OTC trade but it has an order book and traditionally this service is a trusted matchmaking service because someone has to see the order books so it can order it and connect you with your OTC Peer who can fulfill your order and this is the reason that traditional dark pools has bad reputation because [Music] if the if only they can see an order book which supposedly have super large liquidity investors with huge movements of funds or exposed people if they can do price Discovery it's an Arbitrage gold mine for them and they did exploit
this so uh in in traditional dark pools they did collaborate with each other so different dark pools to do price Discovery and go ahead of the market because they knew that the super large players the whales are sending on their dark pool and this is one of the reasons that most we also Goldman sucks GP Morgan they all have their own dark pose so they can do the price Discovery for themselves this way but thankfully this is a problem that we can solve with zero knowledge technology and why the traditional darkable model is especially important right now post tornado cashier because it's formally
regulated so the U.S government formally allows operating dark pools as long I think the last amendment was in 2016 to the regulation National Market System which says that as long as dark pool liquidity does not exceed six percent of US GDP then it's totally fine to do trades with Secret order books as long as it um as long as it enters the Consolidated tape of course after the trade so how ZK will or how I tried to glue this together with CK is because the
The Trusted operator is a central server and can do high frequency trading price Discovery and stuff we can glue together all the straw all the components that are prone to distrust between the parties using a combination of blockchain and ZK here and the protocol there has been to best of my knowledge to trials to build dark pools on blockchain using zero knowledge one is deep ocean which I favor more than the other one it has it's more of an optimistic protocol than a prevention based Decay so it's it's more about the accountability of the service it's it's
still trusted or like it's still centralized but untrusted anybody can be the trusted dealer and it has full accountability so if some price Discovery happens or some cheating happens then with zero knowledge you can actually point to the matchmaking service that it has been cheating the problem with that why I brought the idea uh forward is that it has no sorry my money thanks so it has no specifics how do you handle the settlement with your connected peer which is kind of the critical part because okay from the trusted Services point of view you just have to prove that yeah I made the the matchmaking
correctly hand over the protocol to the two peers and then what one of the two wallets have to transact first and we just talked that in the threat model the first transaction either is the last or something happens of chain so you can't really interact with a contract or something prior exposing your identity the other one that I actually just recently got knowledge of is a renegade Finance they did a really good fundraising recently they are completely trustless and decentralized with ZK their paper is amazing I really advise anyone to read it but the problem I encountered there is
not cryptographical or in the threat model it's an engineering issue that it needs its own peer-to-peer messaging layer on quick to operate which security wise is not a problem but if you are building something like it's already way too hard to get people to use ethereum with its own peer-to-peer messaging layer and stuff and if you are about to maintain your own which has actually nothing to do with your product or project or open source research appear to Pure messaging layer is a product on its own so it's enormous amount of work to maintain and it just shifts Focus from all that so what I
made is kind of the combination of the two I called it log text it's still an optimistic protocol so all matchmaking sir anyone can enter as a matchmaking service it's fully accountable and doesn't need the its own messaging layer the threat model I formalized is that the matchmaking service is honest but curious so it tries to get into look into the hidden order book because it wants to do high frequency trading or arbitrary trading with uh with his peers thus it cannot know the exact liquidity in the central limit order book only which side has more liquidity this is
the only information I allowed in the model to leak into the order book neither any party can learn each other's or their sizes prior a settlement protocol that you can't back out or if you back out you have to reimburse the other party with more funds that is in the trace so far so we are game theoretically really desensitive incentivized to abort the protocol here so the main components I used for this is because you have to reimburse the other party if you about the protocol is an escort system
then to avoid on-chain movements from the main account which leaks your identity I used the creatitude deployment version so you basically pre-fund a non-existent address on chain with your funds you commit with your main identity I'll show in detail the protocol this is just a high level so you commit to your original identity then fund a non-existent address on chain with the funds that you want to exchange and then deploy the create to contract on top of it which handles all the settlement the two parties will negotiate between themselves the order size is using Yahoo's millionaire protocol and they create the settlement contract using Linda's two-party ecdsa
with a public key that nobody knows the private key to and to hide the the which side originates the transaction I used the newly merged account abstraction model in ethereum and of course in each step between each step I use various zero knowledge Technologies I'm so far for them VP I'm using Halo 2 for every step to prove correctness so the escrow logic first we commit to our main identities with a Randomness that also has a nullifier because we have to ensure that at the end of the protocol you can't settle an order twice so you commit to your
original identity with a completely new wallet so it's not your main one that has the enormous amounts of tokens that you want to exit you commit one ether uh and register of chain maybe using some of our protocol originally I use semaphore for this but it was too much because all of its Anonymous messaging layer used way more cryptographic technology than that I actually used here because for me a simple set membership proof is sufficient so you register with your commitment to your original account using a set membership protocol Mercury or a hash accumulator
I will prefer in my nvp hash accumulator because that way I can remove participants from an order book in constant time and constant size proofs and I don't have to leak log n participants from the order book to Pro membership then the pool runs a fifo matchmaking algorithm so first in first out it turns out and maybe this will result in an impossibility result I'm still not there that Pro rata matchmaking will not work with this dark pool because for pro rata you have to see the order book because you match People based on their order sizes so I either do randomized or very traditional fifo matchmaking
when I'm doing the FIFA matchmaking I'm basically just comparing two different groups so Alice registered on the seller group she gets a set membership identifier and the nullifier that you belong to Ether sell and Bob is belonging to either buy groups the matchmaking system goes through in order M that okay I matched two parties from opposing sides acts as a turn server so they connect through Weber's webrtc the pool access storage server connects Alice and Bob and sends the proof that hey here is the proof of membership of
your other side of the liquidity pool or the order book pool that I matched you with they both verify this proof then they share Randomness with each other that they prior committed to because they have to check that does the other party completed the ask robot protocol so if they back out when I'm already committed my identity can I pull out my one ether punishment from them so hence they exchange Randomness and checked whether desk or Chrome tract has the sufficient sufficient penalty committed then so this was just the escrow Logic the matchmaking logic is much simpler part of it was on the previous six phase
diagram so fifo matchmaking runs the pool sends membership proofs to each party that they that it matched together and the two parties between themselves run the Yahoo's millionaire multi-party compilitation protocol to check who has the larger order size but still no amounts yet so who's the winner Alice wins here which means that now we can switch to our main wallets from the scroll ones so far all communication has a trace that hey I verified this proof I got matchmaked to Bob from the protocol they both signed the whole Trace so they have
to commit to the communication Trace so far using Windows two-party cdsa protocol and during the protocol so if you remember just before the last step when you do something very similar to ecdh you have the two partial public Keys you also have to commit to those because this is what's gonna be used later to connect this signature to the original identity and you do a collaborative zero knowledge proof that you did all this lindel's signature multiple signature correctly because that's also uh that's also a step that I
have to hide your identity with the signature so you can't sign with your main wallet on chain thus it can't leak your public key but I have to ensure that you have your liquidity uh to send the funds and you committed to it before hence we need a collaborative ZK proof It's a combination of multi-party computation and zero knowledge proof when the two parties generate the proof together approved together that neither of them can do alone and then they extract this lindel public key for which they don't really know the private key too because it's a multi-party wallet they extract the
public key and pre-fund it with the funds both of them using the create to protocol so you just send it to the hash on chain and you see here that Alice is making the first transaction but so far it's not really a privacy issue because what's visible on chain is that Alice is moving funds to another externally owned accounts so this address so far has no contract code or anything it's just a random address so far and when Bob sends the next transaction that's the first part when you can kind of put together that okay this is gonna be a next escrowed protocol or some kind of exchange because it's clear that it's not neither of the participants wallets
but by this time you can't back out from the protocol because you made the escrow and you proved correctness of all the signatures prior then you share the commitment proofs if you did prior the nullifiers the pool either either the pool acts as a account abstraction delegator or relayer yeah relayer is the terminology or you can introduce and send a user action to any other account attraction relayer is I just thought it's super convenient for the pool to act like it because it's gonna be fast so the pool verifies the membership proves whether the nullifier
is used up or not and then deploys the settlement contract to the already funded address which has both sides of the tokens matched made committed to and covered by an escrow then either the pool or anyone else commits the settlement contract which has either that hey someone aborted or proof is not correct give me by reimbursement or give the other sides funds that they committed into the dark pool protocol then the contract also verifies these weather commitment and the nullifier is complete not used up and the dark pool protocol is done this way and you see that until Bob made the
the transaction to the second one it's still not clearly clear whether um dark pooling is happening here but by that time nobody can back out from the protocol and I thought I really need just one slide on ZK AVM because I finalized the slide at the launch there the biggest problem in my protocol so far is the connection between the main wallet and the settlement protocol is still not very complete so I tried to cover it with the escrow protocol and the various proofs and Lindo but still it's uh not really complete whether the initiating wallet
has the funds to complete the dark pool protocol because we can't leak the initial wallet but with ZK evm that's not really gonna have a or that's not gonna be a problem and in the future I'll dedicate an experiment to implement the whole and modify the whole protocol on top of ZK ABS because that way I can even check the balance of an address that I committed to Prior so I can prove that uh a hidden wallet that I committed to hear has enough balance to solve something and that that would be the the killer application uh on top of renegade Finance but so far all these Works kind
of gets efficiently on normal evm without ZK evm and leaks much less than zksync and friends so far okay my closing side is seemingly missing from the from the offline version so okay thank you for your kind attention I'll be around for your questions [Applause] [Music] okay
second person to win some when the second person liked the loser you mean but there are two commitments so first for the escrow and for for a second for the settlement which one are you referring for the settlement yeah because that's simply because they have to exchange fund funds so both of them have to commit funds to the protocol that time contracts uh both of them
separate addresses that can work but then because creatity also has the address of the deployer so it's the hash of the deployer your random salt and then the code and okay you get so it has to be a known deployer address otherwise you don't know where to search for the other party's contract without another proof I'd say problems because if you don't do kyc uh so the legal issue is the main question here at the beginning I told I so
basically consider the legal questions solved by pointing to the ACT from 2016 that Scott demanded that hey dark pools are totally legal so if you want to close me because my only laundering issues or privacy issues how come Goldman Sachs is operating a dark pool and dozens and dozens of companies are operating Fiat dark pools it's still 6 percent under U.S GDP so I don't know whether that's a satisfying answer for lawyers or for you but I do consider personally so that hey it's completely legal tornado case was yeah really risky because you can wrap it on their money laundering it was not but
still you legitly can label it as such but dark pools legally formally are not illegal so if I made the dark pool on chain why would it be any different um we got to get to the break we ran a little bit over on the last talk but let's give our speaker a hand and uh [Applause]