Merge Implementers' Call 6

let's just get started um yeah welcome to the merchant primary school number six um today is going to be pretty straightforward i guess so um we'll start from implementation updates as usual uh there is uh yeah there is update from my side i'm working on the transition process implementation attacker um because the pr has been merged um into the into this big repo uh so i feel like i'll finish this implementation like um at the end of this week or uh early next week and we'll try to yeah the next challenge will be to um set up the locally the proofwork chain around the beacon chain do all these steps that we do all the the steps that we um we did on the mainnet already and uh yeah finish it with the merge transition process so probably i'll just you yeah yeah likely reuse the scripts that we have from after ionism which is great and yeah we'll use the [Music] the gary pr which already contains the transition logic and in gaf so we'll see this is like the update from my site does anybody else have an implementation updates yeah i think it makes sense everybody is working on the corresponding hard forks so okay cool any questions here okay great so let's move to the research updates um we have like a couple of things to mention and probably discuss we have justin on the call i guess we don't know i can give a quick context i mean 24 72 just justin is uh known for going through polishing and merging uh making sure that kind of the specs conform in terms of naming conventions and structure and all that kind of stuff so he's done that on the the recent merge specs has been about a bunch of review i just did uh it's now passing um ci and and um has incorporated the feedback so i gave it a plus one this morning um if anyone wants to take a look at it please do otherwise i will probably merge it tomorrow yep cool yep so i'll just drop this the pr just in case so yeah there are some renamings and reorder of the fields in the execution payload this is one of the like not substantial but the biggest change i guess right so in some renaming some of the methods um yep okay cool so then yeah yeah the next one is the randall pr so there is a pr which adds the randow to the execution payload as it's been discussed on the previous call so it's passes the randow into the difficulty field of the execution block and then it will be yeah as the difficulty already presented in the um evm context and can be used by difficulty of code to yeah and this is the way the randall will be exposed in the evm for the applications um we will support uh or better to say will not break the existing applications that uses difficulty as the source of randomness by this change and potentially like after the merge in the cleanup fork we will probably and we will likely and we want to do it in the following way so there and there will be sent directly um to the evm context and it will not be embedded in the execution payload um so and like the reasonable question here what if we like do this um [Music] like at the point of merge and it's the minimal version um the counter argument to this is that we don't want to change the we don't want any changes in the evm um like in this first merge iteration but anyway um what do you think uh how much of a big deal it will be to directly and bad run down into the evm context i mean my my argument would be that we have to change difficulty it has to go like because there is no it needs the new context and so defining it as a constant or taking it as the value off of that rpc um has probably negligible complexity difference and so might as well do it at this point is that the question yeah that's the question so is it a big deal you have to directly send it to the evm without yeah i mean the execution layer gets certainly gets context and directives and so i don't think it's a big deal but i'm not managing the software on that side yeah this is the question yeah mostly to a net client monitors how difficult is to change the well and again it will have to be changed it might be like if post merge difficulty equals one um or if post-merge difficulty equals this value that's been passed on would be good to hear from tommaso or ryan because we're changing already i think i think it's fine to do it at the same time yeah the difference is that you don't need to change the vm at all by using this or this route by just embedding the randall into the difficulty field right um i don't think that it's like a big amount of work either probably some testing to to cover this case and tow mouse into the chat so it sounds okay so i don't know if i mentioned the video uh mikhail but you said at some point you wanted to change it to something else um or is this embedding it as the difficulty field kind of the final place you expected to rest no it's it's not kind of final place so this is just not to not have a deal with the evm uh at the beginning this is just more a workaround than the final solution why is this a workaround i'm confused yeah why is this not final uh you mean to use difficulty i i mean to use random my question so final in my mind was randall in the place of difficulty in the payload right do we is there some reason we would want to expose the randow in the evm through some other mechanism besides that opcode i mean does it make sense yeah like is there any reason like we would ever have to return to this like if let's say we set i forget what opcode difficulty is but that opcode now just returns render value are we done forever we never have to come back to this like the evm now has random number generator at the end yeah i mean if that value was hardened say with the pdf or something else then it would be subbed for that new new heart and value but um yeah it's 256 bits it's not it's not clipped it's like the fuller and the amex yeah we're just uh we're just talking about the way the random makes this boot into the edm is exposed by the evm the source of it is is it gonna be the part of the execution payload or is it gonna be um like a side value but it's used by the evm um without like uh being put into into i think it makes sense to put it in the payload i don't see an issue that with that even as a final destination i mean the issue is that people used to start depending on that it is the randall and not a random value because the rundow is a specified source of randomness then is that a problem can we use a different source later on no i don't think it's this problem so we can call it rendao anyway and use another source of randomness so i would like so rendao is a kind of abstract thing here because if we just want to random value we could even take the hash of the render or whatever right but if we say that it is the render out then people will start using it for other correlations as well not just as a random value wait you can't do anything else with right now can you like so it's nothing it's already the random mix so it's already hashed next sword so it's not it's not actually like the signature um so it couldn't be used for you couldn't do like signature verification on it or some other thing uh but if that's i don't see that in that danger like even if it were the signature there's nothing in there in my opinion it's just the signature of the slot those people might do some sort of validation against yeah like on chain validation of stuff and then you take that away and you're like oh the rando is now this other random number they're like oh my contracts broke because i was using that to verify blocks yeah i mean obviously that's really stupid surprised if you could if you could do any on chain valuation validation because it didn't contain anything relevant if it were the signature you could put your entire contract and if randall verifies and then all the logic after that um we're getting a really stupid mechanism it's not a signature so right right so it's the xor of the hash uh with the previous randomic so so there's not a um there's not weird well someone can always try to figure out something weird to do but um it's i just don't see how why you would do it because there's nothing useful you can do with it it's not a signature of a block it doesn't sign any any meaningful data and it's not even a signature the value today is not even a signature right you can't you you can trace it back to a signature if you want you could make a proof that back to signatures but they signed something completely useless so yeah so we would we could call it random well i think that's the point a little bit the fact that we can't figure out in five minutes on a call what people will use it for doesn't mean that it won't get used that way if we say that it is the run now that's all i'm saying yeah like to yeah six point what if like i made a contract and the purpose of the contract was just to upload little bits of beacon blocks and states to it just to add the information in there and i said oh you know what don't worry about uploading the brand out because we already have that because it's exactly what the op code is like it's a contrived example but there's anything yeah no that's fair that's definitely fair i would call it random you mean the up code or like if difficulty is gonna get a daily change i would call it random okay okay so what i'm a bit worried about here is that we're changing difficulty uh which was like much less than 30 bytes um but it will be 32 bytes after the merge so it will need to be checked um whether there is no overflows uh in the execution clients i believe but i think i think the execution clients after the last call and i think all of them got back and said it's 256 bits and i can go verify that but no one said but if they're doing a total difficulty calculation and summing that for some reason they could have weird overflows even though they shouldn't be using total difficulty really anywhere after that point or anywhere meaningful after that point oh i see you're saying it's like there's a potential source for bugs during the merge we need to watch out for right yeah this is the potential source of bags and if we set like difficulty to zero or to one uh there will be no this kind of source of bags and then we will have to pass run down a side of the execution page right but that's like the only thing and also if you set difficulty to one you might accidentally um like still kind of use longest chain rule and it be correct some of the time and you know you don't want to accidentally be correct some of the time because then you have an attack vector right you can set it to zero anyway okay so this this is the pr that just yeah substitutes difficulty with uh the random or rendau value and we can rename the op code after the merge right i mean renaming the upcode is a social thing there's nothing to do with the code and like just write a variable name and code somewhere so i would and then solute it to april i just want to highlight that like anything that like this uh probably would need to make its way into being an eip um but that's maybe a whole separate conversation as to how this shows up in that process right this is like the next item on the agenda yeah how do we document all these changes great okay so if we finished with the rendao um if anybody um like want to look in dpr it will be very much appreciated so um i think if there will be no blockers we can merge it like on the next week so please take your time if you have it take a look yep i think we can move on to do the stacks of the execution layer um so yep tim like us uh raised like very reasonable question yeah so now yeah i guess one thing is figuring out you know where do we want to have the specs for this um i think you know on each one currently eips is the best place uh there's some work happening on an e2 style spec for each one but you know it's not ready yet and i i wouldn't necessarily want the block on that i feel like that even more basic than that though we probably need just a sort of list of like changes or open questions that we need to answer for each one um i think that would that would be useful like obviously for us to kind of have a broad picture of like this is all the stuff we need to do um and i think it's also something that will become increasingly useful as like the community asks one merge um to have some list of like well these are the things we need to solve so i'm happy to help put that together but i'm curious yeah what the people feel is like the best format for this um yeah does that generally make sense basically yep yeah i mean right now the ethereum specs are kind of the summation of the yellow paper and eips and stuff and i think that's attempted to be captured in that ethonos specs repo so even if there is an executableness there maybe that should still be kind of where the execution layer um specs ultimately go so yeah i i think assuming we don't have some sort of executable spec on that side i i would argue to have some sort of uh selection of eips that dictate this change and anything that creeps into the evm and then put them into a fork and ethono specs it's probably easier said than done though it could be quite messy um and we did do a informational eip for the beacon chain launch um it might make sense to have an informational eip that just kind of explains and locks down versions and stuff but uh i'm speaking outside of my domain at that point yeah i think we could have like an informational or meta eip that's kind of a description and um i think the one thing uh that makes this different from like a regular hard fork is there's a lot of non-consensus changes that i think are important to document like you know all the stuff around syncing for example um if like it's obviously like a massive part of the merge um but it's not like something that's actually like a hard fork um so i think those are also the type of things we want to make sure we kind of have a list for um and and i think those can all be eips as well right like it it's fine we have uh i think eips for some of the syncing protocols definitely not everything um but we can open like networking eips for this stuff um yeah so i don't if that's the format people want to use it that we have something better we can just have it in the eth1 specs repo and and use eips as like the templates of the various changes um so i'll okay this is brief since i think everybody here has already heard my arguments and we don't need to spend too much time on it um eips is a specifications repository a place to keep technical specifications it is not a place to document things like it is not a documentation repository there are far better tools for documentation that we should be using i am a huge fan of documenting all this getting everything written down i'm not arguing we should not document it i'm just suggesting eip's repository is not the right place for non-technical documentation like yes i think that was back like oh just a technical spec efp is great place everything else hackmd ethereum.org like wiki github yeah anyway so i think we can use the eth1 specs report to do you know this broad documentation if even you know if like you think it doesn't make sense to have a meta-eat or informationally like fine we can put that in each one specs repo but the this kind of documentation is kind of a wrapper around several technical changes right like what we do about difficulty what we do about sinking and and so on um and it's like that lit and you know do we want that list each of those technical changes that have been associated with eip and if people want to do that i think i think that's fine but it's just good to know kind of already because maybe we can start drafting some of these eips and you know putting together something in the east one specs repo that says hey this is the merge here are the various eips here are the things we still need to figure out but haven't gotten around to writing an eip for as a as a first step to maybe ui and others should black box the functionality from the beacon chain and then enumerate everything that we know is that that we've already kind of specified as changing and know that we will be specifying is changing even on sync op codes that kind of stuff um and then once we've enumerated all figure out the home for the the different things okay yeah that sounds good i can follow up with you and uh nikki allen other people are trying to to get a first draft of that great yep um um like i think we need kind of timeline with checkboxes right yeah i'm arguing for the checkboxes to avoid the timeline so i think and i think we did this fairly well with 1559 where we have this checklist um because there will be increasing pressure at like the worst time when you know when stuff is like 50 ready people will start asking you know like when merge and being able to say well look you know here are like 10 things we still need to figure out um you know both for us like i think first and foremost but also for the community there's value in seeing like oh the consensus changes are done but like sync is broken or you know json rpc is broken or whatever right um yeah i i definitely would not put dates on that document um and kind of use it as a shield against having to provide dates okay see yeah um okay as for the eiep process um [Music] i think it doesn't make much sense to like put um every different part of the execution client change into separate dip probably we can use the approach that has been taken in the click eip which just describes all the things in one document what do you think i mean once we figure out the synth process once we figure out yeah seeing process definitely will be a separate spec um as we have but like all the courses changes maybe one yeah yeah i don't have a strong opinion for against that yeah all the consensus changes should be like in one place i guess the argument for having lots of small eips is that they tend to go a lot smoother because they change set as small what happens when you have a large like monolithic eip is you get a bunch of bike shooting on some like minor piece of it and then the entire eip gets kind of stuck in the mud um also you end up because conversations tend to be centralized around like the discussions to link you get like this just massive thread that everybody unsubscribes to because there's just too much talk about that bike shedding piece and it's very hard to find the actual discussion so my recommendation is is try to flip split up into as many smaller eaps as possible just because it really does make the process go a lot smoother um eips that are like a page long go through almost instantly whereas eips that are you know 10 pages or so take way more than 10 times as long to get through yeah i think i would probably agree but i want to see what those items are that actually need to make it into an eip before we decide for example like this difficulty change being in its own uip that makes sense it's probably like a one-pager and it's it's it's pretty easy but i i there's yep it's unclear to me which things are going to make it into your ip yet yeah and figure out where where to draw the line is definitely an art um again just i recommend caution i've seen a lot of people try to do monolithic eips and it i don't think i've ever seen it go well we'll call on the the artist of micah to give us a hand starters like we'll be like make this shorter okay so yeah and for the moment when we when it makes sense to start like writing those eips um i think that we should figure out the transition process first to be to make sure that nothing like substantial will change also it would be great to get the sync process figure it out too and then we can just put everything together that uh changed all the changes and the consensus for the execution side and put them together and see what could be decomposed and put in a separate ap and what could not be decomposed like and yeah this is just my thoughts on glenn and hell probably we can start like not wait for a sin process figure it out and change something like in the eip drafts later on yeah i i think so like i think yeah like that he said figuring out what are all the big kind of themes in a way um and that'll give us a good picture of like the ordering and when it's the right time to actually uh formalize uh different parts of it so and uh we are starting and we can get this check boxes like now right yep i mean yep okay so we like get the document with checkboxes um in a short time in short term and then add links beside the checkboxes in the medium right yeah and um yeah and you already have some links beside them actually so those checkboxes will be probably checked okay and then once transition process is like prototype prototype we can start thinking about eips right um i had this like research doc that i gave up to keep up to date with the list of leftovers this difficulty thing was one of the last leftover um i can double check with myself but i think um yeah now the transition and the sync and that seems to be all but i'll check check it out we can use it as a source for this like document with checkboxes okay and don't forget the api right you're right api okay so if we yeah okay another another big item is probably um testing and how test generation looks in this unified front and whether everything's kind of separated into these layers um for more of the unit testing and then what things like hive and other integration type tests look like but let's maybe not solve that one today yeah definitely when i was like um saying that this difficulty thing is the last one or probably the last one i was referring to the research open questions right so we seem like we don't have them um okay if we're finished here we move to the open discussions by the way i forgot to ask does anybody have any other research updates yeah if not i have like a small one i've started to write the consensus api improvement proposal uh this document is about improving the communication protocol i'm planning to finish it next week and share with everyone probably it will take more time so we'll see so this is like in progress too okay any other discussions anything else any pro announcements probably okay thanks everyone for coming it was pretty short oh that's nice so um we have altair upcoming and i'd like to just mention that at some point we need to rebase onto out there not everyone here is affected but it will affect those that are implementing the so we should try and time that so that we can move in sync yeah sure thanks brother yeah there will be some other changes like cleanups and probably a new consensus api to catch up with after health here yeah also regarding testing so i have like a kind of plan to finish with the transition process um and then get back to the work in this back and um tests in particular we will need some kind of tests for the transition process as well which will involve both consensus and execution sites it's going to be like interesting thing to to do yep we have a bit of um these kind of like fork integration tests for altair from phaser altair so we can at least use some of that as a basis but how we exactly integrate and or stub the execution side in those tests we'll have to figure out yeah okay thanks everyone i'll see you in 25 minutes thanks everyone thank you what's was this the call that last week two weeks ago we were arguing about uh api or is that e2 call if you call okay