All Core Devs - Execution #122

Transcript

[Music] [Music] [Applause] [Music]

[Music] [Music] so

[Music] [Music] [Music]

[Music] [Music] [Music] so

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music] so

[Music] [Music] do [Music]

Marek Moraczyński: uh yeah sure so uh

all the people should upgrade our nethermine notes to 1 11 2 version and it was quite random that sometimes the on the previous version we can uh skip the validation of uh proof of work uh yeah and that is all lukas do you want to add something about it

uh what yeah

Tim Beiko: so what's the version that people should upgrade to

Łukasz Rozmej: 1.11.2

Tim Beiko: yeah okay 1.11.2 okay um awesome yeah thanks for the update so uh people please upgrade uh if you're running nethermine and in the next call or the one after uh we'll probably go into more details and the actual vulnerability itself um cool i guess first on the agenda um we have updates around the merge and interoperability between the different clients on the execution and consensus layer um mikhail do you want to just give a quick high-level overview of the the different different updates you had

Mikhail Kalinin: yeah sure thanks tim uh has been work on the

drop edition of this engine api um and i think it will be published pretty soon uh probably this day or um the early next week um matt do you think how much time do we need to do this if we assume that it's ready i mean the document it should be straightforward right sorry oh yeah we didn't really um can you repeat this first okay

i think i heard today as part of his sentence but right not 100 okay cool um a part of this uh engine api stuff uh there is a couple of updates that i would like to share here first is the [Music] proposal on using the hard-coded terminal total difficulty in both clients in the consensus client and in the execution client uh here is the link to the pull request again the beacon spec it has the is the link to the full request i've made to the eap as

well and you may go there and read for the details and duration of the hand is in general is reducing the complexity and protecting us from various such cases that could arise around implementation and usage of the dynamic total terminal total difficulty that previously uh were uh the priority had in the stack so um another thing this is a small kind of thing is the the extra data are brought back so the the deprecation of extra data fail field has been removed from the eip

and it's been added to the execution payload so it's back again and yeah the rational here is that it's useful in investigations of various incidents on the mainnet as it's the default usage for the extra data is to just express the client version which is pretty helpful so what's next here um yeah uh also in general about the merge interrupt specs um i think we will have

them and their versions settled down and published like in the middle of the next week probably early next week so stay tuned on that um yeah this is uh with regard to updates i have al also uh want to make one proposal here and to hear from client devs what they're thinking about it um this is like yeah yeah sure this is the about message ordering uh between the consensus and execution clients uh like the order of engine api calls uh to be more strict

and for for the interrupt thing uh the proposal is to um like is to use synchronous calls on the consensus client side which means that if the call is made the consensus client just waits for the response before moving forward uh with its flow of blood processing or block production or any other stuff or the folk choice uh the reason here is that it's just like the easiest way to uh to handle the message ordering stuff and i think it's reasonable to simplify this part for the interrupt and we can

further discuss uh the production ready solution for this part of the protocol and to not focus on on that just during the intro i think it's not super important uh for interrupts it's done so that's just the proposal what what do people think about it

oh

Łukasz Rozmej: sorry i something of my internet didn't hear that well you're you're mentioning changing something to synchronous which one exactly

and

Mikhail Kalinin: the consensus client will synchronously

make the engine api calls so it will send the request when went for response instead of like send one request then go to uh then get back to the like usual block process well and send in one one another request without waiting for the previous one to um to get processed and that could lead to the mess around the message ordering and some um inconsistencies if we don't have like a strict mechanism specified uh for to to pre to preserve the best the order of messages and that's just a workaround for the interrupt just temporal solution to not like get into discussion and get into

specification and implementation of any message consistency mechanism that is like more sophisticated than just some chronos calls so that's the proposal

Łukasz Rozmej: yeah so we we have this kind of ascent from new city by on the let's say in a transport layer right like you're saying but on the protocol lane they are like prepared payload get payload gives us some kind of asynchronicity and um the execute payload and then consensus validated and uh and i don't remember the last one uh also validated message would be giving us asynchronicity on the protocol

level but not on transport player level right

Mikhail Kalinin: um it depends on the transport but yeah yeah yeah right so we have this synchronicity and we want to have it but it like implies that we need to deal with the order of messages and it needs to be preserved like if you're receiving like the message about like some payload uh some child pay a the apparent payload hasn't been yet possessed that's that could be a problem

yeah this is just an example

Łukasz Rozmej: i'm totally for it so when we want test intron city we should just

implement it in the like protocol level and not on the don't rely on the transport level for that oh yeah yeah right so i i'm all for it i'm all for it

Tim Beiko: cool does anyone disagree with that oh danny you kind of came on but we didn't hear you

oh i said i

Danny Ryan: i agree that it makes sense like an iterative step get it get it right in a synchronous uh method and then layer asynchrony and where it makes

them okay

Mikhail Kalinin: i also need to need to uh like just

let yeah this this will go i mean this requirement will be exposed in the kind of merge interrupt at a stack so like the consensus client developers will have it there oh um that's pretty much it from my side

Alex Beregszaszi: okay and i guess yeah i just had one question to to make sure i it it's clear so the the decision for the the hard code the terminal total difficulty um it seemed like there was mostly

consensus on that on this card but i'm curious if anyone like feels otherwise because i as i understand it the trade-off is then you just need to put out like an extra release potentially which has that that terminal total difficulty hard-coded is that is that right

Mikhail Kalinin: um i think there there is a couple of options here um one option is to make a release with the this total difficulty um like hard coded but with some like pretty advanced uh value so uh we definitely sure that the merge fork on the beacon chain happens before

this little difficulty hits on the main net the other option is to have like a couple of releases one is to print this merge hard fork on and wait for and probably yeah and wait for the hard fork and then another one that just releases the clients with this total difficulty and while you hard coded um that's kind of two options here and and and and this and this in this second option uh actually the first release potentially not affects the execution clients right this is to this this is yet to

figure out but that might work this way so we will have like only one release as we as we used to have uh like with this dynamic total difficulty for inter for the execution class so if if it even uh reduces the complexity of uh releasing this stuff at all i mean like uh removing this one extra release from the execution client side

Tim Beiko: got it okay and yeah we don't need to necessarily decide that as we're making the change in the spec basically

Danny Ryan: the risk there the risk in doing one release is that you have to forecast total difficulty in a longer time period which could be

subject to attack or just high variance um i think i personally would take the hit and just do one release because there also is specified the manual override in the event of an attack or say terminal total difficulty just or total difficulty dropping lower and lower um or the difficulty each block tracking dropping lower and lower so it takes a really long time so there is a manual over right there which i think i prefer instead of doing two releases

got it

Marius van der Wijden: um have you thought about the the other way around that miner would speed up the block times

forge the timestamp to create a higher difficulty chain

Danny Ryan: we have discussed that uh is there is it actually practical um without can you actually spoof the network in doing so yes or would time stands like that be rejected

Marius van der Wijden: i think it would be possible

on this require what's the problem with that

Dankrad Feist: what's the problem with that then the merge happens a bit earlier so

Marius van der Wijden: um um if someone would mine their own chain

a separate chain with higher difficulty and then i don't know drop it on everyone i'm not sure

it's just a well 51 attack essentially um and won't they need like the great the bigger hashing power then you keep mine in this

Micah Zoltu: yeah it'd be a 51 attack and same as any other 51 attack where you just sensor blocks that aren't part of your 51

Danny Ryan: there's two sequences of them the beacon

chain hard forks to actually you know update the data structures to have allow for the payload and that's empty and then uh after that the control difficulty is hit and the you know the execution layer payload is inserted into the beacon chain and so the risk on an acceleration would be if they could hit thermal total difficulty prior to the actual vega chain fork because then i think the fork would end up once the fork happened the transition would happen immediately and happen on a pass block so there is like a little bit of an attack there

nice

Micah Zoltu: i say the issue here is because the beacon chain does not time its fork

based on the execution engine's total difficulty

right danny we can't hear i can hear dino that's weird i can't hear daddy oh now i can i'm going to go somewhere else in my house i think it's just tim everybody else can hear me no i can't either yeah i mean too many there um yeah

but yes i think

Tim Beiko: micah i think you're correct where the beacon chain upgrade is triggered uh by i assume uh epoch or slot number and yeah it's not triggered by the total difficulty itself

sorry correct i see

Micah Zoltu: so the real the real source of all these problems then is the fact that the beacon chain execution chain are forking on different metrics and those no matter what those metrics are they there's a possibility that they will diverge and one will happen before after the other and we need them to happen in the correct order right we can change first for any reason we can't just do the beacon chain fork months in

advance like do we need to wait until just before

yeah i mean that's

Danny Ryan: that's the that's the mikhail argument of two releases um and if you i wouldn't want to do two releases in like a two-week time stamp but if we did time it such that the big change worked months before i think that's a much more palatable to really schedule

Micah Zoltu: is there an argument against that other than just does the beacon chain actually need two releases or just be the beacon chain releases and then two months later the execution chain releases

now

Danny Ryan: they both need to know the terminal total difficulty

but i didn't shouldn't be synchronized i see

Micah Zoltu: so the beacon chain releases and then we decide the terminal total difficulty and then we need a release of both beacon or consensus and execution clients is that correct

Mikhail Kalinin: yes we'll need this if we follow this path we will need a small tweak in pikachu stack to be sure that sorry danny oh yeah yeah yeah yeah so but it's doable completely the end really straight forward um this is to my understanding in the current moment of time i haven't like

thought much about this

scenario

Micah Zoltu: is there any any um any reason we can't do the consensus clients update or fork or whatever long long in advance like let's say next week just just throwing it out there is there some reason that we need to do it some kind kind of near the actual proof stake switch or can we do it anytime prior i think it just makes the timelines longer right that would be the only reason like if you have to wait two

months then that's two months like start to the merge yeah sure but i'm saying like we could can we just do the the consensus client update now like whatever the next patch goes

well that's but isn't the

Dankrad Feist: the blocker is like setting on one spec that we're all happy with like if you do it now then in two months you might come up with some changes and like oh now it's too late

we already like i think right so once we do this sorry what was that danny

Alex Beregszaszi: i'd want to be much deeper in the engineering cycle before we would release on the beacon chain in production

right i'm not sure

that's one

Micah Zoltu: just to make sure i understand here the when this consensus clang goes out that is the start of the merge but there is not any sort of time constraint between between when this new consensus client goes out and when the execution client eventually goes out and when the hard work happens like that duration can be whatever we want it just needs to be in that order is that right

okay yeah this book

Mikhail Kalinin: both uh softwares should be tested with each other like with the they're the most recent version of each other before making

these uh releases right and i think in them oh sorry i was just gonna say

Tim Beiko: in the next couple months as we're working on

this it probably makes sense that maybe default to hard coding the total difficulty because it'll be mostly on devnets and whatnot and as we start kind of as we're further down with the spec and we start actually thinking about how to release this on mainnet i feel like we'll have a much more context about it once we've actually like implemented it in the in the happy path

Micah Zoltu: so yeah so i i agree that we shouldn't hold up devnets for this but at the same time i think we do want to test the production code paths as soon as an early as possible like i don't want to wait until the last minute to change the way we do our releases and then have like you know

it's only run on gurley or whatever we wanted every test net will see this mechanism for hard forking

um so we can just one thing

Dankrad Feist: i don't understand why are we talking about like one month to like change a single number in the execution client like it feels to me yeah i agree like cutting a new release is something difficulty difficult but not if it if the change is literally just a single number like you know exactly what you're going to release

no it's just not putting in that number

Tim Beiko: yeah it's not the it's not the time to do the release obviously that can be done in you know a day or two it's getting everybody to upgrade to the release to you know read the blog post i

do think if we wanted to go to release route we can get around that where we tell people like you know first release is out on the date x second release is out on date y so they know that they should be expecting to release but there's just the risk that like yeah every time we do releases people don't upgrade and they don't get the memo and if there's two of them you know there's just the risk that like they've updated to the first one and they're not aware that they need to upgrade again but i don't think it's any it's not a technical barrier

it's a dissimilar yeah

Dankrad Feist: but even that if you if you have made it very clear hey in the next week there will be a release that like you need to install

then what's really the percentage of people who don't get that and should they really be maintaining

ethereum nodes like i mean yeah i mean

Tim Beiko: just to give a recent example geth basically did that a few weeks ago and two major mining pools have not upgraded right

um and you know it's again it's not like an impossible problem but it is something that well like

Dankrad Feist: luckily luckily it doesn't matter if the mining fluids don't do it

in this case

Danny Ryan: i look i i agree donker that it might be the most palatable solution and you can orchestrate and make sure to communicate well but it's it's definitely a consideration and i also think that we

don't necessarily need to decide right now i do um we can we can spend a little bit of time over the next few days to think through whether the dynamic setting of terminal total difficulty can be done actually in a tractable way there was um an issue that emerged that kind of highlighted there might be a number of corner cases here so we can think through it uh and try to make sure that we definitely want to scrap it by mid next week um and then if so then we're kind of working with the static which i think is also solves a couple of other problems

what problems does static difficulty

solve uh primarily when you this donker

Alex Beregszaszi: brought this up on all core devs two weeks ago uh but if the execution engine uh if a user naively runs an execution engine and doesn't connect the beacon node and uh it was relying on being told from the beacon node the terminal difficulty and it never connected to one uh then it would literally just follow the proverbial chain forever and not like not following the transition would not show up as a failure to them even if they wanted to be following the transition whereas if there was a terminal total difficulty released in the execution engine then they would see essentially a failure at the point of the transition and not see any new blocks that would be essentially an alert that something's wrong and then

they'd figure out that they need to run their beacon node um that's the primary thing it solves other than some of the corner cases with sync that we identified a couple days ago

Micah Zoltu: didn't we come up with an alternative potential solution where we set the execution client such that if you are not connected to a consensus client by this difficulty then shut down and and just that just means like you must be connected to the network basically

Mikhail Kalinin: yeah there is also some other um [Music] some other like

details and implications of these dynamic double difficulty stuff so they are just exposed in the um issue i mean they are just described in details you can drop it the link

yeah

Micah Zoltu: someone can drop a link that'd be great i'm just at the moment it sounds like dynamic hold difficulty is the better option so i'd like to better understand what the arguments against that are it sounds like there are some and i just don't understand them

Alex Beregszaszi: yeah i would i would suggest we take it to that issue and move on

to this stuff yeah michael

Tim Beiko: already linked it in the chat so this pr 2605 on uh

on the consensus specs and that links to another issue as part of its rationale um yeah oh and then there's also pr2603 okay oh um i guess anything else on this specific topic

if

Diederik Loerakker: i opened this issue on the consensus specs repository um about transaction typing so the api and the execution layer don't change but within the consensus pack there's something we can change to be

more compatible in the future with new transaction types so if you're interested in typing then just have a look

Tim Beiko: cool and that's uh issue 2608 in the consensus specs um and then there was something uh that uh trent put in the chat before we we started um i think this is from paul from lighthouse if if that's correct but uh he was wondering if there's any uh execution team that already has the latest apis implemented yeah

basically the engine api spec

Marius van der Wijden: i have created an interface for it and i started writing a father for it but we haven't implemented it in in guest yet okay and also there were some questions regarding the interface um that we already like talked about when i implemented it

Tim Beiko: okay um anyone else have an update

or not

Gary Schulte: the same for basu we have uh the latest specs stubbed out for the moment

we're working on the implementation but we're not ready

okay and we are

Marek Moraczyński: not ready to uh in other mind we started working on the interfaces but i think we have a good progress

um yeah one another i

Mikhail Kalinin: just wanted to repeat that stay tuned we will just publish the spec person on this engine api it'll be different to the um the design dock i mean some some stuff some details but in general is the same

in the faces sweet

Tim Beiko: um yeah we'll share that in awkwardness and maybe in the announcement channels as well on the r d discord for people to follow next week um anything else on the merge before we move on

okay um if not uh we had a couple eips that people wanted to discuss uh first one was uh 37 oh sorry mikhail did you say something oh yeah i was just wondering i think yeah

Tim Beiko: oh did you have a specific question or is it just asking where the teams are at

Mikhail Kalinin: uh i was like yeah this is an agenda i'm not sure

i was just looking to get any updates there are on the specs talk your documentation on this draft design proposal

alex yeah

Tim Beiko: felix is not on the call i saw on discord that he was working on updates of the document but i i haven't seen anything published yet

Marius van der Wijden: oh yeah so uh he had some dentistry going on and so he wasn't really able to work this week he's going to finish it next week

um yeah and my question is like

yeah

Mikhail Kalinin: is there a plans uh of the client developers to implement the sync for the interrupt and um yeah you have capacities for that like who's planning to do this

Martin Holst Swende: from guest's perspective picture is as far as i know uh implementing that but in order to do it he is the yeah doing some major refactorings that are needed uh before you can really get started on the new stuff do you that's my question mario is there

the same impression

Marius van der Wijden: yeah so we need to implement some other stuff before we can start it with it and uh but peter is is doing that right now i'm not sure if we if we can actually make it until the merge until until the interrupt but we should until the merge probably but uh until the interrupt but we should have at least some some beta version that we can try

hopefully yeah sounds good yeah hopefully

Alex Beregszaszi: maybe at the beginning of october we can

there will be enough r d done that we can make better decisions about communication protocols and that kind of stuff at that point

Tim Beiko: and i guess one thing that's just worth mentioning i saw peter say this week is uh as part of these refactors within geth uh to support kind of merge sync um fassync is considering is considered being dropped um so if you're a get user running fastsync you should probably switch to snapsync uh going forward i don't know marius or martin if that's roughly right

Martin Holst Swende: uh well there's nothing really from a user perspective that

you need to do

and

Tim Beiko: okay it'll just stop being available

yeah i mean at some point there will be no notes that serve get no date on the network and if you then use an old guest version and try to pass things you're going to be start at some point in the future

Łukasz Rozmej: uh by dropping fast sync do you mean dropping get no data yes that would affect never mind ability to think somewhat because we are still using that

Mikhail Kalinin: so if we don't have a concrete

pr um it's more of something that has been checked around a bit and yeah sooner or later it's going to be dropped and it's yeah it's been in the wind for a long time but at some point

it's going to be dropped and we're not i mean we're moving yeah

Łukasz Rozmej: it's understandable that [Music] it's not scaling extremely well so we are planning uh either to implement snapsync or either to go move to

more like arrigon style um i'm more in favor implementing snapsync but with everything going on with the merge etc we haven't managed to do that yet

Tim Beiko: yeah so please kind of keep an eye out for the announcements on that and yeah every client and i guess infrastructure or user should be moving over to moving away from fasting at the very least

Marius van der Wijden: and just for the people listening in uh snapsync is way faster than fastsync it is uh

way faster and takes way less bandwidth and it's uh in all aspects period to it except in name

so

Tim Beiko: cool anything else on the merge

Guillaume Ballet: just a quick question for martin do you know if we have merged gary's pr about the transition process because that's gonna be necessary too

Mikhail Kalinin: i don't know sorry

okay well we need to check that cool

um okay uh so yeah next up uh light

Tim Beiko: client wanted to give an update on eip 3756 so the gas limit cap uh yeah

that's kind

Lightclient: can you hear me okay

Tim Beiko: yes

great

Lightclient: um yeah we presented this at the last all cordless didn't have a lot of time to discuss it so just to briefly reiterate the gas limit cap um it's motivated by uh putting it upper bound on what the gas limits can be set to by block proposers uh in the benign case high gas limits can increase the size of the state in

history faster than we could sustain the malicious case it amplifies attacks on clients in the past this hasn't really been a significant issue because miners have worked pretty diligently with all core devs to set gas limits but they've shown in the last few months that they are potentially willing to be incentivized to increase limits beyond what may be considered safe so this is a eip proposal to set up our bound on that limit is there any feedback on this

Mikhail Kalinin: well i know there are some people who are heavily opposed to this um

yeah so i'd like to hear the cons from those people or general thoughts

Micah Zoltu: i can give some the cons the primary one is that it means that all core devs will have to actually come to consensus on a gas limit the upper bound previously we have kind of been able to shrug off having to make that decision um if we make this change we will now have to officially make that decision as a group and the that then leads to we need to then decide what is an acceptable rate of state state growth and there is a huge amount of diversity amongst client

devs for what is reasonable in terms of state growth and there's also you know disagreement on just execution time per block on what's reasonable there so i think the biggest con here is that we will be taking something that currently we can kind of ignore or at least have plausible deniability of and we're taking turning into something that now we have to actually talk about and agree on and a very very hard decision

Dankrad Feist: well i think actually that all chord has to be fired making the decision my concern would be that it takes much longer like how long does it reason like take from an all core def decision like will it take an eap every time which take what at least half a year or

something

Micah Zoltu: yeah so when we want to change increase it we wouldn't do any if if this eip passes and we want to presumably would have some default i'm guessing 30 million um it's reasonable default if we wanted then change it later to something bigger so 45 million or whatever then we would need to have an eip and then wait for the next hard fork and get included in a hard fork

Dankrad Feist: i think that was an idea to make it automatically increase according to moore's law or something like that i think that would be a better idea

of all of it uh yeah so i mean there's definitely so good

oh yeah i didn't mean to interrupt but

Martin Holst Swende: my question is basically is this eep uh is the motivation for it is that we think that before the merge uh miners are going to be like not have the long view on ethereum and they just load the statement uh yolo in the last time they have or is this is the is the motivation more longer than that is it do you do you think that even in the future when we're after the merge um that this is going to be needed or wanted or desirable

i

Alex Beregszaszi: i think

that if those tokenomics work and that the the the hype around collecting tokens is around when staking's around that stakers could easily be motivated as well to abuse the limit um there's maybe a bit of counteraction there because they have a longer term view uh but i think a lot of them have machines that can easily run 40 million instead of 30 million and and would do so at the the cost of others but i i don't know i can't speak for all the stickers but i think the the incentives are still there even if you have you know a four-year time horizon instead of a one but i think that's because there don't know all of the uh issues

there

Micah Zoltu: so i think even with the if the incentives were aligned we still have the problem of education where the people who are stakers aren't necessarily the same people who have a very very deep understanding of the pros and cons of higher gas limits everybody most people i talk to who are not core devs um seemed and even a lot of gourd devs uh have a belief that you know state growth is not a problem um yet you know there are definitely core devs me very much included who believe state growth is a major problem and so if group stickers be it might be someone else token voting whatever even if they are altruistic it doesn't

mean they're well informed and so if we do decide to go that route we would need to make sure we have some mechanism of ensuring those people are in fact well informed and educating them which is again a hard problem like i think all the options here are hard problems to answer martin's question though i i do think that whatever rule we applied to to minors we should probably similarly apply um two stakers i think their incentive structures are are similar there is slightly longer time horizon as danny mentioned um but it's not that much

longer like the state growth problem some aspects of the state growth problem are on time horizons that are you know multi-years and if you take out in three months then you might not care about the state of ethereum in three years whereas if you just let block grow state growth grow indefinitely and we don't mitigate it effectively um you know three years maybe when we really start paying for it

Ansgar Dietrichs: um yeah enscar just wanted to briefly point out that with this eap i think this there would still be like a lot of room in how to how to use it right so because like say we say we set the upper limit at 30 million that would actually basically be a recommendation of like

going with 30 million unless we have technical issues where we temporarily reduce it or something one alternative could also be to even like today set it at like say 40 million 50 million something like that where like we don't recommend people to actually go that far but it's like this is the limit where we still consider the network technically safe or something right and in that circumstance where we usually expect not to be at the limit um this kind of change would be much less invasive um while still giving like at least some upper bound so there's no limitless uh like potential for or for catastrophe

any sense

Tim Beiko: right and then it becomes more of a communication than technical

challenge right like saying we allow 40 million but please don't use 40 million

um yeah

Micah Zoltu: um i think as a kind of shelling point 30 million is a reasonable start um but i just just to give everybody a fair warning i will argue too lower from that i personally think the 30 million is too high for a number of reasons

Alex Beregszaszi: i have a question uh has is there any update on the usage of egl has there been voting has there been

movement

Lightclient: i haven't followed the voting as much but i've looked at the mining pools that are still using it it looks like two smaller pools are um still sweeping rewards flex pool and b pool f2 pool was doing it in the beginning and it looks like this didn't sweep for rewards for a pretty long time but i saw that they did sweep rewards a few days ago so it's not clear exactly what their involvement still is but there are two small mining pools that are actively sweeping rewards

Tim Beiko: and another i guess thing that's worth mentioning is the gas limit is still 30 million right um yeah so so yeah it's it's

not currently being pushed upwards um but obviously that could that could change

is anyone from aragon on the call

Andrew Ashikhmin: um yeah it's me andrew well i i think our position is the same as uh before that we are not in favor of this eep but if like the majority decides that we are going through with this heap then we are not going to fight uh and we are not going to die on that hill

oh hensgaard yeah another question that would be is like if we were to move forward with this eap with the plan b to basically have it ready for the feature fork after the merge or with the plan b to basically bundle up the merge with basically as like the one exception to the rule of not having features as part of the merge just so in case we needed earlier it would already be implemented and ready for like a short notice emergency fork i mean again with understanding that you probably wouldn't do that unless it would start being a problem

Lightclient: i think the question is more are we trying to put it in shanghai or are we trying to do a soft fort before shanghai

Alex Beregszaszi: right and knowing we also need to update

upgrade uh in december because of the difficulty bomb right um yeah um marius you have your hand up

Marius van der Wijden: yeah i would i would oppose moving this into the into shanghai or like the next fork or the just because i think we should really keep the fork uh the the the fork is as clean as possible and if we were to include an erp it has to be like a hard consensus critical eap and i don't think that this eap is [Applause]

[Music] is security critical enough to do that so i'm i'm in favor of the eap but i don't i i think i would want to have the fork in november be as small as possible and if we were to need something that it would need to be security critical at this point and not right something that may be uh introduced in the future or something

maybe

Tim Beiko: i guess on that note like it might be helpful to understand from client devs like how how much work would it be to activate this as a soft fork so say that you know two weeks from now we have a call and the block limit is up to you know 40

million because either because of miners moving it up or egl moving it up or whatever other reason and and and it's felt that that's unsafe um how given this is like a minimal change how quickly can you know this be deployed is it a matter of like weeks

Martin Holst Swende: um so how do you mean deploying it

doesn't work really because the soft fork is a minority fork and it becomes um bad yeah

Alex Beregszaszi: you still need to coordinate and get everyone to upgrade especially if

it's if if you picked a hundred million and you know we were nowhere near it maybe you could argue doing a soft work and it just like takes time for it to ripple out but i yeah you still need to coordinate like it's a hard fork in my opinion

Lightclient: the only benefit is i don't think you have to coordinate all of the user clients it's more of the hashing power right

well

Alex Beregszaszi: the user clients are the the the power against the hashing power you know software

yeah

Dankrad Feist: the hashing power might not want the fork so you need the users to upgrade to enforce it

yeah

Alex Beregszaszi: like users exchanges etc yeah and i guess so given that and given that

basically you know we need to have a fork we have the fork in november then we have the merge um is this something that would be easy to like how how much lead time would we need to add this to the november fork if we wanted to right like is this something basically is this something that we'll need to deploy across all of the

test nets

Martin Holst Swende: um yeah it's pretty trivial to change yeah i guess that was what you were getting at

and yeah yeah this is the simple thing yeah because in that case can we and basically kind of following off uh

marius's

Tim Beiko: comments around you know keeping the the merge as lean as possible is this something that we can have a spec for that's kind of ready to implement and if you know we see an issue we can combine it with either basically the november fork or the merge

Mikhail Kalinin: um yeah yeah we can have it in the back pocket as a if if we have to and not otherwise uh schedule it as part of the shanghai that's possible

Alex Beregszaszi: i do want to mention and i apologize this is actually in the in the spec there but i i think it's

implied to me that it wasn't because software um if the gas limit uh on mainnet is already above the target that we'd want to select that you would actually need some sort of hard fork to discreetly uh change it to that to that point is that already

covering the eip i apologize for this it's not this is the main technical questions okay sure so that we could also make the

Dankrad Feist: soft fork so that it only accepts downwards when they're sure yeah when the limit is currently above so that would be

assault there's this additional importance yeah i guess

Tim Beiko: but yeah i do think that would be worth specking kind of in advance

Alex Beregszaszi: yeah i mean if it's a react if we want to keep in

our back pocket as a reaction to an attack then we we need to have what the reaction is because we have to assume that it's going to be above our target already

yes

Tim Beiko: so i guess does that generally make sense to everyone as a next step not kind of you know include this in any upgrade right now spec out what the transition mechanism would look like to adjust the downward um and yeah have this in case we need it either in november or around the merge

Lightclient: i didn't quite understand the exact argument against bundling this in shanghai

Alex Beregszaszi: i think there's not a lot of consensus

i think people feel a bit mixed about it

so as i guess yeah

Tim Beiko: as i understand it there is uh you know wanting to keep the shanghai you know lean um wanting like i guess some chord ads obviously being opposed to it and um needing to come up with an actual value for it which i guess we could default to 30 million um but yeah those seem to be like the three

Lightclient: my view is there's not never really a good time exactly to do some of these things and

if we don't do it in shanghai it's already simple change there's not anything in shanghai already we're not gonna do it during the merge or likely not going to do it after the merge because there's a lot of other things to do and so then it's going to be sitting around for a while and the attack factor isn't going away it's not clear how important is for the security of the chain but from my point of view it seems like shanghai is a good time to do it

Tim Beiko: right um yeah i guess

one thing i i don't know like i know there's also other kind of eips on the agenda today that people wanted to discuss for shanghai and yeah i it does kind of feel like we had this consensus earlier to only focus on the merge at the verities until we have devnets up for the merge um and and you know we're far enough in the implementations and then kind of make decisions around you know what we do in in november based on on how much bandwidth we have um yeah so i think that i don't the the big concern i have is that um

it kind of sets a precedent where we you know move away from just being focused on the merge to starting to work on this and potentially other things um when we don't yet have the merge you know devnets set up and we don't have a good feel for like how much work is left to do um on that yeah i don't know if what other client teams or developers yeah what are your thoughts

Mikhail Kalinin: yeah i kind of agree i i must want to focus on the merge now and not

have as much other features

i don't want to think about and i do think i don't the ex from what i'm getting

Tim Beiko: the exception to that would be if we do see you know the gas limit being raised to like levels we consider unsafe on main net having this already specked out you know like it would basically increase the um the urgency that we need this with and having it already specced out would be valuable um but assuming the kind of urgency for it stays the same it seems like it it just might be better to focus on the merge exclusively until um until we're at least farther along with the implementation of it

the

Micah Zoltu: this it feels like if we want to go down that path we then need to get come to some sort of agreement on what a dangerous level is i believe there are some core devs who believe 30 million is a dangerous level already due to some known eos vectors against certain clients um like is 31 million safe 39 40 45 70 like like if we're going to say if right people range of increase in dangerous levels then we will do an emergency fork that means we need to define in advance i believe what an emergency or what the danger bull is and so we still have to solve that part of the problem even if we go down this path

unless we're just saying if the miners raise it above 30 million then we emergency fork

yeah i i don't know yeah

Tim Beiko: it seems to me like that's kind of the i don't know implicit consensus already where like we have this limit and we sort of agreed to it around um around uh london um yeah so if it went like you know significantly above that but yeah i'm curious what what others think

uh yeah i don't think we necessarily mean if our stance is

if this gives us problems then we might have to roll up with e i don't think we need to try and extract what is if we have it we will be able to say yeah this is this is not good this is that but then i'm thinking most from the last perspective [Music] [Music]

Tim Beiko: your mic i think yeah was was not great uh martin i think what i got was that we can't really define like a specific number now that if this becomes a problem like in the future we can we we can have a fork for it but i don't know if yeah if you want to maybe fix your mic it was a bit uh low there

okay is it a difference yeah this is clearer

Mikhail Kalinin: oh sorry um well from a denial of service perspective um i don't think we need to pre-define what would be a problem or how a problem would look like because

we would notice if we become better by denial of service tax but from a state growth perspective if that is the concern um then i'm not sure yeah exactly that how to define what are dangerous levels of state growth and what are okay levels of state growth

i have no idea uh asgar

Ansgar Dietrichs: yeah i'd personally be in favor of um at least stating clearly or trying to come to an agreement clearly that we would kind of like reconsider

participation in egl um to raise the gas limit kind of illegitimate and like even if we wouldn't immediately act right because there's definitely some room above 30 million where it wouldn't immediately become problematic in any sense but just because this is like a slip slippery slope situation where maybe 32 million is still okay for state growth and maybe 33 years but maybe 34 isn't or something right and like just because if we signal ambivalence i think a lot of miners will be much more interested in the future to kind of be involved there and i think i think at least basically stating very clearly that we would very much expect them to not participate and not raise raise at about 30 million and if they do we basically will likely do something about

it even if like there's probably some room where if it's only a little bit we might just not bother to to like to look into it or something but but i feel like if we if we basically know that there's some some room before we go back then that does implicitly just like make it an endorsement i think in a sense so i think that's the interest

Tim Beiko: i'm fine plus wanting that i don't know about others like i don't want to speak on behalf of everyone

Lightclient: i'm fine moving on to the next things in the call i'm still

of the mindset that i would like to see it in shanghai but i understand it seems like that's the minority view

Tim Beiko: any other thoughts okay um of course so moving on um alex had two eips um that uh he wanted to discuss one is eap 38 55 which is that push zero instruction and then the other one is eip 3680

limit meter and init code alex you want to give a quick overview of them

Alex Beregszaszi: um yeah yeah i will given the word you have to put zero and the pavel about the unit code so the init the pus zero is um it's a very simple one it just introduces a new instruction which which is the constant zero onto the stack um and this is um specified in a way that it can actually be implemented um in the same place where the rest of the pushes are implemented um because um most of the evms implemented such that um

they just have the starting um of code and and the current top code and they just subtract it so they know how many bytes to read in case of put zero they don't need to read anything um so that's on the technical side and and then regarding the demotivation um i think the eip does a pretty good job explaining the motivation and i will try to replicate it here but probably i won't be as good as you know what we put into writing but basically there are a lot of cases uh where someone needs to push zero into the stack a good example is calls since return data has been introduced

quite a few years ago many of the calls would just end up with at least two zeros at the very end which would be the the pointer and size for the return memory because people are not using that anymore they'd rather use the explicit return data of code to retrieve the data so that's one good example to see where the zeros are used but there are many more cases and the the problem we have seen so we we have been motivated by looking at actual byte code on the network as well as um talking to solidity and and some challenges they face in this regard so basically pushing a zero can be done

at least um it can be done in many different ways one one way is just with the push instruction which means um that is two bytes and it costs three gas um but one can can also use a dupe if in case it was already on the stack that also caused free gas and these are like the the clean and nice ways to do it but people are always looking at to save gas so there are certain other instructions which in certain cases can return zero so one example is uh return data size in case there has been no return data it would be zero call this call data size is the same and plenty of others are listed in the ip so in many cases contracts and and people start to use

these just in order to save gas because some of these only cost two gas at run time and the only one byte and so they're cheaper to deploy and the one problem we have seen with this is this kind of puts us in a position that certain changes would be harder to do one example was the transaction packages which would change the behavior of return data size so that's one reason uh why why this um is this optimization is like a bad direction for for many people to go and another reason is um is what what's happening in solidity the team is looking for i like that the need code generator to to have like a nice way to to push like

a known uh unknown value in the cheapest possible way and they don't really want to um go to the extent to to try to use these other instructions and then lastly we also did an analysis on how much gas has been wasted on ontis and we only looked at all the bytecode deployed and how many push one zero uh instructions they had so which is like the sixty zero zero in hex and according to that it seems that um i think like 60 billion gas let me just check it quickly yeah 68 billion gas has been wasted so

far on deploying such code so that's the long motivation

Tim Beiko: that's a lot of gas um does anyone have thoughts comments on this

Martin Holst Swende: cute deep i don't think it's like i mean like a lot of these that touches something about the evm and it's nice and not terribly difficult to implement but neither is it

screamingly important so yeah i'm kind of in favor of it but i'm not yeah i'm not i'm not widely in favor i think that's something lukewarm

right

Lightclient: i feel like this is hard because there's lots of small changes that slowly improve the evm and none of them are necessary screaming this needs to immediately go in and so how do we how do we like you know have a at a higher level drive the protocol to improving evm

Tim Beiko: right i think this is you know kind of the higher level conversation where we have these things like say the merge which is obviously very important and you know after the merge uh there's going to be other like kind of pretty important things to do in the protocol um and you know i i it does feel like we have like a pretty strong consensus about not doing any any changes before the merge but um yeah i i think not necessarily today but we need to figure out how do we keep making these improvements to the evm and you know this is not the only one there's uh you know alex has proposed eip 3540 which was very popular there's been 3074

which also had like a lot of community support

um yeah yeah

Martin Holst Swende: but in the end i mean i'm i'm in favor of it and i wouldn't mind including this in a future work because it's so easy to implement and easy to test knows i mean there are no corner cases to to screw up on

basically yeah um your comment was just intuitively the margin

Dankrad Feist: the marginal value of this field's very low like i am really surprised somehow like just reserving even one op code for this seems uh seems a lot

just to save one

bite uh yes

Andrew Ashikhmin: so from my point of view i'm in favor of this deep i have a suggestion maybe when we can create um uh tentatively uh placeholder for uh hot fork after the merge so and we can tentatively approve eeps that can go into the next postmatch uh fork

what do you think

Tim Beiko: right i think that generally makes sense it feels like it's maybe a bit early for that just because we're again like at the very beginning of implementing the merge

um but i don't know yeah i i do agree that like when when we're we're gonna start you know having the merge implemented it makes sense to look at what's after and we already have like a pretty long list of proposals um you know i mentioned a couple and they're all i've like purposefully left them all open in the ethereum pm repo so we have like a pretty long list of ones that um basically all asked for shanghai and i think we have consensus that like assuming you know what we the fork in november to move back the difficulty bomb is called shanghai um it seems like we don't want to add any other features to that but uh we have a lot of features that like are valuable that we want to

do after the merge um yeah i i'm just not sure what's like the right time to start discussing that it feels like it's probably a bit early but we probably don't want to uh to wait super long either um i guess uh alex to give a quick summary because you dropped off it seems like people are like you know weekly in favor of the proposal um it seems like we don't want to do it before the merge and it seems like there's also a desire to start thinking more deeply about what

we want to do after the merge given this and all the other proposals that are pending um else on the cip okay um the next one then was

eip 3860

Paweł Bylica: uh hi yeah i powered here i i should take care of this one um so uh so this ap mostly limits uh add some

limits to the init code size and additional cost to it and just like quick background before evm can execute any code it needs to do drumless analysis of of the code and this cost of of this analysis is doesn't it's not directly reflected in in any in anywhere um and this is uh partly limited by by two factors um first one the the call or create cost is quite high so the kind of uh limits limit the attack vector and also deployed code has size limit

so analysis of the deployed code is at least capped by the bytes limit and for init code uh there's no limit so this is unbounded and the sizes can be in in megabytes in in practice i mean in like attacking uh attacking uh scenarios um so previously there was like a previous version of this this concept eip at 2677 which only uh introduces the the size limit for init code and uh at some point we realized that uh currently in create two days this is the

precedence for for charging additional gas for init code size which is related to the the requirement of hashing the unit code and we want to uh include the similar uh similar mechanism for image code in general um so this eap proposes charging 2 to gas per unit code word size uh for reference create to already charge you six gas for that um so that would be increased to eight and for create uh like regular create uh the cost should be two and the costs were

were taken from from the performance of of uh current graph implementation of the the jump this analysis it's uh in our opinion it's quite quite low um so um yeah that's that's mostly the the description of the

ap

Tim Beiko: thanks um oh martin

oh um yes so uh yeah i'm

Martin Holst Swende: i'm one of the

co-authors so always got in favor but what i wanted to add was i've been basically wanting to have something like this for a number of years um that's why i wrote the limitation of unit code earlier that one is a bit of a hack and i think it's it's not great and this is more rigorous it actually adds a linear cost which yeah which is proper because it is i think it is currently a denial of service detector against ethereum which we should fix and we should have fixed

it a couple years ago but yeah we're here now that's it

Tim Beiko: thanks for sharing um i'm curious anyone else have thoughts on this

well it

Diederik Loerakker: might actually relate to the merge where in the merge we have this consensus type to describe a transaction which has a maximum size so i suppose that you just want these kind of bounds on transactions as well as in its code in internal transactions and basically everywhere have like a proper

bond

Tim Beiko: right so

i guess i don't know martin and paolo are you proposing this should be coupled with the merge

just uh so i yeah i just first

Paweł Bylica: i want to confirm it's like i i don't know the other thing mentioned but i think it should work more or less the same so there might be some coordination if that's required it's also the ap also applies uh the cup on the transaction if i recall correctly and for internal calls um uh yeah and in terms of when it should happen i actually don't have strong opinions about that i don't think it's my job to decide this but i think i will leave to others

Tim Beiko: um yeah does anyone else have thoughts on this i guess just because oh marius i see you're off mute did you want to add

something yeah

Marius van der Wijden: yeah um probably a bit unfair because i'm also in the guest team but i would also like to have this in as soon as possible um one thing we might need to look at is the increase in gas cost to 2 [Music] gas i know that some some clients are way worse in their jump test analysis so it might make sense to increase the

uh the gas cost even more but i think like the limitation of init code size is a no brainer for me i think that should go in either way and the gas cost increase [Music] should go

into

Tim Beiko: so i guess it it does seem like i don't know the get team given i guess martin is an author and and the authors are like most familiar with this does it make sense to just kind of give everybody two weeks to familiarize themselves with this and see what i guess all the client team's thoughts are about including this alongside the merge um

i did like the idea of like no having your president that we don't accept something into an upgrade on the same call it's proposed just to make sure people have time um yeah exec you have your head up

Alex Beregszaszi: i was wondering why why should this uh go in with the merchant and maybe not before so like in shanghai just to reduce the scope of the merge

Tim Beiko: oh good point um i suspect i guess one reason i can think of and plea please let me know um if if this is wrong um is if uh if we include this in the merge we're gonna have test nets for the merge regardless

if shanghai is just a difficulty bomb pushback uh we don't need to deploy that across all the test nets so that's one reason i can think of but um yeah i you know there might be others and yeah i guess there's a comment by a light client um about like adding 3680 is bigger than obviously the two other eips we discussed um and it seems i guess from what i'm getting is like the get team feels there's like this kind of security risk and proto-mentioned there might be just a better um

i guess interaction with how the beacon chain is already set up um yeah so that seems to be the rationale

Lightclient: i guess my understanding of the pushback against the other two simpler heaps is that if we wanted to have shanghai not have any features the um the initial energy required to have other features in the fork was great enough to not include these like relatively simple eeps but if people want to do 30 uh 3860 then there has to be effort put into building out the tests then it seems like the marginal cost of also adding one or two of these other eeps is

incredibly small because the decision has already been made to have features into the fork is that a misunderstanding

Tim Beiko: but are you are you referring to shanghai

Lightclient: uh shanghai or the merge right i am personally uh fairly opposed to including anything in the merge that doesn't need to absolutely go in but i'm specifically curious

question hi yeah what am i understanding again sorry go ahead maris

Marius van der Wijden: i would also be opposed to putting this in the merge i i was thinking about shanghai for for for this

okay

Tim Beiko: got it sorry so i got that wrong um i do think in that case yeah your argument is probably

um good uh like science we're like um yeah it if we are gonna set up infrastructure for shanghai with this then it basically becomes a proper feature fork and we need testing and we need to deploy across the test nets and whatnot and that's um yeah that's like a much bigger overhead

Lightclient: is that other people's understanding

uh yeah i guess oh alex

but

Alex Beregszaszi: are you saying that for the difficulty bomb you wouldn't even set up a test net just launch it as it is

the difficulty bomb update

Tim Beiko: i think that's what we did in the past but i i might be wrong there but i think from your glacier we didn't set up a test net right because none of the test nets have difficulty bombs uh so we obviously we would had we would add reference tests but i don't think we would spin up a

test right or rather yeah

Martin Holst Swende: they don't have proof of work

so yeah

Tim Beiko: yeah so i think this is kind of the big the big difference is if we just push

back the difficulty bomb it's something we can only release for mainnet and literally not have an upgrade on on test nets um and then if we do have anything else um we need to be on the test nets and that also implies that kind of the work has to be done much sooner because say we wanted to fork mainnet mid-november with the difficulty mom um that means that like at least a month before ideally we fork the test nets so that's like mid-october um and that basically means you want releases out you would want releases out for clients in like two weeks um like early october um and that just seems kind of unrealistic

time wise um yeah so i'm not sure i don't know i i i struggled to see how we would put anything in shanghai at this point which is not uh which has to go through a full test net deployment um and one thing i can do in the next two weeks is i can just double check the difficulty bomb calculations and whatnot um you know to see if anything has changed but as i understand it it's supposed to go off you know early december um and i think no one wanted to fork like around uh the holidays so it's like yeah as i understand it today kind of the latest we could have a main net upgrade

is december that means like november is the latest we're done with with test nets and that means on october we basically need fully tested releases out and that's like two weeks from now

Lightclient: are people strongly in favor of trying to

put 30 80 uh 3860 in shanghai yeah

just for yeah i would be strongly in favor of including this i would be curious to hear from visa and other mind what they feel about the unit code and it costs that so we never mind recently optimize

Łukasz Rozmej: it a bit uh looking at the guest code so um i would say we are in case of like vulnerabilities more or less at the same level of course there's some maybe run time overhead or something but uh generally um i agree that this probably needs to be done but i don't have that

i wasn't the one doing the analysis so i don't have that strong opinion

so we are right now running

Tim Beiko: any other thoughts

i

Marius van der Wijden: i would i would say it's crucially important to do this and not only because of the current clients but also because of uh some other clients

so

Lightclient: what does the timeline look like to make this happen than if we want to do this

in shanghai

i think we would need like we're already at time today

Tim Beiko: i think we would need to be like 100 in agreement on the next call and that's like the absolute latest we could do it um i can kind of i i can look into you know into what like with the difficulty bomb and and whatnot what it would look like um but yeah that's my understanding is like we can't really go past next call to make a decision on that because then it'll be mid-october um and that just seems way too late

Lightclient: is it possible to make a decision now

or do we really want to wait or you know make a decision in one week rather than two

Marius van der Wijden: um i don't think we should make a decision now i think that's too early and said president okay um i think every client team that wants it um that's in favor of it should implement it until next week and uh then maybe have some discussions over or call the oral code of channel or something i don't really want to have another record of meeting next week because i think it's also bad if we have them every week

Tim Beiko: yeah and i think the fact that these proposals are also kind of new um i'd be i'm like less inclined to have like an off schedule meeting where we just put them in and you know uh yeah i i do think like people watch these calls they read the notes the notes take a couple of days to come out so i yeah i i think there's value in like discussing it on the discord over the next two weeks but uh and yeah teams who think this is really important having at least a preliminary implementation and um yeah we can we can make a call on on the next awkward devs um we're okay oh sorry yeah oh i was just agreeing okay yeah we're

already at time um i guess um a couple just announcements uh before we wrap up uh get put out a postmortem on the split that happened uh when they they basically announced that there was a vulnerability that they'd patch uh this is linked in the alcohol devs agenda you can read it there um there's two other or i guess there's three other kind of eips uh we didn't have time to discuss um that are not urgent um if people want to have a look async those are also linked in the agenda um yeah that's pretty much it so thanks everyone

Diederik Loerakker: thanks

Łukasz Rozmej: thank you thanks

Danny Ryan: thanks bye

[Music] [Music] so

[Music] so [Music] [Music]

[Applause] [Music] so

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

[Music] [Music] [Music] so

[Music] [Music] [Music]

so [Music] foreign

[Music]

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