EIP Editing Office Hour #36

EIP Editing Office Hours · 16 Apr 2024 · 53:56

Meeting 36 of the EIP Editing Office Hour, held on 16 April 2024. EIP editors and proposal authors work through open pull requests and questions about the Ethereum standards process. This meeting covers EIP and ERC pull requests heading to Last Call, Review and Draft along with proposals coming back from Stagnant and miscellaneous pull requests.

Topics

From EIP Editing Office Hours, hosted by ECH Institute.

Transcript

welcome to EIP editing office our meeting number 36 we are joined by Sam Wilson the editor who will go ahead and review the proposals listed on the agenda for today's meeting this is issue number 330 at ecat her/ EIP GitHub repository um over to you Sam uh I suppose there is one um there is one um EIP that you would like to begin with we are also joined by few authors but maybe we can get over there later on sure I just want to finish up what I'm writing here and it's related I'm writing an EIP so um yeah so create two I think is F5 so this

is the IP 374 um as I'm sure most people are aware it got added to um CFI yeah Prague uh MD is that the right one um know what I just won't link it uh the font size is really small if you could maybe increase it then it will be better visible how's that I don't know if it is my screen is it still uh too small or is it just not updating yes it's still too small yeah weird

yep better all right get uh whole six lines that we can read um was I copyright lost where I was I'm sorry and C dep and fker contract nonchain ID there we go using Create two just because there's yeah perfect okay so I think that is all I needed to do for this so let me uh just make a p request

for this there we go and then this needs to be a draft and done all right so let's go take a look at what we have to do today uh so you said we had some authors here yeah so we are joined by Daniel and his bull request number is 282 in ERC GitHub repository it seems like you have already reviewed this proposal earlier and he had made all recommended changes so we can perhaps take a look to merge

The Proposal let's do that 282 okay title stuff yep that makes sense yep okay sure let's go and give this a read through batch call and coding in SCA smart contract account um there there we

[Music] go so multiple and hopefully that still fits in the uh the thing but it's a good description uh with Okay good draft standards good okay so batch C and code solution for small contract account wallets to consolidate multiple calls into a single call saving gas yeah okay it's good space here um can we uh okay good so I'll be able to just apply these for you okay

typically interactions between users and contracts have a series of coherent operations such as approve transfer from um while EA W require us to confirm each operation okay this Pro succeed brity this encoding [Music] method okay users calls okay calls okay calls good also implements Gas payment delegation not mutually exclusive okay cool okay batch

calls two value data follows okay so one kind of note I'm going to make here is um these kind of things should be written like this cuz like um Daniel it seems you are on yeah yes sorry oh no worries oh no I sorry I I was joining from the web like web browser so I I don't see the screen share but anyway if you're making any suggestion we will try to apply it and we'll come back next

week or next time I should be able to um apply them for you they're all really really minor suggestions so it's looking really good thank you very much so um this should be because it's not code and then these need to be like this all right follows and then um yeah so the mermaid stuff probably won't render um so you might just need to replace it later um yeah that's should be pretty easy um okay thank you no noise

bites okay patch call sequence so this will just be like this as [Music] follows okay data length data okay okay good uh each Callum capsules three parameters to Value data instruct however using instruct

overhead data increas the two data fix types the additional C read the data from B call using slies gas efficient method uh bch calls coding can compress okay yeah that makes sense okay uh change the consensus lineary y does not change other yep perfect the pro the encoding of batch calls while the specified specific implementation and naming the the project

using um BGE calls referred to as atom Calles multiple operations on behalf of the user perfect okay smart wallet. Soul I'm sure your solidity is good uh this cool yeah that's great so let me uh comment that let me zoom out and then comment on this and then we can approve all of these suggestions and okay

commit and approve there we go so that's going in so where we off to next uh did we have another author here Pua yes we are joined by another author and he has two proposals in draft first one is 266 in ERC depository okay 266 all right is this one I've seen before I don't believe it is oh yeah okay see

okay sure I [Music] say okay sorry it's Daniel here I lost the connection so I'm back so I I saw your suggestion on GitHub and I will apply those and come back the next meeting Tom uh they should already be applied um okay yeah should be good to go okay thank you very much no problem for token balances yeah okay it's fine

function is called share of okay yeah so let's give this a read through all right ownership Shar extension yeah that's really good much improved so the pro is attribute of own ship and profit reach token under signifies St profit rights okay cool um presentation stes through the balance

of token by water address of each token token share for the token H to merge the features of holders okay okay so 721 require 721 good to shares nice okay should we addition sh to a token flexible management six okay okay it's fine good then you have a

reference implement ation uh security considerations okay yeah I think this is great um don't really have any more comments on it so I'll just give you an approve then we're off to 292 right okay okay

okay twitch tokening okay mechanism 71 tokens allows each token to have a unique name with a set expiration date sh uniqueness okay decentralized domain registration okay okay okay so it's meant to be implemented by 721 require 721

perfect um token is named name changed okay token ID of given the name yeah that seems fine foring okay and then yeah that's fine I think um okay maximum

duration okay to facilitate indexing gas efficiency username should adhere to a length constraint of three okay characters to the range enhance readability so the way this sounds to me is that this is optional um and it's like if like if want these properties you should do these restrictions but it's not necessary is that a reasonable understanding of this ell um is the author of this proposal um I don't know if you have a microphone and you would like to respond

to the question I'm not sure if there is is a working microphone s we can add a comment yeah exactly okay and then we can approve

this and then we can resolve this and then we get to wait for this thing to finish or will it be merged automatically yeah yeah okay perfect then I just need to wait for um this thing and then I can unresolve that I don't know why that rule was added but whatever um any other authors or am I just going through this list now yeah we can go with the list all right sounds good um I'm not sure Sam I think this is the incorrect meeting agenda uh not the EIP I one we need to go editing office and right

330 yeah so we have two proposals in last call okay moving to last call move there okay so let's see expand this okay so referable nft

reference mations NTS okay 721 referable indic last call deadline needs to be nice 30 okay the inherent extension of enties me develop expand everything there the is an extension of erc721 it proposes two referable indicators referring and referred and a time-based indicator

created a time stamp the relationship between each n of T forms a directed AIC graph allows users to query tra and analyze relationships beautiful okay many scenarios require The Inheritance reference and extension of enties for instance AR develop his en work based off a previous nft or DJ May remixes record yep okay stop Gap and exam the absence of established relationships between yep that looks good in the sense proposing a referable solution enables efficient apping reference relationships okay this stand accordingly introduces New Concept referable nfts which can transform static nfts into dynamically extensible networks

relationships stru Prov transparently users to query Trace relationships it can enable creators to build upon existing Works without the need to start a new Okay cool so relationship is a structure that contains referring refer referring okay other customiz and optional attributes not necessarily included in standard such Asing okay that's interesting so how does that work let's go find the relationship struct here

okay so down on the reference implementation you have it okay relationship do I have a return relationship no it doesn't look like it okay so can the structure that contains so okay oh you have uh 165 okay

good just triple check this yes that's the reference implementation yeah um choose

um okay so this is just a general piece of

feedback that I often give kind of the ideas that you want to leave as much freedom for implementers as possible um you don't want to say that they have to use a struct because um there's nothing in the interface that says that it needs to be a struct um just that there's those values exist uh so there there's really no reason to mention it in the uh body of the standard um okay so does that me does that this mean this proposal may not be able to merge today or we are just going to increase the end date uh they'll have to change this and and come back um okay unfortunately refering

of yep following functions so update node yep so set node referring of referred of supports interface perfect Target contract is yeah great um then in the rationale notice sure so okay referring of yeah so that's

okay function is essential receiving full m contracts within instruct public the getter only allow retrieve of individual values for specific key since we need comprehensive access to well St addresses and emission requirements so is this something specific to your reference implementation it is yeah okay

Okay Okay C so okay incentive [Music] compatibility Okay so [Music] okay um

okay that's all good okay security considerations spot time stamp B comparison such as transaction LEL okay um the change refence dis profits comp that's not spelled correctly I don't think and regardless of the change ownership not specified in this agreement referring a Tok will not refer its descendants by default in the case

that only a specific child getss referred it means the privity of the contract will involve nobody other than the owner of this specific child token alternatively a train of reference all the way from the route to the Token from rout to recording referring to explicitly Define the distribution of profits okay the sement functions have been deliberately designed to allow unrestrict minting and relationship setting akin to the open referencing system platform such as Google Scholar this decision facilitates strong flexibility ening any us to create and Define relationships between nfds without centralized control while this design alignance with the intended openness of the system inherently carry certain risks authorized or incorrect references created fa in traditional citations okay Additionally the open okay yeah that seems good so we will uh

leave a comment on here and that is the end of this one good so that one merged so moving on to 322 okay okay okay

okay okay spending okay okay good that's merged good cool okay sche 91 good okay take requirement okay good so this should be hopefully just a quick read and then it'll be good to merge so this

is moving to last call can I edit ah good I can edit that's always a good feature yeah at least for the last call stuff um I think I said 30 30 yeah okay so let's get rid of this let's refresh then get rid of this then expand this trees and engagements okay 6538 yep

good um why is there not a resolve button there it is resolve okay okay the specification established okay deployed at okay perfect uh sterilization stuff address okay must be able to okay1 with the following extensions perfect okay good and then POP key

okay cool resolve that um wait that's still incorrect 6538 okay back to where we

were wait and back to where we were okay with the centralized location cool contract okay into three sections okay that seems fine and rationale okay okay

[Music] implementation cc0 cc0 and the file was deleted all right cool that's exciting right so we have a couple of proposals which wants to get back from stagnant and a few proposals requested by Matt uh I think uh it's been a while when uh the proposal is proposed uh just that it is waiting for another rwer because yeah those are on drop

yeah these three are for uh coming up from magnet all right my understanding it is that it may require author approval wouldn't yes so if we go back to the conversation why is it why bot is not adding author like should Bing oh that's weird yeah why um that's really weird to all these three uh pull requests um they are by the same author but I don't

see the mention of that author maybe something is broken we might want to take a look ah it's because they don't have any GitHub usernames okay yeah so um okay so if I go here pretty sure his username is in here somewhere I guess not so we have to go

here here there we go beak I guess yeah yeah okay then we can go to here the SCS so this was 2335 there are three 2 3 3 3 2 3 3 4 and 2 3 3

5 okay so E1 I always forget the author format it's username first okay so that's 2335 233 4 is this a similar kind of deal here yeah same okay so okay and we'll do the same thing

here and then what was the last one was 2333 that makes sense see yeah so normally I wouldn't just be editing other people's eips but there's no like there's no way to edit these if there's no username so um I think this is this is something an editor should do because that's definitely to help yeah otherwise we would be waiting a long time like one person to another

person and nobody will be getting notification exactly yeah so can I rebase this now cannot but I can edit the conflex here so take this put that over there we can grab this new discussion thread stick that

here okay and then R of that get rid of that and what is this person's username okay so that was the one conflict it has been resolved so we will Mark you as resolved committing changes to patch three okay so now we wait to see if the bot updates

correctly so I have a question here um I'm noticing that these proposals are having each other as a required section they're having which sir uh required section like 233 and 233 4 required for 2335 and I think the similar case is with 233 as well so we have to make sure that all of them goes into same status every time we are moving will the bot allow the merge uh so 2335 requires four and three so as long as 2333 doesn't require either of the other two yeah we're good okay okay perfect so let's just uh so I'm just going to wait here

for a sec make sure the bot hey look at that it the bot updated yeah so um yeah so go here for

I guess we could link specifically to this okay maybe similar thing needs to be done with other to Sy yep yeah go and do

that next okay so same deal this goes here okay and 364

and 23 three back to here conf oh no that was incorrect what went wrong here okay

cool so those three are taken care of and if we can maybe quickly take a look at the other two proposals by Matt uh which ones are those um I have pinged the poll request number 8432 and 8266 3226 okay this is intended to encaps many request okay purpose frw contract TR request

execution the head body single field to start the request information the proliferation of smart contracts uh TR Behavior by allowing these systems to delicate okay specification header the 32 request request index okay the each may choose to extend X okay rationale okay Source search request should

be okay okay then same here CC Z all

right approved okay then we can move on to se serving history before proof of stake before the Marge over pewp okay okay block data before Paris over P2P

okay block GB block data from IP plant [Music] specification okay cool so that's easy enough um do we have any other quick ones we can do you think or yes uh there

is one a grammar correction PR number is 8315 all right is this a final EIP is it h no it's not it's draft so yeah yes they they just need to wait for the author to approve it or not yeah yeah so there is one last left in review perhaps we can quickly take that the number is 337 in ERC yes perfect okay so let's give this a look through so multi asset okay the following adapts multiple same

tokens new share method to allow your C20 depending see okay this en vaults which don't have a true share token but rather conver between two arbitrary external tokens it enforces 165 support fors missing use case that is not supported by La multiple assets okay apply multi Vault pipe okay share um share representation of the Vault share May return the to the Vault itself the share function returns an external token entry functions must increase okay it's not

revert cool point should not be here I see 20 tokens okay smart contracts SP interface okay should Vault method okay non compant

BS yeah that seems Seems great into review you go all right um we did great we did like uh 50% 27 was a big big ask so we did 50% great thank you so much S no it's my pleasure uh see you next week or in two weeks I guess two weeks have a good one you too bye