Layer-2 Composability and Communication

Transcript

hi i'm chris winfrey and i'm one of the founders of hop protocol and today we're going to be talking about layer 2 interoperability and composability so previously our team was working on ethereum and before that we were doing some smart contract auditing and so what is interoperability and composability so interoperability is the ability for two systems to be able to talk to each other and composability is when different components of systems can be rearranged in different ways to meet the user's requirements so with layer one ethereum today we have a highly composable system we have

different protocols built on other protocols and this is really powerful because each protocol doesn't need to necessarily have platform risk or trust the protocols it's building on and can just build a thin layer and provide a lot of value to the user and it's really easy to move value across these different protocols because they're basically all in the same environment but layer one ethereum is really expensive today and you know it's gotten better in the past few months but we saw you know even simple swaps costing over a hundred dollars and this is really concerning as a user uh because if you say like enter into a loan or something like that and you need to exit you don't necessarily know that you'll be able to

exit without having to pay you know a gas cost that exceeds you know the interest that you're earning and so if we want ethereum to be used by everyone and not just you know those that have tens of thousands of dollars to interact with d5 protocols we really need to scale ethereum and so luckily there's some great teams working on scaling ethereum notably optimism arbitrarum starkware and zk sync as well as you know other side chains like polygon and xdi but today we're really focused on rollups and so each of these provide a scalable environment transactions are much cheaper but they're all kind of siloed

environments so if you have an application on optimism it's not easy for it to talk to something on arbitrom and it's not easy to transfer value between these protocols and so this is actually something that we saw with ethereum we we tried to get our users on to layer two when when gas prices got expensive and what we found was that users would enter layer two they would make a few transactions and then they would come back to layer one and they would end up spending more on gas than they would have if they just used an application on layer one and so we really need users to get on to layer two and to stay on layer two and to be able to you know access a diverse set of roll ups without ever touching layer ones so we need

layer two to be interoperable and we need to be able to transfer value directly across the two layer twos if we want to scale ethereum with roll-ups and so ethereum itself is even shifting its roadmap towards uh scaling with roll-ups and so we're going to see ethereum become kind of a base layer for rollups where the execution shards become a settlement layer and then data availability shards provide data availability for the roll-up solutions and so there's a lot of other scaling solutions out there like plasma and state channels and valydium but today we're going to be really focused on rollups and uh that's because rollups can give us full evm compatibility and

if we're talking about composability uh we really need a generalized execution environment where anyone can deploy any type of application those applications can build on top of each other just like we're doing with layer one and so a rollup is characterized by a state route and this state route represents all of the state on the roll-up and it's very similar to how ethereum state route represents all of the state on ethereum and the difference between a zk roll up and an optimistic roll up just comes down to how the or the rules for updating this state route so with the zk roll up you'll have a validity proof where you can prove that all the state transitions are valid and update the state route

and then an optimistic roll-up uses fraud proofs to prevent fraudulent updates to that state route so now we can talk a little bit about how layer 1 and roll-ups interact with each other and how value's transferred between them we're working with a lot of the different roll-up teams and starting to see these patterns emerge and so one of the main patterns is a cross-domain messenger and this is kind of called something different depending on which solution you're looking at this is what optimism calls it um and is the language that we've adopted too but basically your cross domain messenger allows layer one contracts to talk to layer two contracts and vice versa so you can see here our

sender contract encodes a message that's passed to the layer one messenger contract and then that gets propagated up to layer two and then message is called on the recipient contract so when we're talking about messages we're talking about contract calls so for this context one and the same um and it's important to note that uh the way that this message propagates up to layer two uh depends on the implementation of the roll-up and then also it's not always the layered two messenger bridge contract that's calling the recipient contract that's also implementation deal details so this is a little bit generalized um and another important note is that

this happens pretty fast so we can send messages from layer one smart contracts to layer two smart contracts and it happens in about the time it takes for uh layer one to reach finality so we're talking about five to ten minutes and then you can actually execute something on layer two from layer one and so we can also send uh messages down from layer two to layer one um so you can see here pretty similarly a message is encoded passed to the layer 2 messenger that propagates down to layer 1 and message is called on the recipient contract but depending on the type of roll-up this can take a week for optimistic roll-ups or it can be pretty fast for

zk roll-ups depending on how often they checkpoint um but this checkpoint transaction is a pretty expensive transaction for zk roll-ups so depending on the scale of the roll-up it might checkpoint pretty infrequently so you know there's some zk roll-ups that might checkpoint every two hours every half hour at scale they can checkpoint a lot faster but that's going to be a really really expensive roll-up for optimism and arbitrary it's going to take a week for that message to reach layer one so the big takeaway is layer one communication to layer two communication is really fast layer two communication to layer one communication can be slow can be fast for for zk roll ups and so the first application that these

roll-up teams usually build on top of their cross domain messenger is their native token bridge because this is really what brings value to the roll-up you know without the native token bridge it's just kind of its own environment um and not necessarily scaling ethereum but the native token bridge allows us to bridge assets onto the roll-up and actually you know utilize ethereum-based assets and you know that's ultimately what we want to do so the way this works it's built on top of the cross-domain messenger the user deposits in this example die into the layer one bridge that die is locked into the bridge and a mint uh is encoded and passed up to layer two and mint is called on the layer two

bridge and a representation of the layer one die is minted for the user and so one of the kind of quirks with layer twos is that there could be multiple representations of the same layer one asset on the layer two and users and applications will likely center around a single uh app or a single asset uh and so we call this the canonical token or the canonical asset um so this is going to be the one that users choose to adopt the one that uniswap and ave choose choose to adopt and ultimately the most uh useful one so canonical dye canonical usdc that's the type of language we'll be using um and so the uh native token bridge

also allows you to exit the roll-up and since we're building on top of the cross domain messenger this is going to depend on the exit time of the cross domain messenger so like we talked about one week for optimistic rollups and then it can vary for zk roll ups and you can see the user actually burns their representation of of die um and that encodes a release function or a release message gets passed down to layer one uh release gets called on the layer one bridge and and the user can exit with their die after the exit period and so luckily there's a good solution to this called

fast exit bridges it's a pretty simple mechanism and basically a liquidity provider provides upfront liquidity for the user and then when the exit eventually reaches layer one the liquidity provider receives that instead of the user and the liquidity provider provides or takes a small fee for providing the service and so the hop token bridge actually can function as a fast exit bridge so you can exit directly from optimism to ethereum in about the time it takes optimism to reach finality so also about five to ten minutes so now we can get into hop protocol and so hop protocol is a scalable

messaging protocol for scaling solutions and so what i mean by that is with a naive approach you could have one layer two talk to the next by propagating a message through layer one and then back up to the next layer two this isn't scalable because each message would require a layer one transaction and that's just going to get really expensive if if you're trying to have many contracts talk to many contracts on the next layer too so the way we solve this is with what we call a cross-domain message route which is simpler than it sounds and we basically aggregate many messages on the origin roll up so here we have a mint release swap deposit and we aggregate these into our merkle

root that we call the cross domain message root and this is very similar to uh the state route for a roll-up or ethereum state route in that it represents all of the messages that we just aggregated and then we can take that really compact piece of data because it's just a single hash and propagate through that through layer one to the destination and as long as we have all the data that it took to kind of compile that cross-domain message route we can then unpack that message route at the destination and then execute all of our messages at the destination so now we can communicate directly from one roll-up to the next roll-up in a scalable way

this is still a pretty slow process though because we're subjected to the exit time of roll-up a this is built this is also built on top of the roll-ups across domain messengers that's how we're passing the cross-domain message route from roll-up to layer one and then back up to the next roll-up and then we also need to wait enough time for uh messages to be enough messages to be aggregated so we can amortize that layer one contract over many messages and so just like rollups built their native bridges as kind of the first application on top of their cross domain messengers we built a cross layer 2 token bridge on top of

our cross layer 2 messaging protocol and so there's a lot to unpack here first we use a special asset so it's a new representation of the layer one asset the reason for this is because we can't program all the functionality we need into the native assets so um the the canonical asset isn't used directly by the bridge but ultimately that's what we want to bridge and i'll get into that later but heath basically represents a deposit into the uh hop bridge contract just like uh canonical eth would represent a deposit into the native bridges layer one smart contract and so in order to perform a cross layer two transfer it it

works very similarly to a fast exit bridge so first the user needs to have a deposit or sorry the bonder needs to have a deposit on roll-up b and the bonder is is the liquidity provider in this case and so alice is making a transfer from roll-up a to roll-up b the first thing that she's going to do is is burn h eath on uh roll up a and then uh the bonder is going to see that and and then mint uh heath for alice on the destination roll up and you can see that she received a little bit less than what she sent and this is because the bonder took a small fee for providing these services and so now alice has completed her cross-layer

2 transfer she's she's gotten her asset at the destination um and then the final step is this settlement step so after alice and many others have uh transferred from roll up a to roll up b we can aggregate all of these messages into a cross domain message route that proves that that heath was burned on roll-up a and then we propagate that cross-domain message route through layer one back up to the destination roll-up um and now uh the bonder who has locked up a lot of their liquidity bonding all of these transactions can now prove that for every heat they minted heath was burned we haven't created any net new heat so now the bonder's collateral is freed up

they can withdraw it they can use it to continue bonding transactions and the system is completely settled but ultimately alice probably doesn't have a teeth on roll-up a and she probably doesn't want a chief on on roll-up b she wants actual the canonical eath on rola bay and she wants to bridge directly to the canonical eath on roll-up b and so we deploy a stable swap amm on each of the scaling solutions between h eath and eth and that way alice can swap from eth to h transfer that heath over the hop bridge to the destination where it's immediately swapped out of a chief back to eath and we can abstract this completely away

from house she doesn't even have to know or think about heath and we can just show her a very familiar user interface for transferring directly from one rollup or scaling solution to the next uh rollup or scaling solution and these transfers happen in the time it takes for the origin roll up to reach finality so so about five to ten minutes so we have a live usdc bridge we currently support polygon and xdi we'll be adding optimism and arbitrarium soon we'll be expanding the the set of assets that we're supporting and then the next big push that we're going to make on the research side is supporting cross-domain contract

calls so right now our cross domain message routes are very specialized for transfers um but we can expand this functionality to actually allow uh a contract on one roll-up to call a contract on the uh another roll-up directly and so because this is asynchronous communication uh there's different uh trust models and trade-offs we can make and we've identified two trust models with two different trade-offs that we're going to allow so the first is an immediate cross-chain contract call and this is an immediate costing contract call can be done when you don't have to verify who the sender is

and what origin roll-up they are sending from um but you can as long as you can make the transaction and have tokens come along with the transaction uh this is perfectly fine so you can do swaps you can do deposits anything where you don't need to actually verify who's sending the transaction um for transactions where you do need to verify the sender on the origin roll up like a withdrawal or a vote transaction this is going to be delayed by the time it takes to propagate that cross-domain message route from the origin roll-up to the destination roll-up um but then you could still do something like withdraw from a vault or or vote in a governance contract

so you know some of the use cases for cross-domain contract calls a lot of this stuff isn't even stuff that we thought of it's it's the things that other teams have pitched to us that we've talked to about hop protocol so things like round-trip swaps you could you could tap into liquidity on another roll-up um say send a usdc from optimism to arbitram uh have that usdc swap to eth and then have the us have the eth send itself back to optimism and and without ever you know touching arbitrary yourself you could do things like cross-domain lending cross-domain governance and i'm sure people are going to come up with a lot more that you could build on top of hop protocol and thanks you can try it out today at hop.exchange

follow us on twitter and i think we have time for a few questions yeah i may ask a bit of a philosophical question so um why do you think there will be ever more than one roll-up because if you look at the history of uh of computer industry there's always and one twitter one airbnb one uber so the biggest guy always gets bigger and the smallest guys will always like get smaller and ultimately the fixed point is there's only one solution so why do you think

like in the long term there will be more than one of them so roll ups are subjected to the same limitations with state growth that layer one ethereum has so if we just push all the users to a single rollup then we actually have the same scalability constraints that we do on layer one ethereum so if we're going to scale ethereum we do need uh many rollups to kind of expand the transaction throughput that we can support just curious when you show this how you pass these messages the only thing that you store on l1 is the miracle route

right right so the messages only stay at the origin and at the destination they are never settled anywhere in between exactly yeah the the cross domain uh it's just the route that's passed uh through layer one so it's a really compact piece of data um all the the and is there a possibility to lose this like if for example if roll up a for some reason uh you know disappears we lose this information so so by nature of being a rollup all the data needs to be available um so so all of this is posted actually on the layer one ethereum chain thank you

[Applause]