Merge Implementers' Call 2

hi okay one more minute and we're starting let me just pop the agenda to the chat ben was on the way we were in a separate zoom room but he's moving over oh cool that's my fault i i forgot that there is a room shared in the invitation so i thought there is no one so that's my problem um okay um hey everybody let's start um welcome to the merch implementers call number two uh there are apparently some problems with berlin right so but yeah probably um some ethereum core devs can attend this call but let's just go through the agenda and discuss some items that we can do without them so um okay so let's start from like the first one we have this new terminology uh the key replacement here is that we replaced the application term uh with the execution one so there is the uh execution layer instead of the application layer this is to not confuse people with the smart contracts and applications using them so applications built on top of the mainnet so that's what's the purpose of it uh also uh the term layer is not um is arguably not the best one for the execution and consensus because they're not actually layered and yeah so here we can think more about it i don't want to spend like much time discussing this but um probably it's better to call it subsystems or engines or whatever um and yeah let's just if people have any ideas uh just drop them in discord and let's probably discuss it offline so anything on the terminology any questions here pretty cool let's just move on so the execution discussion um i was just going my initial idea was just going through the key um parts of the execution stuff and ask for some updates or for understanding for probably questions from uh ethereum developers so that's the initial idea so probably we can do this anyway so any questions to the like communication protocol where's the most update updated link um the communication protocol is that the ryan is inspect that you're maintaining michael yeah right that's the one i also put the link to the previous one uh the new link the ram is blink is put to the top of the previous document so that's like the latest one anyway the yeah anyway this is json rpc for ionism but it's not be probably production so we can yeah we can you know we will anyway get to this discussion later um okay so who has reviewed or who has any thoughts or suggestions questions regarding that uh by communication protocol do you mean eth1 to communication by rpc or anything else um yeah so that's yep so okay nothing regarding any yeah any questions i have a question so um i'm not entirely sure how to handle potential issues and error in this protocol for example if the assemble book fails or the new block fails or the set head fails because either the payload is wrong or some internal error happened i'm not sure how to handle it the spec doesn't specify it anything about error handling yeah right so there are statuses for finalize block set head and for obviously for new block i mean that you can return false if it's not been done correctly yeah you're you're right but assemble block doesn't have yeah right right yeah that's a good question yeah probably we should add it you know some kind of you know status there as well so it will be an object and the status alongside with it right i think especially because you can specify as a parent hash currently you can you could point to something that's just bad so there's definitely a failure case there or something that's non-existent um also yeah the other option is to uh use the um errors um in json rpc as we have them today right uh you mean the result yeah and error is it in the uh spec okay okay see i see the problem one thing because i'm not sure if it's specified it's not explicitly specified assemble block doesn't include it so after assemble block new block will be called or do we do we expect that new block won't be called and it we can be called just by set head uh we actually in general expect that the new block will be called so because there is a state transition happening on the consensus side when the block is assembled and it's proposed it should yeah which the state transition is uh called triggered and yep it will trigger the call to to the new block method okay so it's assemble block then new block right yeah you can like go ahead danny i wouldn't say i would presume get work does not add it into the block tree today right only if they find a solution uh does something get added into the block tree so it's kind of similar logic yeah but in a proof of authority chains uh you would generate the block and edit immediately so that yeah i understand your point here because there is a difference in time like when you keep preparing the blocks with the assemble block you can potentially even call it many times right with the same with the same parent because can you ever you could presumably um there's not an immediately obvious use case for that unless yeah there's not there's not an obvious use case for that you might like prakash a block and to not to avoid executing the same transactions once again right you could imagine yeah you can imagine like doing it slightly early to have something ready to broadcast and then doing it again very close to the time of broadcast to see if you've got a better you know coinbase output on the mev side but even then the i don't know that's like not a very clearly good strategy just a potential strategy [Music] actually a valuable um is it worth the complexity here in having like you be able to point to anything arbitrarily to build build on rather than just building on the head i mean presumably the beacon node keeps the execution engine in sync with what it thinks is the current head and so if there were a reorg you would trigger that and then call symbol block uh and just ask me primarily when you you definitely know the head and you can tell the the parent hash to build on um but then you're opening up like a functionality requirement on the fusion engine to be able to build on arbitrary heads which i don't know is worth complexity um that's a good question so because it could be the case when there is the arbitrary like block became the head afterwards i can imagine this kind of stuff with racing between a bit of racing between the new head and assemble block or um yeah so wha what if the head has changed during the block has been assembled what should happen here i mean you even imagine if the head is being changed while the block is being proposed so this what will how how will this be handled by the beacon node i mean at some point the beacon node has to make a decision about what it's uh what it thinks the head is and assemble the block based on that but the idea would be i begin assembling a block some other subsystem triggers that there's a new head halfway through me assembling a block i ask the execution engine for the the transaction payload but it's gotten a trigger from somewhere else but there's a new head and now i'm out of sync on that and this protects against that case yeah some kind of that consistency cases uh sir go ahead no please please consistency cases are in general really important also consider the case where there are multiple beacon notes talking to the same if you're not not okay yeah so i would say we need to actually think about any concurrent calls to those rpc so what happens if we had one set head and second set head we should probably cue them that's the last one wins for example or something like that in the implementations that's important uh finalized block is probably not important new block is probably not important that much the other relationship between fat head and and some of the other calls may be important yep so my intuition is that all these messages should be processed sequentially uh um but uh what should be [Music] but yeah new set head and new block are causally dependent so they must be processed sequentially but others could be processed concurrently but not sure if if in all cases it could be done concurrently yeah i mean i definitely see how a symbol bot and set head depending on if there's different subsystems in the beacon chain could get out of sync and thus the parent hashes definitely immediately it's a nice quick fix without having to think about things deeper but it might open up complexities on the execution engine side um but i'm not sure okay okay so the assemble block should have some we have started from the error message okay so let's let me think about it too and continue fine probably okay um anything else here we'll move to full choice and chain management yeah i just want to highlight again like the current like with that parent hash in there and there's not really being any bounds on that like a cymbal block could trigger an arbitrary not reorg because it wouldn't be changing the head but trigger an arbitrary like attempt like you have to go and put yourself into this different state to build a block and so there might be complexity there and it's worth people investigating that over the next week or two so we can talk about it again next time for now i'll just raise the error whenever the consistent consistency check fails and then from there we can change implementations to actually handle the case i have a question so if we have finalized block this probably affects what parent hashes can be supplied to con to new block doesn't it so we cannot organize finalized blocks so we do have some some constraints on this parent hash right right so are arbitrary in the sub block tree sense finality yeah but i would not enforce these checks on the execution engine because this is the responsibility of consensus and in some cases probably there will be the case where um consensus like switches from one finalized checkpoint to the concurrent one um this is like a case of some forks or whatever so locally locally you'd never revert penalty like yeah even though there was enough contact value well it it can't happen locally so even if there is it can happen with manual intervention right you might have ended up on the wrong fork and then you change it that's yeah the node would never do it yeah so i have a question so uh finalize block how many uh how how much height of the chain might not be finalized yet i'm not aware of that because it's important uh for state management pruning implementations things like that that's a problem that that is rise here if what i'm uh aware of in from eth one side so practicality of this problem is how big this unfinalized chain could be that we could reorganize right so in standard operation it's two epochs is that depth so that's but that's normal operation so you get in in the happy case you get pruning on reasonable depths but you cannot aggressively prune if you're in a time of non-finality and that you know you could go days without finality so there's definitely a variance that has to be handled on pruning so the risk uh regarding uh non-finalized state is what happened during medarsha for a couple of days the chain didn't finalize and we had many many forks and in that case uh technically you are you can store all the forks in your client because maybe they will become valid but if one fork has only a few votes that might not be worth it the problem is what you do if there's a new block that builds on one of those forks you kind of have to validate that block because you also later need to see if attestations to that block are valid so that i think is the problem but i mean i would say like on mainnet like we should definitely be prepared for longer like non-finality periods but hopefully not days so maybe we can get a more reasonable compromise there um like days would be pretty extreme that would be a pretty crazy failure if we ran into that okay so anything else with regard to the protocol of communication between ssi execution okay cool um let's just move to the folk choice in chain management i know that people started to investigate and that how hard it would be to um to make the fork choice pluggable and how big of the impact it has on the um modifying the chain management of their clients what i just wanted to ask about any updates and thoughts here how it could be improved like from from any point so so maybe i will start from another mindset it's actually pretty easy we had it uh fairly broken down already uh the problem there might be i haven't investigated that much is um later syncing the network uh up to the head and then starting it so integrating the syncing and the fork choice management itself might be harder uh than just but for for starting from head like for the hackathon we want it's it's fairly easy and then the mind yeah because we're hackers only have like this difficulty total difficulty uh rules for the beginning and there's progress on guthrie yeah i guess i can give an update if there are no uh folks from guff on the car actually petersburg either unmuted and muted a couple times we can't hear you peter if you've been speaking yeah sorry about that so if the question was what's guest's progress on these things um yesterday we had a i think yesterday or two days ago meeting with proto he kind of ran through various stuff um i guess the the conclusion was that if you need something for monday then probably the closest we can give you is uh is guillaume's pr which just kind of hacks into hacks of things into essentially just directly does inserts into the blockchain it hacks around all the internals uh we started working on um on essentially new consensus engine which does the whole new fork choice rule but we haven't merged that in yet and as far as i know it's not finalized yet either and i've also started working on the synchronization but yeah i'm kind of sidetracked a bit because uh in order to make the synchronization work i also need to change some other parts of production get and yeah i'm not super keen on hacking stuff together in production parts so so i just want to make it properly which means that it's going to take a bit to lose that kind of the update great thanks beer peter if i may ask the pr you're talking about if this is the pr i've seen is following the old spec it's not a big deal but the jason rpc interface is different than the new spec so it's not following the old spec no uh it's yeah it needs some updates but it will be done after this call okay yeah so um any questions to the chain management and the book choice um okay so this scene process it's just been some kind of high-level proposal in the design in this high-level design dock we discussed on the previous call for how to download the state and do the boxing if people have any um like assessment on that whether it's viable or not or some any kind of other inputs and things to discuss we can do it right now okay cool so let's just assume that that will work um and stuck it later about that i think we'll assume that that's though not people haven't quite gotten there yet so we should probably bring it up also right i agree i mean let's just assume for now that it may work yeah um there was a question um in the chat in the discord i don't remember where exactly was it probably in this court what which part would decide on the gas limit and target voting how this will happen after the merge so my my basic um um my basic thoughts are just it doesn't change so the execution engine has this um voting mechanism and every proposer will be able to make this uh as miners do it now so any um any other opinions and thoughts on that yeah i'd say by default it remains exactly the same which is a block producer regardless of whether it's minor proposer or validator it does that similarly to how 1559 post merge you know the block producer would be responsible for paying base fee for transaction and figuring that out in a similar method don't know on on on e1 clients today what's the how does one access that is it in a it's not like in the get work function call right is it some sort of setting uh configuration setting on the client from what i remember like gath has a flag with just a number which is the target for the gas limit and it will be increased according to the gas limit formula each block right so that should be that functionality should remain stable and be fine yeah i mean we can always add methods to to change it because i mean it's it's a relatively small thing but uh i don't think it's people generally want to keep tweaking it run time but yeah if there's there's a reason to be able to tweak the limits runtime i mean it's more than trivial i mean it's real to just add it right and currently if miner wants to like increase the gas limit it just restores the node right with the new parameter yeah yeah but so essentially if you look at mainnet um generally the gas generally miners always run with the maximum gas limit that was kind of deemed safe for the network and it's not really changed maybe once every half a year or so so it's not like you need to constantly tweak it right i think after a consensus upgrade uh there should know there is no reason like to change this um this part okay so one thing um for uh the next the next item is just slot clock ticks um this is i guess it's been missed like on the previous um call and in the dog but i think it could be important because there is the consensus part that has the slots clock and these sticks should be propagated to the execution i guess because the timestamp of the sticks goes to the block to the next block and it's probably important for transactions to that use the timestamp of code to be up to date with this kind of information so it might probably require some additional message or command so you mean transactions that are sitting in the mempool they might be invalidated or they're not as valuable or things because there's logic that's conditioned upon them yeah they may they might change the execute their like execution flow uh inside of like transaction inside of a smart contract method it calls and also it could be it should be important for the pending block functionality because you have to restart the block each time the new timestamp is observed could you expand on this thing a bit so what what is this notion i'm i feel like i'm missing something proof of stake blocks are only the time stamp is dictated by the slot and the slot is only every 12 seconds so there's not the granularity of the time like you would never see a you know transactions that are hitting timestamps opcode that's not on those 12 second boundaries so it's okay the activation engine can know about time and can decide what spot it is uh and kind of use that or it can be told about time and use that okay but then essentially this would mean that the eth1 blocks should uh also hit the same twelve seconds okay so i guess when you when you call produce block or not whatever it's called you would specify the timestamp to produce it at wouldn't you correct correct okay this is more of uh i think mikael is concerned like when you call produce block you give the time stamp and that's fine it gives you a deterministic result i think michael is worried about systems that are maybe dependent on time stamp that aren't right at the granularity of produce block like managing the mempool thing yeah okay so i guess the the only thing i wanted to the reason i kind of got hung up on this and wanted to emphasize is that anything that transaction execution depends on needs to be crammed into the block header because otherwise we cannot uh synchronize best box right so you can add so we've um i think we've discussed it with diamond a couple days ago that the original rpc apis also had this um round out thing plus some second field right which at least in the in the past api they were just passed along as two more fields independent of the block and i just wanted to ask that if we want to ever add those fields back then we probably need to get them integrated into the header and since with the header i think with this minimal merge spec we've nuked out three four fields for example the mix digest and others we can always repurpose them to if we want to have them in with minimal damage to the i mean the remote changes to the iphone clients right so there's not really because there's a time stamp field the time stamp field consistency with the slot can be checked on the consensus side and we can outside so it's not really i don't think you really need to get another field in there um i think mikhail is more concerned about the execution engine knowing what slot it is without the context of being a new block being called and so it can make decisions about things like the mempool yeah so like my my question uh was like how two ample transactions are executed against which block is a dependent block that is created and restored each time after the new one is received from the wire after the new block is received and imported i'm not following what other question the question is you you have to verify validate the transaction right uh before propagating it to the y right no no not really so when you get the transaction you only check whether the sender has enough balance to denounce his correspondence and yeah okay i get it and for a dependent block it matters which time stamp is used right so for the pending block um yes i guess the question is whether there's uh so if you want to enforce this 12 12 second thing then possibly it would make sense to somehow introduce into the consensus engineer a rule too that the time stamps for the pending block would be again on this 12 second boundary but i guess that's an important spec question i mean calls to assemble block are only going to ever be on that 12 second boundary and so any anything opportunistic like the pending block should respect that and then there's a question of can the execution engine just use its local time mod these 12 second boundaries or should it be told explicitly on like a click from the beacon node okay new slot okay new slot okay new slot so it doesn't have to worry about time sync issues no i think it's safer to just let them let the pen i mean you don't really care what the real world time is you only care that it's in sync with your 12 second click right and the pending block is either way just some opportunistic let's try to execute a batch of transactions and see what happens but it's so the worry would be if i had the beacon node and the execution engine on a separate machine and the pending block becomes is like one second off and so it's a slightly different spot and so when i actually call symbol block the pending block's not as useful to me that would be the that would be the reason for the beacon node clicking you know ticking uh on that boundary so that they would be interesting yeah so i honestly i think so in in geth if you don't if you are not mining then you are creating these pending blocks and if you are mining then you are not creating these spending blocks rather you are you you are specifically creating mining blocks which are a bit different and handled differently so um so for validates for average nodes they would just try to guess the next time and they they won't care about they they won't ever get caught to finalize something and for miners uh well yeah i guess i guess for miners you won't really poke at the pending block because you just want you just wait for the next thing right what is the pending block used for when it's for non-mining nodes well honestly i think it's useless uh yeah i was like thinking that band and block is used by miners so so it's the reason i i would say that it's useless is because uh you have 4 000 transactions in the pool or maybe even larger if you count the bigger pools and miners will pick a few so your local note sees 4 000 transactions fix 200 to execute and then you can check the result but even if you swap two of them which are doing some uni-swap things then you will get wildly different results so i don't really think you can trust the the results in the pending pool it's it was somehow how is this exposed to users today like the pending block thing the pending block is you can just query the pending state so you could instead of getting the balance of the current status of the network you can query the balance of the funding state but as i said it's not really useful right the only reason sorry just one more thing that the only reason we didn't really push for getting rid of the pending block is because it acts as this nice little caching layer meaning that i have my i'm maintaining the list of transactions that i think will get included in network i pick 200 best i run them as a pending block but there's a fairly high chance that out of those 200 maybe 150 will actually land in the next block so by the time i'm executing those 150 at least the all the storage slots that it touches are already hot in memory okay so we keep the precast yeah okay so it keeps your cash a little bit more a little hotter but the got it so if you if you want to if you want to keep that functionality we pretty much just need to have the execution engine respect uh mod 12 second time stamps and and then i think you get most of the functionality of today but no problem and even then even if you didn't you probably get most functionality because most things probably aren't calling the time stamp output yeah so i guess the only request that i would have is that if there's this specific behavior that uh every block will be on on the twice or not by second mark perhaps just added to the spec that this is to be expected plus uh it is expected that pending blocks should behave accordingly okay exactly um yeah yeah and also i was thinking that any block might be useful for applications that send some transaction and just get read them from there from the nodes they are hosted to to send transactions i mean this band in block series dependent state um okay anyway uh by the way then uh what is the uh functionality that is used for miners is it just creating a block from scratch or anything else well guest is a bit uh that's that's a good question so because get currently creates during a single mining cycle it recreates a block multiple times first it creates an empty blocks empty log then it fills it then it tries to create better blocks with different transactions and all of them can be mined so it's uh this is with the proof of work network with click you just create the block whenever you get request to the block so i guess for uh for for the e3 murders perspective one option that we could do is to just wait for these two clients to ask for a block and then we just run the transactions the only issue is that then it will take either half a second or however much it takes to mine it to create a block from scratch or the other alternative is to try to prepare a few blocks in advance by guessing the timestamp and then when you request it we just give you the best one and we return instantaneously right yeah i guess this lifetime ticks will be like input for this kind of optimization as well yeah so either work and if there were that like known by a half a second delay uh to be expected then the proposer essentially would before they're supposed to broadcast right at that boundary they would call it early to be able to pack the block but if it's doing the pre-packing then it can call it later um yeah i was like thinking about just standing not only current uh time stamp rate but also the timestamp of the next slot to to fit this kind of functionality which prepares the block in advance okay cool um let's just yeah i'll think about it more i mean and probably add this to the specification as a separate message what wait why would you need a separate message so you are sending us a new blocks anyway and the new blocks are supposedly on the correct time slot so i can just add 12 seconds to that it's not probably now it could be that the new block is like from the from the past it's not like always oh yeah but i mean so if if you if these two chain accurately uh tracks the 12 second marks every block is another second mark then i can just calculate which will be the next 12 second mark based on on my chain head or and the current time so i don't think that's a problem there is when you give me produce block request and i have to remake the block if you make sure you also account for capsules then that will probably work yeah yeah it's just based on time that would work i mean i would like add like a separate message uh which just stands the time this time update you can just extra because in the first round you would probably not even try to be smart rather just whenever the miner says i will never leave the client says it wants a block i can just make a block and the waiting 500 milliseconds is acceptable actually um is it acceptable so what happens so if each two client wants me to make a block what's the procedure what's the time out how what is the expected propagation time creation time etc expected is to begin propagation at that uh boundary and so sometimes there's like a little bit of pre-work done because you know that you're about to propose um and then propagation should happen in that sub second on normal operation so if there were latencies expected latencies in producing a block you would just start your work a little bit early yeah but so uh let's say it takes me half a second unless it takes me one second to produce a block how does that influence the e2 consensus does it matter if it takes one second or not if i wait until the slot boundary and it takes one second as long as i still have one to two second uh propagation for the full network it's still fine uh you're looking for like sub four second between when i'm beginning my job and when it when you get full propagation but the uh if if there were delays from getting the block that took you know a second then i as a block for this producer would just start my job early such that at the beginning of the slot i have the block prepared rather than waiting to be getting a slot and then not only not having the block repair until one second later so i mean these i don't think that so it's a good idea to make the e2 client smart one what i meant is that it takes one second depending on how many transactions i cram in and it might take less or more so it's i'm just asking about the worst case scenario that if i take one second what happens does that consensus does that break block production or is it just a bit unpleasant it likely is fine uh if you're taking two or three seconds it becomes to not be fine why would you not take i mean i guess my assumption is what a miner does is they just continuously process make new blocks and always whenever they have the block available they start mining on that can't you do like a similar approach that you start making blocks from maybe four seconds before your slot time and whenever you're done you start making the next block with the latest information and send the current one to the beacon node so that it can immediately make a block if it's uh yeah yeah at if i make a block with a certain timestamp and it turns out that the the actual timestamp the validated requests from me is different then i have to remake the book oh no but the validator would always request the block with the time stamp of the time when it actually has a slot like that's determine like well at that time it's deterministic like you already you could imagine time sync between the beacon node and the execution engine being three seconds off or something like that right so yeah you can just say what exact timestamp it wants that's what make well yes yes it is so but if the execution engine was opportunistically creating blocks for the slightly wrong timestamp and thus the wrong thought then once you ask no it shouldn't do that i mean what my assumption would be that beacon nodes knows a block is coming up tells the execution engine uh say like i don't know six seconds before and then the execution engine starts making blocks with that timestamp which would then still be a few seconds in the future but that doesn't matter sure so in the current in the current functionality you could just make the symbol block call multiple times leading up and just take the best one right right yeah related the last one you can get that would give you hopefully more fees here but regardless i don't think that we need a an additional message that says hey this is the slot hey this is the slot yeah yeah yeah right i get it i get it okay so that's just okay cool and lucas there's definitely like things to optimize on this and think about the training communication yes so what i wanted to say is that i wouldn't put too much constraints in the spec on how much long it would it should take to produce the block okay of course we can put some max value that we expect because i would consider this implementation detail that is can also vary [Music] for example on hardware so depending on your hardware it can take longer or shorter to to produce a block so if i was implementing etf2 i would do like you suggested so ask for a blog as soon as i know we can ask for is for a block and then they re-ask for a block if if possible and that's that's how i would um advice instead of having a single method saying give me a block and then these one client has to scatter to make a block you can split it into two method just calling it prepare block which says i'm going to ask for a block with this specific timestamp in the next whatever time and then the e3 client can try to make the best block possible and then when you actually request the block i will give you back whatever the best is i have right instead of having to having a poll on that one message you just say start working i'll ask you in a bit yeah so the problem with the poll is that you ask for for a blog but i don't know should i make better ones should i stop will you request once or twice or 300 times or what happened paul's a bit unpredictable whereas if you make two calls then at least i know that okay i gave you my best block i can throw away all the all that scratch work because it won't be used anymore yeah that's interesting but maybe reasonable i think i think i think you can reproduce that with cool as well like you just like the eth2 node just uh pulls and then whenever it gets a block it just immediately starts the next request and uses the last one it got from that sequence yeah right the execution engine doesn't know when to stop the optimization well it would because you stopped making um i guess it produces potentially one more block than necessary i guess like that would be the only downside but i that that doesn't seem huge i don't think that but it's it's a constant check yeah so currently what get does is that i pre so when i start mining proof of work networks i create a block i gave give it to the miners to start crunching on it but then some more transactions arrive and i assemble a new block that's better so i gave that you give that new block to the miners and then some new transactions arrive and then i create a third block and i will keep doing this until something comes in from the network and if nothing comes in from the network i will create a gazillion work packages until something gets mined all right so it's a continuous optimization it's not just discrete make it make it next block um yes essentially every time the transaction arrives there's a possibility that i can make a better block all right that need a signal to stop making new blocks maybe that signal would be a set head that would also be well and one signal could also be if the if the execution engine is like more than a slot past the last calls for the slot you know that no one's gonna be asking for it even if there's like some sort of time description but then you're starting to make assumptions about time and the relationship between the two which is probably not great yeah so i guess this is a kind of an open question for probably for us first spec i would say that just ask for it once and if i have a block i will give it to you and if not then i will make one and give it to you and as long as it's fast enough it shouldn't be a problem all right yeah okay cool yeah great so it's now much more clear at least for me now um okay so i guess we can move on to the consensus engine to the consensus so yeah i have like a few things to discuss here and then there and some updates okay so uh the first thing for consensus is that there is an idea of the improved an improved transition process which is like basically we have a transition epoch um and when the epoch happens uh the consensus node decides on what will be the total difficulty um of the transition the transition total difficulty it could be done like take the current take the difficulty of the most recent block multiply multiply it by 10 or and set this as the offset for this total difficulty and to compute these total difficulty that will happen in the future what is great about it take the latest e1 data because that's known to be across the client right that that's what i was like going to ask which one to use because if we like take the most recent block it will have to be some some kind of agreed by everybody and that requires some additional agreement process procedure but we already have this f1 data voting so that could right so uh like when transition epoch happens yeah the first um um yeah so the eth one data that are in the state right we can use this block hash and get the difficulty and uh add the difficulty to to the most recent block probably yeah so there actually the why why is this a good idea is because we have um the exact point in time uh with no regard to what difficulty will be on the network and we have this kind of total difficulty mechanism preserved which has its benefits and transition epoch is essentially that is a beacon chain fork because that's the point at which you change the data structures to support the execution payload even though they're empty and so essentially there's a lead time there's a fork that actually happens the the fork happens the actual change in update of the consensus code happens with a lead time before the actual transition and puts the the new code in place and then the transition happens and so doing it as a function of that dynamically i think makes sense uh because it also just removes like another thing miners can potentially play with like if 75 of the miners go offline you know they don't delay the the transition uh by like timing and different things like that that much yeah so the open question here is that how to compute this transition total difficulty what to use so we can think about it and get to this discussion i will also think about how to do it like what potential ways of doing it we have um with relay with the relation to the inputs that we already have like in the beacon state and the beacon block and those that we can get from the execution engine yeah i guess the actual worst case in hard-coding it rather than doing it as a function of this transition epoch is that you uh the the beacon chain fork that adds a new functionality like if you set the total difficulty say three months ahead and miners actually sped things up which is obviously difficult and unlikely but they sped things up and made the transitions total difficulty happen prior to the actual forking of the code uh and this prevents that that kind of crazy case from happening any questions to this transition process okay cool um the other thing to discuss is the execution payload size which is like the biggest uh field here is transactions which has the mac size up to 16 gigabytes at the moment this is because we have to like handle two different cases where there are a few uh transactions with like huge transaction data and a lot of transactions was like no transaction data um that's why it is and there are two limits um like basically on the uh number of bytes of each transaction and number of transactions so that's why this 16 gigabyte is theoretically possible and the um potential can add some context yeah the ssd sse lists have a max size because this comes into play and the structure of uh the mercalization rules and like the the structure of the tree and so max like these things all have to have a max size and thus when you take the max as the byte payload and max number of transactions currently then you get some ridiculous numbers like microsoft so this might be a bit uh unrelated but uh maybe not uh so the death peer-to-peer itself also has um a cap on the message size that cap is as far as i know 16 megabytes but at least gath limits the east suburb packages to 10 megabyte this means that if somebody mines a 11 megabyte block then gas will not be able to propagate if somebody mines a 20 megabyte block ethereum one clients will not be able to propagate it with the current specs that doesn't mean we cannot update it fix it extend it it's just a mental note okay yeah i think like this is the way to limit this kind of stuff like on the network um like by just limiting the gossip message size yeah i was gonna say on the the beacon block gossip limits you can earn gossip validation conditions you can definitely handle it there based off of maybe a function of like gas limit so and we already have this kind of limits right in the gossip i mean we do have validation conditions though and you could add this very easily one more thing to keep in mind is that at least with the ethmoid network we've kind of seen that uh unless you have a very very beefy connection aka amazon you have so for for snapsync we are using uh half a megabyte packets and uh i can request packets from quite a lot of peers simultaneously and actually we've managed to overload the local node with uh so we've managed to uh have timeouts not because the remote node isn't sending us the data fast enough rather because we just overload our own inbound bandwidth with data and it just takes that much amount of time to get it through so um in in essence what i was saying is that once you get to this half a megabyte message size it things get funky so again i don't know what the what the long term goals are on how to scale things but uh you we also probably need to take to keep in mind that network messages should be somewhat meaningful in size okay so get it the the option the app is to limit it on gossip also um the gas limit should work but um yeah i don't think like this is the the gas limit will be anyway checked after the message is received and if there is like a 16 16 gigabyte message nobody wants to download it so it makes sense makes a lot of sense to reduce to to get just refuse this kind of thing something on the gossip network stack agreed okay cool uh the next thing is specific to the structures to the execution payload we have the we are going to have like multiple transaction types right on the mainnet or we already have them since berlin so like the default option for the consensus side is not to cope with these different transaction types and just use this uh op transaction approach which is just the representing transaction as an rlp string um and just which is working from consensus standpoint it's just a string of bytes um and have like this introduced this is what it's already done but we can also introduce the union type with like a park selector which will be only one which will allow for now only one type uh this string of uh fights but will give us some forward compatibility with the next updates when we decide to like uh stem from a back transaction and have them explicitly in the execution payload that was the idea right yeah that's the idea uh the idea being that you can as you add transaction type structured in the ssd payload and get a little bit nicer nicer proof structure rather than having just the opaque rlp by load excuse me um but that for simplicity we can do opaque selector for now and then in the future deprecate opaque selector with specific collectors i think this is an idea from proto-pro do you have anything to add right so the current as a z-spec defines a union type we do not use the union type but we can still improve it and what we would basically do is define it as a single prefix byte to the transaction um and then we define a single selector for the back transaction for all the existing types in their encoded form and then i'm talking about the envelope including the inner selector that applies to the ether1 data but then outside of that we would like this structured data for nice miracle proofs and for this we would like to define other options in the union that are more structured with ssc and then we get this second byte that's also kind of like a selector that applies to all the new types of transactions after the merge so i think we just should do this at some point in time so i don't think anything to discuss with this regard here so if anyone anyone wants to if anyone have any opinion just let's discuss it offline and like there was the the last item is the uint256 uh in the beacon chain stack which is used for total difficulty which is like now um it's about 72 bytes i don't remember well you which is uh like just exceeds the unit unit 64. and we have to use some something bigger so what options here uh first is not eliminating it at all just because it's not used in any arithmetics except for comparison so it's just the spec compares whether the transition total difficulty already happened or not and yeah that could be handled uh the other option would be to i don't know to denominate it somehow but that would probably require some denomination happening on the um execution engine side because it returns little difficulty i don't think it's like probably it would work but yeah it just requires additional um additional work not sure which which way like it's better sorry i think i missed that you're looking for an encoding for a big integer in if2 uh essentially we've avoided bigent's arithmetic and he's two on the node side so far um and right now with total difficulty there is a big end yes right but it's not going to be encoded it's just you know got from the execution engine compare it to to the constant um yeah it's not i mean it's not going to be encoded in ssd structures sorry i don't understand execution engine returns summer total difficulty to the consensus engine right this is required for transition process for transition procedure so the transition uh like happens once the certain total difficulty is is reached and right now the beacon node literally just does not have big end arithmetic and so you could the the total difficulty could be denominated in a un64 and take off a bunch of the um precision and you'd also have to have a function uh that returns that with uh the lesson precision yeah so like the question is how difficult it will it will be to implement in 256 on the beacon chain side that's like it if it's not too difficult i would not i would like to leave it there any if your clients want to speak up terry's from prison here it's not too difficult for us to change and we do use speaking some places yeah for teku i don't see it being difficult we already have uh begins for f1 so we can change it cool let's uh ask the lighthouse folks too but let's just operate as though we can do a big end comparison for this one little thing um unless we hear otherwise yep great yeah so let's just yeah keep it as it is and if there will be a problem actually we can change it okay well with the proper encoding you can do a byte through byte encoding uh comparison if it's just for order oh yeah right yeah but you will receive it uh from like why uh in in json format i guess yeah but you can i see if it's encoded you can like even compare and compare it as like uh lexicographical array that's like an exact decimal form maybe but uh otherwise uh more tricky okay cool anyway okay here we have like 15 minutes let's go to rainies and updates um so proto do you want to sorry sure so um in the past week or so we have had a few of these office hour type of cars which are more casual cars where you can stay in sync with the very bleeding edge of reinism i'll give a summary of what we have done so far so we looked at the first devnet in how to prepare the genesis and then also chatted with a few clients on like how we move forward with the rpc and so we have this one genesis tool ready to go to prepare a test network we have a guide for everyone who would like to set up their own test nuts how to use this kind of thing and i think we should basically try and focus on the rpc on the updating to the latest spec and then we're ready for the first prototype devnet thanks um i would just go through like client updates um on where everybody uh on the with regard to ray and is um yep so maybe we can start like from geth well i kind of gave an update at the beginning of this thing so essentially the first uh first version was the decision was that uh we're going we're keeping guillaume's api updated to i mean it will be changed and updated to to confirm to whatever spec the current api is but otherwise it will still be based on directly just injecting data into the chain anything else yep great um nevermind so uh we have an initial implementation that i am currently testing i hope i will finish testing stabilizing it by tomorrow and if any of eth2 clients would like to participate in testing integration with the rpc i please contact me i would be very happy to work on something like that for example tomorrow so if anyone is available for that great um probably have any any guide how to run the other mind in reynolds mode uh yes i can write something tomorrow but i would like to you know just experiment that i didn't like uh miss something in the spec and we can i can communicate with an adhd to note if anyone has this kind of test set set up or something cool yeah great so um actually work on like taku i'm gonna to you it's gonna be ready tomorrow so i guess i can experiment with catalyst and with another mind as well so just reach out yeah cool thanks anybody from like open ethereum to turbo gas um bazoo and abezu is starting to work on on this back as well okay cool um so yeah let's just yeah go to the consensus um clients we can we can uh we can be controlling clients so as i said that i'm working on takuru um should be like ready by tomorrow i guess uh we'll test with catalyst first then try another mind hopefully anybody else do bagath and know what's their status is um uh so what about prismatic yeah um i'm i'm still not much progress on the api side from my end i'm still reviewing the changes so i think once the api becomes more formalized i'll put it to one side it probably takes me a bit to catch up so that's not too bad other than that we built a faucet and for our regism it's fully configurable it comes with a ready react and angular project as a reference it's also dockerized so hopefully that could be useful and then we also created a guide to startup to to basically start prison for uh rapism so yeah yeah thank you so much for this falset um serious all integrated i guess in the first step net i'm just dropping the the guide on how to run prison that you have mentioned okay um nimbus uh members do you have any updates with ricardo rennis we're working on we've just started working on ryan ism now we have a pr but at this point we are experimenting with catalyst but it's not here we'll be ready for the first testament that's our goal we still have a little bit more work to do in the rpc interface between members and catalysts okay great um anybody from uh from lighthouse nobody's here um anyone else want to give the an update okay great um thanks everybody i have a question not an update if possible um can you give a rough estimate on the dates and plan for the devnet sure so the original idea was to start the devnet somewhere in the first week of the hackathon just it's experimental short left and it's like okay if you join later or or otherwise however this is this kind of opportunity where you just look at can we try the rpc in something more of a shared devnet and so i just like to try and spin up whatever kind of prototype we have in like in the next week or so [Music] and i have this example configuration for the first deafness up in the realism repository i'll share the link again in the chat and there i specify monday as the the ethereum one uh genesis and this can be skipped and then then stay as the actual genesis so there's this delay of knowing the exact genesis state of the theorem one and then from there you can compute the one for ethereum two and then on wednesday the actual like chain event where the first slot starts uh ticking um but this is purely as example right now like i need i would like to confirm this and i probably wait for one or two more office hour calls for to to learn about the readiness of clients thank you very much any any questions any more questions with regard to renaissance school any other discussions questions or announcements anything else before we wrap up great i'm sorry for screwing up the call this zoom link or fix that so okay thank you so much for coming see you tomorrow next week next month um every time so bye bye thank you bye bye everyone