L2 Interop Working Group #5

Transcript

uh welcome to the interrupt working group I believe this is call number five uh we have a pretty solid and packed agenda today which is great I think we can get through it though so we'll try to keep moving quickly I've shared the agenda in the chat uh I won't go through it all right now um anyone have any questions feel free to ask in the chat or just raise your hand jump in um so yeah so let's just uh get started first up on the agenda we have interops hey it's Helena from the Sprinter team um I don't know if uh you guys have heard or not but we're organizing an interoperability onsite in Athens on uh May 22nd to 23rd um I think Dylan's on

this call he's actually the point of contact uh so I'll let him jump in and add some inut yeah hey guys um so yeah like Helena was saying we're going to have an uh a community onsite on the 22nd and 23rd in Athens we're looking to do four tracks uh we want to focus on uh General interrupt so like we're looking maybe for just like one or possibly two of the tracks that be focused on uh L2 interrupt um but we have some pretty cool people involved already we have a form to uh for anyone that's interested in becoming a facilitator or um hosting a workshop we're trying to focus everything on like whiteboard sessions

um like nothing no like panels or anything like that uh just somewhere that like everyone can kind of get away from the noise and focus on on the work so um maybe Helena you can drop the the link for the for the brief in the okay cool um and in that in that brief there's a for see like just to gauge like the level of um uh in in how how much you want to get involved in the in the in the um in the sorry I'm on the I'm on the road right now um but yeah just uh just write in the form if you want to get involved um so yeah thanks I think that's pretty much it thanks a lot Josh for also like putting together the

Planning Group um we got some cool people that we've got on calls with already to to get involved further um so yeah awesome yeah I'm excited for it thanks everyone from the Sprinter team for helping to push interpolis forward anything else on mopolis cool any questions if not maybe just reach out there's a link in the chat thanks Orest and um yeah we can keep going to the next agenda item which is interoperable addresses formerly known as chain specific addresses so just a little bit of a Rebrand

potentially um yeah and I think we have Skelly here to share more yeah hey hey uh can I get sh screen permissions ah yes sorry always forget wor there you go should be good [Music] thanks okay all good do you see the slideshow yep perfect nice awesome okay so inal addresses um as uh Josh said this is a small rebranding older name whatever change specific addresses was a bit of a old name um so we've been working internally uh and on the public GitHub repo on this uh

thanks for all the people that also contributed and commented on the pr and the current work so we'll go as fast as we can through this I know we have limited time and this is a little bit of a technical uh presentation so feel free to we'll share this presentation afterwards and you'll have all the information on the public giab repo so don't go crazy if you don't follow everything uh here uh we can always have a an addendum call to go into more in depth technical um I know aspects of this if you guys want so uh what we have today as we know is uh kind of there's a lot of complexity in defining and addressing how uh let's say users um are referenced

on different chains we have a lot of existing efforts uh but we don't have yet let's say an unified Vision on how all of these uh different efforts and requirements play well together um this is basically the motivation behind interal addresses which is a revamp of an existing uh e uh so what we have is what sorry what we want is to have a deterministic link between uh the actual name or what the user ises and what that name is referring to in both theid and the address we want to have as much flexibility as possible both for defining these chain and addresses and also for defining the resolution uh to

allow more modularity and neutrality uh when it comes to choosing which name service or resolver you're going to use and the key goals for this uh were to basically as most of the standards I will work with is to erase kind of the ambiguity between having to choose one or the other uh being as I said resolution agnostic uh very important point being future proof uh so we are introducing this concept of versions uh while still maintaining a machine relevel format that is shared uh across all of these versions uh so always be kind of no breaking changes backwards compatible uh version so high level Concepts and this is the phras the names

that we're going to use for things in tral average addresses is the pair of address plus chain and optionally a a resolver specification which also has its own address plus chain the human reable names is what the resolver will output and what the user will see plus uh a hash that indicates a checksum of the address plus chain pair uh then obviously we have the target which is the actual address plus chain per of the user or contract or whatever you're actually targeting this does not include the resolver address and CH ID and then we have the the name resolver which is

uh we see the entity let for example ens or whatever uh that is capable of basically translating this and showing the user what uh something understandable to read not just zerox whatever uh this basically trickles down to just these four Fields uh Target gen ID Target address uh oops we are yeah adding undor don't worry about that and resolver gen resolver address uh as I said the two last uh fields are optional um this is a practical example on how you would let's say construct this and how the user will see this we have a specific uh chain ID

which is obviously short because we are using a specific um standard for defining this which we'll see in a bit the address uh the resolver CH ID and the resolver address which is these are the contracts of ens right now and the user will basically see that see that as we see below obviously not without the not with the colors but they can also add the colors if they want uh how does a contract or uh computer see this uh it's pretty straightforward so here do you see my mouse by any chance yeah we can see it oh nice okay awesome this is going to make things a lot

easier so you have this which is the version like this first uh two bites or four characters then this is the checkm uh and then uh you will have some other fields that we'll go into later this is uh the specification for which chain uh type we're going to use this is the obviously the number of the chain uh this is something of the pro I will'll see later address same length of the message uh same as the Gen ID for the resolver sameeh for the address of the result pretty straightforward as I said don't go crazy about this you will be able to see this in detail on GitHub and if you want we can do another more

in-depth technical call uh so this is the the cool thing right so we have this uh kind of version in here uh which will allow us to Define different ways for messages to be justed the main thing about this is that we always want message types to be uh let's say to not have any assumptions when defined but then through assumptions be able to com compress these messages and have these messages be shorter and more uh let say efficient or or less gas consuming or complex uh for either contracts to manage or whatever uh yeah users to to see or developers to see and hand um pretty

straightforward obviously I don't want to like get super technical so the one of the points um that we want to achieve is we know that Contra want let's say a canonical representation for let's say chain uh sorry address chain ID pair this is what we call version 80000 Z this is this eight is the most significant bit uh right um then there is uh the space efficient version which is just all zeroed out uh which has the most significant bit turned turned off or the the say short short version version one um and then

this basically uh specifies if you're using a resolver or you're not using a resolver as well um and this is basically how we are defining a resolver uh which right now like sorry which is open to um including different drc's in the future so this is super extensible um okay going to the specific example right this is how you would define an let's say the shortest version of an interoperable address uh version 0000 which specifies uh let's say an evm specific short representation that has no resolver so this is your checkm which

we can remove from here and just compute it on the Fly for the user interface but we are adding it here since it was previous previously on the spec but we are not sure about this so we'll love your input uh chain ID uh oops okay I think we're missing a one here or whatever uh and then uh the address so this is 32 bytes uh which most let's say applications that know that are only going to be interacting evm to evm can use today obviously it has some drawbacks which is you cannot specify chain IDs larger than this amount which

for the most part is okay but it might change in the future so if it changes you need to go to the uh other version like the long version but it's all good um so this is basically what I said said uh we are only like we are assuming all of these properties right so not supporting addresses longer than 20 bytes not supporting chain IDs longer than 48 bytes and only supporting this specific IP uh 155 um so practically in conclusion uh the main things that we want to achieve is to always as I said like I want to repeat this because this

is the most important part we need always a way to from the canonical format always kind of have uh a standardized way uh for not breaking the standard in the future as we continue to add uh new eips to handle different flavors of uh blockchains or whatever else that we will like to include uh for our let's say uh targets specific spe ifications or name resolver specifications as well or if we want to extend this standard to add extra data on top of these two pair uh two pairs of information uh for example uh I don't

know you can add payment information into an address right like hey uh use this uh as a voucher say or as a a receipt or a payment uh received for hey I need I need you to pay me I know 20 USD right so you can can extend all of this uh through different messaging versions but we're not going to discuss this right now the main idea for this is to do a very very uh yeah simplified MVP for this and then to build on top um so next steps um what we need from you guys and this is super important is uh Community feedback special thanks to

Frank here which is I think the only one that has been reading and commenting on this uh uh like yeah all all weeks and probably all days so thank you so much uh but we need more uh feedback from you guys if you have any questions if you need a specific technical deep type let us know we can do that as well um we need to ramp the the act the current ERC 7828 to interoperable addresses the authors are okay with this obviously we'll keep the uh credits and and like like we don't care about that we just want to like at least keep the same number which is a nice number I like that number we like that number uh just kind of rebump it a bit at these

modifications uh and after that we'll work uh on a full uh specification technical specification we are doing a bit of that on the actual uh GitHub repo but we'll continue on going into more like how libraries should work how uh basically yeah how how the entire system should behave with this and all the different types um and different configurations and then in parallel we'll work on a specific wallet prototype uh for two things one mainly to test the ux of this and figure out what's the best way for the users to both see uh add or reference these uh addresses and from the implementation side of things how the wallet does

actually find and uh basically digests this uh like inoperable addresses into the user format a cool thing about this which I didn't mention but it's pretty nice is that resolver contracts can actually specify how they are being resolved uh so we are like kind of abstracting away the how how resolvers behave into as a different like into their own thing right the standard doesn't say oh if you're a resolver you need to behave for example as the ens resolver behaves you can actually Define how your resolver behaves and have a specific uh module or library or

whatever for wallets to interact with your with your specific resolvers for example a Solana resolver or whatever different resolver uh DNS etc etc um that's basically it uh go into the GI repo we have PRS that we are going to be merging very very soon if not go into the and see the the current work and thank you so much awesome thank you Skelly any questions what is the best place for feedback and discussion definitely it so that would that be an issue

or it can be an issue or it can be comments on the current PRS as we're going to be merging them soon uh yeah I suggest going to PRS checking the current work and after merging probably an issue is best or if you have an already uh let's say a different proposal doing a PR uh with your different implementation or or ideas also works perfectly fine oh and you said can you repeat the open question about the check sums yes so check sums are now enshrined let's say on the memory representation but that's not necessarily because if we

know how to compute checksums we don't necessarily need to add them as part of the message we can just compute them and show them to the users so that's the open question cool all right next up we have a quick update on the excuse me on the open intense framework uh so yeah this will just be a quick update on the oif over the past few weeks we've been having some discussions focused on uh I guess making

sure that we have the best possible initial foundation for the oif uh before we double down on on what we're building and on on top of that Foundation and this initial Foundation I guess what I'm calling the V1 is great huge thanks to everyone who worked on that in particular the booto team hyperlane and others for putting out something that's yeah high quality and helping to set the initial vision for all of this uh but I think we've also realized that there's an opportunity to set an even stronger initial foundation and incorporate some learnings from the past few weeks um so yeah so with that all in mind we've been discussing what a oif 2.0 uh would would look like and a group of us have just been sort of uh

informally doing some initial design brainstorming planning around that uh this includes of course hyperlane across boot node but also leafi open Zeppelin and the Wonderland team uh so yeah leafi and open Zeppelin are a bit newer to the group of the oif but are definitely not new at all of course when it comes to these sorts of uh design considerations interop related work so yeah so very excited to yeah just sort of unify these efforts together and and have it all be a part of this oif 2.0 I don't want to over index on sort of like the marketing and and branding of this oif 2.0 uh I mean there is a little bit of branding there I suppose but it's it's really more about just making sure we have the

best possible thing here the best possible solution and L about like a big splashy hey we have an oif 2.0 thing I think we've yeah there's a balance of both but yeah trying to trying to get back to actually um shipping something here um yeah so I guess just consider this an open call to anyone else who would like to get more involved in this oif 2.0 um last thing I'd say is the goal of the oif is unchanged which is modular deployment of fast bridging infra to all chains this includes intents of course but also resource locks and just generally solving infra getting solving infra and um all of these all this good stuff to to all chains so if any questions let me know um just wanted to

share this quick update still a lot for us to figure out here of course don't want to oversell what we have but um it is I do think it's it's been it's been great to see the progress and yeah we'll of course share updates to keep everyone here in the loop as we continue to make make more progress on this cool if no questions or feedback Al righty sounds good we can keep going I one one quick question are there the um are there any like

specific changes that are being anticipated as part of this 2.0 or like modifications to the foundational Tech or is it is it primarily uh just bringing in a couple new uh projects to the team yeah yeah good question definitely some meaningful updates and and improvements um might be a little bit early to get into specifics unless anyone from open Zeppelin or leafi wants to share I think you know the yeah the the truth is that these are still decisions that that we're trying to sort of sort through um but yeah maybe maybe Jim here can can add

something I think you're muted Jim if you're talking or we can't hear you still can't hear can anyone else hear Jim is it just me okay yeah some kind of mic issue Jim now you're Frozen yeah Jim looks Frozen now um zero what I just say is like we've shared uh like some some things we think are gaps in ERC 7683 with open Zeppelin um just really like how do you standardize the the the settlement layer this is something that I think is probably better done asynchronously but it's just really looking at like what do we think

are the gaps of actually like scaling this and making go everywhere and then trying to build a 2.0 version that fills it that be that'd be my two cents yeah maybe maybe to add I think I I would view it a bit like as two goals actually one is that right and then two I think maybe Z refc in to right like our ongoing work with like having a like oif reference solver be able to support not just like intent protocol implementations in the oif but also other things like the Compact and so certainly it is of uh our interest uh to ensure basically that migration path um for like um yeah basically for like a reference Sol working well um I I think

that's arguably the biggest demand that we've seen for o 1.0 uh and I would be foolish to like kind of like forgo that for the 2.0 version as well and so definitely part of those conversations are to kind of like maintain um kind of that value prop um for folks like you yeah I sorry for I can you guys Hear Me Now by the way I new new laptop so permissions and are funky um cool so I would say like The Meta like I guess improvements of this new oif um like proposal or framework is that um like we saw the V1 of The Oaf repo and I just

didn't think I think broadly the feedback was that it wasn't comprehensive enough I think people wanted to see where potentially resource logs fit in where other verification methods could fit in that weren't messaging protocols like proof layers where offchain auctions could fit in Nom brought up you you know different solver implementations part brought the settlement layers and so he having like a very comprehensive view of that so anyone who's working on different layers that can contribute that to basically just like a full menu of things that anyone could use if they want to be building a bridge for their new chain super down with

this sounds great cool anything else on the oif 2.0 yeah looks nice where you are zero to age cool okay next up I was going to or I am going to share a work in progress uh road map diagram that I've been uh uh yeah sort of jaming on in collaboration with a few other folks would love to get some feedback this idea here is just to sort of share what

we have as a work in progress uh hopefully we'll continue to refine it over the coming weeks I'm sure we will um but again just sort of an open call to anyone that would like to provide more feedback on this document let me share my screen sorry one second find the right screen cool uh can you all see this diagram yep thanks um so yeah so let me know if any questions anything just feel

free to to jump in um if any questions anything is unclear here uh the idea is to sort of summarize at a high level um where we are and where we're going uh as you can tell based on where I'm showing this um this is still sort of just a work in progress uh diagram here it's need to make it a bit prettier and more complete but um yeah summarizing at the top of the goal fast easy trust minimized movement of assets across any chain in the ethereum ecosystem and separating it out here uh over the next 6 to 12 months in sort of 3 to six month chunks um just to kind of give some structure to things and

hopefully hold us you know timelines are tough but hopefully hold us uh and myself accountable to continuing to make progress and move things forward in a in a meaningful way for our users uh so zooming in here on months 1 to three standardization and Wallet work uh I guess is sort of how I'm defining it or framing it a lot of these things are things that I think were already familiar with 7828 we just went through interoperable addresses the oif 78 56 chain specific payment requests this is something that that Jack from from base has been kindly pushing forward uh we may have more to share on that soon cross chain messaging we have had a separate group on this for a while now

trying to consolidate the handful of sort of related and overlapping erc's on this topic 7755 again base team cross-chain calls 7785 moving chain ID registration on chain um versus the sort of current today being on a centralized GitHub list lots of benefits to doing so of course and then last up in this sort of next months one to three this experimental wallet prototype that I've been sort of um that we've all been yeah discussing and and teasing for a little while now um and we'll be starting work on soon I'll have more to share I know you we sort of just keep sharing that that that this wallet will be starting soon but uh for anyone that's not aware the idea is

not that this is a full-fledged wallet the idea is that this is a very experimental sort of proof concept perhaps test net only to actually get these interrupt features into people's hands let them play around with it things like interoperable addresses um and the oif and um yeah actually show hopefully sort of to yeah pave the way a bit in terms of what these things can look like uh from the ux side so so that's the idea with the um the wallet and the first three months as we get down here to these sort of second buckets buns 3 to six and 6 to 12 uh I think there's much more um yeah less un less certainty

around what things make sense here and what we should be prioritizing so again this is sort of a a call for the the group here to provide their input uh some of these things that you'll see in months 3 to 6 and 6 to 12 are a bit more exploratory um this idea of shared Bridge which I think actually Muhammad may be in the group here he's presented a really great workshop on back near the end of last year in Bangkok I think it's certainly an area that's worth more exploration um and other things here some of these things I think we do have more confidence uh that we should be prioritizing um and or maybe not huge effort it's more sort of a coordination thing but l1s load as another example uh and then just continuing to work on the

on the wallet prototype and actually at this at this uh yeah shipping some version of cross chain transactions last up I'll just go through this quickly again more exploration um what are other things that we can do to um actually ship seamless cross-chain interactions get these things into the hands of users um yeah don't have a lot more to share right now um and and very open to to more feedback on what people would like to see in these buckets so yeah that's pretty much just wanted to kind of walk people through that right now and happy to take any questions if there are

any cool sounds like no questions so then we can keep moving next up on the agenda we have uh the open intense framework SL espresso hackathon I think we have Jill here hey yeah great to be here thanks so much Josh um let me share my screen uh let's see can you all see this slide deck I'm now presenting yep okay I'm I'm I'm a Google meet scal I'm not not used to zoom um great so yeah this

is a little bit of a misnomer it's really an espresso hackathon but there is an open intense track to it and I think it's one of the first developer initiatives um since this working group got going that's uh taking the form of a hackathon so I'm just going to share some of the lessons that we've learned along the way so far we're halfway through the hackathon period and we'll have more to come um so yeah I'll share first some context and motivations behind us running this hackathon some of the details the progress and then where're all try and spend most of the time is on kind of the challenges and insights that we've had so far and what we see is some of the possibilities and next steps uh for

making the open intense framework more real for developers uh for those who don't know I think most of you probably know but we're consensus protocol for cross-chain confirmations um you can think of us has a more secure alternative to pre-c confirmations um we sometimes call ourselves an L 1.5 or confirmation layer because we sit kind of between the l2s and the l1s um and whatever this is the team we've got about 20 chains in the process of integrating and to date we've been mostly a B2B company like we've spent most of our time and our Cycles on the goto Market side talking to chains that already exist but we are looking beyond

that now to work towards onboarding developers uh to build and deploy their own chains um specifically right now using the arbitrum orbit stack and then of course using espresso for confirmation so there's a lot of great examples of teams that have gotten Folks up and running building their own chains of course all of the core Stacks like arbitrum we've also taken a lot of inspiration from op's developer experience your docs are chef's kiss if there's anyone from op on here um Celestia of course has a great track record of this stuff in their hackathons and with the roll kit project Ian hackathons are incredible as well so a

lot of yeah a lot of great playbooks that we're drawing from here um and we're trying to get developers ultimately to build more cross chain applications um so you know some of the examples that we came up with were like a cross-chain nft Marketplace cross chain borrowing and lending um these are all things that are top of mind for us and then the other goal of the hackathon of course is just to get developers educated on how inop Works in general and then you know selfishly specifically espresso so this is the QR code if you want to go to the website you can feel free to grab this now um and again the hackathon is running for this month um

it's got two tracks to it so the first track is is just getting people up and running and deploying chains again using the arbitrum orbit stack and using espresso and then the second track is really where the open intense side of it comes in um so this is kind of like the bonus round of okay now you've got some chains up and running let's actually build something uh across two of them or three of them or whatever um and we have recruited some great Partners to this hackathon uh I think that this has been a huge part of whatever success we've had so far has been the involvement of hyperlane across open Zeppelin and boot node um this came about like somewhat

organically we just shared what we were doing and folks from all of these teams reached out and super super grateful uh for your collaboration um we've gotten really great feedback from the developer community that were coring together on the collaboration with all of you guys um if there's anyone else here who's interested getting involved even at this kind of later stage of the game or who would like to collaborate on these types of things in future we would love that um I've mentioned a few times our main integration partner right now is arbitrum so it's the arbitrum orbit stack we're also working with infura and AWS um and it's going pretty well so far like we've got as of today 266 devs

signed up truly globally um we did a lot of work uh customizing uh our you know tweets and our developer push for all of these different regions and it's paying off so far so that's exciting to see really Global participation and again a good number of devs signed up this is our first developer initiative so we don't really have a base to build off of so decently happy with this so far we got about 4,000 people tuned into to the workshop that we hosted alongside node um and again had really great feedback on the workshops people found them really really helpful and then

we've had about 20 developers attending the first couple of office hours uh that we've run okay now for the more kind of interesting parts of this um some of this I'm sure will be old hat to those of you who've done developer initiatives before but we found that it's been really key for us to tap into existing developer communities um eth Global College Dow and developer Dow and then since arbitrum is our stack partner on this like they've all been really really key but what we're finding is that all of these developer communities are full of smart contract developers but really actually not that many who are deep on

blockchain architectures let alone the specifics of interop and intense um and my colleague Mariana who's the one actually kind of running the hack Aon um she pulled this stat that we've got about 600 million smart contracts deployed I think that this is just evm maybe it's across all VMS but you know relative to the number of actual chains deployed or rollups deployed that number is way way bigger right you know we we're looking at maybe a thousand chains deployed or in process of being deployed uh in the ethereum ecosystem um so the community of develop ERS who we can Target here without like

a massive onboarding lift is still pretty small um and then again there's even fewer developers who have a lot of context on intop and intents and are sort of prepared to dive in for you know a few day long or a weekl long effort on a hackathon basis uh to be able to build something real um with the tool sets that we're giving them so that's been a major Challenge and again you know a major Insight uh again my colleague Mariana who's running devel and growth she put together this slide which I think is really great just for the intuition behind this which is okay we've got this big wide world of web two

devs and then we've got a much smaller world of web 3 devs and within that the Lion Share are smart contract devs and like that's where they're coming from and that's what they're thinking about um and so as we think about growing the pie of developers who can be building cross chain and can be building with intense like we've really got to think about how we are doing education and onboarding and um you know that encompasses both finding where to reach people like who are the right people to pull into this of course ultimately we want to be growing the pie to Encompass more web two devs and pull them into the infra side of this but maybe the right

place to start is with the folks who are already familiar with blockchains just from the perspective of smart contract engineering and pull them over to the infer aside um I think that there's a lot of kind of interesting like developer relations and marketing funnel kind of questions here um and then you know of course as well we just want to be thinking about how are we ramping up those who maybe have already some context and Curiosity on the infra side uh to get them building real things and then support them going forward into the future um so you know some of the next steps that we've talked about just internally again we're only halfway through the period of the

hackathon but is just creating more developer resources um you know we did this series of Workshops the other day with across and hyperlane and boot node and open Zeppelin um can we help promote the discoverability of those workshops uh you know we don't even necessarily like want to just own these resources as repository with espresso behind it like we want this to be kind of more of a Community Driven effort so you know' be happy to contribute those workshops to kind of like the oif overall information in resource Hub um or can we do more of this as a group you know recording workshops walking through each of our

projects documentation linking it back to uh ideas for cross-chain application we'd all like to see built and help kind of cross-promote uh each other's work in that way um and then also continuing to work on and promote uh our own documentation each other's documentation one cool idea that Mariana had um was to consider at some point the creation of almost like an interop startup school you know probably many of you are familiar with the crypto startup school that uh a16z runs um where it's you know I think it started as like more or less kind of like a hackathon type of experience but then of

course you also get a lot of input onto how to think about business model how to build the company all of these types of things so again making sure that we're really capturing the developers who we onboard into building it in an infra and building cross chain um to promote them and make sure that yeah they have the support they need to take the next steps and take the projects forward and then lastly we will definitely follow up with more of the actual data that we've collected through the process and further insights when we have them in April as we wrap up the hackathon um we're really excited so far about some of the projects that we've heard getting built but obviously it's still early

days nothing has been submitted yet so we'll know a lot more in April and we'll be thrilled to share more then um in case you missed it here's that QR code again uh you're welcome to go to the site we have a whole list of ideas to build and we have a bunch more details on um on how we're running the hackathon but again I just want to give a huge shout out to this group uh and especially hyperlane across boot node open Zeppelin you guys have been amazing Partners so far and if anyone wants to get involved who's not currently um either in this or in a future project please let us know but it's definitely to me and to Mariana again who I give

full credit for running this whole thing uh it's definitely been a huge lesson so far just in how much opportunity there is to bring cross chain and bring infra blockchain infra to developers overall and then it's also been a huge lesson in just the power of having multiple projects banding together on these things um definitely owe a lot of the success so far to those of you who've jumped in so thank you if there are any questions I'm happy to take them um Mariana is also on here um she's probably even better to answer questions oh I see there's been a bunch

of questions in the chat maybe thanks want to jump in live to have conversation or since we're a little bit running short on time maybe we can um move the Q&A to async is that cool Jill yeah that sounds great thank you guys thanks Jill that's great cool uh next up 7755 updates from Jack awesome yeah uh here is a link to a little demo app we deployed um for anyone to play around with and then I'm going to go ahead and share my screen uh let's see all right I assume you guys can see

this yep perfect okay so yeah hey everyone I'm Jack uh I've been driving forward uh the progress on 7755 for the last handful of months um so I'm going to give a quick quick update today it is uh F well first update it's now r RC 7755 um it's previously known as R IP 7755 uh it's been categorized as a rollup request for comment so just just as a little I guess FYI it's like an ERC but for rollups um and that's how it'll be referred to moving forward some quick background for anyone who's not familiar it's a standard for cross-chain calls in the ethereum ecosystem but is defined uh or implemented in a way to uh like leave open support in the future for non- evm

chains um or the possibility for support for non evm chains in the future um the architecture is similar to a lot of the intent protocols that the ecosystem is becoming familiar with today it relies on three main components there are contracts for message passing uh it relies on offchain fulfillers for relaying messages to destination chains on behalf of users and then um there's a settlement layer for verifying call delivery as a precursor to fulfiller compensation and so the architecture is diagrammed here you can see just like really quick user for happy path user submits a request to a source chain outbox contract with uh compensation for the fulfiller included um the outbox contract then uh notifies

or alerts a fulfiller network by emitting an event if the request makes sense fulfiller submits the call plus any funds needed for call execution on a destination chain inbox contract and the inbox contract acts as a router uh executing the calls to their specified destinations and if all are successful it creates an execution receipt that gets stored in storage in an immutable fashion that cannot be updated or deleted uh in the future bwing any kind of chain reorg of course um and and the existence of this receipt is used as the target of a storage proof that the fulfiller can then generate after a delay submit that back to the source chain outbox and if the proof checks out um the outbox releases compensation to the fulfiller and this is made possible by state sharing between rollups and uh

ethereum mainnet so it's possible because um if the source chain has an L1 state representation exposed in its execution environment you can prove something about the state of L1 um and if the destination is posting its state representation to L1 um you can prove that and then subsequently prove something about the state of destination chain so that's kind of high level how it's working if you want to dive in deeper I invite you to read The Proposal so latest progress we have contracts deployed to test networks for Bas apoia optimism apoia and arbitrum apoia and all uh possible routes between those three chains have been successfully tested end to end so I guess my main update is it works which is cool um the contracts have gone

through an internal audit already and are in a pretty good State um in order to get it to this point to work we had to implement three storage proof verification I guess onchain mechanisms uh one is for op stack chains based on finalized State one is for arbitrum chains based on finalized State and then we got a contribution from the cross-chain alliance team uh of a hashy prover which relies on block header sharing from their Oracle aggregation Network called Hashi uh and that so that'll be really helpful for adding support for nonm chains in the future um if if desired uh also spent a lot of time in recent months working on adding smart Account Support out of the box

specifically ERC 4337 smart accounts um I have more information on that on the next slide so uh I'll talk more about it in in a minute but um the the standard now supports relaying user Ops for the destination chain on behalf of smart accounts um which is is pretty cool and then lastly I added a or deployed a I guess a demo app that I pasted the link to in the chat um feel free to play around with it it's not meant to be from the perspective of the end user where like for example if you're trying to bridge eth you just hit send and then it magically shows up on the destination chain it's purposely set up to be tedious and um like segmented step by step just so like you can get a

visualization of exactly all the steps that need to happen in order for that to work out with uh theem system it's very much meant to be like developer oriented so uh just to take a slightly deeper dive on the count the account abstraction support uh a concern was raised back at Devcon in Thailand that the architecture we or like I went over a couple slides ago doesn't support um permissioned calls so like if the call Target relies on message. sender based authentication um and the sender needs to be like the requester in that case then that wouldn't work uh and so you can get around that by uh submitting a user up to the destination chain and that's what's depicted here so instead

of submitting the request to the destination chain inbox contract a fulfiller could then uh submit a user op to the destination chain entry point and then there's a whole bunch of 4337 um infrastructure deployed and like widely accepted on many chains as far as I'm aware um that can be reused here and that allows us to Route the calls directly through smart accounts and get around that permissioned um issue and so yeah that solves that issue but then if uh if that's the extent of the implementation then you run into the problem where the smart account needs to be funded for gas and any funds needed for uh call execution and that kind of goes against one of the built-in invariants of the system where the

fulfiller should be the the one fronting gas and um call execution funds so we introduced a pay Master support um directly into the specif ific of the system that originally we were going to make the inbox contract the pay Master but because of the fact the inbox contract routes arbitrary calls for like the regular request throw uh request flow um it seemed like a fairly big security issue to uh have it holding funds for pay Master support So ultimately decided to separate that into its own contract that is owned by the inbox um and the paymaster like hooks into the regular 4337 flow um in that it is holding predeposited funds on behalf of fulfillers and keeping track of

allocations of those funds between the fulfillers um and if like because of the fact that fulfiller is the one submitting the call to the uh entry point from the context of the pay Master that's the transaction origin and so that's kind of like built in authorization to spend the funds um just by nature of the fact that yeah the fulfiller is the one submitting the call um so really all the pay master has to do is ensure the fulfiller has predeposited enough uh gas and call execution funds in order for this to like work out everything else about 4337 flow should work as expected after the calls are executed the enture point then calls back into the pay Master pay Master with a postop call um and one of the input arguments here is like the

call execution like result if it was successful or not so that allows the pay Master to then generate the store like the receipt or execution receipt in the inbox storage only if the calls were successful um to yeah uphold that same variant that we went through in the previous architecture diagram and this can be done securely because of the fact that the pay Master is owned by the inbox contract so these two addresses are um aware of each other so uh looking ahead that's kind of where things are right now we are at this a little bit of an inflection point where the contracts are in a um pretty good State uh I think this system has some pretty attractive qualities and a good combination of qualities um and and

they have passed an internal audit and now there's like there's a handful of questions that we have to clarify to determine if it makes sense to move forward with an external audit and like deploying this thing on mainnet to go through some of the properties like I think the system has uh like obviously an interesting proof system with storage proofs uh I think it's expressive in that it allows arbitrary call execution on destination chains um and any batch of calls uh at that it's also permissionless like anyone can submit requests to the source chain outbox contract anyone can run fulfillers um there's no contract owners in the in the system it supports uh permission calls as I went through on the previous slide um and it's pretty

good with latency as well uh it can submit calls in like one to three seconds but like from call request to call fulfillment on destination chain it's largely dependent on the Block time of source and destination chains like that are like relevant for the request so I think it's a compelling group of properties but there's also many other interop protocols that are very good on most of these properties as well um I think the two that may be set 7755 apart are the combination of the proof system and support for permission calls out of the box um and I guess the question is is that enough to justify continuing to push forward on the development of its own standard or are U surrounding interrupt projects mostly just

interested in like using a storage proof utility Library uh and like we can extract attractive properties out of this 7755 proof of concept um but existing interupt protocols already have enough of the properties that like maybe plugging in different properties from here makes more sense so um that's kind of where we're at uh still trying to think through all of the different I guess factors here but if anyone has comments or opinions on that uh I would love to hear from you maybe doesn't make sense on this call just because I know we're running low on time but I'll be around on on Telegram and would yeah would love to chat about it I think regardless on what gets decided uh there will be a fair bit of effort the next

couple weeks upgrade or like updating of documentation um and releasing blog posts just to spread more awareness and education about the system um as uh like it has come a long way from when it was first started the official proposal was updated last week so if anyone goes to read the 7755 proposal on the RP's you will be seeing updated information so um definitely check that out if you want to read more and I think that's all I got for um today so thanks for your time awesome thank you Jack cool uh last up oh I guess I will say for any uh further discussion async maybe we can move that to the telegram

group or Jack if you have a preference for where you want that discussion to go maybe just drop a message here in the chat uh cool uh last up we have a 7683 demo from the Omni Team all right are you guys able to see the screen you can awesome all right so omni's working on an ERC 7683 compliant generalized intent system that does more than just swaps or transfers it in theory will allow pretty much any cross chain call to be conducted so what is Omni real quick we're just a protocol that basically allows you to build a cross-chain dep but deploy it to a single chain and access users from anywhere using intents because it's very

easy to build a cross-chain app but all of the embedded interoperability Solutions is where all the complexity comes from and this causes problems and delays for for onchain applications so Omni is aiming to solve this problem through an ERC 7683 compliant smart contract system that allows apps and users to submit intents a network of solvers to go and fulfill it and our own independent uh cross chain messaging protocol that relays that fulfillment all this is tied together by an SDK that just makes it very easy to use so for this example we'll debut a cross chain deposit into a vault our quote system is fairly straightforward in our SDK you just specify the source and destination chains in the expense you'll basically

so say say the user is depositing 0.01 eth and they need to know exactly how much they're going to get on the destination they can quote for an expense and vice versa if they want to get exactly 0.1 eth on the destination they can quote for the deposit which is what you're seeing here a a quote for a deposit expense and then once you have that quote you basically just retrieve those amounts for the deposit and the expense package it into an order like so again with the source and destination chains context about the deposits on the source the expenses expected on the destination and the call being requested with its ABI and parameters and and Target address once this uh is issued this cross chain fulfillment will take

place because we're just ERC 7683 uh compliant we have our own order data packing and this is what that looks like we basically allow the user to specify who the order is for what destination chain and tightly packed information about the deposit expense and call structure um and just just in case there are any questions about this we have separated the selector so that we could maximize space uh utilization here because each parameter is only 32 bytes basically once ABI encoded and if we had that selector it would needlessly take up another slot so we've gone through and basically gas optimize this to try and make onchain intense as cheap uh and efficient as possible and then we even have the ability to filter based off

order status so using the SDK you can see from start to finish where an order is in its in its life cycle we have a bunch of links here I will share these in the chat right after the demo but let's head over to the demo uh let me blow this up a little more so in this little basic demo front end that we've built we've got a MOX symbiotic Vault they're reaking protocol in the ethereum layer one and I'm connected on Basia so I'm going to deposit 01 WRA stake eth into symbiotic uh we've got our Mack on H Sky we're basically quoting for the expense here so my deposit is going to have 30 bips removed and will be deposited in kind we'll open that up and submit it all right so the order gets submitted

our solvers are going to go and fulfill this order and uh upon inclusion we'll see the transaction on the destination here just waiting for it to complete there we go let's open up the deposit hopefully we get the Fulfillment here soon there we go and then we can see that my address called the open function deposited in 01 WAP stake eth uh this happened at 50116 uh we're still not indexed on the destination yet there we go and we can see the fill took place it deposited in the amount of

wrap stake eath necessary and deposit that uh deposited that into the Vault we were able to get this cross chain call from base aoia over to ethereum Hol sky in about 8 seconds it looks like um but this is highly variable it has to do with layer ones and layer twos Layer Two to Layer Two is obviously even faster um but yeah that's basically a basic quick demo we also have cross chain bridging I could bridge over a little eth from Bas seia over to arbitrum but uh I do recognize that we are out of time basically so if anyone has any questions feel free to share those questions um where did my zoom chat go oh I can't

see it while presenting um yeah that's basically it we are excited to start bringing this forward we have some public test net launch Partners here soon one of which notably is symbiotic and then we have a couple other partners that we've been talking to and interacting with and building this out for so we are excited to bring it to mainnet shortly everything has been deployed on mainnet um all of our contracts are open source we build everything that we do completely in public uh so I will go and share the links to our docs our website and our contracts and solver implementation in the comments for everybody this is great thanks so much and yeah sorry to squeeze you in at the

end thanks for doing it quickly no worries no worries we're excited to also start exploring the open intent framework now that our solution has basically come to Market we're at a point now where things are becoming actionable and ready so we feel that it's now a good time to start contributing to that discussion as well that's great yeah looking forward to that cool well we can end there thanks everybody for being here again I know we all have lots of calls every week appreciate everybody making time and we will talk again soon thanks all thanks thank you bye bye thank you thanks guys