All Core Devs - Execution #153

Transcript

[Music] foreign [Applause] thank you

Tim Beiko: good morning everyone uh this is all core devs execution layer now number 153 um a couple things to cover today uh so first uh obviously updates uh for Shanghai so testing devnets and then there were some updates on uh the withdrawal route and and how the withdrawals would be represented in terms of units uh on the El I'm pretty sure we got all of those details uh agreed upon but just want to make sure we go over them then um uh there was this interesting VIP around uh announcing your deprecation for self-destruct uh that

sort of covering uh and then a couple more things so last call uh or two calls ago uh we made the last call sorry we made the decision to remove uh eof from from Shanghai itself it wasn't clear if we wanted to make it cfied for for Cancun already uh some client teams had had signaled that yes but we we couldn't get everyone um to to agree um that I had a proposal for how we should actually go about organizing uh the next upgrade and then a couple announcements and that will be it um but I guess to kick us off uh I see Perry Barnabas you're both on the call do either of you want to give an update on uh Shanghai devnets and where we're

at there

Barnabas Busa: yeah sure uh I'm not sure if you can hear me well yep uh so last week we have uh deprecated develop two and launched that nut tree uh definitely is currently running and we have a starting pitch for it and I posted in the chat everything seems registered now included all uh Sia and El teams and everyone is able to use the gray instead of the way conversion so that's very good nice another quick update I would like to begin devnet 4 next week sometime midweek and for we

would need all current teams all theater playing things to have the BLS pools uh implemented and working uh so that each client team could actually post BLS update before capella to their local pool and hopefully it was a bit once a couple of hits and it would also be a larger test with about 500 or 600 000 milliliters so we can actually test diversity scenario with 310 or 330 000 editors a key change before capella

Tim Beiko: nice

Danny Ryan: and on devnet 3 are we also sending

exits as well to get those

withdrawals coming through yep cool uh it just takes a long time I just figured to exits uh this morning but uh I'm using the mainnet uh stats or demand that uh settings on it and the minute settings are quite so okay so

Danny Ryan: gotcha and in terms of like doing any of that manual testing sometimes it's good to send exits and let them get fully exited and withdrawable before doing a BLS change because that does a slightly different code path

Barnabas Busa: oh yeah that that will be done in previous

definite story all right cool nice thank you and just from myself

Parithosh Jayanthi: yeah so just to follow up with fun

business updates um also I had a shadow Fork earlier today uh we used the same config same sorry the same client versions and the same spec versions as we had on devnet3 um all client pairs were perfectly fine um the only one that I wasn't able to get working yet was uh aircon but purely because it didn't sink in time and we want to make sure we have an update for the call but I will try out ericon later on and give an update on that we also tried the BLS changes there and I did trigger withdrawal both look good we've also set up nodes to do a main nut Shadow fork and the plan is to have the midnight Shadow Fork on Monday and yeah we're going to use the same configs as

we have this week so yeah that's I think the updates on the shadowfox side and we I I posted a message yesterday about uh on the interrupt Channel about delaying the public test net until after the Shadow Focus done so that we can focus on um bugs during the interrupt time and not focus on user support as mentioned by Paul

Tim Beiko: great and just just to clarify the shadow Fork uh today was on Gordy right

uh it wasn't simple yeah okay interesting

Tim Beiko: nice any other testing your development updates from the client teams okay

um then I guess we already sort of touched on this uh and then we briefly covered it on this on the CL call I believe but um uh we made a change uh in both uh the execution API in on uh the withdrawal EIP to use gray as the unit of account for uh withdrawals to match the CL Alex had two uh PRS to this um so pr354 on the engine API 6325 on the EIP um it seems like our client teams have implemented this already I don't know I'd like to see maybe what is there anything to add Beyond this

Alex Stokes: I don't know if there is uh there's a

pretty simple change just use units of gray and yeah I think all the clients I know all of the clients have implemented the code and yeah it sounds like it's even on uh test net already so I think we're pretty good here there is uh one other PR for the the deeper change to have withdrawals be sort of full SSC uh but yeah that's something people can look at but I think should be a feature conversation

Tim Beiko: okay and just to clarify where did we land with the actual route so we're using guay on the Yale right now but we're still encoding it with RL pure are we encoding just the withdrawal route

with SSD to match the CL

root

Alex Stokes: uh yeah I still use an rlp so it's we just changed the units of the amount

Tim Beiko: got it and my my read was we don't want to do more than that because uh of Shanghai being pretty much done

Micah Zoltu: uh that doesn't align at all with whatever this call last week I thought we were going to get some specs out so we had something more concrete to talk about today and then we're gonna make a change today because there's a lot of disagreement last week right

Lightclient: some specs for the way to way a change which they did do specs for that and specs

score

Danny Ryan: yeah it

was to do specs for both the conversation was heavily leaning towards gray only my interpretation but to at least like voice uh based on the complexity of the SSC specs and people thinking about it a week yeah um my read is to not do it but I'm uh given you know the conversation of last week but I am very open to hearing other people's input at this point

Tim Beiko: yeah and Alex actually had a draft PR for this as well I'm not sure how final it is I just posted it in the chat so I guess does anyone on like the El side feel strongly we should go that route and make the change to

SSD

Łukasz Rozmej: I have a question are we talking only

about changing the route or anything else too

I'm only the root I believe yes

Łukasz Rozmej: okay so we in never mind we're experimenting with generating the the root and I think Marek had success today with actually um being able to uh generate the route from our uh SSD Library correctly

Marek Moraczyński: yeah so uh we get the same results like ethereum JS and some uh consensus reference tests so we are a bit more confident about our library now than we were a week before but still if we want

to change something I would change only withdraus fruit and do not touch transactional receipts root uh yeah

Tim Beiko: yeah I think everyone was pretty much on the same page did not change anything beyond the withdrawals route if we were to change anything um and even that I think there was some concerns to make the change kind of this late in the process but on the other hand if we don't uh okay most people sorry Micah uh yeah on the other hand if if we uh if we don't use SSD right now then we're going to have to change it in the future

but realistically everything else is also

going to change yeah uh sorry speaking for the tmgs we are ready to move to SSG route for withdrawal

Tim Beiko: so I guess yeah there's comments in the chat about like not changing anything unless this is like a safety issue um I would also lean towards like making as few changes as possible now unless someone like really really wants to make this change um and otherwise we can move

more things in future upgrades

Micah Zoltu: so I don't think Marius is here but I do feel last week I believe and may have changed my mind since then it might have misinterpreted um his position was if we change the G way we should also do the SSE route we should not do just the g-way change and he seemed to feel pretty strongly that we do both or neither

Lightclient: I asked him about this and he said that because the majority of other clients felt that they didn't did not want to do SSD but they still wanted to play that he was okay with it hopefully I'm not playing words in his mouth but this is what he sent to me when I asked him

Micah Zoltu: that's why I merged the pr to execution apis

so I will once again uh stage my pointless objection that I really think that we it feels like this change we are not thinking about the long-term health of ethereum we're thinking about how do we you know do what the public wants today and I feel like as core devs our job is to think about the long-term health of ethereum and not capitulate to equals you know logging and demands for I need withdrawals this week um I think that doing the right thing means not adding technical debt that we know is going to be technical debt in like six months and if Cancun we switch to SOC roots that means we've got literally one fort where we have to deal with forever the fact that we had

withdrawal routes as rlp and that's going to live with us until the end of time and the cost of fixing that is you know maybe delay withdraws by a week or two and that feels like a very obvious win to me if the thing we care about is the long-term health of ethereum if we care about just you know giving investors what they want then sure give them withdrawals right now but I really don't think that's what we should be optimizing for

Danny Ryan: and I agree with the sentiment but I also I'm not confident that we know what we want the design to be in Cancun I think that we generally think we should be moving the transactions route to SSD but we have not done the diligence there so I don't even know I could not

confidently say that that's actually what we're going to do because there's an alternative the alternative is that we Hoist the ROP routes into the consensus layer to handle the like client use case that we want here and without doing the transactions dual diligence I I can't say for sure that's what we're going to end up landing on because there's a lot of things there's potentially applications that will break on chain there's lots of pooling that we might break um and and so because we can't do that I don't I feel like Landing one way or the other on withdrawals is you know assuming that we want these things to be unified in a similar operate in a similar manner I'm not confident that we're going to land

on uh one of the other in

campgrounds um Andrew um yeah

Andrew Ashikhmin: I think uh a kind of slightly implied in inclined to fixing or like switching to s0 to in in Cancun I think uh currently uh withdrawals root is not terribly exposed it's it it would it's much more like the amount unit is much more exposed to those and withdrawal withdrawals through so even if uh for some historical blocks it uses a different algorithm I don't think it's a it's a it's too too bad the thing it's

some kind of minor technical issue to my mind

Micah Zoltu: so uh to comment on um Daniel's comment I thought and maybe I'm misremembering or maybe I'm projecting I thought there was agreement a while back that we were going to like everybody on the Yale team kind of agreed that SSD SSC El blocks eventually and it was just a question of when um did I misinterpret that is that or did that change

Danny Ryan: that could certainly have been stated um but i i two weeks ago when thinking

about you know the pressure to change the transactions or um now it definitely alighted the fact that uh there are changes there that will have impact users that we have not done the diligence to understand yet and so even if that is like the agreement they're still not done we've still not done the process of like hey what does this break um and really made sure that it's done if it's if it's certainly to be done to be done in a proper way an appropriate way so uh so yeah I I can't speak to exactly I think there's a general sentiment that that's the direction we want to move in because it's a it's a better commitment but changing things has costs as you

know

uh Thomas sure well

Tomasz Stańczak: I feel the div was a sentiment with Taurus FSC but they go towards the disease much larger change than simply the one that we're discussing now so while if you're talking Mike about the introduction of technical debt I think that's our review of ROP versus SSD will be so significant when we look at it to clean it and the process of thinking is so significant that's uh this technical debt that you're referring here to will be simply a small thing comparing

to the amount of changes so on the uncertainty now in the delay like delay itself for the sake of better long-term Network would be very convincing but this particular change the sscrp I think would be a larger process of thinking of Designing and I would like the designers to rush now thinking of how to solve the sscrp in this particular place like the researchers all of us I would prefer us to look at it holistically and give ourselves a proper time starting with this conversation in the process of preparation for Cancun

and before

Micah Zoltu: both Thomas and and Danny

that those that position you guys both hold is assuming we only change we only do sscification of the withdrawal route in Shanghai not transactions or receipts is that correct

Danny Ryan: correct but my my point being is um the doing of the withdrawals are is premised upon kind of that being the common solution to handling these couple of roots um and we don't know precisely how we will handle the other route even though we have an intention on how we will handle the other route so doing them together seems appropriate to me

Micah Zoltu: I guess I assumed that the consensus teams had already kind of thought about this a lot and solved it and the EOS would would follow but maybe that's from the sound of it maybe that's not the case and we want to rethink just how we're doing

Danny Ryan: it's less about yeah it's also about selling to me it's more about um you know one how do you handle the transition two um you know the technical things that rely upon just transactions group um and you know when we disable something like self-destruct we spend some time figuring out what's going to break and try to make a some sort of cost analysis on moving forward and we have not done that on the

transactions

group

Micah Zoltu: yeah so I agree with all that I agree that the transaction route requires significant thought single through see through because they already exist there they have the past I think the thing that I'm confused on with your your argument I think I'm just missing something is withdrawals root isn't out there so there's no backwards compatibility in the El yet and so if we just do what the CL does like are you worried that if we did what the CL does today in in Yale and we got that out in Shanghai are you worried that we later want to change how withdrawal routes are encoded in the eel and the

seal

Danny Ryan: I'm worried that we then have two different ways that doesn't that doesn't fix kind of one of the core problems that we're talking about here which is how like clients and search execution

payload headers into the execution layer um and so then although we do kind of patch the withdrawals root if we never change the transaction then we'd also have to Hoist the transactions rlp route into the consensus layer and so now we have kind of like a very mismatched Solution on doing that like it doesn't necessarily get us you know the first step on the like common solution um and so I'm hesitant to say it's like the appropriate path at this point

Micah Zoltu: so your hypothesis is that there is a potential future where we do rlp and BCL instead of SSC in the Yale and FSA yes and there's answer you can

either compute it in the CDL or the engine API could return that value

Danny Ryan: um but either way then you have kind of like the mismatch handling of roots which is not the end of the world um but then you have also Z in the execution layer and ROP in the execution layer depending on which route you're looking at and I don't know so I I kind of think fix this in one swoop in a unified design and handle the damage at that point

but

Micah Zoltu: I think your argument I think is compelling if we start with the assumption that there is not consensus that we're moving the Yale to SSE and it sounds like that's where you're coming from is that you're not super sure the El is going to move to

SSE

Danny Ryan: um yes I do not understand what will break your options migration so I couldn't throw my hat in the ring one way or the other until I understand that

Micah Zoltu: right I think I was I was going from the assumption that uh we had already agreed to do SSC in the El but if that is not the case then I do find your argument compelling

Tim Beiko: okay and there's a bunch of support in the chat for like moving things all at the same time to SSE um and you know earlier we were saying we'd rather not make these changes to Shanghai unless they're they're like quite critical um so I think it makes sense to just move forward uh with rlp for now keeping the

gray as a unit and we can discuss SS SSD all the things uh for Shanghai or sorry for Cancun or later um because I know like years ago when we discussed this there were talks about putting SSD on the peer-to-peer layer first because um this way you still have the previous versions running in parallel there's less of a risk than switching all the consensus stuff um so I think it's worth having that conversation but uh yeah for a later fork and going forward with rlp for Shanghai does anyone strongly disagree with that um and like client has a has a comment

we should make sure application developers understand this though uh I'll show our community call tomorrow 15 UTC where we can start uh talking about this stuff with uh the broader Community um yeah uh Andrew

Andrew Ashikhmin: but this withdraw through to exposed like especially the ROP withdraw through to exposed to at all to to Dev developers

Lightclient: it's in the block hash

Andrew Ashikhmin: yeah but I mean still the the context is the the withdrawals through itself they could create a proof to the withdrawals route which I'm guessing that they'll want to do so that they can verify certain withdrawal systems are working

Danny Ryan: yeah I would suspect that is the case

um you know for example one of some of the liquids taking derivatives might use that route to figure out distribution of payouts or something like that um but they'll also be worn heavily that things might change I think most people probably generally understand that header commitments are going to likely change but yeah

Micah Zoltu: correct me if I'm wrong but the withdrawal Roots has to be exposed because if it's not then no one can validate a block

Danny Ryan: like it's part of the blockheader and it needs to be known in order yeah I think it also is exposed within the evm is the question too I'm sorry it has to be by virtue of the black hash

being in there so right

Tim Beiko: okay and eaten said uh in the chat uh he's gonna volunteer on to draft a full uh as a Zing EIP for Cancun um yeah cool uh okay next up on the agenda um oh and I guess yeah uh just to close this out properly so last call we had discussed Ethan actually is PR about had adding the X-ray try Roots uh for the list and execution failed headers it's obviously uh

not gonna happen because we're using guay as a as a unit so I just posted on the agenda uh but yeah just so people are on the same page there okay next up uh self-destruct so uh we've discussed on this call many time for many years uh deactivating self-destruct uh through many different ways um we still haven't landed on an actual technical solution that everyone is happy with um but somebody uh wrote an EIP uh to basically announce that we would deprecate self-destruct so the EIP it's a 6049 I put it in the chat here it doesn't make any code changes so it

doesn't require clients to to write any change in behavior um but it's more like a deprecation announcement um and so I was curious whether people thought we should include this in Shanghai so basically you know saying that as of Shanghai self-destruct is deprecated again the on-chain code would not change but you could imagine um this being your way to like learn the ecosystem of it and you know programming languages can start to give you know deprecation warnings when this happens uh things like ether scan or infer our Alchemy can start uh also warning users that like hey you know the self-destruct uh is now deprecated and

and will be going away or at the very least changing in Behavior sometime soon so yeah curious what people think of this I saw yum and then grad both raise their hands so uh Guillaume you want to go first oh can you hear me

Guillaume Ballet: yeah we can now okay cool uh yeah I don't quite I mean yes there's already uh an EIP uh 4758 that is um actually doing the modification what I don't understand about this EIP is is um why would that be part of Shanghai um if there's no code change oh so it's just announcement

yes

Tim Beiko: yes that's correct

but people pay attention a lot of people only pay attention to the Hartford blog post and then stop paying attention until there's another one of them and if we if we include so for example say we include like uh 47.58 a lot of people will be like wow this is the first time I ever hear that self-destruct is going your way and you know they'll be very mad about it so this is kind of a way to let people know that and the the EIP itself doesn't say it'll go away necessarily but that it might also have like a significant uh Behavior change

Guillaume Ballet: okay yeah life is just about a blog post

announcement a okay fine yeah you're saying people can will only watch if there's a

hardware

Tim Beiko: yeah and then and I do think that it makes it easier for you know like say get the yeah logo warning when it happens for solidity for Viper to log a warning when you compile a contract with self-destruct right it's like uh something that all these these tools and and developers can like point to to say you know we're referring to this and this is why we're giving you like this deprecation warning

true then crowd

Dankrad Feist: uh yeah so I strongly agree with um like yeah finalizing that VIP and marking it

as final or whatever that is the purposes um I same thing as kuyom I don't think it needs to be included in any particular hard Fork so ultimately I think like what you're saying is just that we want to intrude it in the hard Fork blog post which I think is probably a good idea as well but I don't think like it's really it's associated with any helpful and yeah what I want to say like some some people like criticize the CMP because they were like oh but there are alternatives that don't deactivate it at all but yeah I think like that in in any case the changer change of behavior is significant enough that one it doesn't make sense for anyone to use self-destruct now and probably it also won't make sense to start using it after

it does it's basically it's just a way to like somehow do something for legacy applications so I still think like with any any option that's on the table it makes sense to a First Market

just application

Tim Beiko: thank you uh Thomas

Tomasz Stańczak: and strong support of the CIP a creative way of making sure that you have a clear indication for Tool Builders to to deprecate to warn uh I think it's been discussed and generally agreed on that either change or removal of self-destruct would happen uh and showing it in a in an official way mine improve the way we communicate such drastic changes for the future uh in the

past I think that communication was one thing that the users are complaining about that the aips were promoted but when the change was happening creating this two-stage process seems to be a good Improvement

Tim Beiko: okay does anyone disagree with this and there was yeah there was one argument against it uh dankara you sort of hit on it uh I don't know if it was in the El Cortez Channel directly um but people are saying basically there might be uh yeah there was another proposal like eip6190 that's a vertical compatible

self-destruct that might not require any significant changes to it or um yeah I I don't know if anyone has a strong opinion about

Dankrad Feist: well that's actually not true I mean it's still a huge change to solve this track from that it would not clear the contact storage database we just hope somehow that all the contracts uh that current use of this tracked in some ways aren't affected by that but it has actually made a change in Behavior anyway

Tim Beiko: okay then I think yeah then I think I'm convinced uh because the EIP yeah 6049 doesn't say it's necessarily going to go away but that they'll be potentially future Behavior changes so I think that's that's still included so

okay

so I guess oh yeah

Micah Zoltu: worst case scenario we can just re-enable it later

Tim Beiko: yeah right it's better to deprecate it and undeprecated than the like yeah tell people too late okay uh I can add it so I guess at two places that like I would add it is like the Shanghai spec uh with the other VIPs that are listed so as people kind of Click through those they'll see this um and then uh obviously in the announcements we make of of the upgrade yeah and yeah there's thoughts comments on this so that was it for Shanghai

um okay there was another thing uh we sort of discussed last call and didn't quite uh get the resolution on uh so we agreed to move eof out of uh Shanghai um and then I put up a PR to remove it from the spec uh and uh Andrew from Aragon uh was asking if we should move it to CFI for Cancun um ethereum JS felt the same and and I believe Basu as well on the chat uh but I couldn't quite get like a plus one from everyone so does anyone object if we make the eof heaps that work previously included in Shanghai cfi'd for Cancun doesn't mean we have to do them but it just kind of adds them to the list

yeah okay so I'll take this as no objections uh I'll do this PR I'll do this PR right after this call and then okay talking about Cancun I put up a thread on East magicians about this uh a few days ago but basically I think um when we were doing Shanghai we were doing the planning process for Shanghai there was a lot of people who who shared a bunch of feedback about how um how we should consider different uh stakeholder groups in the community what's like the right role for all core

devs what type of conversations the decision should happen here um and and basically you know how they how do we make this all work um I think one thing that that sort of comes up a lot is um the the decision around like relative prioritization of VIPs and like higher level planning so uh we do a pretty good job on the call of like discussing individual eips and like their pros and cons and their technical details um and and but I think when it comes time to like figuring out what's the overall scope of the fork and what should that look like um you know between two eips that the community wants which one should be um should be prioritized

um those are all conversations that like end up being a bit more Awkward on this call and where uh different groups uh want to express their preferences and and are not too sure how to engage with the process um so I think one thing I would like to try out to kind of address this is that as we plan these upgrades we also open a thread on eat magicians um to kind of discuss what what the upgrades priorities and scope should look like um and then we can we can obviously because it stretches on each magician anyone is welcome to contribute to it and we can kind of discuss what comes out of that thread on this call as we're planning the upgrade um but and this is kind of a way to avoid every single project having to

send a representative here and you know having uh having like the the short time on this call kind of taken up by a bunch of people who come and and share like their their one preference for for a fork um we discussed I think Micah you actually had proposed this a long time ago as like a Discord channel that would like a temporary Discord channel that would appear when like we're planning your fork about that um I think East magicians is like a bit better of a platform for this and that like it's a bit of a slower pace and people can put like more thoughtful uh updates there um it's also like a nicer record of like how the decision or like what inputs kind of came into the decision

yeah so I guess I uh how did people know where to go um I guess we would mention it on this call you can link it on the agenda basically the same way that people know where to go to propose an EIP for a hard Fork um so I think we can we can link it in a bunch of places my short answer there yeah I guess any thoughts comments about this if there's no position I think what I

would do is I would try it for Cancun um again I could open this like today as we're starting to kind of discuss it um so people can can start chiming in there and yeah we can see how it goes and whether we want to keep doing it uh for future Forks that's pretty much all we had on the agenda except a couple announcements was there anything else anyone wanted to chat about that we didn't cover oh Mike I don't know if you came off mute or not doesn't seem like it um okay then uh two

quick

announcements

Tim Beiko: first uh we have the first Shanghai kapella Community call tomorrow at 15 UTC um so people listening to this um and then the folks from some client teams want to show up um we'll basically give a quick overview of the fork um tell people uh yeah tell people what's what's in it how it works and then answer their questions um yeah so uh people always enjoy when there's client themes you can answer they're very specific client questions um yeah so we'll have that second uh Puja and the catheters have put together a survey a survey around uh execution layer client diversity

um so obviously in the past year we spent a lot of efforts on the CL side trying to improve client diversity there uh post merge it's also quite important that we improve um the El side of things uh so we're going to reach out to node Runners and and operators to uh better understand kind of which kind they use why to use them and and uh what are things we can do to improve diversity there um and lastly the kcg ceremony is happening Trent do you want to give a quick update on that

sure yeah it's been mentioned a few times on previous calls um it's a prerequisite for proto-dink sharding I won't go too deep into what it actually is but

um just if you're interested in learning more go to ceremony.ethereum.org it's uh yeah it's a prerequisite for Thanksgiving and proto-dink sharding and everyone is encouraged to participate it's open for the next two months uh we have a grand strong available if you want to dig in a little bit deeper write your own implementation so um encourage everybody to go check that out and contribute because it's an important building block for uh future ethereum infrastructure thanks

um okay oh yeah

Micah Zoltu: if if the queue stays full for the entire two months is there a plan to extend it

so it's it's

definitely been saturated these first few days it's dropped a little bit which is a good it's sign um eventually we will have to end the ceremony and choose a final output basically this first two months period is open contribution so anybody can just roll up sit in the lobby as long as they'd like uh but we will at some point switch to special contribution which is bespoke implementations uh special entry regeneration things like that and then we plan to revert to another open contribution period for basically as long as we can until uh

relatively close to Cancun or whatever Network upgrade 4844 scheduled for but at a certain point yes even if the queue is full even if it gets saturated even more than it is now we will have to uh end the ceremony at a certain point and that may happen when there are still people in the queue so if you're worried about this um I'd recommend tracking it trying to get in at uh early as early as possible and getting that out of the way if you're uh if you want to make sure you have the most trustless contribution and that you actually are included

Tim Beiko: sweet and I guess one more small thing

we mentioned this on Discord but uh just as a heads up there's no CL call next week and we'll have an El call two weeks from now anything else before we close okay well thank you very much everyone and talk to you all in two weeks thank you thank you thank you thank you bye thank you

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