Enabling Ethereum-Native Orderbook Exchanges With Novel Zero-Knowledge Construction | Vladimir

[Music] hey guys I'm Vlad from lighter and we're here at e Denver to announce ZK lighter which is uh a new approach we have to uh ethereum Native order book exchanges um with a novel zero knowledge construction so I'm excited to talk you through kind of why this problem is important how we went about solving it some of the architectural decisions you know what some of the applications are and um talk about the work ahead and open it up in case folks have questions um so so just kind of um for some background right um let me kind of start high level so what types of exchanges are there you know the most common type of exchange um across finances is what's called an order book right so in an order book there's competition between all participants retail Market makers high frequency Traders and others kind of anybody could submit or bid at an offer anyone could uh take that bid or offer it's you know it's the most efficient price Discovery mechanism um but this type of exchange works best when you have low costs and low latency so in practice you know in in the crypto world like most of the applications of order books have been centralized kind of until some of the technology that we're going to talk about today but but the order book model is kind of um from a finance perspective from a um market efficiency perspective is the most efficient way to design an exchange some of some other approaches are an RFQ where basically market makers compete to fill orders from retail this one has some good properties but there's less incentives for efficient price Discovery because the market makers aren't trading with each other they're just as long as they win that one order that's all they're trying to do so it's not it's a lot less efficient than a system where anybody could trade with anybody um and of course um the most common one in our space has been an amm which uh is much cheaper to operate um because it's passive Market making but it's also the worst for Price Discovery um and you know an exchange could be used for any kind of marketplace whether it's trading token pairs perpetuals you know could be used for Lending um for bridging options nfts prediction markets or even tokenized stocks so so this is you know this kind of Technology could be used to build many types of marketplaces and so just to give you guys an idea you know I spent before um working on lighter and kind of building in the space I spent a bunch of time doing highfrequency trading at uh Citadel and other places and just to give you guys an idea like the way that what that looks like right I mean there's thousands of orders happening per second usually 100 million orders per day or more and most of the orders are canceled and replaced so there's a lot of activity you know percentage of orders that actually filled is usually around 1% but the reason why all this activity is happening is because market makers are competing with each other for the best prices and as long as anything changes it's uh you know it's to their advantage to quickly update their positions uh and their orders and so this is actually the best possible experience for consumers because it it leads to very low spreads and you have liquidity kind of in any Market environment for any asset um and the most important guarantee for consumers you know if you think about like how do you ensure trust um I mean you know besides the basic ones like asset custody and trade verification the most important one is what we call verifiable matching right which means like can you cryptographically guarantee that uh you know to put it simply you're not screwed over when you send a trade into the market that you're going to get a fill that's at a fair market Price and so as an example amm are verifiable but they don't actually do matching so uh so what happens is cryptographically verified but the price you get may not be the fair market Price you know it's subject to Mev it's subject to sandwich attacks um and so on and so forth centralized or hybrid exchanges do matching but not in a way that's verifiable you know if you send a market order out there you don't really know that it was matched with something at the top of the book and in the priority that you sent it in it could have been matched with something somewhere else in the order book um you might be getting a price that's not the fair price and you wouldn't even know it now this problem you know a lot of people have thought about this the hard part of of it is like how do you do this in a way that has this property but it's also cheap as cheap and fast essentialized exchanges yet has the security of ethereum and that's what we've been um working on figuring out you know with with ZK lighter so basically the solution we came up with is and this is a very general solution like I said it could be used for many types of Market places but it's an application specific ZK rollup with custom ZK snark circuits so um and I'll talk about some of the architecture decisions in in a minute but uh you know what ZK ligher has is a verifiable matching engine that generates succinct proofs uh and this is where the you know the the ZK snarks come in for Price time priority order matching so in other words it's it's guaranteed that when when you in an order the order was matched fairly right and and it has all the other properties you want being scalable secure transparent and non-custodial um so one of the things we um that we introduced as as part of this is a new type of data structure an order book tree data structure which basically it's an it's an it's a tree that stores the bids and offers in the order book in a way that inherits the properties you want from a perfect binary tree and a Merkel tree so it ensures proper price time priority of order execution and because of um the Merkel tree aspects is able to efficiently uh generate proofs of the order matching um so we made a couple of architecture decisions here that were key to um this initial version of ZK lighter so one is uh you know using these building these custom circuits or using a z KVM where you know you could write code in solidity that that operates an order book that's also verifiable but the performance is much much different even I mean the ZK VMS have been making a lot of progress but even in kind of the um state-ofthe-art of of that Tech I mean the performance we can get from Custom circuits is 10,000 times cheaper and 100 times faster and so that that really is the same kind of performance as you'd get from a centralized exchange um another big decision was do we launch this because you know this is an app specific rollup do we launch this as an L2 directly on top of ethereum or as an L3 on top of uh one of the uh existing l2s and we made the decision to launch on top of ZK sync era L2 because we're inheriting um some additional properties there in terms of um you know cheap proof aggregation and the way they handle state so we we're the the this makes the um basically if we weren't doing this it would be only a thousand times cheaper instead of 10,000 times cheaper than a simple solidity implementation so an extra 10x um benefit um another big decision is in terms of data availability right so if you again going back to the point that in when when you have kind of the sufficient Market of high frequency trading you know most orders are not filled most orders are canceled and replaced and so the question is what happens to all that data certainly actual trade need to go need to get posted on the base layer but we made the decision that uh it it would be as long as the proofs that the orders were matched correctly are published like the actual individual orders and cancels can just live on the L3 they don't have to be published um you know in the rollup and this saves a lot of cost as well um finally a decision was made around you know what proving system do we use you know Groth 16 has some challenges around like the first the onetime setup uh having doing the ceremony you know so but once you do that the costs of running it are still about 4X cheaper uh so this decision also is part of what how we get to such um such low cost of performance um there there is that onetime um setup complexity but these circuits you know we're not planning to change them very much so once that happens it's um it'll kind of work from there so in terms of um you know the next steps here right so this week the testnet for ZK lighter will be live and um you know we look forward to seeing what folks build on top of it you know our team is building two products on top of it in the coming months which are which would be for trading spot and perss but uh it could be used for any kind of um decentralized Marketplace kind of the next steps beyond that there's some really big problems to tackle here right so one is decentralizing the sequencer um and you know a lot of rollups are working on this right obviously the l2s and um an app specific rollup like ZK lighter would need eventually to decentralize the sequencer to we're actively working on this next because that's that's kind of the last step here you know the sequencer already has all these nice properties around verifiable matching I think to um to prevent any kind of meth to happen even at the millisecond level um and to introduce things like time lock encryption you know doing that in a way when the sequencers decentralized will be hard problem so if there are folks are working on problems of uh sequence or decentralization you know Mev resistance time lock encryption we'd love to collaborate definitely come find us at the conference um another aspect I mentioned the tradeoff we made around data availability there's a question of you know for you know for future versions does it make sense to have some data availability you know for the market makers or participants who do care about every single order and cancel that occurred like what what should the longer term solution for that look like and how how is that um what you know potentially what would the tokenomics for that data look like as well that's a really interesting problem and then the last one is kind of thinking about for Market participants who are not able to trade basically who love all the properties of the efficiency but you know but the only reason they want to trade on a centralized exchange is because of kcml I mean with a lot of What's um possible with ZK you can also do onchain kcml so you know folks working on that we'd love to speak to as well and collaborate on on that kind of for future versions as well so yeah so those are kind of some of the next steps um any questions come find us um down here our white paper um here's um the link we're we're publishing it now for the first time we've had a couple of um folks review the paper and um it's been um it's been really great to get feedback from the community now now it's published and um definitely email us as well if uh if you're not physically attending the conference and have questions about it we'd love to uh to address those and discuss possible ways to collaborate um that's all we'll be down here to take any questions if you guys have them thank