Merge Implementers' Call 4

hey hello everybody um welcome to the merchant mentors call number four um do you hear me yeah yes cool it's been pretty silent here okay so we have like regular updates for today and a few discussions on top of that um first item in the agenda is the iranism and we are currently running nocturne devnet which has started yesterday um it reached finality and look stable so far there have been a few edge cases which we saw on this um devnet and also there is like an issue with deposits uh with in particular with if one deposit voting but i guess we're near to solve this issue and we will see deposits um like eight teams are running their validators and several community members are doing this as well and they are like helping with doing some testing on it depositing trying to break uh trying to submit bad blocks and so forth so that's great um and yeah um i have like a couple of questions regarding the nocturne devnet um we've been planning to test transaction propagation there um is anybody from go ethereum team on the call now so i believe it's a holiday in germany so most of the team will be offline okay probably proto you you might know um if this pr is about to get merged or already merged i don't know which enables the transaction propagation oh well i think there is this one pr gary that improves on some of the things but i'm not sure about transaction propagation the test net will run for a few more days at least so we can try later yeah okay um yeah makes sense yeah the other question was about like state sync but yeah i guess that was mostly at rest to go theorem team again so let's just keep it um yeah if anybody wants to join nocturne you are free to you're welcome to do this um i'll just drop yeah you may reach out proto or uh just uh drop message in the iranism discord channel and request for some if you get deposited yeah but we need first two deposits to to to be this deposit issue to be resolved okay so here is the layout for neptune all right proto do you want to add anything about nectarine well about rainism in general maybe i think yeah that's like the next yep okay sorry the other thing let's start talk about this yeah yeah so you may just start it right away right so with reyanism i think that we should basically wrap up the hackathon kind of things and think of the merge more like this thing that we are going to work towards with production and this basically means that we want to do the rebase which i'd like to call it if you're playing with git terminology we have altair and london first this is this missing functionality which has been developed in parallel but now it's time to try and like layer the merge work on top of these updates and then implement the new api so we move away from json rpc i'd like to i'd like to move away from that it's up for this question and then um from there we have a better chance of a client that can do the fork transitions well and we can write less code that we have to throw away later so we can work on staging these more difficult problems and make some progress there and just some some context on uh consensus side on altair is that we do have a pre-release another few release coming today and a target for a freeze on that a week from tomorrow so that after that we would begin to rebase the mur the merge spec on altair uh because we'll also be seeing spec conformant um altair releases soon after that on the client that sounds sounds great um so like the rough plan is to wrap up ryanism right and then um like while client implementers are focused on um altair and london we'll keep doing some spec and research work like figuring out the transition process we will do some proof of concepts on top of the infrastructure that we get out of ryanism thanks a lot to proto for doing a tremendous amount of work on it and yeah then we are getting back after probably altair and london is like nero to get finished we get back and like spawn and other merch test net hopefully with uh state sync with the new consensus api which is going to be discussed as well and specked out during this period of time so it's like a a month or two um so that's my understanding and i i think yeah that this kind of plan makes a lot of sense to me yeah i think we'll also extend the consensus test vectors for the merge as well which there's like a lot of work in that direction right now on the spectrum though and it'll certainly be ready for kind of the next wave of development yeah yeah definitely um also uh it's been planned to deploy the vistrol's devnet and to work on charging during realism this work will will keep going in post-training so it's not like a pendant and hopefully we'll like have yeah as i already said we have all resources like infrastructure blog explorer scripts dockers just to spam devnets and test nets easily anything else regarding randomizing i want to echo what mecha said uh huge props to proto for really an effort and for all the contributors and stuff it's really awesome to see the devnet up yeah we'll like really have seven clients implemented the initial merge stack which is amazing result which client is missing um yeah open ethereum is missing yeah and i guess turbo gath is also um has also missed this one but they can like catch up with the changes from go ethereum but i don't know whether it's possible now um the question from micah i don't know how to answer on it will the open will open very room be able to make the merge if no one knows the answer that's fine i'm just curious if someone had any clues i think they're still thinking through it i don't want to speak on their behalf okay yeah yeah definitely probably just somebody heard something and which makes sense to share here but anyway if not let's skip this okay so i guess that's all for anism um and we are moving to research updates um yeah one update from my side i've been supposed to start work on the transition process but unfortunately i had not uh have enough time to do this um to to to to come to some you know readable spec or this kind of stuff for analysis that um that i was supposed to do that i was planned to do but yeah i guess we'll start the next week was actually a bit busy with the orionism and other stuff any other research updates um and miguel this is primarily to [Music] change the transition portion to be a dynamic total difficulty based off of fork yeah yeah that's that's it i was like going to analyze uh the um way how difficult it could be changed throughout the voting period and what value would make sense to how uh what would be the right way to extrapolate digital difficulty that we could expect gotcha yeah let me know when you open that up i can give you a hand yeah sure because uh yeah it's reasonable to use the um if one data voting for to get the block hash which we will use for extrapolation because yeah otherwise we would need to come to consensus on this uh block hash first which is which does not make much sense but we'll see yeah yeah i my god is to use the first eth1 data voting block after the beacon chain fork but as the function of total difficulty rather than using something stale but we can chat about it yeah cool okay other research updates withdrawals maybe yeah i could say a few words i got good feedback from the last call thanks for age and made some improvements uh edit partial withdrawals section it looks viable but it will be restricted to validators with bls withdrawal credentials so it's very limited for usage in shared pools i think we cannot do something on chain interfering one with it but something like shamir's secret vls could work in of chain pools you could check an updated dog with rewards withdrawals section and provide me some feedback on it thank you here is the link will do thanks thanks symmetry anything else before no one okay cool let's move to the spec discussion and the first item is consensus api standard i think it's a good time to open this can of worms uh so we like and to start the discussion yeah i'd like to just share my very um of the top of my head uh opinion on that um so we like have jason rpc yeah the this is the discussion about how the consensus api uh will be provided by execution engines which underlying protocol we will use for that and once we make a decision on this protocol we are free to design the particular endpoints and move forward so like the [Music] what do we have so far is the json rpc api which most of people here are familiar with i guess and the other one is the eth2 api uh the beacon node api uh so json rpc is like based on the yes http um as well but yeah it's your api is the rest api um and my opinion is that the in general i lean i'm leaning towards the rest api um it's like convenient it has a lot of tools it can be secured and so forth um but uh the argument for using the json orbicy is that it's been already implemented in all of the ethon clients um and we will just need to reuse the code but one thing that we should keep in mind here is that this new api will need to be exposed on a separate port and not exposed to the public for security reasons because this is the tight relationship between the consensus layer and execution layer so i think that implementing this from scratch with like rest um approach uh makes sense uh from this point as well uh to avoid like bugs and in the implementation that will relate that will abuse the uh it will um like damage the security anyhow so um yep let's just discuss it um any any opinions that we should use json rpc for this consensus api i have a question uh can you provide me with some more concrete examples of what we will gain if you will re-implement it because just saying that there's tooling that's not really doesn't really clear much so if we should focus on what it will bring us and then we will can decide not before yeah that's fair okay danny um i am actually i'm gonna pull up an old comment from peter and martin when we were debating as to the api between a beacon and validator and peter jumped in and gave a long argument for using restful http instead of json rpc and regretted the choice of json rpc on current ethernet client and here it is i won't go through it all here but if you're interested take a look i think that's so relevant when making these types of decisions obviously i think certainly what does kind of implied is that the uh one of the main drawbacks of changing this kind of thing is adding support for another api type on clients that already serve json uh you said just just now you said restful http did you mean that or is that a misfit are we talking specifically about http which means web sockets are out or is rest over websocket considered still part rest in this case they're still on the table well i mean rest of the design pattern right and if you can transfer you said restful http like so the reason i'm asking is because like i'm a big fan of rest but i'm also a big fan of websockets and especially for like what's essentially going to be a long live connection like this websockets make more sense in my opinion and so rest over websocket i would be like a huge advocate for where i'd be much weaker advocate for doing all the work to do rest over http or doing both you know rest over hp or websocket like we do with json revie make much sense in this context um because correctly i'm wrong and maybe i am here but the there will be a reasonable amount of traffic over this channel and we want to make sure that we're not getting inundated by just http overhead with websocket you spin up the websocket once at the beginning of the connection and you leave it open and the overhead per message is very very low compared to http whereas with http oftentimes you end up with more overhead from hp headers than you do for the actual payload yeah we have a lot of people well later that currently working uh over http i believe you might be overestimating the amount of communication and overhead there uh not from the variables themselves which is that the amount of requests that have to be sent and the payloads there are actually probably pretty small yeah you're sending a request for a few seconds right yeah like i mean it doesn't feel like the header should be large compared to like say one block so one i would actually vote for hdb because like it's just so convenient that you can do things like just curl and requests and stuff like that and like any any other api tends to like have like much stronger blockers if you just want to experiment and do some quick stuff uh democrat you meant you're um on the like rest side i mean you're in support of rest because jason rpc is also um yeah i'm in support of http if we want to do rest and we want to do web sockets together then we can have to emulate some parts of the rest in websockets like things like getting things from the path we need to somehow code encode it etc because rest is it was designed mostly as http api if i'm correct yes and micah sorry uh yeah i'm going to back down websockets if there's um if there's not much throughput i am not surprised if i'm overestimating the volume of traffic here do we have an idea on the so one of the arguments for json rpc is that it allows clients to reuse code because they specif they specifically will need to be opening a server on a different port does that change how much code they're able to reuse like do we know our clients designed in a way that they can very like it's easier to spend up another copy of the same type of server again within their client or would it be just as easy to just spin up a different type of server oh yeah so i wasn't trying to respond to that question i put my hand up before um i could try and respond to that though i would guess that um making a http api is probably trivial for i'd say all languages involved um so i wouldn't i wouldn't imagine it would be that much that much work but i'll wait for other people to answer before i change to a different topic so if i can answer uh mike asked question uh it's very easy for us in other mind to spin up a second port we are already doing it for websockets communication so just add another one would it be significantly easier for nethermind to spin up another json rpc server or just as easy to spin up a rest server within another mine it will be a bit easier to spin up just the second second port i don't think that doing a rest uh would be that hard but in the rest you have you should for example correctly use um http code for communication yeah that's part of rest a little bit like carefully designing the responses etc error responses which are more or less defined in the json rpc already um okay paul do you want to share any other opinion yeah so what my understanding is that one of the things we have yet to figure out with the communications between the consensus and execution clients is how do we deal with them syncing between each other for instance if you like if your consensus client is long running and then you say wipe the db of your execution client how do we get them to sync with each other again um has this has this been like fleshed out somewhere because it seems like it might be um in important factors in determining the the communications that we use um and i'm especially interested because i know that sometimes rest can be um i think it's great for this reason but it can be restrictive at times and i'm i need to think through but i'm not sure if we'd start to run into problems with rest if we're trying to sync these two processes between each other whether we we'd start inferring state between requests and break rest so i guess my primary question is have have we looked at how they're gonna sync together and i've just missed that or um i don't think that rest will give much more more overhead in this case in case of sync than the regular json rpc but i don't know that's just my opinion is the connection between the two stateful at all or like could you have three execution clients on the hypothetically have three execution clients on the back end talking to one um consensus client and everything would be fine or is there like an assumed state um it's stateful because like the it depends of course on the design of the execution client or the execution engine um like if we have like three servers that that are in front of the execution engine 4 which processes blocks this is one design and if we like have the monolith architecture as we have it today so um yeah there is a one one to one relationship or one or many to one uh many beacon nodes to one execution engine but not the opposite but how is it it doesn't need to be stateful i mean the only state would be whether the execution node has actually received the block right but once it has it like i think that should be the only execution engines rely on a notion of the current head for a lot of things um that could be changed uh and you could just like kind of have a represent a more dynamic representation of of the block tree and multiple different potential heads but they today rely on like when you set the head there's certain things that are like optimized in terms of what state is available and which pending blocks are being created and that kind of stuff is it possible to design other way it would be really nice if this could be a stateful or stateless connection like can we make it so when the consensus client makes a request of the execution engine it gives the execution engine at that point in time all the state it needs to answer that correctly i mean you certainly can and i think the the so inserting block has the state that it needs you know i mean you either have the previous block or not and um a symbol block i think right now tells us the head you want to assemble on and so the information again is there but there's still like certainly likely some optimizations and reuse of how these things work today that that head becomes really useful um set head but you can you can certainly kind of design an execution engine that doesn't really care about that head and uh the other methods i think would work fine but it doesn't reuse existing code quite the same okay so if if a consensus client asks a execution client to build me a block um it will tell it enough information that it will either get a correct block or it will give back an error saying i can't build that because i don't know about this head you're talking about um but it won't give back an incorrect block right it has enough information to make sure that to validate it let's give them back the right block yeah right and uh when you were like uh saying that like suppose there are three execution engines and there is one consensus client in front of them and yet in order to get to stay in sync in order to maintain the state uh and to maintain the full state and the execution chain um this uh consensus client will have to feed all three with new blocks and with any other information required to get sync and stay uh synced okay so you'd have to essentially whatever you have routing there would have to do a broadcast so it receives a um you know new block new set head from the consensus client and then it would broadcast that down to all of its connected execution clients hypothetically so that way they all update themselves right yeah like set had a new block i think one of the things paul is concerned about is for example if uh consensus says insert block and the execution engine doesn't actually have the parent in there you know what is the communication protocol to recover from that does the consensus just walk backwards until parents until the execution has what it's supposed to have and then inserts from there or is there some other more dynamic recovery um that's i don't think we've quite worked and that's the kind of like how are these two things in sync um you know what happens if one shuts down and then you it comes back up and doesn't have a database like that kind of stuff we haven't worked through that and i think to answer your question paul we haven't worked through it um yeah actually before the assemble block with some parent hash is sent we have this new block um with this parent hash right so if it's it was not the case uh then yeah there is a consistency between uh the beacon chain and execution chain uh if we are talking about like uh one consensus engine and one one execution engine if this is like the infrastructure where you you have like multiple we can become clients we can change clients using like a few execution engines or something like that yeah probably that could be the case so yeah it seems to me that um like a test would be if you have say one um consensus client and then you had a proxy and then say three execution clients behind that proxy um that wouldn't really make sense because you like you know the that walking back process procedure that danny was talking about would just doesn't doesn't make sense if you start bouncing off random um executions clients based on the proxy so it gives me the idea that maybe rest isn't the best thing that we're chasing for i mean naturally i i'm i would prefer to rest just because it's a it's a like over a json rpc just because i because i prefer that but this just kind of feels to me a little bit more like an rpc like a one-to-one rpc yeah i get it what i don't really like about json rpc is that it custom error codes custom error messages but as it's been said we're all familiar with that and one thing where is considering here is that all if two clients currently support json or pc and have a json rpc client to fetch deposits and get eth1 data for the rewards so we don't have an overhead and like implementing this json or pc client either thanks i was just gonna say that um the current design is having you know these two separate processes consensus and execution processes i think is the way that we're going for now just because it kind of makes sense but um a world where they're wrapped in the one process um not necessarily maintained by the same team but they present as a single binary um seems appealing to me and perhaps using something like json rpc is nice because we could start to use like a ipc um socket as a comms transport between them and if we're doing something like instead of having two processors we're importing them as a binary then that works very well for them to talk between each other um whereas like having a http client http server between these two like inside the same processes is a little odd as well and by my by binary you mean the binary protocol so i mean binaries in like um like you know something.exe in windows kind of thing okay correct me if i'm wrong but um let's say the consensus client says hey assemble me a block with this parent an execution client doesn't have that parent um is it correct that the execution client then goes to its own gossip network to get that block it doesn't talk back to the this claim is that correct it's still one way communication or request response rather there are two options to respond back with error and which will be like the like database and consistency error um because these two parts are actually one client and their data should be consistent the other option is yes to try to go to and download and pull this block from not from gossip but from the block yeah from eth protocol network protocol and to get those blocks but yeah i guess what was i kept in mind is what like it's just responded with error so there is no such parent block so i thought we're not responding to the etho quests anymore didn't we cut that part of the gospel or cut that part of the protocol out sorry could you repeat the question can you still request the block through ether did we cut that out as part of the networking to make the execution engine kind of more silent uh no we don't cut this out we just we cut out the vlog gossip got it it's not cut out because of how initial sync especially state think might be performed it can still be utilized and there's certainly an interesting design decision here if there is some sort of like if the execution engine detects some sort of inconsis consistency because it's being requests are being made for things that it doesn't know about it it can use that endpoint to go and fill fill you know the unknown things and to use the p2p network to get back into consistency with the consensus node which is interesting it probably works out of the box but it's also kind of a strange design decision i like it because it makes it so the so basically the flow here would be the consensus engine says hey do this thing for me execution engine says i can't do that and then it basically goes and fixes itself on its own like it's essentially a self-healing system and so if you had like an edge server proxy server between the two you could notice that oh we got a consistency area take that execution engine out of rotation because it's down for a bit and then we'll try it again later and meanwhile i can then fall back to a backup execution engine or just it's got three in rotation now it's only got two in rotation or something and so the whole system ends up being fairly self-healing if the execution engines can heal themselves when they get a request that indicates they're out of sync right yeah i i kind of like it as well i mean there's it also just gets to leverage exactly what the execution engine does today to heal itself if it finds learns about things it doesn't know about but it can still especially on the one-to-one communication that kind of kind of complicate things like if you get if you talk to an execution engine locally and it doesn't know something then you just kind of sit there and wait and hope that it knows about it in the future because it presumably helps self-healing itself and the consensus can't really be as proactive that it as it might want to be i see because it would just basically have to just pull it since it's a one-way communication channel until it gets back a success right yeah the case we're discussing now is um yeah in if there is no like um like if consensus client asks for assembling a block on top some of some parent that is not known for that is not like presented in the execution chain it would mean that um the consensus client before while importing a parent of this block got failed or something bad happened because if execution engine response was like this block is valid then we assume that it's been inserted in the in its uh database and it's changed so i would say that this is like uh like some weird and odd uh case rather than something yeah that should be usual well i think the re the reason i keep harping on this um one to many is because i think pragmatic i suspect pragmatically what we're gonna see is that we're gonna see a bunch of people running validator clients and very few and leaning on third-party providers for the execution client because the execution client is so expensive to run like i run a few and they are not cheap and they're not easy like it's you you basically have to run opera an operation center to run an eth1 client or an execution client right now and that isn't going to change in the media future like we're working on that but that's a ways off and so i think realistically we probably will see people going to places like infira and quick node and all these and alchemy for their execution client and they run their own um consensus client and in that scenario we do have exactly this where you've got you you hit some proxy server and the processor is going to route you to one of 100 execution clients and so i suspect that's going to be at least first the time being that's going to be the the common scenario um not the uncommon one like we would like which is unfortunate but i think the real i suspected reality i think an operation operations center is pretty exaggerated um i agree it's like it's it's it's a big problem it's like where it connects more than two times um but also as a comment like uh from the research perspective we are thinking about how to change that like using improve custody where we do make it necessary for people to run their own execution like we want to make it really hard to do exactly what to describe like we will actually break that pattern that we at nimbus have users that run both get an invest from a raspberry pi i've heard rumor of such such people i don't know how they do it i've got like a a server that i rent that i struggle to keep on yeah we we struggle to keep gath up on like a you know box with eight gigan and four cores um and then sometimes it runs fine just real quick perhaps the the the right question is is we should if everybody is in agreement that we are going to brick people that are not running both execution and consensus client then yes i think we can kind of design towards the one-to-one connection and focus on that making that good and smooth if we think that at least for for the time being they're we we're going to allow for and enable people to do like use alchemy and infira then i think we should design for that because i do think that's going to be more common so maybe the first question is which one are we actually designing well there's two types of there's validators uh sorry i'm getting a lot of feedback there's validators which uh there's an explicit desire to put a proof of custody on execution so that it's not outdoor school but for users in general there there's all sorts of uh design considerations you know running a beacon chain and and getting proofs about state uh execution their state or running a light beacon chain and not running execution at all or you know amongst different many different versions of that so there's not just the validator that we're designing for here not sure also maybe to add maybe to add um that uh also the one-to-one design might include things like secret shared validators and stuff like that we should also consider that because it might make sense for example to run a secret shared validators where you have uh four separate beacon nodes but only one execution nodes uh designs like that uh made possible so i wouldn't i wouldn't necessarily say that just because we don't want impura that means we should optimize for what you want yeah is that yeah sorry go ahead i was gonna say if if we do look at um one too many do we have this so the idea that you know if a consensus um client requests a block from the execution client and it excuse me it doesn't know the parent and it goes and tries to find the block itself don't we have the problem that the execution client can't rely on blocks being valid unless it can verify them with a consensus client um right and you might say that okay so then if it gets a request for a block then it should assume that it's canonical but then that kind of breaks when you get to infuria when you you you'll just have people spraying anything at it wait validity is independent of consensus right so you could anyone could tell it to follow a an execution chain and that would be and it could be valid with respect to execution parameters you know the evm transition correct but the consensus any any consensus kind of outer layer on top of that is not going to pick that chain if there weren't a valid uh set of transactions i mean a valid set of wouldn't wouldn't that be a dustbin by then though i could just fill up absolutely if you open it up if you open it up to like if your opens up to anyone being able to trigger whatever i mean i think that that's certainly a loss factor yeah and that's what i was going to say that it must be a consensus block first um it can't self heal from just getting the execution block hash it can if it's a trusted relationship i mean i i the idea of consensus running i'm sorry if in bureau running execution layer clients and not having any view into like the consensus layer i mean i think that they you would need to like they would need to design their own trust model here on on these endpoints i don't think that you can open up any of this stuff to arbitrary requests regardless okay so getting back to json or sea rest api anything any arguments against or um against json rpc does anybody have anything to add here i'm i my feeling is that we're we're not quite at that question yet that we still don't understand the the nature of the the communications between the two the two items and that i think when amica went down the role of like talking about one to one or one to many that's probably what we want to what we need to be thinking about in abstract terms before we start to pick protocols but perhaps i'm missing something yeah i i would tend to agree that these one-to-one one-to-many many-to-many type of questions and the staying in sync question need to be poked on at least for a week or two uh to even see if like the current communication protocol is sufficient and then if if it is or is not uh that that might tell us what we want to do here i mean my gut i have a uh flight preference for respiration tv but based off of what i currently know but i think there's unknown if i was to choose how it ends up i'd love to see it to be like one-to-many restful http http because i think that's super flexible that'd be that'd be nice to aim for i reckon proto you had a slight preference for wrestle hdg because of the authentication model is that something you want to share before we move on well so i think separation is really important of the two different rpcs and this is for security as well as just stability i think in the current design there's a lot of assumptions on the e1 connection on the existing event connection for the deposit data fetching and sync and um in this test net it's really been a struggle mostly to work around these assumptions to make it stable and i think just starting with a fresh connection that's focused on consensus isolated and secured it's just a much better approach understand correctly are you basically arguing that by using a different protocol we kind of guarantee that we're not going to have clients with bugs that cause bleed between the two yeah so within the json rpc they're like it the protocol itself is fine it's the client that exposes it and decline that fetches from it that have these existing assumptions around it for deposit data sync and at the same time we mix it up with the previous existing code and i think that it's just like you you just increase the the surface for books in the consensus api so cody are you kind of making an argument for dedicated deposit endpoints on execution clients honestly i think that's a better idea as well we have seen various i also like books in the receipt logs and whatnot and if they break something this critical then yeah like it would have been a lot i would not mind separate lucas do you want to add something uh so a little bit on the side because we are i heard some talk about uh one too many clients um connections is that is that right oh it's okay uh we were even thinking about making it many too many so uh arbitrary number of clients could talk to one uh ethereum to letter in one node and vice versa so uh we were also what this would be this would need some additional work on our side to enable that and we would have to differentiate the clients and keep some state for them uh some block tree info about the current state and some transaction pool uh need need to be separate uh but the rest could be probably shared that might be a good way to like reduce resource usage because if each ethereum to validator node would require an ethereum one node that might be quite a big requirement if we can share each ethereum onenote for like 10 or 100 ethereum two nodes that would make it less of a pain and easier for like providers of that of that infrastructure for example unless there are any other arguments i think we should wrap up and uh yeah we are already using json rpc for consensus api and we'll keep doing this for the proof of concept and for development phase um yeah that being said it's yet to figure out what are the requirements for this communication protocol uh with regard to the sync process so we'll see we'll see more inputs to this question and get back to it later on okay yeah anything else here okay cool let's move to the next one okay spec discussions execution um first of all uh we met some interesting edge case uh with the catalyst on the nocturne.net um there was a kind of uh yeah okay so the the the case is the following uh like um suppose we have a block uh and we have like two children of this block um and these both children have the same state route which is legal because we don't have uh minor rewards anymore and these two blocks can have empty transaction lists and what catalyst does it rejects the second block it observes with the error like yeah this and this mechanism is a part of mechanism that protects from state mirroring attacks i guess nobody from go ethereum here to discuss this particular behavior but yeah probably proto can add anything here so this state mirroring attack really only applies to like long range attacks i think so beyond like more than 100 or so blocks in the test net when they're done with many transactions it's very common to have the same state routes and rewards are issued in the consensus protocol and not in the execution protocol so you'll end up with the exact same state and maybe we should redesign this so that we have a unique state route parent block and this would be changed if here in one side yeah i have like a related question does any any uh other uh econ clients has a problem with the or has issues or has some protection against um having this kind of uh two blocks with the same state route is this problem there's a warning coming from guess but does it actually hurt the functionality currently so when it inserts a side chain and reorganizes the blocks then it will abort yeah just reject the block right so at least for basically we need to uh it's on my to-do list to read martin's right up and see how it affects us so we don't know i don't know what the behavior is right now okay i mean essentially if the if the consensus side tries to insert what the execution sees as a block it already has and it just returns and say it returned and said like okay i i have that already um then and you point then you did a set head assuming that method exists um would there be much issue here because essentially i i suppose two different we talked about this a little bit but like two different beacon chain forks could point to the same underlying execution layer chain and that both of them essentially if you reorg from this to that you'd say that head and then point to the same place and the execution layer probably doesn't care i think there's probably just some like minor things to work through here but i don't i don't suspect that we would need to enforce that every beacon chain execution layer root has is unique across forks obviously you could do that by like inserting so the problem why we protect against this attack is to optimize the way we sync these execution padlocks in the ethereum one client so if you can trust the state route then you can basically skip ahead and when there's this kind of long range mirror attack i don't i'm not familiar with the details then you may skip this validation and so even though the state route is the same the block contents could be different and then you could get into this dangerous kind of sync scenario um what do you mean by like contents being different so if you optimize to trust the state route then you can get this kind of problem where if you reorganize and then accept the state route because it's the same then your block contents may not be federated correctly i have a question uh we are talking about the mirrored state attacks yeah yes uh so i think it's related to pruning right and we will prune on when we were on the finalize a block from ethereum to consensus in ethereum one execution engine because before that we cannot really prune yeah yeah i agree because with europe with you on that also i think that uh this is not related to uh all uh potential and prune state try pruning implementations this is uh i might be wrong here um it's probably better to ask your ethereum but from what i understand um it's related to how the how geth does state try pruning and yeah this kind of attack is specific to geth and to this particular pruning algorithm when when they have like this side chain which is not executed before it reaches a greater total difficulty than the canonical chain and then they switch to the side chain and if there is like a gap so they can't retrieve the state because it's been pruned uh they trust like this portion of chain they can't execute that's and that's where the state mirroring appears yeah so is it based on reorganizations um yeah in reorganizations and because of pruning yeah so if we don't pronounce the thing before we the block gets finalized we don't have this issue really yeah right so i don't think we need to make state route unique for each block in the context of uh executing and the context of execution on the beacon chain but this this is just uh this uh like edge case appeared in the nocturne devnet as a signal to to consider um this state route in not unique for each block and yeah keep in mind for further um design or like testing and so forth so in never mind we support side chains when we expect sometimes the state should not to be uh different because of low volume of traffic there so we are working fine with that generally it's uh um right you said that there was a write-up from martin on this yeah he uh posted it recently in the um in the private key base that these one devs have um yeah i got to read that i think it's ultimately just a link to a to a github uh yeah okay um so anything else on the execution side anything that it one implementers would like to ask or discuss here okay go so the next step is consensus discussions i don't think that much that there is much to discuss here but just in case does anybody want to discuss anything or ask a question okay cool um so let's go to the open discussions and there has been a proposal to move this goal to the like to the same day uh when if doing another skull is happening just we will just make it but uh for the same time slot so it will be like one hour of uh merchant panerai school and then the two implementers call just wondering what do people think about it and probably polarized this question and probably paul has can would like to share his opinion yeah sure thanks for raising michael um yeah it was just my suggestion um these days this call is 11 pm now um and then midnight when daylight savings is on um they're pretty disruptive um to sleep schedules so stacking them together um is appealing to me i'm not sure if anyone has reasons why that's not a good idea perhaps i think also meeting fragmentation is also something that i'm interested in i like to pack my meetings together um yeah yeah i just wonder if we can see it for two and a half hours um like if we have a lot to discuss with the merchant with regard to other e2 stuff the other one the one problem i see is like call exhaustion an hour two uh but the these two calls are like fairly light usually i think that might change a little bit as we're moving towards altair production but those calls are often even only 30 or 40 minutes any objections from trying it out and see how it goes um okay so let's just try um so we have like youtube letters goal next week i guess we might try the new time for the vertical the like three weeks after today right i think that's good a little bit of extra time now that rainism's died down and there's a lot of like work on altair in london that'll happen that's that's a fine break yep thanks for uh the kind consideration everyone it really means more than you think i have a guest room you can just move in in colorado time zones are pretty good over here yeah i'll ask my government if i'm allowed to leave yeah i guess you probably can't even get into this country i've lived in the us don't believe anyone who tells you their time zones are anything and near sane oh it's great we're awake i wake i have calls at six in the morning it's wonderful yeah there's sometimes sometimes there's seven okay any closing remarks okay thanks everyone thanks for uh this great month of ryan's work that i've been lucky to be a part of um see you in three weeks thank you thanks everyone thank you girl hi guys