EIP Editing Office Hour #17

EIP Editing Office Hours · 16 May 2023 · 55:14

Meeting 17 of the EIP Editing Office Hour, held on 16 May 2023. EIP editors and proposal authors work through open pull requests and questions about the Ethereum standards process. This meeting covers EIP pull requests heading to Final, Review and Draft along with proposals coming back from Stagnant.

Topics

From EIP Editing Office Hours, hosted by ECH Institute.

Transcript

welcome to EIP editing office hour 17 I have shared agenda and chat we are joined by EAP editor Sam Wilson and a few authors with proposals to be discussed here the first proposal of our discussion is to move the proposal into final status and the pr number is 6901. so Sam if you may um yeah pull up your screen and we can look into the proposal sure so I already went through all of the two final ones before the call um so 6901 had a Content change recently so um we'll have to restart the last call deadline on that one and 4910 I'd like to review offline because it's really

long all right not a problem so those with okay perfect and you have already immersed rest of them which were there so we can quickly okay before we move ahead 6901 author Stephen I I believe uh you're fine with that I don't know if you get a chance to take a look at the comment that Sam put just before the meeting no I didn't actually uh oh yeah I did it literally one minute ago it's just um traditionally if you make large changes to the content you have to restart the last call deadline

um okay but that last change was actually uh more days ago oh was it okay I mean the last commit probably was just uh about uh so some wording but the actual interface I think it changed like 10 days ago okay yeah so I'll um take another look at that I'll add it to my to-do list but uh yeah we'll we'll have to change the last call deadline a little bit but maybe not the full two weeks so that was six four five four so all right cool did you have any other questions or are we good with moving forward on that one

oh no I yeah I will just uh look for the last time the interface change because we yeah just the interface right it's any substantial content changes um well yeah yeah but uh yeah I mean all substantial changes I think we're done a few days ago okay yeah so we'll we can take a look at that um yeah okay very well so the next one we are joined by author for PR 6806 which is in draft this one here all right did you have any specific

questions about this one or combo uh if you are talking we are unable to hear but if you have any question specific question please share with us ah nope yeah it's simple and useful I think I can't okay all right so

okay turns I couldn't hold with the specified nft and the length of time and second CMT has been held by the current account okay there's a contract phone or an authorized account to specify whether specific transfer should be ignored for the purposes of tracking okay so this gives a lot of a lot of power to the owner of the like the deployer of the um nft contract right okay right right Okay so

oh wow all right so pretty standard feedback um this is more motivation um because this paragraph here isn't describing like a choice you made in the standard itself um I think these are okay yeah these can stay uh just this last paragraph should be in the motivation section yeah governance implementation good okay okay so as a non uh editor commented

more as a technical comment functions that are generally only called by the deployer of a contract don't necessarily need to be standardized in an EIP um so this set holding whitelist address um function that's kind of like the mint and burn functions that open Zeppelin provides like it's it's not something that needs to be standardized between implementations the deployer is the only person who's going to be able to call it so it doesn't really need to be part of the standard and then whichever you know ERC 721 that's implementing 6806 can have their own way of setting these holding time white list addresses

um basically it's just most people won't ever need to call this function only a very very limited number of people will and those are the people who are going to understand their contract in the first place um yeah okay I see yeah yeah and then that would be another good thing to put in your rationale is why you don't have a function but it's up to you right like it's okay this seems um okay

yeah I mean I think that's my only comment on this otherwise it's it's pretty decent okay thank you sound no problem all right where are we off to next so the next one is the pr number six nine five six all right that's for draft as well yeah Thomas's uh request right now reviewing request sorry I didn't catch that I think this was a colleague of mine sorry about that no I am Thomas oh hey

okay let's take a look it's a pretty long one all right let's see so tell me a little bit about it what is it uh well it's um as the name suggests um we bind nfts to assets primarily physical assets um so that's this term vegetal all around um and we quite often um the physically assets are bound for a serial number something in the metadata and what we suggest here is we bind it directly on chain to the Token ID one to one and Inseparable over the whole lifetime of a physical object basically

so you really can reflect physical objects on chain and that is done and that's a bit of a fancy thing um through an oracle authorized transfer so we sign an attestation of chain which is then verified on chain okay interested Oracle so it would be a a drawing there which makes it probably easier to understand okay I will definitely take a look at that okay so thanks for the overview so first thing that jumps out is that there are several proposals that are linking various physical assets to things on chain um one of them I think was by plasma and

it's specifically real estate have you talked with any authors of like similar proposals or uh to those not but we've talked a lot with offers from sole bound tokens okay because essentially technically what we're doing well maybe maybe I can jump in here we even made an implementation with CIP I'm local by the way the other router here uh we looked into southbound tokens first because we were not uh sure how which way you want to approach it um sorry who's better whose parts are in the back yeah

um we checked uh saltbound tokens first um and we made the first implementation on EIP 5484 with soul bonds and then we figured that this is not covering the use case we looked at for example those uh real estate EIP so you mentioned um it's also not the same use case because it's not a hard link between the asset and the token actually okay yeah that uses like a legal construct to link them so this is a little bit different yes and this is a real Hardware link there are similar Solutions like um for example

uh the erc721a specifiers they made an nft but this is an eoa so then a new highest owner and we don't we don't build any form of Chip or Hardware or something like that into into the physical asset actually okay we just have a passive marker interesting all right okay so the first thing that jumps out here is you're using these capitalized terms or these just because they're special definitions or correct okay definition session further

down below yeah okay Okay so this is mostly just a formatting thing to match the style of the other proposals but um we normally use uh uh back texture signify code so um if you wouldn't mind using perhaps bolded text or or just something else to other than backticks for the for those um that'd be great foreign okay

uh that's abandoned for token through our classification of control of the asset okay let's contact thank you foreign

okay um but the whole proposal is a bit on the long side yeah um that's okay it's just um the abstract is the only one we we really put like a limit on the length um how much should we shorten it um usually it's it's at most one or two paragraphs um so like

for example like a an asset example of physical object is equipped with an anchor uh is probably fine and then this this blurb describing like the properties of an anchor you can probably just move that into the specification section um you just need it to be like a really terse technical description of The Proposal um yeah and for sure it wasn't generally quite difficult because there's a security relevant part of chain as well it's not too big but how to put that into an EIP was kind of yeah it's a bit hard if it's security related there is a section at the end obviously but uh yeah okay

okay [Music] all right yeah so I'm going to probably take this offline because there is a lot here to go through um no it looks it looks pretty good um I think you'll need to lower case this um okay I mean like quickly looking at it this looks really good um it's just a little bit much to go through on on the call um I will take a look at it offline so

this is 6956. yeah I mean in the meantime the the pull request is now open for two weeks I think we worked a bit on the reference implementation which probably might also have some interface changes would you prefer us to merge that before no you can just make them right in the in their PR it's totally okay plus 10 then we would also do that um but it requires them changing also description a bit too but I can do that when we unified the building and get rid of the tactics yeah so so yeah just um just kind of go ahead with your implementation and everything and just update your um proposal like it should be fine and and obviously don't wait for

the EIP to go to final before you start working on your project this is kind of like a a separate process that you'll be going through okay cool yeah so I'll uh yeah I'll get through that sorry it's taken two weeks so far yeah should we ping you as soon as all the changes emerge um no I have all pings turned off for the most part um or else I'd be swamped with people asking me to review stuff uh and so I will

um yeah it's on my to-do list I'll take a look at it yeah probably done by end of tomorrow okay yeah perfect all right yeah the next one is BR BS Triple H math checking and evm and we have been joined by renin Souza hi hey why didn't this get merged did it just get into a fight with a bot and what's going on all checks have passed Matt has requested changes what were your changes man so he was the first one to request changes and I changed them right away uh

I don't think I I don't know if he needs to if he specifically needs to approve as he requested it but was the first ones I I changed yeah it's just um Matt sometimes comments with the like hard uh request changes option which means that other people can't override it oh makes sense that's all it is so let me just make sure that his all of his changes are um case so you approved there and then you requested changes later so open zap lens solid layer efficiency who can yeah okay so that's done uh

uh and then did you have any other blocking changes meant no okay and this has been like a month yeah so I'm gonna just clear Matt so foreign yep so that's all that was

just mileage yeah all right the next one is a PR 6786 and we are joined by auten yeah um hey this was hi uh this was actually uh made by my colleague but he's um he's not here right now so um I think uh these were updated as you can probably uh it was just the um pull request number yeah yeah okay did you have any specific questions or just looking to get it reviewed

uh yeah just looking to get it reviewed and uh yeah we're not very familiar with the whole uh process so um that's also why I'm I'm here to look at see how these things work so the uh probably the most important thing for you to take away from this call is that this is very author driven um every status change like going from draft to review to last call um that's all on you to open a pull request to do that so whenever you think you're ready to make that change just go for it and then uh yeah we aren't we are going to change your EIP for you except through comments on here yeah right right okay I understand yeah so um

okay so first question uh did you look at 4910 when you were implementing this or writing this um 49 10 I am really sure I have to um just a second uh because I have discussed with my my colleague about this as well but uh he actually had to move away from his apartment now they and uh he couldn't join um I'm going to assume that I probably have commented on this I have not okay I'll just leave a comment to that effect down here um for ERC

49 10. just because we have quite a few like mandatory um royalty payment Eeps that are out there so um I'd like to just point everybody at to make sure everybody's aware of all the other uh ones that are out there so uh okay let's implement the interface okay uh be royalties character

okay and then this is on any nfts this will work for 721s and all that okay maybe okay yeah yeah same throttle them there uh Sports interface okay so um okay

yeah yeah so that's good uh function user payment okay it's fine test cases okay okay oh okay we'll just reference that perfect thank you and uh after we do this I'll also I mean I'll also let him

know about the um other um EIP the 4910 yeah I put it on the discussion thread so it should be there um yeah so but I think that sort of covers a different angle and things but yeah yeah this looks like view it so this is kind of like a like if they want to pay royalties this tells you who to pay royalties to uh it's sort of uh we well I'm just gonna uh let out say that we kind of want to link royalties to um uh something else like functionality and then we want to keep track of whose paid royalties for the like

okay identifiable transfers and yeah so we need to sort of keep track of that um because just somebody going to the Creator and paying those royalties isn't uh like trackable it makes sense yeah yeah at least this way you can like you know that somebody has paid the royalties correctly or not yeah yeah yeah um okay and then we've got this good

yeah I think I think those were there just uh or the tests to work maybe ah okay let me think I'm I'm not really sure but we'll look into that because the other one has them as well so I think that was part of the reason okay contracts um okay then the tests yeah Okay cool so

yeah it's just um if every project includes all of their build system configuration files like the repository grows super quickly so we try to keep just like the core parts of um like the reference implementation there um yeah so sorry about it okay so should we should we then would it be better for us to reference a different repo with the tests and like the whole thing working or is that not necessary yeah just if you can get it down to just like your your tests file and your um contract itself that would be the best and just keep it in this repo okay okay we'll do that thank you by the same

seven eight five yeah that's Stills okay cool which one is extension so okay

specification wow foreign completely missed the point of this so this isn't a um like utility functions to make interacting with an erc721 easier this is defining a concept of a use of an ERC 721 yeah okay okay yeah that would uh I'll also like update the description to

be more uh helpful in that and expressing that okay I appreciate it and then uh yeah just my uh my reading comprehension

there's uh okay I must have okay function update utility set utility URI get utility URI um so who can set the utility URI is that yeah so yeah this was uh this was mainly for the creator of each nft because there are collections uh that have like multiple creators like the storefront on openc or other places um so basically I think it would be related to there's an EIP about uh Creator

um and royalty that gives you the Creator address for each nft so I think that would be a possible uh source of identification either this or the contract owner okay but so the idea here is that however that is expressed so somebody who is not the contract deployer might have the authority to call this function yeah okay so yeah then it makes sense to have it in the standard yeah that's that's good um it's right here um

oh right I see yeah it's it's not really a huge thing that's why it's going over here and not as a comment on their PR on there okay so good uh here's your changes to the UK picture or view set utility then this came in and Save codes oh yeah I see good point

uh Mr Collins we got sees 785 okay it's Jason schema all right it basically just adds um the set of utilities like from line 97 downwards oh okay perfect yeah um there's one oh thank you perfect nope down there yeah it's like yeah 150 something yeah

okay yeah I think this one should also maybe be moved to motivation some of it as per your comments on the other one yeah some of it um just because yeah so I'll just leave a comment here um oh you know what I don't need to type it out again yeah I every week I type out the same message it's uh it's great okay this standard is

compatible okay test case is good yeah so similar thing um I'm just gonna be less polite here um don't take it personally yeah it's uh the test cases and and the build stuff it's also there because so we kind of made them together so yeah makes sense um that's a long one all right okay

good CC you know this needs to be uh this is 0-1.0 and okay okay same thing good all right awesome and then if we make all these changes are we coming back uh two weeks from now uh you uh somebody should be along to review

them and if they aren't you can definitely come back but um yeah it should just happen on its own okay so in case uh the uh the merge should happen uh by itself like automatically if there are no more uh changes requested afterwards so an editor has to approve it so it'll either be me or Panda or Matt um or like client I guess but um yeah so when somebody approves it it'll merge oh okay awesome thanks for coming out thank you yeah all right before we move to the next one uh there was this question in chat by

author uh for the pull request in last call 6901 I I suppose you have mentioned last call deadline as 30th of May and is checking if it can be 23rd or 27th um I mean the safest would probably be I'm fine with the 27th yeah if you just want to make that change yeah sure all right uh so the next PR here is a PR 6969 and we are joined by Zach Cole hello good morning you can you hear me yeah I can hear you

yeah so is this still being discussed or is this good to go in here okay I don't know why GitHub keeps the um the old annotations around it's it's infuriating yeah do you want me to go over it or I'm sorry I'm not super familiar with the process oh did you have any uh questions that you wanted answered about it or are you just waiting for somebody to merge it here yeah just trying to get a merge so I could because right now Kevin owaki's uh like the he submitted the pr so it's kind of it's prohibitively difficult for

me to like yeah exactly yeah yeah so uh it will not merge unless this line changes to 6968. okay so that's all that's required I wouldn't say that's all but that is the minimum uh you'll need discussions too oh we have that as well which is yeah it's just not in it it's just like Kevin is gonna get a guy I don't believe I'm not I don't know maybe I'm speeding uh I don't know if he is or not but uh I we have The Magicians yeah so he responded in the comment but he didn't update the document itself yeah so I I cannot edit the conversation yeah I can't really

either I can submit a PR to his cork uh but we do want to maintain 6969 adjacent uh numbers yeah yeah yeah so if you submit a new one uh from your account um like another PR uh with six nine six eight I'll I'll approve it like that'll be fine um okay just make a note of it in the description or as a as a comment on your own PR that it's okay because yeah if if Kevin's having trouble with Git then we can we can work around it yeah I don't know if it's problems or just time constraints or what it is but uh yeah just kind of bottlenecking me we have

like a working group that's already working on it and we want to update the specification and everything and I don't really want to like get too bogged down and uh sniping a new number I'd rather kind of just get on with the show yep yeah so just make another PR exactly the same content um if you want exactly the same commit and just put a comment on it that I said it was okay okay and uh so that means we can get 6968. yep yeah for sure it's just yeah cool all right well that's all I got of course it's easy any other things you'd want me to add to this document um

see so [Music] got it um obviously remove all that uh using protocols

so got it specification gas tracking good um yeah yeah so it's just the number and um

cool cool yeah so all right what are we off to next thank you oh no problem thanks for coming the next one is a PR 6239 and we are joined by Jessica Chang Ed yeah over here hey hi okay oh no it's not mine oh this is so this is by Jessica Chang I guess is Jessica still on the call uh yes okay oh yeah she is there yep okay this is just me taking a long time

to review this isn't it um yes and this time we would like to uh second merge if you don't have any more comments okay actually yeah triples just open tokens good it's good so I think the only thing that was left on this one was the

definition of that struct right foreign so okay so who would be calling this is

this is this the owner of the token or the deployer of the contract uh it'll be the deployer of the contract okay so that I think a really easy way to resolve this um rdf data kind of disagreement we've got going on here is to just remove it entirely so um let's see

so yeah I think that makes it pretty simple just remove ice semantic spt update from the standard entirely and it'll be good to merge all right uh okay so I just uh let's ask is the option to just keep that um the problem with it is it's not defined like if there was a specific um definition for this struct like one exact rdf data struct then it would be totally fine to keep in but because this

isn't defined by the specification you can't implement this interface like completely right like somebody can't copy this paste it into solidity and then implement it they have to also Define this rdf data memory struct or just rdf rdf data struct um and if you can't like if you don't have a common definition of it it isn't really a standard all right thanks all right so we have one last for today and that is PR number six seven eight seven uh six seven eight seven order book decks which you face withdrawal yeah I'm here John vacation

if you have any specific question for this proposal please do let us know yeah I think this is just another case of me um not reviewing things that I've reviewed before hello I am Jessica also Jessica hey now I get the confusion okay okay yes okay good okay and then let's look at your

motivation Okay so I think foreign

yeah that makes sense um okay I don't really have any good examples I think everything here seems pretty pretty well just like pretty obvious at least to me why it's there um

okay okay yeah so it's just that the the content that you have in your rationale section is is more motivation um but I also can't say anything that really needs to be explained so I can't really help you there um which is unique request okay uh that could be used to smooth the force which I'll use in the commit

withdrawal function okay she's trying to shoot a force which one of a certain amount foreign

all right otherwise I think it looks good um just that's it so yeah Sam I think we have covered pretty much all um for whom we have author present here in the call but there were a few other authors who left common but uh we didn't get to take it today so yeah whenever you get offline time to maybe take a look there are four or five more PRS many awesome thanks so much yeah thanks for putting this together I appreciate it um talk to you all in two weeks thank you have a good one everyone thanks then