Combining Scalability with Composability

Transcript

okay so um should i share the slides

on here should i be sharing the slides via google me i mean i don't know yeah how's the best way of doing it is it just me to share screen [Music] um um

yeah yeah quite spot ugh

just just let me know when i should start so just let me know when i should start good okay cool um right so am i like on a screen or something is it okay cool um hi everyone um i'm going to be talking about combining scalability with

interoperability and avoiding fragmentation for ethereum layer 2 um especially in d5 so um diversify is an existing layer 2 scale scaling solution for d5 and it's been live for about a year and we work with stark web and we have a kind of a unique solution to this but i'm going to be talking more generally about how it can apply to lots of other layer 2 solutions so so just a bit more about about diversify um specifically uh what we've built is uh a very application specific um solution for for d5 so making it

really easy uh to swap and yield and do the kind of 99 of what most people want to do um in d5 without paying gas fees without failed transactions because it's all on a layer two solution um and today if you go to diversify you basically on board uh connect your metamask ledger uh or other wallet and um i i i can do all of that but the big difference being that you don't need to if you want to hand your own compound for example you don't need to go and make a deposit and pay gas fees for that you can do it all within uh this interface and you don't pay any gas fee and the sort of

sort of big way that we achieve that is by uh using a layering solution and it's and specifically um we're using stark web so it's uh built in cairo which is a a language for writing um and building in in the kai the start ecosystem and so we get all of the security that you get from ethereum um with much higher transaction throughput much lower cost um and full self custody around uh all the assets that are held and managed in diversified um and so on the kind of from from that perspective um there's all the benefits but also

completely fast and frictionless uh all transactions are real time you don't need to wait for and then to be included on chain um and that's achieved by um using zero knowledge proofs for uh the uh for all transactions so essentially uh a certain number of transactions are collected uh they will prove to be to be valid in the sense that they that anyone who's making for example a transfer has the correct balance um and has signed that they want to send it to someone and those all get included at the end of a batching period into one proof which is what's submitted on chain and verified by a contract and that ensures that everything was correct

um so uh in terms of how this particular scaling solution works it's application specific so it's not evm based you can't just deploy any solidity smart contract and it's very much tailored for in our case uh trading and making transfers those are the two operations which uh the entire solution is built around and means that for those operations it is very very efficient um so in production today on mainnet um on average a proof contains 4096 transactions um and a proof that we would submit to be verified and chain of that size uses around 4.5 million gas

um but the interesting thing about uh this this and why it's such a great scaling solution is that actually even if we were increasing those proof sizes and including more transactions as layer 2 gets more adoption the gas wouldn't uh increase linearly its scale something so that cost of a batch is roughly fixed but today um it's already using less than 1100 gas per trade or transfer um which of course is much much cheaper than using um unisop or other layer one um exchanges or deep applications on ethereum but the uh sort of sort of issue that's now appearing is that there

are many different um layer two apps uh and layer two scaling solutions appearing on ethereum it's a very much the ecosystem is um very organic and that's part of the appeal of ethereum and it's fully open anyone can build anything and so we've had teams all over the world implementing different solutions without any central planning and so today we have very many or an increasing number of single application scaling solutions using layer 2 so for example diversify but also loop ring has and gk sync for transfers um which are all live on mainnet and can handle many thousands of transactions and with very low cost

um but these all implement are all implemented in different ways um and so and even in the kind of next wave we're seeing that there's um many generalized scaling solutions including optimism arbitram and uh in the future startnet which are in beta or close to launch where you can deploy for example um celebrity smart contracts or contractors in stock whereas cairo language and um that's leading already even though layer 2 is only just getting some adoption to a fragmentation because all of these different solutions have um usually only the ability to deposit

and withdraw from them to onboard and off board from ethereum layer 1 which has again like a cost to to do but in the future as we see increasing adoption of these solutions that's going to mean that um a people people need to at some point have their funds on on layer one in order to onboard and if gas prices keep rising and if um more and more sort of end user applications end up being on layer two that becomes an issue but also um liquidity for example if we have unisoft on optimism or um already existing markets on diversified

is much harder to um arbitrage and keep in sync across all of these different solutions than it is today on layer one where we have the ability to have fully composable transactions uh when someone makes a trade there are many um many different um components that interact together and that's something that doesn't work today on the layered ecosystem that's evolving so one of the most obvious issues here is that withdrawals from um optimism or diversify or loop ring uh take take some time and there's different reasons for that but

it can be 24 hours or longer in the case of a zero knowledge roll-up it's because of the time taken to actually generate uh the the zero knowledge proof that's then submitted on chain and verified um in the case of optimistic roll-up it's usually because there has to be a delay period before before the state can be finalized on layer one and that of course leads to serious ux issues but also um means that it's very difficult to then um move directly between different layer twos um and i think ultimately what we're seeing is that

the likely future way that most people will use ethereum will be um to use layer 2's but layer 1 will provide a backbone of liquidity so there may be um protocols like uniswap and arve which provides deep liquidity and ultimately layer 2 needs to be able to interpret operate with to access um access liquidity and so we we need a solution to this problem and many people are working on some potential solutions trusted bridges which include moving funds between centralized exchanges are already um something that exists and we're seeing um for example finance being like a

clear example of that where people move to finance smart chain or polygon um but uh there's another wave now of trustless bridges being built we're seeing wrapped assets from other blockchains um and also the concept of mass migrations where um we could essentially build a standard to let people move their funds between different layer two solutions instantly at much lower cost than having to individually each withdraw to layer one and then redeposit but the solution that um we're using it diversify and which i think is a standard that um will be increasingly implemented in many other

um at least uh zero knowledge based roll and scaling solutions is the concept of conditional transfers so a conditional transfer is a fundamental tool which exists in the in the case of uh diversify where if you essentially uh under the under a normal transfer a user signs the amount they want to send to a particular address um and then submit that and that will get included into a future proof um with a conditional transfer you're essentially saying that i will transfer to someone else

but only if a sudden condition is met and um that condition can be anything that can be verified on uh layer one so uh the uh clear example that we're using it for today is to have fast close to instant withdrawals from layer two back to no one and um in this example alice has a layer two account on diversify and has juanis there she signs a conditional transfer um to the operator uh and says i will i will give you my one either but only if i receive one each um on ethereum and

um actually the the exact thing that she signs um includes a contract specified on uh on layer one so a normal solidity smart contract that will register the kind of a fact which verifies that the transfer occurred um to her on layer one so after she sent this um she sent this uh signature to the operator the operator knows that as long as they send um the the required amount on ethereum they will be able to claim it on layer two and so it makes the transfer via this uh transfer registry contract contract

to prove that it occurred which means that some at some point later let's say 30 minutes later when the next proof is submitted on chain um containing all of the transactions that occurred um and diversify that uh conditional transfer will be considered valid by the proof um and so sorry valid in the um verification of the proof and therefore will have occurred so this is a really really flexible and powerful concept and of course uh in this sort of example of fast withdrawals um that's solving an immediate need today

but looking slightly further down the line um we can also think of this being used to do direct movement of funds between multiple different layer two solutions without needing to um without needing to wait for proofs to be submitted or for a batch waiting period to end um so you could for example uh use this today uh in in in the current way it's implemented and to directly send funds between uh diversified uh dydx which are uh both built on the sit on on using uh stockwear and contain this

conditional transfer mechanism but in the future you could also make the condition um based on uh an article that or actually anything that can be seen on layer one so for example if you wanted to build a different order type that uh was only valid under certain conditions on certain market conditions uh for example like a stop um limit order where you want to sell certain amount of ethereum but only if a price goes below a certain point um you could you can do that using this because the condition that you would use would be a layer one

oracle which um basically just says whether the price is above or below uh that threshold so um so this is something which is incredibly incredibly flexible um and um really sort of empowers builders to create whatever they want and the way that it's actually currently implemented means that independent teams can actually deploy new transfer registry um contracts on on ethereum and we'd be able to then register them so if someone wanted to create an arbitrage a contract between layer two and unit swap or sushi swap uh

they can do that and the the actual on like facility implementation would say we would just register a fact only if there was a successful trade on on sushi as well and this means that you can then um create uh basically liquidity sharing between layer one and layer two and not get this kind of fragmentation um of uh everything that goes on there too being slightly out of sync with the rest of um the market and so um sort of looking looking ahead uh i think the the way that we're starting to see layer 2 emerge would be that ultimately all all end users would

be interacting with um d5 via viral layer 2 and won't be paying gas to do so um but and all uh let's say trading for example and swapping would internally match on there too but if it needs to access deeper liquidity or more equilibriums available would lead to using a mechanism like this to access um to access that to fill any remaining um any remaining quantity of orders and um this mechanism is one of the ones which will will really allow that allow that to happen um so thank you very much um for for

listening um diversify is hiring at the moment we've got a few different roles open um including in particular data analyst blockchain researcher and elite course like developer in javascript um so please um please speak to me if you're if you're interested and we will be backed by a great set of companies in the space and thanks very much two

okay i mean so for example i think you're talking about this slide um i've i put hermes and casing on the left side because today what's live is kind of their version ones which are basically just doing transfers and so very very efficient transfers particularly tailored for that but i think in both those two cases they are building evm solutions that will allow more arbitrary logic to be yeah you know any any smart contract to be deployed and it would sit on the right side in the case of

um starkware in particular so whilst what we're using i mean it's essentially implemented in cairo you could build in theory any um and any application for you know optimize further for other things um so start net will be coming in um in in the future which and already that there's a beta which is a little test um that does allow um you know anyone to build anything and deploy it and that and so diversify will be migrating to that when it launches um which is going to be a almost uh an open composable um permissionless uh system but rather than writing

incidentally you write in in cairo which uh means that you're sort of more closely it's a language that's more tailored to the way that um the way that zero knowledge uh proofs uh work and more optimized for that um no so actually the thing about that is actually so this conditional transfer the way that it's actually implemented means that what you sign is just a hash and the hash is it is generated in a certain way that it basically it

can include and it includes an ethereum address which is a smart contract um so it it's it's very flexible from that perspective that the the proof system doesn't need to know what that contract is it doesn't need to know what logic was implemented on layer one in that contract it just needs to be pointed at that address and then look for a specific type of fact that was registered so um if you're if you're writing this layer once the smart contract you make a function um you have to ensure that it will basically register a fact that's just saving an information that can be checked by the proof um but you but other than that the um the actual prover system doesn't need to know what was what it does so in the case of the fast withdrawals

when you call this function all it does is save this fact that it that the transfer happened and then make the transfer but if you were making an arbitrage contract you would again save the same fact um and make a trade on unison um so uh that's that's why that's possible today without needing to write specific logic for it in the um in the actual layer two implementation great thank you very much you