EIP Editing Office Hour #52 (EIP + ERC)

EIP Editing Office Hours · 18 Feb 2025 · 1:00:00

Meeting 52 of the EIP Editing Office Hour, held on 18 February 2025 and covering both EIPs and ERCs. EIP editors and proposal authors work through open pull requests and questions about the Ethereum standards process. This meeting covers pull requests heading to Final, Last Call, Review and Draft, mostly for ERCs.

Topics

From EIP Editing Office Hours, hosted by ECH Institute.

Transcript

[Music] oh [Music] oh

[Music] a [Music] [Music] the editing office our meeting 52 this

is issue number 380 on eat cat herders EIP IP GitHub repository on agenda today we have a bunch of uh open PLL request I think we have a few on Final and last call waiting status couple of more for reviews then miscellaneous followed by a bunch of new proposals to be added as draft on eips and erc's sign so um I would like to welcome Sam Wilson thank you Sam for joining us here today Sam is the editor who is going to make the review for the call and the participants of the call please drop any questions at point of time you may have either with respect to the proposal that is being

reviewed or in general about the processes so passing it on to you Sam sure so uh Hey everybody Welcome um let's jump into 7818 all right so this is moving into final so we want to make sure that there's no additional discussion that's going on here so last conversation was in January December rather yeah Okay cool so nothing new let's give this a read through so introduce an extension for

your C20 tokens I the okay uh which facilitates the implementation of an experation mechanism through this extension tokens of predefined validity period after which they become invalid and can no longer be transferred or used this functionality proves beneficial in scenario such as time to bonds Loyalty Rewards or game token automatic inv validation after specific duration the ex is crafted to seamlessly align with the ac20 standard great okay so why do we want this uh this extension facilitates the development of vc20 standard compatible tokens featuring expir dates potential applications yep those are all good use cases perfect okay so we have an Epoch so

Epoch represent a specific period of block range which tokens you're value they can be categorized into two types yep okay use B tokra from the current Epoch against past Epoch which can only be an epoch's back past Epoch can be set to any value and allog flexibility and tracking some tokens to valid up to n okay the useful Balan is the sum of tokens between the current Epoch and the past Epoch ensure that only non-expired tokens are considered okay so you create that so usable balance is 350 yeah okay okay compation

must following okay so this is looking pretty decent okay so balance must return the total balance of tokens by the account that out any Associated remain within the duration exp tokens must not be included in the return balance and that only actively useable tokens are reflect in the result all right balance of at eoch M return that's a typo there can

I we go so we're going to go down to balance that must return the balance of tokens help by an account at the specified Epoch if a specified Epoch is expired this function must return zero that's an interesting choice for example if Epoch 5 is expired calling balance of epoch address address returns zero even if there were text held that Epoch current Epoch must return the current Epoch of the contract Epoch length must return the duration between Epoch and blocks or time in

seconds EPO type blocks based or time based validity duration must return the validity duration of tokens in term of epoch counts is EPO expired must return TR the epoch is expired okay transfer transfer fund must exclusively transfer tokens that remain not expired at the time transaction turn false additionally implementations May L prioritize the automatic transfer to tokens closest to expiration ens show that the earliest expiring tokens are used first provided they be transfer at Epoch and transfer from Epoch must transfer the specified number of tokens have by an account at the specified Epoch to the recipient if the epoch has expired the transa yeah must revert or return false total Supply should be set

to zero or tracking only valid or no okay cool additional potential use of functions these optional functions provide additional functionality be useful depending on specifi use case get e balance returns tokens wait are these not H get Epoch info returns both the start and end the specified Epoch okay I guess this is okay it's not great because they're not like fully specified in a interface but somebody else can come along and write a standard for that if they want

so I love the term Epoch implementations can support menu for greater control over when tokens are valid or expired on chain can support F expiration World tokens within the same Epoch expire simultaneously this flexibility [Music] enables yeah that's good it's backwards compatible the reference implementation can be found here but in the reference implementation we apply sort of list this yep good y it seems fine so we'll fix this typo and then we will approve it

all right so then next we have got a interface proposal moving into the last call all right let's go take a look at that um I have a few background with respect to not this particular proposal but in general interface related proposal in yesterday's RPC meeting people were wondering like what would be the best place to talk about about interface related proposal or the spec changes that they would want to bring to RPC methods um I understand that wallet Dem meeting is is happening there where people are discussing a specification which may be affecting wallet or in

general RPC methods what would be your suggestion around that like where they should find more discussion sure so if you're looking for um just discussion all wallet devs is probably the place to be that's all wallet. is our website you can find a Discord invite there um if you're actually looking for somewhere to document the changes like you want to write a proposal uh they would most likely belong in the ERC um repository um and I I'll H be happy to approve those um but the Like official place where we document these things is the execution apis repository and that's kind of like a Json RPC

um dou umentation website and that would probably be the the ultimate place to get things uh documented um yeah so hopefully that answers your question and we can go into this yes I may have a follow up on that like I understand the present e simulate or multi call they do not work with any kind of EIP they are generally making specs changes directly but in case there is an interest general interest of having this specs speci ified in form of um a proposal I suppose um as you suggested going to ERC get a repository would be a good idea but um how how can we collect

more engagement like if there are people to um maybe actually implement it um this wallet Dev calls could you maybe talk about more about the frequency and how they can join of course so uh we run a monthly call I think it's on every third Wednesday uh of the month um here is our you know website uh the next call is uh tomorrow at 1M um yeah feel free to come out this is probably the easiest place to get in touch with um a lot of wallet developers um the server is kind of quiet but uh every pretty much every wallet is represented here if you want to ask any

questions or talk to anybody or or or push uh a particular proposal uh yeah come come to our our Discord server come to our calls um we'll be happy to talk about your proposal thank you Sam all right so let's jump into uh moving this to last call all right so let's pull up E1 so last call comes after status last call deadline and then two

weeks from today is March 4th 25304 okay so let's give this a nice read add block hash to default block methods so add block hash option to Json RPC methods that currently support a default block parameter great description uh for Json RPC methods which currently accepted default block parameter additionally allow the parameter to be a block hash the CIP can be considered a generalization of e234 it would enable clients ambigous specify the block they want to query for

certain Json RPC methods even if the block is not in the canonical chain this allows blocks to maintain a coherent picture of the blockchains clients maintain even in the presence of reorgs without requiring that the known maintain a persistent connection with the client or story any client specific State all right so the following Jason RPC methods are affected okay the following options quoted from the Json RPC spec are currently impossible for the default block parameter earliest latest pending safe and finalized all right there's no way to clearly just work between a data parameter and a quantity parameter this e a scheme for the block parameter the following option is addition allowed so the block is not found it should raise JPC error y if the tag is

block Falls good hex spring using new block parameter scheme in other words the following equivalent for the default block parameter so earliest uh all right yeah it's good rationale some test cases this looks good so I'm going to approve this um but then we're going to require probably a new approval so I'll

leave this open and we'll move on to 868 actually let's see if you have any act discussion going on I doubt it but yeah okay so what's going on on this one so I assigned a number okay uh 14 days ago all

right yeah so this hasn't been dealt with so I'm not going to be moving this into last call but I will leave a comment to that effect on here okay oh looks like this will merge Perfect all right so let's look at some erc's moving to review

okay so if we go over here yeah so there's still some to-dos in here so this is incomplete and we'll not be moving forward um yeah it's 798 now uh 1185 um yes this is still yeah last [Music] meeting yeah so these will break stuff

so they can't do that so we'll leave that one I I think it is like um was reported to me because of this particular PR the EIP board was broken I don't know they made some changes somewhere in this PC the EIP what was broken uh the EIP board was broken the one you designed for eips insight that people are yeah for this yeah somehow somehow this particular Feer broke that I'm hoping to get more details on it in the EIP when the team will be there to maybe postmortem this

particular so it's probably breaking because of well that's very broken but where is validator yeah so it didn't actually run the validator on it why not that's really weird files changed ERC 1158 huh let's go see why this is broken code I I think they had fixed it like they found the issue and they fixed it but I asked them to maybe explain it so

we can share it with the authors and they do not make this kind of mistake again okay yeah so um excuse me I'm just getting a phone call I'll be right back hey sorry about that okay

so um miscellaneous yeah yeah so what is this one so 2569 y so why did this not merge on its own ah that would be why yeah so why they they not run that's

annoying let's try yeah just closing and opening may help yeah there's a way to do it without closing and opening I just never remember how to do it so yeah I noticed that it is waiting for quite some time seems like everything is working that's why I just added it here uh why aren't these things starting huh

that's really weird Okay um so let's grab this person's Branch this is an EIP sorry I'm going to be doing this off screen for a sec and okay and then the port request you using

is Master check out all right so Master head yeah there's that's really odd um um this person is really messed up

gift um um so what is this supposed to be editing this is supposed to be editing just 2569 okay so get diff origin Master get origin

Master with the head in eips and 25 69 oh this is this is an ERC oh okay that's an easy one to do here so proposals

easy enough okay say 2569 yeah so drop Minima theme yeah that's probably something I should look at but um I have a whole bunch of other stuff on that vein that I'm working on so I'm not going to be reviewing that on the call here um all right so I guess we can yeah next the drafts here oh um sorry sorry did we just mention that we are skipping on the uh Minima thing yeah so this one is is like um a technical thing for the reposit like for for rendering um it's not

really relevant to EIP authors um and I have a whole uh other version of the website that I'm working on uh so yeah I I will get to that I know it's been open for a long time I willon get to it I got the context yeah of course yeah okay okay what's going on

here all right intense Centric EA smart accounts so uh 7806 minimal intent Centric EA smart account minimal effort intent okay and okay so uh this proposal defines

interfaces to build intense andrick smart accounts eway account delegate contract um and EA account can delicate contract code to the smart contract to implementation and sign intents to allow softw and relays to execute on behalf of the account owner okay so this is 7702 extension uh AA account Direction it's a Hot Topic and blockchain yeah okay um wait okay so the ERC 4337 Engineers buil the

permission standard while unlocking enormous number of useful features 4337 show several limitations complexity require multiple components account entry point pay master bundler and plugins uh SE okay okay here we have phoners okay and okay okay so these your int 10 bites

um put this on unified so each intent is a pack data structure containing sufficient information okay okay so each intent is a pack data structure containing sufficient information about operations the account owner wants to execute okay um

Okay so the turn

PCH call data user intent okay okay Center standard wait standard

okay um okay L header length of instructions the actual head the actual instructions not reord for all implementations okay oh so it's optional um okay

okay so the I standard interface okay fly controls the validation process for for

okay the account side so this is these the interface cool [Music] at the each account only need to be deployed not once it has the account owner responsibility to delegate to a safe um Okay Main challenge with the general int is being able to adapt to

users okay um what okay and my

good enough uh execution the area brings some benefits um okay this Prof

gotting another phone call I'll be right back all right back sorry about that okay so this is for using this proposal motivation section perfect

um the intent has fa by itself link to spot provider the market yeah this is again more motivation um uh okay good uh this on chain okay

okay okay put that there all right so that is one draft down let's move on to the next draft a I was Wonder if you could take the eips there seems to be a smaller one one just requires the EIP number and other one is waiting on these on here the delayed execution or so the delayed execution just requires the EIP number yeah okay and the second one is like U they have made

the changes just requir more change okay so let's take a look at this is a new one it just said yeah yeah just have to make sure I'm not assigning things out of order here [Music] um so the last EIP I did was 9356 so 9354 so this one needs to be

[Music] assigned that one needs to be assigned and then if we look at UHC so the last ERC I assigned was 89 three so 894 and 896 all right so this lot of work in the background pardon I'm saying it's a lot of work in the background people don't know about it oh yeah yeah uh so this is February 15th wait okay yeah so that one's before and then six hours ago 3 hours

ago so nine hours ago goes over there yeah okay so that's the order yeah okay so 374 goes here this is ANP assigned by me and put that

there okay delate execution that is also an EIP 7886 get rid of that too

there all right and then we have the ERC here and 7887 I can't edit this one that's all right okay so um yeah I guess we can actually review this one now

okay so we can fix up their header a little bit more for them just like that all right this purpose makes execution block statically verifiable through minimal checks that only require the previous state but no execution of blocks transactions long validators to test blocks validity without completing its execution we allow transaction to be skipped when invalided execution time without invalidating the whole block to ensure that even skip transactions pay for their resources the coinbase pays for all inclusion costs up front and

recovers the cost only oh that's interesting interesting key advantage of the skipping mechanism is that enables asynchronous block validation a block can be considered valid even it contains an invalid transactions because those transactions end up skipping execution without oh that's really cool um okay uh so we want to change

this so this will go up here and then that will go again one okay Del execution by making the blocks validity statically verifiable requires two things deferred execution outputs all header fields that commit to the execution outputs are deferred by one slot for example State pre-state Route and parent State Route um same applies to the general purpose execution requests the requests are deferred by one slot and the request in the C must however this Lo would only defer the computation of these execution outputs rather than the actual execution because verifying the transaction okay front payment by the coin

okay uh section because okay and change the header structure deferred fields to verify the connect

particular we need to defer these fields replace them with the equivalent okay you include a signature from coinbase okay that's

[Music] okay we incl a signature from coinbase or a header so the coinbase address can authorize the up payment yeah okay the final header structure then is this the following is used to recover

the signer's address intended to be coinbase from the sign block Header by sing over the header blah blah therefore the the coin base coin Bas commitment is protected from replay attacks because the headers are commitment to the block signature only serious oh okay it's good again must be considered valid we SP validation from its execution and etherum execution specs sta so for

okay that's good that's fine good neat apply body sure something isn't closed properly here

what's going on huh I have no idea what's going on here present the block why does it just start highlighting here yeah all right this is oh it's probably picking it up as uh latch anyways this is good for now I'm going to wrap it up here um I have another meeting I have to go to thanks

everybody for coming out um see you in two weeks thank you Sam have [Music] oh

[Music] oh [Music] oh

[Music] oh [Music] [Music]

oh oh [Music] oh

[Music]