Loopring 3.6: Features and Challenges

Transcript

[Music] hey uh welcome to adcom my name is daniel wong i'm the founder and ceo of blueprint today i would like to talk about blueprints 3.6 which is a major release coming this fall i want to mention the major features as well as the challenges that we currently have first of all a little bit background about our team we are a small team of 20 people we have 16 engineers and one ui designer

so a pretty small team we don't have a lot of operation or marketing personnel so mostly engineering focus uh i'm also from a engineering background i used to work at google as a software engineer and tech lead and then i worked for jd.com which is an e-commerce company in china and john insurance as a senior director so let's just talk about blueprint 3.6 we are operating a protocol which we call blueprint 3.1 so rubric 3.6 is going to be a improvement over

the 3.1 version we are still using the very same text stack we use the same lib snark and the snark library we also write a circuit using c plus plus so the underlying technologies are still the same so we this is the first feature we don't really require account creation before the account can be able to receive money on layer 2.

previously this is not possible by not allowing by allowing people to receive money without a account we can make sure you know on layer two the sender can send uh either our erc20 token to any address on ethereum and we will automatically create a account for the new uh recipient if he doesn't have a account yet and then we also increased the overall capacity in the roll-up previously we can only support 1 million users and 205 tokens now we can support up to four

billion uh accounts on the in the same layer one layer two uh merkle tree we support 4095 tokens limited number of orders so this version i think is good enough from a capacity perspective to support the ethereum foundation's transfers and tradings in the in the coming two years i think it's sufficient we also abstract a deposit contract which will handle all the a real token transfers for deposits as well as for withdrawals so this isat

management contract can be used for a tax instance to interact with d5 products to earn interest for their users all can even provide flash loans by utilizing those iss deposited by their by the tax users so this one abstraction will make layer 1 interactions or composability much easier we also moved most requests to layer two previously uh withdrawal can do can you know uh be done on layer one and

then on layer two we process those requests on layer two and now most things are on layer two so this will further reduce the layer one footprint and make withdrawal much cheaper and much faster because we don't have to wait for layer one confirmation for those requests but of course we provide a way to force withdrawals on layer one so in some rare cases if the real ear doesn't respond that doesn't you know honor the layer two withdrawal requests you know people can still submit layer one request

to force the operator order relayer uh to do the withdrawal but most things are right now on layer two including account creation including account key update uh you know account uh social recoveries etc everything except uh deposited on layer two the next one is is a major change for the protocol previously we can only uh best processing one type of requests in in one block now of different types of

uh requests or transactions can be passed together into one single block so this gun this block can handle all all type of uh requests which means those requests no longer to be weighed to be packed in their dedicated type of blocks with further means user don't have to wait so from the user's perspective all those other transaction latency will be minimized for example withdrawal will be really fast compared to the previous version

we now also support multiple ways of authorizing user requests or sometimes i say request sometimes i say like layer 2 transactions basically they are the same thing previously for layer 2 transactions we only support edd as a signature the edd i say it's a layer 2 signature scheme but now if the account doesn't have any edds a key set then we can use we can allow the user to sign with their ecbs a key or the owner of the account can approve the transaction on layer 2

sorry on layer one so that you know we can check the approval while the block is committed on layer one also we introduced another concept called agent so the agent once authorized can perform all kinds of of operations or you know transact on behalf of the users uh one of the features that that we implement with agent is this faster withdrawal unlike um the fast withdrawal idea we had with 3.1 which is not really put into production this new fast withdrawal is able to

accelerate all the withdrawal requests so it really just depends on how how much liquidity we have if we have enough funds for example ether then in theory we can accelerate all the ether withdrawal by just providing the ether first and then get easier from the user so in theory once the withdrawal has been you know validated the uh token transfer from the liquidity provider to the user will be immediate there's no wait time there's like zero confirmation time so it's in theory the

fattest resolver that we can achieve so this one will be enabled by default in the future after we launch the the new version we would like to work with potential liquidity providers to accelerate as many types of tokens as possible we also enabled another feature called receipt for withdrawals and transfers the operator can provide a receipt to the interested party so that the interested party will be will be assured that this withdrawal will be put

into a block this is very useful for peer-to-peer payment so when the merchant receives a receipt from the relayer he's guaranteed that you know his money will be received within a certain amount of time the the recipient of the the merchant will be able to use the receipt on-chain to challenge the the relayer and the relay will help to respond with additional data to locate the actual transfer in one of the blocks otherwise the the operator of the relayer will be

slashed so this of course can only guarantee um as much asset as the stake that the operator has put on chain oh this one is a duplicate all right and the tens feature is the secure otc or peer-to-peer trades so with 3.1 um you know we have to trust the relayer because the relayer you know has the power to match any order with any other others right but sometimes we really want to treat uh

without the help of the relay we want to treat um you know of the order book so when that happens uh there is a trust issue with 3.6 you can set a field in your order say i only want to uh i only want this order of mine to be able to match with another order from a specific address so the relay will not be able to match the order with some other some other others some other people's order previously we also have a feature called all or none means you know my order should be matched fully or not

or not mesh at all so with combining these two features it's really easy to do like trustless and secure otc trading in looping 3.5 we have already implemented something called parallel transfers which means the transfer is not really depends on the previous one by using a nouns uh if you want you can still use a nonce and then require the nonce is greater than the previous transfer but sometimes some some scenario require

you to send out a bunch of transfers uh in one batch and you want all those transfers to be successful regardless which of those transfers you know go to goes first uh after another so the the sequence of those transfers in that batch doesn't really matter this is previously impossible but we have make it possible in 3.6 the dual authoring can even allow you to send a transfer some token to a recipient without even knowing the recipient's address or account id you can just sign a transfer and send the transfer data

to the recipient and then allow the recipient to provide the address and sign that transfer again and that transfer is guaranteed not to be able to be used by another recipient so you have a guarantee uh for that security we call that a technology called dual authoring um which is a pretty nice uh net scene uh to to take a look with 3.6 we also enable people to deposit to any other address and we draw your own money to any other address on layer one

so with this feature you know we can do cross layer uh any token to any uh sorry any address to any address transfers so the boundary between layers is really now minimized we hope with this feature we can you know make our own wallet to be able to help our users to migrate all those transfers to layer two instead of you know costing more money uh paying more gas on layer one sorry about the slice those numbers are somehow

incorrect so those are the major features that we have in 3.6 but we also have some challenge going forward so our our lupine 3.6 is going to be launched in q4 so those are other challenges first one we still need to run a trusted setup ceremony because as i said we are using the same technical stack we use we use lipsnark and eastner and those libraries require us to run a setup once we modify the circuit code that's boring but

i think going forward after this release we are going to migrate to something uh cooler uh either using universal setup or using some technology that doesn't require trusted setup at all also you know during this migration from 3.1 to 3.6 we encountered the anticipated challenge we want to migrate all our users from the current rollout to the next one and because those two roll ups are not really compatible i mean the the merkle tree structures are different so it's not easy we haven't really gone through this yet but we

we expect this is pretty uh tedious and and you know error-prone so this is something we hope to be able to solve in the next release also we als we also have some other ideas that we think can be implemented in another roll up we don't want to make this single roll up more complex you know more complex means more it's more error prone is more like a cost for example to audit so we have i think the other team may have the same

uh you know uh idea to implement something uh in a rollup so we come to this interoperability issue we hope that people can move around their eye set between rollups without really interacting with the layer one otherwise you can do a withdrawal you can then do a deposit but we want to make sure the roll-up interaction is there's no layer one transaction and the uh the delay is really minimized we don't have that solution yet so hopefully you know if some other team have great ideas we would like to work a partner with hopefully we can get this solved

also the current relator of mine of my team is really centralized and it's not open for example a couple of days ago our relator had some issues so you know our decks stopped running so that's something we really hope to solve in the near future but it's hard it's hard to be decentralized and in the meanwhile to provide really high throughput with very small latency it's hard besides all these technical challenges we also have this issue of

user education right we want to bring layer 2 solutions to our user but now we need to tell them what layer two a's what layer two means to them why there are multiple layer tools is is that was just one layer two solution uh as we are working on the wallet we feel um it needs we need some time to figure out how to present a technical solution to our end user who are not supposed to learn all those technical details we need somehow you know make sure the user experience is intuitive and easy

to to understand so that's our what we are working on in terms of blueprint 3.6 uh i hope we can you know work with developers in ethereum ecosystem to make layer 2 solutions more popular among our among the entire community and our users thank you so much thank you for adcom ethereum foundation and a lot of people have helped us to make tk roll up possible for lupine thank you