EIP Editing Office Hour #57 (EIP + ERC)

Transcript

Heat. Heat. [Music] Heat. Heat. N.

[Music] [Music] Hey hey [Music]

Oh [Music] hey. Hello. Heat. Heat. N. [Music] Heat. Heat.

[Music] Yeah, doing great. Welcome to EIP editing office hour meeting number 57. This is issue number 1440 at ethereum/pm GitHub repositories.

So users or developers who are joining us uh now they may notice this change that earlier we used to share the agenda on ETC herders EIP IP GitHub repository but now for the increased visibility we are having this agenda added to Ethereum/PM repository. So please feel free to drop your link in the chat for us or as a comment uh in the agenda. We are joined by Sam Wilson for reviewing these proposals today. And um welcome Sam. And you can perhaps start with the perhaps start with the items which

are added for final and last call reviews. Hey, sorry. All right. So, I guess uh we can uh jump into this. Um so, I took care of this one already. Um and we can Are we joined by any authors today? Yes, joined by Nick. Yeah. Uh so, it's 9 PR number 9 on ERC which seems to be close. Oh, no. Eight is closed.

All right, let's take a look at this. Cool. Good. So let's jump into this uh permanent asset bound token standard.

Um yep yep sorry I was on mute. Uh we added to the specification the the rationale um and then started diving a bit more uh into the other sections and and creating our keywords uh such as uh mirrored being terminology used. See, you haven't been assigned a number yet. So, that would be why this Yeah. Yeah. Correct. Okay. Um, so there is a llinter that hasn't run on this yet because it hasn't been assigned a number. That's my bad. Um, it will complain a lot about the stuff in here. So, um, just make sure to fix that before, uh, we try merging. Um, but I can give you at least a content review for now.

So, Um, okay. The student introduces tokens known as permanent asset bound tokens, permanent ABTs. Um the state introduces a subclass of tokens known as permanent assetbound tokens specific token concept ABTs establish no

ownership paradigm where an asset can own another asset and name K evolve together over time. These are irreversibly linked to a token of the contract. Okay, so there is another standard um that's vaguely like this. I just want to make sure you're aware of it. Um uh what's it called? Anyways, somewhere in here there is another standard that um is for tokens owning other tokens. I don't remember

what it's called. I will try to find it and I will link it to you um after this call. But for now, we will continue going. Uh yeah, much appreciated. So, um, let me just find a pen so I can write that down. And that's okay. Uh, permanent a permanent binding mechanism. Okay. One spell contract. Excuse me. Traditional token transfer proof functions

disabled. Okay. Um do you have any questions while I'm reviewing this or is it you just want to review? Um uh the one question just to clarify what you said previously. Um so with the number uh prior to having the number it'll be popping up uh that we'll have issues. Correct. Because right now we don't do the pull request isn't the ERC anymore. There's a new system in play. Uh yeah, so it will be here. It's just um this llinter here uh E validator.

Um it won't run until the file name has um Gotcha. Like a number. Yeah. So that's that's it. Um token and then also it might be used for uh for context when it comes to ABTs. Um I think I mentioned this last time but that's the category as a whole and there will be variations um of those ABTs. So as you'll see in the motivation we're going over the the general scope of where we can see ABTs be applied. Uh but there's uh different versions of ABTS whether it's going to be uh permalink or let's say sharded uh ABTs. There's

different types of ownership models but it's all uh pertaining uh assets owning asset models. Um it's just how far you can go and actually uh have them interact. Okay, that makes sense. Like they're different flavors of kind of the same thing. Yes. Yes. Exactly. In this case, it's permal link where it's a permanent uh bond between the two assets. Yeah. So, um

Okay. Real world asset ownership structures. And regarding uh EPI, which is the European blockchain services infrastructure, um would you also like me to put links in there and also like what they're working? Okay. So, just expand what it Okay, gotcha. Yeah. Um because like I Googled it, it didn't immediately come up unless I typed it wrong. So, it'd be nice just to get the full um Okay. Okay. Okay. So, this is kind of

inheriting the um behavior from ERC20, correct? Okay. And it's inheriting I would say primarily also for the backwards compatibility aspect where where most of the um the current infrastructure we see um is accustom to to using that. So it' pop up on say supported platforms such as uh openc and and and other yeah okay that makes sense.

Okay. Okay. Okay. So, how where's your reveal

function defined? Okay.

Apologies. My mic was on mute. Um, so in in regards to uh the reveal itself as um it may not be seen as necessary. I think that's what you're actually writing right there. in some cases um you'd recommend to remove it or just let's say briefly mentioning that there's a uh possibility of of having this cuz I think that's um at least when it comes to saving let's say and reducing fees that it's pretty useful and I see the reveal being utilized um quite a bit with already existing collections. Um, yeah. So, if you'd like, you can um mention it in your specification section as like an optional interface that you

can implement. Uh, kind of like ERC 72 721's metadata extension. Um, and then you can talk about it in the rationale. Uh, but like you really don't need to mention it at all. Uh, like this comment will kind of explain why, but generally the idea is minting and burning are admin functions generally speaking. Um, and the person who deploys the contract knows how to interact with a contract. So there doesn't need to be a general purpose interface for minting and burning or revealing because the person who again created the contract already knows how to do those things. Um, but if you expect it to be like a user thing like like if you know I can come and mint tokens and that's going to be a a

standard thing for anybody to do then it might make sense to include it in the specification section. Yeah, thank you for the explanation. Okay. Bounce off the binding tokens

contract. Um the asset that they're bound to require manual updates traceability visibility across countries. disableility. Okay. So, are the transfer functions always disabled or uh in in the case of permal link? Uh yes. uh genian abts uh because there's as I mentioned before there's there's different relationships um where let's say one NFT as another example can own uh like there be sharded multiple

ownerships uh for another version of it another version is where you can actually um let's say link them and then unlink them uh depending on how you want that relationship to function but in the case of permal link uh abts it would be uh in essence turned off okay yeah so that makes We're but we're mirroring those results um just so you can see the actual owner and the and the full supply. But all that information is essentially there and that enables us to have the reveal work the the way it does. Yes. So I guess what I'm what I'm asking is like your specification section doesn't mention a transfer function. Um so it it's kind of confusing to say that they're disabled

when they're really not specified. Does that kind of make sense? So it' be best within the specification section to say that these are present. However, um they're they're being mirrored or they are essentially uh disabled. Um I I think what you have is actually better where you where you don't have transfer functions. Um but instead of saying disabled, you just say that you you don't include them in the specification. It's effectively the same thing because like if you call a function that doesn't exist, it it reverts. Um well, it it stops but it has no effect. So, um you could just change it from disabled to not specified or um omitted from the the interface uh as opposed to

saying disabled. I think that'd be more clear. Yeah.

Okay. Yep. That's fine. Um, yeah. So, you can just delete this since it's a new standard. There's no backwards compatibility. That's fine. Uh, test cases, you can just delete this whole section because it's optional. Um, and then if you end up wanting test cases later, you can add the section back in. Um yeah, I'll keep this just because like um okay security considerations token if an individual

loses access to Yep. to get this risk. We strongly recommend the risk of standards like um uh a nonable. Okay. 689. Okay.

Good. And that's good. And then I'll give some non-editorial comments here. Um, and while I was uh or I'll finish first, I'm going to ask. Good. Um, there. All right.

You had the a question? Yes. So, um I know it's in review, but there was uh the one that you might have been speaking about was uh ERC6551 nonfgeable token bond accounts and I'm curious if that's the one you were referring to because So, this is one. Yeah, it's this is the exact one. Yeah, it is. It's similar, but this isn't the exact one I was thinking of. Yeah, there there is one specifically for like a token owning another token. Mhm.

Um yeah, but this one is is is pretty close. Um but it isn't permanent per permanent. So I can see why you wouldn't want to use this one. Yeah, I I'll take a look. Uh and do you think it's worth uh comparing potentially this one uh within the rationale as well because I can see um how we can describe how there are some similarities but there's also differences or would that be best for the uh other one if any? Uh so this so that is a good thing to do generally and uh it should go in your motivation section like because you're talking about why to choose one standard over another um where rationale is more for describing like uh why you made certain choices within the document. Um, but I

will warn you that if you mention um another ERC, uh, especially ones that aren't final, uh, you your ERC won't be able to progress past that ERC's, uh, status. So, for example, um, this one's in review. So, if you link to the standard, you won't be able to go past review until this one does. Um, so it's up to you. You're allowed to do that. It's just keep that in mind. Yeah, but thank you for that. No, no worries. Um, did you have anything else on this one? Uh, no. No, no, that was all. Okay, cool. I'll uh assign you a number as soon as I I can. I'm sorry about the wait. All right. And is there anything else uh that we should do uh for getting to the draft phase or can we continue

working on it within the uh draft phase moving forward? You can definitely continue working on it. Yeah. Okay. Marvelous. Oh, and I will also mention that uh moving between the statuses is author driven. So when you're you feel it's ready, you you open the poll request to move it into review and then you're responsible for finding people or or groups to review it and so on. That's all that's all on you. Okay, perfect. Thank you so much, Sam. Oh, no worries. My pleasure. And next we are joined by um Arthur who has two proposals, two PRs actually. One is 9631. It's added in miscellaneous. I guess it's an attempt to update the GitHub um

ID 9631. There we go. Yeah. All right. This is um interesting. We are joined by the author and uh he may not be able to talk but able to respond in chat if we have any question.

Sure. I'm just trying to figure out what the specific proof is here. Oh, this line here saying that it changed usernames. Yeah. Okay. So there is a redirect. Um yeah, these are always kind of difficult. I will um do this one offline.

um 9631 um and I will let you know about it. Uh yeah, and we have another proposal, another PR 9633 which is a draft proposal. Okay. 96 33 same kind of idea. Oh no, this is a different one. All right. Yeah. Cool. All right. Hey, I'm super down for something

like that. That would be very excited. Um, okay. Let's come up. So, descriptions are probably one of the hardest parts of VIPs. So, um, please don't be offended that I'm rewarding this. It's just uh you want to kind of expand on the ideas that are introduced in your title and not uh just restate the title. And then all of this stuff here, this EIP as a standardized way to support is kind of just fluff. you only get 144 characters in your description. So, it's it's really useful to be super concise. Uh, so let's see.

Um, okay. And rapid type transaction sign. Okay. And

Okay. Quantum computers are getting more advanced when new postquantum algorithms have been designed. Uh these algorithms architect drawbacks large key size verification types decisions make them more expensive to compute store in the current curve in use. Okay, this could be preser future proof. Okay, so Okay. Resolution to the safest way to

represent alternative algorithms within a transaction. Okay. Um so you say by 07 gas per additional by 16 a new 2017 transaction uh with a transaction type of bet. The type is an unsigned 8 bit integer that represents the you send the transaction the parent field. This IP does not define algorithms for the transaction type. Um okay.

The signature field contains information required to verify the secret transaction. The parent field. This is a better arbitrage which would then be passed to the verification function. The parent field contains another E278 type transaction envelope. Well, must be able to contain every supposed to be. Is this supposed to be which instead of while? Seems like it might be uh must be to contain every possible transaction type including legacy transaction with transaction type. The only but the only exception is the algorithmic transaction itself which must not be placed within itself. Okay.

All these transactions contain y par r and s value which must be set to by zero. Uh if wrapped in a alg. Okay. Okay. Um so okay.

Um yeah. Okay. So All

right. Good. If you transition the transaction must not generate a transaction receive the transaction must generate transaction receive the transaction is wrapping. Okay. Further each type algorith maximum size signature for field transaction verification signature.

Okay. So, this is um Okay. Um, All right.

What was the abbreviation used? PQ Okay. Um, so we're going to skip

Oh, that's interesting. Does that work? Uh setting three, four, five two three.

Um yeah. Uh, give me one second. I'll be right back. Nick, I see your hands raised. Uh curious, is it related to the PR that was just reviewed?

I It was the previous one. I I had a question uh for Sam just regarding uh numbering, but I'll wait until he's done with this one and I'll find a good moment to jump in. I'm in no rush. Sure. Thank you. Yep. Of course. Sorry about that. I'm back. Uh did you have a question, Nick? Uh yes. Uh really quick, uh in regards to the numbering since I know it's changed, um and with ABTS being the big category and we're going to have assets

underneath there, is there a way or is there the opportunity to have the uh numbers similar? Uh so for example, in the past what we did with uh ERC 688 and ERC 689, we made the polar coast at the same time. Uh at this point in time, we're not doing that with the other uh variations. Um, but it would be nice if they were somewhat similar. Is that possible now with the numbering system or Not really. It's just they're just going to be assigned in order from like that that the poll requests are created.

Okay. Gotcha. Gotcha. Yeah. Well, thank you very much. That was my work. Appreciate it. Have a nice day and thank you once more. Oh, you too. Thanks for coming everybody here. Akash Uja Sam, have a good one. Till next time. and consider transactions invalid where lenx signature info is greater than al maxis function defined below. Okay, good.

transactions pedal must be. Yep. Good, good, good. All

right. Cool. Yeah, this looks great. Um just a few small things and then again waiting for me to assign a number before the bot will run. So um that'll happen hopefully today. Uh all right so uh are we moving on to 7837 here? Uh so we are joined by Mercy who has some question for PR 930 of ERC. That's right. 9 Okay. Okay.

So has this been February 25th? I think yesterday. Perfect. Okay, good. So let's give this a look. Uh emerging of NFTs. Hierarchical NFTs emerging. Okay. Uh this

introduc 6150. This introduces structure parent child relationship between NFTs allow an NFT to be fractionally split into multiple child entities merge back into a single entity. Provides interfaces to retrieve an NFT's parent um children and hierarchal size flexible account management. The standard is particularly useful for applications in fractional ownership. Cool. Yeah, that's reasonable. Um merging capabilities allowing assets to be dynamically restructured. This proposes refresh auto ship where assets using split merged. Okay. So splitting one of the key limitations of 6150 is its rigid hierarchy. Let's 6150 modular file system like hierarchal

keys. [Music] Um interesting. Okay. Split into smaller independent units. Okay. Okay. So, this is kind of like instead of it treating like files, they're more like well it yeah I think I'm kind of getting the idea here. Um this question of a stock later on a full share. Okay.

this uh uh fashion structures. Okay. Yeah, I think the motivation does a pretty good job of justifying the proposal. Um so Okay. NFT M child NFT mint marriage

chair bash optional extensions burnable. Okay. So I will go and make a comment on here. Good. And then um um transfer share ownership from one NFT

to another. Okay. Under the same parent, optional extensions burnable. You might want to make this a header. Um, yeah, I'll keep that like that. Okay. Okay, make your back compatible. Let's

provide a blow. Okay. All right, cool. Um, yeah, that's it for this one. When you fix these, um, we'll get back around to it and review it. Um, um, I'm not sure. Mercy, do you have any further question? I I thought you mentioned that you had some something to ask. I wanted I wanted to ask a question cuz at I want to know if um like what is really expected for an ERC to be finally merged

like um if I have an ERC for example and then how do I get a community to like start using it or start making implementation like I understand the EIP aspect but I don't really get the ERC what I'm saying you can't um you can't force people to to implement stuff. Um that's why a lot of ERC's kind of just die because even though they might be a good idea, they don't have like a company behind them that's pushing for it.

Um but like I guess the idea would be like you'd reach out to interested parties like for anything NFT related. Um the OpenC Discord is a good resource. There's a lot of active developers on there. Um, there's also an NFT working group that has like members from different uh community organizations in there and uh you can mention it there, but really it's like the only ERC's that are going to get adopted are the ones that um have some kind of commercial push behind them. Um, as unfortunate as that is.

Okay. like how what makes you now to decide that okay this ERC is ready to be implemented like the final review and then it gets out there like what's the concept that's up to the authors okay yeah when they decide it's ready they can move it to final okay thank you yeah that's why yeah no worries that's why there's like um like a a good example here is um uh So, soulbound tokens, there's like two three four five um, different types of definitions for soulbound tokens. Um, and like I don't

think anybody has settled on which one is the correct soulbound token. Um, yeah. So, until somebody does, they're all just going to be here. Okay. Yeah. Thank you. Oh, no worries. Yeah, I don't know if we have much time here. Uh, but whenever you get a chance, maybe you can take a look at the last call proposals. And I believe there is one uh requested by EF team. Uh they wanted this proposal to be moved to review. So yeah, you can I I can't move this one to review. I'm an author on it.

Okay, no worries. Um, I think uh one good news that I was planning to share it with the community is Oh, wait. I'm an author on this. I can approve it. Well, you are not good. Yeah. I thought I thought it needed an editor approval. It needs an author approval, which I can do there. Okay. Hopefully that will get merged now. It should. Yeah. Okay. Yeah. And uh I wanted to share it with the community that earlier we used to have just two office hour in a month like once in two weeks then we started having one more with EIP focused only

and I'm very happy to share that now we will have editing office hour every week. The alternate week will be for EIP plus ERC and same goes for EIPs only. So now we have more opportunities to get the proposal reviewed and ask your questions with different editors. Uh we are supported by Sam Wilson of course and also Gajender Singh and Mankind. So people if you are listening to this please feel free to add your pull request which you think is not being pushed or is being stopped for any reason. If you have any question this is the best place to ask your questions and get them answered.

And yeah, I think this is merged now with that. I think that's pretty much uh time we have got for today. Thank you so much Sam for reviewing all of these. And yeah, whenever you get a chance, you can perhaps take a look at them async as well. Otherwise, they will be carried over to the next editing office hour. Thank you. Thanks so much. Thanks. Have a great rest of the day. [Music] Hold

[Music] on. Hold on. Heat. [Music] Heat. Heat. Heat. N.

[Music] Perfect.

[Music] [Music]

move [Music] on. Heat. [Music] Heat. Heat. Heat. N. [Music] Heat. Heat.

[Music] Heat. Heat.

[Music] [Music] Oh,

[Music] hey. [Music] Something will [Music] Heat.

Heat. Oops. [Music]