All Core Devs - Execution #147

Transcript

thank you [Music] [Music] [Music] [Music] foreign

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

[Music] [Music] [Music] foreign [Music]

foreign [Music] [Music] [Music] [Music]

thank you [Music] foreign foreign [Music] [Music]

is [Music] [Music] here [Music] [Music]

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

[Music] foreign [Music] [Music]

Tim Beiko: um welcome everyone to this first post merge all core devs call uh all cordoves 147 um I just shared the agenda in the chat here um I think we'll try and keep it relatively brief today uh basically cover the merge some discussion around uh starting to plan for Shanghai um I guess I'll start by saying congratulations everyone I think the merge went extremely smoothly by basically all accounts um yeah it's been a while to see this happen on chain finally after so many

Shadow Forks already tested and to have it go off relatively without any issues basically so yeah congrats on all the time themes researchers testing folks who worked on this for years to make it possible um it was really cool to finally see it live on the network um yeah and I guess you know to start um I'd love to hear from just different time teams about how you thought went if there's any kind of minor issues you're chasing down or stuff like that that you want to kind of share uh with folks here um but yeah anyone want to share kind of their perspective on how it went um and and what they're they're

monitoring you're looking at now

Marek Moraczyński: I can start so we had many notes in our infra and generally all of them are working without any issues no transition issues uh what's more just after we hit transition I received some notes to confirm that our post merge sync is working and look very good uh so generally so far another mind notes are very stable post merge I haven't noticed any critical reports from users yeah that is all

amazing

um yeah basically anyone want to go next yeah I can talk or Basel uh we

Fabio Di Fabio: we had some uh issue just on the merge block uh some user have to restart the nodes to restart the syncing the cows are still unknown it was related to Bonsai when bonsai was used but the restart of the engine and the consensus flyer fixed the the problem mostly

[Music] then there are some issue related to some missed attestation from that we are investigating and also users that are reporting timeouts our notes are doing fine they are missing some attestation as well so we are investigating this part uh but uh they are in sync and uh following the the

Dead

Tim Beiko: awesome thanks um

someone from Aragon want to go

Andrew Ashikhmin: um yeah sure so I I think um most Aragon notes went fine through the merge but now we are hearing reports that if you haven't know that you try to restart after the knowledge or to sync uh after the merge then it occasionally becomes stuck or so it looks like we need to improve our post to merge syncing behavior and there were also a couple of other smaller issues that um appear to affect only like

not all the nodes but some nodes we are still investigating what's going on

Tim Beiko: got it thanks for the update um get

uh so for us the merge was surprisingly boring so we haven't noticed anything going wrong and Martin's essentially when I asked what Netflix is or what what is he looking at essentially his uh he said that the most interesting things about them I think are the Twitter and Reddit means so that's actually nothing we are not aware of anything that has gone wrong

will probably we do expect uh some people to have issues so it's a kind of a new world with different time combinations so I'm almost certain that some people will open issues on every top crackers and there's a fairly High chance that some of them could be legitimate so it's uh probably next couple weeks is going to be interesting just to make sure that it works

Tim Beiko: got it um yeah that sounds that sounds pretty pretty great overall um any of the CL teams on the call want to share uh from their perspective I see some prison folks take who

um I don't know if we have folks from other teams as well

Ben Edgington: if you want to fill some silence uh techu no specific um techie related issues all seems very smooth uh a lot of people seem to have pair techu with Basu so we're seeing similar reports of occasional missed attestations and uh empty blocks from time to time but it doesn't seem epidemic it just seems to be a handful of users and it seems to be exclusively uh with

Basu so it's basically looking good sweet um any other CLT monitor or

Tim Beiko: anything if not

um I don't know if someone wants to just maybe take a minute or two oh Micah you want to share something

Micah Zoltu: uh sure I think I was the only person in the world who had a problem with the merge um debugged and looked into a little bit and it turns out it's because I forgot to upgrade my execution client and install a consensus client which I realized after the merge I was like why isn't like light following and it was because I had spent the entire time prepping helping other people update that I forgot to do my own

Tim Beiko: I guess yes as long as you update your client things work um does anyone want to take a minute or two to kind of talk about uh just this the

state of the chain what we're seeing in terms of just participation rates um slots uh block inclusion and slots and whatnot um I don't think I see Perry on the call who's usually are are expert here but anyone want to jump in

um yeah Perry do you want to give a quick quick overview yeah in general we're not seeing um an unexpected amount of Miss slots we are seeing something like 98 99 at the stations so roughly 98.99 percentage of block cells being produced which is Big um we also do have relatively full

blocks and I think I saw a couple of tweets of people talking about um percentage of solar blocks in pow versus POS and eip159 Etc are working great so I think we look good

Tim Beiko: and yeah do we know can we attribute like this a one percent drop to anything um and I know yeah there was a little bit higher of a drop right when the merge happened I think we it's like we quickly hit like 95 ish um yeah have we attributed this to something or haven't had time to look into it yet

[Music] yours second

Tim yes hello yes yes we can yeah yeah that's cool um not

in here so one other thing regarding the the uh merge this old chain yes it kept producing and right now the four coin shows I think 25 blocks uh were produced and these are so these are produced by clients older than I guess one not 10 21 I think which are not configured for for the merge if if someone just uses the get client which is properly configured

but it doesn't have the the beaker node it would just Flatline but these are the data holes on that the timestamp with the latest block that I see on fourth one is two hours old um but we discussed that a bit earlier and Peter made the observation that right now for someone who runs old software and is mining the old blocks uh we'll probably have very large difficulties propagating them across the network because the most of the peers which have gone over to to dung the merge they will no longer propagate and announce the new blocks so it will be very yeah a very chaotic chain but apparently at least five

blocks now reached he's not that's that's 5 or 25 blocks just to be clear Okay so so 8 plus 25 but just interestingly the initially there were a lot more blocks being mined or propagated and our kind of our explanation is that once the transition was happening then uh the blocks were still being propagated and once we finalized the merge then the entire network just stopped propagating blocks and from that point onward it's semi impossible to get proof of world blocks from one minor to the other and back so our expectation is that currently if

there are a couple miners still mining on the old chain they are most problem mining their own visual worlds and if they and these worlds will collide if they connect so it's it's a

bit of a test has

Micah Zoltu: the proof of work awesome Network um partitioned from the state custom Network like they're no longer communicating

I don't know so there's no so the partitioning logic is based on the fork ID and that's not yet

uh come together for me that maybe that's something we I don't I haven't seen that again I'm sorry but maybe that's something we could talk about today yeah

Tim Beiko: yeah and I guess uh

yeah just to make sure there's nothing else on like the actual merge itself we can finish that but yeah I think after that we could we can discuss uh yeah uh the the kind of fork Fork net split block for sure um but yeah just before we go there was there anything else anyone saw on chain or with their client uh that you wanted to share oh okay uh in that case uh sure if we want to cover quickly um this Fork ID chain uh just for context uh for folks listening uh usually when we have a network upgrade

the peer-to-peer Network gets automatically disconnected from non-upgraded peers and we use blocks to determine this um but because the merge was triggered by TTD and not a block height uh the kind of mechanism we usually use for this uh does not uh does not work and so we need to like retroactively have it or after the merge we need to have another Network upgrade which simply changes the fork ID at a specific block we've done this on a couple of the test Nets we have not done this on Gordy yet I believe uh so I think if we and and we've obviously haven't done it

for mainnet so I think if we wanted to to kind of set this it would probably make sense to have it happen on Gordy and mainnet roughly around the same time so that uh people only have to download a single release and both networks get upgraded um yeah I'm curious what people think about this generally like when should we do it um yeah what how long is it okay to have kind of the network uh not be partitioned uh by Fork

ID

uh okay so maybe oh sorry please

can you repeat the question

how

Tim Beiko: how quickly do we need to do this right like um do we want to like aim for a specific uh block height like today and and actually implement it or is this something that could wait say after Defcon and it'll be all right

um so essentially the the reason the whole Fork I gave this to this to cleanly separate networks when uh most nodes do not upgrade so essentially mostly test stats in the case of maina we historically always updated that for the merge I'm assuming almost everybody's already updated so

perspective there's no particular rush because I mean for us it's super healthy um the only thing we're really unhelpful about is the old group of world chain but that doesn't didn't really apparently so so I think it's completely fine to wait until whenever it's just it would be nice to finish the upgrade finish the merge completely so the same if there's no rush to oh sorry Danny yeah is there another like if that's the logic should we not just wait until the next hard Fork on the main nut because otherwise there's a chance that users fall off when there's nothing really

that we you know the cleanup doesn't seem requisite and so maybe the cleanup should actually just happen on the next forced coordination point which is the next hard

Fork

so the weird thing is that this thing was already rolled out on at least sepholia I'm not sure about girly maybe even girly so we kind of ended up in a situation where our testnets have a different Behavior than maina subset yeah sure yeah and I I guess if I was arguing to only do it on the next hard Fork I'd say actually still clean up the chestnuts but if you think the Divergent Behavior there is not good or maybe not even a good president then

I mean what

those

four kind of supports a completely fine to so to say do two works in the same block from for Patty's perspective so you could just say that okay the next thought for I think that's Shanghai that would apply both the Shanghai update and also the merge Netflix for Academy so that works a big wonky but yeah I mean it it's fine

Micah Zoltu: I assumed we would just skip this work ID and just do the Shanghai

radio

we can't skip them but as Peter said I mean if we bundle them together then effective it will be

skipped

Micah Zoltu: yeah okay

Tim Beiko: because yeah the clients expect a block for this right

yes I mean you know in here we could typically just uh from a client configuration perspective it's uh it's weird that the merge we actually applied the merge and then some part of it is just missing because we figured we don't need it it's just wonky yeah I guess but we'd be fine to apply it together with strong high and then it's the same thing as a liquid

sticker foreign

Tim Beiko: yeah I think given there there's always a risk like Danny was saying it's like users you know mess up when they're upgrading um if there's no strong reason to do it before Shanghai I personally would also

rather have it just bundle like do like a double Fork on the Shanghai block um does anyone have like a stronger objection to that

so one one thing that we need to keep in mind is that um currently we're talking about uh two chains here one of them is the merged super stake chain and the other one is the left behind that book of world chain and in these cases basically nobody is running the old chain or probably sticking enough many people however yeah the changes have not been named you still have uh so if there if another alternative chain pops up then this

discussion might need to be reconsidered so that's the only uh assuming that they don't do this upgrade properly for themselves uh I'm almost certain that they will not so so anyway so I love tldr I think it's completely fine to postpone doing this until Shanghai as long as the climate change change doesn't change I think some weird change happens and we can always

reconsider foreign

Tim Beiko: reasonable to me anyone disagree strongly with that okay

um and then related to the merge I think Chris uh hagger uh from the flashbots team wanted to give a quick update on uh a museum boost

um yeah Chris yeah absolutely from our perspective the merch went well we waited the 16th box enabled petting bits and uh we are seeing no problems and I just wanted to bring out the topic of adding a SSC subscription to the beacon notes that allows Builders to trigger log work right now we are using a custom start and it would be nice if you can put just headphone SSE subscription

Tim Beiko: and this is to the beacon note correct

Chris Hager: yes it would be an addition to the beacon notes so um to trigger lock work on whenever a new payload event is received and that would land itself nicely that could include the Builder attributes we are currently using a decode here and this is um this will just be sent out like once a slot it would be really beneficial and there is more and more Builders coming up they would all cross it from just having a subscription

Tim Beiko: so I guess just because we don't have all the CL folks on this call and I

suspect no one has had the time to think through it maybe the best way to go about this is if you can maybe put together like just a short like summary of what it would look like like either like as a an issue of pull requests and we can maybe discuss that on the CL call next week in more detail and people will have time to review before

then does that seem yeah absolutely yeah I yeah totally yeah thanks cool and otherwise things are looking fine like we are not seeing any any excuse on the map was relays at the moment nice yeah on the on the flashbots relay we've seen how many how many blocks come on the flashlights really is

storing the the term served 176 payloads and there is 6.5 Charles and registered proposals which is about 15 of all the proposals that are connected or have connected at some point nice okay thanks sweet um any

Tim Beiko: anything else related to the merge um oh andgar has a question about uh

history duplication for execution payload um and what the status is on that and God you're going to take like a minute to just

share the background

Ansgar Dietrichs: I'm not sure if it's the the list when you put it just was wondering um because it's talking to some sales people earlier in the morning and then basically just I think of my understanding is correct that basically right now um because the execution payload is part of the beacon Focus course it's it's being stored as part of the beacon chain history by the CL and then of course the execution pellets passed onto the El and also stop there as history so right now basically on any machines uh running both nodes um you basically just store the the

execution period twice I think um ideally of course at some point we would want to have some sort of deduplication strategy where it's only stored two sides of something so just wondering when I guess for me that's broadly like post merge cleanup and so now that we're a personalized is wondering when when would be the best time to kind of talk about these things

Tim Beiko: and I said Terence has his heads up yeah so um I can speak on behalf on behalf of prison we do not claim we do not plan to duplicate them we have a flag flag to basically store the Blended version and that is currently um not enabled by default because we

wanted more testing I think in our next release we could um being able by default but yeah pldr is that we don't plan to um duplicate them but prism prism uses kind of a the eth API to do so it doesn't have support and like a more optimized way from say the the engine API right that's right yeah I believe Lighthouse as well yeah I mean you know I think I think the conversation then becomes is the um the the pr that yasik put up quite a quite a while ago you know is that

even maybe an optional um endpoint on the internet API is that something that we want to move forward with or is The Ether API sufficient or you know I think I think that's that's the more interesting question I do I do I'm glad that you all are able to do the DJ position now but I think we want to have a competition on whether it's should be elevated in support

Ben Edgington: yeah on techu side we have shelved this for now um because we really don't want to pollute the uh Beacon chain side with rlp encody and all of that what we would really like to see is an API on the engine API which just delivers a payload

in rlp then we can rebuild the you know with the transactions rmp encoded um so that we can just rebuild the block from the blinded block so we've done all the kind of database work on our side and we can store blinded blocks but we can't reconstruct the full block without a specific engine API so that's that's where we are right so I would I would suggest we revisit yasik's PR over this next week and then decide on the consensus layer side if this is um if that's meeting our needs or if we need to modify it now that we're kind of thinking about the blinded blocks um and then also Loop then execution

layer folks you know over the next couple of weeks to then decide if it's something that can be well supported over time and maybe something that we can add as optional um I guess that's that's also probably a debate discussion Point um but I think that we can have the consensus layer side of this uh conversation probably over the next week if

y'all are willing no objections um sweet anything else related to the merge okay

um if not uh the other kind of thing I had on the agenda is um um on the recorder channel did you see that I'm sorry what uh art and Morocco yes we should set the house a certain number and instead of TT TTD

Tim Beiko: um it's certainly safe to do so independently in your client um because this cannot will not be reverted um

I guess then the question is you elevated to specifications and is that worthwhile I don't have a firm

um so the one thing that I would avoid reinterpreting this is that at least current for for gas the the 4kid is tied to work block numbers so if I were to just now retrospectively add that then I'm all of a sudden also affecting changes on the fork ID so there there are these considerations to make that the there might be some people links between

uh

okay yes but um when we do the network upgrade

Tim Beiko: so it's almost like the clients could use the four block internally to do things better but we don't want to advertise that on the peer-to-peer Network as an actual Fork block because then um yeah we're effectively doing this Fork ID change retroactively and losing peers

yeah but so but the problem is that if you want to get rid of the DTV then

the engine API has no friends of the tpd the previous message right

if somebody wants to transition a click or a work Network you need the ocean ptd so it's uh I think it would be a huge kind of form to just redefine the merge after the fact yeah I didn't I didn't want to um I'm not a proponent I just wanted to erase it because the article had mentioned it I want to see what people thought about it so my two senses that we can definitely think about it but I think it has more implications than immediately obvious right yeah and I guess maybe it could be complementarily added

somewhere um when ready to do a network upgrade on a merged network but probably shouldn't subsume

this foreign

Mikhail Kalinin: it probably makes sense to check that the remote Pier that you are connected to has a certain block hash at a certain height just to prove that it's on the right chain if this thing starts from scratch I don't know if it makes sense but probably the

Tim Beiko: I guess given that this is you know first a client thing is this something that say a cooler can prototype and

Micah Zoltu: see if it can

work it doesn't the execution client and the client share ttds with each other right now oh right they would need a prototype under the CL as well so that is one minor thing that did come up is the exchange um transition configuration some consensus let our clients turned that off I believe at finality and some did not I think the spec was maybe didn't say to turn it off but some thought there's no issue and so I think one of the extremely minor issues seen was some users seeing errors around not having that exchange configuration so there's already a little bit of a hiccup

to that so them okay

Micah Zoltu: can we just remove it like make

that the way to go forward is all the sense of Clans and the student client removed that exchange is that safe yeah to clarify there were warnings um so not errors but yeah um I think it's probably reasonable to add a little note that it can be turned off at finalized

[Music]

so one thing that get at least uses that exchange is to detect if uh consensus client is online but is not yet synced so we've added a lot of different warnings to try to detect uh different misconfigurations or different issues on the consensus client side and currently

if we don't see any messages from the consensus client and we try to warn the user that it seems that they have to satisfied is offline however if we see poor choice sorry we see these PD exchanges but we do not see consensus updates then that would mean that the client is online but is not yet synced so there are a few things that we can deduce from from these messages now if we were to remove this ddb Exchange as the beacon client is not yet synced then essentially we would lose all communication so because that's why I wouldn't have anything to tell us until it actually syncs up so from our

perspective it would be like it doesn't even exist so this is again it's a nice side effect that little heartbeat chatter between the two clients so you could we could definitely remove it but then it might be interesting to consider um adding some API to somehow try to diagnose or or detect if something's almost wrong or something's just or if something is correct but odd is there a reason that the consensus client doesn't heartbeat with the execution plan right now I think there wasn't really a reason to

do it it's more like we if for us it was super annoying that we didn't know from from the get lost what's happening whether some people who were actually running the the girly the supports they were they kept opening issues that Gap is stuck that it froze it's something and it was very annoying for us because we always have to figure out okay but okay is it really get it that is stuck or is the beacon kind of doing this data and that's why we added All These Warnings so that the user can actually see that no get seems operational and the weaker client seems not operational and I think it was it's just a user experience nice it is it's not really needed for

anything and I'm assuming that's why it wasn't really ever added because there was no need for it

I don't know

Micah Zoltu: that what you describe sounds like a pretty strong need to me um just having the test client regularly say hey I'm here and this is my status like I'm doing this like I'm synced or I'm sinking or I'm initializing I'm just having that information of the execution client allows extra client to give better information to their users which is valuable

I kind of agree so I think it would be nice to have some cross uh I mean the consensus client can always uh query us because they have the apis but the other way around you know so maybe it would be nice to expose some

some synchronization synchronization state from the sentence side and back down to the execution right so we can have also better logs so I'm all Force backing that out it's more meaningful

remain synchronization like a sync process status propagated from cl to El we don't imagine any

any sort of information in there but that's the one that immediately into my mind is just like the syncing status initialization status so the life cycle of accessibility right is you you're doing boot up you're initializing you're setting things up starting your services then you start syncing and that's going to take a bit and then you finally are synced and you're following and just

having at least those three seems like a good

starting got it

so the only we can debate what information will be useful just the idea is that since the consensus client is driving the whole thing uh the execution clients they only they don't have any option other than to wait for information to arrive but if no information is arriving then we just don't know what to do we can't even print anything to the user whereas if some status updates were periodically shared that at least we could we could decide whether everything is fine or or something's wrong

I think that's useful

Tim Beiko: I guess what's the best place to like spec this out um or continue this conversation

further yeah probably an engine

Mikhail Kalinin: API execution API yeah sorry if you're a PR okay yeah so I guess at the very least you can open an issue there um highlighting some of these concerns

and yeah then we can add a PR to the engine API

and I guess such a thing could be rolled out even um

you don't need to synchronize across the client to roll it up we could Define this optional endpoint right my optional I mean that eventually it would be part of the spec and everybody should implement it but it shouldn't be a problem if a client doesn't stick it yet and then you could just everybody could Implement whenever they have time and then eventually it

will all adjustable together

Tim Beiko: yeah and I think this also uh kind of leads into the conversation around like versioning the engine API which was sort of happening in the in the chat in parallel um yeah so thinking about how we want to have optionals uh and potentially different just versions of the API

so with versions I I'm I don't want to say I'm opposed to versions but I think we should really really consider if it's really necessary yes because the moment you introduce versions the moment uh it happened that okay the clients need to seek multiple versions and then okay guests can speak version one to F3 and then prison can speak version two four and six and uh you might end up in real scenarios where it is right and some weird incompatibilities so if we want to do versioning I would say that maybe you should just use versions at a temporary

or quick path but we should not really plan on supporting more than one in the long run

ever because

Mikhail Kalinin: when I was like thinking about versioning I was like thinking about something similar similar mechanism to what we have in the sub protocol with like support and the version that I supported by the REM the counterparty so it should be some Exchange what version is supported by CL and El and whatever is the minimal version of the two should be used for communication but you

also should consider hard Works um um so and yeah optional methods and methods that that are not related to um directly to like consensus stuff um like uh these did application of um payload bodies they are like um kind of not going to be affected by any hard work and they can be deprecated as well and some new methods can be introduced and this is why I guess we need versioning yeah but I I think we should take this discussion um from this call into an issue or a Discord

it's like gonna be a long one

uh just a very quick response to that I think the East packages versions is a perfect example of why versioning is bad and specifically there was a point in time when guests both at least four or five different versions of the protocol and every single other client spoke a different one so we essentially the only way we could stop supporting both clients is that we went on the ACD course and the research this code and we just announced that okay you guys have one year to fix this one and a half years to drop this and three years to drop that and we just enforce that so we kind of use that way to deprecate the

old protocols and uh and that was super bad from that perspective because all these old protocols have different data models and then our database we couldn't upgrade our database because we had to serve some other clients on some weird version of weird old Legacy version of E so that's why I was saying I think we want to use conversions to add a temporary upgrade so that's okay while we are holding up version two you can also use version one that's completely fine but I think the we should really force people okay after everybody I'm doing it to version two that's the prop version one so it should be more like a transition tool rather than supporting in the

long term more performance

Tim Beiko: okay so yeah and we can continue this uh conversation on on the engine API repo um any any closing comments on it okay uh anything else on the merge okay

um so uh with the Verge uh behind us basically we we kind of held off discussing Shanghai uh for the past couple months too much because uh we were all quite focused uh on the merge

Tim Beiko: um I think on the last CL call uh we we

discussed that some teams feel like taking a well-deserved break right now might be the way to go um and potentially having less uh less awkward devs over the next month or so for the CL folks have agreed to already kind of skip the call before and after Defcon uh obviously we'll skip the call during Defcon itself um but that gives us at least you know three weeks and potentially more like five if we decided to also skip the next awkward devs um where it would still be good to try and make some progress on not necessarily like deciding exactly what goes into Shanghai but at the very least understanding what are the different

things that are being considered and how we want to like first of all are those things like technically sound um you know are there any issues with them um and then you know are there like higher level priorities that we want to focus on um and to perhaps try and have this happen a bit more async that we usually do um so I've put together a proposal on eight magicians for this um at a high level um we could use each magicians as a way for eips to signal that they'd like to be considered for Shanghai most cips already have uh East magician's thread because uh that's where discussion happens anyway um and basically we can we can kind of keep this list as a reference point for

client developers and researchers to look at um and and kind of dig into the different proposals um and I think if if there's eips where we feel like we need to have like a deeper discussion or something like that we can organize ad hoc and kind of breakout rooms with with the people who are most interested in them um and and kind of share those um but kind of have a month or so where we're not necessarily having like all quartets calls or CL calls and making explicit decisions uh about what goes in the fork so people have a chance to just take a step back um rest and also consider things from a bit of a higher level um and then there were a couple like other ideas around like potentially just

having like using the Discord party Lounge when we usually have awkward ads in the CL calls for people to come and chat about this stuff um maybe having an extra Discord Channel as well um but I guess I just like at the higher level I'm curious like how do people feel about just taking roughly a month um and and not having these call schedules and trying to do this a bit more asynch um any thoughts there I see and Scar you have your hands up

Ansgar Dietrichs: yeah just uh what do you want to say I think in general that makes sense I just uh think it's important if we want to have this a bit more like a relax time where basically people don't feel like they they miss out on decision

making and I think it's important that we actually also kind of structure it that way so that basically um if we I basically I would be worried if we go too much into actual kind of decision making territory asynchronously uh basically like including high level priorities like what what what what kind of kind of work should Shanghai be all these kind of things I think are better left for them once we return to to synchronous communication um and also like Erp discussions is basically people have to be afraid that if they miss out on those and then they come back and all the decisions are on the erps are already made I think then it basically negates the purpose so I think kind of if we just leave it to opposing all the earps that are on the table maybe going into them a little bit

checking them on soundness and whatnot but like explicitly try and refrain from from kind of like talking too much about relative priorities and um and um what should and should not go into Shanghai I think that that would otherwise I think it kind of

loses the point yeah I yeah I agree there you like I think the goal is you know you don't want people to feel like they have to show up does all this optional stuff because

Tim Beiko: that's that's worse than our status quo um I think and to be curious what I meant for like having calls about specific eips is some of them do have like technical things that dig through and you know like I'll take an example we've been doing a lot with 4844 recently um it's not about like does this go into Shanghai or not but it's more you know

there are things with the EIP that still need to be specified or whatnot and um that's that's more like the the end goal is to give up

Greg Colvin: I know I just strongly suggest that people go and start reviewing eips a lot of a lot of them have been sitting there for a while so people could have forgotten about them and asynchronously people can get looking at the eips on The Magicians and start actively reviewing them I think most of them are at the review stage or very late drafts and that's something we can do asynchronously and will really help on

the decisions

Tim Beiko: yeah I think I think that's that's reasonable I shared the link uh in the chat about the eips that have already signaled this there will be more because first of all we hadn't really agreed to this yet and and I'll also make sure to reach out to anyone who'd like previously signaled for Shanghai uh to make sure they're like aware that this is what what you were doing um so you could expect this list to grow in the next like week or two um I guess is anyone like strongly disagree with this approach if not um I guess in terms of just like

Logistics um I think we we agreed to keep the consensus they were called next week um because um first we have stuff to talk about but also uh in case you know we see some merge stuff coming up uh you know in the first week of adoption it'll be good to have this this place of discuss things um I would suggest that we kind of remove the Awkward devs on the 29th um unless obviously if there's a major issue on on mainnet you know some sort of emergency level thing we can we can always bring it back um that we like default to remove it um so that we that would mean we basically get a month async so we would have um this this call on the 22nd of

September uh then no call on the 29th no call on the sixth uh Devcon is the week after that no call on the week after Defcon which is usually a bit slow anyways and then we would resume all core devs um two weeks after Devcon um does that sound reasonable to people okay I will go with it if there's no objections um and then I think that the last kind of bit um was uh Mika you've advocated for like a a Shanghai planning channel on Discord um I think the pro there is obviously we can maybe move the conversation a bit forward

um in the meantime the con that I can see and why I'm a bit hesitant to do it is um again if if we're like forcing client teams to Monitor and that if they're not looking at this channel they kind of missed like you know a big decision about Shanghai that might go against like the purpose of things um we obviously have all core devs which we can use to discuss this stuff already um but yeah I'm curious if client teams feel strongly that like a channel like this would be quite beneficial or um actually potentially like harmful or distracting just because uh they then need to monitor it and and make sure like yeah they haven't missed something there

Micah Zoltu: so I think it uh having this channel I

would like it even if we do take a break um like once the break's over I think having the channels there is valuable um not necessarily just for during this break yeah okay I personally okay yeah I would support it much more strongly if we only turn it on after the break basically um so that we like for the next four weeks client devs don't feel like they have to monitor that constantly and like otherwise they missed like this scope and shape of Shanghai changing but then when we actually get talking about that I I think it's reasonable to have such a channel yeah

any

Tim Beiko: and anyways we can reconfirm that in a few weeks but like this anyone else have a suggestion or strong opinion on this okay um yeah and I I I I posted um yeah okay so I posted a link to the east magician's thread um on the agenda for today um and and my guys according to the chat that we could just shut down all that Discord if you want to force vacation I don't think it's like necessarily forcing vacations but I think it's more like we can have people spend time on you know what they want and if that includes vacation that's great and also feel like

if they're not following us closely for two weeks they're not missing like oh this major EIP got included in Shanghai and

yeah if

Micah Zoltu: it feels to me like we could there would be value in having a place to do to talk about these things so that way once we do start a Shanghai plain officially we've already like work through some of the conversations that are likely to occur there would be I'm totally on board with no decision-making power yeah happening during this time but I still think there's a value in those of us who don't take vacations being able to go

and

Tim Beiko: I think that's these things I agree I think I would use a party Lounge for that so I think we can have like an unofficial meeting uh weekly at 14 UTC

in the party Lounge on Discord um and they're very much are people who want to work on this stuff 20 hours a day seven days a week uh 50 weeks 52 weeks a year so I think yeah that's fine as well um I think we can yeah have like a a soft chicken or like a soft agenda to use a party Lounge when we would usually have the courthouse or CL calls um and anyone can kind of join there and discuss stuff does that make sense no objections oh take it as yes um and then the last thing I had somewhat related is um at Devcon we're putting

together another session similar to what we did in Osaka um to kind of have a conversation about um the ethereum roadmap to kind of answer questions from the community to have people who like want to talk about specific core eips um have a chance to organize um so if you're a client Dev and planning to attend Devcon um it would be neat if uh at least folks from like most teams could send people for a couple hours of this um I think the community really appreciates when we have these in-person sessions it helps kind of clarify a lot of the things we do here

um yeah so I've posted again the link uh to that in in the chat um we don't have a specific time uh but I think the Defcon schedule will be going out in the next week or two so um once that's out I'll share it there um but you can expect it to last a couple hours and be quite similar to what happened in Osaka was there anything else anyone wanted to chat about

okay yep please

request if we are uh eventually when we are back to

discussing Shanghai and uh and essentially going forward is that uh because actually we've been filing a lot of complexity in the whole system with these uh with the merge and it would be nice to also just pause the moment and try to figure out what thing this merge allows us to to now remove from the from the clients and one specific thing just to give an example is that essentially after the merge uh everything that's related to EP hash can be essentially removed and deleted from clients however most times still implement this pluggable consensus system where you can

have proof of work or you have proof of authority and now and after first take however if we were to take this one step forward and create a group of authority like Behavior through the engine API that essentially executionally your clients could get rid of their entire bloodable consensus model which would be a lot of code thrown out the window so for example this is a case where it would require working a bit and creating a timing spec for running a group of authority to be contained so don't you say but in exchange it would allow removing a lot of clothes from from the from the execution clients

so I think it would be nice to in the shortish term future to try to focus on these kinds of things to where we can not only keep filing new stuff on top rather also try to cut existing stuff out that are not

needed anymore

Micah Zoltu: is that something that someone could do like as a hackathon type project where they basically spin up something that looks like since a client from the point of view of the execution layer and it's but it's just a proof of authority

thank

you I think yes so I think it's uh probably you need to think about it a bit and uh my assumption would be that it would be

some it would need to be somewhat similar to click just operating on the on the engine API level but if somebody were to think through it I'm more or less confident that it can be done in a fairly short amount of time

oh uh Proto I see you have your hand up yeah

Protolambda: so this is exactly how you think about layer 2 as well using the engine API to not have to modify gov or other execution layer clients as much and rather create the block production and the consensus outside of the nodes and if somebody is around during each Berlin then I'm definitely down to help Port

Arthur Clique to switch external

software super foreign anything else okay well I guess we could wrap up um yeah again congrats everyone on the merge um amazing work it went down I think more smoothly than even people here expected um yeah it's it's been great and I'll see some of you at Defcon and otherwise uh

see everyone here on the Awkward devs on October 27th foreign everyone cheers bye thank you thank you bye bye everyone [Music] foreign [Music]

[Music] [Music] [Music] foreign [Music] [Music] [Music]

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