L2 Interop Working Group #4

Transcript

so let's get started this is the L2 interrupt working group call agenda is in the chat or it will be in one second here we go one second and it is also in the ethereum PM repo for anyone who wants to follow along there cool uh so we have we have a packed agenda today with lots of great stuff so going to try to keep us on time if any section starts to run over too much I might jump in and ask if we can either continue async or on the next call cool so starting things off with a quick overview of where things are today uh just for anyone who's maybe trying to

catch up to where things are in the interrup working group I know we have lots of telegram messages it's hard to keep up I'm going to try to work on that as well provide some summary so folks don't have to read every single message uh but as a quick high level overview we have three main tracks underway at the moment this is number one chain specific addresses number two message passing and three intense on the topic of intense last week we did a public announcement for the open intense framework uh thanks everyone in this group for being a part of it still early days for the framework really the goal is for everyone here in this group to to shape it to help it be maximally effective we'll get a bit more into it as part of our first agenda item on on today's call um and then lastly

just a quick thing I wanted to share as a teaser we will soon start working on an experimental wallet to demonstrate all of the interrupt work that's been underway this will just be a prototype proof of concept purposes Uh current plan is to Fork an existing wallet but still a lot to sort through as as we get into this just wanted to share as a as a quick teaser for everybody um and again the sort of high level ideas to show what interrup actually feels like in your hands in a wallet we'll share more in the coming weeks and um yeah ping me if you'd like to get involved okay cool uh so yeah jumping into the agenda first up review of the open intense framework and I guess before

jumping in just wanted to quickly provide some high level framing uh to be clear this framework is not meant to be a finished product today the goal is again for us to continue iterating and improving on it over the coming weeks and months to deliver something that is maximally useful for all parties across ethereum anyone that wants to get intense should have should have an easy way to get intense um three main components of the framework open- Source solver implementation number one number two we have a modular Suite of smart contracts that Define the logic for executing and settling intents and number three the customizable UI template to make all of this more accessible to end

users so yeah I guess want to open this up for discussion there has been some discussion in the chat around like what this framework is or isn't and I think maybe just some general uncertainty around how things like resource locks may or may not fit in uh which yeah maybe that's just on us for not doing uh enough to sort of explain this well when it was first launched so I want to take a few minutes here on the call go through any questions or feedback um yeah and maybe just starting off if anyone has thoughts on things they definitely want to see be a part of this framework or unsure if it's already a part of it today um I know some of the the leafi team uh has been has been providing feedback so yeah anyone that wants to jump in first please feel free

to do so I can start uh so I um Alexander I work at Lei under the Catalyst intent system one of the big things that I see has an issue with the current way that the framework is post especially on the or on the reference implementation in general is that the reference implementation does not differentiate between what is uh required for an intent system to implement to be part of the framework or be built within it and what is optional and not required for building an intent

system that is compatible with the framework and easily integratable into their relayer as a result it's hard to provide feedback and design a proper system around it since a lot of these are either or that is not part of the standard or well we can change that later and for me it will be very helpful if what we actually designing to building a framework for and with is defined and then the reference implementation is an aid in understanding how are these Concepts that we've defined that we say building an intent system within this framework uh what does it need to have and this is how you implement it in our opinionated

way so you have two different kind of reference documented an un an un opinion one which is more of a a standard not a first standard because it's still somewhat opinionated and then you have the very opinion reference implementation which just to do references on the reference implementation here it has like high level of data availability within the contract it has maybe some schematics for how you integrate it but those are the reference implementation and not necessarily how the framework for building and system should be in general got it thanks

Alexander anyone else have comments anyone want to respond to Alexander feedback I have a question um since this the first time we are joining this group here um now we just got this comment from Alex um and um my question would be who who's leading this effort I I saw that hyperlane is is um has essentially pushed the um oif um who is who's in charge to make these changes who makes decisions like this is a pretty large group here um is there a

process on how things are supposed to be is it just request based and we take it from there or um yeah I think maybe also starting with uh what's the goal for whom are we building this framework what's the idea behind that framework who's supposed to implement it also because like there's an UI component and so on so I was I feel like it's a lot and then at the same time not flexible enough um so I'm I'm just curious uh bit lost on that sure yeah so there's been a small team working on this for a while now uh hyperlane and others have done a great

job at at getting us to where we are today uh this is a collaboration between many people now going forward I think in terms of who can contribute and how are we going to get to our ultimate goal I think it's like you said just it's an open uh open open repo that that anybody can start contributing to and um yeah I think I think it's something that we're going to continue to figure out sort of in real time the best way to do it so maybe not the sort of best best answer but we're kind of we're kind of figuring this out live I think in real time and for whom are we building this that was also a question Alexander had for whom is this framework is it for for DBS to have a bridge page or what's the

idea yeah so the starting off and uh if anyone from if Nom from Wonderland or anyone wants to jump in um I think starting off it is really about making this as modular and unopinionated as possible so that it can get into the hands of of many end users oh there we go it looks like we got the Denver crew here now plugged in um so maybe we can have them jump here in a second if they're able to but um yes so I think starting off for example with uh this should be something that l2s can uh can adopt it should be something that really anyone who uh wants to get intense can get intense through this sort of modular unopinionated framework I do think sort of maybe what you're alluding to is that

we need to perhaps be a bit opinionated about where we're starting off and and which users are we um yeah starting with so yeah actually Skelly maybe I see you have your hand up yeah thanks uh so Philip as you said like yeah this is mainly the first step or or an initial effort into having uh say some specs being translated into code I think the current team did like an awesome job on basically setting up all the uh the raw structure for us to uh start experimenting and also for for having teams um I don't know see in code what what we

are talking about there are still a lot of things that need to be fixed uh let's say standard wise there are a lot of things that we don't really have a way of knowing like yeah sorry for the cat uh that we still have no clue uh and we need to figure out one of the key things that we need to I'm so sorry one of the key things that we need to figure out are related to crush addresses and related to a lot of the user stories which I think um having uh the team in person kind of tackling this will be a lot of help uh with but mainly uh if you have any concerns or any ideas or any

improvements I would rather have you guys uh either use the standard repo the inup repo or use the open intense repo open up a PR open up an issue there uh just because sometimes the concerns kind of get lost in on the chats um yeah cat is is pretty happy about this or pretty angry uh but besides that I mean just take this as a first step this is not uh supposed to be kind of a a reference a reference implementation uh for the future but it's mostly a starting point for us similar to what we're doing with the all the documents and specs on the current interrupt repository it's a call

for action and call for collaboration cool thanks we have a few hands up you want to start with heart yeah sure thanks Josh um yeah my take on this guys is like okay intents are pretty useful people like this intent based bridging get this fast transfer to new chains do actions um we have a standard for it the 7683 standard which I think is like been fairly well received and uh people want intents everywhere kind of like the tagline Josh has been pushing uh philli I look at the the push here um you know like in leafi like when you're talking with us at across you want across to get to a new chain quickly and so if we can have a framework that makes it easier to bring

intense every where that's like a net good thing for ethereum interoperability where we can just Bridge Intense or get intense to every corner of the ethereum ecosystem so I look at this as a really freaking cool opportunity for us to standardize around a general framework um and have a bunch of settlement systems different architectures that let us get to different chains maybe with some different security properties it's great um and we can have a common solver Network um the ENT entire push behind 7683 was to take AC cross's solar Network and transform it into a public good that anyone could access and so to me this open intense is just like a nice next logical Stamper extension of 7683

which helps us get this intent framework into more places more quickly um and an early days effort so that's my take ell and n and crew in Denver hey everybody can you guys yes cool yeah just so I think give some context Philip I think if I understand your question correctly it was like who was this for like why was this created uh maybe to give some context originally when we started this about like three four months ago it was basically based on conversations where like we talking a lot of chains a lot of daps wallets like but everybody kind of wanted intents and there was like somewhat limited ways of getting it right so we actually talking a lot of teams who were building their

own intent protocol and product experiences and we saw like four or five working with us building top pip particular example but we felt like wow this seems very inefficient like what if there was a way to like share kind of like common abstractions and tooling that allowed these different teams to kind of like work together to still serve themselves right with an intent experience but not have to reinvent the whole wheel from scratch um and so that's kind of like where it started right and that's where I think you see some of the like kind of abstractions like oh hey a reference solver that can solve for different intent protocols oh hey right like uh contract so it can like be settled with different mechanisms and so that was just I think where it started like definitely the intent is not to like say like hey this will solve everything or

like there's like a particular like Grand Vision behind like what it could look like that's definitely is a very I hope so that like as part of this broader effort we can all collectively come together and kind of decide hey what do we want it to look like but it was really just like I saw a bunch of people doing a bunch of similar work and I was like hey it's easier if we don't kind of like duplicate efforts and that was kind of I think the main context whether that's right like yeah 7683 or other the intent framework already supports resource blocks already supports like non 7683 protocols like I don't think it's like opinionated about pretty much anything to be honest it's just like meant as like a shared tool chain for people who build in this space to get intents

everywhere um yeah um M Maybe just to because it it I don't want to push back too hard on on on any of this essentially I want to differentiate between three things the first thing is intense intense everywhere yes I agree or we agree right like totally behind it it is it is the best user experience it's that shine abstract experience the user shouldn't care essentially Lea has been all around all about shant AB faction like for three years right it's what it was all about getting in and out of any asset within one transaction that's what we've

been working on so intense like plays right up our La perfect the next topic out of these three is 7683 again should we standardize it yes absolutely we need the stand up for that so I we 100% support the move there's nothing against that however when we as a community decide to push a standard and and Market it we should be careful and see what's out there so before we raise the standard we should look left and right what is there there has been VI Shani from socket um also at Defcon um raising concerns around it unisoft itself came

up with the compact which is like a resource lock based Catalyst has been talking about um resource locks others have been too right so 7683 is an interface great from my perspective it is too early to promote a specific implementation it becomes even worse if we then build the oif which is the third topic I'm touching base on the open 10 framework that builds on an immature standard and and so 7683 as an interface is mature enough as an implementation it is not mature enough to then push an open intense standard and we essentially start pushing something out with tech depth from there day one is not a good

idea from my perspective and this is where I wish we wouldn't have rushed all of this right um and and have a clear discussion um what is the intent what is the interface how should implementation look like and then if we want to push for an implementation we should really just keep it as small as possible and not with UI and whatsoever because like all of that in the end of the day then gives a wrong impression I can tell you so leevi has been building a widget um like it's it's very modern it uses like most modern lightweight standards out there to build a front end SDK and and widget um and I know how much time it takes to maintain this to build this and

as the space is fragmenting and there are more and more assets and multi chain asset standards and so on like like actually being able to provide like to make sure that this is actually a go-to solution that's sustainable that that's a company by itself and I think we should get a little bit back to the drawing block and and yeah differentiate between what's interface what's implementation and what do we actually want to push and again for whom if you say nl2 wants to adopt this what does it mean nl2 wants to adopt this does it mean they have a widget they can put on their native bridging interface is that the problem we want to solve is that is that reasonable because then

suddenly we have that specific use case and Target group and then um others might get lost um and might not use that open intent framework so the moment we the moment we do too much we are narrowing down the target group and we are narrowing down the use case and that's why I'm I'm I think that oif might be a little bit too overblown and a little bit too early to to promote that strongly yeah thank you I don't think any of us would disagree with what you're saying but I do want to maybe before we go over to Christian Hart or n do you want to respond to any of that yeah I think um I I appreciate your feedback um I think um I definitely

don't want to like oversell the oif and like maybe the fact that like everybody came together to promote it makes you feel like oh man like this is like last call and like if I don't do something right now then like well like the train is running and like disaster is happening on the other end like I really justew I like the reason why we started working on this was really just like hey people are working on stuff and it seems like if they're working on stuff together seems better like that's literally it like I'm not trying to like say like oh this is like the best implementation like this is like right like everybody should switch to this like definitely not saying that whatsoever it was just like yeah like people right like everybody like not everybody a lot of people in this room

right have been working on these kind of like things right and like just as an engineer maybe I'm too engineer minded here just I see like every body basically doing very similar things and oh man it would' be so awesome if we work together on this so just think of this more as a forum for people to like talk to each other right like like already we have on the repos right to basically like have shared tooling and abstraction don't view this as like definitely don't view this as like oh the oif is going to solve inner off it's going to solve intense like this is how everybody gets intense definitely not like totally agree that that's would be bad but I don't think that's what it's intended cool thanks let's go to Christian yeah sorry Josh I won't yeah go okay just uh real quick I want to you

know agree with what was just said on a slightly different topic just in terms of like um this announcement going out and um how we're sort of like explaining the user value um I think the announcement uh doesn't really explain the value to users and I think that um there's a couple things we have to look out for one is like when we talk about intents in general there might be a lot of confusion because there's a lot of different usages of the word intents in different contexts and a lot of the popular usage right now might be related to AI agents and how they use intents um within like categorization um and so you know we may need to clarify uh when we talk about intents publicly that we're talking about like the intent to move assets across chains and maybe

illustrate that better I think also we have to be mindful and we see this a lot with like the support um requests that we handle at metam that like for a lot of users the different ethereum uh l2s are just like different chains and they don't understand like the opportunity to build really cool interoperability use cases specifically among you know layer 2 networks within ethereum and how that's different from like I don't don't know I could go to like layer zero or thorchain like you know and do like cross-chain swaps right and that's like a completely different mechanism right and that has nothing to do with like Metropolitan ethereum and the type of interoperability that we can build within the ethereum ecosystem um and so and I know like so the the main sort of like open intense framework announcement

kind of has a little bit of just like we are building a thing to solve a problem that is not really obvious to users and maybe the thread it makes a lot of sense to developers you know and I totally agree for developers the message is like we want to standardize something that will make it easier for us to align on like an interface for doing these things um there's also a thread from Stacy that uh ethereum uh account retweeted and it's a pretty good like explain and it's really good to see that um the one user value that she mentions is like you get fast uh bridging but I don't think that's actually the main user value because I think like you could have different interfaces and whoever does implementations will get that with different interfaces I think the real user value is like over time different

wallets and daps will be able to adopt a lot more routes for doing these types of uh bridging actions because there'll be a standard interface to do it and I want to call out like when um the W3 was pushing standards and sort of like socializing standards like web standards in the early 2000s the really common thing that I think was refective at clicking with people was like if the different browser apps align around different standards it's more likely that all these different websites and the different things that they're doing are going to work on your browser right and as long as everybody's aligning on similar standards um you're going to get less of what we were seeing in the late 990s which was like on One browser it's like oh you don't have this version of flash so you just can't load this

website right and you're like you're you're the browser of choice that you use is not compatible with every website and I think that that's the ultimate user value that we need to be driving it's like all of these different apps that interact with these different ethereum chains will be like able to more effectively um you know do these types of actions and have like standard interfaces for these actions sorry Greg do you mind if I say something immediately to it just real quick Christian it's it's great that you reference that because I very clearly remember that phase of that 2.0 and exactly that is what I was missing I was missing the RFC phase I was missing the request for comment phase for this this is why it feels rushed right like all of that could have gone down

like a little bit better by having by actually having that request for Comon face for that standard yeah I I think this is where I want to like make make a point about standards in general and I think this is where this thing this interface like came out and it's like probably more valuable than negative um I'm not sure how many people here have actually like really tried to push a lot of like standards especially like you know at this level that's more interface level versus like core protocol but you immediately get into paralysis like standardization paralysis if you just don't actually

have a p that like a bunch of people can on and just like rally behind to try and to iterate from and I think that's like the fundamental thing why this is in my opinion not a bad thing and probably the best thing that we've gotten out of this group is to say hey we're actually just like gonna continue to move forward test and prod and like continue to iterate and fix it because it's an interface it doesn't matter right like that's I think the beauty this isn't like a core EIP this is at the ERC level um and I think we actually just need to like remember that fundamentally it's fine you know like I've worked with so many eips to try and get them across they're very challenging um the fact that we actually

have a PC done makes this like infinitely better and easier for us to push forward um you know that's what we did with multi- injector provider right and like it worked it just took forever for wall to get implemented and this will take forever to get implemented across thingss but there is like user groups that need this new chains need this framework solers need this framework for the new chains um and frankly there's like nothing really that works right now uh like har said you know it takes time for AC cross and like other teams to like actually get into new chains and so this is like fundamentally like I think a very good step forward um yeah I'll just contribute my two sents in terms I think I think this

is cool this is a really cool effort um maybe like some historical background like I think we've been talking about in for like 3 four years now um and there's a bunch of products now in the space everyone's sort of building around it I think it is the right time for us to get more serious about standardization I do think that standardization is going to have a big impact um and so anything that moves Us in that direction is great um it does also feel uh great that there's sort of practical things being written right we started hosting these cake workshops and Cake working group about a year ago and I think that there was a lot of like great discussions and Alignment around the concept of intents and resource locks and the benefit that I would have towards interop that has

happened over the course of of the last year and at least I'm quite excited that to see that there's um that there's uh sort of practical code that that we're starting to have conversations around and in alignment regardless of you know the maturity of it uh at at this stage oh any other feedback comments I I would like just to I guess quickly emphasize that again like we're sort of in the I hear Philipe on the we missed a phase here in terms of gathering comments RFC um but I do think we're sort of in that phase now the idea is to be in that phase and and for us it's more about get getting serious around standardization

maintaining momentum and just pushing forward show showing this as a as a shelling point that we can all gather around but it still is very very early and I think anyone who's been involved with it to date is very open to um to feedback and finding the best way forward for this so did do you feel like you got some of your questions answered at least yes yeah it makes sense um I do agree that having an implementation pushes others to contribute I us want us to be cautious around how strongly we promote something and how strongly we sorry was it am I

not supposed to talk no no you're good yeah thanks keep okay um I I just want to I think we should um be careful how fast we push people to implement this um because if we if we end up that people have like huge migration issues and constant breaking changes um like people just stop recommending it right like you want to get it at least right to a certain degree so that um that we have certain things like maintainability upgradeability backwards compatibility all these things like think a little bit about that um before we get people implementing it and then they have a bad experience and like if if word of mouth

mouth doesn't work for it we have kind of failed um like these standards work WEA word of mouth right they find adoption because people recommend it so we make to make sure that it actually is a recommendable standard um so I would love to keep the implementation as small as possible and um make sure um we have a huge buy and I think we have like like the the buy in for the for the first push was very verbal I would love to challenge each of the contributors like each of of of the signers essentially to which extent they are implementing intense right now or have already implemented it like where

are they at um there are a few people that were very early with intense right like across um LED and then like we saw Mayan as a bridge um following up suit squid followed up as well um and lei as an aggregator has been supporting all of those from the get-go um but but then I'm wondering like like on which level do we have a buy in right now um and um yeah what what what the what are the individual needs and can we satisfy all of them with that one standard got it num um yeah I want to I think read some of the like um things that I guess

mentioned in the chat right about like I hear you philli that like uh right like people should be aware what they're getting right and what we should like what we should definitely not sell them is like oh they up is solved right I've never liked that term some people push it right like clearly it's not solved for the reason why we're all here because it's definitionally not solved um and but I think also what I think sucks is if you are like right if you're a new chain if you are like a new project right like being told like actually hold up wait let us go through the RFC phase of this standard like Des effort to only then get intense that is like I think right like everybody in Twitter talks about all the time how like ethereum is so fragmented and basically telling them hold up wait for

the RFC phase of the standard to get intense that that doesn't seem right either right and so again I think the point here is that like for people who want to get intense today right and get maybe Spen I don't want to put you on the spot but like right like if you're in orbit chain today right like you go out there and you go basically back hard hey can you please deploy My Chains right that's just like not a table world that we live in like we just need to be in a world where like people can get the drop experience that they want and maybe yeah right like in six months like heart will be like everywhere and that's great but like until then like I think people need the ability to get intense beforehand and this is just hopefully I mean again if this is not useful please

tell me but like hopefully this is a useful set of tools that allow people to get intense to their chain without having to wait for permission from anybody else my name was mentioned Josh I'll go for two seconds just since my name was mentioned just just like the way I see value here like we want intense fast everywhere remember unify ethereum that's Josh's job here Josh's literal job at the foundation is like let's unify ethereum and make it all feel like one chain again so like let's go right so intense everywhere faster is good right now what I see happening is we have a framework and a and a process by which arbitrum can now you know in their Universal intense engine they can go and point in this direction to use Open

Standards like 7683 and then extended in this intent framework to get intense to every orbit chain on day one that is awesome super chain can build a 7683 settlement contract that will let them get intense faster and cheaper to Super chain chains that's awesome agay can do the same thing hyperlane can bring it to all these other places this is all a great stuff so like it's not all solved but like good effort let's go let's move fast let's do something let's unify ethereum I think it's cool so that's my ring cry thanks har so let's go through a couple other hands are up real quick and then we'll maybe go to the next topic on the call and we can schedule a different call to maybe continue this discussion I do think it's an important

point I'm glad that Philipe and others are here raising these points I think what would be very bad we would all agree is to keep going without uh or to to move down the wrong path here none of us wants to move in the wrong direction um so let's make sure that we're addressing all these points and that we're kicking off the oif in the best way possible so maybe it's a maybe in for a separate call um Arjun um hey um so I guess uh one thing that I'm hearing is that it sounds like a lot of people are we're sort of all in agreement that we all want intense um and that we shouldn't move too fast on the oif uh approach because there might be challenges do we are there any like specific challenges that we want to

point out on this call because we have spent 30 minutes agreeing on that that first point yeah I think what we should do is is to do this async um I do want to make sure that we capture everything that's being brought up make sure we capture everyone's actual concerns that that are real concerns pointing to real things but maybe let's um if that's okay with everybody here let's do that async and and probably on on a separate call as well that works cool awesome thanks I think that was that was a good first discussion um cool moving on agenda item number two we just wanted to quickly touch on the GitHub repo for the L2 inop Skelly are

you here yes got threee um yeah so repo wise I wanted to also paste uh the pr Lei team has been uh discussing on this call so if you guys want to give that a quick read uh collaborate uh and comment there that'd be awesome just to keep the conversation going uh besides that there are a bunch of other open PRS by us and by other teams uh one of the most important ones um is actually everything related to um CH specific addresses and nomenclature so defining because I I've seen some people of concern about okay

what our intents what are we referring to uh when we talk about this or that so honestly having a way for us to just agree on the uh words that we use to define Concepts uh that' be awesome besides that anything that we can uh point to inside that repo for example current efforts uh or any as um Philips was was refering like any specific implementations uh for people using uh the open intent Frameworks or other standards that' be great uh as well uh so mainly this is a call for uh collaboration uh for people to start um I know if there is anyone

here that is feels like very strongly about uh Hey I want to uh kind of put more effort or or like specifically um I know set aside some hours to to work on this uh repo either ping uh Josh or me or anybody else at Wonderland and let us know we'll we love to have you and have more people kind of um yeah putting some some love on that REO thanks Kelly cool if no questions next up we have a presentation demo from layer swap on their intents

with atomic swaps guys [Music] hello can I share my screen yeah kind of interesting that you had all this discussion before this presentation so I will try to keep it as quick as possible but I'm founder of ler swap we've been operating a bridging solution for around two three years now and right now we designed a protocol that addresses like two main points the first thing is that we designed a protocol that is completely trustless so you can re us in a trustless Manor and the second important point is as you already

mentioned is that a new networks having really really hard time to get on board that into new uh into any bridging protocol at all usually they get just onboarded into like centralized bridging protocols like layers Swap and Etc so we want to fix that so we want to fix these two major problems we want to be bridging trustless and we want to be it permissionless for any network so how is basically a combination of different uh advancement in our uh space like it's a it intends Atomic swaps improved version of atomic swaps and light clients like Helios that you can run uh light clad

inside the browser for evm Trend so let me walk you through like it for from technical side and then I will show you a demo live in production but let's say what happens when Alice wants to transfer one itum from stet to optimis so I will assume that there is already a familiarity with standard version of atomic swap so I will just introduce the one that we modified it so what happens now is Al least discovered all solvers who are ready for uh solving this route like from St to Optimus one once she disc discover is she locks her funds in stet network in PR htlc contract she locks one itum with time lock so at this

stage the funds are locked nothing can happen with these funds only funds can be unlocked when time lock expired nothing else so then auction starts and solver start like it's offchain auction whatever happens like like someone wins this action and let's say it's a bob right Bob wins the action and what what he what he does is he actually does the htlc things so he generates the secret and calculates the hash based on the secret and LS one inum in optimis PR TLC contract now with hash loock and time lock so time locks work work the same so when Once time look you can loock the funds but the H loock is the new uh new

uh condition where if someone release the secret so in this block the funds will go to so it's embedding the contract but what happen right now is Ali is sitting in a dab in a bridging UI and Alice observed this transaction in optimis network she sees that there is a transaction for her with specific haslock that uh solver is already put the funds the everything is fine wants to CH wants to complete the transaction so now how she observes this transaction right so uh she she get from a regular RPC endpoint right so that's not secure because the for example the

RPC provider can provide you a wrong dat or RPC provider can be running a solver for their own so they can cud and give you some wrong cash Lo but for this you run a life client inside your browser uh with helos so you verify that for example for optim you basically have a verification of PL confirmations which is more than enough to be sure that RPC provider is not lying to you so once Alice verifies this she verifies it and adds this haslock in her original original commitment so right now her original log is with the same condition so we have PR htlc contract in stet in optimism with

same harl so right now what solver does is she uh he just went and released the secret in source and destination Network and the exchange is done so is completely done in a trust us manner so in in none of the stages funds were taken into the custody for neite so the last thing that I just want to mention before uh uh before uh uh demo so this protocol is completely permissionless what I mean is like it means like what it takes for a new network to join this protocol it just means to deploy a PR TLC contract in this new network and run a solver so

that's it so no Gatekeepers at all so let me uh quickly do a demo right now as we are running on time let's see let's go from arbitrum to optimism do I have funds yes and you will see here that basically second Yeah so basically user has to do two steps right now so right now I I am confirming the initial transaction so my transaction is committed with the time log and right now the solver is uh locking the funds for me okay so solver locked the funds so you can see that transaction is verified by Life tank it's because we

run helos for optimine so this is the loog transaction done by the solver so what I have to do is right now I just have to confirm it just confirm that this is the hash loock I want to use once I confirm this hash loock this actually sends the transaction to relayer which published to the network and right now in in few seconds my trustless asset exchange will be completed and yeah and that's uh basically it I'll be happy to answer any questions if you have let's let's see this finish so yeah and also you can see that basically the the ux for example

compared to Cross or any other protocol is definitely bad it takes more time it takes like two two steps but the uh initial our idea is that we we wanted to this be completely trustless completely permission less then figure out the ux so that was the basically the main idea so yeah that's pretty much it so let me know if there are any questions thanks any questions as always all demos do not work right cool maybe we can check back on this let's let's keep going for short on time um next up Aztec RFP for cross

chain interrupt hello everyone um hopefully you can see my screen but um very quickly um if you do not know what ask Aztec is a privacy preserving layer to uh we're going to be launching fully decentralized with permissionless sequences improvers um but less known fact about Aztec is we have both private execution and also public execution so you get to have Atomic communication between the private domains and public domains not just a privacy chain um as of today we have like sandbox which is a local Tool uh similar to Anvil that runs locally on

your machine and next up is our decentralized test net which will happen in a couple of months uh definitely in this quad um and I'm Rahul I'm a senior product manager at Aztec uh I lead our test net efforts and also our cross chain work um so I mentioned we are about to launch our test net why are we so investing so much in interop already isn't it a bit early um and my thinking here is l2's every L2 here has brought significant ux improvements uh but in their own siloed ecosystems like even within their own stack sometimes those ux improvements shatter um we think if Aztec sort of runs with the same Playbook of creating an isolated privacy

chain an isolated ecosystem with our own apps we kind of sort of have failed in my head like a true L2 is something that uh should help and compose on like the rest of the other l2s instead of creating our own sort of Silo EOS system um so what we really want to do is not just build our own privacy chain and stay in our own infinite Garden but rather bring privacy to all of ethereum and I sort of started thinking what's the easiest way to bring privacy to existing l2s to existing apps in these l2s um and the bridge was how I came up with the solution uh imagine if like every L2 like every L2 and most apps have been asking for privacy um this is

actually something that web to does better than web 3 U and interrup and privacy are two of the last sort of products that users have always asked for that do not really exist um instead of having each app and the reason they don't exist is like especially for privacy like if you want to have each app build their own privacy set it's a huge Technical and compliance hurdle um and there's so much stuff that you need to figure out instead you can just use Aztec uh and this helps with all of the interop efforts that we need to do for ethereum because like Aztec Has This Global privacy set which can have all of ethereum buil on top of it but what

would you actually do with this like why is this bridge actually helpful for the other apps imagine doing like some kind of ZK proof of passwort to get all of my defi interactions on arbitrum right this is actually something that institutional defi would require they want to know have some kind of an idea of all of the liquidity providers uses or imagine if you could sort of control all the assets on another chain using a private multisig on astec uh you could have like for example a face ID or like multiple different authentication schemes using whatever account protraction scheme you have in Aztec and then use this message passing bridge to gatekeep whatever interactions you want on optimism

arbitrum base whatever have you uh you could also do like ZK ml or ZK variance of compliance or regulatory requirements that you want like privacy pools limiting viewing Keys whatever you want um for any interactions you do on all of the existing eles um so you could have something really cool like you would Pro privately sort of deposit um into let's say a on arbitrum and then Bridge all of the proceeds all the a tokens so to speak back into Aztec um and you could use some of these new EIP 7702 or 4337 to automate this such that the user in some cases may not even need an ethereum wallet for um now this sort of all of this detail is already on this dog that I've

shared uh if you read through this RFP you'll see like an additional dog that goes into the weeds with everything that I've spoken about some of these flows like what you need to know about Aztec uh because Aztec is not really evm compatible to allow for this sort of during complete private public execution environment U one thing you'll notice though is I have intentionally not spoken about what IP to follow what do you want resource lockin do you want 7802 or whatever ERC Zips everyone cares for um and that's because we're kind of early if you think like 7755 is the right way try and build it I know Bas is already creating a bunch of PC's where they've connected 7755 with like Solana

and a bunch of other l2s if you think uh 7683 the right way let's try to build the private compatible version of this um it actually helps test your hypothesis if your EIP is actually alt like VM agnostic like can it actually hand all the other unique VMS that l2s bring like stocket or fuel or selfishly Astic of course um it kind of tests how rigorous all of uh the work that D1 line has to do for the L2 interrupt as well um I don't want to take up too much time but here's what I'll say like this is for me this is like a personal urge to sort of think about the user and instead of building like yet yet another chain abstraction solution or yet another

bridge that has basically similar offerings as everything else out there from the user point of view um and instead created something a bit more differentiated that optionally adds this layer of privacy so like all of eum can benefit from whatever other l2s are doing um it's also never been a better time to build privacy software uh thanks to various regimes and stuff uh so really there is like it has actually just never been better like Josh has done such a good job of coordinating all of this with each other we can just build on top of it in a much more exponential fashion than we've done before um so what what does this mean for everyone here um if if this is of interest to you you can um feel free to

read this you can either set up a proposal this is really a request with proposals on people who want to build cross apps feel free to do that otherwise you can tweet about this you can tell your friends or whoever is looking for like building a much more differentiated bridging solution or chain abstraction solution I'll drop some links in the zoom chat for people who want to follow this along um but that's it for my side I'm open to any questions I've left my contact telegram Twitter or X rather and this RFP I'd love to see um I'd be happy to answer any questions along this not perfect maybe just time for one question so we can get to the last topic here but yes Orest hey just one quick question

just in case I missed it when you say privacy this is all due to ZK and so it comes with the limitation that we can't share such State correct like the private um elements are all only visible to one user and can't interact with with an another is that correct yeah this is ZK so private shed state is not really possible but you have you interact that's why you also have a public side like all the public l2s so you can still h hi your identity basically you could also go a bit extra and off fisc the exact interactions you want to do like you could batch a bunch of swaps to hide individual swaps um and then there are more complex things that I'll not bore

everyone elsewh with but I'm happy to talk about it awesome thanks cool then moving on last up the broadcaster ERC from arbitrum Henry are you available perfect uh yeah I'm here I assume everyone can uh see my screen here but um just put this into slideshow so my name is Henry uh Chris and I are smart contract developers at offchain labs and we've written this uh cross chain broadcaster standard don't have a ERC number yet but I'm hoping we

can get into a little bit about how it works and what it does and why we made it so this ERC defines a standardized protocol for trustless cross rollup message passing with storage proofs so it allows contracts to broadcast and receive messages across upgradable heterogenous rollup Stacks through a simple unified API and by broadcast I mean that you know when a Dap sends a message it can be read and received by all chain granted they share a common ancestor so getting into some of the core components of the spec we have these two contracts

the broadcaster and receiver contracts there will be one of each of these on every chain and they are the contracts that daps directly interface with to send and receive messages uh amongst each other uh and across chains so broadcaster is super simple it just takes in messages and puts them in its own storage and then the receiver contract uh we'll get into a little bit about how it works later but basically it can process a series of storage proofs to read the storage of broadcasters on other chains and thereby uh receive

messages so we think one of the main Innovations of this uh standard are these provs and pointers and so basically these block has prover contracts uh contain an execute logic to obtain a Target block has given a home block has so in this you know picture we've got L to M it uh you can take a chain L block hash and get a chain M Block hash through verifying a storage proof assume the chain M Block hash exists in chain L Storage if that makes sense um so this is what allows us to support heterogeneous rollup Stacks

because they each have different like locations for where they're storing block hashes on parent and child chains and so on um so we have contracts that Define procedures for each of these chains and we also have these pointer contracts which uh basically reference the most upto-date version of the block cash prover for a given chain and that's what allows um this system to handle uh the fact that rollups can upgrade their contracts move storage slots around and so on so each chain like taking arbitrum one as an example will have two of these uh provs and

pointers they'll have one that whose home is uh taking arbitrum one there'll be one whose home is L1 and Target is arbitrum one and one whose home is arbitrum one and Target is L1 so you can go um you've uh linked arbitrum one to ethereum in both directions and so if you take a bunch of these pointers and string them together you can uh you've made what's called a route and a route is a list of these pointer contracts that Define how to obtain the block has of a remote chain from a local chain and so this is what

allows us to Traverse uh multiple chains to get to uh another so like in this picture we've got uh chain L and chain P are both l2s chain m is main net ethereum and then chain R is an L3 on top of chain p and by stringing these uh pointers together we can go from a chain L block has to a chain M block has to a chain P block has and finally to a chain uh R Block has which then we can use to read the broadcaster storage okay so you know putting all

this together here's what it looks like in one picture um you know you've got this broadcaster on chain R and you want to read one of its messages on chain L you have a Dap calling into the receiver passing some storage proofs and a route of pointers ABC uh and then the receiver calls into these uh block cash prover contracts to execute to iteratively like execute this procedure to get the block cash of this remote chain to then uh verify a storage proof again that to get you know a message so that's kind of the gist about

how the cross chain broadcaster Works how it enables a simple API how it deals with upgradeability and how it can unify heterogeneous rollup Stacks into a sort of unified system that's easy for developers so if you want to learn more about it or discuss it we have a post on eth magicians we have a repo where we have a reference implementation and as well as the standards text and we have also a blog post about it and an FAQ about it um I don't know if I have time for questions probably not but if we do I'm

happy to take some if not then we can move on thanks Henry any quick questions uh yeah first uh first just a simple question uh why is it uh uh why is it an ELC rather than rip if I understand correctly each of the rollups actually has to deploy has to deploy the contract in order to point the correct slot for its uh for its route so wouldn't it make sense to make it this an RP um I mean we're we're open to making it an RP and yes you're correct that like each rollup would have to to uh deploy and maintain these pointer

things um yeah I mean we're we're open to making it in rrc or rip if that uh ends up making more sense no I think just it seems it seems like a classy case for an Rip but uh uh doesn't doesn't matter as much just wondered uh and another question about um so another question uh about finality uh I do you take into account reorgs of various layer tools or finality or or long finality time such as waiting for a forward proof yeah so these uh provs should only get finalized block

hashes so you know if you're if you're going from if you're getting an L1 block hash from an L2 block hash it should be a finalized L1 block hash if you're going other way it should be an L2 block like passed through the entire uh fraud proof period and been confirmed and finalized on L1 yeah so latency would still be uh latency would still be seven days in the case of optimistic all up like using the canonic bridge that's correct yeah all right thanks sure Oris and how do you guys generate the storage proofs you mentioned to have a code implementation already

deep yeah we we don't have an implementation of like the offchain bits that would be generating these proofs uh we just have a reference implementation of the contracts um but we think that there will probably be you know like op stack and Nitro will have like some their own implementations of this thing that'll be deployed in a lot of different places so whatever offchain code is going to need to understand like how to build storage proofs that are compatible with those specific PR that's yeah one uh one interesting thing about this uh about rollups implementing this is that it also serves as a light client

contract right so like I mean h you would be you would be able to make view calls into it in order to prove the state of uh like to prove the state if an RPC gives you a giv you such a proof right I me you you could technically use it as a light client uh yeah that's that's absolutely right so that's uh yeah I'm so so I'm really glad about this because that's actually one of the things that uh we we're hoping to standardize in the future so that as part of the onchain config for every rollup uh you would have a you you would have a a light client contract with a standardized a ABI so that wallets uh wallets that use a use a chain their familiar with can

still verify it state so I think this this uh this ERC or RP could be extended to become also the Light client stand out we we we are a bit over time want to get to frano real quick oh okay sorry no worries thank you uh yeah so I wanted to ask Henry would you consider changing the interface of the receiver to be less tied to the fact that it uses these routes and storage proofs and that is so that uh like Ellie says some other protocol that is able to implement broadcasts in a different way is able to use the same interface and um yeah would you consider doing

that um I mean I think that you know if there were multiple uh broadcast protocols that had different interfaces like like the the routes and storage proofs are pretty core to how this thing work so I don't think they can really be removed but maybe there can be like some higher level contract that sort of acts as like a middle middle uh middleman thing could make sense um I do think it could be investigated though yeah yeah I'm I'm not saying you remove the routes just you would just make the types of the function less specific to what it's doing so it just use bites you know like

instead of the the struct and in that way some other protocol could reuse that okay yeah I see what you mean um yeah I mean potentially if like that's what uh people would find more useful then yeah I don't I don't see any specific reason why not okay yeah that would be nice to hear if anyone else would be interested in implementing this and then you know that would be one data point cool okay well I think we got through everything sorry we're a little bit over um also a reminder that we will be

streaming some of the discussions and talks happening in Denver I will drop a link in the telegram group and we will continue this discussion maybe even later this week the two takeaways that I just dropped in the chat I think we do for sure need more time to go through the oif address feedback all that kind of good stuff um and then also uh yeah there was some good discussion in the chat around cross chain token standardization and I think that is certainly something that could use more attention as well so anything else um please drop a message in the chat and we'll talk to you all soon thanks everybody thank you bye bye guys you bye