Cross-Chain Addresses Call #2

Transcript

all right I think we can get started I'm sure people will continue to trickle in um yeah thanks all for joining very much appreciate all of the collaboration that's already been happening across a bunch of different perspectives and viewpoints a lot of great progress already uh on just refining the vision for how we can make sure we are taking positive steps to the end game that we all want to get to around uh improving L2 ux while also not uh degrading the experience for any users or flows uh and thank you to Marco and and Jeff for doing a lot of the heavy lifting to get the draft of this ERC together um yeah we don't have a a huge agenda although

there is a nice list of open questions for us to get through today uh before we jump into a review of the ERC draft does anyone have anything they wanted to to start off with or just mention here at the at the jump um I uh I was gonna propose um taking as little time on the call today but maybe on the next call or something um having a sort of parallel document of considered Alternatives or Forks in the road because I'm a little confused with uh you know the comments about

censorship proof like completely abandoning the offchain registry or those kinds of things like there's all these uh Forks in the road that I just want to like capture and make sure that if those are going to be a separate EIP Som days they're somehow written down um so I might be on the call trying to uh write write things down capture of things that get tabled yeah that'd be great yeah there's there's certainly a few different um directions that we can take I guess is this in reference to maybe was Wilson's recent message in the chat around sort of just focusing on on the offchain registry element or something

else yeah yeah I mean that's that's why I got pulled in here I think so I'm I'm sort of curious because I I noticed in the draft the fallback was status quo and I I thought the goal of either this or some future RC was totally moving away from it so I'm sort of trying to keep that separate and not slow down the other stuff with it yep got it okay great yeah if you don't mind I'm I'm happy to collaborate with you on that document that that sounds like a great idea we should have that cool okay well then we can uh yeah just jump into things if no one else has anything I'll hand it over to Marco and Jeff here okay um I I can maybe recap super

quickly what uh what I think is in the document and then people can tell me if they agree or not and uh I don't know maybe we can go on each of the of these points and see uh the major comments in there uh so I would say that uh the first thing the document does is try to settle on this uh uh on a format just Syntax for what is an extension of of an address with a chain ID hey Mar sorry to interrupt do you mind sharing your screen so it's more visual for us yeah sure second there's a bit of a limit to what

I can make this large is this visible for people yep okay yep Yeah so basically sorry these three points mainly I wanted to touch on so the the first is the the format so here in the document after the motivation there is this syntactic format so this is sort of the grammar of what this could look like um so as this is the at syntax that we that is the sort of email in inspired uh where we have here the chain that is sort of the main problem that we need to look at that could be ANL one and this would be this is a

similar to the case that we have today I have an I have an address and I just live on a test net or main net for example uh and then there is the case more interesting where there is a name in there and then this name we would like this to be uh um a name of a rollup and in this case we would like and this is sort of the the tricky thing that maybe is the most complicated part of this of this document how do we do the resolution of uh of this name uh so that uh we find the right chain idea of this L2 and then if the also the the user is a name at this point then how do we solve this username on an L2 so these are sort of the the tricks that we try

to to go through in this document so basically uh just the format uh how do we build a registry of chain names for L1 test Nets and especially for L2 that is kind of the the driving case uh to replace uh basically what is now the the centralized giab list and then how we do uh once we identify the right L2 how do we move the NS resolution how do we continue it on on that L2 okay these are kind of the the main points uh so basically the after the format the document tries to go step by step on how do we do the resolution so the the simplest case so the first step is to do

the uh the the L1 part so for example if you take this example uh we would first we need to figure out how to to resolve the if and in this case if we assume that there are a few of them that this is just like each theol and maybe let's say less than 10 of these well-known l1s that they don't move too much then this can still be a centralized list like it is today it's just a small file that lives in a wallet and and that's it so that's that's not a big deal we expect uh to find in this in this local file let's say a mapping between e and all the information that I need to resolve the rest so I go from E to I need at least the the chain ID really in uh in

in in bytes or inex decimal how to identify because this is the piece of information that has to go inside transaction that has to be signed so this name on itself is useless unless we can get to this uh and then in case we want to continue with more resolution then we can also say point to the right um ens contract that leaves on that cnad um so and this I mean if if at every step we stop using names then this is not useful uh but I mean this is kind of the the point that we do want so we need to keep following this this these addresses which brings us to the L2 resolutions once we have this we can go check the rest of the of the the address

so in this case it was rollup do so we need to resolve rollup to resolve rollup we can use the address that we found in the previous step uh and then this is going to guide us so this is a bit of a the most complicated part because we try to build this registry so that there is a unique mapping we can get into this separately uh but then so this is the resolution how do I find the chain ID of the roll up and then once I did that uh the last part of the resolution is okay now that I know in which rollup I should go how do I go there find another ens address and then resolve my Alice name so these are the the three steps and here there is a there is a recap uh that that does the same steps so we have the

first part is we just do it LO so imagine that t list is the file that lives in the in the in the user phone or like a wallet so this is still local then the is the part where we tried to find the the rollup chain ID these are two calls but and this is done on the L1 and then once we have this we can we can continue resolving the name on the L2 and at this point we have all the information that we need and we can just send the transaction correctly signed uh to the to the L2 so this is a bit of a quick overview of the of the document so I don't I don't think it's worth getting it to more details of of each one of the steps does this make

sense to everybody I'm kind of confused thanks thanks for that overview I'm kind of confused on the L1 part um you know if I have like zxf okay yeah Sam said the E maps of the root chain ID I see so there's an offchain registry of L1 tlds is is that right yeah yeah so I mean we also discussed in a little bit in the channel in the telegram group um if this also should be on on on chain is just that it's sorry is not a

particularly big concern because like I said there's supposed to be few of them and it has the side effect that basically if I um if the only way to to know the chin IDE of sepolia is to go to main net then it sorts of um so I mean test Nets are supposed to be completely separate world where you can do your testing well here you would have a test net that depends on Main net like you need to first go to main net you can find the chity of seia and then you can go to your testing and it's a bit weird and there's no that much reason to to do this so I have a bit of a concern overloading the eth um so in ens names the eth actually means like use a

particular resolver contract if I understand correctly but here eth means look up in an offchain contract for uh offchain registry for a chain ID so they look the same but they have completely different meanings and I think that that's a concern of mine I see I you have a perfectly fair point I don't know if Jeff do do you have any comment on that um so I feel like right now I mean I might not be asking the specific question but um you me and Marco have slightly different opinions about this and I thought it was still worthwhile to just talk to the group about how we kind of how deep we go into this kind of

abstraction of the the ens names so you know as an ens guy and doing ens for all this time we don't really have this case where like we we very rarely like to have things like you know we have like Alice at roll up. e and Alice is not ens name so in this situation we'd have to change the resolution process so um it actually points to something like alice. roll up. e and it goes to that rollup to the L2 like we don't have this kind of L2 resolution process right now right now everything starts from L1 and we use ccip read to kind of opaquely go get that data and then verify on L1 and that data can be on an L2 or it can be offchain um and in this situation you

know it it may not necessarily be on the say optimism. e the the initial alice. eth might actually be on ZK sync or on L1 um so I have a concern as well about whether or not we should be creating these nicer looking address you know ens names if you will or I guess they're not really en names um so yeah I have Sor go maybe I think there there's like two so I would like to talk about what you what you're mentioning that but I think here the concern is slightly different is is basically saying uh so I think um I think the point is that I would like from the

address to be able to to start doing my my journey of resolution and I think so you're right that we are a bit overloading this but but not really because I mean today if I tell you uh whatever do e why are you assuming that this is on Main net and then you need to go to uh to DNS sorry to ens so this is sort of a you have some sort of pre-existing social idea about this you say ah e this sounds like an ethereum thing I know that ens is the place where they register this and and so so we're just trying to basically formalize this we're basically saying if you see. you know that this is something that lives on on

etherum Main right but it's kind of the other direction that I'm worried about because not all ens names end in eth mhm I see so the point is that again you you need to pick so so this uh this is completely arbitrary just I don't know in the telegram group people seem to to like it so this could be could be a new thing or but the point is that there should be one thing that allows you to start your your resolution because if if you have 15 then do you see what I mean yeah so I I think I can probably answer his question a little bit um in terms of like if if it was this way so like roll up. e and we wanted to make

sure that you know we're like we're overloading eth to mean also start on ethereum Main net then of course we'd have to mandate in this EIP that any L2 rollup that wants to be you know um compliant with the standard would have to use a e name and not like a XYZ name um so it would have if we did overload it obviously we'd have to mandate that yeah that makes sense it it seems to me that we should either if we're going to solve for other l1s we should either like properly solve for it or we just shouldn't solve for it at all and it feels like we're in this awkward Middle Ground where we're like use

dooa in this chain registry it's highly under specified right again I think uh I mean one way to go through that question is to like start with the question what feels right for ethereum test Nets and then depending on the answer to that like it might just be that whatever we do for tests it just just feels like an obviously sensible thing for do to do for other layer ones to just do something isomorphic to that or potentially it might not and if it's the first case then like that's fine then

that's our outcome and then if it's the second case then like that's our outcome too and then it's up to them to decide like do they want to do something parallel or do they want to do something different um for my opinion I guess you know it does seem more natural to have like a dotolo otherwise you have to kind of overload no overload is the wrong word like add another identifier to be like at e or at ear or something like that which it would be like EXT yeah right I mean

the other option is like some just uh basically treating seia as being like an old2 or I guess like likeis sh and just expecting it to have some kind of record that's like at the mia. ens actually it's not the worst idea either is it I think that like dooa if like what does that what does that mean what does doia mean like anybody can make a chain called toia so presumably you're referring to some specific registry where it's called doap poia and then the question is what is that what is that registry and I think that we should take that question seriously if we're actually trying to

solve this problem and given L1 M that ethereum probably has the best you know decentralization security guarantees if we want to make an L1 registry it probably makes sense to put it there yeah I mean I think that's fine I think uh I mean like I have this uh like small philosophical hangup that like in principle a test that is supposed to be this kind of parallel universe that you go into where you do things for testing and those things don't touch main net and saying that if you wants to resolve an address that that represents

something on zolia then like you can't avoid touching mainnet like that that feels a little weird but if other people here decide that like actually that's fine then like I'm totally happy to go along with that well but just so we agree on the cost the cost of doing that is that you still need some registry so you still have to pick a canonical place for people to fetch those records and so what is that place and what is sort of the the up time guarantees the decentralization guarantees of that registry yeah yeah that is fair I mean I and I guess in practice like in most of the test dead activities like they're not even going to use like this type of addresses they'll just they're like

they're a much more highly technical thing that just like directly uses zerox addresses without anything else added to them so yeah like like I guess it it does feel survivable so in terms of size uh I so maybe I'm just trying to avoid solving the problem here the point is that what we do is already uh this having just a file somewhere that somebody put together and we trust it because it doesn't move basically at all there are few things so I'm just basically here I'm just saying I'm not gonna fix that problem we're just gonna continue with that is that

that when we put l2s in the same in the same system it starts to to feel uneasy because there there are manual tools and they move a lot so we're just trying to to fix the the new problem and not try to fix the old problem the new problem I'm not sure those are those are isomorphic like E Today means you have sorry somebody's echoing my my voice you that today is an enss thing and if you want to resolve it you go to L1 there's no offchain thing you're talking about introducing a do ofoia which doesn't exist today and would rely on a new offchain thing that's also not required today so I think you've changed changed the parameters I

see but at the same time I mean today uh so you're right that this is not the existing thing uh at the same time this is maybe a sort of formalization of what already informally happens like if somebody s me an address without any chain idid and they say ah by the way this is my suppos thing uh you start to to f on your own the chain IDs and all the other information that so this is just a way of saying structuring a little bit what already happens in in formally that makes sense I I guess I kind of thought the point of the CIP though was to get for very formal about these things that were causing people to lose money and make

mistakes yeah so I I think I think I'm so this is what I'm trying to I'm trying to say let's make things more let's make it clear that today uh just by looking at the name suppos that you're inferring that this is the the the chain ID so let's just write this down in a file so that is a bit more more formal than than just your what's happens in your mind um and and I'm just saying let's avoid the problem of putting this on chain because it's it's just a few names and and it's easy and we can keep the the test separate like if if I'm a wallet developer for example it's not great that I need to connect to two networks and like uh I don't know there are different delays different so I it's a bit uh but I like I know like vitalic

said I don't have particularly strong feelings about this I'm happy either way if people think it's important to put this on dl1 absolutely like maybe we can come back to this specific question yeah M yeah okay so I don't know let's go to the the second part or I don't want to direct this too much like if I'd like to to go for like highest concern first yeah I guess that's a good question does does anyone have strong feelings here on like what is the if we

could only solve for excuse me if if we could only solve for one thing on this call or make progress on one thing on this call what is that one or two most important things here because there's a handful and I mean I'm happy just to go through the list of open questions but if there's something that is uh obviously highest priority it's a little bit unclear to me otherwise I can just start going through the list of open questions here no yeah thanks right here uh yeah this was we covered this right we did cover that yep exactly and number two I think we also covered in the chat I think they what was said about

what was said about number two I think that this is incorrect right aren't all didn't I guess unless I'm misund understanding maybe Marco can clarify so I think it's uh so basically saying U yeah so it's basically trying to say okay up up to now all the NS resolutions that were in L1 now we're talking about jumping from L1 to L2 this seems like a big change uh uh so I think uh so definitely this is kind of like the the the important thing for rollups or at least I mean I I work at matter lab so the important things for us was to make sure that the resolution could jump to L2 as soon as

possible because we didn't want people to register like potentially many many chain IDs of of l2s and l3s on L1 or maybe the users they shouldn't have to create names on the L1 so we wanted to move to dl2 as as soon as possible so this definitely part of the motivation uh so regarding of how novel and sort of breaking with the existing this is uh not at all because we can we can talk about this but so this is what Jeff just mentioned earlier that there is already a way today uh sorry I done this is my note there is already a way today using ens and ccip read to do the

exact same thing so to say I'm going to do a little bit of resolution on L1 I stop and I get the instructions on how to continue on the L2 and this is what what is already implemented by I think linear uh they have a blog post about this so let's say that we are we are sort of doing the the same thing maybe in a slightly simpler way uh because we don't need gateways Etc but it's it's I would say it's not something new as a concept make sense I guess like one big uh this like philosophical sag in all of this right is that the path for resolving the ens of the username

and the with the layer two that you're actually looking for an address on like those two things are separate right and so like basic like hypothetically it would be completely valid to say yeah know like you have something like i have. e and uh hypothetically or or even you would say you know I might I I might decide to register like falic do Linea do eth and uh the the procedure for registering that would be on Linea and all of the logic uh that that actually like maps that ens name to specific addresses would be on Linea but

then at the same time like the specific thing that I want might actually be like say vitalic eth at know like polygon e for example right and if that happens then like technically yeah like fully yeah resolving like well resolving would not even actually require going into polygon right it would only require going into to Linea because that's where the that's where the record is but the address would still be a uh polygon address right um so I guess uh one question is like is that also how

other people are seeing this and if or I guess either if so or if not like is there any way in which we're accidentally making that too confusing I don't understand why you say that you need to go on Linea to do the resolution uh because um like the way that an ens name works right is that there is a procedure for uh resolving an ens name and by default that procedure only involves being on being on L1 because enss on on right but with ccip read that procedure might involve going

on to specific l2s through the through the ccip read system s the thing that I'm missing a bit is the so the use case that I had in mind was very different is the thing that everything is a subset so like if I go on Linea is because all my information is there on linear right so it's a bit but understand that there are other use cases so I would like to understand what is so why would you put on Linea your information about polygon um I think because like a user I mean a user wants to have I think like all of their ens information in one place right like you want your ens

record to live in one place so that it's easy to edit and like that's the way that ens works today right like if we're saying it's going to work differently then like that's suggesting a change to ens uh maybe I'm confused I I sort of thought you know ens today has a way for a name to specify an address per chain and correct it does you put that record on on any chain and that would continue to work as it does today correct and what we're specifying is a new URI that's more specific it can be resolved sort of uh without the normal ens look up of you know your specific choice on

that particular chain it sort of has all the information not exactly right we want to be able to say like this ens name on a certain chain so that when you look it up on the like in the ens records you know which address to get like we're the receiver still gets to specify their address on each chain but the sender picks the chain that they want to interact on right but like so if so in the like status it my record a subdomain of lineae then even if you want to determine which address to send to me in

order to send to me on polygon you would have to go on to Linea I mean indirectly through the ccip read mechanism but you're still going on to Linea right yeah yeah that makes sense and I think let me reframe what I said that um you currently if I say hey send it to Wilson qc. eth and I and I send you my I have to tell you additionally send it to me on polygon yes and I think the problem we're trying to solve is give people you know a single URI that expresses their name and where they want to receive it but they would continue to use the same ccip and ens look up and find wherever I've stored my uh you know my address on polygon for Wilson q. e that would all continue to work as

expected or as it does today right agree yeah and so is there a new a new problem I'm not sure if I misunderstood I don't yeah I don't I don't think um I don't think there is okay um mhm M should we go to question three that sounds good yeah is I'm not super familiar with the the poly Market use case can somebody explain this wait wait before we get to question

three I just want to clarify so like I think question two is talking about what you wrote Marco with the kind of like uh vitalic at Linea e and obviously this is kind of completely new resolution process that doesn't go through CCI read so are we agreed as a group whether to go towards us or against us CU I wasn't quite sure if that was the uh conclusion I was hoping to to go back to that point in question four okay question four okay that's fine yeah yeah my bad yeah I think question three is May maybe we don't I think maybe Nan wrote this or I'm not sure if the person who wrote this is on the call but yeah maybe we should op to for if if it's approximate I'm confused on what you're

saying because my understanding from what we just said is that you know we can we can solve change for how we express it the format of how we express it separately but let's say it's Wilson qac doe polygon you know orgon B.E um you would still use ccip reading all I've all you've given me is a format to express where exactly I want to receive this is is is am I misunderstanding something Jeff yeah so it's and you're not misunderstanding at all um it's just so Marco obviously um wanted to add something extra to the ens resolution I mean I'm not sure even call it the en resolution process I would I would expect it's this own special resolution process for this EIP that would only be

um implemented Maybe by you know wallets and l2s and clients um that would be something on the lines of having a canonical subdomain registra like linear. e or ZK sync. e and then instead of having vitalic e at base. e it would be something like vitalic at base. e and instead of and because vitalic isn't you know a a fully qualified ens name it would just assume that like it lives on bass. E and and check base. E's L2 registry address and then do the resolution process on the L2 and I think Marco wants to do that in the correct you know you can add anything Marco if I'm getting this wrong but he wants to

do that because it would allow you to do these kind of local um reads without having to do the whole back and forth with ccip read which would which would be increase latency now I'm not sure if this I mean I think the idea of it makes sense uh I'm not sure if it makes sense for this EIP and I told Marco that but I thought it makes sense to at least talk to the group about this because obviously a lot of you guys are working for l2s as well um and at ens I feel like it's a little bit confusing but you know maybe it makes sense I mean we have talked about doing cutting try and cut that round trip a little bit more so I think so at the beginning of the of the document um we were working with this at uh syntax and I was trying

to make this work and then while going through the document Jeff explained to me several times I was a bit it was a bit hard to to get to uh but he explained to me really well this ens and ccip read um so now I understand a bit better that the two things are very very close and I'm a bit undecided actually on on which one is the is the right way to go um so from a point of view of syntax there is basically very little difference so this would be sort of user. rollup do I don't know e and in the other case we were talking about user at roll up. okay so in simple cases this is basically uh I mean it's it's a very small difference uh I'm not sure if uh

there is so there are definitely a couple of problems that we identified while working on on on the on the draft that needs to be fixed which is for example on linear for for this for example the solution that Linea use the the the rollup here still has the problem that it could be somebody else could register with the same chain ID so this could be uh lead to spoofing Etc so but these are things that we can fix in the current uh uh in in the current ens plus ccci read and also what Jeff was mentioning about so right now in ccip read uses an external Gateway uh while one advantage of this uh of the the draft is that you don't

need to use an external Gateway you just need to connect like if you have two nodes running like if you're a huge wallet for example and you have your own nodes that you trust that are synchronized to several rollups and and mainnet you don't need to go through any Gateway like you can do all your resolution on your own and it's probably more trustworthy less verification needs Etc so but this again this is something that can be just uh retrofited into a specific version of ccip read where you where you have a specific format in in the gate way and you have a specific way to verify the information that you get from from there so I don't think we are like this seems like special cases of a more generic thing rather than than a different solution I'm wondering if

there are so I was trying to to sort of show the the parts where these things are the same or they could made the same I'm not sure if there are other things that are drastically different like for example somebody was saying in this syntax you really have a very sharp distinction from what is the chain part and what is the the the user part um which goes in so here in the format you have really like everything that is on the left is the address and everything on the right is the is the chain ID so here is a it's it's less clear is this a huge deal I don't know so I don't know I think one one point of discussion where is not super clear to me is um are these two

things doing the same can they be made to be the same or do we want them to actually be very different for so I mean just as you were talking I just started to feel that actually this doesn't really for me makes sense in this spec just because I feel like this could be a very generic ccip read extension spec where you have a generic way of being like okay this is data on a specific L2 like um when that error come um so the CCP re throws an error right instead of going to the it obviously can give you a Gateway or it can give you a specific chain ID that you can go look it up yourself and this could work generically not just for you know ens but for any information and any other protocol that also uses EIP 368 I think

it probably makes more sense in a separate spec and I know obviously CK syn wants to you know do it like this because it saves round trips but I think it might make sense as more generic spec that would would help other protocols also using EIP 368 um Jeff sorry there there's a lot of things that Marco went over and then um I feel like I lost the the plot a little bit so you're uh the the point you were just coming down in favor of is a spec that's user. e at rollup do. e or uh I'm confused what you were just endorsing at the end if if I don't know if you can type it in the chat I'm not ending anything I don't know about Jeff oh you

talking about me or was talking about Marco uh I was talking about you I thought we were talking about um this we started talking about uh yeah we started talking about l i i um sorry yeah can you just specify the the performance that you're or the the uh the the syntax that you're endorsing is as helpful sure I mean I was I was taking it from a more high level position because basically this whole syntactic kind of like debate is related to um basically Marco is talking about reducing latency by not going through the ccip reprocess so the ccip repr process just a recap is basically this process where a contract will error out with an offchain error and then it will

give you a Gateway and so you have to go to this Gateway run an HTTP request the Gateway will give you back some information that information you'll take and then um go and do the proof yourself on L1 and so this is kind of back and forth that you've kind of wait from the gateway to do these things and so Marco wants a way to essentially do ccip read but without having to talk to a Gateway and so right now I feel like we're talking about how to like implement this within this spec but it's actually it could be a very generic spec that allows not just ens to do this but anyone using ccip read Because ccip read is not a ens specific spec thanks I guess uh I mean one thing

there right is that uh if we want to think about the longer term future of uh stuff like ccip read right like it's uh like what the thing fundamentally is right is it's basically like the the fall back light client if you don't have any other kind of client right and that and so if you have some other like way of reading that L2 that's even faster then in the long run in principle you should be able to right and I think there's you know like in aspects to taking the to the current scheme where it's uh like

like there there's something inherently transitionary about it and like I think like basically there is this longer term road map that goes into um having a a a much Fuller way to talk about like in this particular case I want to read a particular thing from L2 that will answer that'll probably migrate over time like uh you know if we figure out self protocols then you know the concept of listing IP addresses what what might end up going away and so on and so forth so it's uh like I think it's also prudent to make like basically make sure that

stuff that we're doing here and stuff that happens within ccip and clients are sort of as independent of each other as possible and that and that we're not making assumptions that can strain them maybe one one thing that is related and I just I just saw it in the document there is a so I was a bit concerned about the degradation of like the verifiability that you have so today if I send some like I can look at my ledger I can look at the x of the address I can check the chain and I sign and I'm happy uh if uh I need to go through a very complex resolution process so I mean

right now what I'm hoping is that the resolution process is like I could do it by hand like I do a couple of rpcs I resolve roll up to to a chain ID I resolve user to one address and that's it I sign and I'm s like if I'm sending a million dollar I can do this by hand and make sure while if I have a very complex U chain of uh I went to Linea where there is my DNS stuff and then I that sent me to polygon that sent me somewhere else and there is a CP and a gug so at that point like you're really trusting what like you really need to trust uh uh all the like your what the wallet is doing basically so I don't know like

uh in this case it's very it's very sharp the the the dist the difference between the two things but again if this could be any name posted anywhere then again we get into this game of this could uh so I don't know it's just again I'm not just trying to add more complexity to the question but I think it's a relevant hey folks I just want to make sure I'm keeping up with this discussion so um what we're talking about trying to simplify and name resolution so let's just make an assumption that we go with username at roll up. eth so the resolution will look like I'm going to

go to L1 ens I'm going to look up the roll up that eth address right uh and then I'm going to go to that rollup and I have my local resolution directly on chain because the NS contracts are deployed there and I don't need gateways middleman nothing right in order to do that resolution the way that I see it it it's it's a it's a parallel to how DNS Works in like the non web 3 world right um so is there a major drawback to this or am I misunderstanding the problem right so I I feel like the at roll up. e part is uh pretty well understood right the uh part that's a little bit more tricky is that if you

just do user roll up. e then what is the procedure for resolving user uh the user should be resolved on the RO up if the okay okay see so this is different right because uh the difference is that user Roll up. eth and user. Roll up. eth could potentially mean to different things okay that's not how I I'm thinking about it you user. at roll up.

e would have a user. e registration on that rollup like it would be local to to the chain right see but okay right so this is something that's just like it's different from the way that ens works today right because the way that ens works today is user. specific like points to a resolving process where that resolving process starts on layer one and potentially through ccip read or something you could even go go into a bunch of other layer twos and layer 3es and based on that it outputs a mapping from chain to uh to address right and that and then you would look in that

mapping and then you would see like which address at roll up or which address is it pointing to at the the the rollup that roll up. E points to right and like that's a different procedure from saying okay first we do roll up. e and then in order to resolve the user part we just immediately start the resolution process inside the rollup understood so you're talking about backwards compatibility of existing names like what do we do with them right so if somebody or yeah or I guess I'm just uh like I just want to highlight the facts that like these are two different uh like these are two different paths yeah I would just like

to highlight as well that you know if you start to enshrine something like let's say it's base. e and it's like metallic at base. e what you're kind of doing right now by saying that I'm going to go to the L2 to resolve ballic at base. e is that you're kind of enshrining base. e as like the the only in this name on bass but actually right now it's possible to have like other names on Bas like for instance on optimism right now there's um a subdomain reg called opt names. e and optims do eth gives out subdomains on optimism um but op optimism optimism might have their own you know optimism.

e and give out subdomains and so there is some clash with like okay are there any other ens names on this you know L2 now it's currently possible with ens like we don't have any restrictions to this so um I think there are some other tradeoffs as well to to kind of enshrining this in this process where this EIP might bias a single subdomain of you I I I really think we should avoid creating a new uh um like I'm trying to trying to say what we should avoid without saying we should avoid this whole EIP we should avoid like trying to resolve some specific problems that ens solves like in my opinion everything to the left of the app let's just say is a string it's like a black box it's an

address it's an enss name it's a different string format I don't think this proposal should try to solve that I think the proposal is trying to describe give users to a way to describe intent around where they want to receive funds and this sort of gets to my question and the thing number five like it feels like we started on this path and we discovered nested problems of like oh wait in order to resolve l2s we need like a trusted registry of l2s and we have sort of solved that that could possibly be its own EIP I think we now have also said oh do we also need a trusted registry of l1s or is that strictly out of the question I think we

should should decide whether that's in scope or out of scope but um yeah I do wonder if if like getting alignment on some of these building blocks and then coming back to the original question would would help just to uh address your question Jeff first I mean are we not allowing multiple um you know roll up names to the same chain ID so if optimism has multiple that they want they can just register those as so I mean this probably should be discussed in this call as well or or maybe in a later call but the EIP talks a little about about spoing and one of the ways we deal with spoofing is having

something like another like a second mapping of chain ID to to name and I guess you could have multiple names that's just not how we've done it in the spec um but yeah currently it would be chain ID to like Optimus not eth and Optimus not eth would map chain ID and that's kind of in part of the resolution process would be to like verify this and like make sure that they're pointing each other to make sure it's not like a spoof so maybe optimism with o TP mism isn't like verified and the wallets and clients that resolving this will know that it's actually it's not the it's not maap from chain ID to op uh OTP instead of

opt um so that's what we have in the spec right now and um yeah I think having multiple names that go to a single chain ID might get confusing and at the very least they'll still be like a uh like a centralized Arbiter of these like multiple like I I don't see like a genine benefit to having like multiple names to a chain ID if you if you know what I mean understood okay and Wilson my question is if we limit the scope of the CIP just to chain um registry does that actually solve any problem for us I just want to I'm not I'm I'm merely pointing

out that it could possibly be split into two eips and further saying that the process you described does not match how ens works today and I think it would be great to not change how ens works today it's a good username resolution system and so I think we should focus on expressing um I want this thing on this chain at this user identifier that user identifier could be an address it could an ens name in which case we leverag the existing ens resolution process which uses L1 as as Jeff was describing okay but on its own I just want to clarify that actually helps us

and solves the problem don't know which problem it solves the problem that we currently don't have a way to give a string for me to give a string to you that tells you where I want funds in a comprehensive way I I think that's what we're trying to solve okay but you only you saying just do it in two separate eips one for name and one for chain I'm not saying it has to be two eips I'm sort of just pointing out I it feels like there's like four different debates happening at the same time and it might be helpful to First align on some of the building blocks required here and it seems like one of the building blocks is we need a trusted

registry for L2 IDs and and and mapping those back and you know finalizing that could be helpful on its own before you know moving on to some of these other questions okay I mean I think I can just maybe re explain what Wilson saying I think he's he's basically saying that jeffl e optimism e jeff. e optimism. eth is okay way to express it it doesn't have to be Jeff optimism. eth and change um existing standards so it might be longer and it might not it might not have this um

advantage that Marco wants of getting around ccip read for for lower latency but it still solved the problem I think that's what he's talking about I hear you I do think it's complex so we have six minutes left how do folks want to best use these final six minutes I think um yeah what we've been discussing with Wilson has flagged is probably a good next step to make sure that we are separating out the various questions or building blocks um to make sure that yeah we can answer each of them and in which order so maybe we can do that async after this call um if

anyone wants to help out with that um maybe mark Jeff I don't know if you have strong feelings here we have a smaller group dedicated to ERC uh drafting we can take it there in the main group but um yeah um and then I guess in terms of just the timeline like what's uh a next step is the is do we are we getting to the point where we would want to actually publish those ercs and get them talked about in a larger Circle do we want like another round of this uh to like actually yeah like realign

ourselves on the whole package like what's our feeling I would lean towards aligning ourselves a bit more at least on the building blocks before we and then yeah maybe to publish by end of next week if that makes sense that makes that makes sense yeah I think having an internal timeline for publishing I think is good um I mean I think like this stuff can be staggered right I think so like we could decide know like for example that our deliverables for step one are just um let's say the uh chain uh dat database inside of ens um and the the

address format that uses the ad and there's like things that this obviously does not does not quite cover like it doesn't like quite cover like the really ideal way to handle Like the quote the poly Market use case like for um for one example but that's just something we can keep uh figuring out over time right can somebody maybe write out what the poly Market use case is so we understand it maybe strong feelings about how it should go you can join the working group with

us we value your opinion yeah happy to be present if I can be helpful I think uh theic wrote out the poly Market one in a tweet or something so maybe somebody can yeah yeah I just uh posted the tweet in the chat thank you like yeah I guess in the final three minutes if there's no other question one thing that we probably won't answer in the final three minutes but it's good for us to frame as one of these main questions is going back to this yeah this question that Wilson added number eight is making these human readable a mistake I would be might be hopeful if anyone wants to lay out the bear case quickly for why it could be a

mistake uh I think I can L I don't know if yoa is on the call I think he maybe had some thoughts on this as well but I think it's interesting again given we're reusing like e TLD in a different way maybe we need to solve that but um it could be helpful to distinguish these from usernames and so for example I think like the left of the app could be a username but the rest of it should be sort of machine readable and maybe it should be more complex to suggest to people they might make a mistake yeah y go ahead yeah when I when I was saying it a mistake it's not about being human readable but human writable so it could be addressed in a different way my concern was that H people that people think that it's okay to edit it that

okay so we appended we appended the chain and I want to send someone to someone on another chain so I'll just edit the address manually and change the chain name so it's uh so there's a risk that will miss the Mark here and H people will still make the the same kind of mistakes that they do now so one way we could solve this at least for addresses not for the not for the case where the user is also an ens name if it's an address we could change for example the the way we calculate the way we calculate the uh the check sum we could say that the check sum should also include the the chain part so it's human readable but if you try to modify it if

you try to change the chain name the wallet will say it's an invalid address because uh the checks will no longer be H true so it's uh so the concern wasn't about it being readable but about people trying to modify it manually which uh they should never do for an address yeah that's a good point maybe a quick answer so I think the fact of using names maybe is helpful in the sense that right now if I just write address in exad decimal and chain ID in exod decimal I can sign and send and maybe lose my money or or something while right now my wallet has to solve these names so if the name does not exist because I changed I don't know coinbase for something else manually

then maybe it's going to fail and so there is less of a chance of that problem is that so or or is it the same I'm sorry I didn't quite understand the um I think we're at time I think it's a good question I wonder if we should just take it as an action item to discuss further yeah okay great any quick final thoughts in the final 10 seconds here um nothing for me but just uh maybe I didn't understand the question either so maybe whoever asked it can reiterate in the chat and I'll I'll think about it too sounds great thanks everyone for

joining if you want to be in the working group just drop a message in the main group all right thanks all cheers bye