L2 Interop Working Group #7

Transcript

Okay, I think let's get started. So today's call will be focused on 7786 and finding the most effective pragmatic path forward for unified message packing message passing across all of Ethereum. Uh the goal of today's call is to take a look at 7786 as a strong candidate for this, evaluate the bull case, uh and I guess see what questions or areas of concerns people might have. Um I guess I also want to note that with any standardization effort, the default of course is uh lots of debate and discussion without ever shipping anything that gets into the hands of users. So I I do think we all

have a shared goal and and recognize the urgency to fixing the fragmentation problem. And I think the best thing we can do here is to continue to bring that sense of urgency and pragmatism to this discussion without losing track of certain key values and and the need for broad buyin of course. So um yeah, at a certain point we'll need to pick a direction and accelerate on it so that we can continue to uh actually solve interop in 2025. Um I say that sort of tongue and cheek. Of course, you know, there's it's solving interop is going to be a long journey, but I I do think that I think we all agree that there's a lot that we will continue to do in 2025. So yeah, thanks all for joining and I guess

with that little intro, we can yeah, I'll just kick things off. I think we want to start with a brief overview of of where we are with the with the standard. Um yeah, so uh I guess to give maybe a little extra context, um you know, specifically this debate, I I think it should it would be very useful if it really focuses on like the value that 7786 is providing over like you know, the specific implementation details which we can discuss in another forum. Um is Sergey on to give a presentation? Hey guys. Yep, I'm here. Okay, cool. So, yeah, Sergey from Axelr is going to give kind of a pre presentation that overviews what 7786 is.

Yep, happy to do that. Um, share a couple of slides. Hopefully you guys can see it. Yeah, for a little bit of context and background. Um, you know, Sergey, um, I work on Axel these days. You know, prior to this, I worked on the outground protocol. My um general view on standards is to do them only if and when necessary. I'm not a fan of standards overall. Um but uh I do them kind of a you know or I think there's a need for them when um things are not moving u you know fast enough and I think for the Ethereum community it's pretty important to move fast on these things.

A little bit of context, I also helped to standardize uh BLS signatures that um you know that was in the draft uh that ended up being adopted for the consensus at the Ethereum community that was back when I was at the grant and led a you know cryptography group there and there was pretty similar you know time horizon at that time where I think um a lot of different implementations existed that couldn't really agree with one another right so like I've seen cases at that time where somebody would produce signatures that would not be verified in like other implementations and everybody was just kind of you know stuck and I think um you know we um came together with the community and you know Ethereum folks and um you know Stanford folks and a few others and um pushed that through

and I think um unification of message passing for similar reasons is in a u you know need hopefully will get standardized and moved along. So why 7786? Um in general the way I view things is that interoperability is composed in layers. Um you have at the very core of it uh very basic primitives that are responsible for the transport of messages. You have uh security properties that interperability provides and security can differ based on the method of validation. You could have external validation, you can have uh you know light clients, you can have zero knowledge proofs and then you have application layer protocols. If we think about it and

standardize things in the right way in the modular way then things can be evolving and you know improving independently from one another right so um and I think that's really been has one one of the philosophies uh and how we approached uh you know this this spec is making sure it's as minimal as possible right uh making sure it only does the very simple things that are necessary so that uh other applications s and other uh modules can be plugged in around it and you know evolved and approved in an independent way. So all intra protocols at the very core of it rely on basic ability to be able to take a message and deliver it on the

destination chain. all of them, right? Intense, you have broadcast protocols, you have, you know, token transfer protocols, uh token issuance protocols, whether or not you they do it for every message, they batch things, they all need crosschain messaging and uh uh you know, in the same way you can think of all the L2s whenever they post state to L1, um you know, it's a message that's being delivered. So really agreeing what the message specification is um is uh you know very very critical and very very important. Uh once you have that consistent essentially API for sending messages um applications and all kinds of middleware can be built in

parallel independently and evolve and you know advance very very rapidly. Um now why I think it's important to to standardize this API well API by itself doesn't have any its own value you know regardless to what you know a lot of interop players will will will will try to say at the very simplistic case you can think of it as really kind of a header of an envelope okay uh that specifies how you send a message from a source to a destination uh very simple it has things like who is the sender what is the sending address what is the destination address, what is the destination chain? you can debate and we can discuss and you know we should discuss and incorporate various feedback

what are the you know data types for all these things what are the additional fields that may be included with it but at the end of the day it's you know it's a very simple API and it's a very simple kind of header of the of the envelope um simplest way to think about it is the IP packet if you're familiar very very simplistically who sends the packets to whom and then you have the rest of the you know TCP IP stack being built on top of it that has various properties you on delivery, on security, and so on and so forth. So, you know, if you're familiar with the networking stack, I think this back uh takes, you know, a lot of philosophical differences uh or philosophical similarities with the with the with the standard networking um you know, protocols.

Um yeah, so 7786 um you know Open Zeppelin led the um the development of it uh with consultation of some of our engineers at Axel uh and a lot of other industry experts and the goal has really to propose something that's neutral and uh agnostic of any specific vendor. So it doesn't follow directly you know accelerator specifications uh it doesn't follow anybody specific uh implementations but it is close enough to everybody in some sense so anybody can take and you know adjust their APIs and spec to follow um the same uh you know header uh of this of this envelope it's not that complicated but as soon as we agree then everybody can can start

building their you know their middleware and services around it uh and keep building on top of Um it's open you know you can take a look at it please comment um I don't think um you know as Ellie said we want to get into too many you know technical debates uh you know on on this call uh primarily purpose is to educate but absolutely please comment and give any feedback that you have on top of it and uh Alen Zeppelin team you know and everyone else involved we'll be happy to to iterate around um why it's important to do now I think Um so number one I think timing is right. Um I think as I opened up like you know I kind of said that generally I

don't like standards. I think the industries move a lot faster um in many cases except when standards become a bottleneck and I think in Ethereum community a lack of the standard is really a bottleneck that I keep on seeing over and over again and incompatibility between different products and services that people are building across the ecosystem I think set everything back. So um um I think you know standardizing it very very simply uh will allow um all the different vendors to keep on building their unique security properties, their unique you know API services, intent services, everything else around it much much faster.

Um this this spec has been in consultation with us and other intra providers like I mentioned it's really battle tested like billions of dollars has been you know processed by the protocols at this point we know what the API needs to look like we know how this API extends to other environments uh EVM and non EVM um so I think it has a very very strong you know base base ground and you know it can be extended further down as needed but um I think it's as simple enough that hopefully won't happen too often. Um, so that's it. I think that's all I wanted to cover. Um, so I'll happy to answer any questions or pass it back to Ellie. Yeah. Um, I guess

for the rest of this discussion, you know, people people can ask questions in the chat. Um, you know, or if you want to like raise your hand live um and ask a question, that's also really great, too. So maybe I'll pause here for any questions before we move into the next segment. All right, no questions. Perfect. Um, so uh to give kind of a some context around this discussion. So, uh, many of us, you know, on this call believe that 7786 is a very good standard and that it has a lot of value. Um, but, uh, you know, there are definitely like as with any standard, there are very reasonable arguments against 7786. So, um, you know, I want to discuss those during

this call. Um and so maybe I can start out with uh just a few questions that I think we commonly get about 7786 um and the value of it. So I think a first question is well why don't we standardize an existing protocol you know exist there um a lot of the existing interop protocols today are very well designed and they're very they're very good and you know could we meet our goal faster by standardizing one of them. So, I don't know if Francisco if you want to comment on this um because you put it really nicely in the past. Yeah, sure.

Um I think the the what you're referring to is the this idea of thinking about what the developers of the future intera protocols are are going to be um are going to be thinking of and and the decisions that they will want to make, right? Um even though there are protocols out there that are uh what is called modular security. So you can sort of swap out the verification mechanisms that that is used underneath to to verify whatever pass happened on another chain. Um you know protocols tend to want neutrality right they want to be sort of self-contained.

um they want to reduce their their dependencies on on other uh protocols on other businesses. They want to control their their their stack and and their interfaces. Um and so it it really doesn't seem to me viable um to say to the interrupt protocol developers, you should use protocol X or Y uh to offer your functionality. Right? We want to have um an interface that they can take off the shelf and and use to offer their protocol without relying on another party. Um and I think so far that hasn't existed even though there have been proposals. Um they they had problems and

they had limitations and that's why each new entry each new party that entered uh this um space had to come up with their own thing. Um and so the goal of ERC 7786 is to make something that is um you know finally good enough to to satisfy these um you know to to get over these limitations that we've had in the past and and satisfy whatever needs new protocols may have. Um and also you know to make sure for slight deviations by building in some degree of extensibility um so that protocols could you know slightly deviate if they really need to.

Um but this this idea of you know being able to take an interface off the shelf and use it which is you know what we have seen happen with like ERC20 ERC 4626 all of the NFTts um you know I think it's really critical and we haven't had it so far. Yeah that's great. And if I could add um just something of my own um you know I just it's very important that the standard be credibly neutral. Um like Francisco said, it's not very realistic to expect you know certain uh interop protocols to adopt the protocols of their competitors. Um I also think it's very important to um you know just not make the ecosystem too reliant on any single protocol. um you know the

protocols will always exist underneath but it would not be good if you know all of the infrastructure that apps use for messaging relies on a single project and you know that project doesn't exist anymore or you know is not aligned with the values of the ecosystem. Um so yeah I think the big point here is that the standard should be credibly neutral which is why u you know standardizing existing things um we didn't think was a very good idea. Any comments, questions? I had one question, sorry. And maybe we'll get into this next. Um, so feel free just to say if so, but um, yeah, I think neutrality is obviously critical

here and and I guess I would say even sort of table stakes. Um, but I'm wondering if we can maybe help explain why we are bullish, sort of the more um I offensive reasons, why we are confident that this solves real problems, why the customers of this will actually adopt it um beyond the sort of neutrality aspects of it. Yeah, these are really good questions. Um I will okay I'll share my thoughts and then um maybe CJ you could share yours because I think that you do a good job of describing this. So I would say that the customers of 7786 are mainly two things. They are the messaging protocols um and the application developers. I'd say the application

developers are the primary customer of 7786. And a standard interface for messaging provides the following value for applications. Um so first off it provides a single API that can um interact with any messaging protocol that currently exists and does exist in the future. This makes applications like modular they don't have to worry about the specifics of the messaging protocol itself. They don't have to do specific integrations for specific protocols. Um and this just makes it a lot easier for application developers to deploy applications across a variety of different chains. Uh the other thing is that you know chains are supported by

different messaging protocols. Um while a lot of the protocols are you know used on a lot of the chains you know certain protocols are not connected to certain chains etc. And realistically apps want to connect to all chains. So they want to be able to use multiple messaging protocols at the same time. You know eg uh receiving a message from chain A uses protocol X but receiving a message from chain B uses protocol Y. They want to be able to do this so they can actually offer this really seamless uh crosschain experience to their users. So a single interface just makes all of this much easier. Um but I'll hand it over to CJ.

Yeah. So I see there being like two main customers of this interface. The first is uh apps like Ellie said. So like if you have one sort of interface to crosschain messaging like apps can you know write their smart contract code and then the interop provider is just totally modular. So like if they want to like move to a more secure provider like innovation happens and all of a sudden like there is just a way more secure messaging uh provider apps can move to that provider without having to like rewrite their code and upgrade their contracts and all that. There's no like lock in. So it allows apps to inevitably be more secure. It allows crosschain to be faster. Like no one's going to be

locked into some like two-year-old interop provider, right? Like just as innovation proceeds like apps can just use that innovation, right? So that's one thing. The second thing is for protocol developers themselves like having a standard API really simplifies things. This has come up in this group itself, right? There have been several people that have proposed like novel verification mechanisms for crosschain messaging and they were forced to also define their own interface for sending the message which is silly. Like they that's not where they're innovating.

That's not what their work is. They shouldn't have to spend time on that. And like if they define an interface like apps that already use a different interface can't use their work, right? If you come up with some really really novel verification scheme that's totally trustless, fast, like infinitely secure, like how can you push it to existing apps if they're using a different interface, right? So the idea is like we remove that part from the equation and say this is the interface and let innovation on verification, speed, trustlessness, all that like happen separate from the interface. So yeah, that's it. Yeah. And if I can add to that, I think one of the things I really hope to see, um, many messaging

protocols today do have this like modular verification, but not all of them. And what I really think that this API can allow is like once some of those messaging protocols start supporting like real-time ZK proofs and things like that, applications can like very easily upgrade to those more secure verification methods, you know, without having to rework anything in their contracts. But anyway, does anybody have any Oh, go ahead. I was just going to say yeah like crosschain uh verification is going to continue to innovate like forever. It it will never stop like there will always be people coming up with better mechanisms more secure faster cheaper right and we just want that to just sort of happen right to just be plugged in and and modular and not something that people need to move to. So

yeah, I also want to mention a particular use case which is when um as a as a smart contract developer you are you know creating your protocol you want to deploy it on many roll-ups um and you have the need to use say the canonical bridge of that rollup to connect talk back to the L1 um currently you need to separately integrate each um particular bridge you know that each rollup uses right? Um that will u behave slightly differently. Um and you know that's additional work you need to do. Uh and this sort of unified interface would make that uh easier and and more efficient.

Anybody have any feedback or you know disagreements? There's a couple questions in the chat. one around how does it compare with 7281 XC20. Um, okay. I don't recall what 7821 is off the top of my head. I would have to look it up, but compared to XERC20, um, so it actually is very similar to XRC20, you know, kind of all of these like interfaces are very very similar. Like Sergey said, I would say the main difference is that XCRC20 is specifically for token bridging, whereas 7786 supports token bridging, but then it also can support like arbitrary

message passing of data. Um, which I think is uh very important to do as well. Yeah, I we should see this as different layers. Um and you've got the message passing layer and then on top of that you've got the token bridging layer and XCRC20 7821 also um is an alternative to it. So they they're also in that layer. Uh but then um underneath you you you have the message passing. take a kind of like an intent protocol for example would um use XRC20 or uh 7821 um to do like rebalancing of of the

liquidity across chains but it would use 7786 for message passing of like um notifying that a fail happened and that you know that settlement has to happen on the other chain. So um there there's there's room for those two depending on exactly what you're doing. Um yeah, Wade has a good question actually. Um and maybe uh Francisco you could also answer this one. It's um 7786 uses uh Cape 2 and Cape 10. Um so do we think that you know these those separate standards are going to be standardized as well? Yeah. So first I'll mention one of the things that uh we we really wanted to do with 71086 is make it um very well defined how it supports

different chains different VMs um and uh which is something that previous ERC attempts at at message passing like unification hadn't done successfully and so uh that's why we chose Cape 2 and Cape 10 to do even though like recognizing that they they have some some limitations and some some issues. Um but uh there is the interoperable address uh standard sort of effort working group that's currently going on and the we are interested in adopting that uh because you know it it fixes some of the issues that Cape 10

has for us. So even though you might see that in the spec right now, it is, you know, this is one of the things that is uh sort of in the in the to-do list to um to improve. So there's definitely no consensus on K10 uh being the crosschain address standard. Uh I invite you to look at the interoperable address progress. Uh there's been a very recent spec um that was just shared in the chat that's looking actually really good. Yeah. And um yeah, I guess I just also want to highlight that uh you know 7786 it has like you know even though it is is proposed like it's still in the

process where we can still make changes to it if you know the community feels like certain changes are important it's not set in stone. Uh so yeah I just want to like everybody should who is interested can go and provide feedback like on um on the standard you know in gith in GitHub. U yeah. All right. Any other questions? I just wanted to second that like really quick. Yeah, like 7786 like we we are still iterating on it and like at this point we want to do more of like community iteration like because the whole point is to just get everyone to sort of agree on the packet format right the header. Um so it's not like we decided it should be this and this is our pitch like take it or leave it. It's like let's just work together as a

community and agree on like a common API for sending messages. All right. Any thoughts or should I dive into some more hard questions? All right. Um All right. So, uh another you know another kind of question that or you know very legitimate um argument against 7786 is that you know well any sort of existing application would need to upgrade to this protocol and that's a lot of work.

it's easier if the existing applications just you know stay using the protocol that they're already using and um yes so this is true and I would say that this is kind of unavoidable um you know current apps that are integrated with a particular messaging protocol like it is to for them to do any sort of upgrade they will have to change their contracts and they are already kind of like vendor locked in to a certain protocol which is specifically 7786 is trying to fix so I think that this is kind of an unavoidable problem with any solution.

Um you know even if we would say standardize like an existing protocol all of the applications that exist that use other protocols would would need to upgrade to it. Um so yes this is a very fair criticism but I think it's unavoidable and um but secondly uh I think that specifically new applications can very easily adopt this and I think that you know there will be a lot more new crosschain applications like going forward in the future than there are today and so all of these new applications can easily adopt it um and over time existing applications uh you know can slowly migrate to it but uh yes you know we don't expect that existing uh applications will like migrate to this new API on day one. Um you know

that's really uh that's really not realistic but um but the other option so the alternative for exist for um existing applications is they can migrate to 7786 it's difficult but they get a lot of benefits or they can just remain as is which is totally fine but then they also suffer all of the problems that we talked about which is like this fragmentation they can't you know contact certain chains like all of these things. So, um I guess TLDDR what I just said like yes, current applications probably will not adopt this anytime soon. Uh but we believe new applications will any thoughts?

Um, another thing too, um, that I think is cool to point out about 7786, um, and this, you know, this could be true for other other standards as well, but, um, so Open Zeppelin has, you know, uh, been developing adapters for different messaging protocols. Um because the flip side to the question is well why would a messaging protocol like adopt this you know and so with these adapters 7786 can be adapted to work with any messaging protocol you know without a direct integration from the protocol itself. Um so this will also make the adoption of it very easy um because it can be adopted you know these major messaging protocols that are already used u you know can basically be uh can work with

7786 like day one. Uh yeah, Victor. Yeah, I guess to that point, have has there been any work on like case studies to show which messaging protocols could fit uh well beneath this interface and which ones might not fail fit well underneath this interface. Uh yeah. So we sort of took like our like as our like um I don't know go what is it I don't know what the word is like the the way we're thinking about this is we take like axel layer zero wormhole and usually hyperlane and try to make sure our interface works with those and then as a secondary thing we usually try to take some major L2 bridges like the orbitum bridge and what else was it Fran

like uh what other L2 bridges did we look at optimism Yeah, like arbitrage optimism. That's like our sort of north star. Like we want to make sure it works with all those things and if we can like then it's pretty good. Um, we also like did add this thing called attributes into the spec that's supposed to be our way to like make it work with the long tail of interop providers like that. It might be slightly more difficult today. Um but yeah I I'll add a little bit to that which is that the core of this interface which is you have you know you have a sender you have a destination chain you have a receiver a payload that

basic thing is almost universal right um quite naturally um and so that's also the core of 7786 and so that's easy to do where it starts to differ you know to to deviate and to differ more is in what is related to paying for gas um and relaying costs. Those interfaces are more significantly different. Um and we are now in the process of also standardizing that part. Um and you know we still have to um understand how well it it maps um to existing things. Um but the core of it is quite universal.

Yeah, that actually and actually uh one of the things I was you know I'm kind of new this space but one kind unsure about when I read the specification the first time was the interface for execute message has payable and if I send value to that execute message function what happens to it is like was it immediately clear to me um like it seems my understanding after finishing reading this and thinking about it for a bit is it seems like it should be the case that equivalent values should be sent to the receiver and that that payable amount is not eligible for gas like gas deductions. But maybe that's not the case. I'm curious about that. So, so if you read the the AC the AC accompanying text, you'll see it says, you know, it's

undefined what happens to to the value in in payable. It may be rejected. So it it'll depend on the protocol and and that's there because like if if it's a if it's a canonical bridge you you'll have a very simple way of just sending through um the the ETH or the token but in other bridges you won't be able to do that. So um but it's something that I would be interested in working out more in the spec how that works. And in this in in the open PR we have where we're working on the quoting and and cast payment. Um I am touching a little bit of these these lines to to make that a little bit clearer but it you know the the behavior it's still depends on on the underlying bridge. And there was one more thing I wanted to say about uh how this

interface a universal interface adapt to to this wide variety of protocols. There there's one part where um it is particularly hard which is the chain ID because every protocol uses proprietary chain IDs um to identify the destination and source chains. Um this is the part where it gets really more difficult to translate interfaces. Um and you know the the the choice of gape 2 which are the the chain agnostic uh chain ID standard um sort of gives us the solution for that. But then to figure out the mapping to that to the proprietary chain ID um is a little bit

harder and that I think is the the main the only thing about the you know the core part of the message sending that is trickier to do. And actually kind of relating to that, I noticed that basically there's a source chain uh Cape 2 and then there's also the sender Cape 10, which the Cape 10 should also include a Cape 2 Channity if I'm correctly. So why have those to be two separate fields? This this is really a very technical uh detail that I don't think it makes sense to to go into now. I'm happy to talk about it more later, but um definitely have have thought about it and and and considered it.

Yeah, if there's no other um other comments on that, uh maybe we can move forward to kind of just talking about the practicality of 7786 and getting it uh you know into production. Um so I think with the message passing interface uh you know there we need to strike like a good balance. We need to strike a good balance between having something very soon so that all of these crosschain apps that are going to pop up have something to use um that's standard like that's standardized. It only becomes harder to create a standard um API you know like the further we go down. So that's one end but on the other end we also want this API to be good. We want it to be uh you know very futurep proof.

We want it to be something that you know will stand the test of time over several years. Um so with that I think that the 7786 currently strikes a good balance because uh while it's not officially standardized yet um there are implementations of these smart contracts that exist today um from my understanding you know uh like these could fairly easily be made uh you know like production ready and put on mainet. Um the adapters don't all exist today but uh based on our conversations with some others in the group it seems like creating these adapters would not take a whole lot of time. So um the other thing so I guess that's kind of another pro of

7786 right now is that it has a lot of like actual infrastructure already built behind it which allows us to move a lot more quickly on it which I think is important. Oh yeah, just wanted to second like um at at Axelr like we will you know have an adapter for this so that way like you can send messages through the Axelor protocol if we don't support it natively you know so you can send messages through the Axel protocol using 776. We're also in the process of shipping another product built on 776 that is sort of like a aggregator that you can send messages across multiple interop protocols at the same time and they're only considered verified based on some security scheme that the app defines

like two out of three. Uh and that would use 7786 as well. Uh that's a nice product in my opinion because I think that's like the most secure way to do crosschain messaging. It's hard to like hack two bridges at the exact same time. Uh so but yeah those are just two uh products. Yeah. Um no yeah that's a good point. Like this kind of aligns nicely with Vitalic's uh blog post that he posted a while ago about kind of like proof aggregation. You know having this interface that can easily do that it you know it's great because proto u applications can you know upgrade to these aggregated proofs uh very easily.

Anyway, Orrestest. Yes. Do you have a timeline for some sort of first I guess complete suite like an alpha version for for for me to take and and play with and actually see you know the EIP and the relaying and and ideally also some verification work together. Yeah. Maybe Francisco. Yeah. Well, that's a it's an important question. Great question and it really you know we really have to understand ERC7786 is an interface right so when we talk about a like an end toend suite we would be talking about a particular instantiation

of that um and we could say talk about the axular adapter for that right um and I can't give you a timeline right now but it's you know we we have the adapter we've deployed it and tested it you know an end toend thing uh Maybe we should talk about that offline to understand um what you want to see and and when we can get it done. Sure. Thank you. Yeah, a lot of this is sort of I don't want to say blocked but like not totally prioritized because we're trying to get like sort of community consensus around the spec itself. Like so it's like do you want to go the full mile to push something to production while it's still being sort of designed, you know? But if if there's

um a desire for yeah like an alpha product that people can play with like we can prioritize that and like that I I don't think that should take more than like a few months really like it's fairly simple. Yeah. Um I do want to go back to Marissa's question in the chat. Um so this question is that 7786 does not enforce like a certain verification mechanism. This means that all sorts of verification mechanisms can be used and they don't all have the same security and but the security of these verification mechanisms very much affects affects the applications.

Applications don't want to allow certain message verification types um but they do want to allow others. Um so yeah this so app so the apps deciding what their own security module is uh still works with 7786. So applications would still say like hey I require this certain verifier I require a zk proof um and they would reject any messages that that don't have that. So applications are still able to like specify um you know very specific security parameters because uh which is yeah this is a very important property that we need to keep because this is a very good point. Any more questions?

Um, yeah, I just had a one which I typed out in the chat, but basically on attribute keys, it says that um in the current spec, well, the version that's on on the website, it says every key must have the format of solidity function signature, which is four bytes. Um, so why is that enforced? I think this may limit um generalizability beyond EVM. In the end, the only thing that matters is the resulting four bytes, right? Uh, which it acts as a tag. It's just a standardized way to generate it and it would be generated offchain. So, as far as I can tell, it wouldn't really be an issue to to use it in nonem context. You just need the the four byte constant in there. Um, but then the the rest of the

the encoding um can be VM specific. I think it might make sense. And then know maybe because he also says that um it's expected for you know certain attribute keys to be standardized via ERC's um you know there might be like two classes of of actually keys right one that's standardized one that's maybe more custom um depending on the bridge or messaging protocol um like basically I think two questions basically you know is for enough do we need more potentially um and you know should we res reserve some of the attribute key space for like attribute keys that need to be

standardized and maybe another another you know another category for okay this actually can be anything arbitrary and doesn't have to be standardized at all and messaging bridges can implement whatever they want my take here is like four bytes seems to be enough for function selectors and I think it's roughly the same uh here even though you know there are obviously the possibility of having collisions but you you're never thinking about this when you talk to a trusted contract, right? You already know what its AI is. And this would it would be the same here um with um gateways. You sort of you're sort of you're connecting to a particular gateway, you know what attributes it supports. So, it's a

similar thing there. I don't think we should be worried about the collisions. Um, okay, Matt asked a really good question in uh the chat, you know, which is I think I can summarize as, you know, like we say that applications don't have to make any changes to their contracts if they want to switch messaging protocols, but like is that actually true and like what does that actually mean? Um so the changes should be very minimal but like there will be changes specifically in that you know an application will have to specify a certain verifier you know uh verifiers um you know may be specific to certain chains etc. So like they will have to

specify that um but the idea is that this is like a configurable item. It is not changes to the core structure of their smart contracts. Um the other thing is fee you uh mentioned is uh like fee calculations and fee calculations should ideally just be very modular and like you should have kind of like a singular modular interface that says like calculate crosschain gas that can be in you know implemented in any such way uh but it's the same API interface that all of these apps would connect with. So no they don't have to adjust their uh fee fee mechanism inside their app. But I don't know if uh CJ or uh Frangio have any more comments. Yeah, I was just Yeah, regarding the the fees, like like I said, we're in the process of of

designing the the fee API, so we we can't answer the particular part about the fees just yet. Um um but it's a really great point. We need to look into actually with this um apply across the board. Um and I pasted the PR link over there. people are invited to to let us know what they think about it there. Yeah, that is the ultimate goal though, right? Is to just be able to hot swap and it all just works. Um there's some element of maybe that won't work in certain cases, but that's what we're working for. Fees are harder, right?

Even though we are working towards that with fees, it is harder. There's just something like send a message. It Yeah, it has proven pretty swappable in practice. You just send a message. there's like a little bit of a translation and that's it. But the app doesn't care. Also for the fee part of things, um we have talked about sort of like having two like like 7786 sort of encompassing like two interfaces where there's the message sending interface and the the fee interface. So for like the situation where for some reason some interop protocol like the fee interface like they it just cannot work with 7786 that they can still support the

messaging interface because that is generally much simpler. Um and yeah and that's like your app logic as well. So yeah. Anyone have thoughts? Hey guys, Matt here. Um something we've been working on, I just need to get out. Um there's been a lot going on in our end is a protocol that will publish a suggestion around chains being able to declare their gas markets because not only do our are fees an ongoing thing, but chains regularly produce upgrades to their gas markets that change the nature

of the fee structure. And so you can be working under one set of assumptions that may or may not be valid if there's been an upgrade on the target chain. So just something to consider that these are dynamic markets that change with upgrade. Yeah, I think the way I see it is that something like that we could uh you know it could be very very modular um in the sense that yeah like applications should be able to like this should be abstracted from applications. It should be extracted from the messaging API itself. Um but then like different sort of gas markets can be swapped in or you know gas specifications can be swapped in um you know when they're needed.

I think the question is discoverability. So I want to I'm on chain A. I'm trying to pass a message a swap to chain B. You know do I does my application have an accurate understanding of the current state of that gas market? And so maybe you know the proposal that I'll put forward is a mechanism by which each chain can sort of specify here's how my gas market works here's the parameters and here is the version um so that if the version has incremented uh the application can verify yeah the way we're thinking about this generally is the application requests a fee estimate like before sending a message right and so it sounds like what you're building this like gas thing

would sort of like plug in behind the fee estimate so like the application is always getting like a correct estimate or correct enough. Sounds good. Um all right, if there's no other comments, you know, maybe it would be useful, uh I know we only have about 10 minutes left to just briefly kind of discuss the uh properties we felt like a messaging protocol should have. Uh so I can link this in the chat. It is still a PR so subject to uh subject to change.

Uh but so any sort of messaging interface whether it's 7786 or not we feel like should have safety obviously uh as long as you assume that the message verification is honest. You know the API should be able to deliver a message if and only if it was actually made at the source chain. Um the API should also have livveness. So assuming the livveness of the individual chains and the censorship of censorship resistance of the individual chains u a message should eventually be received on the destination chain. Uh we think VM agnosticism is very important. Um as uh was mentioned earlier um previous standards have focused on only EVM APIs.

Um which it makes sense because mosta most use cases are EVM use cases. But I think in the future uh nonem use cases are going to become quite important to support. Um secondly or fourthly uh it should support any sort of verification mechanism. So proof agnostic. It should be protocol agnostic meaning it should support any underlying messaging protocol. Um and uh finally it should be optimized for the most popular use cases. So this would be bridging tokens. Uh even though 7786 can very much support like an arbitrary message passing scheme um we are we recognize that bridging tokens is like the primary use case that something like this would

be used for. Uh so we are taking that into consideration you know and you know for example there are ways you could extend 7786 to kind of handle like these very certain edge cases in certain applications. uh but realistically we don't think it's worth that and if an application really has this super complex thing that they need to uh that they need to do then they should just interact with the messaging protocol itself. Um trying to make the messaging proto or trying to make uh 7786 like you work for every single possible use case would just make it very complex kind of defeating the purpose in the first place.

Um, I see a few comments in the chat. Let me read them. Oh, I just wanted to double click on the altvm point real quick. Um, so this was one of our main goals with 7786 and I think is one of the actual like technical differences between 7786 and some other previous ERC's. Um, and we view this as very important like we really tried to make the spec something that can be implemented from Salana, from any sort of VM or honestly even chains that don't have a VM, right? Like at at Axelar like our protocol is quite similar to 7786 and we've implemented this coming from XRP ledger which is not a smart contract chain. like you can

make like smart contract calls from XRP ledger using an interface very very similar to 7786 and on Ethereum you don't know the difference like of whether it came from there or came from Bitcoin right you could do this from Bitcoin um and so that was like one of our goals yeah and one thing I like about this goal um is that so we often focus on specifically L2 interop which is I think by far the most important thing right now and 100% um but really in the future you want interop between L1's like there should be very clean interop between Ethereum and Salana because that's actually a major pathway that users want and it's and if you can use the same interface to bridge to Salana as you're using to bridge to like arbitrum or OP uh like that's incredibly incredibly

useful even within the L2 sphere right we want to enable alt VMs um like startnet um and uh the lack of of of a standard that caters to them could really you know hamper that innovation. So I think this is another benefit. Um okay wait I had a question which is that uh 7786 uh does not actually guarantee uh message delivery of or guarantee that messages are actually delivered um in the sense that it's more UDP like TCP. Uh so what I would say is that like actual message delivery is really um for the messaging

protocol level like an API itself can't really enforce it. So you have to trust that the protocol will enforce message delivery and that the chains themselves are like live. Um but I guess another way to put it is that the API should not prevent that. like there should be no situation where an API prevents a message from being delivered that was you know actually sent from the source chain. Yeah. Liveness is generally provided by a relayer right like uh which is like somewhat I don't want to say outside the protocol but it's like a higher level than the protocol itself like than verification. However, like Ellie said, messages should be deliverable, right?

Like there's no there's nothing that like a message should be like blocked uh on some like centralized entity. It should be like once the message is sent like it it can be delivered. You could deliver it, the relayer could deliver it like it's it's valid. I guess my question is more regarding like let's say if you want to you know do like a lock and mint um or like kind of unlock operation we'll have to basically from the source from target chain send back to the source chain before I do the unlock operation because I cannot assume that message have been delivered right yes this is true yeah yeah yeah but there should never be a case where like if you lock on the source chain like it should be mintable on the destination chain it's just a question of like when right does that make sense

Yeah, I was wondering whether you know like a TCP like extension should al also be um you know like standardized but it seems yeah like if it's really just to a message passing we don't have to uh it can just be at level. Yeah, I think maybe that's also a good question which is like you know why don't we standardize a messaging protocol itself because then we could standardize something like a you know guaranteed delivery mechanism within like a certain time bound. Um and the answer to that is that messaging protocols which often are combined with verification layers as well are I think would be something that is very difficult to standardize. Maybe in

the future we can, but I don't think it's it's at all realistic to standardize that in the near term because there are very many valid you know design trade-offs and decisions to be made. Um also the messaging protocol standard would need to support every single use case which makes it you know even more complex. Uh so anyway that's like the benefit of just focusing on the API instead of kind of going down the rabbit hole of actually you know standardizing the the messaging protocol itself. All right, we only have five minutes left. Uh, does anybody have some final thoughts? Oh, yeah, Josh. Yeah, sorry. I just had um I guess maybe one final question from my side at least, and we

already touched on this a little bit, but maybe we could um yeah, quickly come back to what is the success criteria for 7786 12, 18 months from now, whatever. Assuming the bull case, what do we think success looks like? Uh yes, this is a really good question. Go ahead CJ. So uh first success criteria is the products that I mentioned before, right? Like from from my side, from the Axel side, like we want to make sure we ship the adapters for this. It's usable, it's workable, it's running in production. Also the aggregator, right? That uses 7786 usable, workable, running in production.

those two things. The other thing that I think would be a success criteria is if we see new interop protocols like coming out or being designed that use the 7786 interface that don't feel the need to like design their own interface for no real reason that say okay like there's 7786 I'm going to use it and behind that will be my novel verification scheme what whatever my innovation is. Um so yeah that's what I think. Yeah. Um yeah, for me the success rate or success criteria is very similar. If we can have adapters for Axelr, wormhole, layer zero and hyperlink. Um since those are the most popular protocols right now, um if we can have those within like 6 months

and deployed in production and apps can start using them, that would be very successful. My hope is that we could actually do it faster than that. Um and then the next step of success criteria would be like how many new applications are actually using this interface. Yeah, I I mine are similar to CJ's um which is you know I want to see new interrupt protocols using this interface for their message um sending feature. Um but I you know plus one to Ellies as well like I want to see applications you know being able to use that successfully.

I'll just say just yeah plus one on Elise that I think we will do them once we settle on some of these final issues. We'd want to uh add support for all those message messaging systems uh sooner than 6 months. And then the other thing that we are going to be looking for for success criteria is we want to start enabling more of the open zeppelin contracts to enable embed crosschain messaging and then we will be success criteria for us will be to see beginning to see adoption of those contracts and use of them and deployment of them. So

um yep and maybe as a as like a final thought on timelines uh so the like the exact timelines kind of depend on how much you know further iteration we need on 7786 and you know other things um but what I would like to propose uh now that we've had this discussion is that uh you know we or at least I feel that 7786 is a very good way to go forward. going forward we should um we can iterate on like the very minor details of 7786 um that some people brought up here. I think maybe we can do that over the next um well I don't know I want to give people enough time to do it but like at the latest like the next month at most

and then I think we should you know like standardize 7786 unless we have some major reason not to. I don't know if anybody agrees or disagrees with that. That sounds good to me. I guess to Josh's question um in the chat when we say new interop protocols um does anyone have thoughts on what sort of protocols? Um I get I think like uh an example uh which you yourself brought up would be um basis uh ERC which is itself really just the verification part like that's the main

part but it has its own interface you know if like that protocol would adapt to the 7786 interface uh like that would be really really successful I think uh for me one that comes to mind is uh the super chain right um and I would also say espresso right? Um as a way to communicate between rollups. Um yes, Espresso um you know assuming there's nothing crazy that happens where we end up don't not standardizing this. Espresso will adopt uh 7786. All right. Um we're at the top of the hour. So um I appreciate everybody joining. Um, if you have any comments

like definitely put them in the Telegram chat or you can put them directly on the uh on GitHub. Um, you can put them in like the L2 interop repo um or on the uh 7786 repo as well. Um, I would just like I mean really if anybody has like any thoughts I think the most useful thing right now is for us just to get as much feedback as possible. Uh, so I would very very much appreciate it if anybody does that. Um, if anybody thinks of, you know, arguments against 7786 that they want to discuss, like, yeah, put them in the chat. Uh, we would like to work through all of them. But I appreciate everybody who asked questions. Uh, and everybody who listened.

Thank you. Thank you for running this session, Ellie. Bye-bye, guys. Thanks all. Thanks. Bye. Cheers, everyone. Bye.