EIP Editing Office Hour #59 (EIP + ERC)

Transcript

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

[Music] Oh, [Music] [Music]

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

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

Oh. Oh. [Music] [Music]

Recording in progress. Welcome to EIP editing office hour meeting 59. This is issue number 1481 on Ethereum/PM report. This meeting is for EIP plus ERC related pull requests. On agenda, we have added a bunch of uh last call proposals, some review and a lot of draft proposals. So, without further ado, let me invite Sam Wilson to share his screen and uh we can start from the last call proposals. Sam, thank you for joining us here today. No, no problem.

Is my um screen share working or no? It is. Okay, perfect. All right, so let's jump right into this. Um 1010. Um okay token tokens on transfer charges per token interfer forces the cap supply. All right. So we will take a look at their discussion thread. All right, nothing new on there. Um,

okay. The CRC purposes stander for a new type of funible token called diffusive tokens give tokens to decrease the senders balance administ tokens directly to the recipient increasing the total supply of every transfer action. A fixed native currency fee is charged per token transferred and this fee is paid by the percentage to the contract owner. The supply growth is limited by max supply set by the owner. Cool maint balance on transfers. Okay. Okay.

All right. Yeah. I mean, I have no complaints with this. It is a token standard. Well, all right. 1005. Oh, sure. Let's do some of these uh ones that we have authors here for. So, let's look at 993. Uh for setting multiple type messages do Merkel tree. Okay, cool. Um and then we have a Okay. Hey, look. Spam. Yeah. I don't I

just don't know what that is. Um saw it on the PR. Yeah, people love just spamming for some reason. I don't even know why. I don't know what to get out of it. Um, okay. So, air drops. Yeah, I guess so. Um, thanks for the review, by the way. Oh, no worries. Yeah. Uh, if you have any specific questions or whatever, just just ask while I'm while I'm looking at this.

Okay, good. All right. This CC provides a data for sending multiple typed messages with the same signature by encoding them into a Merkel tree to independently verify messages without requiring full knowledge of the others. Okay, good. Uh gives a flexibility to verify messages in isolation or an aggregate. This opens up. Yeah, that's good. That's really good abstract. Um as the ecosystem moved towards eless transactions, users are often required to sign multiple chain messages in quick succession to first signatures needed for precise spending allowance followed by subsequent messages. Okay, so 2612. Okay, you're final. That's good.

[Music] Pre-approving. Okay. Yeah. The composite signature uses miracle tree to hash multiple tip data messages together under a single route. The user sends only the miracle route. The process is described below. For a set of messages and Cody choosing 712's encode and computes hash. Okay. And then you depend on 712. Good. These messages message hashes leave nodes in a Merkel tree and computer Merkel route. Sign the Merkel route. Okay. To verify that an individual message MX is included on the composite signature, verify the miracle route. Yep. Compute the leaf node for message MX and

verify it's path to the miracle group using the proof. Verify miracle proof. Okay. Okay. Super blow

verifies. Okay. [Music] So, okay. Specification of the E sign type V5. Uh the CC method to the Yeah, I know. I didn't know what to call it.

Yeah. Yeah. Um multiple type data message signal signature using the specification drive descript above the signing account must be prior unlocked. The message return signature mark in approved these corresponding to an input message. Okay. returns. Okay.

Okay. Um and

okay. Okay. Okay. So, Okay.

Um, good. Do you talk about what type of hash function you're supposed to use or is that just not um specified for this? Oh, it's at the bottom. Uh, wait. Where at the Yeah, yeah, I guess you say K 256. Okay. Or K. Okay.

having trouble with that, but I don't remember what the error was. I'll try again and then I'll I'll let you know. Thanks. Mark down the lintter was upset about it. Yeah, you have to use a relative link. Um, so it'll be something like that. Sure. Okay. Good.

Messages. So, Victor recommended showing up at most 10. Um, I felt it was pretty reasonable, so I kind of stuck with it. Oh, it's more of like a recommendation, not really a card thing. Yeah, it's just like a UI kind of thing. That makes sense. Um, system must be 256 miss the number of messages. Okay.

So if they didn't do that, I don't know if it would change the um the viability of it. It would just kind of it's just kind of a nice to have. But I do Okay. So if Yes. So, if one wallet didn't pad, but the contract expected it to be padded, it would still be compatible. Um, the contracts don't expect it to be padded currently. Um, they'll handle any length. It's just like the consistency is kind of I thought was Yeah. As long as like two Okay, so if you like ignore the security consideration section uh and only follow the specification section as long as two implementations can still talk to each other, that's fine to keep it in the security consideration

section. But if they if if they would become incompatible, then it should be in the specification section. tree reference implementation. Yeah. So, Sorry that

backwards. Uh, okay. Good. You have your copyright. Perfect. Get ignore is fine. Good. Um, I can make that happen. Yeah, thank you. Um, hard hat config. Okay. Oh. Uh, give me one second. I'll I'll be right back. Sorry.

Just a second. Sorry about that. Okay. Scient data.ts. Okay. Merco. That's good. Some

tests. Great. Yeah. Yeah. Overall, great uh great proposal. It sounds useful. Um yeah. Uh, so just in case you aren't aware, um, moving through the statuses is, uh, on the authors. So whenever you feel it's ready to move to review, last call, and final, uh, you can open those poll requests. Got it. Got it. Uh, so this would be, so it would merge as draft first and then I'd make a pull request for subsequent to move. Exactly. Got it.

Thanks a lot, Sam. I'll make these changes and then I'll get back to you probably a week from today. Yeah, no worries. Thank you. All right, so 886, let's go and take a look at that. All right cool. on that on that last point, Sam. Um, first of all, thank you for reviewing it. The the there's two points I'd left open. Um, so there's one about the it doesn't talk about code snippet there.

So, we're talking about real life will. So, there is no code snippet. I didn't know. Oh, I assumed it was a code because it was capitalized. Um, yeah, it's one of those do you capitalize it or do you don't capitalize it? Maybe that that's fine. Yeah. And then and then the last one I wasn't sure whether cuz it's is it good practice to add in um ERC 165 and add in the actual function for the um the identifiers cuz what I did I went I went to one of the calculators and added it in. There is a snippet of code I saw in um EIP1363 and sort of thought maybe I should do it that way. Um but it's not in the interface. It's more of a comment that's in the code. I can I can Yeah. Uh, all you really need to do for that one is

just say um like contracts must implement support interface from ERC165 and and in the actual interface itself, do I add because there's a comment section um in IRC um the the sort of 1363 and I copied it. It does it that way. Do I just add that or do I just just add some wording? however you want to do it as long as like my complaint is that people won't see 165 in the requires header. Um so it's best to just mention it somewhere in the specification section. However you want to do that is fine.

Oh, all right. Fine. Um thank you. Uh that was really it. Those were my only questions. So I can check them in. I've I've removed the make file like you suggested. We were trying to be nice and sort of make it easy for somebody to actually run it. So the the make file has been removed and the hard hat files as well. I've noticed that in the test case section I still refer to them. So it's do I remove that section because it feels like that section now won't run that you can't run the make command anymore. There is no make file. So do you want me to Oh yeah. Yeah. Exact. I I can probably do that for you here. Um so let's go through this quickly.

andable contracts for contracts inheritance tokens after the owner's death. Um, so I think we can go Okay.

Um the CP interface for cont set up a will and designate executives to enable the transfer tokens to inherit after specified waiting period as way the CP standard interface forable tokens. Perfect. Yeah, good. Um, I mean, Okay. Be critical

token. Okay. Okay. So, now let's just cancel out. Oh, okay. Yeah, that's good.

Link [Music] that. And then all of these are probably good. Yeah, that looks great. And then we can go here and here.

There we go. Um, so like I said earlier, whenever you're ready to move it into review, you can open a pull request and uh move it into review. Okay, I'll do that today, tomorrow. Thank you very much. Thank you. Oh, no worries. Um, whenever you're like, so kind of I I guess the uh the things you need to have done before moving into review are more like um you don't expect there to be any further changes and you're going to go out and solicit feedback from anybody who'd be interested in using this. That's kind of the idea behind what failed here. Um, yeah, it doesn't matter. Um, behind the review status.

So, is it is this the Ethereum magicians style thing? Uh, kind of. So, so like um it's a very author driven process for for better or worse. So, um once you're satisfied that you're mostly done, you move it into review and then it's up to you to find people to review it. Um those people can be zero people if you want, but we definitely recommend getting at least the people you expect to implement the standard to look it over. Um and then once you're satisfied that all of that's done, you can move it into last call. Okay. It feels like we're marking our own homework as sort of part of scans we are sort of implementing it and we've already sort of done that so to speak in terms of

that that code is more or less live or a slight variation. We pulled it into our contract. Yeah. So then you're probably good to go. Um like do do you expect other companies or or other maybe wallets directly to implement this kind of a standard or um ideally yeah ideally yes because we kind of we we grappled with this problem is that we want to sort of do real estate and we want people to hold these contracts for a long time and the question of death which is a sad sort of conversation to have but it came up and then we we came up with a solution. And we thought actually if we make it open to the world, we hope it will get adopted. We we we we're certainly using it. Um but if it becomes a standard, it's kind of like a favor

that we give back and and if it gets adopted, fantastic. If it doesn't, we don't lose anything. So it's it's kind of we don't need to bang the drum, but ideally it is worth probably advertising it a bit more and making other people sort of be aware of it and try and use it. That makes sense. So this is kind of like um you've already built this product and this is your like documentation for it almost. Yeah, this is this was the solution that we found and it works for us and we went let's just give it back to the community and be nice. Yeah, perfect. I appreciate it. Okay, thank you. Take care.

Am I okay to drop off for this meeting? Yeah, thanks for coming. Oh no, it's 4337. We have one of the co-authors here. So any questions we would try to solve it because many proposals are being stuck this if this proposal doesn't move forward. Yep. Yeah. Any construction. Okay. How many characters is this? This still

feels a bit long. Um, oh no, it's fine. Yeah, I might just be being a little bit too nitpicky here. Anyways, [Music] um, okay. Draft review account which completely avoids any for consensus layer protocol features change to the bottom layer of transaction type. This proposed instead introduces a high layer pseudo transaction object user operation users send user operation objects into a separate mepool special class vector called bundlers package of these objects

into a transaction making a handle ops call to a special contract and then that transaction gets included in the block. Great. Um, okay. Uh, the next for work motivation and 2938 for consensus protocol implementing the same goal.

2938 is in stagnant. [Music] Um, so yeah. Okay.

What do you mean by link to the logo? Uh yeah. So um you can't link to a proposal that's less advanced than your own proposal. So like you're moving into review. So that means you can only link to review last call and final proposals. Uh 2938 is instagnant. So you either need to delete this link or um ask the authors of 2938 of which I am one uh to move it to withdrawn. So, um I will do that later today. Um and uh it shouldn't be a problem for you, but uh yeah, actually I can just I can do that right now.

Um we Okay. Okay. Achieve the key goal of counter extraction. Allow users to use smart contract accounts contain arbitrary verification. Consider EOS primary account. Completely remove any need at all for users to also have EOS as required as required. Yep. Allow any bundler think block builders to participate in the process of building include. Yep. Work with all. Okay.

Okay. Avoid trusted sellers do not require any Ethereum consensus changes. Okay. part 7702 PTX fees with the IC20 tokens sponsor trans good so user operation is instruction descriptive transaction be on behalf of users not named trans yeah yeah that makes sense transaction it contains two called signature Um,

Okay. We show the full list in his operation. Actually, the contract received a packed version which is also mentioned later. Okay. Okay. Yeah, I guess that that's fine to keep. Uh not the signature field usage defined by the protocol, but yep. Uh sender entry point must be weight list supported entry point. So that is definitely a um 48 48 Um bundler node block builder that can

handle user operations create a value can block still valid. This can be achieved by a number of ways. Yeah, same 54 54. Okay, then 7732. Yeah.

[Music] So 55 55 um 70 [Music] Okay. P master. What is a general suggestion? We want to reference them

not as a requirement but as a prior art or things. So we should remove the references specify them without a link. Uh yeah. So there are like there are kind of two options here. Um one of them is removing it which I recommend against. It's good to have additional context. Yeah. Um yeah. So um too um are there any to-dos left in this or can it be moved for review? We want to have this reference I Yeah. No, it's not. You should um

stagnant. Yeah, I'm I'm asking um Matt and Onscar if we can just withdraw 2938. That way you can use it. Um that would be easier. Uh so let's take a look at withdrawn are allowed to reference. Uh withdrawn you can reference them. Yeah. Okay. Um, yeah. I mean, my recommendation for 7732 would be to just open a poll request, moving it to review, and uh hopefully the authors agree with you.

Um, it looks like it's done. I don't know why it's still a draft. Um, or not done, but it looks like it's completely written. Um 7796. Yeah, same thing here. Um thanks Okay. Okay. I have a contract that pay

for the transaction center itself. I have a contract that provides. Okay. Also known as an authorizer contract or contract that enables multiple user operations to share a single validation fully defined in ERC 7766. Um I'm going to guess that that's also a draft. Yep. So, I'm going to stop mentioning these um Okay. 7796. I have a contract that pay

for the transactions or the contract itself. Sorry. Decentralized permission permissionless P2P network user operations deposited amount of ether any point contract pay. Okay. Um I have a small question here just to trying to understand it better. So I noticed that all these new EIPs are mentioned under the section of definition. Do we really need to mention the EIP? I mean we can simply just define that that is an option with art. We don't

want to remove the references because it's relevant. Yes. The easy way is to clean them out but don't want to maintain them. Yeah. Because I feel like uh not only the EIP those are mentioned here can be a blocker but also the P EIP those could be required section on these EIPs can be another blocker. In that way we would never be able to go past the draft status unless all the EIPs whether mentioned in uh the proposal or part of requires of these mentioned proposals are in draft or any other status. Actually some of these are

general reference but 7562 is our document and it is in draft and we wanted to make the core 4467 uh final but we do want to mention that you do need those rules in order to be used. So I'm not sure about the wording. How can we do it? We're not allowed to reference the fact that you need validation rules. Well, you you can say you need validation rules without specifying what the validation rules are. Um or you can just move them both to final at the same time.

the the the problem being like if 4337 went to final but the validation rules weren't then you can't implement 4337 because it's talking about something that isn't finished being written yet will take a very long time until we will be able to finalize it because okay even if we okay we can oify version of 7562 we have today but it is updated with new up codes added to the protocol for example. So uh okay so yeah yeah it is since define rules we a bit more

reluctant to oify it because 437 define an interface interface to account and to the end point. So yeah that can be oified pretty easily. Yeah, the valable can be alsified with the current version once there is a change in the in in the EVM it will be opened again or we can the number and then we can't change for 37 to the new validation rules. Yeah. So I we have this problem with quite a few types of EIPs. Um another one being like the hardware requirement EIPs that people like to publish. Um, kind of the solution we're going with right now is

to link from the hard fork meta into the version that belongs with that hard fork. So like in the Fusaka metaip, you would link to the 4337 validation rules for Fusaka. Um, that might work. Um, you'd have to talk to Tim about that, but that's probably what I'd recommend. But ERC 437 is an ERC. Yes. EIP there is no hard fork that depends on 437. It's no it would just be like a it would just be like a this is the ERC for 4337 that goes with Fusaka. It wouldn't be like a

dependency. It' just be like an informative link. I doubt that is possible because in meta we only mentioned core EIP and I think this time we have also mentioned networking EIP but just to say that it it can be going in yeah I who is looking at a metaip these are the core devs but true valation rules are checked by the bundlers they are not looking at core IPs because they don't care about What are the thoughts? This is what are the thoughts on having meta ERC's like do you think that could be a

solution in which we can start adding these things? Uh yeah, I mean we could definitely look into that. Um there I don't know of any other EI ERC's that need to be released every hard fork though. I'm sure there are. I just can't think of any right now. What you're saying basically we need to in 437 say that search for the latest meta for 437 and then you will find the validation rules that apply because we are not allowed to reference them from 437 itself right exactly like 4337 needs to end at some point it can't just keep

getting updated over and over again. Yeah, forcement ends but 762 isn't ended yet. So instead of referencing it, we will say okay, go find yourself and find the latest validation rules. Search for an ERC with the title. Yeah, I know. I know. And use the latest one. Yeah. And that's kind of why I'm saying it'd be nice to index these all in one place as opposed to having to search. Um, but this is kind of a discussion that we can hopefully do offline. I'll add it to my long list of discussions. Um, um, one other note here, Sam. Uh, I'm

noticing that all the file links are going at 404. Are we missing something there? All the witch links like inside this file. Yes. Yeah, that's just how our rendering system works for now. Okay. Yeah, it's it's fixed in the new one that I'm working on. Um Okay. Uh [Music] 6464.

Okay. And for replay attacks senior must plan on chain ID and entry point address that one since your authorization t value can be provided alongside the operation strct but authorization tpples are not okay change to the end point contract the account and the pay master packed version of the truck packed operation is used. Okay. Beneficiary address that we paid without all the gas fees. Okay. Smart contract.

Death. Okay. Smart contract. Sequential transaction nons values uses replay protection method as the valid order transaction. It also contributes the transaction hack uniqueness as a transaction by the same sender with the same nons may not be included in the chain twice. However, regarding using operation between two values key sequence.

Okay. Okay. Inter method is hand. So your operation is the entry point must perform the following set must make two loops verification with the execution loop and the verification with the handop must perform the following set your operation. Create the sender smoke yet exist using code provided in the factory addresses. Okay.

Um the sender does not exist in the unit contract the sender call must fail the max possible fee the sender needs to pay based on validation and gas columns current gas fees calcation signature and pay the fees. Okay. Line 237. Now they're all just the same line.

You've only changed one line. Okay. 237 the enterprise I have to cover the

max possible post the execution of the usual operation call. Okay, it's up to the account to choose how to parse the call data and express the account to have an execute function that pars with the method. The entry point must build the call later by code and call the account the call from pre-charge penalty of 10% is applied on the amount guess the amount of information is equal to carry. This penalty is necessary to prevent the user operations from observing large parts of the gas space in the bundle but leaving it unused to preventing the bundle from including other user operations after the execution of outcomes.

Okay. And before accepting should use an RPC method to locally call handle ops function on the entry point. KJ put that full definition. Okay. support for E.

Okay, it's fine. Put the extra parameter. Okay, wait. 7769. [Music] Yeah. Yeah. I just wanted to um make sure that this section existed. Um and it does. So that's good. Um no, the point is that we splitted 437 into three separate ERC's so that we can oify 437, but we can't. Right. Yeah. You have to link them in the other direction from the more draft proposal to the

final proposal. Yes. But the the logical link is from the main main one to the partial to the less important one. This is the main ERC. what you're saying that we can't reference those like create extension. I mean I guess another option would be to um make 4337 just the contract interfaces um and then have like the RPC the rules all those things and then have uh either a meta or anformational EIP that like

links everything together at the end. Um but uh yeah the one like you can't finalize a proposal until all of the like components of that proposal are also finalized. Yeah. Okay. Pay deposit. Okay. Okay.

Okay good. 583 583. Okay. Did you put contract?

Yes. So what what we can do copy the GitHub repo basically. Yeah. If you can just cut it down to like kind of like imagine if you were reading a textbook and you had like a like an example implementation in the textbook, that's what you want to include in the repository. So you want to avoid like build system files, lock files. You just want like the minimum amount of stuff to give the reader an understanding of how to implement the standard. Yeah, that's that's an important one. Um

yeah. Um cool. Um and with that I have to go. I have another call. So, thank you everybody for coming out. Sorry I couldn't get through more proposals. We'll see you all either next week or in two weeks. Take care. Thank you, Sam. [Music] Hey hey

hey. [Music] Heat. Heat. [Music] Hey,

hey hey. [Music]