Smart Accounts Are the Answer to Ethereum's Interop Problems

Transcript

Okay, cool. Uh, hey guys, I'm Tanish. Uh, I'm an engineer at Ithaca. I've been building the Porto smart accounts along with vectorized. Uh, the so the latest feature that we've shipped is interop. And basically, this talk is a way to uh inform you of like the first principles that we've learned about interop. and if you're like DAP developers or uh users and how you should be thinking about of an interop world and preparing for like the next wave of smart accounts and how you can make your DAPs more modern. Um so this is abstract. We'll first talk about the goals. There's a lot of different types of interop that people talk about. Uh we'll talk about which one we talk about specifically and also uh why we think it's important. Uh then there's the two layers settlement layer and the account layer. There's a reason

why we why we call them separately layers and we'll also discuss it in the call and then uh later in the talk and then there's a design walk through and like I I really believe that we've so a principle that we value a lot at is like minimalism. So eventually like most of the chain abstraction or interop systems that you'll see will distill down to these parts. So I think it'll be helpful in the end for you to be able to recognize them and see how your DAPs or um projects interact with each of them and how how you would want to choose each of them. Uh cool. uh and if you have any questions feel free to interrupt or we can take them at the end of the uh session as well. So the goal first thing is we want n to one interrupt with atomic execution. So it

means n origin chain so you pull from n chains and go to one destination chains destination chain there there's also a lot of uh different versions like 1:1 where you only can go from one origin chain to one destination chain and n to m which is you can go from n origin chains to multiple destination chains. Um I think N to1 is the most u most valuable because 1:1 is easy because 1:1 is good and it also like provides you some value but the lift from going from one to one interrupt to end to one interrupt is pretty small and if you have a small lift then you why not just do N to1 and when you can pull from multiple chains and if you have assets across different chains some assets only exist on some particular chains so you can do that. The reason why we don't do

end tom is two twof two folds. One end tom is super complicated and and we think for no reason in the sense that whenever a user comes to a chain or comes to an app they do it with a purpose. This app is on a particular chain. So that's why this also atomic execution is there. So end to interrupt plus atomic execution means that you bridge and atomically execute the user's action on the destination destination chain. So our end goal is to make sure that the user's action on the destination chain is done. And how we reach there is like the bridging algorithm and the path rooting algorithm. We don't think that end tom makes too much sense in the beginning because of the complexity and also the user does not have to go to multiple chains at the same time in 99% of the

cases today. Cool. The second goal is one signature for everything. And this is like one goal that we have there explicitly and this is also why you would um we we would be talking about the account layer because um if you don't have this goal then basically all smart accounts today without any changes like I have a claim about this in the at the end. All smart accounts today without any changes can support interop onchain like there's onchain complexity of interop is very small um and we'll also discuss that and the next is crosschain swapping and you have like three versions of this so I believe like a must have is that you must do like ve he because most settlement layers will only like bridge ve for you and if you're not handling like the the user wants ETH and the user wants wet then

that's pretty bad UX also for like USDC USDC.e E um with arbitrum and all of that. I'm I'm sure like we all agree that this this is a must have for any uh any um chain abraction system. The next is nice to have for short tail assets, ETHUSDC, BTC, USDC, USDC or some other kind of like token. A great UX to have is longtail assets. Um it's because whenever a user goes to a chain, they actually do it with a purpose and the purpose would be depositing into a D5 app. Many many times these D5 apps have like weird positions like an NFT position and these positions have deterministic value but if you're not able to unwrap those positions when the user needs them then you first have to go to that chain unwrap it explicitly then come back and do it. So although this is super hard to do um and also

there's a lot of versions for this you can have meme coins and stuff like that but it's it's great to have if you can do this. Cool. So before we like talk about the designs in general like some intuition about how this will work in general so that you can follow along and then at the end we'll have like a bigger architecture walk through. So Alice wants to deposit 10 to a on base. Alice deposits seven ETH on ARB and 3.1 ETH on optimism to an escrow but sim like this this will always be the case. You can call it resource locks. You can call it something else but Alice has to lock up their funds on on this on this chain at some point. Then there's this entity called the big bulky bridger and um which is like an off-chain bulky uh sent super centralized service uh that will

send 10 e to alice on base first uh before it does anything on the origin chains or like after the escrow is done and does the a execution for them. So it sends the funds and automatically also does the a deposit for them and then later this big bulky brer comes and settles with arban optimism. So it it takes a proof from the destination chain puts in all all of the origin chain says that I have deposited those funds um and now now basically give me the funds that were escrow. The reason that this is 7 and 3.1 E is that the 0.1 E is the fees that the bridge is taking. So out of 10 E like there's uh some fees that the bridge is taking for doing the bridge for the gas abstraction on all chains.

Um cool and also one case that I I'd want to make implicitly throughout this um talk is that this big bulky bridger being big and bulky does not have any effects on the on the security properties of the user like this censorship resistance is still provided by the Ethereum base layer. So always like if you have tiny bit of gas fees you can always rescue your funds or do whatever you want with them because the account is permissionless. So this big bulky bridger is kind of like a block builder entity which is um which you like which for the user in this specific case will not hurt any of the security properties.

Okay. So the first layer the settlement layer what we I think this is analogous to TLS in the sense that the settlement layer's only use only like purpose is to get the funds from one chain to another or like get a message from one chain to another. Um it does not care about what the message it specifically is. It could be a hash of all of the transfers that you're making or anything. But this is kind of analogous to TLS in the sense. The account layer on the other hand is analogous to HTTP which like adds headers to how the account will um how the account will view your uh execution payload and what the execution payloads are and then there's like some admin stuff like depositing into the escrow and stuff like that. So the layers are the escrow provider um where are you

escrowing? There should be some kind of refund management and the claim that I made about this being still being censorship resistance and still being good in terms of security properties only works if the refund is permissionless because often the destination chain action will fail because there's some latency although for the user chain abstraction in this paradigm should look almost instant but there's some like always like users would want to do swaps on meme coins on some chain and this the are super volatile um so the destination chain action will often fail so the user should have uh the user should be able to rescue their funds from the escrow whenever they there. So, a refund basically. And then there's the crosschain proof provider. So, there's um yeah, go ahead. There's different flavors of this crosschain proof provider. Uh and I've listed like the top three ones on on Jumper LiFi today.

Uh this is a reservoir relay and this is completely trusted. It says basically I give you funds on the destination chain. You have to trust me that I've given you those funds and um u I I take them from you on the origin chain. This works. It's super fast. Some people if they're okay with the trust assumption can use this. Next is across which uses the UMA oracles right now. And of course all of these people are coming with like new models uh at some point. Um which uses the UMA oracles which are these are optimistic. So I I like optimistic roll-ups. I say that I've given you the funds. If somebody claims disputes it then an UMA oracle votes on it. Um and if if the vote is wrong then you get your like your you have a bond mechanism and stuff like that. There's layer zero which have the

DVN. So they do do it through consensus between multiple parties that the action has actually taken on the other chain and ZK bridges when I don't know like there's no good players who are doing it right now but I I think we all agree that at some point everything will be like ZK bridges because I will also make the case at some point that when we have like good fast ZK bridges along with uh single slot finality then bridging should be free uh and we'll talk about that in detail about how the where the costs of bridging are actually coming from. Cool. Uh so let's talk about all of these players. So escrow is if you've heard of resource locks that's an escrow in a way that you all you escrow way ahead in the p in the in the past. Um you have unis swaps compact you have

across spoke pool. So like all of these players have an escro system although it might not be explicitly marked as such. Um the escro should have time based permissionless refunds. If within two hours the proof doesn't come if within one hour a proof doesn't come. If within one day the proof doesn't come I need to get my funds back. uh because often like the destination chain action if it fails once it will not pass again because of expireies quote expireies and stuff like that and then it should listen to a crosschain oracle which is the proof system that we're talking about to settle and give the funds back the crosschain oracle can be ZK optimistic consensus faster proofs means faster settlement and lower fees all of the um most of the cost of bridging comes from the settlement settlement time because the uh because the person who's bridging

for you is locking up their funds. We have a slide about this next. The crosschain oracle provider should manage reorgs. Um because like the crosschain oracle is supposed to be the source of truth. So you don't want that the user does like that someone does a destination chain action for you. It gets reorged out but you still have paid the paid the person who did this for you on the origin chains. So it should manage reors. It should manage what flavor of finality does it want. Um does it want like hard finality soft finality like three four block confirmations? It's up to the cross oracle provider and how the escrow is working with it. One point to make here is that the settlement time does not affect the user latencies in the model that I showed you and like this is the model that most

people are going for. Um because the big bridger is instantly sending you funds on the destination chain as soon as your funds are deposited on the escrow. So settlement is just when this bridger can come back and claim funds from you. It is not when the user gets their funds on the destination chain or when the action on the destination chain is done. So yes, the claim with single slot finality bridging should be free and instant and we'll see uh we'll see that next. Okay, so the bridging provider uh in this case fronts the funds on the destination chain. it always needs to hold inventory and this is why it's also kind of always has to be bulky and I also think it isn't a good idea to do this within the um within the protocol itself because it always needs to hold

inventory if you want to do this model of you front the funds first and come back and claim them later because it this time somebody needs to provide this capital the alpha for bridging like how do you become a good bridging provider is you have to do fast cheap rebalancing again and finally the reason for why do why you have to do this the main cost of inventory The main cost of bridging is inventory lockup. So let's say I've provided you ETH. I've provided 10 E on the destination chain and now I have to go get my 10 E back to my original chain because I'm still want to continue providing the service. I'm I've run out of funds on the origin chain as a bridging provider. So let's say there's an optimistic roll up. So I have to withdraw using cononical bridges. So there's a 7-day rollup withdrawal period

that in that time my ETH inventory is not earning any yield. Um assuming 4% ETH staking safe staking yield. So that's seven basis points of ETH heel that I'm missing out on. And of course I can do this in faster ways if there's netting and there's someone else who wants to come from this side to that side and I can net with them or I can use some faster bridge. But this is basically the seven basis points is roughly like a little lower than this what the order of fees that you will see on bridging exchanges today. So that's why I am saying that if you have single slot finality and you can instantly rebalance using cononical bridges across chains then this should just be free because it is a lowrisisk commoditized activity. Um because you're giving there's no price risk that you're exposing yourself to. It is just giving

someone ETH on this chain and getting getting from this. So I'm pretty sure at some point like these RPC providers or these service providers will make this free as as long as they can rebalance quickly. Cool. And then this is a swapping provider. This is optional if you want to like have the must have nice to have and good to have goals that people were talking about. Um if you use your own inventory so you have ETH and USDC inventory because anyways you have to hold inventory as a bridging provider. If you use your own inventory then you're a market maker because you're giving quotes depending on your own inventory or swapping. If you use someone else's inventory which is like you use a DEX or an RFQ then you're then you're like a Dex aggregator. So you can choose any of these models. You can also

not like not want to become a dex uh become any of these and um use like a third party swapping service. But these are the four like basic basic actors in in a settlement uh system. the account layer which is the HTTP. Uh and I made a claim at some point and we'll discuss this next um is that if you don't care about one signature for everything, you don't need to make any changes to your smart accounts today to actually support interop because the reason is that interop at minimum needs n plus one payloads. You have to send at least one action on all of the chains that you're touching. On the origin chains, this action is that deposit into the escrow. On the destination chain, this action is um I want to deposit on our way. So you at

least need n plus1 payloads. If you don't care about UX, you can make the user sign N plus1 times. Otherwise, how to sign these N plus1 digests with one signature? That's the only question like that accounts have to solve in general for the chain abstraction schemes. There's two broad approaches to this. The big strct approach or the Merkel approach and we'll discuss this next. The account also has to kind of care about admin stuff. So synchronizing keys across chains, synchronizing upgrades across chains if your account is upgradable. uh because like if you're signing one thing for everything then for every chain then all accounts need to have the same key. So um this is also a pretty big open problem like how to synchronize this effectively. Um but key syncing key storage key like key store rollups like all of this is that part

the account also needs to take care of fund security. um it needs to make sure that the signature actually passes. It need to make sure that that if there's spending limit, session keys, all of that is upheld uh in all on all uh chains and yeah so this is why it's analogous to HTTP because it takes care of like this on what to put on this on top of this ST on on top of this interop payload uh and so it kind of adds headers to the uh interrupt payload. So all accounts already support interop on chain if they support arbitrary execution bundles which is like anybody can like anybody with a signature 1271 signature or like some kind of signature from the account can induce an execution on the um uh can induce an execution on the account uh which most providers do

because like this is one of the ways to make it permissionless. you don't always want to go through um some kind of relay gas abstraction pay master entity but um so if you're able to do arbitrary executions using your own account signature um then you can do this how how can you do this on every origin chain you make the user execute to the like ex make an execution to deposit funds to the escrow on on the destination chain you send funds to the user's account and then do the user's intended action like execute the user's intended action and then you come back and claim from the escrow claiming from the escrow does not need to have any um interaction from the user. So this by onchain you kind of don't need any changes because but this still has n plus1 signatures in the sense that the

user has to make one signature for each payload. How do we solve this? How to do this all in one signature. Uh this is what we call the big strct. So one one thing is the big strct approach. You take all of these original you take you make an array of payloads. You put them in a big bigger strct. You get the user to sign over the bigger strct. This this works. One uh one bad thing about this is that it leads to call data redundancy and if there's like some solidity optimizers in the uh in the room they realize that like most of the call cost that you have gas costs that you have on layer 2 are call data costs. So you don't want to replay the payloads of other chains on on a chain that you don't need it on. So if you're on base you only need base

payload but if you have this big strct you have to take this big strct everywhere because the digest will be calculated by this big strct. The approach that I like the most and the one that we use in the Ithaca account uh is the Merkel approach and I also think this is the theoretically optimal approach called data wise. Um I'll not go too much into what Merkel or Merkel trees are but basically all of the payloads become leaves in the Merkel tree. You just sign the root and then on each chain you provide the proof u proof for that leaf. Um if you have questions about this we can talk about this later but um I'm not going to go into this now. So in the in the ethica account like before we had even thought about interrupt after adding interrupt in the account itself the code differs less

than 50 lines and all of this was coming from verifying Merkel 6. So we could have done that that done it without but it would have the n plus1 signatures. Okay so the general flow uh this is also the last slide. How much time do I have? I have four minutes. Okay I'll spend left leave some time for questions. So there's this big bulky relay marketmaker structure in the middle. You can call it whatever. Um the first thing that it does is it induces a deposit from the user. So assume that the user has signed this one signature and given it to the relay market maker and it's just said like I don't want to care about gas anywhere. Take take this amount of fees at the end in the diff of the origins and the output uh and the and the destination and just do all of the

actions for me. I want I don't I won't go to any chain and do the actions. So the market maker takes the signature takes the payload takes a myrtle proof first goes to the account and says deposit to the escrow. The account deposits to the escrow. The escrow must emit an event. The market maker looks at the event. Okay, escrow deposit is done. What kind of reorg risk am I comfortable with? Do I even care about that? This will get reordered at some point. Most people don't care like in fact like across is like a first come first latency auction. So people are actually like going closer to the sequencer to hear the events quickly so that they can just hear the events and fill this on the destination chain. But all of the let's say all of the risk of reorg is priced in into this fees. So it it does

this first. funds are now in escrow then this I have this like weird like code block you send funds and execute atomically on the account you send funds and execute using you can do it multi call or whatever but make sure that you don't send funds to the account and then the execution doesn't go through and you can't get your funds back so you have to do this atomically so that the execution happens the DAP execution has now happened another thing that you make the account do or you do in some other way is call like this crosschain oracle to inform the origin chains that okay I've done the action that you've said so now give me the um uh give me the money on the origin. So this settler usually emits an event with like some hash some entity offchain which is the crosschain

oracle reads this event make sure it's good takes care of all of the reorg stuff then it writes to their origin chain counterpart then the relay market maker goes back calls the escrow the escrow checks has have I received a message from the destination chain that the funds have been received and the output has been done uh execution has been done if yes send the funds to the market maker that's where the flow ends so if like the I think the claim is Most entities that you look at like some of these entities might be like in within one contract within separate contracts but in the end most systems will look like this uh because these are the fundamental elements of the system. If you have a resource lock system then the escrow is just like within the account itself. Um but yeah you now now you'll

be able to identify like the different parts and what parts you want to add to your stack. Um yep that's it. Uh if you want to like build with Porto join the telegram. We're like actively helping our developers to um it's a new uh to to like build cool things with us. If you have any questions, I can take them now if I have some time. Go ahead. And there would be one leaf that would pertain for the transaction on base. How do you know which of the leaves? The mic. Oh. Um how do you know? So um so in the Merkel tree you said that um you would just um prove the leaf that it pertains to the one transaction you're looking for but how do you know which one is the one that you're looking for?

Right? Because each of these leaves will have like a like 712 digest. So like each of these chain leaves will have a chain ID embedded into them. Okay. So there's a structure which has a chain ID. You sign over the structure when you put that structure on chain. Um just you just check that this is the chain ID that you're on. So the chain ID is in. Okay. That's exactly cool. Uh yeah, I think we're also out of time. Thank you guys. [Applause]