L2 Interop Working Group #2

Transcript

right hello everybody Welcome to the call number two for the interrupt working group uh thank you very much everybody for joining and for being active in the chat it's been great I know that you know U maybe we haven't had as much progress as we've liked over the past week or two but I do think in a lot of ways um things are continuing to move forward um and I know I've repeated this a bunch but um yeah continuing to optimize for momentum I think is really important and and I do think we're getting there um so I just wanted to encourage us all to to not lose track of that not lose track of how important it is that we deliver tangible value to users over these next few months um

while not losing track of you know our long-term goals as well um and yeah thank you everybody for for uh keeping us all accountable towards that well cool uh so jumping into the agenda uh first up updates from the chain specific addresses group um yeah I'll start really quickly I guess the tldr from my perspective is that we've certainly spent a considerable amount of time going through the the trade-off and design space here I think we have enough information to make an informed decision um I would love you know anyone else to jump in you know share their thoughts from the group um or anyone that's

outside of the group of course um I would encourage anyone that's not fully up to speed to go through that group I'll drop a link here in the chat and I'll also I should have done this previously but I I'll I'll share a summary that I have I'll drop that right after the call um so that we don't have to spend time on this call kind of rehashing things we've already discussed but yes we do have a separate telegram group uh for chain specific address discussion and so I guess going forward I think the most productive thing at this point is for us to I think we can finalize this next week and and do it as think in chat um sorry um and yeah so I've been having conversations with we've been having conversations with all of the wallets uh

this includes metamask all of the l2s again like very close optimistic we can get this over the hump next week um yeah if anyone else from the group has things to add please jump in right now otherwise I guess I'd vote sorry someone's not muted um otherwise I guess yeah my vote and happy to be overruled of course here is that we keep maybe the rest of this async and move on to other topics uh just in the interest of time here but um yeah anyone else have anything to want to add on the topic of chain specific addresses cool okay okay

keep going going make sure everybody is muted please I'm getting a little bit of an echo cool um updates from the message passing group um yeah I'll just share a few slides that I put together really quickly um okay so uh here's the tldr of what we've been discussing so we did agree on the high level goal goals of this ERC which were the goals I presented um during the last call um we are right now working on agreeing on a message format um and all of this for all of this we're using uh 7786 as the

basis of our discussion um so right now we're talking about a message format that has attributes in it like described in 7786 so that's kind of the the lower level stuff that we're doing the goal of this standard that we're working on is to uh thank you to Francisco from open Zeppelin for this is we're standardizing application layer apis to replicate the user and developer experience of same chain calls in the cross chain setting so that is our goal specifically our goal is not to standardize a messaging protocol itself it's just the apis that devs will use and I'm of the opinion that this ERC should work to cover 90% of use cases really well and then edge

cases can be handled by ID messaging protocol itself but 90% of use cases means you know cross-chain function calls bridging Etc and it's not useful if this ERC is adopted but then people have to put a bunch of wrapper contracts around it because then kind of what's the use of a standard if people aren't really using the standard so uh that's my quick tldr of the message passing group um and then I also in this message passing group we had a lot of discussion kind of about the scope like what what are we achieving with this so I put together just a brief set of my ideas about how this ERC and message passing relates to the goal of like having something within three to six months so

the end goal is that we want fast trust trustless me message passing between all of these different layers and that is kind of that's in opposition a little bit to users getting tangible benefits in six months because a fast track messaging protocol is it's going to be hard for us to agree on it's still like very new um so to get to the left side we need to do things like standardize the data that's actually being proved on chain or across change we need to standardize the messaging interfaces we need to standardize how l2s read L1 data Etc all of these are super super important and we are going to continue to work on all of these things in the message passing group however it may be difficult to get real

real tangible benefit to users in the next 6 months doing these things so uh I'm just going to propose something which is that I think that adopting 7683 would be very good because it seems like it's in a really good place where it can be it can be adopted and implemented pretty quickly and this would this is good because it will give users more liquidity um you know better swaps it will make the whole ecosystem work better within a very short time frame and then obviously adopting chain specific addresses uh is what we're going to do as well so I think that these are the two things that can make the biggest impact in 3 to six months and then in the meantime uh we should work on these other things so I would like to get the message passing API ERC

um like decided on by the group within a month um so that we can start implementing these things but I also know that it's going to take a while for certain projects to be able to implement these on mainnet um because it's quite an upgrade to their uh current protocol so anyway my proposal is just that we work on all of these things in parallel then we work on standardizing the data approved and then finally down the road we'll work on standardizing the messaging protocol itself I think all of this should definitely be able to be doable within this year like I standardizing the messaging protocol should not be something that we're doing in like 2027 um but yeah basically tldr of all of this is that we should work on these things in parallel the message passing

group will work on um standardizing fetching L1 data the messaging API and the messaging protocol I think a separate group should handle 7683 and getting that make that to main net and um obviously there's already a group for chain specific addresses and yeah so that's just my brief uh my beef brief proposal there yeah Amad I'm not sure if you're talking but you're muted yeah so about that uh I wanted to say that uh I I'm not sure about the reasoning behind standardizing reading

L1 data um I think that each rollup should have its own way of reading L1 data and that we shouldn't try to restrict it to a certain mechanism uh because like as we can see the Innovation that's happening in the L2 space there is multiple uh approaches to this uh to this to this uh particular thing and yeah like I think it should be more uh open uh is there any re specific reasons for standardizing so that's the first question the second thing that I'd like to say about uh chain specific addresses maybe I forgot to mention this before uh but um I wanted to make sure that

whatever whatever approach we have for chain specific addresses needs to make sure that we can specify chain specific addresses not only in wallet interfaces but also on chain so we need to have a mechanism to um like read those chain specific addresses um on chain uh as well as uh on wallet interfaces so if we're planning for example to use uh chain names or ens names we need to have a way to represent those in um in uh in onchain yeah that's all I wanted to say um yeah so regarding the first point um

we can certainly discuss this I think that we should discuss it async and the message passing group so if you're not already in that um DM me and I can make sure you're added um because I think it's it's something that's a little bit further down the line anyway um I'll let Josh maybe comment on the second Point yeah I guess the short answer is fully agree um plans are in the works and yeah we should keep the conversation going on on that point um yeah and from my perspective I don't know if Hart or someone from across or Unis swap is on the call but I don't know if you could give us an update like how how quickly do you think that we could get something like that into main net across um across at least like a few different solver

networks yeah Ellie I I think zero AG is on here and I think I saw mark on here too um so I don't know Z if you want to pop into but um so 7683 I mean it's the contracts are deployed and like reference implementations for solvers are being written the part that I wanted to add just to maybe share how I think this works with what you're working on like 7786 I think these two things fit together like beautifully um the mental model I have is you have like the intent as this kind of order ticket for your intention of what you want to do cross chain and the settlement layer um which is esro user runs and validated that the

intent was filled um it should use a message passing interface like 7786 to verify that intent and then we can plug in whatever verification mechanism we want be it storage proofs ZK proofs optimistics proofs whatever um in in there and so like that all fits together really really nicely um yeah so yeah I guess we're we're Trucking on that um yeah uh I don't know if Ed was first or zero age was first um I think oh zero go ahead cool yeah uh first to weigh in on timelines like when

something like this would be ready to to really get into production use on um main net Chains It's a good open question and I think that it'll continue to evolve from here but I think that three months is a pretty good rough estimate when we might start seeing systems that can leverage these standards come online and actually um relay messages I have three uh initial thoughts on the EIP on uh 7786 that maybe I just haven't read it closely enough at this point but my

first is that just working practically with push based message passing one of the most important things to determine before you even able to send the message is how much is the message going to cost right and almost all message passing has some notion of like all right we're going to pay whoever's relaying this message or even you're gonna someone's gonna have to pay to ingest the message and dispatch it or whatever so some interface for quoting right of what's the estimate on how much this

is going to cost protocol fees or gas fees or whatever that means doesn't mean that every Gateway would have to use it some might it might not be easily um something that you can just put on chain or or even calculate but having at least a standardized method that matches the same syntax General syntax that tells you what you need to supply would be really useful and practice like a quote method oh go ahead no no no you finish you finish the second thing is it seems

as though this standard is mostly targeting push based message passing right where you are kicking off a message and then the message lands on the destination chain there's a lot of really interesting poll-based read specific um methodologies that are being designed right now right um and some kind of unification or clarification around this might be useful maybe we just really hone in on this being for pushing messages and leave the the poll based stuff as as

more abstract like as long as you have access to a state route you can submit proofs whatever but it might be worthwhile to bundle these these same principles and also spe specify like the interface on the receiving end right the the outbox on the destination chain and even in cases where there was no explicit message that went into a Gateway or inbox um specifying this is this is the interface for um receiving these messages or even just pulling from arbitrary State rots or

whatever so that's the second thing um and then the third question is around um if we want to specify some degree of substandards as part of this right now there's a lot of heavy lifting in the the data payload and um sort of just left up to the you know like exercise for the reader and I think there's going to be a lot happening in there and I worry that if we standardize around okay you're using this interface

to kick this off and you specify the CIP and hopefully there's a way to um derive what what that maps to in an non-chain way now what right and so we have 10 different gateways and 10 different um data payloads that are all doing very similar things so maybe we could work to standardize on a couple common use cases for messages that would be getting passed and um constrain that another thing that is um I think generally important on that front that standardization could help with is when end users are signing payloads that you want it to be

structured typed 712 data or something like that having uh standards on what they see gives users familiarity and um enables us to build uh UI elements and um improve the signing experience right and give more visibility um and signing an opaque data payload is not ideal right so granted you can always encode it and map it back to what you need but we should still try to standardize around what what action would end users commonly be taking or governance

commonly be taking that kind of thing and um standardize around that last thing I I just realized that we should at least address at some point is aggregation if you have if you want to leverage multiple gateways um um or some kind of redundancy in the way that you're pass passing messages for things that are really high um security risk or you just need additional confidence maybe that's something we'd want to integrate into this standard or at least have a footnote explaining how it would work anyway if that was a lot but that's

uh yeah no I appreciate that um some of my just like really quick reactions are that so in my opinion doing poll-based messaging um can be on the messaging protocol level it doesn't necessarily need into be need to be into the dev API standard if that's not going to be important for most of the use cases but we can discuss and we in fact are discussing this in the other uh telegram group um I would also suggest maybe we have an action item from this to like spin up a 7683 getting to production group that specifically is focused on that because I think that that is that work is very short term and it's going to be separate um from the general message passing Dev API kind of work um and then around the subst standards Point um yes I think

this is I agree with this we'll probably end up implementing these uh all of these messaging protocol standards and in different chunks as we come to agree on them uh Ed I think you're next yeah please please to I'm sorry can I give some element of answer for the previous question because as a notor of 7786 I'd like to answerer some of them that would be awesome yeah yeah so for the first point um the reason we did not put and this was mentioned quickly the reason we do not mention anything about the payment and the the quoting part in 7786 is that this basically yes we you need someone to pay for the the operation to

go through but this doesn't have to happen on any particular chain this payment could be said settled on the original chain it could be settled on the destination chain it could even be settled on a third party chain that has nothing to do with it or it could even be settled off chain like through some kind of Visa payment or something like that so while I certainly agree that uh this part of like you need to have to pay for the message going through the network should be standardized uh it's something that is in my opinion completely orthogonal from the message being sent and being received and that's why it's in our opinion out of scope of 7786 so that was the first things I like

I wanted to say for your second point which was push versus pull uh we we've think about that a lot uh the thing is that we don't find any example of pool based model where what is being pulled wasn't somehow pushed uh before like the data that you want to prove on the other end like I've never seen any case where what you're proving is some storage slot containing some stor some some value because like knowing which storage look to look for is is unrealistic and usually what you're trying to prove is some event being emitted or something like that but the emission of the event

could be seen as data being placed for for it to be fetched by a different chain so that's why we feel that even in what is usually qualified as p model the data that is being pulled was somehow placed here that's why we feel that a push model is simple and and works fine maybe people will have Contra argument and cont example and we' love to to hear about that uh in any way like it could also be the case that a push based model Works in most cases and additional standardization effort should be done with po model I'm not sure I mean the goal is also we don't want the standard to and you and there was a third point

that was about the format of the message the idea with 7786 is to implement something that is similar to a a call like a contract calling another contract like Unis calling anc20 contract for example uh and and and we want that to be a like an application thing not an end user so we don't think 7786 is something that would be used for let's say an EOS way to call something on another chain the goal is that it allows for perir of contract to communicate between for example a governor and some kind of executive that would be on another layer and therefore like the idea is that we just want them to be

able to pass arbitrary data and that data format like each each pair of contract that communicate to the bridge uh in my opinion should be able to to to set their own format of the data regardless of of what of of the bridge are using and the bridge should not uh try to to introspect this data and read it so so that's where like I think you you mentioned things like EIP 712 I'm not sure it's really relevant here those were my my my answerers thank you yeah I think this would be a really good discussion to have in the uh telegram group just because I know we want to get to other topics today so anyway um but Ed go ahead oh I think you're muted Ed

thanks um yeah I just have a question about uh sort of the expectations for this you said that it's a goal to be both trustless and fast which both of those are great um the question is how fast is fast in a setting where it's trustless is the expectation that fast means about the speed of L1 block time or does fast mean faster than L1 block time yeah this is a good question and it's I think we're open to discussion because I think people have different opinions um I believe Mark tinway at The interop Forum proposed that you should be able to do bridging within three slots or less um I'm not sure if he was referring to op slots or L1 slots in my

opinion the bare minimum is to have is for fast message passing to be on the order of 12 seconds for L1 block time that's the bare minimum and then we should improve from there okay thanks yeah oh sorry vitalic said that I'm sorry um all right any other comments about kind of message passing uh road map and plans if not I'll hand it back to Josh thanks so much Ellie if nothing else on there we can

move on to the next agenda item we have about 30 minutes left and three items so we'll be a little bit tight but I think we can get through it all um one second sorry okay sorry uh next up I wanted to share just a a brief highlevel proposal for how we can uh better organize the effort in our working groups this is sort of a process thing um yeah how can we better organize discussions over the next 3 months I definitely don't want to bike shed on like optimizing the process but also in my opinion clearly we do need some lightweight process to help guide us so the goal is still to accelerate but to do so in the most effective way possible where we land not

just on a suboptimal local Maxima but the correct solution for ethereum uh so I've been working with a few folks on this and and uh the awesome folks over at Wonderland who have kindly offered to dedicate some resources to helping accelerate uh and do some of the nitty-gritty work that we all know needs to get done but is just tricky to find the bandwidth for uh of course again it's important that we balance this acceleration with making sure we get the proper inputs here uh but confident we can find the right balance and and push things forward together so I just wanted to share that note U before I got into sort of how we're thinking about organizing things over the next three months again this is just sort of very high level um anyone you know jump in if you know there's thoughts um so yeah I

guess with all that said I can hand it over to the Wonderland guys who have a little um yeah weig share presentation on this yeah thanks J okay let me share my screen let me know if you're able to see this yep perfect awesome okay so as Josh was uh mentioning uh I mean there are a lot of efforts currently ongoing there are a lot of uh there is a lot of excitement uh right to get to get done and to get the right uh shipped as fast as possible to bring users a lot of value I mean we've been sort of lacking for the past uh yeah I

know few months uh regarding this so I mean we we get that um I mean yeah there's a lot of interest in this we just need a little bit of uh alignment uh pun intended and also kind of checking I know checking into a more kind of organized way to collaborate right like let's move into what we know I mean there is already a lot of effort put on like open software development and collaboration let's use that rather than just throw a ton of messages on a telegram group so put together uh I mean we all know that not just l2s but the entire ecosystem is not actually ready to

interoperate today right if we have the perfect apis the the perfect uh standards and everything ready it will also take a lot of time for people to integrate this and to ship this into production safely for then users to use and there is also education that needs to happen and a lot of things so this is something that we need to accelerate on but we need to accelerate on into the right direction and not generate like more confusion or kind of uh I know strand Us in local Max im as uh Josh was saying but kind of try to figure out the best POS possible way or path into this so there are a lot of efforts as you

already know uh I think we all are on the same page on what we want to do and why uh but I think we are lacking some common language and some kind of clear understandings uh regarding this um but it's something that is very easy to solve and I'm very optimistic that we can do this in a very short time span uh okay so shipping interoperability so we have uh this qu quarter one plus one month uh how very easy I mean we should Mo move to uh having our conversations in GitHub like moving everything into a kind of a forum or GitHub issues or PRS or whatever type

of uh collaboration platform we can still keep using telegram for ring this or if we want to have the ath R&D server as well um we can do these calls this is awesome I mean we should continue to be as public as possible uh sometimes theam might be a mess uh for new people to jump into GitHub is way easier and it allows us to kind of pinpoint specific things uh we should document a lot of the things that we're doing this is an effort that we'll do uh the first month so we'll gather as much information as we can we'll digest that information I will present those into GitHub uh PRS uh just so we can continue the conversation

about specific topics there and not get kind of confused or or entangled into other uh conversations or experimentations uh I mean avoid duplication of work we honestly I think we've been repeating the same things over and over for the past weeks uh this should also just go into some place that we can just point people to whenever we are discussing these things like or whenever these things pop up um and as I said like this should be similar to a development effort right we are building something for Builders uh and users uh and we should kind of use the same uh processes that we we' been doing and one of the most important points is also

like we need to build first the foundations uh I know that there is a lot of um kind of experimentation and crazy ideas and improvements that we can do for the current state of interoperability but if we did them then you'll end up at the same problem that we have today which is okay how do protocols and users interact with this and you will just create a new API and then we will have yet another protocol that we will need to support so that's not idea okay so uh starting from next month just in a few days um as I said we standard standardize the standards compare them uh kind of prime all the information to get conversation flowing

into the right direction uh we kind of make the nomenclature or the naming of things uh its own separate thing like we know naming is very very hard one of the toughest jobs for of every developer we don't give a about that let's just do that separately um as I said categorized efforts and we'll focus mostly on Primitives and properties of the systems um this is extremely important uh right now most of the documents I've seen don't necessarily include The Primitives and the properties of the system that they are describing they just kind of describe a

system and that's it and you need to infer the properties or The Primitives that this system is based on or is trying to achieve this is a key part of being able to kind of uh I know compare and start building on top of these things and just discuss about hey is this breaking any of The Primitives or the invariance that we design the system uh for do we agree on this invariance or not like that's a very very technical discussion and we can uh let say circumvent a lot of the the the chitchat around other things if we do this uh for March uh ideally we can get the a single first draft for every cat I think this is very doable we do have a lot of

information as I said already by a lot of great people uh from great teams um as I said as well like we should just focus on the things that are Ms I know there is a lot of creativity going around but I think we should just create a system that allows us to obstruct away all these kind of uh nice toab or or crazy ideas and just give them the just create a system that enables those things to happen but just for now focus on uh kind of only the the core aspects of what we're trying to build um we will start drafting a demo contracts and UI um a usern interface uh for these uh for

these efforts this should be very very simple honestly um ideally we get collaboration uh from I know a wallet provider if they want to else we just use like a a burner account or an account account abstraction contract on the UI itself so doesn't matter um and then ideally we can start the uh draft review process of the draft that we created um April our last month so we get these draft reviews we create the erc's uh or let's say uh ERC drafts uh we launched the demo we got feedback on that um ideally we polish fix and change if there's anything that broke or that

we up um and the things that we need to make sure here is that experimentation here plays a key role because we need two things we need one we need to make sure that the current um standard doesn't break existing protocols or doesn't um let's say kind of oh doesn't basically uh disable protocol existing protocols to integrate the standard let's say missing a feature a key feature or whatever and more importantly we need to make sure that all the experimentation and C ideas that you guys have do have a place uh in this new standard um things that we need to

avoid uh C some implementations uh they they suck like the standards and and I guess we've seen some discussion on this SC around this standards are not necessarily implementations they are just uh specs so we shouldn't be enshrining any specific implementation into the standards that we build the demo is just going to be an example for people to grab and to also experiment on and adapt as they see it fit naming bike shadding as well like this is a pain in the ass let's just not get hung up on naming things um there are not going to be any uh say protocol specific or partner specific uh flavor specs

obviously we're trying to build this as generic as possible um we should avoid uh kind of having the user or the that developers handle a lot of the complexity complexity should be uh hidden away uh it should be handled either by the standard or by the protocols uh which do have the technical expertise uh to do this uh one of the things Euro said which was extremely important is that uh payloads should be easily seen and analyzed right uh currently we were not thinking about this and this is an extremely important point because we were thinking for example 77086 is aimed at protocol developers it's not aimed at users it's an

improvement for protocol developers to not have them build more wrappers for other things etc etc so okay you just build an intergate 7786 and that's it right but the thing is users don't care about that and that's not the standard that we're trying trying to build we're trying to build a standard for everybody uh and ideally F being focused on user and inators which are the ones that are going to literally create the adoption for this um then to experimentation as you've seen on the telegram group if you're there like there is a lot of things that we can uh build on top of

this uh there was discussion around like how do we rebalance uh like the money flying around how do we integrate intents as Hart was saying like intents work right now they can be shipped but the cool thing is how do we ship them using the shirt standard so anybody like any new wallet any new t or or whatever can just say hey I'm using the interrup standard so I get intents for free because they use the standard so that's the end goal the it's not a good thing and maybe we are like literally shooting ourselves in the foot if we are going to rush implementing intents and then we are going to say oh by the way now you

need to also implement this new interrupt standard uh that also implements intents and then we also have have to and say okay intense now change whatever to support this new interupt standard so that's not the way forward in my opinion uh we also talked about the uh kind of multi multi SE of bridges and and out of M Bridges like everything here uh should be possible uh so pretty straightforward the end goal the end goal here is as we all know um we just want people to use uh ethereum right we just want people to

use what we are building as fast and as cheap as possible and we just want developers to be able to build on top of these things as fast and as cheap as possible uh and the one of the most important aspects of creating a standard is also that the distribution that you get when building on top of a standard is massive right when you build an year C20 you get amm you get wallets supporting and displaying your balance uh you get I know The Ledger thing is saying hey you're transferring this token and it shows like the sybol and everything uh if you build a non-standard erc20 like nonstandard token uh you don't get that and this is

exactly what happens with messaging protocols right now you're building a messaging protocol that does whatever right from here uh you won't get like wallets won't support you uh l2s won't support you users will literally don't know how to interact with you so that's the pain that we're trying to solve uh and that's it thanks thanks Kelly just one quick note I guess before we move on and if anyone else has things but um yeah open invitation to anyone else in the group for folks who would who do have interest to jump into more I guess what I'll call sort of the backend Logistics heavy things um yes myself at the EF others on

the call here Nicholas and others at the EF are dedicating more and more uh I guess I'll say all of our time on this going forward um but do want to also find the right balance to make making this a collaborative effort of course um and you know this is where Wonderland and others are coming in so um yeah we love to make sure that anyone else who who wants to to um get involved in in these things that that we just went through is able to do so yeah Nicholas yeah a quick message to say um on the first slide I think you were mentioning um posting messages on on Telegram and versus GitHub and we have like kind of a Cambrian explosion of of G of telegram

groups in the last few weeks so like just quick message the best way to use those telegram groups is to have like quick chats and whatever um is really important and really makes the conversation move forward you should try to post it uh on GitHub because this is where things are moving and um tomorrow in the next ACD I will introduce a bot that basically um crosspost everything to um ethereum magician so like every call that we have like this will be automatically posted on each magician and you will have summary and like you can take it from there eventually in the

future we can build on top of this and and we will have like um AI tooling that will help us dig faster in the in the information so yeah yeah keep in mind to like be as like FML as possible on Telegram and as um personent as possible on on GitHub it's PG am I unmuted um I just want to say that uh this is actually my first time attending this call uh and uh so what we were just saying with the Wonderland section here um like at polygon we have people who are doing every single one of

the pieces uh for egg lay right now and I think what my goal is because I am personally swamped is to is to kind of bring those resources out here into the public a little bit more so that they have a chance to interact with everybody um I think that there's probably pieces of this that we can really help support both like logistically financially um and brain brain powerwise um because our goal is also to like create this same world here so um the what it would be really useful uh for me is to make sure that we have a section on these calls at least occasionally where we're highlighting places where resources are needed so that I can kind

of identify those um at a high level and make sure that I'm just bringing in the right people from our team um because it's like not always my brain that's able to to to do the thinking about about these pieces yeah great Point agreed and I will um yeah follow up with you on that and make sure that we do have the this going forward cool thanks PG anything else or we can move on to the next agenda item cool uh next up rip 7859 Ian from polymer hey everybody can you hear me we

can oh thanks Josh so this rip is really just born out of a desire um for all rollups to provide a view of inside their execution environment of the L1 block that they are building L2 blocks off of um and the motivation here is that this unlocks a lot of capabilities that we're all familiar with it allows you to verify arbitrary claims about the L1 inside the L2 and it also lets you for example um when you're doing cross-chain transactions between two different rollups make sure that the two rups are building off of the same uh L1 history so that um if they if the L1 does Fork underneath one of them it'll Fork underneath both of them and they both can reorg uh together um so originally this started out really is

just like an informal call uh to get every L2 to implement EIP 4788 as it is EIP 4788 is a um a pre-compile contract that stores beacon block routs and a ring buffer and these can of course be used to verify arbitrary claims about L1 execution blocks as well um but this is actually pretty expensive and pretty clunky to to generate these SSC Merkel proofs um so then it invol evolved into using sort of a modified ring buffer that instead uh stores a hash of a subset of the execution L1 execution headers so that you don't have to provide the entire execution header as a pre-image um in order to access the

fields that you're interested in and accessing and using um to also reduce gas costs um but then after getting some feedback from uh Ty way from op labs um it's been reformatted to instead just standardize a set of interfaces a contract interface for exposing uh information about the L1 origin um which is the L1 block that the L2 is currently uh building off of um without specifying any underlying uh implementation although it does also specify some invariance about what does L1 origin mean uh what qualifies as a valid L1 origin um so uh yesterday in the chat vitalic made some really good points

that you know if you have l1s load and it's an l1s load implemented such that uh verification is deferred to settlement time so you don't actually have to prove every access in the VM um then that provides a much more efficient access uh to L1 storage reads and I completely agree if you have l1s load then you would not use this proposal to verify uh L1 storage reads but this proposal is more general purpose and provides some capabilities that you can't get out of l1s load um and in particular um it can be used to verify claims about State accounts receipts and logs and transactions in addition to storage slots um the way that it's

proposed here it could also be used to verify claims about historic L1 data not just the current L1 origin so it specifies uh similar to EIP 4788 it specifies retaining some number of historic uh versions of the L State uh and um it can also be used again to perform these cross roll up consistency checks to make sure that the two rollups are actually building off of the same ethereum Fork um which you can't do with LNS load you need you need a top level commitment that you can compare uh the storage value is not going to tell you what what ethereum Fork You're Building off of um and another thing which I think it would be good to get some input from from some of the larger um rollup builders on is that

I don't think L1 SL SL at least with deferred actually e either way you implement it um it's not going to be able to operate if the L2 sequencer loses connectivity with the L1 um and in in opack for example uh one of the reasons why they have this Max sequencer drift parameter which is basically like how how much the time stamp of your L2 block can drift away from the L1 time stamp one of the reasons I have this is so that even if the sequencer loses connectivity to to the L1 uh to an L1 node it can still continue building blocks for this amount of time in sort of it's like detached state which would not be possible with l1s load um any transaction that had l1s load which

required reading from an L1 node would not be able to execute and when when you know when the sequencer is operating in this detached uh state so I think that is potentially another difference here um so yeah I think those are those are the main differences I want to highlight and again really the the goal here isn't even really to get like this specific RP accepted or um included or implemented or whatever it's really just for us to agree that we need to have some view of the L1 inside of the L2 execution environment because it unlocks a lot of different capabilities and it's really just such a low-level primitive that personally it was really surprising when I figured out that like op stack and

scroll I think are the only ones that do it maybe I'm wrong um but yeah I guess that's that's the pitch and would be great to get feedback from people on this call thanks again feedback questions yep Ed yeah a couple things um one is it would be useful to uh in an RP here to Define what is supposed to happen on an lill three chain um right because there are plenty of those and um so yeah and I'm not sure what the right answer is but I think it's useful to think about that yeah um another one is um that uh in the uh

document as it is now there's this notion of an L2 block being derived from an L1 block um and the way that that works in many rollups um at the time is such that when the L2 block is made there is not yet an L1 block that it's derived from so I can clarify that a little bit um so if the L2 sequence or sequences a block at time T um at some time later let's say t plus 30 seconds that um uh that the the input to that block will get batch posted onto L1 right and so the Block in which that input is recorded on L1 does not exist

at the time that the sequencer sequences the block and yet you want it to the case that the full contents of the block can be computed at that time so even though it's true eventually that the block will be derived from L1 um the contents of the block need to be independent of that because that block doesn't exist when the when the L2 block is sequenced so I think talking in terms of the L2 having a view of some recent L1 block makes a lot of sense um but um and I think this is true in P stack as well as arbitrum that when a block is sequenced the L1 block that it will eventually be recorded in um doesn't yet have a known

hash completely agree and that may have just been a miscommunication and yeah I think so um could be yeah the notion I mean I think the notion of um having visibility into a set of um of L1 um execution hashes makes a lot of sense on L2 yeah yeah would you agree that um so necessarily any nent L2 block that's being built you have to be considering uh deposits in in the L1 contract and so the the goal here was really for whatever whatever L1 block cash that you were currently considering for deposits in order to contri yeah there's some notion of what is the most recent L2 L1 block that's

visible to the L2 at that time yeah yeah so I would yeah you have ideas about how how to better word that that would be great yeah yeah yeah great let's connect offline thanks oh sorry I'm just now seeing this [Music] message so I haven't really given that a whole lot of thought um but ultimately the correctness of this mapping needs to be enforced at settlement time similar to how like the l1s load reads could be enforced at settlement time it gets

baked into your uh chain derivation logic which is part of your Vault prooof program logic which is embedded in the L1 or the ZK circuit which is embedded in the L1 and verifies uh outputs at settlement time and so at that point is when uh when this correct the correct mapping is actually enforced um I don't know if that completely answers your question though cool well thank you Ian yeah no problem Pro did I was this a question

sorry I'm just clarifying the wording that OB uses so yes I think this is sort of the same point that we were discussing in response to my question got it yeah I'll definitely improve on this thanks cool thanks guys uh last up on the agenda we have Derek from Ron hey thanks Josh hey everyone um amazing meeting so far I hope I don't change this I'm going to share my screen

so at Reon you probably know as better as wet connect we recently rebranded from W connect to to reone and we have a wallet SDK mainly and an app SDK and and we've also done a bunch of Standards before and what I'm going to show now is it's a little bit Downstream of everything that's been discussed here basically in our wallet s we've um we we wanted to make it easier for wallets to actually consume and bridging and provide bridging to end users basically with the with the goal that the end user just sees one aggregated balance and can just use that across um all networks and we wanted to build that in a way that it also

supports EAS and all types of accounts so and taking some tradeoffs where maybe that's not the fastest latency compared to some resource locking approaches but without further Ado I'll share my screen and then you can take a look all right I recorded this earlier today can everyone see the screen yep take that as a yes so on the right side you see a sample dab and what we build works both with in wallet apps like a send button um where shortly we also support um cross chain addresses um but in this case I'm going to use a more difficult scenario where

you're actually using an external app I'm also going to get to a new standard that we cooked up to support that and so on the right side is our sample app it's a donut shop where you can buy digital Donuts in the middle you can see our Swift sample wallet so our wallet SDK is an all mobile wallets so we have sdks in all relevant programming languages this one is the sample wallet for Swift and our side you can see my portfolio um what's not worthy is that um yeah I don't have enough assets to actually buy this many donuts I want to buy six donuts on base but I only have um I only have three uscc on base

and one donut costs one usdc so let's see what happens yeah I'm just going to click a button here okay I'm clicking the checkout button all right and now you can see a little loading spinner in the sample wallet and the UI pops up and basically it tells me that um as part of this you're going to bridge funds in this case I'm bridging funds from arbitrum behind the scenes in this scenario this is using a cross I know hard is also on the call so giving you a shout

out and takes a couple of seconds and now it's done so some other features this thing can do is it can actually Source from multiple Source networks and then in currently just Bridges to the Target Network and so yeah it supports multiple Source networks it can also abstract stable coins so in another example I'm checking out in USC but I only have us on my wallet and yeah it's pretty cool another thing I want to highlight is the ERC 7811 standard that this app is using um the ERC 7811 standard addresses the problem that um currently apps like Unis

Swap and I know oxh is on the call actually block the UI if you don't have enough funds on the target Network so basically ERC 811 the wallet get assets standard is a solution such that the app can discover that the user actually has in more funds on other networks and hence you can actually fulfill the request so um we've released the wallet SDK of this about a month ago currently there's our wallet SDK as I mentioned is in all the wallets and yeah currently there's two top wallets that are integrating the solution and yeah I wanted to share this year I'm

looking for feedback and people who want to collaborate on the app site 7811 standard also looking for feedback on this technical approach or can can dive a little bit deeper into this what we have right now and how we want to improve the latency in the future so yeah thanks for checking it out thanks Derrik and yeah thank you for squeezing that in quickly at the end of this call here I do want to be respectful of time if anyone wants to keep chatting about this with you where's the best place for them to to find you you want me to drop your Telegram in the chat here I'll put my Telegram in the chat I don't use zoom so often but I think I found the yeah here we go cool so anyone

follow up with Derek directly and yeah we can end there awesome thanks everybody talk to you thanks Josh yep thanks Josh thank you see you thanks thanks so much just Dro it