EIP Editing Office Hour #56 (EIP + ERC)

Transcript

[Music] Please hold on. [Music] Heat. Heat.

[Music] [Music] Hey. Hey. Hey.

[Music] [Music]

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

[Music] Oh yeah.

[Music] Uh, welcome to EIB editing office hour number 56. Uh we'll be going through a few uh author questions today and then going through uh some last call review and uh some other poll requests. So I guess without further ado, let's uh take a look at poll request 999 and I believe we have the author with us today. So you had some questions.

Correct. So uh we worked previously on uh another token standard known as keybound tokens that was ERC 68 and ERC 689 and we had a fungeible and nonf fungeible version of it. Uh and with this one right here we have something similar occurring where we'll have multiple versions or we have the ability to have multiple version uh versions uh of what we're calling ABT which is assetbound tokens. Um, regarding first the naming, do you think it's necessary for all these versions to include the nonfgeible part in the first tab or can we have something like in this example permalink uh ABT and then potentially have hybrid ABTs uh etc. Um, that's

entirely up to you. Um, we don't really have any rules about the naming. As long as you feel it's sufficiently unique to identify your standard, you can call it whatever you want. Okay. Marvelous. Uh and then uh my secondary question would be uh within the motivation because I think we had a um a similar thing uh when we were producing the uh keybound token standard um because as I said there's multiple versions um that have the possibility to be created uh with ABTS. Can I uh is it still right to have generalized information about ABTs as a whole within each documentation and then at the end of the motivation specify in this case what permal link uh ABTS do or

what they're targeting or would it be best to just have the the initial target for just permal links? So are you going to be doing one EIP per uh like style of token or are you going to be doing it all in one proposal? It'll be uh separate. They'll be individual. Okay. Yeah. Then it it'd be a good idea to to include like duplicate the motivation. Okay. Marvelous. Just so that each one stands on its own. Okay. Perfect. Cool. Anything else about this one that you wanted to know or uh No, that that was all. I know we have uh some more items to or some things to add uh within there, but we'll be adding that within the uh draft and hammering out the uh

specification and rationale uh moving forward and then going back and forth on it. Cool. Yeah. Um yes, I won't review this today um until you have at least some specification, but uh feel free to come back when you're ready. Okay. So, you would like us for us to add specification and at least like a sketch of what it's going to look like. Yeah, just enough to let us know that it's kind of like a legitimate standard and not just like a placeholder or an April Fool's joke. So, yeah. Okay. No, thank you. Appreciate it. Yeah. Um, anybody else here have uh any questions or can I just dive into the agenda today? All right.

Oh uh so Vinkumar asks uh hey I have an existing ERC that is on status review but has yet to be reviewed. Okay so um it is we the EIP editors only provide like um editorial kind of comments. We don't really do technical reviews. Um so it's on EIP authors to go out and get technical reviews. Um, if you need suggestions for where to look, uh, please post your EIP number and I can maybe give you some pointers there. But, um, yeah, it's really an author driven process. Uh, and then when you feel your proposal is done being reviewed and ready to advance, um, you

can open a poll request yourself to move it into last call. Does that kind of make sense? Yeah. Um because uh regarding that um um regarding the status it's pending as EIP code owner board that is yet to do the review. So I'm not I'm not too sure about the processes with that because we also did So you have a pull request open. Yeah. Uh I can share here in Yeah. Share the link. Yeah. Yeah. So, um, the bot only reviews, um, once an EIP editor has reviewed. Um, see, yeah, so here I I'll do this right

now. Um, but, uh, yeah, for future reference, um, there's a, um, cue here of all the PRs that need to be reviewed. Um, okay. I see. I see. Yeah. So it just it just takes me a while to get to everything. Um so purpose money stated interface 165 to implement purpose. Okay. So can I Okay. So, um, my first suggestion here is, um, your title is or your description is really just,

um, restating a lot of your title here. Um so uh I'll just search. Um, okay. So, Okay. So, smart contract interface

money5 standard to implement the purpose about money concept. purpose about money PBM wrapper and a digital money that wraps it digital money token store value money token refer to as a fee token should be okay Okay. voucher because

constraint payment to the redeemer is akin to a physical cash voucher where the payers respected purchases. Okay. Compatible smart contract. Okay. Um, is it a a purposebound money token or

tokens or uh it's a purposebound money token. So these tokens okay there. Yeah. So, Okay. I

just Okay. First of all, the technology lack interoperability uh by making the PBM specification open gives new participants free. Okay. Okay.

[Music] CC20 compatible digital currency. Okay. PBM C compliant smart contract which ref sub token by specify one or more conditions after met PBM business logic. Okay. Yep. Okay, the question redeemer is a product

defined as the ultimate recipient or end point for PDM tokens to which these tokens are intrinsically okay. PPM shell here to be in bounding. Okay. PBM shell here to the definition of unraive token. Okay.

Okay, that's more of a comment for your discussion thread. Hopefully that's back up. Where did that go? Wow. Ether is slow now. Um Okay. Okay, we'll just skip that for

now. Have the P tokens say burnt. Okay. PM token should have expired time. This is the PPM creator. The car components contain basic functionalities check. 50% of it could be spent in

supermarkets. Keep track of supermarket spendings by PPM users. Okay, cool. Okay. So, why is this an abstract

contract? This is an example of the the contract of uh how to use a PBN token. Yeah. So generally we prefer to put um an example implementation in the reference implementation section. Okay. Um and PVP must include compulsory state variable. So there is a requirement here that too this isn't just um an example. So,

Okay. Do you have an interface? Okay, you do have an interface. Yeah. Burn. Yeah. So, like my my suggestion here is if like this strct is mandatory like to be implemented. Oh, but you're saying some of them are optional here. Yeah. Okay. Yeah. So, um the normal way to encode that in like solidity would be to divide it into several different interfaces and then mark certain interfaces as optional. Um that's what E um 721 does with the metadata extension.

Um so I'd suggest something similar here. Um so we separate the interfaces for those. They are optional. Yeah, exactly. So, like for example, let's say um I don't know, let's say total supply and actually that's kind of a bad example. Um let's do token symbol and currency symbol. Like if those two are optional together, they go into one interface. Yeah. Okay. Um yeah. Uh so

okay must have had a method to retrieve. Okay. So you have an address list here. Okay. Token receiver. Okay. Okay. Front running. Yeah. Okay.

Yeah. So, really just try to cut this down to things that are like not general smart contract development considerations, but like specific to yours like you might have something I'm just going to guess here something unique uh in a in your proposal with unwrapping tokens or um you had mentioned up here that you don't necessarily need to wrap the solve token right away when the wrapper is created. So like those might have some unique security considerations for this proposal. That's what should go in this section. Um try don't keep it too general. Otherwise, everything else I think looks good. Um yeah, so there's your review for this one. Um I'll come back around to it uh after you've made

your changes. Thank you so much. Thank you. Thanks for coming. All right. Um Oh, really quick, Sam. A quick question just so I relay the correct information to my fellow authors working on that standards. So for the next meeting have the specification and potentially some additional things just filled out and then in that meeting that's where we'll be then moved to draft correct or yeah so I ideally it'll happen before the next meeting um just as as soon as somebody gets to it but if you come to this call it's kind of a back door to jump the queue. Um, I don't really recommend that people do that, but I won't stop you if you show up. All right. Gotcha. Okay, we'll get that

hammered out. Thank you. All right, let's take a look at some of these last call tokens. Decentralized employment standard. All right. Uh, [Music] Yeah. So it's been updated, but I don't think Okay.

Okay. So, nothing's changed on that one. Diffuse of token transferring tokens does not decrease token center balance means new tok. Okay. Fix native currency fees charged per token transference fee is paid by the sender to the contract owner.

Okay. Okay. Exactly.

I mean, that link seems to work for me. Oh, is it that it changed? Uh, that would make sense. I guess it has been updated. Weird. Yeah. So that one needs to be updated.

Okay. 34. So 10:15 update. So All

right. So now moving into draft skip jump test immediate argument check. All jump test bites become valid jump test. All right.

So, moving on to block level warming with fair cost savings. Okay. You've been assigned 7557. Do you still have 7557? You do. Okay. some fair distribution of the gas costs

associated with the access associated with access to addresses and storage slots along multiple transactions with shared items in their access list. Then 2929 introduces new gas that

differentiates between cold and warm access to accounts and storage. However, the cost of every cold access is born by each transaction separately. Even though the validator only needs to fetch the state object once for the entire block, when multiple transactions access the same object in the same block, the fees charged for these transactions do not accurately respect the computations that block builders and validators perform for the blockchain state. Yep. 2930 made it possible for transactions to prespecify and prepay for the accounts and storage slots that the transaction plans to access or the cost paid repeatedly rather than once the block level with the 6800 on the road map for cost is expected to increase

affected by this up transactions at most contracts with the high code size each transaction block will be forced to pay the full retail price. Okay, the validators only have to perform the actual reading from the Ethereum state once per block and subsequently to the values that were already referenced are significantly more efficient. If witnesses are introduced to Ethereum blocks, the same witness can be used by multiple transactions. Fair and inefficient. Another change construction. Uh restrict behavior transaction type.

All right. Restrict the outcome of their execution. All right. This proposal defines a transaction payload to defines the the progress.

[Music] Three network configuration for

DAPS 9312. I'll be right back. One second.

Sorry about that. I'm back. Um [Music]

[Music] All

right, I'm going to wrap that up here. Um, thanks everybody for coming out. Sorry it was a quiet call. Um, see you all in two weeks. [Music] Hold on.

[Music] Hey. Heat. Heat. [Music] Oh hey.

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

Oh you [Music] feel Heat. Heat. [Music] Hey,

hey hey. [Music] [Music]

Heat. Hey, Heat. [Music]