Intro to Loopring's zkSNARK based DEX protocol

all right thanks for coming my name is Daniel Wong I'm the founder and CEO of loop ring so today I'm going to talk about loop rinse report always use user zero knowledge proof to scale so scalability is something we want you to achieve but not privacy okay so salubrious project that started back in August 2017 so we focus on one thing and one thing only which is author based tax protocol so over the last year and a half we have deployed three major versions of the protocol on top of aetherium we introduced some cool features including you know ring matching to your authoring to prevent front-running and some like very cool fee models unfortunately you know the product is not a widely adopted so we asked us ourself why was it was amazing in the current implementation so I think it's really boils down like three issues so right now the the user experience it's not good it's not easy fix right and one of those issues in this area is the treating the finality so for market makers they really want to see their their settlements got finalized as soon as possible so that they can you know start submitting new orders but right now only three really have to wait for like 60 15 seconds also to make sure the the settlement is built into the blocks but sometimes it takes really even longer array and ii ii ii ii one and the third one is even a bigger problem right so this rule is so low the gas cost is so high okay i'm going to show you some numbers so our ago in 3.0 is to make sure we achieve the followings so the settlement should be finalized as soon as possible this this finality is not actually the block-level approaching level finality it should be like centralized exchange level finality so it can be reverted but he's not you are fairly certain that the settlement is it's done and then we want to achieve higher throughput lower cost and then there's no shouldn't have any trade-off in security so we don't want to use side chains you know other cool stuff to achieve throughput by sacrificing security all right so with the previous versions this is the number right so we can put about 26 settlements in one ichiran block so you can do the math right right now it's like less than two trades per second and the ether midnight I think this is true even for our competitors right more or less the cost is even a bigger problem right here so it depends on the price of ether is is you know the price the cost is probably 10 to 20 cents right imagine we have we have the police market you know the cost is about 3 or even more 20 or even more so with lupins 3.0 we really have two options first is called with data availability so what what does what does that mean so with unction data will ability means you know any third party can depends on the human blockchain can reconstruct the state of the tags for any given moment in history so you don't really have to trust anyone right you can because you can reconstruct the state which is basically the Merkle tree then you have the way to generate merkel proof we'll be used by anyone to claim the I sat in the tax so with auction date availability we managed to put 1,800 settlement in one theorem block so this means like 120 trees per second okay and then the cost for gas is less than 0.2 to US cents this is assume that the price is 190 right now it's a little bit higher right but it's not compared to 13 cents is it's nothing right the other one is you know we turn off the unction did have availability so we found another tax operators they can find another option to provide the data for example the fund the auditing firm say okay we are going to publish data on a daily basis or you know put a PFA is something like that so there are some risks right for for normal users it's possible that they don't have access to the data in real time and sometimes you know if the tax operator do not really honor their promise maybe user will not have access to the data at all but if we turn this off you know we can put like seven thousand transactions or settlements in one easy room block so this is the carbonyl result so the the cost is even lower right unless gently it's about 0.05 percent and there are now often costs so previously we when we do a 1.

0 2.0 we put everything unchanged so blueprint protocol is basically a side of a smart contracts now we have option parts right we have the co2 maintained often Merkle tree and to most like I think most importantly we have some program called prover that has to generate zero knowledge proof so we tried Amazon AWS with this 48 cords a young processor with a lot of memories so for a virtual block that has 512 trees it takes less than an hour to generate so the price is $6 per hour if we use some cloud service in China in this price is going to be like half right it lacks $3 per hour right now with AWS the price or the cost to generate the proof for each settlement is is less than zero point nine cent right this is irrelevant it has nothing to do with the ether cost it's just purely the cloud service cost so if we combine those numbers together we get a foot final throughput and cost right so is one or twenty four with that availability one cent and this to attend dinner will be off for fifteen and still less than one cent I think it's pretty good number I mean especially with date availability that means the protocol is as secure as the theorem itself right there's no trade-off in in security at all and if we find a trustworthy big name to support a tax by in auditing the data availability option we can you know achieve even higher throughput so we we have pretty excited about this okay so this is the design so the idea is really simple very similar to TK roll-up so basically you you move out most of the data often most of the computations option into a into a Merkle tree a single Merkle tree so that the more country has reversed if the top part is the account so you have multiple accounts as the leaf and this is account you have multiple tokens and it's token you have multiple others right so this is a single sparse Merkle tree that you have to update option right by updating option I mean you know you have to take care of those requests from either on chain or option for is request you do the calculation to make sure you know the is it the root is it eventually updated so right so right now the Lucas 3.0 supports the following six different types of requests but actually we simply need to support these three to make the tags fully functional so so the the option with Java order cancellation and transfer really optional so the way we we handle those requests is to pass those requests together into a block so this is like virtual block it's not the block of the etherium so those virtual block cut process as a batch to to update Merkle tree and after this block we have a new merkel root for the block it's the post processing recruit reroute we we then submit this route which is 32 bytes unchanged so that's the only data well with some metadata but this is the the major part of the data that need to be submitted unction so the computation is almost zero and we just need to pay the guys for those 32 bytes not basic sorry 32 parts and then option when we update after we process the requests update the Merkle tree we get you know a better sense of how we did how we updated those Merkle trees so those data are going to be formatted into something we call receipts and use those receipts we run the approver to to generate the final proof okay and then we submit a proof so I'm going to talk about the proof verification later but you know when we passed those requests there are really two ways to do that and the first way is to to you know prove those different type of requests into blocks so those like virtual blocks right it's not the easier block it's the our tax brach so so you you you pass those requests based on the time they come and then you process but this is it turns out to be really bad because we learned the circuit the the zero knowledge proof free little computation it really not good at handling the dynamic numbers of requests sorry it's not really good at handling like different types of requests because that will make the circuit really big and the proving time is like multiple times than it should be so this is terrible this and we tried the actually this is what we did right as a final result so we actually pass requests at the same time together same type a type together so that the circuit you know to to handle this type request has nothing to do with the logics that has the other type will require so by doing this at the time to generate the proof is minimized so we can in fact if I could be reduced the proving cost so this is the way we which shows okay and the second point is that circuit is not really good at traveling the dynamic arrays so we have to only provide a fixed size of different blocks for let's say for this settlement right so we can put like really two requests in one block or six eight well you cannot put a you know random number as a block here so requesting one block if if we don't have let's say let's say we have only 120 requests then you have to zero pad like eight default requests there to make 128 so the circuit will will iterate 128 times it cannot iterate dynamic number of times right so this is some restriction of the circuit I don't know whether this is going to be like a solution to fix this if we have a solution then you know we have one one single type of block right now for this type we have different sizes right alright so as I said you know it turns out for East tax now we have a virtual blockchain on top of a theory on midnight so we as I said we don't use like set change so these are actually III reom the data for each block so is certainly too bad with some methods are very small so you don't know how many how many by looking at the toast number you don't know how many requests are included into this block because no matter the number regardless of the number of requests this size is fixed it's very very small right so in theory we can even put like more requests in a block but there are some restrictions in etherium that don't support and many a very large batch of requests so this is only data very very small so if we turn on the data availability for option settlement it's green block you have to provide extra data to make sure everyone can use these data to reconstruct the marquetry right for function deposit we drove out you don't have to do that because each function already so the data is available on chain so only obtain requests needs to provide like accurate data for data availability and this is really has has something to do with the the number of requests so the the more you have the more requests you have the more data you need to put on chain all right so when the block has been submitted after box on material you can run the word at approver once approval is ready you can submit a proof to a block and the proof is going to be worried if I don't chain using the word by a verification key so once the proof is verified this block is going to be that the status is changed from committed to verify it okay and if if a block is verified and all the previous block has been verified then the block becomes finalized so finalized means this block cannot be reverted at all so it's final it's truly final this like boxing level final so previously I said that we want to achieve the settlement finality right like instead is tenuous with finality but that finality is like still can be reverted it's like centralized exchange level finality but here if we once we got a block finalized is finalized so it also means if let's say this is the that we travel right if the Huichol block is finalized that means people can actually take money from the small contract all right this is like finalized ok so what we can learn from this so we can always commit blocks in sequence right one by one but the the proof itself can be submitted auto powder you can submit a lot that you can submit proof for him and then for him and for him so it's indifferent can be in different orders that means you know generating the proof can be paralleled because it takes like hours sometimes right to generate the proof using like not that powerful PC so if you can parallel the approved any reason you can use in their best to do lot of work in same time so this is very very important for us to really truly scale the tags otherwise you know the unction part is good if the option party is not scalable then it's not fully scalable right so so this is what we have done and then we also applied some delay the max delay between a proof submission and approve era fication I'm sorry the blocks image and the proof of occasion so there's like a minimum maximum like two hours I cannot remember the exact number but is during that time if you after like two hour if you still don't have a valid proof submitted for a block then you can't penalize the the tax operator got Paulist sorry and their stake may be partially or even fully burnt we also want to enforce the tax operator to handle the ancient deposit and withdrawal requests because that's really important for user to be able to deposit and then you know their their balance it's got updated in time you know timely manner right and the four wheels over if you something withdrawal requests you'd certainly want to get money out of the tax in a timely manner so we end up having like two very small like it's like unchained deposit which I was Sachin it's not really the section but it's kind of like that so they are hashed so that they linked together to make sure you know later when we process those events you know it's the data modification really minimal so actually in general we also applied Mac's request age so if a request is summit unchain and you don't the tax operator don't really handle this request in you know within this time the tax operator is going to be punished so so there's a time limit to avoid sable attack we also have applied another restriction for the number of pending unchain requests so you cannot that's a user cannot submit action request if there are already is too many requests otherwise one a bad thing may happen is that you know a lot of users submit a lot of very small tiny untrained requests and the tax operator don't help them to to the settlement all you need to do is to handle action requests because there's a punishment if they don't do that right so this is to avoid the that kind of attack okay so if something bad happens if the tax operators don't really fulfill their duty by processing requests or they submit some bad data unchain which is not valid verifiable then the tax will go to a which oval mode with basically say you know tells the tax you you are broke you cease operation you have to return all the money back with your users before you can get all the stake back right if the tax operator don't really care about the stakes they will do nothing and after a certain amount of time anyone can you know because we have data availability I'm sure anyone can reconstruct the Merkle tree and then by providing the merkel route you can also get your money back right so in the future we are going to sponsor someone to to build it rule 2 to reconstruct the marquetry based on the ancient date availability to help users to get their money back if the tax operator is not it's doing something something evil okay we also introduced a maintenance mode because we have so many different type of restrictions to to force the decorator tax operator to process user events in a timely manner if the you know text operator want to upgrade their back-end you know they will say hey I need to stop right so this mode is just for for text operators to do something to maintain their back-end to stop to stop operation for a certain amount of time so the so the tax operator can like buy the maintenance time so it's not free so the longer your your operation is stopped the longer - more your how to pay so so I think this is very necessary for fotox operators because they need time to upgrade their systems so in general a loop ring 3.0 he has inherits a lot of cool features that I haven't even talked about from our previous versions like the other aliasing like front row and different running partial order matching service there are a lot of cool stuff we also introduced a treating treating key so that means you order don't really need to be signed with your private key your your ethan practice privacy key so once you create a tax account on some exchange when you do trading you can just give your treating key to your whoever me is managing your account right you don't have to give them the the private key of the etherium account right now we are I would say this is now still not productive ready a lot of things can change can be optimized so with zero knowledge proof especially G key snarks we need a trusted set up right this is this is not good right so hopefully we don't need to do the trusted setup so Saxo sonic so in the future maybe we can just share a trust set up among all the taxes on aetherium right now we have to verify every single proof for for each block which cost half-million gasps right it's pretty expensive so maybe we can you know generate Starks for Starks to make any recursive so we can probably only run the verifier function for every maybe every thousand blocks to reduce the gas and the other one with also what we're looking forward is the cheaper like storage on blockchain as wheat Alec has acknowledged that right now the story's price is it's too high right we can you know hopefully the thermal will reduce the cost so we can put even more settlements in one block I think the most possible optimization is like GPU enabled Premiere Pro alcohol rice if we make it run on GPU then it's going to be a lot more cost-effective so a lot of things that can can be done on top of 3.0 so right now we are making the 3.

0 code really production-ready I think we are still not ready to compete with like finance like the top-tier sexiest right but to compete us with small ones or even the mid-sized ones I think I'm pretty confident because this is really secure you you as a tax operator you don't have to invest a lot of money in like Internal Security like measures right so it's a big win and for normal users this 3.0 it's user experience it's really similar to at the centralized exchanges you have deposited we drove all you have your your treating keys treating it's like the treating password on Finance right so the the user experience is much similar to to the two binaries so this is blueprints 3.0 we have open sourced our code like three two or three weeks ago the code decima contract has not been in the security have not been audited yet but we are working on that so our plan is to launch a beta version maybe later this this quarter or next quarter so we are I really look forward to that so this is this is a 3.0 you guys have questions well you can go ahead yes that's true so we have like a parent protocol contract so use that one you can call a function called creat tax then boom is you have a new tax so everything is yours and you are responsible to you can you can choose to stake some tokens there say hey you know I have something to lose trust me because if I am NOT if I do something evil then I lost all my stake right yeah so so basically we we don't want to run the single past tax we want to open sourced is we want to help you guys to run tax yeah but we will probably also run a tax but is not like exclusive so that so the business model is probably different from like stock tax or something right well we use snarks for scalability in order privacy so in so with the availability everything is available unchanged all the transactions all the settlements you see them the data unchanged so is as secure as transparent as the previous versions without data availability it means you can always request the data option but you should have access to all the trading data so isn't there's no privacy here sure thank you yeah so no no privacy it's probably is not our focus and we even think privacy may introduce some regulatory issues here if we want to treat security tokens in the future so this is not related to privacy at all yeah yeah all right so that's it so thank you thank you [Applause]