All Core Devs - Execution #133

Transcript

[Music] [Music] [Music] [Music]

[Music] [Music]

[Applause] [Music] [Music] so

[Music] [Music] do [Music]

Tim Beiko: okay good morning everyone

welcome to awkwardev's number 133 uh we have a couple things today so uh obviously a lot of time discussing kiln and the latest uh merge updates and then we have some upgrade some sorry updates on a bunch of eips we had previously discussed for shanghai um so one around beacon chain withdrawals which is actually a new eip with a different approach um an update on the prototyping that happened for the shard blob transactions and then finally an update on an ep we discussed this a while back but uh the idea of having the coinbase uh address be warm uh rather than cold with regards to gas costs um

then finally uh we have um um i'm sorry i'm blanking on the name right now uh somebody from one inch uh apologies uh here to talk about another eip which reprices uh reverted up codes oh anton yes sorry about that so anton to talk about the ipa with your prices uh reverted operations um and then last thing i'll give a quick shout out now but uh we had been discussing how to call the execution layer client release this is for the merge so there's already a name for the consensus there ones next week at the same time as this call so 1400 utc on

friday uh we'll have a breakout room to discuss that so if you have strong opinions about namings um this is where you should show up um cool so for kiln um maris i saw you were in the discord uh trying every possible client combination do you want to give a quick update and then we can probably get others to chime in

Marius van der Wijden: yes sure um so i've been trying to set up a uh a document for all the different clients um the same way we did with kenzugi so that once we launch kiln the community can come together and and

run some of them haven't had proper auth support yet or they don't use auth for the normal operations uh that that are not like the normal calls that are not part of the the engine api spec and so i think that's something that we need to discuss whether we want for example the eth calls on the engine api port on the authenticated port to also

require authentication and i would prefer that because that's way easier to implement for us or if we're going the route that some of the consensus layer clients uh chose to do the uh the calls for for the the er ether calls uh without without authentication and only do the engine api calls with authentication and so maybe mikhail has some thoughts about this

yeah i mean

Danny Ryan: my opinion is that anything on that port should be authenticated and i think that's probably how it's specified if it's not

it should be clarified

Mikhail Kalinin: uh yeah i agree so it's it's like the authentication is for the endpoint and the endpoint has two namespaces currently which choose engine and eath subset of

each

Justin Florentine: yeah this is basic here that's how exactly how we read the spec and that's how it's been implemented

i'll go for another mind

Danny Ryan: yeah we can circle back on that make sure there's any clarifying text that needs to be there and just also coordinate with the other side

Marius van der Wijden: that's good okay um yeah and we also like

we also plan to maybe not run the unauthenticated endpoints um or we might choose not to run the unauthenticated endpoints and that would break clients that don't have this so yeah otherwise it looks pretty good tiku and lighthouse already support the authentication out of the box lodestar supports authentication for the engine calls and i'm not 100 sure about nimbus and prism there seems to be some issues with the authentication that's it

cool

Tim Beiko: thanks for sharing um anyone else have updates on

kim maybe perry on devnet five yep

Parithosh Jayanthi: uh sure so we did launch merged net five yesterday um the merge for epoch has been hit earlier today and we already found one issue with the client team that's looking into it but ttd hasn't been hit yet um most likely it would take another two or three days and latest on monday we're just gonna run a bunch more miners to to hit the ttd um tooling links are up i'll post a link on chat and we should have more information on kiln sometime next week

Tim Beiko: um yeah and i guess i related to kiln um one thing to note is we'll we'll do a an announcement on the ef blog like we did with kinsugi um you know kind of explain to the community what it is and whatnot um we'll link marius's doc which has kind of the like pairwise uh instructions between clients um but if client teams want to have like a like one pager or you know short a bit of documentation about uh how to kind of get killed running on on their client and that's really helpful as well and uh i'll reach out or yeah and and and we can we can include those uh for the teams uh that have it

also my uh my

Marius van der Wijden: my document will be extremely brief so uh i think it's more for like really technical people and it would be nice to have longer uh longer explanations for people that are not that into uh running stuff on the cli and stuff so if you're out there and you're interested in in doing something for the merge and helping us out then you can just create a blog post with your favorite com combination and explain uh to the average user how they can set up a note on kill that would be really great

Tim Beiko: yeah

very good point um and yeah i guess just to kind of check in with the the other other teams um you know is everyone roughly on track for uh being ready to to go on a more public kiln version next week

from now that my site we are ready without we tested it with a one sale we're going to launch the first notes with of uh on the merged net file with party on monday andrew

Andrew Ashikhmin: well i'm still working on um

fixing uh the tests in hive um so like i've just realized that there are still things to be done in our code base so we will try to make it but it's a bit uncertain

Tim Beiko: got it

Gary Schulte: basically was on track for a kill and release uh with or without off next week

Tim Beiko: cool great um anything else on kiln or just the the the merge devnets that people wanted to discuss

Mikhail Kalinin: um we actually have a small stack update is it okay to share it now

Tim Beiko: of course

yeah

oh yeah

Mikhail Kalinin: cool so um we are we have like uh several prs to the engine api they are mostly clarification prs uh one of them sets quality of service to exchange transition configuration method uh and this quality service requires a bit of attention from implementation side also we have a slight update to the optimistic things pack really slight one all these updates are backwards compatible with the v2 version and what we are about to do is to release

all of this under v2.1 version so it should be pretty much okay to have a devnet or a test net with we too and then uh clients will be able to upgrade to b2.1 uh uh once yeah once everyone once each client is ready so that's like the plan and i guess we will have this we 2.1 release early next week that's the update

Tim Beiko: is it possible to have like a like a kind of very clear separation of v2 and v2.1 just in terms of the meta specs because

we're probably going to link v2 uh some if if not linking it directly it'll be like sub-linked somewhere in the kiln blog post and so just to make sure that like that link stays pointing towards v2 and v2.1 is like

Danny Ryan: why not just like to be 2.1 i guess considering that these are all backwards compatible and don't change anything for end users

Tim Beiko: i don't have a strong um just that peop i guess my yeah my resume is just like you don't want people to kind of look at the spec and then look at the clients and like there's a mismatch um but i don't have a strong opinion there

Mikhail Kalinin: yeah i think it will be just released like as a regular bump of uh kiln version or kinsuki version but just with 2.1 to reflect that it's backward compatible um marius uh yeah i hear your question and uh they will there will be like a few prs in engine api a couple of them clarifying things and polishing them um one is setting the quality of service which actually on the exchange transition configuration method which actually for el from implementation side it means that el should

fire a message in the log if cl hasn't triggered this method for 60 seconds or for uh 120 seconds so this kind of stuff so it's like to be sure that cl is really um that the el is driven by some cl um that's that's that's it's basically for el

psi yeah i don't know any

Danny Ryan: i was saying on the optimistic sync side it's there's a case in which um you can be a little bit more liberal and what you're allowed to import um and so it's kind of expansive in that and so the other it does not

reduce the spec

Mikhail Kalinin: um yeah good question we don't have spec for finalized safe latest and unsafe yet um so it it actually a slight change to the execution apis uh it's a matter of adding like these values to to the enum that that's already there in the spec but in terms of implementation might be much more invasive

Marius van der Wijden: um yeah and i think that that's a that's a pretty big change on uh

or might be a big big change on on the like the user side so i would uh i would vote for like doing this uh spec pretty quickly so that we can implement it and then have the the the service providers and everyone uh testing this

yeah

Danny Ryan: to be clear the user can do nothing because latest is still there which you know it's the addition of the other two but but yeah if they want to actually leverage the new functionality they they need to practice

it

Mikhail Kalinin: um

yeah the question is do we want to have this for kiln at the end yeah for for the record it can't be implemented like kiln [Music] test net can be launched and then it's um this feature is implemented and deployed there it's like not a blocker to launch

Danny Ryan: yeah i mean i would i would i think we should get it written down and i think that people can roll it out and that should definitely be out by the public testaments the not kiln but the existing public

distance

Mikhail Kalinin: um yeah i guess then if we want to have this for public test nets we would like also to test it and kill probably at the

end of or in the middle of this

yeah and i do think one

Tim Beiko: it seems like the biggest so actually doing the json rpc spec is is not like the biggest thing i think the biggest challenge was actually getting the safe head uh exposed and and kind of passed through the execution layer um and then kind of dealing with that in the execution layer um and so that i i guess that probably is something not like you want to do you don't want to hold kiln on

um yeah

Danny Ryan: yeah so both of these values are passed already it's a matter of the execution later than kind of tracking and tagging them as as blocks and states that could be retrieved by those keywords

got it and right sorry

Marius van der Wijden: like the big problem that i faced when i started to implementing i i started implementing uh finalized that was pretty easy uh the issue is that latest currently um just uses the internal blockchain object and so we will return the

unsafe head and um we can like if we if we i think having latest as as the unsafe makes more sense because you want to build on top of uh latest

um but yeah i think georgia

Micah Zoltu: people who are using jason rpc though are not building blocks they are app developers or integrators and whatnot who very much do not want latest yeah but you know but you want to know and save that when they're on latest

Marius van der Wijden: but you want to create your transactions on top of uh latest

you want to have the nons

Micah Zoltu: i don't think so i think you won't

think about the safehead like well i refer let your phrase i think you're correct that you want your transactions to be to be executed against like when it comes to like gas pricing for example latest or unsafe is going to be give you a more correct gas pricing however for um determining what this state of the universe is like has a transaction final or is a transaction mined so to speak i think safehead is what basically every user wants right and so ideally dapps will switch to using safe and unsafe appropriately and so the question is is what is the default that most people are going to want most of the time i think safe is that

i

i

Danny Ryan: yeah i guess i'm a bit mixed on this i know we hashed this out months ago but um you know the the proof of work block in the first second is also something like unsafe in that it does get uncle it's not rare for it to get knuckled so like the latest doesn't really imply that it's going to be there forever whereas if we had a new keyword that was safe that then now is new and allows me to make like firmer decisions than block confirmations uh you know 1v1 block confirmation and allows me to make not quite as firm decision as as finalists

but

Dankrad Feist: as a counterpoint in proof work there's no balancing so there's there isn't the danger that someone intentionally creates a block um that is likely to be

reorg

Danny Ryan: i agree but but that is um you know of a block that might be like just be like i don't care about the intention i just know that if i get ahead and proof of work it might be uncles but if it's

it

Mikhail Kalinin: i think it depends mostly on the uh unlike the general use case for which people use the latest and cannot be like distinguished for

some use cases where unsafe is uh the one thing that people want to use can't be like easily um juggled in the in india in in-depth and services that use

jsonpc

Tim Beiko: is it so yes safe as a separate and like endpoint than it is to like rewire latest

Danny Ryan: um probably i mean i think what marius was saying is latest is latest and it's used in this like very particular way for certain things obviously it's used also to read uh the state of the world but the if you just add safe and unsafe and kind of say hey stop using latest and be more

particular about safe and unsafe in the future um that might be a path

Tim Beiko: right because it feels like if we do

still people i mean

Dankrad Feist: sorry i'm i'm a bit confused there because we are adding the new endpoint anyway that that's already is like i mean so this is not i i don't see the argument

yeah

Danny Ryan: no the the issue here is that uh whether you're wiring latest to be the tip of the chain as it is or wiring it to be this thing that might lag

yeah

Dankrad Feist: but i mean also another counter point to the earlier argument that latest is what you want to build the transaction on well if you have a transaction that can only be built on latest that is like that is also not

safe anyway right like any transaction that assumes one particular state can simply fail to encounter that state when it's actually included

Marius van der Wijden: but but you like you want to you want to build the nonce on top of

what uh what i'm not talking about transit yeah

Micah Zoltu: i don't think i mean the nonsense basically everyone handles it yeah the wallets handle the nonce and they track them internally they don't use the node for that so i'm not too worried about that particular aspect

i guess i think i think it depends

Marius van der Wijden: i think it depends a bit on whether you want to read or write the blockchain and

and for writing the blockchain calls on like wiring latest to unsafe might be better and for reading the blockchain wiring uh safe to to save might be better uh sorry latest to save might be better and um from like i remember that it used to be that we had like the the most used call was was it called estimate gas so so this stuff

and yeah so

Micah Zoltu: i think it depends on what type of views you are if you are a mav miner for example you're definitely gonna want on

safehead but i'm dope not too worried about defaults for those people those people can very easily change their code to use you know unsafe if that's what they want and what i'm more worried about is the average user who is not an ethereum expert you know barely understands what gas is or probably doesn't understand what gas is they're just trying to use some dap or buy an nft or whatever and when it says their transaction has mined like they're completed like they get that little ta-da thing at the end of their dap that says hey you got your nft or whatever it is you're trying to do is done now i want that done to really mean done and so for these users who are using dapps today they're using latest because the only option and that done doesn't actually mean done because there's real

potential but luckily you know if we reorg probably your transaction will still make it but maybe not depending on what you're doing and so if we switch all those users over to safe done means done in almost all scenarios right like except for the very weird scenario where we actually have a safe head reorg which can happen but rarely will those users won't run into problems and those are the ones that i think we should be optimizing defaults for not the power users who you know want to play with the very edge of the chain and they're you know worried about you know doing these uni-swap transactions or whatever that need to go in at the exact moment in time that the price moves or whatever like i think we should focus more on those users that don't know what ethereum is barely know what they're

doing they installed metamask and that's kind of it

Tim Beiko: and one i guess one data point i can add in favor of that is it took us it still takes a long time for even very popular apps to have uh like proper 1559 support a lot of times like i'll still use a random application and like the web3 or ethers version that they're using uh basically populates your your transaction as a legacy transaction uh even though it's been like nine months since 1559 is live um so i think that you yeah if we can switch everyone by default um there's a large portion of applications that will provide a better

ux that otherwise just might not um yeah that said i don't know i guess i the one thing i'd be curious to just understand a bit better is the engineering cost like you know is it 10 times harder to rewire latest than it is to just have uh safe as a separate flag um and lay this kind of map that unsafe um yeah that seems to also be important

but

Micah Zoltu: i can't speak for all of the client teams obviously but um from the client code base that i have

looked at um generally you know json rpc receives a message over rpc and you know it's parsing those variables um you can do that aliasing right there and uh it shouldn't matter what

your aliasing to

Danny Ryan: yeah i guess it's only if like latest is also double used for things deep in the code base that aren't really related to json rpc

Micah Zoltu: yeah so i guess if from a naming perspective within a given client code base it's certainly possible that a clients may be using the word latest everywhere in their code based refer to the unsafe head and then it's kind of weird to have the jason rpc have you know some aliasing to safe head i'm not terribly worried about that

because you can do the aliasing like right as you enter basically at the very edge and so it shouldn't cause a problem in your code base overall but again this is you can't speak to a specific client just in general

Danny Ryan: given that safe and unsafe or almost equivalent almost a hundred percent of the time on main net i'm i'm not um too concerned about the distinction of which one gets wired here so i'm

gonna withdraw my carrying yeah and i guess i just go ahead beerus

i

Marius van der Wijden: i just took a look at uh at our code and i think we can pretty easily rewire it so yeah it should be okay

Tim Beiko: okay and so there's a bunch of comments in the chat so are we like roughly aligned obviously finalize is there do we want to expose both safe and unsafe alongside latest so to have like safe

Micah Zoltu: yeah i think the the only contention from what i'm gathering is what will latest alias do i think everybody sounds like an agreement we will expose finalize safe unsafe and we just need to

decide again what latest will alias do which of those

Mikhail Kalinin: and by default it probably makes sense to make it an alias to unsafe uh to just i mean there are probably some patterns where latest where it is expected that latest will return the head like literally the the tip of the chain so and if we change this semantics to um like to to to make it not always uh the heads so probably um some dabs and services will have to adjust their code bases

to use the new and new tag

i think yeah yeah

Micah Zoltu: there will be some but those will be like professionals that care that much like the only people that care about a four to six seconds difference it's like mev miners front runners etc and i really don't care about and designing our system to favor them i would much rather design our system to favor you know the idiot that doesn't know what they're doing

Marius van der Wijden: yeah i would i think they're the same people

wow

Tim Beiko: personally just based on the experience of rolling out 1559 and like the time it took to adopt which was much longer than i expected um i would

push a bit to having latest defaults to the safe head because we kind of will a bit more you know rewiring we kind of give this extra security for free to like a bunch of end users who might not be aware about it and that that seems like a win and otherwise i suspect it'll take years for certain applications to update

um yeah

Micah Zoltu: yeah i concur with the timeline like it's going to be many years before we see latest stop being used and that's assuming that we can get all the docs updated to discourage

juice

Danny Ryan: yeah i think i agree i do also agree with nicole that

the change has the chance to break more things but if those are sophisticated users that can handle breakage then i guess that's okay

and

Marius van der Wijden: and that's why i think we should create the spec as soon as possible implement it as soon as possible so we can have users test it

Tim Beiko: so i guess does it make sense to go go ahead with the assumption that latest is safehead get that implemented as a high priority after kiln if we obviously see that something breaks in a way that is like very hard to fix or or whatnot we can you know change this decision but um yeah

at the very least we'll know uh it once it's implemented and and and i suspect once we once we fork the public test nets um is when we'll get a lot of data about how you know real applications kind of react to this

Marius van der Wijden: one question would be what what happens in the in the case if we don't have a safe hat yet so for example in proof of work we don't have a stayfat then we need to do the latest back rewired back to

you're

Micah Zoltu: talking about like if you want to

release your client with these endpoints ahead of the merge which presumably you would want to do right um ideally i would say like finalized is some number of confirmations and safe one confirmation but that's uh i don't like that either because that's significantly longer than

you can also just

Danny Ryan: sweep it under the rug and point safe

and unsafe the same thing yeah or whatever

Tim Beiko: i think it's it's very weird to return something like a proof of work value to finalized because they're very different concepts

Micah Zoltu: i don't think we want to narrow it though because we want people to update their dapps before the merge happens that way when the merge happens they seamlessly transition into

it and so if finalized what makes sense for a particular dap they can start using finalized um like which means something hope useful like you know six confirmations or whatever or ten confirmations or something that's you know approximately what finalized something that's useful to them and is kind of representative in terms of time scales that's similar to what finalized will be in the merge that way their dap can still work today but they can have it merge ready so as soon as the merge happens they can immediately start using the correct you know safe unsafe finalize if they want

Danny Ryan: so the spec can have if these methods

are exposed prior to the merge these are recommended values

Micah Zoltu: yeah something like that

Danny Ryan: i don't think we need to be super dictatorial on those recommended values okay

not

Mikhail Kalinin: sure it will be easy to define this recommended value so probably yeah i need to think about it

like

Micah Zoltu: we can discuss it in discord i'm happy to hold the carry on this conversation

more

Tim Beiko: cool um but just to be careful do we have rough agreement that playlist is safehead and does anyone have like a strong objection to that

Mikhail Kalinin: i think that actually that developers

should have this objection personally i don't have an objection to to him to have analysis safe or unsafe just yeah either way is good for me personally

Tim Beiko: um yeah so i guess as soon as kiln is released uh this is probably the next big thing that we should we should be working on

Mikhail Kalinin: so uh latest is safe right

Tim Beiko: yes i think we go for that with that for now if some infrastructure provider or application tells us this breaks

everything in a very complicated way we can we can change it but assuming that um that's not the case yeah you can just go ahead with

this

Mikhail Kalinin: yeah one thing to clarify here is that we have saved block hash currently pointing to finalized yeah to the finalized hash so we either shoot and yeah this this will happen until we have uh getsafe had an authentication of the outside opposite

Danny Ryan: i think it's the head and the head and safe head are equivalent right now

Mikhail Kalinin: oh really oh sorry sorry for confusion yeah yeah yeah i was just going to suggest

Danny Ryan: yeah so there's there's

actually work on the consensus later side that i think is ongoing um we can catch up on that in the call next week but uh i believe they're trying to kind of make sure the engineering requirements are tractable with respect to the algorithm

Vitalik Buterin: one quick concern on safehead um so the safehead formula right basically means that the safe head does not progress if more than 50 of uh validators are offline um but like the whole point of having something other what um like actually having the the chain and not just do a yellow lfd so that we can stay off us have a chance that keeps progressing in that case so do we want to try to account for that in any way

Danny Ryan: i mean that's an argument for keeping the latest says is right

Vitalik Buterin: or it's an argument for uh modifying safe so that it only takes into account what it's it's based on recently online validators or something like that

Dankrad Feist: i mean shouldn't this be a manual intervention by the user because like that's literally what safehead is trying to protect you against like say you are on the minority fork um then what you're suggesting is literally not safe like that is exactly like you will be on the 10 chain um because your optical fiber went offline or something

and

uh and now you you're

Vitalik Buterin: right then but that's already a situation where you're assuming like high latency that's causing you to not see the majority chain right so safe head is already conditional on that

Dankrad Feist: um it would in practice protect you from that though like it would in practice um exactly in this situation stop that like oh so it's true that i guess you can't prove safety another condition but it would protect you from exactly that so i mean my feeling is that this should be a manual user intervention like the situation you describe should be me as a

user saying yeah i checked this is not due to a catastrophic um outage of like uh networking split between u.s and europe it is instead because a majority client went offline due to a bag um so i want to trust this chain

Vitalik Buterin: i don't know how i feel about intuitively how i feel about that like like i think that does really move away from how we've been treating the chi like the the the head of the shared circumstances so far

Dankrad Feist: right but isn't a network split the most

likely thing that leads to such a condition

Vitalik Buterin: um it depends like there i think that there could also be lots of notes going offline at the same time

[Music]

Danny Ryan: we should probably have this conversation out of the call

yeah

Tim Beiko: um i guess we can use just the merge general channel to flush this out sure

Micah Zoltu: yeah i think i think if i'm correct from wrong but this particular discussion is consensus layer right and just whatever this layer feeds the exclusion client is

what

technical student client will yes okay cool anything else on kintsugi or sorry kiln or demerge

Tim Beiko: okay um next up uh we have a new eip uh for beacon chain withdrawals which uses a push format um danny and alex are the authors i don't know if alex oh yeah both of them are on

the call um yeah do you want to give a quick rundown about the changes

Alex Stokes: yeah i can uh so last time we talked about withdrawals that would be implemented in this pool style where the user would have some proofs there'd be some information committed to in the evm and then you could affect the withdrawal danny actually did an analysis of how the spec was written and basically based on that uh that kind of got us you know more confident a place where we could move to a push style withdrawal where the idea is basically you know when the conditions are met on the beacon chain you can imagine these withdrawals are sort of forced into the

head of a of a execution block uh and and then validate it that way um you know you can read the eip but the main thing is a new transaction type a new eip-2718 transaction type that uh is treated pretty especially rather than having evm execution it essentially just is an instruction for a balance transfer or a balance increase um yeah the one thing that i think we want to do that we haven't uh yet with the cip is add logs uh that was the one thing most people are doing so far with uh these types of withdrawals and

otherwise yeah i guess the main question here is just uh does this general approach sound good to everyone with this new transaction type the new semantics and yeah danny was there anything else you wanted to add

Danny Ryan: uh yeah the document i shared here uh pretty much in the spec uh for the validator that defines these credentials which are these so-called eth1 withdrawal credentials that can be deployed on maintenance today um it says that code would be executed so we did an analysis to see if anyone's actually depending on that um because if they were heavily that would kind of preclude this and really need pull to be able to handle gas accounting and things uh it doesn't seem to be the

case um so i think it does open this up and and open up the being able to change this withdrawal credential uh definition um but yeah it's pretty much the consensus layer uh maintaining a cue of these withdrawal receipts and dequeuing them into uh the execution layer um and that being a consensus layer validity condition that the exact proper type three transactions are put into that execution layer block um and the execution layer just uh does the balance updates accordingly no signatures and things are proofs required

miguel

yeah um i

Mikhail Kalinin: yeah i think that this is simple um on the outside but one thing here i understand why withdrawal uh operation is made as a transaction to re to to reuse over the existing mechanism and probably reduce the complexity but i think that semantically withdrawal is not a transaction because what we usually use for a transaction is the application layer transaction uh and uh withdrawal operation is the um not an application layer stuff it's an important a more in protocol thing so i think it would make sense to have

like a separate uh set a separate list of uh operations separate list of withdrawals and yeah just could make things more clear in code and more clear um i like less conditions to check so we have a separate list which is checked by consensus layer and it doesn't need to you know to be combined with the transactions list so that's that's what's what's in mind

Danny Ryan: right

Micah Zoltu: i think there there's there's minor benefit i think in having them included as transactions just because tooling that already exists for you know tracking you know deposits and withdrawals on chain uh just like tracking eth and the movement of beast

and whatnot will all just kind of just work more or less um or at the very least you'll see a new transaction type you now know you need to deal with whereas if we put it somewhere else it very easily gets missed by tools that are trying to aggregate this is minor not a

yeah

Danny Ryan: right now on the consensus layer we do track it in a separate list ex there's a couple different designs but you could pass it as a separate list on the engine api um and then the execution engine execution layer could then construct the extrusion layer block in whatever way we decide is reasonable i think right now it's it's a type three

transaction after some discussions with geth and i i do think that's a reasonable approach but if people wanted to make a new kind of system operation list and deal with it differently i'm open to it uh but i think there's less friction in doing it as a type three transaction

oh thank you

Andrew Ashikhmin: um yeah i would like to have a more comprehensive document because here uh in this episode i see only very limited uh set of changes only concerning the execution layer i'm like personally i'm uncomfortable implementing this without

understanding the entire picture what's done on the consensus layer how or what are the security guarantees basically i like how the other eep 4844 sharp blob transaction is specified it concerns both layers and i think like going forward in general it would be nice to have like if it's a set of changes concerning both layers that they should be all specified in a single document

Danny Ryan: so i do have the consensus layer specified it's in a pr uh because that's ultimately where it needs to live because that's the way that spec is written um certainly there can be more exposition in eips and and i think that is certain that is a

conversation we need to have i mean in the in the the merge eip itself uh it's not in the mer gip itself it kind of has these there are these events and you just listen to these events and the entirety of that uh beacon chain functionality is not specified there um and is instead specified kind of in an ancillary reflective spec but i i'm open to like this is more about eip process there is the functionality is defined and um i'll i'll link to it in a comment on there so that you can go look at it um ultimately if we had to find it in there we're gonna have to find it somewhere else as well and so i'm a bit hesitant to be writing things down in two places

Andrew Ashikhmin: because right now like

how will what are the security guarantees i just personally don't understand them is that no malicious player includes uh such transactions so it it to me it it seems a bit raw very raw at the moment

Danny Ryan: well i i i'm going to point you to this the uh reflection of the consensus layer specs um quite frankly it's a these are uh bound by literal withdrawals uh and eth and validators they're put into a queue and they're uh ensured that they are precisely the correct amount is put into the execution layer um that's

that is the functionality and it's a consensus layer validation uh but i will show you i'll link to the pr right now

Micah Zoltu: am i correct that this is an alternative to um doing withdrawals via a traditional ethereum transaction and a contract that can validate

a proof

Danny Ryan: correct right

Alex Stokes: and not needing the beacon state or anything like that

Micah Zoltu: the advantage or the argument gary in favor of the other one is that um it doesn't require anything on the execution layer right like attachment client doesn't team doesn't need to do anything at all is that accurate

Danny Ryan: what do

you mean on which one

Micah Zoltu: if we go with the uh it's just a special contract that just has a bunch of

ethernet and

Danny Ryan: well there's two you need to have the beacon root op code for one and to [Music] be able to send transactions from no ethos at the source or to meant you know 10 to the 10 million eth into this contract at some fork right boundary

Micah Zoltu: that's right

okay

Danny Ryan: which the latter after discussions uh the last couple weeks was most people did not want to do at all

Marius van der Wijden: i think my main point was we don't want to have another way to start a transaction

and and so so we don't have another we we don't want to have another way to start an evm execution and because that might add additional complexities and and uh so what if the transaction rewards what if the transaction i don't know creates another

contract and

Micah Zoltu: is there a reason that people doing withdrawals can't just be expected to have some eth on layer one to pay for

um yeah

Marius van der Wijden: the problem is if if this transaction can revert then [Music] you need to tell the consensus layer about it and so by do i do

by doing it this way only the consensus layer tells the execution layer do this and then there's like there's no no data flowing in the opposite direction

Danny Ryan: yeah you pretty much can't do push in a sane way if it's going to be triggering code execution that is unbounded you can do full and so i think those are the two options on the table

Mikhail Kalinin: will this this transaction type if we go with transaction

we just banned one for in the mempo so it should not be propagated right

Alex Stokes: yeah it will only be part of blocks pass from nikki to this client

yeah there's okay so

Mikhail Kalinin: there will be exceptions so there will be exception in the memphis code so if the if you see this transaction just drop it and then do not propagate it it just

Danny Ryan: yeah there's no value to it and no way to validate it

Marius van der Wijden: i wouldn't even really call it a transaction i think it should be passed in the engine api as as a blob and then we include it as a transaction into the block but not really like use it right

Danny Ryan: so in the engine api you can have you know essentially a new list of system operations that the meta system of the beacon chain is

dictating to put into the

block the way you accidentally get them um propagated is if you a block gets uncles or i guess we don't have knuckles anymore do it though yeah yeah so i guess the

Micah Zoltu: so at least under proof of work and block it's on called all the transactions that were in the uncle block and get propagated across networks like when you receive that block you receive all transactions that were in it and they just are a big list of transactions you're like oh here's new transactions i'm gonna start spreading these out if we're adding a new transaction type that should not spread out that means the code will maybe need to be added in

that area you know that says you know when you're blasting out all the transactions you saw on a block don't include these unless right the block is actually mined in which case do include them

yeah just gets weird it feels weird it's

Marius van der Wijden: it's not hard to do that

Danny Ryan: yeah but i mean any exceptional argument like that any exceptional condition like that does lend argument to like making it a new system operations list rather than transaction but i'm i i don't have the the depth to say which one is is more reasonable my intuition is the type three transaction but

i could be convinced

another one

Micah Zoltu: think i'm very very weakly um in preference of a system actions system operations list but very weak at the moment

Marius van der Wijden: yeah i'm also weekly in favor of system operation because we're doing a lot of like precondition checking on transactions and um we like yeah i think i think we have to implement it to prototype it and see what what works what what creates like mess

alex you did do something of a prototype

Alex Stokes: yeah i didn't touch any gossiping or you know networking but essentially uh it has the transaction types i mean it's super streamlined because it's just another transaction type there's like one minor check to say hey if this is one of these type three transactions then just do a balance increase otherwise pop into the evm i thought it was not that bad i'll go grab a link

Micah Zoltu: are there other system operations we have in mind anywhere on our current roadmap

yeah just in the future but like

Micah Zoltu: even five or ten years down the road like is there anything that we're thinking about that would also fall into this category

Danny Ryan: i can't think of anything immediately

Łukasz Rozmej: so not system operations but account abstraction uses some kind of user operation that is also gossips separately and bundled into transactions

right

Danny Ryan: right but those ultimately making it into normal transactions right

Łukasz Rozmej: um yes but not sure but maybe when including included to the block and before that they leave us separate entities but i'm not entirely sure

Tim Beiko: right there's a comment from proto in the chat about how l2's also have a similar concept where you know they did when you deposit funds from l1 to l2 it's kind of similar then uh deposit or moving from the beacon chain back to the execution layer so perhaps if if the mechanism kind of can be reused that might be interesting um i guess in terms of next steps here is it worth trying to prototype a sort

of system operations version of this and and perhaps having both uh side by side can kind of help the decide

Alex Stokes: i'm happy to do so but does anyone actually want to see that

yeah yeah i don't want to

Andrew Ashikhmin: yeah i think it makes more sense i agree with mario's and that it makes more sense to have it rather than transactions as kind of system operations and uh my understanding is that engine api should definitely be involved uh

it just is so it's not kind of the the eep is not complete i don't see any mentioning of engine api at all here

Danny Ryan: the engine api has not made it into um eeps before but instead has these kind of like operations or these events from the consensus layer so it would be the expansion of um an event like the the new block event or whatever that would also have these operations

in

Andrew Ashikhmin: um well my point is is it might it doesn't have to be like verbatim in a single document but

at least there should be references so that when you have a single document that references it has all the necessary references that i can have a single point of entry and then able to understand the entire picture what changes on the consensus layer what changes in the engine api what changes on the execution layer otherwise it seems like like separate bits without any unifying picture okay sorry that's my two cents

Tim Beiko: right

Micah Zoltu: i do yeah i think what andrew's asking for is the the thing that i always pushy corey ip authors to build which is um don't include that in the ip please but um big eaps like this definitely benefit from having like a hack and b article or something that ties it all together like

with like tim did of 1559 um i use that as my example always is an excellent example of you know tying the whole picture together in some metadocument and the eip can remain just the spec

Tim Beiko: right this is i guess kind of it

Danny Ryan: yeah we can put all the pieces together in one place

Tim Beiko: yeah i guess we do that withdrawal sort of meta spec um yeah

Micah Zoltu: the downside is it requires a bunch of writing and no one likes doing that

yeah so i guess yeah the

Tim Beiko: does that make sense in terms of next steps though to prototype the the systems operations version and to put

together a kind of more comprehensive uh meta spec

Danny Ryan: yeah and the document um the consensus layer and engine api i think will look almost exactly the same whether it's the system operations or not and then there'll be two options on the um on the execution layer so two eips choice at that point

um tech of the

Micah Zoltu: question was asked earlier would a prototype actually sway anyone one way or the other like or people like i i agree that we shouldn't have someone waste their time building a prototype if that will not sway any opinions

maybe it's worth writing down in kind of

a stripped-down eip um before doing a prototype there's no fields

Tim Beiko: i guess yeah marius andrew would that like sway like i yeah i guess it's mostly for your consumption so any thoughts on that i don't know if you're speaking maris but we can't hear you on zoom

Marius van der Wijden: i'm i'm not speaking

Tim Beiko: okay sorry

um i'm

Marius van der Wijden: uh i'm happy either way

uh i i looked at alex's pr and um yeah it looks pretty good so i would be also okay with having the transaction style um i don't know

Danny Ryan: well let's let's put the the meta spec together have a proposal for the engine api finish uh the networking components and log components of the existing eip and uh get some feedback from there and then if people feel strongly about after they get to chew on it a little bit a different operations list we can address that at that point

Tim Beiko: that sounds good

um cool just because uh yeah we're starting to run sharp short on time um yeah that seems like a good next step we do have a couple more eips so i'll move to the shard blob transactions

and

Tim Beiko: basically last time we discussed this everyone seemed to think this was a a very valuable thing to have in shanghai but there were questions about like how easy it would be to actually implement this what it would what it would take um and a few people uh implemented a prototype during denver um proto was one of them and he posted an update on uh the agenda today um do you want to take a couple minutes to just walk

through the prototype you implemented and then you had a couple questions you wanted to address on the call

Protolambda: yes sure thank you tim so hello everyone we're presenting eip4844 titled shark blog transactions so not to be confused with 4488 the order call data expansion thing this just focuses on the separate data it works differently so bear with me i'll summarize the erp this introduces a new transaction type the transaction type has all the same features as a regular one five f9

transaction house however it adds this additional data outside of the transaction this data is not encoded within the exclusion layer this data is instead stored within the consensus node and can be pruned after being available for sufficient amount of time this data is formatted as these field elements so this means we can do this case g commitment over the data instead of regular hashing and this erp also introduces two pre-components and an upgrade to verify this data within the evm in an efficient way

and then this erp is always also ford compatible with the full sharding design where we introduce data that ability sampling and then the tricky points with this erp are really that we are introducing this transaction type that has this additional data data that lives within the with the transaction when it's uh produced and it's propagated but not within the execution payload but then the data is distorted as this blob and it's referenced in the beacon block it's referenced in the transaction but it's not stored along with it it's

temporarily retained within the consensus layer not for this shorter term availability and then in agenda i listed a few points um how we can extend this cip and if this is the right approach this ep2718 first introduced transactions describes how to encode these transactions but now that we have this additional data we might want to define how this network payload differs from the encoding as presented within the regular transactions list and then

how do we relay this this blob data we could relay it with the transaction or there may be more efficient device and then similar to the withdrawal transaction type this also looks at implementing the transition type of different encoding with sse and then we also have this question how we will introduce kcg commitments into the ethereum we have been looking at [Music] how we can facilitate the trusted setup how we can introduce this in various different clients there are libraries that

offer this case g functionality and we are looking to minimize it as much as possible so that it's actually really simple extension to the bls work that's already present in clients and then from there we need to work on devnets and we've built this prototype for the exclusion layer for the consensus layer and i'd like your review on those implementations so it can improve the

erp

Tim Beiko: thanks for sharing all this um there is a question about i find in the chat uh i guess yeah we can start there where the

k case that g commitment is probably the biggest or like most contentious thing um as part of this so yeah uh you know what our client teams thoughts about doing this in like basically the next year

Danny Ryan: the commitment scheme because of the kind of cryptographic complexity of those operations and just needing new and robust libraries

is that what you mean

likely

Micah Zoltu: i think it's basically the same argument that kept bls from getting integrated for two years

oh right qcg is mostly bls right

Micah Zoltu: uh sure so like if we still don't have bls

Danny Ryan: but we do have bls in production we just don't have evm operations we do like we use it quite a bit

you know millions of operators on the execution layer though right yeah correct but not in not in the uvm

Tim Beiko: um andrew has his hand up

Andrew Ashikhmin: um yeah i just um i guess i missed uh the original

discussion about bls on the execution letter yeah to my mind there is already a better proven uh library uh that can be used so i'm not that worried because yeah it already exists um so from my perspective uh uh we can implement it in every gone relatively easily um i made so there are a couple of corrections small small things really so that um in the signature the city in the if it's it uses v but v is this legacy field that blends chain chain id and y parity and we should use y parity similar to er 1559 transactions

and also in get intrinsic gas uh a couple of things are omitted the the create cost for create transactions and the cost of access to this i made the comments on the magicians it's just minor minor corrections

Protolambda: yes thank you for your comments we'll get back to those on the forum in general all the functionality is just the same same costs same everything as with eip-1559 if there are differences then we'll try to reduce those the only real addition here is that we're adding this additional data so this list of percentages and those hashes refer to the data

that's then propagated along with the transaction

Marius van der Wijden: um can you expand a bit on the opcode and the two pre-compiles what do they do

Protolambda: so the pre-compiles are to verify this type of kct commitment there's one way to verify a single point of data and there's another way to verify all of it at the same time and the idea really here is that we want to not introduce the stateless requirement to the ethm where we are directly accessing this transaction data but instead we provide a proof and the original data i'll scale data into the

ether and they can prove that it matches the ksgt commitment and so we can prune away this information and the evm execution will still work the block data is really independent from the evm

Tim Beiko: there's a question in the chat about uh concerns about history growth

Protolambda: um yeah probably wanna share thoughts about it so the transaction type does the same thing as one five f9s and that's regards it doesn't grow more and then the additional data on the blob

that's retained in the contents layer not in the exclusion layer so it doesn't affect history growth by all that much within the exclusion layer there's this list of first hashes but it's a maximum of 16 hashes so that's not that that's really not that much compared to these other limits within dpm the real growth is in the consensus layer and this is limited to say a month of data and even when we have large blobs and when we say would have a megabyte of data per block then with a month of data this is still capped to a maximum and doesn't grow out of bounds

and these parameters like how for how long do we retain the data and for how many of these blobs do we want to start with these are up for discussion

Danny Ryan: yeah it's worth just noting that like data availability that is needed for uh roll-ups doesn't mean persistent data storage it means ensuring there are these like data withholding attacks and that those that want the data within some bound time can get that data and then it's made available but not that it's then persisted forever similar to you know dissimilar to the the chain persistent requirements that the work network has right now

Tim Beiko: uh guillaume you have your hand up

yeah i just had a quick question uh about the kcg again like um i mean i used it for for vocal trees in the past it's uh i'm confident it's not such a big deal but we moved away from that for vertical trees how about using ipa uh instead of kcg has a has that been considered

Vitalik Buterin: uh yeah so i actually wrote a big youth research post considering yet the answer is basically that doing data availability sampling and all of that associated stuff just gets much harder with um ipas because they don't have a lot of the nice algebraic properties that casey g does

okay

Protolambda: right so one of the features of this erp is that it tries to be forward

compatible with the full sharding roadmap and central to that is data variability sampling which has been designed around kcg and optimized for kcg and so by building on top of that we are forged compatible and we can roll out sharding without further changes to the exclusion layer it will just be consensual changes after this

Danny Ryan: right so nice way to think about it from that full sharding map is really black boxing is data available that's this function that the consensus layer has to call and in this proposal you just download the data but in subsequent proposals you swap that

function out and do data availability sampling as there was more and more data uh there's been some questions about a trusted setup yes kcg commitments in this scheme would require um a trusted setup of relatively low number of power something on the order of like 16 actually i think it requires 12 but we would do 16 to handle quite a bit of growth from there in the future [Music] and this is something that would be required for sharding no matter what so it's something that the ef is is looking into doing right now um and kind of surveying the landscape of previous um

powers of towel that have been done and uh looking to reuse some of that tech but also too because it's a low number of powers likely doing some sort of uh browser-based ceremony being available um to get much much wider participation than in prior ceremonies uh but working

with power

Micah Zoltu: low power just means the computation required to participate is lower right

Danny Ryan: yeah like our estimates is you could do this in like a minute and a half on your browser um as opposed to doing it in a highly uh optimized compiled thing that still took 20 minutes

or something

Tim Beiko: great uh just yeah again because they're

a bit short on time in terms of next steps here um obviously there's been like some you know technical feedback on on various aspects of it but are there i i guess what are you know people's biggest like what are the things that people would most want to see to consider pursuing this further

Danny Ryan: so i just want to say you know it seems pretty critical that some sort of scaling relief is provided in shanghai i think our two options are repricing and modifying call data which has uh you know chain growth issues and also isn't really elegant

with respect to the future sharding map whereas this brings in probably quite a bit more complexity but is uh synergistic and essentially it lays the foundation for extending it to be compatible you know with with full sharding so it kind of lays the foundations and kind of iteratively gets us to sharding so that's that's it's really a complexity trade-off versus the the elegance of this integrating into the starting room map in general and i i think it'd be very valuable to get a client of winter's take on the on the complexity here you know there is that prototype that proto and others worked on um

yeah i mean getting peter getting martin getting anyone a deeper look at this

Ansgar Dietrichs: um yeah and i just wanted to say for context maybe just kind of going forward and i think the important thing is really just as danny was saying that we basically really want to do something for shanghai for for scaling and i think the one thing we want to avoid is everyone agreeing that this would be nice and i think right now it sounds like everyone all the client teams are agreeing that this would be nice and then only four or five months from now people kind of get to the point where they're like yeah but unfortunately it's just too much

complexity we just won't be able to do that for shanghai and at that point it will be like very late to try and simplify or try and do other things so like basically the idea would just be like ideally we would want to to get feedback on how realistic is this as as soon as possible and i think for example litecoin has looked into simplifying that removing the kcg part which wouldn't be great because then you lose some of the port compatibility with some of the usefulness for zk roll up so it's not great but at least it would be something we could do try to do um if this is just too complex but like it would be really important to get like feedback on how realistic not just how desirable but how realistic is this for for like a timeline that would have this in

shanghai right at the end of this year

Tim Beiko: and i think one thing i'll add to that is you know we've already committed to one thing well which is actually a set of vips but like to the whole uh you know evm object format um i guess call it a feature for shanghai um we have these discussions about uh beacon chain withdrawals which uh clearly are like a non-trivial thing to do no matter what approach we take and then we have this um so you know just those three like they're not yet i don't know eips or set of vips like those three features alone are are kind of already a very large hard fork and and that's probably something like i guess

as soon as the merge code is wrapped up that we need to like consider is you know if we did those three is that even realistic um if not you know what what else can we do

um yeah

Danny Ryan: um real quick removing the kcg that would essentially be using a different commitment scheme currently to reduce complexity knowing that full data is going to be downloaded you don't need to do data availability sampling and then in the future you would ex you'd essentially deprecate that transaction type for a new transaction type that had kcd commitments that allowed for the data availability sampling is that the idea

yeah that's that's how i understood i

think i mean and maybe proto the commitments are already versioned in the the way we specified it

Dankrad Feist: so doing using a different commitment scheme would basically making version zero of the commitment scheme being um a hash based one

Danny Ryan: right but we'd have to deprecate that commitment scheme come sharding because you wouldn't be able to do the data availability

Dankrad Feist: yes

Protolambda: the transaction type still has to encode it in one way or another and validate it in one way or another even though it's versatile in the evm so there will be some difference

Dankrad Feist: it also would not allow the evaluation at um at a point one which uh which would mean it would be much less useful for sdk roll ups

Tim Beiko: okay i guess yeah just to time box

this because we do have two other topics to cover before the end of the call um where's the best place i guess for people to like review this and engage do we have like a channel on discord for this or something

Protolambda: there is the sharded data channel which we can revive originally for the first sharding roadmap but this is a stepping stone so let's start there then there are two prototypes one on the exclusion layer on the consensus layer if you're specialized in either one of those then please have a look and reach out and give your feedback

Tim Beiko: yeah let's use the charted data channel um okay thanks a lot uh for everyone uh on

this next up uh there's another eip that we have discussed uh briefly for shanghai um eip3651 which uh proposes the warm uh to treat the coinbase uh address as warm um we have william on the call uh yeah you wanna give a quick quick summary and i guess reason why you'd like to see this in shanghai

William Morriss: yes for berlin we added eip 2929 which initialized the access list to include origin the recipients and the set of all precompiles uh this missed coinbase unfortunately so the proposal is to add coinbase to this list it would reduce the cost of direct

coinbase transfers which are used by conditional transaction fees such as systems like flashbots where there's an auction system often but you're trying to pay the miner conditionally only if your transaction succeeds or does what you want um and i currently believe these are overpriced because we already modify the coinbase's eth balance and account several times during the block to receive the block reward in the transaction fees so by making coinbase warm it should already be correctly priced to reduce that cost thank you

Tim Beiko: thanks

um i'm curious what our clients thoughts on this oh andrew

Andrew Ashikhmin: uh yeah i think it's a simple and useful proposal so i think we can do it in shanghai

uh antonio sorry anton demires oh anton you're back on mute can you hear me

Tim Beiko: yes yeah uh sorry uh hi everyone uh i have also the question regarding this uh heap as far as i remember

each call with a value attached will cost also 9k of gas extra this uh maybe also should be reviewed maybe with uh another improvement proposal because this is a also a lot

William Morriss: yes i agree with that that nine thousand for each transfers uh might make sense in a cold context but not in a warm context that should be reviewed in the future

Vitalik Buterin: so um in the uh one the the verbal tree right uh a gas cost vip this is one of the companion eips through the vertical

tree ipa i do have a proposal that basically subs like removes all of those kind of special purpose gas cuts that moves the wall into the cold warm system so one of the side effects will be that like warm eat moving will be cheaper

William Morriss: thank you

Tim Beiko: and marius you are going to say something earlier

Marius van der Wijden: yes even even though it benefits uh mev people and i don't like mav people i'll i'll support this the cip it's it was an oversight in the original original one and and i think it's a no-brainer to include it is it

Tim Beiko: i guess am i right in thinking this is literally like a one

line change in a way where we just add a parameter to the list of things that is warming

29.29 but

Marius van der Wijden: not a one line change but

like maybe five ten but just plus like you know hundreds of lines of tests output great um i guess and and um you know

Tim Beiko: we already have included a couple similar uh fixes if you want in in shanghai um so like uh i tried to pull it up right now um uh uh basically push zero seemed like another small one limiting the the and metering in the code um

so you know is this something that people feel confident that we could kind of include as another small win um and that i guess probably wouldn't affect our ability to ship these larger features we were just talking about or yeah i guess to put it differently does anyone feel like if we did do this you know it might impact whatever we do uh blob transactions uh beacon chain withdrawals

Marius van der Wijden: i think we can pretty easily include this without it it increases the the amount of testing we have every every ap

exponentially increases the amount of testing we have to do but it's not that bad

Tim Beiko: okay i guess any objections with moving at the cfi for shanghai and and starting to implement it when we we start the shanghai

dev nets

uh yeah i i mean it's it's uh basically repeating what vitalik said but uh because of uh because of the vocal tree stuff that comes in the fork right after shanghai that kind of makes this whole thing moot um yeah i just wonder and in fact it's also a comment about the next eip

i just wonder if it really makes sense to to bother doing this when it's going to be uh yeah sorry i forgot the word but it's it's not going to it's not going to be used afterwards

Micah Zoltu: i think my one count argument to that is just that well optimistically verbal trees will be included you know in the fork after shanghai history has shown that we are not super great at predicting our future roadmaps and so for something super easy um there's an undefined duration

actually the gas changes are supposed to happen in shanghai

um know

Andrew Ashikhmin: i don't think it's true because that entails a refactoring a fundamental reflection on the data of the data structures so i don't think that gas changes for the vocal tree can happen in shanghai

Tim Beiko: right and i don't know just i guess to be like clear like the only thing we've agreed so far to include in shanghai where um were uh these the four eips basically related the evm object format so 3540 3670 which was the eof code validation then we added these two other small ones uh the push zero instruction and limiting and metering init code um and we had like some sort of i guess soft commitments towards including uh

obviously beacon chain withdrawals um and some kind of scaling solution like we just discussed whether that's a whole new system or something more simple like reducing the call data cost um yeah and so and i guess you know yeah we it's worth noting like those three things like eof beacon chain withdrawals and um and uh blog transactions are all pretty significant so um i'm personally a bit skeptical of including any other big thing until we have like more clarity on on those but um yeah i guess the question is like can we

include this like i guess there seems to be some consensus that we can include this small change um the question is like is it worthwhile to include it if in you know nine months after it gets it gets obsoleted um that's i don't know maybe quickly we can cover that before we move we move on and hopefully stay like a couple minutes after for the last eip

um i think

Marius van der Wijden: i think it makes sense to include it

Micah Zoltu: yeah i don't but

i guess

Tim Beiko: do any other client teams have it have an opinion on this

Andrew Ashikhmin: uh fine to include from aragon

basically

Gary Schulte: yeah from a basic perspective it doesn't seem like it's going to be a significant additional load but it could be one of those death by a thousand cut things

Tim Beiko: right and and thomas or anyone else from

from that mind

Łukasz Rozmej: actually oh i don't have a hard stance about it but i think it's fine

to include it okay so i guess and

Tim Beiko: to be clear when we say included you know we're moving it to consider it for inclusion which is like this in between state which will get it prototyped on the on the devnet and whatnot so i think it probably makes sense to move it there try to get it on the devnets if we do see that for whatever reason this adds

some overhead that is just just too great we can always choose to remove it and that's probably true of all the other you know small kind of quick fixes if there is you know like an exponential testing increase uh by just having these small fixes uh we can obviously decide to just focus on the on the larger changes but it seems reasonable to at least move it to consider it for inclusion and and try to get it on

devnet

Tim Beiko: um okay we're already at time uh i appreciate if if people have a couple extra minutes uh we can discuss anton's eip uh which is eib3978 um appreciate you kind of bearing with us through the call anton um do you want to

take a couple minutes to just describe the eip and um yeah why do you think it's it's valuable

yeah

Anton Bukov: yes uh hi everyone uh i was my colleague michael first time participate in such a call so yeah we proposed this uh eep 3978 which basically uh reprised the reverted transactions we discover reverted reverted operations i would say because we discovered that in case of reward [Music] all gaza fund is being erased and users

they pay for reverted operations same price as for persistent operations this sounds uh really unfair because it increases costs of reverse transactions and in general it seems that we can switch this behavior to keep access costs and refund the modification costs yeah but basically that's it we enumerated uh the most expensive uh operations

and proposed to use access costs for these operations in case they will be reverted

Tim Beiko: thanks um the people there's there is a discussion to link in the eip so we can we can have like longer discussions there but the people just have quick comments or questions before we we wrap up uh do andrew then

Andrew Ashikhmin: um i think uh it's well definitely not for shanghai and in general um aragorn's perspective is that instead of tweaking like do making some small

tweaks to the gas schedule we should concentrate on bigger scalability improvements uh yeah so we are kind of tentatively against this

got it

uh yes same argument i mean uh that i i made before and uh what andrew just said it's uh this one is going to be very very uh very difficult to or at least very intricate to to build and it's it's becoming pointless after the verbal tree update so um i would really be against this one

Marius van der Wijden: and i totally agree with guillaume on this one

Tim Beiko: got it um anton so you have your hand up

again yeah

Anton Bukov: one more thing here i want to add uh there is a interesting example if some dex is swapping user assets it will be cheaper to return funds back to the user if swap not happened for some reason like deadline or bad rate it will be cheaper to return funds back to user to keep at least some gas refund instead of reverting whole transaction this sounds a little bit strange and ridiculous

so correct my

Micah Zoltu: correct understanding that if we don't make this change and adapts optimized then they will

optimize for the more operationally expensive choice which is to do more work is that correct and actually write data

William Morriss: that's right

Micah Zoltu: that's unfortunate um i do think that this change is correct like it is the right thing to do um but i do worry about echo oilers who said i think the complexity is high and with verbal trees um kind of doing the same thing functionally much more questionable

than one point base

Tim Beiko: so i guess yeah at the clearly there's not like consensus for

this um and like we just discussed there's a ton of other things that seem to have really high consensus for shanghai plus vertical trees um it's kind of slated uh yeah slated for after um i guess if people do want to discuss this there is a discussion to link in the eip but uh we won't be moving yet to cfi uh for for shanghai um we're already over time uh the last thing on the agenda like i mentioned the very beginning uh we do have a call next friday at this time so 1400 utc to discuss the naming of the client releases for the merge on the execution layer side if people want to join that

there's a link in the agenda and anything else anybody wanted to cover quickly before we wrap up okay um thank you very much everybody uh thanks william anton and the others for coming out to present uh eips um and we will see you in two weeks

thanks thank you see you thanks bye oh thank you right thanks everyone thank you [Music] [Music]

so [Music] [Music] [Music]

[Applause] [Music] so

so [Music] [Music] [Music] [Music]

[Music] [Music] [Music] you

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.