EIP Editing Office Hour #99 (EIP + ERC)

Transcript

[music] >> Give me a second as

>> [music] >> Welcome to EIP editing office hour meeting number 99. In this meeting we are going to cover both on EIPs and ERCs GitHub repositories. On agenda, we have proposals to be reviewed for the status change going into last call review, a few miscellaneous and a bunch of draft proposals for review. We are joined by editor Yohai Raviv today. Welcome Yohai.

Um maybe we can get started. We are also joined by a a few authors, so maybe we can get started by reviewing the PRs. Uh on chat, uh the first one is for ERC, PR number is 1734. Yes, let's get started. All right. Most last call? Right.

Let's see because I think that's like going to be very nitpicky, but I think our policy is that they have a last call for at least 2 weeks, right? That's correct. 14 days. >> Okay. Yes. Okay, so because this is from Cyber Sentry, could you update this date that when I approve this, this is more than 2 weeks because now it's 11 days. Yeah, I got it. I'll um I'll knock that one now. I'll send it straight through. Thank you. Thank you. Then I will approve it if you push it.

All right, the next one we have got here today is 17 Oh, sorry. 1679. You are already there. Yes. Yes. I um dropped there some comments and I fixed them. >> [clears throat] >> Cool. Okay, let's see. Okay, it says here regulated agent

mandate. but it's abbreviated as RAMS. Is it correct? Uh and standard. Okay. So the accreditation mandate standard. Oh, okay. It's Okay. That Okay. But yeah, okay. So like our our policy is that we want these uh um uh the the abbrevi- abbreviations um to be defined. [music] And well, now we have to guess what this SS So I will add I will add it so you can you can add that. I thought that we couldn't write standard. That's why.

Wait. You could not write standard? Was it flagged by something? Mhm. >> Let me see where did I have

Yes, we [music] always add these URLs to the RFCs. So, I would recommend suggest 8274 >> Oh, let's see. [music] Maybe this is a

very deep question, but if you have an attestation service, this is not on ERC, right? I guess. So, it's not on ERC, right? Oh, yes. No, no, it's not on ERC. Okay. Okay. Yeah. Yeah, thanks. Thanks. >> Yeah.

Would you maybe maybe like a more general question like these kind of uh like maybe this is this is this is more common in in in ERCs, but these kind of variables, [music] these are like well, it it's pretty clear I think what it means, uh but these are like Solidity concepts and these are not these are not existing like all all languages. Um do we have like some kind of policy? I think not because it would not make sense, but yeah.

Yeah, I mean, if it is added there as a part of a specification or an explanation, we do not have a strict policy around that, but it is generally recommended to provide something which is generic for all languages. I see. I see. Yeah, I think yeah, I mean, this is this is like so clear I think it could not be interpreted as otherwise. Yeah, I think that's true. Yeah. Yeah, I'm I'm more thinking about like but that's like a hypothetical thing. Like we could of course imagine that in 10 years uh Solidity is not the leading language anymore.

Uh and that that [music] these uh these kind of constants then might not be uh well defined, but yeah. Yeah, definitely we can think about it and try to come up with some I know instructions around the that so authors can follow. Maybe add it in contributing.md going forward. Yeah, maybe maybe that's an idea. Yeah, we can we can we can discuss that in the PR opinion. Yeah. Okay. >> Yeah, cool cool. >> Oh, whoops.

I shouldn't have clicked. Then it makes Sorry. >> Yeah, so I added these two URLs. I think

you can also see this comment. Mhm. If you can add that and there is like this SOA If you do that then I think it's fine. I only want to check [music] the required EIPs and ERCs. Those. I'll fix it that in few before we get to the the meeting.

Yeah. Yeah. Yeah, could you also check like the requirements ERCs? Because let's see, this is not Nothing required in there. Just the 165. Okay. Okay. All right. Okay. Yeah. Yeah, if you apply these comments then then I can merge it. Let's see because this was also resolved I think.

Okay, so I just added the Okay. Perfect. Cool. Cool. I think we can move to the next one. Yeah. If these comments are resolved then then you can merge it. Next >> Nice. Nice. Let's see. [music] It's 2042. Oh no, wait. That's an issue. Uh next one is Orion's 1723.

Uh yeah. Cool. I can give a maybe like a 1-minute intro if you want to. I guess I can do that. Um so yeah, me and a colleague at OpenSea wrote this spec. We really liked 8004, which is an agent registry, but um we realized a couple of patterns were kind of emerging. One is that we thought that there'd be this kind of like almost like a paid marketplace for tools to emerge. Right now, tools and skills are mostly free and open source.

Um, but we were thinking that these paid skills were going to emerge. And then in addition to that, the X402 has allowed for agents to pay for a per tool call basis. But we also thought that, you know, living in the world of NFTs and subscriptions and different types of access gating, that this would be helpful as well because a an NFT collection may develop a tool for just their members or you may you can create an NFT collection to create a kind of a a membership base that allows you to call into tools that you may develop. So, yeah, the the registry is pretty simple. You register your tool and then we have this concept called predicates. And a predicate contract is is what you look at to see how you're

gating the membership. So, it could say you need ownership of a NFT collection. You need an NFT subscription that is active, but it could also expand to being like validating ZK proofs or off-chain attestations or different kinds of things. So, it leaves the predicate layer very open for people to kind of develop, but it leaves the registry kind of a bit simple and dumb so that people can use it as one place to register and then create different kinds of ways to >> show whether you can access this tool for for calling. And then you would publish like a well-known manifest at your URL and have a Keccak hash of that and that helps lock it down so that people can't just your always your tool at your URL is the

one that's pointing to like the registry information. [music] Cool. Nice. And this also got some friction, right? I understood that on X you got like what was it? 250k uh views? Yeah, yeah. Um our the tweet I had announcing this had 270,000 impressions, which just blew our expectations out of the water. Uh so, yeah, we got a lot of support. Um Jesse from Base kind of like replied to it and a couple other people also um Vito or what's his name? At the Ethereum Foundation, he works on AI.

Oh, yeah, Vito, v i t t o. So, he he also expressed support, so I'll be reaching out to him to >> to to chat about this, too. Nice, nice. Yeah, exciting, exciting. Yeah, just going to comment like these very small things.

Like we always we always link these. So. Tomorrow. Yes. Mhm. Yes, and also like abbreviations, so this CAIP or CAP or I don't know.

We we need to define them. >> Sure. >> I'm just uh wondering if uh the CAIP I understand it's a standard for chain agnostic. Um I am not very sure like how do we mention it or use it because we are obviously not providing any link here. We might want to check if uh the links are permissible for CAIP and we can perhaps use that in the proposal in order to give full context to the readers.

Okay, let me actually check because So, I'm not just for for for the audience like uh I'm not super deep into ERCs, so you might think like why does this [music] person not know what a CAIP is. Um but okay, so this as I now see it, this seems to be well, it looks like an EIP, but it's not it's an CAIP. [music] and yeah, we maybe we should discuss this at an EIP IP meeting, but I understand that this is maybe like another repository or or or well, uh something that we might want to add to [music] the trusted URLs.

Yeah, right. That's what I'm proposing. >> Perhaps we need to go back and check if CAIPs are allowed to be linked. If not, then we can make a proposal to make it permissible. Yeah, I'm I'm fairly sure that this is >> 5757 it is done. Oh, yeah. You can check it in You can check it in EIP 1, but how to make a proposal is explained in EIP 5757. Oh, it is allowed. Yes, very well. Nice. Okay, this is interesting because I've never Yeah.

>> Wow. Wow. Okay, cool. I I learned something new today. >> [laughter] >> Okay, then uh then yeah, then then we should link to these to these CAIPs. >> Yes. CAIPs. Cool. We can do that. Nice. Nice. Nice. Nice. Nice. Okay, great. That's That's cool. That's we already have this. >> Yeah, maybe just as a as a general

[music] comment because I just raised like the points. Okay, should we like make like some like these examples like [music] in a more general sense that we should not target Solidity, but I guess that actually does not make a lot of sense. Because like everybody or not everyone, but but most developers use Solidity. So, then to use like to abstract this language in order to to to yeah, to be like more [music] future-proof. I think that that doesn't have like any practical value at this point. Um, but yeah, like if Solidity at some point it gets replaced, then we should be aware that these specifications might also be well, get outdated, but yeah, I would not see that happening in

the next year or so. >> Mhm.

So, here here in these docs you say without calling anything, but I would assume This this could be somewhat ambiguous because what is this calling? What is it? Is it like an EVM call? Is it like a function call within your contract? Yeah, I think it meant more doing it as a call rather than as a like a in a transaction scope. Um cuz cuz there's a has access and then there's a try has access. So, I think the try has access shouldn't have any kind of like state effects.

Um but I can I can clear clarify that. Sure. Yeah, I mean maybe it's also like some nitpicky comment, but uh yeah, like an EVM sense like a call would mean like an an an an call to an to an external access, but oh yeah, okay, it's a view. Yeah, okay. Yeah, maybe it's also clear from from the from the context, but yeah, maybe like the word call can be interpreted in in in multiple ways. Yeah, okay. Yeah, I can reword it I can take it. Cuz yeah, the word call, as you say, is kind of a in the idiom context has its own.

Yeah, exactly. Yeah, yeah. >> Yeah, I'm not sure if you maybe are

doing this, but if you could like link to the all the CAIP um references in the in the in the EIP. Yeah, cool. And one another piece of suggestion here, when you are trying to add the link to CAIPs, try to use the commit link if possible because sometimes our bot become picky and it does not generally accept get directly because this is outside the directory. Okay, the commit link as opposed to like the main branch for the URL. >> Yeah, whatever you are referring for this particular proposal because it is possible that it gets updated in future.

That's true. Yeah. Yeah, that's actually also like an interesting point in [music] general because is this Yeah, okay. Yeah, that's actually a very good point in the Java class so the CAIP is still in review so it Yeah, it it it could still change [music] like this is from 2020 and maybe this is like a very generally used CAIP.

But yeah, it could indeed change so [music] indeed this this should be permanent because you could reference something in the CAIP and that might well change tomorrow. Well, that also brings to another point of discussion for our editors. Maybe we can discuss it in EIP IP meeting. Generally speaking, we do not [music] allow any proposal in Ethereum repository to be there if the proposal's status is not superseded with the existing proposal. For example, if we are referring to another proposal, that proposal must be in either final status or in last call or something like that by the time this proposal gets to that final status that

is already merged there. I don't know how do we want to deal with this because it seems to be in review for over 6 years now. Mhm. But yeah, having a commit will help there. It's another discussion point. Yeah. Yeah, that's actually a good point. Pooja, could could you add this discussion to the next EIP EIP IP meeting because I think Yeah, okay. Yeah. Like for practical purposes, I would say we might not want to do that but on the other hand I don't know. I think that permalinking it should also solve this [music] issue somewhat.

Yeah, that's right but I will include it. Yeah. Yeah. Yeah, the challenge is as an author that's out of my control like whether how CAIP does their own, you know, process. Of Of course, 6 years is like >> a bit too long, but but like it's hard for me as an individual person to for them to move to final firm in order for it to be a requirement for mine to move to final, but um I see where you're coming from. It >> makes sense that you can't really finalize a spec if you're depending on other things that aren't finalized. Yeah, exactly exactly. Yeah, so that's what I mean that's also my feeling because like for um yeah, for for like practical purposes, this will then not be handy because this will then

um no, it it would essentially mean that a lot Well, if you would reference this EIP, then you could like hang in a review for like, well, 6 years in this case. Or maybe maybe longer and that's that's of course also not the not what we want. But yeah, the the permalink should at least Yeah, that that that should address this this problem. Yeah. Because like in the end, you want you want the ERCs and the EIPs [music] all to be well, self-contained is what I would like to word here, but that it is clear clear also in the future like what you actually meant at the point.

Um and yeah, the permalink should should [music] point to whatever you were linking to at that point. So, that that that should be fine. Yeah. Aha. Unicode normalization form C. It's not near field communication. Nice. This is the first time I see this one. Yeah, okay. I think the BOM is the byte order mark, right?

Oh, he's fine. Thank you.

>> Let's see there there are like there's a reference implementation which uses like a major minus scheme and there's also like in Here there's also semantic versioning but here you use you also use the patch. Is that correct? Yeah, the major minor was just for the registry itself and then this is for the tooling metadata. Okay, cool. Cool. Yeah. >> Oops, yeah. Looks like there's a

Exactly. Back to missing. Yeah, if you could also check because so the CIB the these would need URLs but also the RFCs. I think there are also some RFCs in them without the the URL. And this is this is like just because if you read it, it's so handy if you can just click on this thing. That that that's just handy. Yeah. Yeah. >> Is this correct?

This slash [music] here? So that would be or is this comment maybe incorrect? Uh oh yeah, that the comment looks incorrect. I think above is the two comments above that says the 19 format has like the slash in there. I see it. Yeah. Yeah. Yeah, so let me fix that that comment there. >> Yeah, mhm. I'm This might sound like

super nitpicky, but isn't there like an ERC or or maybe an EIP which mentions like the the naming of Ethereum itself because should it not be done Ethereum mainnet? Yeah, that's what the the the chain ID is there and that's like like the cap that cap 19. Ah, okay. Okay, okay, so this is already part of that. Okay. Yeah, so the chain ID is included. I see. I see. >> I think you'd like this part. You have

to verify ability. Yeah, you were mentioning that um Yeah, I think one big gap here for the AI tooling is um yeah, how can you reproduce it? How can you get um kind of proofs that um what was actually done was done by the the calling. Nice. Nice. Yeah, exactly. Yeah, and this is uh so this T at station, I think this is [music] also abbreviation.

Could you um define this abbreviation? Mhm. Yeah. Yeah, this is very interesting. The human readable summary of the

verifiable ability setup. Do we also have the trust me, bro, verifiable ability? Do we have to what? The trust me, bro, verifiable ability. Sorry, it's a bad joke. >> Just Just trust me. Yeah, also the E 2 EE. Is this also for which could be useful

[music] like something like um verifiable hardware or like verifiable sensors? Uh yeah, what what was your question about? Yeah, yeah, just a like a general question like like this this [music] ERC like could it also like target Uh is is a sensor, [music] yeah. Yeah, yeah, the idea is um I think kind of these type of attestations will evolve over time, but um there is a way to have kind of hardware attested and then be able to give proofs that shows that the hardware ran uh what they're saying it ran.

>> Right. Okay, interesting. Cool. Yeah, there's just some providers that are starting to support this. I think uh Venice AI is one that um you can actually choose um a model and a calling type that would give you a hardware attested TEE, which is pretty cool. So, I think it's the the future of this. Right, yeah. Yeah, I like because I this is is maybe like more from an AI perspective. Um but I was thinking also a bit more like as an agent [music] well, that would be like a very static agent, but like as a like as a sensor reporting these things, but that might be like

beyond the scope of this ERC because this targets mostly [music] Yeah, maybe like I said general

comments. [music] like the audited source and the proprietary source, [music] like these could technically also be like the same thing, right? Because if you have a proprietary uh, source, then you could just make it all of this by not setting up a a third-party auditor, which is actually yourself, but If that makes sense. Um, yeah, I think audit is one level higher if you have a third-party auditor like releasing a report, then you would kind of go to that next level.

Right. Yeah, but I mean like in in a setup like that would of course also indicate like people will will might have malicious malicious intent, but um, if you would set up like a a shell company or like whatever to use that as a third-party auditor, then you typically are audited. Yeah, yeah. Yeah. Yeah. Yeah. I mean, I'm always thinking like how can this be abused and what can go wrong? No, of course. Yeah. Um, the goal is to make it as trustless as possible, but >> Yeah, yeah, yeah, yeah.

Yeah, third party can mean it's a kind of opaque, you know, what you have to look into what that third party is to understand if it's a real trusted third party. Exactly, exactly. Yeah. >> Um,

let's see. I think this ACE encoder is also not Oh, wait. It's SK. Okay, yeah. Okay, let's uh Let's see if I can label it. 2 E E E E At least I I assume that this is ACE. Yeah. That is also a bit awkward because we

here we also have abbreviations, but >> yeah, DNS is I think well known. DNS also, but yeah, I mean >> it's also like part of what like what how do you say this like what bubble you are from because if you are from like some other bubble then you might not know what >> DLS is. Mhm. Uh okay, yeah, I think for style like

this is also Wait, is this Solidity? Uh you might want to add the add syntax highlighting [music] lighting here. Yeah, let me clarify that, but yeah, it's just kind of pseudo code. Yeah, yeah. Oh, it's it's pseudo code. All right, yeah, all right. Yeah, that's fine. >> Yeah, here you refer to check for, but

what is this check for? Maybe because I think this is the fourth item in this list, but it's a bullet list. So, if you [music] convert it to a numbered list, then it's clear. >> Um you're welcome. Um

Yes. We are at time, so I just wanted to maybe um tell you that um if you can maybe take this one async. It seems a new proposal. It might require more thorough review. Mhm. But in the meantime, I believe uh the other guy has already finished fixed the suggestions that you have suggested for PR number uh That one. 1679, yes, that's right. Yes. So, we can merge that. Yes. And I also see while you're reviewing it, I'm just mentioning it. I also see Alex Forest on the call uh which is here for EIP 4337.

That is another very important proposal, and we would love to see that proposal go to final. So, if you could maybe take a look at it async and just merge it for last call if everything is all right or maybe leave your comments. Yes. Uh which one was this? Yeah. And one last piece of information for authors joining here today. If you are on ECH Discord, uh we can obviously communicate it there. But one another way of letting the world know about this EIP or ERC that you are contributing to Ethereum repository as a standard is PEP and >> EIP. So, we do invite you all to maybe talk about your proposal on PEP and EIP to share with the rest of the world,

especially the use cases and why that is [music] considered as game standard. So, please reach out to us for scheduling Yeah, before you EIP or the ESC which you just [music] mentioned, which one was it? Uh it is in the last call uh 4337. 4337. Ah, this one. Yes. >> Okay. Yeah. And of course, Ryan, since you are already reviewing it, so yeah, if you can maybe quickly take a look because I noticed that uh the author has implemented all the comments suggested by Sam Wilson from the last meeting. So, >> and I also know that there are a lot of proposals which requires 4337 to move to the final status.

So, if we can move this one faster, it will help many other proposals. Right. Okay, let me let let me then then >> go through this. Yeah, let's see because if Sorry for the interruption, Ryan, but I hope the proposal will be reviewed. Yeah, no problem at all. I didn't mean to take up so much time, but um yeah, I appreciate the review and I'll I'll get through all the things you have written. Yeah, Ryan, I I will finish the reading your one after after this after this call.

Cool. Thank you. Looking at it like [music] these high content ESCs, yeah, it just takes a lot of time. Which I also don't want to throw away these these kind of uh uh Uh okay, this is about to All right, okay. >> Let's see if you can do this.

And all these comments will need to be solved. Yes, I think I think this this this looks fine. Let's merge it. Um yeah, Ryan, I will review your one after this call. And uh Yeah, I guess uh is it it for today? [music] Only three, so yeah. The big big big issues, yeah.

We made a big progress here today. Yes, and of course there are a bunch of other PRs whenever editors get a chance, they take a look at it. This is what we can do in 1 hour. Hope to see everyone in the next call. Thank you everyone for taking out time for today. Thank you so much. Have a nice night. Thank you. Bye.