Defi pooling: Taping L1 liquidity from L2 / Henri Lieutaud

Transcript

hello everyone thank you for being with uh with me today so today I'm gonna present a topic that is not that recent it's been something it's something we've been talking about for a while now we called it often D5 pooling and what it is in a nutshell is a way for you to build applications that live on L2 that give your users L2 experience with fast cheap fees fast transactions cheap transactions and a better ux all the while using L1 liquidity and using D5 applications that live on L1 that have a lot of advantages around L2 so I'm going to try to explain how is it I want to underline that this

is very much an open field so if you have questions around about it don't hesitate and ask them and if you want to try and build stuff in that field reach out I'll be more than happy to give you pointers on how to explore that that land so before we start I'm Henry I'm a developer advocate for Stark net at where I work at starkware which is the company that develops darknet I'm based in Paris and you can reach me on Twitter or on telegram we have a booth over there so don't hesitate and come say hi so what am I going to talk about today first of all I'm going to do a very quick refresher as to what are validity roll ups or ZK Roll-Ups and how they

work then I'm going to talk about messaging Bridges and protocols and then finally I'm going to explain how that all results into what D5 pulling is so first let's talk very briefly about validity Roll-Ups so who here in the in the room is somehow familiar with validity Roll-Ups or ZK Roll-Ups can you raise your hand nice so a few of you so for those of you who are already familiar I hope I want you it will be fast don't worry so first let's introduce a concept that are validity proofs validity proofs are really the basis of what validity roll ups are and they're essentially a cryptographic tool which you can put in

the same category as say ashing functions or digital signatures they are mathematical tools that are backed so they are based on mathematics you can dive into how they work if you want but if you're building an application you can also just use them in your application um and validity proofs allow for the following they allow one person to run a program and generate a proof of the execution of that program meaning they run their program they get the output and they also get a proof this proof is like a value a number and by sending this proof and the output to another person

this other person can use these two elements put them in another mathematical uh instrument and verify that the program was executed correctly and that indeed it yielded that input so in another word in other words it allow person a Alice to execute a program and it allows person B to verify that the program was used was executed correctly and trustlessly exploit the result because they know mathematically that this is what the the program yielded now where this gets really interesting is the following there is an asymmetry between proving and verifying um

when you're proving a big program it takes longer to verify on the other end but it gets exponentially cheaper meaning the bigger the program the lower the marginal cost of verification per unit of compute so into it introduces enough symmetry between the person doing the calculation and the person verifying the calculation all right so these are validity proofs in a nutshell now how do they relate to blockchain and how do we use them in in the blockchain world well here is what validity Roll-Ups are in a nutshell validity Roll-Ups are blockchains they have blocks they have transactions they have Smart contracts and these

blockchains are executed by entities which are called sequencers and every now and then let's say every 100 block these sequencers generate a proof that the blockchain move from block 0 to block 100 correctly and that proof gets sent to ethereum in a smart contract where it is verified so in other words this blockchain is executed by a big machine and it can be verified by small machines in a smart contract on ethereum and the ethereum blockchain as certainty that the blockchain was executed the off chain blockchain was executed correctly

because it has this proof and it is able to interpret it all right now what is really nice with that setting when you start thinking about it in different term is that to the best of my knowledge this is the only instance where you get blockchains talking to each other natively think about it when you are using a bridge that relies on validators sign signing messages what you're really doing is you're asking blockchain a to interpret something that is coming from blockchain B but the only way blockchain a knows that blockchain b did something is because a bunch of humans signed messages to say yes yes this is

what happened right so you're relying on the human translator taking the example of say Bitcoin for example there's no way for ethereum to actually validate what happened on bitcoin because running a full node a full Bitcoin node on ethereum would be way too expensive well with validity proof you get to prove the blockchain and use that result uh in in ethereum so they can actually understand what happened on the other end without human translation just based on mathematics um so the cool thing with validity roll up is that they allow you to pass messages so now I'm going to talk a little bit about messaging Bridges and how they relate to uh to validity Roll-Ups and D5

so first of all let's define what cross chain Protocols are cross chains Protocols are essentially a way for L1 and L2 to exchange messages when you think about bridges these days most of the time you think about asset Bridges you think about bridging nfts you think about bridging tokens reality is you can do a lot more with blockchains than just manipulating tokens right you can manipulate permissions you can maybe delegate execution of code or this kind of stuff so cross chain Protocols are really not about moving assets they're about moving data they're about exchanging instructions and coordinating behaviors of smart contract on L1 and on L2 right

they allow smart contracts on both chain to interact with each other and be a meaningful whole without having to rely on humans now if you think back at what D5 is D5 is sort of similar right they are protocols there are set of rules that govern how you move asset around in the blockchain in ethereum and usually most of D5 application rely on input that comes from L1 right it comes from a transaction it comes from an oracle update it comes from a liquidation event something like that now the concept of defy pulling is really simple how what happens if you connect both of this world what happens

if you use ad5 protocol and you connect it with a cross chain protocol what happen if you link in L1 D5 liquidity Depot with stuff that are happening on L2 another way of looking at it is the following right now when you think about defy on L2 what most protocols do is just clone their application on another layer you have a landing pool on L1 and you just instantiate the same Landing pool on L2 meaning what you're doing is just fragmenting liquidity and usually you will have one pool which is much deeper than the other and this makes it really hard for the

second pool to live because users have no incentive to pull in that pool um even though the other one is much harder to use and much more expensive because it lives on on L1 D5 pooling is really about not cloning your application but extending it adding extra functionality on L2 instead of duplicating functionalities okay um and that gives you a lot of power because now you're able to get the both the best of both world you're able to give to your users experience that is much cheaper much faster it's L2 right and much better ux with change such as starknet you get to

leverage account abstraction which enable experiences for users that are far better than what whatever you could imagine on top of ethereum and you also get the best of L1 liquidity you have a much much bigger pool of pool of pools right there's much more applications living on L1 than living on L2 these pools are generally much much deeper so liquidity is more efficient and you also get the best best security because it lives on ethereum it doesn't leave on another chain right so let's see examples of what defy pulling is and what I want you to come on with is not necessarily those two use

cases these are interesting use cases I want you to come home with knowing that extending your protocol to L2 is a very powerful way to give access to your protocol if you have an L1 protocol give access to more people and if you don't have a protocol it's a way to provide access to existing liquidity pools on L1 with much better ux so let's look at the case study the first one would be batching user actions the issue one of the big issues with uh with V5 on L1 right now is that it's expensive to do transactions on L1 so it may not make sense to deposit money in say the curve a curve pool if you have only 10 or 20 dollars of of

liquidity so what do you do then do you just do it on another chain well one way to do it with L2 would be the following you on L2 you gather users they will deposit money on your protocol on L2 so they will deposit say USD on your protocol on L2 everyone every now and then you will get a message moving from L2 to L1 that will at that point actually move the funds on L1 so if you have a hundred people doing transactions very cheaply on L2 at some points the L2 protocol will send

a message and just move everybody's money in one transaction to L1 that sounds simple that's because it is that's what urine is doing but directly on L1 but now you get to do it on L2 the cool thing about this thing too is that if you build your protocol in a smart way you can actually tokenize the like say for example let's imagine with the other Landing pool if you're depositing USD and you get a USD you can actually give them ausd on L2 and they get to exchange it with the ausd equivalent which is on L1 so what you you're doing with that really is just

typing into L1 liquidity and using L2 L2 user experience um there's not much more to it right it looks simple that's because it is there's a lot of things to do with that um another interesting uh example I like to take is um using starknet for Dao treasury management right now most Dows that live on L1 I have a very big problem with the engagement of people voting is very expensive on L1 so most people don't vote so you don't get a lot of participation in your Dow the other

solution is to use something like snapshot which is great snapshot is a wonderful system but it doesn't have teeth it's just signaling it's entirely off chain so you rely on Snapshot to collect voters intention and then a multi-sig is tasked with enforcing those decisions well here you could imagine having a system where you get the best of both worlds again and you have your governance on L2 and your liquidity on L1 so you get your brain on L2 and your muscle on L1 because yeah we didn't talk about the other side of that what happens if your

Dao fully leaves on L2 then you get people to vote for not a lot of money but then liquidity pools are not great or they're shifting more so your assets are way less efficient so what you can do in that case is basically have a set of smart contracts on L2 where people vote take decision on Capital allocation and you pull the result you count their vote and you reach a decision and what's that decision is Rich you send a message the smart contract will send a message to L1 that will execute some action you can actually use ready-made tools

for that if you use a multi-sig contract and you just connect it with L2 it can take instructions from L2 and just execute them on L1 you don't have to change a lot of stuff for it to be efficient I want to mention that those two use cases are not something I just made up there there are smart people already smarter people than me working on this thing snapshot which I mentioned is working on Snapshot X which is actually even more involved than what I just described they're working on the system to collect all the user votes off chain the signatures that you're currently doing with snapshot count them as is in a smart contract on starknet and then use these discount to

send a message to L1 and execute and enforce decisions on L1 and the part about depositing batching user user funds on L2 and then sending instructions on L1 you have Ave making experiments around that you have maker who are doing experiment around that and a lot more people something that is also really interesting that I want to to mention is that right now if you're an L1 project and you want to bridge your pro your token to L2 often time you have to go through a specific Bridge register your token and then you don't have a lot of flexibility of how your token will

behave on L2 right maybe it's a standard contract that is deployed for you on L2 and this kind of stuff messaging Bridges and having a tight connection to L1 allow you to design your own bridge and to actually operate your token and your Bridge token exactly the way you want so maker for example is operating their own Bridge their own Stark net Bridge and they're fully in control of the representation of their token on L2 all right and that's about what I wanted to present soup

there you go so to sum up what I discussed um defy pulling is essentially a new primitive you can use in defy it's about not just using input that comes from L1 interaction but using input that come from L2 interactions this is something that wasn't possible before because up until then whatever was coming from outside the chain was trusted you relied on validators you relied on people signing information and they had control over your protocol now with validity proof you can do this in a fully non-trusted way it's a really exciting Pro primitive because

it allows you to do a bunch of stuff but one of them being to expand your user base right now Defy is very hard to use blockchains in general are very hard to use but l2s are a bit easier to use so you get to have more users for URL one application all the while having more efficient liquidity I also want to mention that this is very much an unexplored territory there are a lot of things to build using this messaging Bridge some people are really into it but you should be too like you're much you're very welcome to come and

experiment I'm going to be doing a a workshop later for if Prague where I'm actually going to take you through how to deploy your own bridge I'm gonna explain to you how to write the solidity part to receive input from L1 from L2 and I'm going to teach you how to write the L2 part that receives input from L1 and how you can get started experimenting with that it's also something that you can that can be very useful for you to experiment during a hackathon so yeah come to this Workshop if you're interested in making this work we also have a booth down the down the hall and come say hi we'll be happy to to help you out

are there any questions yes um thanks for the chat it's very interesting topic um one of the field arguably most most important we need is liquidity depths for amms that's where the industry desperately needs but I failed to see how this could work without aggregating you're right amms are a more complicated topic this the system I describe works well for it works really well for Lending for amms it's more complicated so I'll say this way this is a nut that hasn't been cracked yet there's no reason why it

can't so I think there's a you can imagine a lot of different ways you can do that and I don't know what what's the right recipe but at least here yeah I don't know it's I I don't have a good design for that but it's definitely an interesting uh an interesting area of experimentation yes hi I wanted to ask about the um so the messaging layer and the storage proofs part that's fine I was just curious about the D5 pooling part on the L1 how is this date how is this pooling happening actually on a smart contract

level are there any implementations that are like you feel like are similar Direction one should be looking at to explore how these how how the V5 what is what is D5 pooling in on a smart contract what does it look like on a smart what is defy pulling on L1 yeah right what sort of um ways of doing it that can be efficient for this use case yeah sure so for example taking back the example I took of batching user uh user deposits you would have an L1 contract that is able to man to hold assets right um when L2 users send USD to the L2 D5 pooling then the l2d5 pulling at some

point will withdraw money from starknet and it will withdraw money to the D5 polling counterpart on L1 so now that D5 pooling contract on L1 will all these funds and will be programmed to deposit those funds and put them to work in any kind of pool so it's about you have contracts on both side and it's just about like think about it kind of like yearn in a way you have a factory or you have a contract that is able to move money around it receives specific inputs from time to time but instead of receiving these inputs directly from handle one it receives them from L2 does that make more sense kind of okay any questions

thank you for the talk so I wonder as far as I understand correct me if I'm wrong that in this roll up space starkware is kind of special because it doesn't strive for evm compatibility whereas other projects want to be as compatible as like as closely as possible how does this distinction correlate with the issue that you've described so pooling is it easier if you're evm compatible or not or is it just an orthogonal metric that doesn't have any influence here that's a good question and I I don't know about that I think it's still very much early and I would be very interested in talking with teams who are taking this approach either on the kvms or on ZK VM and to get their insights on

that um so yeah I I don't know foreign I wanted to ask if there is any latency between the layers I mean how do the layer 2 users know that the state of the blockchain they are experiencing is the same as is on the L1 and it did not change since the last update okay your question is about latency is that correct yeah yeah um so messages move from L2 to L1 at a specific pace so L2 to L1 messages move every few hours L1 to L2 messages are

move every few minutes now how are users aware of this that's up to you that's how you define your that is how you design your application do you want to give them an instant token that has value or are you going to put this in a pool and then transfer them token later on it's really up to the app developers to give the visibility on that or to abstract it away um but it's kind of like again like applications like yearn who pull user deposit to then deposit later on or Lido for example this is very much about how you define your application it's not necessarily a technical issue does that make sense okay thank you

all right any more questions here's an I'm thinking now about here and here's another fun thing that was done by yearn actually it's an experimentation but you know that you earn as these concept of strategies where depending on the best way you allocate liquidity they will change the parameters of where the the allocate liquidity right all of that calculation is done off chain and then a multi-sig will say yes this is the best strategy and they will implement it on chain in other words your strategy relies on Multi multi-6 they recently did an experimentation where they wrote the best strategy allocation algorithm in Cairo and it proved that this strategy

is the best one and then they use that output to change the result on chain so the used provable code and validity Roll-Ups to make their system safer anyway just the fun stuff also you can experiment with with related to our labs all right I think I'm done with my presentation thank you for listening to me don't understand come ask questions foreign [Music]