All Core Devs - Execution #166

Transcript

foreign [Music] [Applause]

thank you

Tim Beiko: welcome everyone to acde number 166.

um so we have a lot of uh basically PR updates uh reviews um and then there was some process stuff around the whole eiprc that conversation and then naming uh just a shout about naming the next upgrade um I guess maybe to start um does anyone want to give an update on the state of dencoon devnets and implementations

thank you here

Parithosh Jayanthi: I can go um with that uh we still have devnets have been up and running um we're updating the tooling a little

bit but blob scan is supposed to work now the issue is that um it took so long to get it working on our infra that we've already started expiring the old blobs like the first couple of days of blobs have expired so we can't index um the beginning few days and blobscan doesn't support starting indexing a delay data stage so we wanted to ask which clients already support um like an archive mode and I think Tech who already messaged with with the flag that they use um so we're going to be doing that but we can't do anything about the ms7 so we're going to have that for definite eight onwards

um besides that we did a tiny Shadow Fork of sepolia this week um it doesn't really mean much because it's a very small subset of clients there but it already brought out maybe one or two bugs in Genesis that um that we deal with and we're still getting the tooling up so we'll do like a bigger analysis of how things are going how blobs perform there and stuff like that over the next couple of days and I think in terms of The Next Step net um the first step is getting high and getting all the client images in Hive so only then would we start planning that next

week

Tim Beiko: awesome thanks um do any of the client

teams want to go into detail about some of the issues or they might have seen on their ends or like progress that they've made

okay

Tim Beiko: um if not I believe we have the 4844 call uh next Monday as well so we can also spend time there and uh yeah dig into the details and and make steps around devnet8 and I'm I'm I'd be curious to hear also from client teams um has anyone started implementation on the rest of uh Dan eips uh so

obviously 444 is still the main one but like what's the general status for um yeah for other ones

uh merek

yeah so for another month's height we implemented uh all of eips and uh only we haven't merged yet for 798 but it should be merged soon to the master

Tim Beiko: nice uh Andrew

Andrew Ashikhmin: yeah yeah so um sorry I'm on holiday this week but I'd like to say that we we still are catching up on 4844 so uh so hopefully next week or maybe the week after we'll

be able to uh finish with 4844 and then pass the fire test uh We've implemented a couple of other oops I think 1153 and one other with with M Copy was it was that and copy yeah I think we have uh the beacon State Route in progress and uh yeah I don't think we've done this self-destruct yet not yet but uh but my question would be which like which heaps do we want in the in indefinite 8 like

all of uh Cancun if some idea subset besides

for 844

Tim Beiko: I was just on vacation as well so my memory might be a bit old here but I believe we said we wanted all of them um but Perry maybe correct me if I'm wrong

Parithosh Jayanthi: yeah we wanted all of them enough for posted a tiny um link with what what all of them means like which commit to Target Etc

awesome uh

uh Justin phase two

Justin Florentine: is uh making progress on the stuff for eight we have the beacon route uh in progress we already have the updates to receipts to include data gases and data gas price however I just noticed that that PR has not been merged in yet so um if we could get that finalized that'd be great um yeah so uh pretty much same status oh the yeah yeah Beacon route stuff is in Flight as well

Danno Ferrin: also M copies and T stories in self-destruct is pending specification clarification but otherwise ready to go in

Tim Beiko: awesome

Gajinder Singh: only tmgs side we have sort of ready with the definite expect just a small PR that is spending regarding to uh frog Choice update 3 and also with respect to that uh I mean I I opened the simplification pr uh which I would like to talk about regarding again the engine API method for uh for new payloads

Tim Beiko: cool let's yeah let's cover that right after we finish the client updates um I don't know if I think Geth on the El side is the other one missing

anyone from Geth want to give an update and yeah on the CL side uh yeah don't necessarily want to put you on the spot but if anyone has updates they want to share uh you can definitely uh cover those as well uh through Lighthouse we've got the devnetic spec implemented we're just in the process of reviewing it right now

so Lotsa is also almost ready with definite it's back

and potato side

we are ready the only thing that we are implementing now is the new publishing API for supporting the broadcast validation option but I guess it's not super important for running the metatn case but this is the only thing that we are working on

Tim Beiko: got it um anyone from Nimbus or prism and the colon um anything else uh on the dev natural implementation status otherwise we can

move the engender's pr

and

just uh clarification uh should override Builder flag I guess should be added to devnet 8 spec

Danny Ryan: yes that's what we talked about on the consensus player call last week I can't remember if we talked about it on like execution that I call before so it can easily be a no op but it should be in the

intervals

Tim Beiko: cool uh Mario I thought you had your hand up for a second

Mario Vega: yeah this is my update um we have um that's ready for obviously for the A4

for that was eight and 6780 which is a self-destruct summary and copy is ready also but we're still working on 47 88 and tracks in storage tests but should be running the following couple weeks nice um yeah

Tim Beiko: okay uh do you want to talk about uh the parent block route engine API PR

Gajinder Singh: yep so basically in new payload what's happening is that the payload that is coming from Beacon not uh it it now

doesn't have a parent we can block root but then there is a separate param that comes with the pair and we can block route so El basically then can marry it to create the for the full payload but but uh I'm trying to propose as a simplification uh so that you know that become blocks execution payload itself will have should have a parent we can block route so that there is one-to-one correspondence between uh the uh data that is on the beacon block as well as uh the execution block that gets constructed out of it uh so it is

basically helpful in the scenarios mostly in the scenarios of debugging where basically you know we are debugging something we want to construct uh we want to run a block execution block uh and we just want to extract data out of from the we can block and uh so basically of course we can still marry parent become parent we can block root from there but I think it is quite handy and also quite clean that parent begin block route exists as part of uh the new payload uh payload that we get

Danny Ryan: so there's a couple things here like you could either change the consensus data structure

or just change the engine API so which would require some more translation in like constructing the data structure when calling that method we did as I linked to in the consensus PR that you opened up we did debate this before doing the release It ultimately came to kind of an aesthetic sensibility do you duplicate this field and thus have kind of this internal data structure self-contained or do you gather it from the outer commitment um we landed on don't do the duplication and some people thought okay well that's okay but it's

aesthetically nicer for it to be self-contained if it's actually a pain debugging um and the aesthetic principles have been elevated more practical principles um I think it's totally fine to cut another release with it we're gonna have to add a few tests there's an additional line of code in the validation to make sure these two things are the same thing but ultimately I think it's fine if consensus devs or others wanted and we didn't have too much of a reason in either direction before the latest release

Tim Beiko: and does anyone on the Yale side have

any thoughts on it

Danny Ryan: because the longer we don't do it like if we have a devnet with this in there then people are going to create tooling for the workaround and then all of a sudden it's going to be worked under you know it's like yeah the longer we have it the more people are just going to figure out how to deal with it

Tim Beiko: so I'd like to figure it out soon and I don't know there's a couple CL teams on the call now but not everyone like can we maybe is it too long to wait until next week

to like have it fully agreed upon

Danny Ryan: yeah I just I wonder when devnet 8 is because doing it before definitely it would be preferable to doing it after right

Tim Beiko: I guess yeah I'll get two questions at Perry maybe oh okay let's try and answer his own question so only like do we expect to have devnet 8 up before the CL call next week I I would be surprised if so I think that highly doubt that

Parithosh Jayanthi: yeah hey yeah I think real estate it'll be the week

after okay so if we got free signal on this call and from the pr from everyone else before that call and essentially on the same day cut the updated release in one week time would that be okay or do we want to try to expedite the decision

asynchronously

Tim Beiko: yeah I think go ahead Perry

oh sorry

Sean Anderson: I was going to say I think it'd be okay to like expedite expedite the decision async because it is sort of just an aesthetic change and it's just like

requires like a little bit of leg work I guess um my two cents is it it is nicer to conclude Ginger's PR and like add the field and uh makes it like a little bit easier but I'm also I haven't been implementing this it's been marked so he'd have a little bit more inside than

it

Danny Ryan: okay thanks can we just get does any other consensus layer team have feelings either strong or weak in either direction and then I can knock on doors after the call to see if if it if we get positive all around we'll try to cut it release more like

Tuesday to unblock this uh but yeah if anybody has a vocal opinion please say so

now

Tim Beiko: okay I guess there aren't so yeah let's try to uh get some feedback on it async and uh at the latest uh yeah finalize it on this y'all call next week

Danny Ryan: thanks

Tim Beiko: um sweet uh next up uh Dano you had a clarification uh PR about the

self-destruct VIP do you want to get some context on that

Danno Ferrin: sure so as I was working through implementing it for Basu and integrating it with the execution spec tests um Three Corner cases that weren't really clear in the EIP uh were discovered and this EIP makes them explicit these are currently reflected in the execution spec tests and in at least basically when I think other clients that are following it um the first of the three items is to separate the notion of contract creation from account creation now this is a situation where he would send money to an address and I call those Hollow addresses you don't know whether it's externally owned or a contract um so that exists prior to the transaction so you start the transaction you do create two into what that address

turns out that address is it creates to address um and then you self-destruct in that case um I think the spec should self-destruct that address because the contract code that's going in in the storage didn't exist prior to the transaction um so that would basically separate the notion of account creation from contract creation and what 6780 tracks would be contract creation when you actually call the create operation or if you actually started in a create transaction so that's the first clarification that's reflected in tests right now um the second one is they're the corner um where you can actually burn ether with self-destruct if you self-destruct and you set yourself as a beneficiary currently that ether just completely disappears because by expect the last

step is to set the balance of the self-destruct contract to zero um so this would change so that you only destroy ether if you're destroying a contract in the same transaction so if a contract existed prior to the transaction you did the self-destruct and you point it to yourself all of your balance will stay in your accounts so it wouldn't self-destruct it um now we can't get rid of it because it turns out optimism depends on this feature and they do depend on the in-transaction create and Destroy Loop of a smart contract to to burn The Ether and this is in their L2 so there are people out there using this feature we can't just get rid of the burn feature um so that's not something that I don't think is is good to do right now the final step is to say that

self-destruct always halts the current frame I think that was an oversight in the first one that was always the intent that if you do a self-destruct into what's going to be like the new sweep mode that the execution then halts at the end of that self-destruct so that just puts in a line clarifies that the tests have always reflected that so that's just worthy of them of clarification so those are just three things that are you could argue that those were the correct behaviors but it's much easier just to put those into the spec and say no these are the correct behaviors and to make it clear can optimism not just activate

EIT

Tim Beiko: so I guess before we go into the optimism discussion I just want to clarify are are the first and third bullets just you're clarifying you're

clarifying the current semantics and then the second bullet is one where we may want to change what the current EIP actually does

Danno Ferrin: the way they're they're all three of them I think are clarifying current semantics because the second one is really an emergent property um because the burn comes from the set to zero um only in the internal transaction um so I think that that you know if we were that doesn't really represent a change if we were to change it I would say that it would fail for self-destruct itself in a transaction if I were to change it and get rid of the burning um so I would say that all three of them are clarifications of semantics and those are the most likely

interpretations but you know based on readings you could get different readings of it uh the halt I think is absolutely needed as a clarification because I think the best reading is that it does not halt

Tim Beiko: okay so there's some comments on like the the the burning aside from that does anyone and we can we can cover that after but does anyone have any comments or contentions on the two other points so the contract versus account creation and the halting uh the cult is everyone agreed that those two clarifications make sense

I guess if you disagree now's your chance to race that okay so I guess on the on the destroying one um yeah just for context because this was posted in a previous it wasn't posted on this eip's thread but on the previous uh self-destruct uh EIP thread so I believe that sending um like self-destructing and setting yourself as the beneficiary is how at least optimism and maybe other day or two's basically manage uh withdrawals back to L1 so how they destroy kind of Supply on L2 as they send it back to L1 um and there's a bunch of comments in

the chat about this um and it's not clear you know it's not clear whether this is like a major deal breaker for l2's or not but yeah this and I guess yeah Mario has a comment saying if we rename the app code to send all it's kind of weird if you send it all to your own address that they would then destroy the ether um that seems yeah unintuitive yeah any thoughts on how we should approach this

Danno Ferrin: so the op code wouldn't be sent all when you write in a transaction it's still a

self-destruct if the transaction exists so we can't go there yet so if we get rid of this the self-destruct for a contract created in the transaction then it truly becomes cell phone send all

Tim Beiko: okay does anyone not think we should make this change or the people feel like they need to look into it more to better understand

Danno Ferrin: so the change would to be never to burn are you proposing we

change it so it never Burns

Tim Beiko: okay so the current implementation now would still burn it right

Danno Ferrin: yes the current implementation and tests

Tim Beiko: okay

converting

Danno Ferrin: okay so table to burn for two weeks and let people think about it with the alternative being rewrite it so that it never Burns and if you self-destruct yourself um in the same transaction will it leave a hollow account or will it leave the data or will the the self-destruct fail

yeah uh Muriel

Mario Vega: yeah I just wanted to verify my comment um so on the test right now if I think it follows exactly what the what Daniel

proposes so if it's insane transaction it's selfless choice we give but if it's in different transactions the creation and descent all it doesn't destroy the it and in my opinion that's how um yeah that's the semantics that sound more uh yeah in line with what the awkward name describes but but yeah I don't know what other people think okay

Tim Beiko: so clearly not a ton of reactions I think yeah it's

worth looking into it a bit more um I've reached out I sent your uh PR to some folks on the optimism side Nano I think we should reach out to other layer twos as well and maybe I know hopefully by like the CL call next week we can at least have a good view on like this this uh is this like a deal breaker for for any of them and uh go from there

Danno Ferrin: okay um if we do a change we can write this in chat my recommendation is we would leave a hollow account with State and notes deleted if we delete in the same transaction

yeah

Danno Ferrin: other than that um you know it's currently tested for

how it's described so sounds good

Tim Beiko: any other comments thoughts on this um next up I had an execution API PR I think a live client you brought this up uh 438 uh get blocked receipt

Lightclient: hey uh so there's three PR's I wanted to talk really quickly about into the execution API is this first one here adding this new method eth get Block

receipts I understand some clients already have something kind of like this it seems that there's been like generally positive feedback on Discord and on this GitHub issue for the for adding the method to the spec and supporting it basically I'm just trying to ask if there's anybody who feels strongly against not going forward with this or weekly I guess not going forward with this

Tim Beiko: last chance and there's some base you support on the pr as well so yeah oh another my good favor as well let's do it

Lightclient: cool so let's go ahead with

that one I'll I'll merge it after this call the next issue is four three zero and that is a request to move the mining related ether PCS so right now you can check there are five still in the specification and these are eth mining each Hatchery youth get work submit work and ether submit hash rate they're not really used anymore for post merge related things I'm curious if client teams feel okay with us removing this from the spec this doesn't say that you have to remove it from your client immediately if you have networks that you still want to support but generally it seems like something that we don't need to have in the like canonical ethereum spec

okay yes remove okay do it

Lightclient: excellent okay uh okay all right the last one is 297 in the execution apis repo this one has been around for a while and we've been toying with some different ideas ultimately the goal is to improve the ux for running execution layer clients and consensus layer clients on the same machine so today you have to kind of negotiate outside of the two clients as the user of the clients where you're going to save your JWT token generate that JWT token and then kind of Point them both into that direction

these PRS are sort of trying to figure out a way to improve that where the user doesn't need to try and coordinate across both of the pieces of software like where this token is going to live and this was the original proposal that I had come up with was just coming up with some sort of default location and some order precedent for reading and potentially writing the JWT token there I'll let you take a look and review like what the exact locations are but we went down this path and ultimately I think you're sick made a proposal to have a fixed JWT token and only allow the fixed JWT token to be used if you are binding the engine API to your local host we

went down that path for a while and decided that ultimately we're kind of relying on some browser security properties of not being able to do a cross domain requests to localhost as like the kind of like securing property of that system and it seemed a little bit brittle so I've kind of like come back now to this default file path method and trying to yeah just reinvigorate the interest in making this happen so I'm curious like if client teams are interested in supporting this if so any comments maybe yeah if you're not interested also important

Lucas

good

Łukasz Rozmej: question uh would there be any potential issues with accessing this path um because uh and on different OS so for example on the windows I'm not sure if you have by default access to roaming up data of not your not for your actual application right that you're running and this would be like cross between el and cl so like question mark about the access paths and access rights to the

Buffs

Lightclient: yeah that's a it's a good question I'm not 100 sure on that for Windows uh I don't know if anyone knows off the top

of their head if that's the case would need to look into that Enrico

Enrico Del Fante: yeah we have been discussing this morning about this internally and I was the game VR was that for us it was kind of weird that we have a spec that start prescribing things so in detail it's also really cooperating system stuff and you end up having these issues like doing Windows uh by default you get access to this directory or what if user gonna use Docker and just start having

other level of complexity and then spagging out these details there it becomes a little bit um yeah

off

Lightclient: yeah that's that's fair originally when I proposed this I used the must terminology as in this was like a hard requirement for clients but we stepped that back to more of a May the clients May provide dysfunctionality and I do I think it is useful if we decide to like move forward something like this to have hey some you know a relatively simple Speck about like where can clients negotiate on this location if it's too

much effort to implement then this is a choice for clients but I think ultimately like this is a problem like outside of the exact implementation of how to deal with this problem negotiated the jdbt token it's just a silly thing for users to have to do on a single machine and we should come up with a better way I don't know if this is the end all way this default path I'm happy to like find other another route but yeah

Enrico Del Fante: another consideration we were doing is that maybe this kind of complexity will be gradually uh you know simplified by the tooling that overall come up for homesteakers to just help things set up and this kind of

detail will be kind of hidden by using these tools and might be that this kind of complexity were initially there uh practically for when we were close to the merge but then time pass by if users get used to this and a lot of tooling around this complexity yeah

Lightclient: abstract the way that this stuff I don't know I mean even just for myself I would love to not have to deal with this and I don't think I think users aren't really getting better or any clients they just stop running clients so I don't know I think that we could we

can do a lot better about making it easier for people to be running our software okay generally it seems pretty mixed

take away

Ahmad Bitar: I think just having a default value for the location of the def that the file is is fine as long as we are not enforcing the user to always locate the file at that place then and if the user does not specify another for where it is

uh I think having a default value is is a good option uh I don't see why anyone would object to having a default value or or how it would affect the user experience in a negative way to having an a default value even with the tooling that already exists with the existing complexity since they already specified that location of the GWT file they do not have to deal with any regressions caused by this change

Lightclient: right I think the point Enrico was making and currently if I'm wrong was just there's more effort on the client side to deal with these different

default locations and it adds some complexity like it does

Enrico Del Fante: yeah I mean at the end you may start uh having more more interaction with uh end users that assume that is gonna work but then for their system that don't work and so they start um yeah there are more much more support around this is this thing and then you fall back to say okay please explicitly pass this this information that the JWT path experiently prepare to fix it so but I agree at the end that's a default value

uh it seems like uh seems like um cannot worth uh cannot be cannot make things worse actually

Lightclient: okay it sounds like we don't really have enough Forum to prove this this time I would really like if more client teams could weigh in on the issue and we could try and iterate a little bit on it and get it to something that people are generally happy with

Tim Beiko: Barnabas had a nice comment as well saying that with whole Sky it's going to force each client team to run multiple set of nodes so people will experience

the pain personally a bit more

Lightclient: um so that might be I think the client teams already run nodes nothing off yeah you heard it a knock in every household 10 knucks in every household

Tim Beiko: yes yeah but yeah okay let's and people can continue uh discussing like the specifics on the uh on the issue but I agree it seems like uh we might want to get a bit more inputs before moving forward with this

Lightclient: yeah sounds good I'll merge the first two PRS thanks a lot for the feedback on this one as well cheers

Tim Beiko: um next up so there's two uh related uh I guess uh proposals so um eip7329 which is the EIP ERC of repo split we've discussed this uh on the call uh I believe two calls ago and then it kept discussing it on eipip and then um so uh that Dano and like client put this together and I think uh Greg Colvin I'm not sure if he's on the call but had a proposal to eip1 that addresses some of the issues around the process but maybe yeah a live client

um like client Daniel do you want uh to give some context on this

Danno Ferrin: the contact is to affect what we decided a month ago um and this EIP just formalizes it in a way that is acceptable editors it outlines the Alternatives considered and the objections but I don't consider my opinion changing on it that we want this full separation we want full governance split um and that's what we had agreed on what the all core devs wanted a month ago so that's formalizing this process

Tim Beiko: does anyone else have comments thoughts on this

Danno Ferrin: do any core devs disagree do any core devs want us to stick with one unified EIP repo

Tim Beiko: okay so this seems pretty clear I don't believe Greg oh oh you are here okay great perfect so yeah do you want to talk about your PR and um yeah

Greg Colvin: not all of us are on board with it as it is it I can't really review the big PR because it touches 924 files so some of us feel this is major surgery that we

want to consider uh my EIP it'll probably get split some of it are I hope uncontroversial changes about things that people have complained about that that don't require this split which is things like our link policies way too tight and people don't like fighting with that and other issues of that sort um the bigger thing it tries to do is to clarify um what parts of the responsibility and workflow belong to the developers and what parts are editorial I think they've

gotten mixed up and so we start wanting to split the editorial repos instead of saying some of what we want to split shouldn't be there in the first place um so I think a lot of the trouble is just that we're trying to track EIP status in the at a total process the editors don't care about whether it's CLI or not or CFI if it's considered for inclusion if it's going on the test Nets that's entirely development workflow um so my EIP just tries to separate that

to create um essentially two side repos where all of the see editing gets moved into one repo all of the EIP editing gets moved into the other but the current repo stays the same because that is the working repo where the editors do their main work and actually publish it's horribly cluttered because people check in the draft and then all of the editing on the draft is going on in that repo and for erc's that's a huge amount of churn

Tim Beiko: does this does this imply that there would be a single repo where like

all the drafts get merged into so there's like a ERC pre-draft repo and EIP pre-draft repo and then they go both get merged into this common repo or is it more that this common repo hosts things like eip1 or whatever like high level process stuff but then there's an eip's repo and an erc's repo and that's where all the activity um for for each side happens

Greg Colvin: it could it could work like this um a draft gets checked in to the existing repo the bot says we have a new draft here I'm going to put a PR maybe automatic merge but at least a PR over

on say the core repo the the core directory in the EIP repo the software one side so now there's a draft there and further editing happens over there um as as the working group iterates on that draft at some point that draft could go to CFI um and when its status changes to CFI the bot can then put a PR back on the main repo and say hey this one's gotten the CFI still will make a note of it so the main repo only contains the major

changes in status and those major changes are defined by the working group in this case the core developers say what their status is they don't have to tell the editors we don't care and so this I think splits off the work in the ways that the work is actually done and lets the editors manage their repo in the way that's best for us to do our own work and publish final documents which is our real job is to get to a final document that actually describes the protocol

and to support work in between but not to get in the way and we're just in the way right now and I don't think the split gets us out of the way it just doubles the problems

Danno Ferrin: so basically I think the split does get the editors out of the way because it gives all Core devs Final jurisdiction over the items it wants to do in this process set up with this working group and the second editor group I don't think gives us final jurisdiction it still provides the ways for editors to be in the way and if one person to stand up and say I veto this or to keep a spec from going to final because we have some little knit wrong with particular formatting or process of one particular

thing the big Advantage I see of the split is it gives the awkward Dev side of the house final and total jurisdiction over how they do their processes and what they publish and that is what I want more than anything else is final jurisdiction in this meeting

Greg Colvin: that's what I'm trying to do or a working a working group should and already does have at least one editor um in the working group and I would say that that editor should have right permissions and if the working group wants to push it to final the uh the other editors back off and just say you say it's final you want to merge it it's

your PR Do It

Danno Ferrin: um but that's not the experience you've had in the past there was a networking prior reset this is final and an editor that was not in the working group from outside the working group came and said no you have to go through the process of a two-week because the other editor still could go in it's we've seen these happen in the past right I don't want it possible for someone outside of all core devs to come in and say you have to do that so unless those editors are given complete sold jurisdiction I don't see how to solve this without it actually being a full formal total split a working group is just you know moving the deck chairs around

Greg Colvin: I've very clearly I want to get rid of those stages there shouldn't be a last call

for tour VIPs there's certain um but I don't want to I don't I want to rehatch this discussion we have the IPS on the table we have discussion threads both on The Magicians and Discord so that's where to take this up I'm just saying this is controversial you can force the merge if you want but you'll be forcing it through controversy on the editor's side and if you force it through against controversy on the editor side you will do damage and I don't I don't think the split is necessary to achieve the goals that you want to achieve

but I don't I don't want to spend this morning of arguments here

Tim Beiko: yeah I mean there's a way where like we could eventually get to that even with a repo split so I think clearly you know the strong support for the repo split uh we just you know have no objections again um and it probably makes sense to go forward with that first and then if we find that there's some you know core set of like overhead you know like the obvious number the obvious the obvious thing is just like numbering but if there's like more than that that like makes sense to live in a common repo maybe after we sort of create this sort of EIP Miller or EIP editors report or something like that

Greg Colvin: but I please

please let the editors try to come to a consensus we aren't there yet we don't have a consensus on this

Tim Beiko: sure but that means you know you personally could block this decision for like another year if if you wanted to

Greg Colvin: look Victor strongly opposed but has said he will not block I am strongly opposed I'm blocking um I've said that I will remove the block if we finish this whole discussion and have a reasonably coherent plan that doesn't risk splitting the editorial organization into two organizations and that if I cannot remove my block

I'll simply remove myself as an editor and allow the the other editors to do what they want to do but I yeah this is the nature of the consensus here we probably can't get unanimity but I'd sure like to be closer than one editor strongly for two editors strongly against and others in the middle um you know let's take a little time we've got solid proposals on the table to discuss we're not going in circles

Tim Beiko: um but I just think your block is kind of there's like some fundamental thing here

where if the reason to split out the erc's in EIP process is like each side has more control over how they do things then of course the editorial is going to be split out because you know the editorial in the long run is probably going to be quite different and maybe a single person can choose to like sit on both and I believe at least some of the current VIP editors want to do that but yeah but it's it's going to be two different processes so I just like fundamentally it seems hard if we actually want like the benefits of splitting the repo which is we can tailor both sides of the process the like the users of the process and the main stakeholders then from an editorial perspective you're going to have to

change things as well because otherwise otherwise we'd all be happy with the current process like the fact that we feel there's some constraints as part of the ERC process that make it harder to do EIP work is kind of the root of it

Greg Colvin: yes I want to fix that I don't believe that the current split proposal is the right way to split things

Tim Beiko: right

Greg Colvin: but and I guess there look I'm sorry editing we're editing technical English it's all the same it's technical English it has the same spelling the same grammar the only form we're imposing is we really want to see

an abstract we really want to see a Securities uh considerations and we really want to see uh references and we're handing over to the core devs what references are allowed what sections in between the abstract and the security are allowed and I would propose that yes if the core devs say it's final publish it the editors will back off and say it's your EIP you're telling us to publish it despite our misgivings we will publish you know to give the core devs plenty of control but not say we need to editorial

organizations to manage stuff is not editorial I don't see um I keep bringing up the ITF the internet engineering task force they've been managing all of the IP and more protocols for what 50 years now maybe 60. um they have one editorial organization with one head editor that never felt the need for multiple editorial organizations to manage all the different processes they simply give a lot of power to each working group to manage their processes and keep the editorial work

uh minimal I think that's a good model for us I don't think making up another model that's this complicated I just don't think it's the way to go but I think we can meet the actual problems and fix those um and I'd like a chance to do so

Tim Beiko: right but again the set of court devs and like everyone on this call sort of has already moved past this so I don't think blocking the split is the right approach when you know what else can I do

Greg Colvin: I totally disagree and if this split goes through I will need to leave

because the organization the values will have diverged from my values and I believe the values of those who set up the organization Circa 2017

Tim Beiko: I think if you care about the consistency of the editorial process um you know waiting to see how the split goes even if you disagree with it and then potentially trying to find ways to like make things more coherent at the editorial level if there's if there's room for that like I think you know that could be an approach but I given we've discussed this for you know first many years but also many months

recently and there seems to be like extremely strong support from the core development and and research side across both the execution consensus there I I think we should continue to work on the Smith I I feel like you know we asked like 10 minutes ago if anyone had objections and there doesn't seem to be so I thought my objections I mean sorry for the client teams yeah

Greg Colvin: yeah

Tim Beiko: so but I think look if and if you disagree with this at like a fundamental level and don't feel like you can engage with the process afterwards

Greg Colvin: there's no going back to what we had

from the split

Tim Beiko: well you can always add I I disagree I think if if there is actually like a set of common things that like need to happen across both repos um and like yeah numbering is one example but if there's like more of those types of things then you just add an eip's meta repo or EIP erc's repo or whatever EIP coordination like I but my view is like from the client teams from the research teams and like everyone I've spoken to who's like deeply involved in proposing changes on the the protocol side the split is what they'd like to go forward to um and and I think respecting that and you know potentially trying to find ways

to make things better afterwards is like an approach where you can probably get some of your changes as well like I I haven't like fully reviewed your your PR but like just skimming through it I suspect a lot of the things you propose there are things we would want on the EIP side of things but you know the difference is like which repo does this end up being written in and I think the strong preference from all the client teams is they want a separate repo that's focused on core eips and and this can be part of that

Greg Colvin: yeah I'm proposing a separate repo but I'm not proposing creating that either the ERC or an EIP repo don't

create that by essentially cloning the existing EIP repo and trying to clone the existing process right

Tim Beiko: sure so then you're saying you've got like a blocking objection on basically an implementation detail where most of the client teams effectively disagree with you

Greg Colvin: um and right but it's it's the editorial team that has to live in these repos

Tim Beiko: um but but again like part of the argument is like why we want this split is client teams do not live in these repos right now because they feel like they're not set up for them and the thing we want to get out of it is that yeah

Greg Colvin: yes I'm proposing that there be an EIP repo separate from

yeah separate from the editorial repo that there be there'd be a developers repo for the purpose of managing the IPS but I would like it to start new and empty and then going forward we start working in it it's not much easier requires no surgery to speak of um and um if we really like that more stuff can be migrated into it as we want to I think it amounts it amounts to a good piece of the split to work with but but not trying my hugest subjection is no I don't want

to split the editorial processes and I don't think that things like Lake rules and spelling and grammar need to evolve in different directions I just think the editors need to back off to editing and let the core groups uh take care of of developing and specifying what they develop

Daniel

Tim Beiko: I thought you had your hand up

Danno Ferrin: um so a lot of these things in the eip1 pain relief they're they're not not mutually exclusive we can still do every single one of them yes and the one commentary I want to say is that a lot of these ideas have been discussed but

never seriously considered until the moment the split was mentioned um and so there's a bit of the Overton window shift and it's that having to threaten to leave and to split things to get work done is not healthy so if we had final jurisdiction on this we wouldn't need to um work we wouldn't we would know and control our final Destiny and even that little bit of asking the editors to back off they're still the final step we don't have full autonomy in the process and that is what is essential in this split

Greg Colvin: that's what I'm offering I guess

does anyone else have thoughts on this or

Greg Colvin: I'm offering that the core devs have the power to merge final eips no matter what the other editors think

Parithosh Jayanthi: there shouldn't be an editor group to think about it we should be our final owner of it

Greg Colvin: okay that's okay with me too but I don't I don't see the objection to letting the editors check the spelling and grammar and and the check that all of the links are actually live links

Tim Beiko: but that yeah the thing is the split does not stop this right the split makes this happen in two different repos and I think again this is like the preference that's been stated many times so it's I don't know I feel like there's a pretty

strong like preference from the client developer group of how this should be done technically to accommodate their workflows which in practice doesn't really change you know how like what what what modifications we can make to the process um so yeah I don't know based on like this and the other conversations I I would be like I I think we should probably move forward with the split consider your suggestions as part of the uh like new or I don't know like separated core EIP Focus repo um and and I think like yeah if if that's a way to get more clients to engage with the process then that's

that's great and if there are things we can do after that to help the editorial side we should we should obviously do those um but I think holding up the entire kind of transition that people are like pretty strongly in favor because of some objections um because of like some objections to the form on your end seems uh yeah that seems wrong

Greg Colvin: this repo modifies 924 files I can't review it

Tim Beiko: sure well I mean I I think like kind did the PR but I assume most of those are just like links and naming changes right

Greg Colvin: I don't know I can't review it GitHub can't show me a table of contents

anyway there's an editor's meeting next week we can take this up as editors next week

Tim Beiko: yeah but I okay

all right

Greg Colvin: and I'm sorry blocking is part of the consensus process and deciding that deciding that my block is solid but I'm not going to change my mind

Tim Beiko: sure but that doesn't mean everyone else has to stop moving forward because of your

blog

Greg Colvin: no they don't

Tim Beiko: yeah

Greg Colvin: and I think the editors are free to move on without me but that's true but I this is this is how important it is to me and it's a hill I'm willing to die on I'm

sorry

Tim Beiko: um yeah I I appreciate that I don't yeah I don't know

Greg Colvin: I if there's all right I'm trying so hard to give everybody what what they really need here and this is on the basis of God at least 30 years of experience in standards groups on how they go right and wrong so I this isn't coming out of nowhere yeah I I don't know if anyone feels like this makes them reconsider whether which

is width this is probably the time to speak up

Tim Beiko: otherwise I think after all right the editors can take it up next week no but yeah I'm mostly curious to hear about client teams because yeah yeah but yeah last call I guess the voice and yeah so I guess in terms of Next Step then yes you know you can obviously discuss it in the editor meeting and this kind of specifics even just also around like reviewing the pr in the script and whatnot but I think from like the client team's perspectives it seems pretty clear that we want to move

um and I think it's helpful to also have um EIP what is it 7329 that like lays out the specifics so I'd I'd I encourage find teams to review that as well as um as well as as your PR Greg so that you know there's probably a lot of these suggestions that we would want to pull in uh to the to the post

of the three book

Danny Ryan: um 7329 is in last call until the end of the month so please comment

Tim Beiko: okay last uh thing I believe we had on the agenda just a quick shout there's an

eighth magician's Thread about finding a name for the next upgrade so Prague and uh Elektra uh the two uh the two uh uh options proposed first are Petra and Elektra and then uh then in the comments says he wants to die on the Prague Electra Hill I don't know if we want to discuss this now or just leave it on each magicians yeah any thoughts on this okay uh so okay let's use uh let's use

each each magicians anything else um that anyone wanted to bring up cool

we'll

Barnabas Busa: bring up uh yeah uh block uh version three and point four Beacon API

Tim Beiko: yes please

this

Barnabas Busa: is something we want to include in

Tim Beiko: uh any comments from client teams have people had time to review it

okay if if there's no comments here I think we should do I oh and then everyone has I was gonna say so for for the for the blogs version three I think we should try and do like for the uh other PR we mentioned get some uh consensus async in the next week and make a go no go decision on the CL call um Alexa uh I is I believe your PR is like similar

yeah and just small uh Paragould so your records and uh general clean up for

Loops and um well if we can consider it for inclusion to it or imagine it will be cool

Tim Beiko: does anyone have thoughts on on this PR Ok Okay I think what we should do as well so um let's discuss the may think well I'll make sure to add them to the agenda for the 444 call next week as well so um we you know people have uh in a couple days to to look at them before yeah and we can we can make a call at

the latest uh on the AC DC call next week about whether we include them in definite okay well thanks everyone uh talk to you all soon

all enjoy Paris

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