L2 Interop Working Group #1

Transcript

[Music] right uh hello everybody again thank you very much for joining uh before we jump into the agenda just wanted to say that I'm super excited and very much appreciative of everyone coming together here with the shared goal to accelerate interrup uh I think it sends a really strong signal that we are all here uh coming to the table to solve one of the most valuable things we can for users within the entire EOS system yeah I think we probably all agree that there is urgency here uh some of the primary things that we should probably not lose track of in my mind I just wanted to to start with here um

which number one to me is what problem are we solving and yeah not to to mark from optimism for you know really drilling this and and many others for making sure that that we stay focused on this and I I would really ask for the whole group here to you know as we go forward this call and future calls to make sure we don't lose track of that uh and then number two I think just as important in my mind is uh maintaining momentum and forward progress towards the solution uh we need we need like need to make sure that we land at the right solution here um but also think there is a potential uh failure case I guess where where we get bogged down in technical debate uh and and so so this to me is sort of one of the trickier as aspects

of this whole Endeavor to balance um and again yeah just would ask that we try not to lose track of of the urgency here as we evaluate what are the things that we we really need to have where should we invest more time and when what things are you know potentially okay to to come back to later I definitely don't have all the answers but I think we can all try to keep the group on track uh to our goals as we get into these discussions if anyone else has anything to add there um yeah feel free to jump in now or one other thing I was going to say just in terms of uh yeah sort of housekeeping let's try to do we do have a pretty good number of people here so let's try to do

the old uh raised hand thing anyone else have anything that they want to add cool all right uh so yeah we can jump into first part of the agenda which is chain specific ad address this I was going to start with just a very quick twom minute refresher and overview for anyone who may have forgotten or just isn't fully up to speed with things so let me share my screen I'll keep this short and sweet this works okay can you all see my

screen here yeah yes so yeah just again just just a really quick overview original ERC is 3770 back in 2021 drawing inspiration from that for 7828 which is the ens based version uh summarizing it here below this is a unified address format that allows specifying the account as well as the chain on which that account tends to transact the goals again let's let's not lose track of that automatic handling of of cross L2 sends just by putting the

correct address into the send field what are other uh mus haves of this design supporting all chains in the theem ecosystem this includes non evm it does not include alt l1s it does not include things that are and it does not it does not include things that are that are yeah sorry just clearly outside of the ethereum ecosystem what are we optimizing for human readability and intuitiveness uh and a scalable solution that supports the continued rapid growth of the L2 L3 ecosystem by moving chain registration to ens uh any questions or anything at any

point feel free just to to raise your hand um okay but what exactly will this look like answer is uh TBD we have some candidates um as you can see here on the screen uh this can be something like alice. at roll up. there's Alternatives I think from discussions that we've had leading up to this point many you know there's sort of um yeah varying degrees of passion or preference for each of these uh I think perhaps more and more more of us are sort of coming to the conclusion that um that any of these would uh would solve the problem that we're looking to

solve and that I think we could we could probably get comfortable moving forward with with either of these uh in my mind I do have a preference uh for something that again I think is a bit more human readable and intuitive which is the which is the top solution uh here with the at sign but uh hopefully we don't get too bogged down on on this on this question either okay uh last thing open questions here finalizing the format there's a sort of a a bucket of questions around the rollout of onchain configs which is 7785 we haven't really touched on that um and then compatibility with kite uh and this may be one of the sort of more tricky

things for us to to answer at least on this call but um we've had some initial discussions around that and I wanted to actually um yeah hand it off here to to some other folks who have been thinking about this maybe um maybe March in if if you're available yeah sure thanks so yeah we had a bunch of discussion about how this could be compat if and how this could be compatible with kype this of course still being analyzed discussed but the early idea is to have one Cape like prefix ecosystem and then everything under underneath being compatible with the ERC that Josh was just that Joshua

was just showing right so currently for those who don't know kype is the chain agnostic protocol today you can reach ethereum chains by doing a very human unfriendly EIP 155 colon chain ID colon address so this probably will keep working and the discussion is to potentially add a new add a new kipe entry somewhere in there that will have for example this ERC that was just shown but one one thing I would add to the group is I very much support the urgency that Joshua was talking about and I would love for us to even agree on the small steps right if we as a community can come and like at least

agree that okay this will be the the chain format this will I hope mentally unblock people to be like okay now that we have the chain addressing solved we can talk more about interop and messaging and like next layers any other thoughts on this question of compatibility with Kye what is the benefit of using Cape kpe um for this format so in this case we would I mean what will be shown in the in the later

things there are a bunch of wallets what not that are already using kype the way to think about it is it's Skype here will be mo almost like a fixed prefix and then everything underneath will be for example this ERC that Josh was showing right but this means that you'll still be able to like distinguish it from I don't know Solan addresses globally yeah I I just want to add like uh uh without going to the details of like this proposition uh of how to integrate with kype I think it's a great idea to be Kye compatible because eventually other blockchains also have addresses and things like that so uh

other ones and other EOS system so something that is open for one implementation by wallets just has a larger chance of being uh more easily adopted in wallets uh so I see the value there Lon yeah and coming from the wallet perspective I think um yeah I think when you have a multi-chain wallet with different ecosystems you know it's helpful to have some kind of um addressing there uh across those but I just want to clarify that you know from the wallet side if we were to basically the the use of the cape standards are mostly for like

low-level um uh um routing and all that but uh in the interface you know we would we would definitely uh be able to translate that to another um format and present that differently to users uh so that it's in an optimal kind of human human friendly um format any other questions around this question of compatibility or more broadly on chain specific

addresses there's a few questions in the chat see so yes this is depending on ens um but I think there's a solution here where we can support non evm l2s um maybe someone who has been thinking more deeply about this can oh actually we have a r did you want to jump in uh yeah I was I I'm representing Aztec which is not an evml to um yeah my just my question was like

it's unclear how exactly I could even help with Skype or disintegration Andreas thank you um um if you if you want to talk about interoperability that's train agnostic and that is based where that allows you to use any type of keys and and um um refer and and refer to you know different types of Origins you know like chains why not use D IDs it's a it's a it's a rade standards already adopted that's what's going to

be used in in um we'll make it um going to be used in in um um in regulatory um uh context especially in the um EU integrates with with with authentication framework works like that enterprises are using or2 open ID connect so and it's easily extensible for for for what we're trying to achieve here you don't have to reinvent the wheel yeah sorry maybe I missed the first part what you're proposing that that we use wi instead did the

IDS got it yeah let's come back to that um so there's another raised hand I guess maybe circling back to this question around uh ens and non evm l2s I would like someone from actually ens to to chiming I think there's a a more comprehensive explanation sort of vision here I see eskinder here are you available to to jump in yeah I didn't get to work directly on this so I don't think I could speak uh to it to the same degree as Jeff who worked directly on the standard um but I

would say is like non evm chains broadly speaking like ens is building towards that support and one of the goals you know for us broadly with name chain is is to be able to you know handle for non evm so I don't see this as a permanent kind of like blocker um but something to build towards and having this interface to day I think we'll make it easier down the line thanks uh yes common so there's 7 s uh or 7828 but there's also

7785 for uh the chain ID uh erc's and this also proposes making the hashes 256 bit Longs in the long term and making the chain IDs hashes and this would allow multiple ens so that a single ens contract is not fully enshrined and uh it has similar with properties yep exactly uh and this would rely on that first have any wallets um chimed in here

because it seems like this is about um how accounts and addresses are expressed in in wallets and shown to the user so I'm curious if any have already expressed support or any kind of concern any of the wallet teams want to jump in here yeah so so I'm representing fire blocks an Institutional wallet side uh I don't have like I mentioned earlier the the kype uh uh uh orientation is interesting like again I don't have a specific opinion on the uh suggestion

because it's the first time I've seen it but uh that's just something that I mentioned uh using dids is definitely like a different direction I'm not sure if it's something that is like I'm not sure what is the Practical suggestion for dads but dads are very interesting from like the wallet standard space I'll have to say but again like I don't want to derail uh that conversation if like it's not a clear Direction and IIM mean um from Phantom we use diip internally uh it's very useful not just for addresses but to express to identify different resources

so that probably won't change but as has been stated here and in the chat it's not human readable so we don't show that to users at all um adopting some other standard for addresses would be would be great and we are open to the idea of adopting some other standard yeah from the metamask side um yeah we're planning to uh or we're already using uh some Cape standards uh in in our wallet uh and have kind of weighed in on that a bit uh to see if we can make that easier uh on the ethereum side and uh again I

think when it comes to displaying to the user I think there's a lot more flexibility um to translate anything that's kind of at the protocol level to be uh displayed differently and and that's where we're looking for you know also some standards in the industry and maybe it's worth adding that a lot of the conversation between wallets actually happens on the kyes level right because so like a lot of the times us and mam mask would meet is in the kype wallet connect setup so I think that's like a important aspect to to mention that our conversation is a lot of times happening on that level of how do we support something that is across all chains to improve user experience well anything else on this

chain specific address question and DS which is something that's actually I'm I'm not super familiar with Hudson yeah um I just had a question if anyone from uh ens was here someone in the chat I think Mohammad asked uh like is the ens governance process would that theoretically be involved if this uh ERC goes through or if there's anyone who just might know in general yeah the en government should have no impact on this uh the name can't be like revoked from ownership so I think it comes down to like what is the ownership structure and how is that secured versus like the Dow being able

to like kind of snatch back a name that's not something that's possible today um additional context on this is we're actually rebuilding the ens like core protocol from scratch for the name chain roll out so we're going to be going through um kind of like a migration so there will be like a whole new suite of audits and everything so everybody should be able to see kind of like um the result of those Audits and get additional confirmation on like the security of name ownership got it okay so this is more the standard will be like very well integrated into the like uh name chain that's being built from scratch so that

so that's actually like we're not giving fees to ens as we're doing these names and stuff like that it's a standard being applied right yeah yeah exactly and like the one of the things that's really nice about this for ens is is we have to serve all of the l2s and right now the lack of standardization around this is obviously like a barrier for us to be able to do that so I think this would help um from that point as well thanks yep Mark did you freeze mark just wondering

if anyone has started prototyping this at all not that I'm aware of hey um sorry just wondering if anybody has started prototyping this at all yeah not that I'm aware of um is Mark lagging for anyone else is that just on my side okay cool I heard it twice yeah sorry Mark you're you're lagging a little bit but we heard your question um yeah I don't think anyone has gotten to the uh implementation cool I think you know is anybody here interested in trying to prototype this because I think that um we'd learn a lot from that and uh you

know it's like in the in the bottleneck for for getting this into production yeah um the ens team obviously down to help prototype this um I think I think what's more impactful would be like getting some commitments from the l2s to try and help um get their feedback and like actually put something together to see how see how it looks but uh we're definitely down help about that you should clarify a little bit more what do you want to prototype because on one side what we're trying to agree is how we're going to name things and then the best application would be I

guess some somewhere in wallets probably where you know you could actually use a wallet and that will resolve it and based on this will go to one L2 or the other where imagine a library that can just take a name and then resolve it correctly so just to to get on that um I think it's both a question at the L2 level or the support but also at the wallet level because imagine if you enter that into the like S field um and the wallet itself doesn't support the L2 um will

your tokens just disappear uh for users that can be like very tricky to understand I think one important question is is if you want the address resolution to be on chain verifiable or not because like if it might be easy to make that service that Mark mentioned as a offchain service but to make it onchain verifiable on every L2 is a story yeah vitalic replied in the chat

that this should be requirements I think that was sort of what we've been operating under but right like I think one of the longer term goals here should be to move toward a world where it's possible to have a universal L2 client where like as a wallet you can write or you one piece of code once and then every compliant L2 uh should be able to just uh like like it should be able to interpret every compliant till to um automatically using like config contracts and whatever other missionary we figure out over time

so goad sorry I think you go for it ask yeah I was just going to see if there was um more consensus around people making a commitment to try to prototype something um sounds like metamask would be interested ens interested maybe if we had two or three l2s who wanted to maybe have like a smaller working group that could be a really useful way for us to kind of continue this I can talk for St Network I think would be interested in U collaborating on that or status wallets I need to

check up with the guys to see if this something that they can integrate in their pipeline but I know that uh they have been working on that for a while so I think if we come up with an actual good way to do it they will be more than happy to uh prioritize that versus whatever effort they're doing at the moment all right awesome anyone else interested sure happy help from zi sync hopefully you'll not need too much from us but yeah I don't think it will be heavy I think it's more just um proving it out right I'm also down from uh op

Labs amazing aesome yeah this is great thanks eser for pushing on this yeah so maybe what we can do after the call or if anyone wants to spin up a group I can spin one up have a chain address implementor group and uh yeah going on that for anyone that wants to jump in Andreas yeah so what do you do with when you have like with the with the with the R1 curve so how do you support then multiple U different um different curves I mean if you if you have that already implemented at the um L2 level and people are using it then you're you're you're locking them out of the um of that of that of that interrupt so I

think one of the key characteristics it must be key agnostic yeah I me I think like a long term this stuff should be designed around a abstraction anyway well we have a few people with hands up just trying to be mindful of time we do want to get to the second agenda item so maybe let's try to we'll try to get through the hands that are up and then move over to the second topic uh Muhammad yeah I'm just trying to understand from a rollup perspective or like a chain who wants to support this standard do we have any idea or like rough proposal how that should be like the unchain

verification like are we expecting to deploy a system smart contract or pre-compile that gets uh gets the like address and return the result of the resolution or verify something with that or are do we still have to figure that out together good question uh vitalic or anyone else have thoughts here we can also maybe this is something that we need to iterate on in the implementers group prototypers group so maybe we come back to yeah give us give give us a while to figure it out there are a bunch of technical details

in there so okay uh fro yeah uh this might be a technical a technical detail to figure out later but I get a feeling that there isn't a consensus on the way that onchain config is going to happen um the erc's are are using ens records um but then vitalic in the chat also talked about uh confi contracts and they seem to be mutually exclusive so is the is any one of these the like the true way that there is consensus or is this still something we're figuring out yeah my understanding at least is

that we are moving forward with the onchain config ERC have the number in front of me right now but but that's that's how we're moving forward um some things can still be in flux but uh yes 7785 um that's my understanding okay so ens records correct yeah I I have one question on this is how we ensure that the ens record are evaluated the same way in the different chain how we um ensure that there is some consistency across

chain yeah thanks another good question if anyone else has anything to chime in but maybe this is something else that we can um that we can come back to I am I am collecting these questions and promise we will get back to these if it's okay with the group maybe we can uh yeah move forward to the second topic which is the collection of cross chain messaging ercs we have um and we have a few groups here today that are going to share thoughts and perspectives on that would any of those groups like to anyone want to go first uh yeah I can go first thanks um could I share my screen it's

okay if not but uh it looks like sharing is not turned on yeah s should be fixed now okay um okay one second um all right uh can you see my screen yep y okay perfect oh okay sorry and now it's like

uh I can't see my own screen all right there we go uh okay yeah so I'm going to run through what I think is uh best for us to do is so I think that we should have General message passing so we're talking about cross chain interoperability and we should have a general message passing interface and this is what we should work to standardize in this group so the reason I think this is that message passing is the core primitive for all of our inner op things that we want to do so like if we want want to do cross-chain function calls at its core that involves passing a message from one

chain to another same thing with intents or Bridges they all at their core require message passing um and I would like to say that the message passing interface is different from the protocol there probably will be a lot of message passing protocols out there that chains use but they should all form to the same interface so that devs can move across chains and deploy apps across chains without needing to change their code or understand the under in uh message passing protocol um so yes I think that we should focus like very very general and low level at first um on just the message passing before we kind of get into more specific things I think we can build all of the more specific things on

top as like sub protocols or sub interfaces of a general message passing interface and so these are the requirements that I feel strongly that such a standard should have is it shouldn't require any VM changes it should be VM agnostic and proof agnostic uh specifically the proof agnosticism also helps with uh synchronous composability but it should support all kinds of inter op like synchronous and asynchronous uh you know like native um Native interop that's like integrated with the chains uh State transition function itself versus you know outside interop um it should be unopinionated about apps built on top of it and also

about protocols deployed below it and it should be have an easy API to use for devs because that's kind of the whole point of this interface is to like make the life easier for application developers to send messages and luckily this is what most of us are building anyway like this is pretty much what a lot of the erc's that are listed out there uh this is exactly what they're building in some form or another and from my standpoint uh so I worked on an ERC 7841 but um from my standpoint I really don't care like which one we adopt so long as it meets those requirements and can be a general protocol that any chain can use and any application can use for what it needs like totally I really really don't care

if it's the one I work at on so uh but here's what I think that we should do one we should agree on these requirements and I think that's like the first place to start do we all agree on this are there any other requirements we think that we should add with the context that we should keep it very low level and general and not application specific then I think two we should agree on a message format this is like the common Foundation that almost all of the erc's have is they have some sort of a message format um and then we can agree on the apis so I think the apis to send and receive messages are where the erc's differ the most um and so I think that maybe that can be like the last

thing that we tackle and so brief overview like so I worked on this ERC 7841 uh the status of it now is that we are planning to kind of add a chunk to um 77 86 from Axel and open Zeppelin and basically add a chunk in their ERC that kind of covers the use cases that this ERC does and but the reason I just wanted to bring this up is that this message type so this message type is very similar across like all of these erc's it has some sort of a sender key sender chain ID receiver key destination chain ID um payload and then maybe some extra metadata so like in this ERC we have a nons and a session ID uh for example in

7786 you could use attributes to put that information in but like this is fundamentally like what all of these message standards need so if we can agree on this this is like a really really good first step and uh so I think the one thing that may be slightly differs from the other erc's in my perspective but it's just my opinion um I view cross chain function calls as something you build on top of message passing so I don't think the interface necessarily has to tell tell chains how they need to do cross chain function calls um but I'm open to discussion about that because I think all of the other erc's are specific around like actually executing

a function across chain um but anyway yeah that's it so going back to these requirements uh these are the requirements I think that we need for such an interface and I'll stop sharing my screen Martin yeah I agree and the lower level interface the simpler interface the higher odds we can actually agree and then we can have another round of discussions of building on top of that right up to the level where as you were you were showing their La the level where like hey maybe we can even trim some of these Downs there are the questions like hey you should even have a destination chain or should be more like a broadcast style thing etc etc so

like the the simpler it is the harder the ODS of agreeing so that then we can shill our erc's kind of on top of something rather than on top of of yeah what are the chunks you're planning on adding to 7786 that are not already covered out of curiosity yeah so um it is a way I don't know if you're familiar with 7 86 um also I know open Zeppelin is also on that call they have attributes um to you know specify metadata that you need and so one of the the use cases that we wanted to make sure was supported was these more complex use cases where you might actually want to send multiple messages back and forth between chains and um and

you know and use cases where maybe you have like a message that you want to broadcast and you want to allow multiple applications to be able to read it so we're going to add a chunk um where that kind of specifies like how you could use these attributes to do that within the 7786 which previously it would have been very difficult to do those use cases R yeah so maybe I can um now talk about um 7786 um and where that comes from and some of the the problems that we see and that we have tried to to address

so we have been some of us have been working on on this ERC um initially uh open Zeppelin and axel have been collaborating on it and and co-designing it um we at open Zeppelin we we had looked into the cross chain problem space like three years ago and found it to be very fragmented like we had really simple things we wanted to do back then like say write uh erc20 source code that a project would be able to deploy on multiple chains uh let's say arbitrum and optimism and make it bridgeable from the L1 and in order to do that you need to write different code um and that just increases the the level

of effort that you need to make um the level the number like the lines of code that you need to audit and so on so that really slowed down the thing and and eventually actually even put the breaks on on what we were doing um because we we had to imp lement different Logic for each of those chains and choose which chains to support and so on so that particular problem with tokens now I'm happy to see that it's it's being addressed with 7802 um uh which is this uh standard for bridal tokens but I totally agree with Ellie that we need to go below that and standardize as well the the low level primitive of cross chain message passing um and so this is the scope of

7786 it's just a a very simple interface um for sending messages from one chain and receiving them on on the other chain so this allows teams like open Zeppelin or anyone building libraries tools or or infrastructure to to build on that um instead of having to individually integrate each chain or each provider um that there is and on the side of the users there can also end up being sort of a vendor lockin situation if they decide to use a particular protocol as an abstraction layer and we think the best outcome for users is to have these vendor agnostic solutions that they can use so that's where uh 7786 comes in

some some and some of the motivations and so the problems that we are solving for are we want this ERC to be able to cover every chain and protocol that um has cross chain messaging um General message passing as a feature and so for that we have tried to make it a very minimal spec like Martian just said to make it very easy to adopt to reduce the effort required to implement it we've also tried to make it we've actually made it extensible so that any any feature that falls out of this minimal core um that is in the standard can be implemented on top of it in a way that you know it's it's sort of forward

compatible for it and this can be used by protocols that have very specific features they want to expose but that it can also be used over time to evolve it as we find new things that we want to standardize across the space uh but always aiming to have a core of shared functionality that will work everywhere where uh 7786 is implemented um another thing that we um thought of and and tried to do is to make it fully compatible with nonm chains this is a particular place where previous efforts uh fell short um and so for that we've chosen kype 10 um account IDs which came before in this

call came up before in this call um and yeah so we've also been reaching out and working out with many of you here in this call to check that the interface that we have does cover all of the scenarios and use cases that we you know each of us is interested in um and iterating on things that we find uh need to be improved so we're still in this process um like Ellie said before we are uh we've been collaborating on that and and have some changes in the pipeline to um improve support for synchronous composability uh We've also been uh thinking about bundles together with the base team um and those are two things that are happening um and and we've also talked

with uh ZK sync about supporting native authentication we can go into that detail later but it's something that I think uh the rollups in particular that are and this call would be interested in and lastly let me say one thing that we left out of scope initially is the issue of gas and fee payment which um and and by extension that sort of implies relaying uh and it's not because this isn't important but it is a place where there's a lot more diversity across protocols and it requires more work to come to some Universal solution but it looks like something we may want to focus on next so this is the the brain thanks FR you this is

great cool we do have two more groups that still want to get to um maybe we can start with n hyperline or to uh let me just quickly figure out how to share my screen it's been a while since I've used Zoom uh share there you go oh no I didn't approve the update for Zoom so I have to restart actually maybe somebody else can go first and then I will sure come back if it's m you don't really need to restart I think it just shows you the error troubleshoot if anyone from Wonderland wants to jump in

here yeah absolutely hey guys um so we have a few uh proposals that we sent I guess the first one and the one that you probably know about is the let's say the cross the cross chain mint and burn uh standard so this is just um let say a simple clarification on the say function signatures that Bridges should be calling just for it to make it simpler uh for developers to not have to overload the already used mint and burn functions with extra logic that handles let's say the specificity um of CR chain meting that's that's just it so that's uh just the that ERC it's very very simple and

the way uh basically it's let's say backwards compatible you can use wrappers you can have Bridges uh basically trans translate from the cross chain Min to the actual internal Min uh in the case for xc20 or other tokens um and that's it uh then uh we are proposing two different uh Primitives one uh is the the separation between uh validation of messages and execution of messages which we think is very very important uh this is something that I I've seen people uh talk about on the chat as well uh and as Al as well mentioned and I think Martin as well is there is a kind of a very important

thing that we need to First Define which is okay how do we validate messages and what information do we need for that uh both from the uh sending side and from the receiving side I think Mar say like hey a message is just uh something that you broadcast right then on the other end on the receiving end you're choosing uh to prove that a specific message is valid and you and with that um validation then you can either execute or you can use that message as whatever cor doesn't necessarily need to be uh tied uh or have an execution engine enshrined into the messaging layer um and then the other thing that we are proposing is the kind of an entry point primitive

which is essentially a wrapper contract uh on top of the messaging uh execution that allows uh developers to enforce specific logic uh for those messages to be triggered this is very important for two reasons uh so you can say hey why don't you literally just uh instead of pointing to your final recipient point to an intermediate recipient that does this exra logic uh that would work but for some more complex cases you actually need uh the execution uh messaging uh contract to be the one doing the actual calls in the case for example for uh say cross chain ERC 20s you actually need the messaging protocol to be calling the

cross chain Mint or the cross chain burn because that's the agent that is uh allowed to call those specific functions and if you want to add any let's say Logic on top for example do a mul send then most of the protocols that we have right now don't really have uh logic to handle this and they shouldn't which is fine some of them have some sort of logic to handle like very very specific cases but we should enable uh developers and users to use kind of this wrapped uh versions of specific and shrin logic outside of the messaging protocon layer and the good thing about this is that these contracts are should be agnostic because they just basically use the same apis that we are trying to agree on and

they should also be uh let's say they should leave on multiple chains as well since they're just vanilla contracts uh so it should be very easy to use those uh let say across chain without needing to kind of reimplement them and redeploy them for every specific chain should I go yep any questions for Skelly otherwise yeah we can num you're you're good to go and any questions I didn't mean to jump the questions I think all good all right um

so I uh hope everybody can see my screen uh I just quickly copied uh Ellie's slides because I thought they were pretty nice um and yes so I think I I personally sorry not I'm from hyper Lane I personally agree like these are like very important requirements I think for any message passing interface that this group standardizes um to kind of have at the base but I think one thing I would like to kind put I guess the focus on is specifically these two points so I guess um one way that like I think your see that like we've been here writing at hyper Lane 7854 is maybe very different right is that it's an interface that already exists and has already been running in production uh for the last couple years

and one of the reasons why I think that is um something to consider is because um developers who were built of these message passing interface will always considered the like alternative right which is basically like using a specific protocol that has presumably like uh either some advantages in terms of like time to Market with tooling um and of just like General um kind of awareness or like tool Stacks built on top like I think all the things that we said intents liquidity tokens um and in that regard the ERC that we've proposed is I think very different but I think it's like a very key um I guess consideration I think for this group um like sometimes I feel that similar way about like rollup Bridges right where like developers could have

been using rollup Bridges to send messages between L1 L2 and vice versa but because the developer experience has been pretty rough um that is kind of like part of the reason why people even use like other specifically inp protocols that have very different like trust assumptions um and so one thing that I want kind of like yeah put I guess as context is that like we as hyper has have always believed that like the message passing interface has to be like yeah standardized and fully open and that's been true for hylane basically since the beginning of when we started right and so the interface that we've specified in 784 is fully open source but I think comes with the benefit of being basically tested in production but also having I think a set

of um tooling when it comes to like right explorers when it comes to like token standards when it comes to um like testing Frameworks that developers will be able to use and so I think part of our consideration when choosing a standard very much has to be like um yeah like what are the alternatives for developers to pick uh because I think it's good obviously if we agree in a standard and obviously the less kind of like like complexity it has the more likely we all uh to agree upon but I don't want us to kind of like forget that like we're not doing this in isolation we're doing this uh with respect to kind of like Alternatives that developers might choose that are not maybe not meeting the these requirements um and so I think to kind of like Aid on that like the inter

interface as specified in thec already has a lot of implementations and so it's already VM agnostic right so like we as high plan we first implemented the like uh evm implementation but there's already production implementations of like kmm of of the svm which Solana and other svm based rollups um there are current implementations for like the chyo VM for the fuel VM for Kaden and many others kind of like in progress uh and because uh everything has been open source like that's been like I would argue after like uh IBC and after um I think like chains safe has had a prior implementation that out of people have been able to reuse as well it is actually currently the like most like open and usable standard if like a new

rollup wanted to use interoperability but not pick a vendor and I think that's really like I think the like the key part that again I want us to kind of recognize is that like right now we're pitting people against like hey use the standard and like build a lot of the tooling yourself or like uh basically choose a vendor right and I think we obviously have seen that like a lot of an interrupt today is very like vendor based um I also want to reiterate I think the point about the like verification mechanism agnosticism like I think that's very important right like a lot of uh folks here on the call are working on like better trust assumptions like I think Super chain like is probably the most prominent example of that and any message passing interface that um I think we should standardize

should be able to basically Encompass and allow developers to use use these different verification mechanisms and on there I just again want to emphasize that the message interface that our e specifies already has like um basically Ro aage support it already has like super chain support and as easily can support others it has like six things helos uh helos like client um and so those are all things that are basically like ready to be used already and like yeah hopefully part of the consideration for this group as to um uh yeah what to kind of standardize on uh and then the last part that I want to mention is um relay I think is much more important than maybe we like they recognize I

think I had like a call earlier today with Francisco from open Zeppelin and I think it was a great question about like right like there's some erc's uh like 4626 which actually can basically kind of gain its full value because we just standardize the messaging interface and there's not that much tooling around it that that's necessary but at least from my personal perspective relaying actually is a very key developer and user experience for anything that's built on top of the messaging experience right like no user ever wants to like submit transactions on the destination chain and like if we don't standardize relaying Behavior at all it ends up we're pushing that complexity over to developers or users who like in turn then make this calculus between like oh do I go with this kind of like more

vendored interoperability protocol or do I choose the standard um so yeah those are kind of the like things I want to mention again emphasizing that like yeah I think the ERC probably looks a bit weirder because right like it is based on the interface that hyan has but because Hy is fully open source and people have been operating right like this interface without our core team at all being involved I figured it's like worth kind of like at least like having people be aware that this is an option I recognize that it's a little different from all the other standards I think it's a good thing but I can I can see why people might have some reservations as well thanks ma'am any

questions feedback uh this is more of a general question but I think a big difference in the designs of the erc's is whether they are a pull based ERC or a push based ERC um and I think that we will we either have to support both kinds or we'll have to decide you know which one we think is worth supporting I guess I just want to point that out Arun so we started to have some of this discussion in the chat um ultimately like both pull and push push based formats are going to need some standardized messaging interface um that

is consumed by providers the question and and this is maybe a good question for um for Bo Mark and Ellie since you have more familiarity with the pool based interfaces the question is can those be the same interface or do they have different requirements um so can the pull based and the push based be the same interface I think this is basically exactly what we were kind of trying to discuss with uh open Zeppelin and axar um because there is is a push base in RS is a PO ERC I think it I think it is difficult to do um I think that there are ways you can

do it but they're Bas they're kind of really hacky like if you have a push-based interface you could imagine a pull-based protocol by like saying that the push is a no op and doesn't do anything and instead you let people pull from it so I don't know it's possible it's possible but it's not a clean I don't think there's a very clean way to do it I mean I think technically you could have a pool-based system where the uh proof request is for a particular message format that's also used in a push based system um although I'm not sure if there will be alignment between uh rollup ecosystems that use just like any event as like a originating message

when they submit this proof request or if there's going to be alignment around perhaps using like an explicit uh messaging format that's different or unique um from a I guess just a regular or any log kind of thing yeah that's a good point I think okay so one I do think that the message format can be the same between pull and push based it's just like the interface and how the apis work have to be different and I really like the the point that b brought up brought up personally I'm kind of opinionated that like even the event style uh interoperability protocols should like still form to a general message format um that is my

opinion it is possible to design one interface that supports both it's just a question of whether that complexity is worth it right because then like every protocol every Gateway needs to support both and like there's technical um you know costs associated with that um so yeah it's just if we think it's worth it it's it's doable you know or we think it's not worth it so just going to jump in um I think the the benefit here is like from the perspective of whoever is building L1 blocks um uh or whoever is like sequencing these transactions ideally if you're like like if you're dealing with

a poll based message packet um relaying a pull-based message package or a push based message packet shouldn't really make a difference and all of that should be abstracted away to the interface and so like if there is space for like a hierarchical set of Standards such that there is an underlying message format that is shared between both of these and then it's the the interface level that's different that would I think simplify things quite a bit I really like that yeah yeah definitely plus one to what Orin said and I guess it's still again it goes back to the differentiation between validation and execution for push uh say style messaging protocols what you actually have is uh both the

validation and execution um happens at the same time and most of the times you don't necessarily have uh a way to revalidate the same message that just got executed right so if other applications or protocols want to also uh let's say jump jump on the same train and use the same let's say messaging uh protocol to revalidate a message for other purposes that's not usually possible um so kind of decoupling that um from the design uh perspective on how like messaging protocols work uh it's I think a very good first step so we are at time I see there's a hand maybe we can get to this quickly

and then wrap CJ yeah I just wanted to say something really quick um so push based protocols don't necessarily have to have verification and execution occur at the same time right like the verification can arrive and then sometime later the message can be executed it like you know 7786 which is push Bas Now does not take a stance on that right and that is why it's possible to actually have a uh standard that is supports push and pull at the same time so um yeah and then my point is that in my opinion a poll-based approach covers like 100% of the use cases because you can build a push based on top of it but if we're talking about an API for devs most devs they're going to want to do a

cross-chain function call that's the use case that they're going to want to call use which is like very suitable to a push-based model Skelly did you have something oh yeah basically I guess I agree that the what Frank Fran was saying which is the push pull is kind of a loaded term um we either I mean from how we've been thinking about things it's around validation execution if you guys want to use another terms and we can agree on other terms to kind of make conversation happen uh easier I'm I'm all up for it but yeah but but I guess we we are pretty aligned and I agree

with what uh CJ was saying as well cool all right well yeah it does seem like there is some some alignment here um we should probably wrap I hope everyone found this first call helpful like I mentioned at the start I want to be mindful of everyone's time I really appreciate how everyone's coming to the table here uh I guess one last thing maybe it's worth having another breakout group even just an async telegram group for continued discussion around consolidating this message passing interface work it sounds like some consolidation is already happening um with espresso Wonderland basically everyone that's that's talking here today so uh maybe we can keep that up um yeah we can keep chatting about that and yeah and if there's appetite I would

love to have another schedule another follow-up call soon so let's um yeah let's continue the conversation in chat and thanks so much thanks all all right thank you thank you thanks everybody