All Core Devs - Execution #156

Transcript

foreign [Music] thank you

for acde156

Tim Beiko: um many things on the agenda today uh talking about siponia obviously and then what we want to do about Gordy potentially mainnet then Peter had a bunch of uh client related topics uh that it would make sense to go over and then finally um some updates on Cancun so we had some an SSD breakout yesterday and then there's um eips that are uh starting to want to be considered for the upgrade so I think it's sort of challenging a bit

about like how we want to approach that and then there's a couple years uh to discuss today um but I guess to start does someone want to give a quick recap of sepolia this week

Parithosh Jayanthi: sure I can go um so we had this apolia Fork on Tuesday early morning and we had a couple of BLS changes lined up just before the fork and they were executed as expected after the capella Fork we noticed some participation drop immediately after but it was mainly due to some validators running on older version of the ER and updating it without the issue the BLS changes made it on change

as expected and we did have one full withdrawal as well mainly the reason for such a low number of changes and withdrawals is that the validator set is really smart but everything seems to be functioning normally right now

Tim Beiko: nice any other comments

Marius van der Wijden: um there was some issue some bad blood created by another month um if another man I could talk about it

Marek Moraczyński: yeah we produced a few bad blocks on sepolia uh uh what can I say it's definitely not related to Shanghai and it's some kind of regression uh it's not like we produce it every time but only

uh a few of them and I think we will fix it soon but I can't share full details because we are still investigating it but of course it shouldn't affect any hard

work playing yeah it's just something very never mind specific or yes yes yes yes yes

Marek Moraczyński: yes it's how we produce blocks and I'm not sure if it's possible at all on when we have less validators than on sepolia but yeah I will explore it more I I can share details later but uh yeah we need to investigate it more

Tim Beiko: okay any other team ran into some issues or had anything they wanted to highlight okay then oh yeah please

Marek Moraczyński: what about this metamask oh is that fixed

Tim Beiko: I don't know if it's fixed the med someone from metamask replied that uh they were using uh I believe East get balance um and so it's not true if it's an issue with the Json RPC implementation of that in a specific client yeah maybe they give just a background

so metamasks seem to have an issue updated user balances when withdrawals happened which you know etherscan or others like would do correctly um but I don't know that we found like the root cause of of that

and

Parithosh Jayanthi: at least the symptom seems to be fixed if I check the wallet on metamask right now it shows the right balance

oh

Parithosh Jayanthi: so I'm not sure if it was a caching thing or if they push an update or it's fixed or what happened but yeah

Tim Beiko: yeah and I guess it's oh yeah

Marius van der Wijden: that's

good to know um yeah so I I checked uh in with the guest client on sepolia and it works um so I I think every client team should just double check it that everything works fine and then I would consider this issue like a resolved

Danny Ryan: yeah double check the get balance endpoint is what you mean

Marius van der Wijden: yes yes it's it's a five minute thing

Tim Beiko: yeah and if there's any wallet developers or anyone who works with balances listening to this uh basically the withdrawals are not a user transaction so if you're like scanning

user transactions they get a balance um withdrawals would not be counted as part of that so get balance should work um but yeah withdrawals are not like a specific transaction in the block that you can kind of fetch and I think that was the only sort of infrastructure level issue we saw with sepolia was there anything else

Parithosh Jayanthi: nope I think that was the only one we saw would also be reproducible on Shashank so

um please test your infrastructure

Marek Moraczyński: yeah one more thing on sapolia we could add we could consider adding more boot notes because uh Ahmad from our team was testing all El clients and all have some problems with finding peers Etc so we could add more boot notes to help with this issue

Marius van der Wijden: yeah we also had some similar issue also because no one except for gas is able to

snap surf um it's kind of very difficult to snap sync on sepolia because we don't have many peers that are able to serve it and so yeah it would be really really good if other teams could Implement snap serving as soon as possible so that we don't rely on one client for for all of snack and yeah

Tim Beiko: yeah so snap serving and if we can get

more people to run boot notes on the network that would be great I don't think those two things are pretty unrelated to Shanghai though so just I guess to be clear is there any any other like chappella related issues we saw in sepolia or concerns that teams have if not um I guess I'm curious how people feel about uh Gordy um should we go ahead and set a time for it uh do we want to do Gordy first and then uh wait to see how that goes and then schedule magnet

um I know Perry you had a comment basically proposing two epochs one for uh March 14th and one for March 22nd yeah so I guess I'm curious to hear just from different client teams what they think the next like the best steps forwards here is it just Gordy Gordy and mainnet and um when you know should we should we aim for these uh Ahmad oh we can't hear you

Ahmad Bitar: uh can you hear me now

yes we can yeah

Ahmad Bitar: um so um uh speaking of sipolia uh during uh we faced some problems with peering when

we try to find peers in Super Bowl you have to thank the client that is not related to chappella at all but Randy talked about it

Marek Moraczyński: ah okay sorry I missed that

Ahmad Bitar: no worries

Tim Beiko: um Matt yeah

Matt Nelson: back on the original topic um our suggestion would be to just set gurley's date today I have a feeling that when a lot of the public validators are testing we'll uncover a slew of more issues but that's just a hunch

Tim Beiko: okay and does basically have a preference between the two dates like I made more for the 14th versus like 20 seconds or so

Matt Nelson: um it doesn't really matter too too much for us we didn't have very many issues at all with sepulia and we can adjust our release timing for either selfishly the later date is always better in my opinion but the neither will be this is a weekly held opinion

Tim Beiko: and I guess yeah so for the to hit the earlier date so that's like uh 12 days from now it means that like in the first half of next week we'd have to like put out the uh pull out the blog post and so we need like client releases you know in the next like four or five days um yeah um Danny

Danny Ryan: um just a quick comment on the dates or the epochs chosen uh Perry you mentioned that it would be a sync committee boundary which I don't think we really care about on the consensus layer side we care about it being a historic Roots boundary um which I believe are on like 8192 slot boundaries so it does rotate but you can get one about every day um unless those boundaries are in sync which would be funny but uh so we should check epochs against that rather than against the yeah and I think for example yeah we got one that was both basically um okay maybe they maybe they're always in sync yes

I'm not sure yeah if someone wants the sanity trick at the exact numbers that would be great um okay I'm I apologize they're always in sync okay um but I guess the reason we're doing it is because of historic Roots got it

all right

Tim Beiko: uh Matt's your hand was stood up did you have something else you wanted to add or just forget nope sorry okay all good um Marius I see you've covered uh no I'm always off mute

but

Marius van der Wijden: uh yeah it um for us it's um I think

uh having early the earlier date is better because then we have more time between girly and Maynard from my point of view we could schedule minute and curly at this now um but uh if other client teams don't like kind of scared about it then it's fine too do one and then the other

Tim Beiko: um yeah there's a proposal in the chat from Iraq what about like around the 16th for Gordy so more like the Thursday then the uh then the Tuesday

if we did that I guess the the difference with doing that is like um if we do it on the Tuesday then we know by like all core dabs on the Thursday how it went if we do it on the Tuesday on the Thursday um at best we get you know maybe a couple hours before all quartets uh to see how it went so it you know the potential risk is like the delay the four two days we might delay analysis like a week yeah um got it got it yeah so I guess so far it seems like people would rather have Gordy a bit sooner and potentially spill out the main net release does anyone disagree strongly with that

in that case uh so the epoch that you had proposed Perry was uh 162304 if we can just sanity check that this uh I guess what time this happens and and uh and uh whether it's a historic Roots boundaries I think that would be good but any objections to that otherwise okay it doesn't seem like it and let me scroll down on Adrian's

tool uh 16304 162304 so it would be at around 10 pm UTC which is 3 P.M at Pacific um there's no Europe I guess that's yeah it's like late late Europe early um early Australia and midday uh us

of Buddhist

Potuz: yeah so uh what are more or less the timelines that we had because uh so we're gonna be forking into weeks in girly and then we will need at least one

meeting to set up the yearbook and then we'll need some time to soak clients for uh main net so I'm not sure what was the consensus on how much time do we want between release I'm waiting for uh for people to upgrade um whether or not we should be talking about at least tentative dates now

Tim Beiko: yeah I mean for mainnet we usually want to give people at least like two weeks after the announcement that seems reasonable so like imagine you know Gordy happens on the 14th um and then everything goes well on the 16th uh we we agreed to move forward with mainnet um you know I think the earliest that puts us is like the first week of April

basically

Potuz: uh yeah I was counting at least the second like sort of like a month after after

girly spark

Tim Beiko: yeah I think that's interesting right yeah at least to me I don't know if anyone feels strongly

Potuz: then I don't see anything wrong with not not bundling this

yeah

Tim Beiko: yeah I don't think it should be as close you know like I think it's it's fine to move the test Nets in like quicker succession than we remove my net basically okay so I guess uh I'll open a PR for uh the uh Epoch um and then uh yeah we can we can go

with that again assuming that uh I'm pretty sure the map checks out for the for the roots battery um and uh yeah if clients can have a release uh either you know tomorrow or early next week that would be great then we'll put out uh the announcement uh around midweek next week still let people know but um people should expect Gordy's upgrade to happen on uh Tuesday the 14th around uh what was it it was 10 10 p.m at UTC more or less anything else on that um and yeah on the next call we can talk

about the main update but I think people should expect no sooner than like three four weeks after

Gordy uh do we have Peter on the call no okay so Peter had like three topics he wanted to bring up but he's not here so we'll skip those for now and then uh potentially get to them at the end If he if he shows up or if other people have opinions on the Cancun side uh we had we had an SSD a second SSD breakout yesterday uh and Ethan I saw you added some notes um do you want to maybe give a quick update there

Etan Kissling: uh sure uh can you hear me yes that's

good yeah um yesterday we summarized two approaches again like I did a lot of metrics testing that I measured like whether the SSC Union or the normalized transaction approach is better and as usual with those things we came up with even more ideas that also affect the receipt three um so just to summarize once more for the people new to this the goal here is to update the representation of transactions and receipts as part of the block as part of the consensus execution

payload as well and the goal is that we can prove any individual field of a transactional receipt like you can create a proof that checks hey a transaction with this transaction hash was successful in this block without having to download the entire transaction so there are three pieces of information that you can request in Json RPC um that are not part of the serialized transaction namely that is the transaction hash itself which is computed from the rlp serialization or the hash tray

route for an SSC transaction and there is also the from address like who is sending the transaction who signed it and the third piece of information is for transactions that deploy a new contract there is the address of this new contract and the question that we have here is whether we should put those three items into the transactions three or into the receipt stream there are arguments both ways and transaction tree um kinda makes more sense because um those three items the transaction

hash the from address and the contract deploy address they are statically computable based on just a transaction they do not depend on the ethereum state like the rest of the receipts and it's also this approach that we did in the execution payload where we put a little field in there that says block cache even though the block hash can be computed from all the other fields so anytime that we put something into the consensus object that is computed but requires algorithms that are unused in consensus we could continue this tradition and

make those three items available as part of the transaction object the problem is that it consumes more space in consensus objects that's 32 bytes for the transaction ID it's 20 bytes for the contract employee address and it's another 20 bytes for the from address so it's about 50 bytes and that we are talking per transaction that is about 10 kilobytes per block that it is bigger if we include those in that the alternative is to put it into the receipts object and there are arguments in favor of that as well because those receipts already contain information about the outcome of

a transaction it's kind of fitting to put stuff like hey a contract was deployed at this new address or a transaction was included into a block with this um additional hash or with this from address arguments can be made both ways in the Json RPC currently the transaction hash and the from address they are exposed in both get blocked by number and in get transaction receipts and the contract address is exposed only as part of the receipt but that's just place an RPC so yeah just as an additional point so if someone has

big preference one way or the other that would be nice to to speak up

Tim Beiko: thank you for the overview any thoughts I guess one question there was on the agenda and um I think I also have after uh hearing this is like what's the best place to just uh read the sort of basically longer version of what she just went through is there uh I saw you put like a couple notes in

the agenda is there a specific EIP oh you have actually the hack MD okay so you posted this I can be on the agenda is that the main thing people should look at if they want to wrap their heads around all of this

Etan Kissling: uh yeah I think the hack MD is the best entry point um I just created that one yesterday so it's not yet complete um but um it contains this Mansion as well um yeah so I guess right now no one has a clean idea there yet so the other point that we have is related to SSC transaction signature

schemes that's eip6493 and there we had a question right now I sort of mix in the Genesis hash the fourth version when a transaction type was introduced and the chain ID into the into the hash that we are signing and yesterday in the call we had a question like do we need all three of these or um could we for example drop the Genesis hash there if we already have the fork version um and the chain ID so if someone is still familiar with the decision process of why the genetase validators root and the fourth versions are both used in

um maybe that could put some more light into this like what act what what actually should we put into our signatures on execution

Tim Beiko: any thoughts comments okay so I guess if in the next couple weeks client teams can look into this uh we there's a typed transaction channel on Discord without these conversations are happening as well um but obviously figuring out

how we want to approach teams for Cancun with regards to SSD um is is pretty important okay I guess uh as we're kind of moving to Cancun stuff um there was two other eips uh uh panapip wanted to bring you up today but before we do those um we have sort of this thread on it magicians where people can you know share what they'd like to see for the upgrades there's been a couple things there already um I think it would be really valuable if in the next couple weeks client teams can sort of chime in there or at least

think about like what are the most important things that they see for Cancun and you know beyond just like whether each specific EIP or not you know should be CFI like um what's like we already have 4844 scheduled for Cancun you know are there other sort of significant things we want to accomplish there are there you know some VIPs that like Klein team Schiller are much more um needed or urgent and I guess similarly you know for EIP Champions this is the spot where like uh it would make sense to advertise that you want an EIP considered for the for the upgrade

um there's also a Cancun candidate tag you can use on these magicians um so there's you can sort of see all the different candidates um all in one uh all in one page yeah so and I think over the next couple weeks like as Shanghai wraps up we can spend more and more time discussing like what the right scope is for Cancun and um what we want to uh add alongside 444 um I don't know yeah before we go into more details there any thoughts by clients or other people um I see there's a couple comments in the chat um Okay so

BLS pre-compile and uh 478 date is this uh I believe the beacon State Route in the El um got mentioned um anything else teens feel strongly about today

Andrew Ashikhmin: I have a question um so is the cryptography in 2537 the same as in Blob transactions so is it different and my thinking is whether it was the same then makes sense to bundle them together

Alex

I don't know if you have a mic

Alex Stokes: uh yeah so well the other Alex oxic actually did this a bit but the thing with this is that there's kind of been a whole Saga these pre-compiles and I think the current one current direction is actually to say well no pre-compiles since they're actually like kind of involved there's like at least nine I think we could bump that number up to like 11. so that's a lot of pre-compiles and instead the question is like what if we can do this without freaking files and one way we could think about doing that is um basically doing it natively and then the bottleneck there is having modular

arithmetic so Jared from the guest team has been looking at what he calls evm Mac I don't know if there's an EIP number yet but the point being is there's an alternative Fork here or like a different design route we could take and um yeah this is kind of just the question of like do we want to ship this now versus take the time to explore this other path separately yeah the cryptography is the same or at least you know the 2537 stuff is like a foundational layer for forever for I don't know if we want to like get or block them on each other though

Tim Beiko: got it thanks uh Danny

Danny Ryan: yeah I mean I'm very Pro Evie and Max

and these other things that can help us not have to write premium tiles in the future I kind of I mean at this point I see BLS is like a native uh ethereum curve an ethereum uh crypto and so um we have the tools we have the libraries we have like extremely robust versions of these and so exposing this DVM makes sense to me whereas I totally agree that we shouldn't have to we should do things to not have to maintain and build um all of these curves outside of the evm but this one seems pretty native

thanks uh Dana

Danno Ferrin: um one of the things I'd like to raise against the idea of random

um curves as uh pre-compiles is the gas pricing is is sometimes over fitted to specific algorithm to try and fix a particular curve um and then sometimes there's like holes they don't map specifically if we use something like evm Max to charge per instruction and there is optimizations or there's de-optimizations that are needed and the gas prices are reflected natively and the contract bringing the code they want and that reduces risks related to gas-based consumption um in a block so I think that's why we should be very skeptical of bringing random Curves in as new pre-compiles um the and also the EIP for edmx I think is 5843 I posted that in chat

Tim Beiko: um yeah there's comments about Twitter

BLS is random or not I don't think that's worth getting into uh too much okay so um yeah let's let's spend more time I guess in the next two weeks just thinking about uh you know what con teams would like to see and others who are listening to this as well if you want to chime in uh this youth magician's thread is probably the best spot to do it um and I'll look over all of it before the next call and make sure to like uh summarize it and um yeah so we can come in the call with a bit more of an informed opinion um and then two other things uh that uh I guess are proposed for this uh are

eip's five nine twenty which is the pay op code in eip6190 which is a new approach to dealing with self-destruct uh Panda pip was the champion for both of those I don't know are you on the call no I don't think so um I don't know if there's I think he's a single author on both uh oh no actually uh Victor was the author on the payoff code is Victor on the call no okay um and then he was the only author on the self-destruct one so I don't know if

there's anyone who has comments or thoughts on either of those if not we can just review them async

Guillaume Ballet: um sorry I was looking for I was looking to raise my hand I couldn't find the no worries yeah uh I I didn't go through it very thoroughly but I did look at uh at the self-destruct one yeah um I don't think it should be called uh virco compatible self-destruct because I don't think it's really directly related to Virgo it's more like the the new self-destruct uh we wanted to disable self-destruct um yeah so that's that's a nitpick but I don't think it should be it should be

called the like Virgo should be in there uh one thing I did not understand so maybe someone did um or at least maybe I misunderstood it seems that you have it's basically uh when you self-destruct self-destruct an account you create a pointer to a potential new account uh that will over uh override the the older account and what I see is that effectively self-destruct or creating or self-destructing an account will mean will mean you'll have to jump from okay from self-destructed account to self-destructed account and um that makes self-destruct uh I mean the cost of self-destruct is is not

constant and um yeah I'm also uh worried about the the need to just uh to jump uh all over um all over the database so uh what I would like to have discussed was an opportunity to update the pointer like basically only have one pointer uh so that you don't you don't jump all over the database so that was that was my first comment and I had another comment oh yeah I don't think the at least I did not understand uh how create two would be affected I think that's missing from the EIP so yeah if maybe I missed something I would like to uh to know if someone under understands it differently

Tim Beiko: thanks anyone have comments or thoughts

uh yeah thank God

Dankrad Feist: uh sorry I mean uh we talk about with eip6190 yeah but so I don't understand why where uh where this pointer a thing comes from that you say glio I thought it simply I I don't I don't see anything of that in

VIP

Guillaume Ballet: uh well when you self-destruct okay maybe I misunderstood again but uh from what I understand when you self-destruct something you replace the code um with one and you set the nonce to some value right it's not when you solve

this stroke that you create a pointerest when you create what you call create again uh it sets the okay let me just uh get the EIP because I didn't have it under uh like I was looking at it immediately but it seems to me that at some point you you set oh right it's the first value of storage that gets uh that gets a uh like the contract zero slot storage slot uh putting the EIP is set to the address that would be issued in the contract you use the creative code so that's what I call the pointer it's the step two in the self-destruct Behavior

Danno Ferrin: there's no pointer in that function it's

just a marker to prove it was self-destructed correctly

um wait

Guillaume Ballet: I think you have to Traverse so you read this you read yeah you read the zero storage slot and then you go to that address it's in that place and see if it's also been self-destructing if it has and you go to the next one again right

Dankrad Feist: oh oh so like we're trying this VIP tries to recreate the self-destruct Behavior exactly as it was originally uh okay because I thought I was right sorry right I see so yeah that that doesn't seem viable yeah I agree

Guillaume Ballet: um yeah I mean it's not it's got some

nice properties but indeed it's not this indirection thing doesn't look super great to me

Dankrad Feist: well because I can I can potentially create an infinite stack office after such a construct like that right and yeah okay any other

so

Dankrad Feist: so I mean the EF seems Seems incomplete to me yeah like if this is the intended behavior that basically every time you self-destruct you compute a new contract address and next time a contract is put is created at that old address you use this new contract address Instead This behavior is not

specified in that EAP so that seems largely incomplete then um but yeah I don't think that would be viable unless we can somehow make contract invocation and everything a very like depend on like the gas costs depend on the number of times students are distracted and I guess for some oh sorry yeah go ahead

Andrew Ashikhmin: uh yeah I think but if the code is overwritten to just uh 0 1 there is no further possibility of self-destruct because yeah it doesn't it's

self-destruct is obliterated by the code rewrite

sorry what code do we write

Andrew Ashikhmin: so I think uh maybe I misunderstanding something but I think uh we in the Eep if the contract code is set to zero one so once it's um self-destructed it loses the capability of uh further self-destruct because there is no production but a new contract can be deployed at that address that would have the capability again right

Lightclient: no the address yeah the accounts doesn't actually get removed so it's not what okay the the specifications unclear to

me then what it's supposed yeah why are we why are we writing this new address at the zeroth storage slot so it's actually explained in a different EIP which is 6189 I think uh where you yeah that's what I was describing was pointers you forward the calls I think the the words they use is um so yeah you create a new contract so if you self-destruct the new contract like if you this self-destruct the contract and then you recreate on top of it and then you self-destruct this new contract the self-destruct gets forwarded and every time this is um this is written in gas cost of self-destruct it says every time you get a forward uh how they call it an alliance uh you pay

5 000 gas extra um so it is uh it is not overwritten it's you create a new contract uh that serves a as an Elias well the self-con the self-destructive contract is an alliance to this newly created contract and the chain can go on forever well not forever but uh long enough

Dankrad Feist: why exactly are we considering this EIP like I'm I mean my last say it was still there was the previous VIP was the one that simply so like I mean this is a very elaborate construction to reconstruct the original

self-destruct Behavior and it's kind of annoying

Tim Beiko: yeah and I think so last time there was a basically I think it was like 47.58 or something the one that just uh converts it to send all the problem with that is all these create two you know contracts um so then there was this other VIP which just uh swapped the nonce but uh but still lets you sort of recreate a contract with the same address if the nons had been swapped to this uh Max inth number but then the issue with that is you can get like mutable contracts where like you the the the the contract storage is

not cleared so you could redeploy a contract um at the same address using the old storage which is unsafe um and I think this is sort of where we we got in stuck

Dankrad Feist: and okay but I haven't I haven't seen the discussion where where like there was anyone who was actually affected by this oh yeah there is yeah yeah yeah

Tim Beiko: there's uh so why are we

Dankrad Feist: why are we not considering that that version of the EIP Which is less complex than this so

Tim Beiko: so Jared I believe like looked at affected contracts like there are several contracts which would break uh and like non-trivial contracts if we just uh you

know convert the send all and this is where

you don't

Dankrad Feist: understand that part yeah I'm talking about the next step not about the

center

Tim Beiko: yeah so no one yeah I guess the short answer is no one has done it so I think the two next steps okay

Dankrad Feist: that you probably like we should first we should consider that other version of the AP and only default to this crazy construction if we find that that yeah breaks something major yeah

Tim Beiko: and I guess then the two the two paths to explore one is like uh 47 58 with a tweak another is kind of a weird tweak but like you know you you allow self-destructing and recreating in the same transaction or something you know I think that would uh that would solve

most of the affected contracts but it did add a lot of complexity and I think uh there was another proposal which is you you uh allow recreating uh new contracts if they've been self-destructed with this like nonce uh nonce change but you you move the storage to a new like to a new location so you're sort of if you're not deleting the old storage from the the try but you're making it inaccessible and the downside there is obviously you you let's basically yeah but yeah

just while

Dankrad Feist: the downside is significant complexity to support an absolutely marginal thing that has no real use case

Tim Beiko: the downside of what sorry

Dankrad Feist: of this latest Suite of EIP is like six one ninety and stuff but yeah I mean it's a it's an insane amount of complexity that's what we really wanted to avoid yeah

Tim Beiko: yeah and I think it would be good for somebody to just look in the different like how do you not break this create two redeploy flow with the least amount of complexity um I agree that would be like a very valuable thing to do

Dankrad Feist: well I mean it's not possible with anything less than this like if we want to recreate the full Behavior then I mean this is this this has been possible but like clear and possible from the beginning but I really want to avoid it

Tim Beiko: at the risk of basically breaking some

contracts correct

Dankrad Feist: oh yeah

Tim Beiko: okay yeah um um yeah so I'm yeah I feel like having better data at least on like the different like approaches and being able to actually assess the complexity would be good and obviously like ideally breaking zero contracts would be ideal

Dankrad Feist: uh by the way what is the state of uh deprecating self-destruct Yes we made that decision

Tim Beiko: yeah so we yeah so we it's deprecated as a Shanghai

basically so we've told people it's deprecated um yeah or I guess we'll tell you know it hasn't happened on magnet yet but like it's part of the the Shanghai spec anything else on self-destruct uh and I guess there was no other comments on the payoff code okay Adam Peter you had three things you wanted to chat about

um removing uh pending block slash pending transaction 866 and then removing support for non-emerged networks do you want to give some quick background on those

Péter Szilágyi: uh sure so let's take the easiest one um so for 4844 is backed out in 68 and I think most clients are already on it or if they are not I'm hoping everybody's only 67 at least and then the question is can we simply drop the 66 if anybody opposed to that essentially if any client is so unless there's a client still on feed 66 is to be found to drop it

I'm just asking because it's just it's hygiene to delete all the stuff that are not needed anymore

Tim Beiko: does anyone yeah does anyone oppose dropping

866

Péter Szilágyi: does anyone oppose dropping leads 67 might as well

throttle

Marek Moraczyński: uh so uh we have if x60 uh eight implemented but not released on purpose uh EIP was in draft and in case of new Breaking changes in EIP it could break communication between peers but we if we

all agree today that there will be no changes to this CIP we can add it in next release knowing that the hard work is coming in it means that all Nether might notes after hard Fork will support uh if 68 of course previous version don't support as I said on purpose because CIP was in draft

Péter Szilágyi: yeah so it's uh this is just the weirdest of the active process I think everybody will stand up on board with e68 the way it was packed and since I mean even if one client released it it's already you really cannot really change it anymore without breaking that

client and I think currently almost all the clients have implemented and apparently rolled out so you know there's no possibility to change it don't make a change if it's just roll up e69 on this

one

Marek Moraczyński: yeah so we will add it to the next release

Péter Szilágyi: then I guess what we can do is remove 66 now and 67 I guess after the artwork because then upper body should be up to date cool

Tim Beiko: yeah Fabio

Fabio Di Fabio: yes uh we invested were thinking about that and let's say we are also fine we keep supporting all the uh

version of the protocol for private network but we can announce only the new version on mainnet but we were also uh evaluating that since at the moment only get support snap sync removing this will also remove the support for fast sync and what if we wait

that was already removed positive yeah I what if we eat

Fabio Di Fabio: uh for

at least another client to implement a snap sync server before doing that this was our suggestions

hi Lucas

Łukasz Rozmej: uh so I think like we can deprecate it 66 but that doesn't mean we have to remove it I think gef wants to remove it because going forward with their uh State layout in terms of never mind we are working on implementing our own State layout changes and supporting snapshots and snap sync but uh yeah I hope this will come somewhere this year but uh yeah that's that's it so I think we can like say 66 is

deprecated while still some clients can support it if needed so we also need it on other chains where there aren't gift nodes to sync so we won't like remove it entirely right now

Tim Beiko: got it Andrew

Andrew Ashikhmin: uh well uh Aragon formally supports his 66 but not actually doesn't because it doesn't serve get no data so like dropping it for Aragon would be uh actually clearer we we don't have this capability and like no intention of supporting get no

data

Tim Beiko: so I guess does it make sense to deprecate it on mainnet as of uh Shanghai basically um and then if client teams can also ship eat 68 as as part of the Shanghai um that'd be good because then we know sort of all the main appears support

868

Péter Szilágyi: yeah actually um I think that the catch that I was missing is uh e66 was the last one wait that will be 68 did we try new capital data after 867 Maybe yeah okay okay that is a bit more complicated because um because of the

capital of data which means that all clients need to be able to think via nursing at least the client side okay it should be implemented yeah so um long story short for Gap if you want to when we want to switch to the new um data model we will need to stop supporting this either way so it would be nice to nice to have other other clients also catch up with the synchronization part plus it would be super nice if other clients could actually start serving it

because it's uh we are currently on supaulia synchronizing simple is a bit harder because there are relatively few Gap loans but only get nodes can serve Snapchat data so it's a bit annoying I mean I guess long story short we should not drop it 67 sorry 66 just immediately right now but uh yeah we will be forced to come before we switch the

the try I guess

Łukasz Rozmej: so the mind can think uh snap sync and I think bazoo probably also but I'm not sure so we can think through e67 but like it's 66 is still relevant for us until we change our our database model right so that's what I want to say

Péter Szilágyi: yeah okay I guess then for for me the verdict on this question will be that uh Gap will retain 67.

um just so that we have it and then the moment we we roll out the new data model then we will implicitly also stop serving you mean

66 right yeah

Tim Beiko: yeah okay yeah yeah okay

Péter Szilágyi: I guess at that point most people will run 68 anyway so so 67 is kind of like this boring thing the interesting thing is the 66 because that's the last generation that supports okay uh then uh for me the answer is that we will retain it for now and then when we switch over probably possibly

what we can do is uh if somebody's running so our we will support both data models initially simply because we cannot just upgrade our database from one of the other and then anybody who's running their own data model will continue serving with 66 and anybody who resyncs essentially running the new data model to stop serving system I guess that will be a good middle ground and then eventually we'll call it remove it out completely afterwards so that was one question

now

Tim Beiko: yes uh the next ones were uh pending block pending

transactions and then syncing non-merge Networks

Péter Szilágyi: yes yeah so uh yeah that's one of those in the annoying things that people that we want to drop since forever because it's not really useful although it's not really harmful either it's just one of those things that that get we get annoying bug reports that hey if I'm wanting to subscribe to the pending block then okay the block number should be what or the block hash will be want or or essentially I'm getting number of

pending blocks and is it for the same height is it for different height it gets a bit weird and uh and my uh suggestion is whether I think it would be clean if we would stop serving the apis for the pending block because uh depending block essentially contains a random selection of 200 transactions out of 4 000 that the note has it doesn't including energy transactions either so the state that you can retrieve from the pending block will be kind of random so it's not really the next thing the transactions included in it will be kind of random

so what's the point

yeah Andrew

Andrew Ashikhmin: um it's um I was thinking that um we can perhaps repurpose spending block for something else because now we have this um with after the merge um we have to wait for a fork Choice updated until we um Mark a specific block as like as the the head of the chain so we will before uh Seattle deems to be the head of the chain we have we are aware of of some new payloads but they are not officially yet

can canonized so but if somebody wants to be able to access new new blogs that we are aware of we can I was thinking that we can use pending block for that or maybe some come up with something new but it's I think it's a valid use case for it would be it would be bad to lose access to such available data but not Sanctified by EO by CL yet

Péter Szilágyi: so the problem there is that in theory you can have a sibling and so if I I can give you five new payloads that are all siblings and then

which one would you return where I could give you even multiple one on top of the others so it's a bit

Andrew Ashikhmin: uh yeah true but um I I guess uh in most cases it will be just one block

we can come

Andrew Ashikhmin: come up with some heuristic so it's not it might be not necessarily um uh um predetermined it might vary by client to client but I think uh it's it's a it's a useful piece of functionality for people who are who who want access to the latest data and they they might not care if about some weird theoretical

scenarios because the other you might use heuristics okay give me the biggest block or the most the likeliest somehow by some heuristic to become the head of the chain

Péter Szilágyi: yeah but that kind of changes the things a bit again because that's that's in that case you can actually for example retrieve transactions which belong to a specific block for those blogs have a proper block from a block hatch difficult so it's a defending block has a lot of these guesswork fields whereas uh if it's included in the chain

already even if it's not set up the head yet then kind of behaves like the old blocks already so it's a uh if for me the weird thing is that we have these for example uh you can filter for pending transactions but then okay you have a stream of transactions but do they belong to the same pending block different pending blocks I know it's it can all be interpreted and somehow added a certain context it just seems like a mental effort that's not really useful so is there any legitimate use case for depending on like ever anything

we can definitely keep it it's just I'm not sure there's a point in keeping it

Andrew Ashikhmin: well I guess for some Mev or some some other scenarios when you want to be super fast and you you you you don't want to lose any latency then you need access to like to the most probable pending block and start building on top on top of that

Péter Szilágyi: yeah but that's not funny but it's not the most powerful one so currently with um with all the flashback bundling and everything it's the the next block will

be saved if the next signer is actually running any kind of immediately capable Miner then the next block that the network will see will be completely different than what what will be produced

actually

Tim Beiko: is it I guess is this something that gethalone can try removing and see what happens basically

nothing it's

Péter Szilágyi: so the pending block is um and all the attending apis are specified and part of the execution layers pack so it's it's not really something that we can just yellow remove and then book

nothing

collapse away

Tim Beiko: so maybe one one way to like actually see if it's useful is to just make a PR to the execution API specs removing it and then you know share that with like Mev people or other I guess developers or users and see you know today like object strongly on the pr I don't know if anyone else has thoughts about this but it seems like we struggled to to see if it's actually useful for end users and if we if we claim to remove it

then at least people will show up and complain if they're actually affected by it

better

Tim Beiko: for me it seems that depending law is kind of similar to an archive node where it's something people kind of have there but they don't really use it on any kind of power user will just need some extra infrastructure on top anyway because whatever's out of the box is is not sufficient

Péter Szilágyi: my guess would be that if you're running some nav stock then you would try to collect all the transactions independent of the funding like you don't care about the next 200 transaction with your

client things are interesting you care about the next four thousand and then try to mix and match and dig stuff out of them so again you have a spending block which is somewhat seen things for functionality but you think it's too limited to be actually useful for for the power user data because none to suffice same with archive archivals are super nice except when you actually want fast access then you need to index on top because well you're not going to read through the state drive anyway if you're running some production system thanks anyways we don't necessarily have to

write any conclusion here rather it's more like um it's open-ended question at long term the spending block I think it's been playing us for a while and I know we're just in this mode of trying to delete stuff that or not

English

Tim Beiko: yeah and I guess what do you think would be the best place to collect feedback from users on this this is sort of why I was suggested making a PRT execution apis because Mo I suspect right now what happens like if we removed it people wouldn't be aware and then they might complain after um so trying to like preempt that is

there a way we can like suggest it and and if there is strong strong demanding yeah

yeah

Péter Szilágyi: we can always announce that we decided to remove it and then see how big of a fallback there is

yeah

Tim Beiko: yeah and that's why I was suggesting bestly opening a PR on the execution apis repo I think that's like we don't have to merge the PR but like you can open it we can you know share that as a thing where people can go and comment on it if they're not happy about it

yeah cool yeah

Tim Beiko: you had pending transaction as well

which I assume is like the same pending everything

okay yeah

Péter Szilágyi: yeah but it's the same point yeah got it so um okay with pending transaction there's a bit of um Nuance there because uh I think for Gap specifically when you virtue depending transactions we don't give you the uh the transactions from the pending block but the transactions from the transaction pools because everybody was kind of interested in that and not the funding block which kind of already highlighted that the pending block itself is kind of useless and people want something else so I'm completely fine to retain the functionality to retrieve the file of

transactions from the food that that seems like a useful thing I just don't see assembling that into a part of that into a block and then returning that something so pending transaction I'm perhaps if there's a API between an intersection let me just rename it to retrieve the Fool's transaction or whatever call it something meaningful

okay and then the last one was um on the chat that we should call the pending block parameter

Péter Szilágyi: I mean it I'm

assuming you mean the the pending bit string literal identifier that kind of yeah that support you get rid of that out of the world's implication cool okay and my last open up question again it's more like a discussion stalker in his starter is that um again one cleaning some stuff up in gas currently all the clients and getting through everybody has kind of two ways to single price the network application of likes I mean they

can synchronize in this Forward Thinking mode and apply the proof of work with authority and they can synchronizing this backward filling mode where we have a beacon time which tells us the head and then we go backwards improving everything and there are some subtle and lots of subtle differences and they are various optimizations and so you can optimize a lot of stuff if you know that you only need to do one of these options talk about these methodologies but if you need to maintain both it gets a bit wonky it's it's always harder to optimize if you

actually because your stuff can be called in completely different ways plus we have all that all the almost forward synchronization code which is actually not tested nowadays or not since all the networks and maybe wrinkle is the last standing after but once we don't okay that all our networks will be post merge and became driven so we actually won't have any production Network that can does not work and nobody will have the

capacity to make it work because there will be no public network to make it work on and um this is a question I got a long-term question that is there an appetite towards trying to remove this functionality but by removing a Forward Thinking functionality we could essentially say that we will never be able to synchronize a non-verse network error plus and if that's not that we launch will need to be merged at Genesis already because you wouldn't be able to the mind the first few blocks the transitioning across a normal establish

the worst parents but there are some implications and the question is what what do people think about this

thanks uh Lucas

Łukasz Rozmej: so I think the synchronization methods supported right it's fairly internal thing implementation detail so each client can diverge here easily and we I think differ a bit in in the centralization methods right the the API of uh of eth protocol just supports multiple approaches and for example nevermind will be supporting synchronizing non-merge networks as we

have few that we support and I don't think they will be merging anytime soon um yep that's from the nevermind side but uh we generally um have the approach that we try to go backwards on them so we kind of have some trusted block hash that we uh that we include in the for example in the release and we try to use the backwards thing on them while uh while we only have this forward sync doing a small part which generally it is less optimized but it's like not big deal because of that

Tim Beiko: thanks any other thoughts

Péter Szilágyi: so the just once I've known that uh yeah it is true that I mean we can always leave this to every client to decide for themselves whether they want to support this or the lower Quantum support the other cache is that if we ever want to launch test networks that are not Genesis merged than any client which drops its functionality will be unable to participate at least in that phase where the thing gets merged which might be an interesting

indication

Tim Beiko: any other thoughts comments

okay yeah I mean we can continue the conversation on this and obviously like there'll probably be some Divergence between uh what we do on my net and you know what we have to do or what client teams have to do to support uh other networks outside of

mainnet yep

Andrew Ashikhmin: um yeah I'd like to say that I think it sounds like a good idea because in arrogant at least the the forward sync is fairly complicated and I would like to drop it at some point

but

Péter Szilágyi: forward I think is one thing on

supporting block propagation block announcements block fetching from the other side is for example another mechanism that is only useful for non-verse networks so if we assume that a client will not support a non-merge that we're going forward and all this block retrieval logic can be completely deleted again these are not necessarily big complicated things especially since they are kind of working now my kind of my it's just a maintenance thing that the code is there and then you want to refactor some API or something then you always have to tiptoe around existing code that nobody's using so it might blow up in your face anyway once somebody's thrust

to use it later obviously it might be different for for some clients which wants to support log ethereum Networks that's one thing and the other thing is I'm not sure how layer tools what layer tools do so it might be interesting to get some feedback on some layer too because I know some sort of thing derivatives so if I would be curious if how they work in the organization if they depend on this or not

Marius van der Wijden: can we can we start by creating a new its protocol to drop the the messages

Péter Szilágyi: so um we definitely can I guess it will be kind of similar in similarly with problematic uh 1966 where if some client wants to keep supporting this then they will need to support some ion program for e66 which is fine as long as we are just dropping stuff but what happens when we need to add something and they want to add it to their non-word networking and then we would have a report in the program but what messages

exactly

Marek Moraczyński: what messages do you want to drop

exactly which one

Marius van der Wijden: new block

apparently the block from block propagation Block announcement messages are forbidden on post merge networks but they are still particles yeah

Péter Szilágyi: okay and then there's always the option to remove it from the protocol but if we remove it then it's going to be a problem for for clients who still want to be able to support it

Łukasz Rozmej: ah so you mean okay if we remove it

then okay okay got it but we could probably like if we removed in like x69 right or something then we could still like support it in the 669 just have it this disabled as we have have it there like with some some kind of way it's not a it's not a big deal in my opinion but um yeah the question is it's not a like a question for it's limiting things so we shouldn't like maybe take it to like be blocked by it but yeah if someone especially uses uh especially gef as a fork

and for example l2s Etc they wouldn't be able to they would have to like be very careful when merging stuff right uh back if this uses there so I don't know from this perspective but it shouldn't be a blocker to to go forward in general

Péter Szilágyi: yeah but only for clients who are willing to draw people the non-verse network support because if you don't want to drop the numbers that will support them you will implicitly needs to keep this these messages through the block propagation and sickness that means that you cannot just remove

it from from the protocol unless you're willing to create a new satellite

protocol just for blockification look around right

Péter Szilágyi: sorry okay I didn't hear that but um anyway I don't really want to park this whole discussion I think uh my three um issues that I I opened I wanted to bring

it up here it's just um it's kind of like a small part of the general direction of um trying to somehow slim clients down so that we we stop finding new complexity on and somehow try to remove stuff that either webcast experiments or fast lessons or past implementation details and it's always a bit annoying to remove stuff because there's always somebody relying on it and I definitely think we should somehow figure out how to proceed for those people I don't really want to just leave people hanging in the air but we I think need to accept it that we cannot buy

them complexity or not forever we need to somehow start turning down

something

Tim Beiko: I think I think that makes sense I think you know slowly starting to bring things up here and like suggesting PRS and like making people feel like it's gonna happen or it might happen is is valuable because um it takes a long time for the community to realize that uh a deprecation is is happening have anything else anyone wanted to

Péter Szilágyi: I mean Matt really loves this so

Tim Beiko: yeah we

need to fill the last eight minutes uh for that is he still even on the call did he drop off the call okay no he's still here depression oh yeah I like the idea Jerry considered for deprecation cfd and I think that is something though like we've announced self-destruct being deprecated in this upgrade like I think at the very least when we make these Network upgrades we can flag stuff as um even if there's no actual code changes that's a good way to you know start letting people know um

but yeah okay if there's nothing else um then yeah I guess that's it for today I'll put up the PRS for the Gordy uh Fork epochs um and we can uh yeah we can uh announce that uh next week when kind teams have have releases out but yeah thanks everyone and talk to you soon thank you bye-bye thank you bye

messages

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