L2 Interop Working Group #8

Transcript

I think we can get started. This is the L2 interrupt working group. On today's call, we will be focused, I think exclusively, we'll see how it goes, on chain specific addresses and a few significant updates and revamps around that chunk of work um that I'm really excited by and I think will hope to um yeah move this in a really positive direction. chain specific addresses, aka interoperable addresses, has been a topic that many of us have been discussing for quite a while now. Um, and I think we're all excited to um, yeah, kind of take this to the to the

next level and and kind of get things finalized. So, um, yeah, big shout out to everyone who has been working on this chunk of work for a long time. And shout out to some of the Wonderland team who is here today, who has jumped into this chunk of complex, messy work and has really been great in helping push it along and get it to um, what I think and hope is a much better state um, today and and you know, thanks to all of the other work that they were able to use as a foundation for this. Um, so yeah, I guess without further words, we can just jump right into the discussion. Um, and I'll hand it over to the Wonderland team to to give a bit of an overview on

things and and anyone else, of course, feel free to jump in with questions. Raise your hand. Um, awesome. Um, hello everyone. I'm going to share my my screen real quick. [Music] Um, can I get a thumbs up if you're seeing my screen? Okay. Yeah. Okay. Awesome.

Um, hello everyone. I'm Teddy from Wonderland. I've been leading the uh the efforts on what uh was initially named crosschain addresses and uh I have sort of two documents to show you for this call. The first one is uh this one that uh was sort of a recommended reading um which T is going to share in the chat if you haven't uh seen it already. Uh but we are not going to uh to go over uh this one. It's just um important that you know it it exists and

that you can refer back to it if you want to on board yourself to this. And the other one is sort of the my presentation of the subject we have been working with um ERC 7828 which has um was proposed uh sometime late last year. Um and initially we tried to sort of overhaul it. It has some history. It initially started as a text text representation. Then we tried to also uh define a binary one then make it only

binary. Then we went back to text. It's really a bunch of context that doesn't really matter. Um other than the fact that uh we chose to split the standard um basically the standard defined this uh address at chain uh bound uh check sum format for chains and define a few name uh ways to have better representations that than row addresses or raw chain ids.

And we also have uh the need for um for like the idea is for this to serve the needs of two groups of people. Um those working with wallets and uh any other software that wants to display an address chain combo to a user. On a fundamental level, this the scope for this is very simple. This is just okay, people know about addresses and we have to also strap a a chain a chain ID on top of that so people know um where that address actually lives.

Um but then you got the needs of the wallets that I already mentioned and the smart contracts which is people working on the intents uh cross message passing resource logs verticals where they uh need like a con concise um representation because uh every every bite uh counts and also they needed some other guarantees such as uh knowing that a given address can have two possible representations which the um for which a text format is not really optimal. So um we decided to to serve

the needs of two different groups of people. We're going going to define two different standards. Um the idea with uh DRC 7930 is to be the um to be the binary representation standard. Uh I'm going to refresh this because I have I have some other examples of this. Uh there we are. So um we intend this one to be the binary one for um for use within smart contracts. And it defines basically a payload

with with a version a chain type and chain reference uh chain type chain reference and address fields uh which would be which would map to to address at uh chain. Basically version is an internal internal thing. So we can extend this standard in the future. Chain type vaguely matches to a K namespace and chain reference uh is the the K preference. So what chain uh within that ecosystems within that ecosystem we're talking about and address is the address

specific to that chain which we all already know. Um so this standard is mostly concerned with the binary binary payload but in order to bridge the gap between uh this standard and 78 to8 and keeping them both compatible is uh this also defines a very basic text representation uh which is also which could also be useful for when you don't actually have the means to I don't know resolve an ENS name or per perform some other um like more advanced logic or you are just a developer trying to uh to

troubleshoot stuff. This has a text representation as well. Um and uh this text representation is actually what lets you plug into 7828 and give the two standards convertible between each other. So the the target audience for 78 to8 is uh is anything that interacts with humans and which could benefit from uh having more readable and memorable names. And it it um the the gist of it is

that we define the like every uh name of this format from 7830 is like uh compatible with this one. So you can still use a row address if you want. But it also defines that you can uh put hierarchical names within the address or the chain field. And we actually strap some semantics on top of the of these hierarchy. So you can have the idea is that the top level domain defines how are you actually supposed to resolve the uh to resolve that name into something

that's not ambiguous. and that you can follow as a and you can actually the reference back into a chain ID or into an address. Um the idea with this is basically to uh create an indirection level app. So currently we have a a centralized registry of chain names like mapping from chain names to chain IDs and instead of maintaining that in the future we will maintain a list like a list of protocols to name chains and to name addresses on those chains. Uh which would be hopefully a much shorter list. And the way you do

you know which one to use is by this uh top level domain. So in this example um we have uh alis at coolchain.short. Coolchain.short short. It has the DLD short, which means we should use the the short list which is what we currently use in for example ERC 3770 and Alis has a top level domain which is which means it's it should be resolved via regular ENS. Um it's worth noting that uh while this standard allows for the use of ENS

uh it's not uh entirely coupled to it. So uh the idea is that you could have an some other TL which maps to using some other naming registry. um if in the future uh somebody uh wants to to use something other than DNS and also in the uh in the case that's crucial for the case of naming chains since um it would be very cool to use a decentralized list of chains as proposing ERC 775 but that is uh currently not possible because uh 775 is actually uh

pretty far from reaching production. So in this other example that I have uh this is this is more of uh more made up because uh we can't use your C775 yet but the idea would be that uh you can say uh use roll appl as the chain as the chain part and then uh the Eid would mean that you use uh ERC 775 to resolve that to an actual chain ID. And this also showcases that you could use um you could still use addresses like

row addresses or row chain IDs like they would show like you would do with 7830. Um, so you can use this for things that don't that are not actually named and you can represent things without going through a naming registry. Um, this this is a work in progress. Um we are um there are a few um a few things that uh we're trying to to define is especially the reverse resolutions of addresses on other chains is something that is uh

currently uh being implemented by ENS and we have some erh uh we some some comments and some needs from from them. And uh it would also be very cool to see ERC 775 moving forward. So we can um so we can decentralize the naming of chains as well. And this um this centralized list of naming resolvers also called the name register registry

um is uh something that we have not created yet and for now we're uh debating the possibility of using the uh of using the same repo as the chain list. And this is the part where I where I ask you for for stuff. And it's where uh we're having we're wanting to get this ERC's uh like finalized as soon as possible.

Our goal would be for them to be in a final call status in the next uh like two weeks from now. So erh we will really appreciate your feedback on on any of these and in particular I would like to I would like to ask you to use the it machines uh forums the threads we have links for for the two of them here and they are also in the in the other document and T probably shared them in the chat already and the idea is that for every sort of minor change that uh that we

have to the ERC's we use different PRs. So for example um like making 7828 be a text representation of 7930 addresses was its own PR and any feedback that you have that you that you make on on those PRs will be will be hard to follow on if they are not um if they are not properly archived. So we would like to have all the feedback happen on the on the forum so we don't have to then track another like huge huge list of different PRs that you have

to read to get up to speed and also um erh like we we would like for people to on board themselves to this bec without having to I don't know go through a telegram group or something so it's easier on everybody. So yeah, we're doing uh we're doing interes and we we want your help with this. So I haven't gone through the the chat. Um is there is there any questions that uh you guys have on this?

Uh yes one question um probably you've covered this or maybe you've covered this I've joined late uh but why do we need uh the check sum uh in the uh machine representation of addresses? Um no we we don't actually the the checksum is only for meant for displaying it on uh for displaying the text representation to humans. The machine address does not have a checksum. uh it assumes that however you transmit that information has the er has the capability of erh knowing if you got the same message

in as out like if you were to share it in a QR code for example the QR code has its own redundancy if you were to send it over TCP TCP has everything that TCP has and it's the check sum is only relevant ing context where it's possible that a user like um had a typo or has um like has something different on the like the the naming schemes can get uh very like can get uh sophisticated in the future. So you would want to perhaps you could have uh text representations

which are different for the same actual address. And the way the checksum is defined is that it only hashes over the the chain and address part. It does not concern itself with for example which naming resolver you're using. So you could have like the same address be represented in text in two ways and but the check would be the same. So you would would be prompted to look into it like the ide for it also to not make the the representations as opaque.

Okay. Yeah, this makes sense. Uh though there is one thing that I'm concerned about like as a user if it's uh if I'm typing a name as a user I want something simple uh like just alpha numeric but if I have to type uh at the end some check sum which is like a hash or something like that would be very hard for me especially even though I'm like um kind of it person no the you will not type the checksum not as a not as a lay person and not as a the as the nerdest of all developers. Um the UX that we envision is that you use like you type the name and from that

name they actually the wallet at least with ENS which is was what I researched so far the the wallet can then figure out where the like on which chains there is an address available for that name and then it can list So you pick from the select and then you get the you get the checks on the the wallet computes the checksum for you. So if you are somewhere that if you for example uh saw the address in a pamphlet uh you you could type and and say yeah that's that's the same checksum I did uh

I did everything okay and then uh like send the donation or whatever. Okay. Okay. I see. Thank you. So the check sum just to uh I just read it and verify in another place. Yeah. Yeah. Uh I see some hands up. Uh you would you like to go next? Yeah. I just I had a comment um specifically on this. Um I think the team did a really good job uh taking the initial proposal to now splitting into two machine readable and then the human readable that um um leverages that um this is very solid well thought out I think we should push to get this you

know done as soon as possible um support the twoe timeline autumn awesome job that's all okay thank you very much my my question is if you can give a short update or comment on the integration with chain agnostics proposals. Uh some of this is being proposed as a cape. Is that right? Um can you comment on that? Yes, I'm actually really glad that you asked. The idea is that um these standards support um support Ethereum addresses but they are not limited to that. like they can support uh both chains within the

Ethereum ecosystem which are not EVM and I don't know have larger addresses such as uh Aztec or stet stet and they can also support things uh like completely outside of the Ethereum ecosystem um mostly because there's some uh like we were inspired for that for other tooling which already supports it and it's based of Ethereum such as ENS with ENIP9. Um so in order uh we want this to be extensible to as many uh chains L1's L2s also for that we need

to have a like we need to have a place where we agree on the text representations like on how to map the text representations of addresses to a binary payload because that's for them for some cases that's uh pretty easy and uh for some other cases there are some alternatives in the case of Ethereum you could I don't know you could argue over uh if you want to use uh EIP55 canization of um of uh capitalization or um or or similar things and I don't know Bitcoin has several address

types. So the idea is that we defined a k profile which is k 3 350 um which is currently in draft and it's receiving feedback. We didn't link from it from the presentation but the other the other document uh actually includes it. Um but uh yes so there there Skype 350 which defines um a profile of what the chain should define as are their text representations, their binary representations and how to map between the two and uh then the K

namespaces uh for every chain are completed later. um if you're not familiar with how k uh how kasa works it's sort of a meta specification. So you can have a specification of how does for example ken is a specification of how an address looks and then I don't think we can hear you.

Do you think we lost you? Are you Oh, hey. We'll see if Teddy comes back in a second. While we wait, any other question, feedback from I see there's a few other L2 teams, wallet teams here in the Sorry, can you hear me? Yep, you're back now. Oh, okay.

We lost you for Yeah. So, some So, how much did you lose that? Was the K part clear? I think we lost about the past 30 to 60 seconds. Oh, okay. Um, so yeah, the ideas for that kypes are meta specifications of what should uh address like what should uh chains specify to comply with. In the case of H K 350 is the mapping from text to from text to binary and from binary to text in the case of

7930 in the concept of 7930. So um what we did is we defined the K 3 350 and then we defined the name spaces uh for both Ethereum and Solana. Um the Solana one was not for any particular reason other than supporting some other to sort of to test that we that we could and Solana was particularly easy on how they define their their addresses under IDs. Um but yeah both of these things are as open PRs. So you can you can chime in on any

any feedback that you that you have. Cool. Thanks. Okay. Any other questions you you have or you guys have or anything I miss from the chat? Yeah, sure. I have a question. So, you have this like the the text format kind of looks like an email address. um which is nice in some ways but also like raises the the question of like how do you avoid collisions with you know TLD is defined by I can and potential confusion there.

Um you mean uh confusion between addresses and email addresses? Uh yeah, we like we didn't think of that to be honest and okay uh and we imagine that they would appear in very different uh context. One thing off the top of my head which could be fine which be to define an MX record or something akin to that that where you can make the email address map to the actual uh blockchain address. So you can actually fix that by

making them the same. But that's that's just speculation on my part. Um no we didn't in the vision they could uh they could collide and the idea is to not um an an actual mitigation to to that which is not really uh yeah an actual mitigation to to that to that is the fact that the we would have a centralized list of these name resolvers and the idea A would be to not uh use the LDS that I can also uses so that can get it out out of the

way and in the case of naming registries uh so far it has been in their best interest to not collide with icon. So I don't know uh icon does not provide the ETH um address and the ETH uh TLD for DNS was chosen because there isn't one in in so I don't think that's going because of the TLDDS I don't think it's going to be a big issue. Yeah. And one thing I will say is like video that they're not going to appear in the same context I don't think is probably true. I I think pe people do already, you know, want to send, you know, send crypto to an email address.

And if you have that the case where you have have a, you know, a two line on a transaction that can take either an email address or one of these names, it could exact it could totally be the exact same context. Um the as far as not planning if I can like yeah ETH probably at this point I can would not probably uh endorse a ETH TLD at this point because they are pro I'm guessing they're aware of the fact that it's major it's used by so many people in this space. I guess seriously I would be concerned with other kinds of TLDDs that might appear and that future collisions could occur.

Um yes, we will have to sort of the EF would have to approve of that collision by adding it into the name registry registry basically. Well, I'm basically I'm saying it's like e, you know, some the members of the community of this community decide to use uh some neat new TLD, you know, dot chain and then I can later approves achain TLDD owned by some corporation. I can I was just going to jump in really quick, Teddy. I I think so the the email collision topic I think is a good one and is something that um we touched on a long time ago actually when um when we were first sort of debating usage of the ad sign versus colon versus other sort

of syntax. Um, and so I think I do think it's something that um is still a concern. I think, and Teddy, like correct me if I'm I guess misunderstanding or um if you disagree, but I think the I guess the way that I think that we're thinking about this is that um the way that we've set things up now allows us to have some flexibility. We don't we don't need to answer this question in the immediate term around the specific syntax. and maybe we do in the very near future decide to move away from at to avoid this email collision uh issue but um I don't know not not to say that we shouldn't discuss it right now but I'm wondering if it's something that we should maybe have a separate um sort

of venue to discuss more specifics around uh syntax and this is a sort of thing that would be a good fit for the for the forum um because there's also the the argument that using a colon uh uh would um include would mean having ambiguities with K 10 which would be more frequent. Uh but you would the forum is probably the best place to go in depth into that. Yeah, makes sense to me. Uh there's a couple of questions from Franio in the chat as well.

Yeah, just the one about the timeline I think is the only really important one. the this thing about email collisions. Do we need to decide this in the next two weeks? Essentially, um yes, because the ERC like the ERC's do do not define the um like the naming naming registries we're going to use. uh and they do not define the um uh how future chains are going to vis which which that allows us to move the standard faster but it does define the grammar of what names look like. So uh this is one of the items that should be uh resolved within two weeks but I am

uh like I have the time to discuss it and I'm confident we can we can figure it out. Okay, anyone else has any questions that they would like us to address right now. Else we can um move this conversation to the forum and we will be addressing all the feedback uh during these two weeks as um Teddy mentioned. So let us know. I hope this was very helpful for you to

get contacts on both sunders and we really appreciate you taking the time and providing feedback on everything. Thank you so much Teddy and Titi for walking us through and answering a bunch of questions. This is great. Um any other questions, feedback right now? Otherwise we can um yeah move it to the forum like like TT mentioned. Cool. If not, then we can end the call there. Thank you so much everybody. Thank you. Bye. See you in the forum.