# Eth2.0 Call #69 [2021/7/29]

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2021-10-09
- Duration: 58:47
- Topics: blockchain, smart contracts, distributed ledger, ethereum
- Watch: https://streameth.org/watch/yt-NJWYZ0gABfg
- YouTube: https://www.youtube.com/watch?v=NJWYZ0gABfg

## Description

https://github.com/ethereum/eth2.0-pm/issues/229

## Transcript

okay yeah welcome everyone uh danny is not here today so i'll be facilitating a call and let me pull up the agenda uh but i know the first thing was the uh the devnet so it seems like it went pretty well uh there might be some minor bugs with block production and the sync aggregation but otherwise uh we successfully forked the devnet it looks like and uh yeah building a chain uh was there anything in particular anyone wanted to add to that right now [Music] we might we probably might want to have a chat offline about whether we want to fully declare that success or not um it did it did pretty well but i'm not i'm not sure it wasn't um like an a plus i would say so yeah maybe we'll have a chat offline about whether we do another one it's fair yeah i mean i think we definitely want to do another one but it's still exciting to see progress even from the last one yeah totally well done everyone we did deploy some kind of last minute fixes and i guess this didn't go that well i've seen a lot of issues still on the outside cool okay um we will circle back to altair after the client updates uh so i'm sure we'll have another touch point for that so then uh yeah would anyone like to kick us off let's see i think usually we have a randomized list so uh let's start with white house hello everyone um so we've been working a lot in our 1.5.0 release we published a blog post last week which details the features it will contain else our progress is coming along well uh 1.5.0 will have altered testnet support out of the box we're also working on testing some new upgrades to our networking stack there's been one last rare bug we've been hunting but luckily we managed to get a back trace on it in the in the last couple of hours so we'll be climbing through the function call so i'm tracing that one down so that's a good sign um you can expect to see a 1.5.0 release candidate in the next week or two and after we get 1.5.0 out we'll start working on the next release and that should contain weak subjectivity sync remote signer and some nice cpu savings looking at perhaps an order a 40 reduction uh on fraud or cpu usage so that's it for us i'm excited for the week subjectivity sync i was sinking the chain from scratch the other day and it took a while yeah i know it hurts i think us developers um on it are going to be the ones benefiting from it so much because we can just spin up nodes quickly right great yeah looking forward uh let's see let's go to nimbus next hi uh can you hear me yeah yeah perfect so in the past two weeks well we had a couple of people at ecc uh besides that on the dev front we did a lot of updates to uh to have the proper working uh vadata client and all the rest api and of course altai work so that current test net goes well and i would like us to mention that we are starting to work on wix objectives inc as well great very exciting next let's do prism hey guys terence here so we released version 1.4.2 last week and uh it has the awesome uh doppleganger feature feature so encourage people to try out and they also most importantly contains updates for the london hall fort so don't forget to update it before next week and then other than that most of our resources are on a tear optimizations we have been doing lots of work on internally refactored rpc endpoints under one place and aside from a tear we're mostly just bought fixes with the e2 api and then and then the slasher and yeah and yep that's it thank you great and terence are the e2 api updates are those in the release yet yeah those are yep those are in the release and then we encourage people to try out and a lot of people have been trying out and then and then opening issues so that's awesome great yeah exciting to see okay how about lodestar hey everyone so i'm a bit excited to share that finally we have two validators running on mainnet and they are doing just fine almost 95 96 of total possible rewards we're getting so super excited to join the club we on the side we have our like iron prototype functional and hope to deploy to a proper domain soon uh kaiman demoed last night at toronto diamond went super well uh on that line we'll continue doing research on other styles because this one is rest based so excited to try other strategies besides that we added support for the e1 fallback functionality and we are working hard on lowering memory consumption thank you proto for the help on that regards that's it thank you yeah very exciting so you guys have a validator client now so we uh have another one to add and that's great for client diversity so it's very good to see the progress on that definitely and next we'll do tekku yeah hi um so we put out our 21.7.0 release uh this week um it's got mostly just a few bug fixes couple of things we've mentioned before that now actually in the release uh the main one is a file handle leak um jpm led p2p bit of a corner case there that slowed the file handles so that's cleaned up uh coming up so still in the in in the development branch um is a whole bunch of changes to discovery as well we've done a lot of work there to be more standards compliant and i have more nodes in the node table and kind of do it all all nicely that's looking pretty good um and starting to investigate improvements around uh how we store historical state so we can create that faster plus a whole bunch of little cleanups and getting ready um alto y is probably the only thing is that we now support the contribution and proof event on the on the events endpoint so you can track that gossip as it comes in as well i think that's us great let's see and then yeah soleus did you have anything you wanted to add uh grand dyna right yeah so solas from the team so we worked on various small fixes and optimizations and probably the biggest one was the improvement of of our attestation packing algorithm so and the another major thing is that we proceeded with this experiment that i talked last time we will try to uh to run multiple uh forks at the same time and it's taking a bit longer than we expected but hopefully we'll have some results in in a couple of weeks of running clients uh but otherwise i think we just will need another two weeks but basically i would say it's a major thing and if somebody will try to experiment with something like this then it's probably much easier uh to to take just an existing find that does a forking in a regular a hard in a regular way and just run this client in in two modes uh basically so so you would have two separate clients instead of one client running running the two hard parts so so far that's that's probably all from us great thank you and let's see was there anyone else i think i got everyone i keep adding more clients okay uh then in that case uh we can move to talking about altair so there's a devnet this morning and uh seems like things went pretty well but there's still some places for improvement it sounds like um in the meantime on the spec side we've had uh one release kind of two releases in the last couple weeks so things to improve both testing and then also improving the aggregation count with sync aggregators and then also tightening the gossip validations in this most previous release beta 2 that one i think was supposed to be in the devnet this morning but maybe it didn't quite make it out but either way these will uh these should help harden the sync committee duties on the network and uh yeah lead to lead to better better chain um there's and yeah like i said lots of testing uh with most of both those spec releases so please clients uh take a look at that if you haven't already uh so yeah next we can move to planning and like paul kind of said earlier perhaps uh you know we moved to a more asynchronous thing here but yeah does anyone have any any thoughts there um i think we wanted to see how devnet 2 went and it sounds like we want a devnet three so that might push back uh i'll tear itself but uh you know that's something we all need to decide i'm i'm open to an altar three next week if um if perry's up for it yeah that sounds good to me as well but does this mean we decide today when we want to do a vermont altair work and then decide to abort it if next week goes badly or do we just take a call in two weeks we could probably talk more asynchronously i don't really expect devnet 3 to go poorly uh but i guess we'll have to see how it goes yeah i mean we're consistently seeing the transition work well the piece we're not seeing is the perfect inclusion rates on on sync committee signatures um i i think i'd be tempted to to push it out to piermont at this point and get that feedback given that we want to kill pim on after this anyway so if we really decide we've got to make massive changes it's not the end of the world but it just gives us a somewhat more realistic use case to see you know how inclusion goes on some committees and so on i support that as well that's probably pretty good i wouldn't mind um yeah getting rid of pmont as well we might as well do that to it something to consider if we do it with pmont is that we have to get we're getting users around it now so we have to make sure it's all included in releases and things like that um just something for everyone to consider and i hope that i will be able to use the next few days to kind of run out these issues you're seeing that would be great we should definitely keep an eye on the seat committee aggregation like adrian mentioned and yeah i mean generally i think the progress is going well so uh we'll just keep pushing forward yeah i mean in terms of in terms of the fall for pyrmont i think it needs to be probably at least a couple of weeks out anyway because we need to get that the config for pm updated in each client and a release so everyone has to get a release out and then we've got to convince users to upgrade or it'll just go into non-finality and kind of cause chaos just because people didn't upgrade more than because there's a problem with the fork um so we want to do a fair bit of lead time i'd say was there a tentative um date for forking fairmont already no i think we're gonna try and decide that on this call i mean um john what johnston i have for me is a month um three weeks or three or four weeks yeah i think the minimum would be two three is probably better yeah i think i think two weeks worth it forwards works with us since we still have to uh merge all the hardware changes into into into our mastery range so that that was a vote for four weeks was it prison i will say terence you do have a name yes no no it's uh i would say between three to four weeks yeah so three is fine too okay i mean sounds like there's rough consensus for three um you know obviously if something comes up we can reevaluate but uh yeah i mean the sooner we move to pier mod the sooner we get to mainnet so yeah totally if it's if it's useful i don't mind um like if we want to spin up another devnet next week i'm i don't mind doing that it's fairly low um input on my end um maybe i just won't stay up for it but we could we could spin one up if that's going to be useful to anyone for having problems i'm happy to do that so right and that may be helpful but uh yeah it does seem like the part is going well so then maybe we can just keep the devnet 2 running for these various uh you know debugging issues yeah sure i guess if anyone would like very strongly prefer devnet three then uh you know let's chat but um i guess we'll just see how if there's demand okay so it sounds like maybe devnet three maybe we don't need it uh i guess we'll look more at that two from this morning and have a better idea and we can uh discuss that asynchronously and then it sounds like there's rough consensus around uh pyramid four can say three weeks uh once we've gotten some more debugging updates and and releases into clients and then that push to users so everyone's aware and then we can do that nice one i'm gonna be proud great okay um let's see from here i'll move on to other different types of updates was there anything with altair anyone wanted to raise before we move on okay in that case uh let's move on to research updates or updates with the spec generally does anyone have anything to add here [Music] okay sounds like no in which case we'll move on to our next topic the merge updates does anyone have anything to present here um okay i'm not to call you up but maybe if you have something to uh to update there yeah i can give like a short update on that um at first eap 3675 has been merged recently uh thanks a lot for ap editors to give it a green light um uh it's in a draft status anyway so it will be definitely updated further and more clarification will be added on demand there is already a follow-up discussion in the pr thread regarding some points so but anyway it's already um should be considered by client developers as the thing uh that will be implemented and uh it would be great they starting to take a look in order to facilitate uh further development of the spec also on the beacon chain side uh the you can chain spec the merge stack has been rebased to alter many thanks to proto who did this job i've also opened a pull request with our basin this this back to london it actually adds the base fifa gas a field to the execution payload and adds a couple of uh verification rules to the gas limit and to the base fee so it's open now i guess yeah it's pretty straightforward i guess it can be merged uh relatively soon also there is an opened vr uh for the p2p interface for the nurse pack as well [Music] so that's that's solved on the next side promo for myself cool thank you yeah it's very exciting to see all the eips and the continued progress on the beacon chain spec and you know that'll sounds like that'll be the thing we focus on after up here so good that we're getting it all ready okay uh we can move to general spec discussion anything else anyone wants to bring up is there anything uh anyone would like to discuss just regarding the forking altair um it might be handy to have like maybe estetica could be involved in this or something but it might be handy to have just a resource um that's a table of all the clients and which version you need to be on for the altair fork uh this is for piano that is and whether or not that version has been released or yet or not yet i'm kind of like a canonical source of info um i don't know if there's anyone from ethnic or on the call or anyone who's interested in doing something like that i was thinking it might be good to start to get the word out asap that you know you're gonna have to upgrade your client because we're gonna fork out there um and we're gonna pimp without air and and this is where you should look for updates we are planning a blog post about that for prism but i do think it may be beneficial if something comes from if staker or or or like ef for a more general blog post yeah the more channels the better cool yeah we'll blog post it as well we'll make lots of noise about it on our own yeah definitely a great idea uh something we should definitely do and yeah and the more channels the better [Music] and i have a quick question to acquire the boomers about this week's subjectivity sync what is like the rough targets in terms of date for releasing this feature is it like altair or near near south i think taku already has wicked subjectivity um for us probably before altair i would say maybe in the coming months or so not sure about anyone else uh for prison you'll be after a tear probably i would say a month after a terrish yeah [Music] lots of already have it implemented since a month ago we've also have some progress on this and we plan to finish it within the next one we probably also will have uh in a month or or so uh defined is general radius as uh as the tolerance loads the state from from the anchor state but i would like to trust the other teams what what were the main things that you found in the this week's objective implementation as as far as i know uh you need you need the back syncing of the old blocks uh before the before the state that you load and is there is there anything else that needs to be done during this this be subjective to seeing her uh one of the surprise things is you need to check the signatures when you're doing the back syncing of blocks because they're not included in the hash but otherwise i think it was fairly straightforward i mean you know as much as anything ever is but nothing nothing surprising it's just being able to start from the state and go forward from there and do you do like a sinking in in reverse basically uh do do you use some mechanism which actually verifies that you end up in a in a state that you just loaded yes so we we work backwards but we work backwards in batches so we request i don't know what the actual number is but say 100 blocks at a time um kind of from the state we started with 100 blocks back forward and we checked that matches and we get kind of keep walking backwards uh it's it's a little optimistic and that we can get a few batches from different gears at the same time and then check our lineup and that kind of stuff but but ultimately it lets you not download too many blocks from the wrong branch before you discover that it doesn't actually line up with the state you've got and at the end check that you are at the genesis that you expect to be no we treat the state we started as as definitive because you can put anything you like in the box ultimately um the only the only reference point you've actually got is the hash in the state you started with okay like you you have to check signatures but if you as long as you own one validator basically you can get something that lines up back with to the genesis block because you just sign a block that that has the parent hash of genesis and it'll look completely valid all the hashes line up okay but theoretically i believe that [Music] it would be possible to to make a a different chain which uh let's assume you got a wrong snapshot from from an attacker and you uh you probably would be able to end up with a different genesis not the the the main one or the community one i do theoretically possible all right it is possible that the attacker would be sloppy and make it obvious that they've led you astray but more likely they would just line it up to the genesis so the check doesn't give you any extra security ah okay okay okay okay interesting [Music] i think the the solution would be maybe to to have some checkpoints [Music] snapshots and yeah as long as you as these checkpoints are burned into the client and we assume that the clients are uh are not adversaries and then probably that would work don't you think so kind of the same thing um so if if the checkpoint you have is within the week subjectivity period then yes you could verify fully from there that you ultimately want the state from there so you can actually verify the block transitions board but the the checkpoint state you're starting from is the checkpoint like it's it is the one known state that you're being told this is on the chain you can't easily trust stuff before that um because it you might have had bad ladies that have exited and withdrawn all their funds and then sign a completely valid looking chain so there's there's a number of heuristics you can do to start detecting that and so on but ultimately your key thing is that you want to start from a state that's known to be valid within the week subjectivity period and you can do that either with a state or with a root hash and where you get those from is kind of the big question in all of this um but but it is that it's the checkpoint you're starting from that's that's what's giving you security and checking back from there is kind of less useful because all your transitions are from the state you started from anyway and if if you try to sing from the genesis i mean the other way around not the backwards but the forward i'm just thinking is there any benefit in terms of security here so then you can be led astray by validators that are exited because because of the weak subjectivity i mean some not enough validators have exited yet but theoretically it could have happened by now i think and certainly at some point in the future it will become a possible attack um that that you can have a chain made up of signatures where you have nothing that's slashable um which makes two completely valid chains one of them is the canonical chain because we it happened in real time and one of them came along afterwards um unless someone tells you which is the canonical chain or you start applying heuristics like i can find more nodes on this channel yeah change yeah i think it's uh i understood this i remember this discussion some time before uh yeah look at this okay okay so so basically you just think backwards and and that's all in terms of uh checking the uh and signature controller yeah and the rest of things is just details so making sure that your client is able to handle rest api requests from before you have any states um so there's a whole bunch of rest apis that you can't answer because you don't have a state for turkey that was natural because we have a mode that will prune anything any finalized states anyway to save this space is there any calls that that would affect the gossip sub score the operation like in terms of tracking the head of the chain and performing validated duties and participating in in network you don't need any states prior to the latest finalized um you do need to backfill those blocks at the moment um hopefully once all clients support checkpoint sync then we can not necessarily download all the blocks but there's then questions around who is storing them are they going to be lost forever kind of thing and so there's some other problems to solve there okay so so to summarize there is no much magic there just basically we loaded the statement and seeing the blocks backwards and that's all pretty much yep correct okay thanks um is there anywhere a detailed description of the algorithm of this thing like starting from getting the checkpoints going through the state downloading and so forth another thing written [Music] nothing written down but uh yeah basically just start from the state and then uh work your way backwards but it is very important i would say to backfill and it you know it's i think even kind of on us to like say that we have the norm that you should backfill because then like adrian was kind of into that you might have this huge problem where suddenly no one has the blocks and i don't think we want to get to that state yeah i mean in terms of how it all works the whole spec is is designed to be able to take a state and a block and you can always apply it so it's kind of nice that there's no real reason to start from genesis in terms of what you have in your client you just don't need it um but yeah absolutely please do back for blocks don't make it optional don't even provide a flag to not do it just just do it it'll be good for the network at the moment yeah that's our approach as well but i mean long term it would be nice if people could run like validators without or generally for notes without having all the history always present yeah absolutely there's a there's a chicken and egg problem that's been going on for a while here in that we didn't support checkpoint sync in a lot of clients because there's nowhere to get checkpoints states from um and it was a real pain to start with now that infuria is providing it it's kind of centralized which isn't it's an ideal we'd like more than just them but at least it's a starting point so small clients start supporting it it becomes more viable for everyone to do it hopefully more places to get it from hopefully then we start to address this problem of where we store old blocks but so that not every client has to have it i can kind of just keep working this problem until we are we are able to just store the very latest stuff in each running node and have reliable ways of getting older stuff yeah once you wonder why do you need to verify the blocks and block signatures when you're backfilling the block hash that's included in so the parent root of each block is actually the hash tree root of the beacon block not the signed beacon block so the signature isn't included in it so most likely you're going to get the right signature and it's not going to be an issue but it's possible that i can give you the right block with the wrong signature via rbc i guess if you valid well as long as you validate it there that's fine but you've got to validate it somewhere along the line there to make sure that the signature is actually the one that matches that block otherwise you will store the wrong wrong signature and then potentially serve those wrong blocks all those wrong signatures to all other other nodes when they request them from yeah so basically the block signs the signature yasik had a proposal to add an extra field to the beacon state to include the the block signature as well in there so you could just go backwards that by referring signatures but it didn't make it into altair but maybe we'll include it one day i think it's probably still open on the fx repo if anyone's interested as a pair and you would also need to recreate some states to verify those signatures right uh no you can do it without creating the states in fact there's no way to create older states when you start from before the checkpoint you start with you can't run the process backwards basically but it's it's just verified with the validators public key which you can get from the current state because we never lose them oh i get it so you can't verify that the proposal was due to propose that block that the proposal index is in the hash so if you're following the hashes back then you've already verified that is right yeah yeah thank you for thanks a lot for our clarification regarding the history i'm just wondering will there be a a big demand for a history of uh beacon chain after the marriage before the marriage point uh maybe somebody was discussing about that because it looks like after the emerge there there won't be i don't know maybe the stakers will like to see their past performance but otherwise as uh as this uh history of beacon chain until the match point doesn't have an executioner history or data don't you think that maybe after the merger clients will not sink the state before the match and maybe this will be a common behavior was there such a discussion [Music] i don't know if i've heard something like that i would kind of suggest to keep the full state and you know our history i should say and as more you know as most as possible i think we should have the norm that we have the full history um some of these things we've been discussing around like you know these longer term projects around serving historical state are super important i'd say they're like parallel streams of work um but yeah until then you can store everything they can and yeah maybe down the line there's different sync modes or pruning modes that uh you know drop state before the merge but uh we're not there yet i think in general if no client includes an option to prune old blocks then most people will just use what's available if clients start including options to promote blocks then i think you will see a lot of people using that option yeah absolutely that's and that's what we've seen on the e1 side yes downloads stores all blocks by default so most people have them available yeah i think this this question came to me because i was thinking that for users it may be a bit hard to uh you know to use the let's say api of of past blocks for instance where you may have we have a past block of warching which is after a while there will be a block that has a same lot numbers on both chain basically uh on both chains so there will be a block number [Music] there is a block number of number thousand uh one thousand it exists both on on chain and uh on beacon chain and from user perspective well there will be some maybe some confusion on which which blocker is number 1000 we [Music] we could just say like just from a social consensus standpoint that all beacon blocks are plus 100 million or something just to make sure we don't have collisions on the numbers for ux purposes it is an interesting question because mainnet is five million blocks or so ahead of where the beacon chain will be so when the merge happens the head block number will drop backwards by a million or by a few million yeah outside of consensus blocks we still have the execution blocks counting up from five 10 million or whatever they're at forever and so they'll always be conflicting [Music] yes i think i think it is something that we just need to be clear in the rest apis of how you're referring to things or in the json rpc rather um i don't know how much work has been done on this today it hadn't occurred to me until now so i might just be a bit slow yeah and i'm just going to add it's almost a bit of an api issue um but yeah i mean the more i think about it the more i do see the conflict so one thing we could say is like hey this is a slot number on the beacon chain and then we can keep the block numbers as they are on the execution chain um but yeah that is a good point yeah we're also gonna have shard blocks as well i guess people just have to get used to being specific about what type of block they're talking about and reload blocks it'll just we'll just keep adding more blocks of all block numbers have a prefix basically which indicates where they're from we keep a list somewhere of you know prefix uh one billion is execution client and free or prefix zero is executing client prefix one is client prefix two is shard n and then these prefixes just you know are a billion plus whatever the actual block number is so that way when you're seeing a block number it's always a big number but it always starts with kind of a hint as to what kind of block number it is [Music] i think the prefixes or some magic with numbers may affect the current execution layer i believe there are some contracts that are using what numbers or maybe indirectly are using that but the only one way that just came to my head and i don't know this is not nice but maybe it will contribute to the uh to the discussion maybe we could during the match we just roll uh the beacon chain block number slot number to to the future which is aligned to the last proof work block and i believe that maybe in future we actually we will just forget the uh the beacon chain uh for the uh match uh because i personally don't see much more for uh for users of this uh history then we would have a liner block numbers uh basically so so just to repeat during the match we just draw a slot number uh to the future uh which is uh like next number after the proof of work the last proof of work block so this makes a line error a very nice numbering [Music] just an idea maybe it's not the best but yeah let's let's discuss maybe after this call all right slots as it mentioned in my photo skip slots will get this thing to diverge anyway [Music] like the robust quad with no blocks in it and block execution block numbers will be behind this behind the slot number eventually note that stop numbers are much more like timestamps than block heights yeah unless we change the logic in in the clients yeah but i think of course this would add extra complexity but otherwise i think it would be possible [Music] of course with complexity consequences to to just handle this role [Music] in the code which problem are we trying to solve the height is already embedded in the beacon block and if there's an index in the client the map slots to block heights everything just works fine uh so i don't think there's a code problem i think this is just from a user standpoint users are going to end up incredibly confused when you have you know block number five slash seven like what is that like for for users would be nice if there's an easy way when they're communicating with each other and when websites present data to them there's an easy way to identify oh this is a consensus block or oh this is an execution block [Music] right prefix to the hash might be kind of like michael was suggesting yeah i'm in post either you're either talking slots which contain you know so that's that's how we number the consensus blocks um or you're talking height of execution blocks um uh i mean the the place that this hits it probably hurts you know block explorers and things like that a bit but the biggest issue is going to be around the json rpc client which is is where execution clients so yeah but the execution clients are really exposing this stuff and they have the backwards compatibility concerns from a beacon node perspective we're always going to talk in slots we'll probably have some apis that let you query by execution height but it potentially maps to multiple beacon blocks um but all the all the challenges in backwards compatibility and making this understandable to users is really going to be the execution clients so i wonder if if this is something to bring up tomorrow on core devs more than here because they've got the context and the actual ability to do something about it just so we were prepared for that call is it's terribly unreasonable or reasonable to at some point before the merge or on the merge to just move the block number forward by a very very large number is that going to be really hard or is that easy personally i would say that would be right when i said consensus uh site number yeah so slot number so the the advantage right now is that you can take a time and calculate the slot and it just works you you need to know the genesis time um but it's a simple division uh if you change it you've got a simple division prior to this number and then a bunch of plots that don't exist at all it's weird and then a simple division okay from a different genesis route so it kind of at some point we maybe wind up doing that if we ever change the slot time uh but if we can put it off as long as possible it'd be really nice okay yeah i would also say that skipping forward the slots is is going to be really complicated the spec the f2 spec relies a lot on the idea of the current epoch and the previous epoch epoch being 32 slots um and to have gaps in that is going to be super edge casey i can just imagine heaps of clients all over the place finding bugs in that you know every time you subtract one from the slot um now you need to go and make sure you need to stop subtract one or five million or something so i'd say that's a bit bit complicated in my opinion it gets worse the whole fellow data registry has references to slots multiple prevalent data for their lifecycle data [Music] and so if a federator tries to exit they certainly get into some very weird states so i'm hearing very hard yeah i think that's right maybe we can have a two numbers actually the one is like a classical execution layer eight or something and another one is a consensus slot this maybe would not basically this would not break anything on each end as it doesn't interfere with each other what do you think so you're saying just when you expose the slot number to the rest of the world you just like you know add 5 million to it but for internal communication you're using the real slot number no i i would say maybe we keep as a as a public number we keep the execution layer number which is the current 8 but internally we have these slot numbers which we just we may show it somewhere in explorers or or something like that but the actual block numbers uh would be uh just as as it is now in there will not the appropriate gaps any uh i mean for the for the execution layer there will not be any gaps it will just proceed but at some point during the merger uh there will be a two numbers uh one number will be executional error uh execution a lower number and another one will be associated will be pr every time and another number is a slot number of uh consensus so the execution [Music] client execution payload will still have the the incrementing block number um the execution environment will still execute so that that separation still exists you've still got slot and execution block number that just flows through it's just about avoiding confusion of which one you're specifying um which i think really just comes down to which api you're talking to if you're talking to the execution client then you're talking execution block numbers if you're talking to the beacon node you're talking in slots uh yeah but in as yeah go ahead as the apis evolve we may get into points where that becomes more confusing but then we can kind of design the apis to take either or and specify which type it is and that kind of thing yeah for users i i believe that the apollo should see one number as a main number uh and it would be great as uh that it is uh just a continuation of execution layer numbers i think this is an interesting topic overall yeah i don't think we'll get to one number because slot and height are always going to be two different numbers they just don't increment at the same speed um today in the in the consensus chain we don't really track height at all we just use slot but it becomes more important the execution thing um i i suspect we might have covered this as much as we possibly can given where the beacon node side of this um there's like as i said there's if there's going to be confusion and problems it's going to come up with the json rpc apis um so i wonder if we if we need to spend more time on this here or if we just shelve it and see what what the execution guys want yeah we can move on i mean it kind of sounds like uh just having a pair of these numbers and just being clear about sort of the types of what you're referring to is uh the simplest path forward and we can leave it open for uh you know experimentation with other options so on that note uh does anyone else have anything else um yeah i want to mention um i have been talking about crowder and dashboard three times before and i wanted to share it with you today mostly we show information about the geographical distribution of the nodes and also the different client distribution uh which is not um what we might expect uh i mean it could be better in terms of software distribution um we have a couple of other things that you can see in the dashboard um and so also want to mention that um the press release for the standardization of the metrics uh has been merged uh thanks paris for that and so i would like to ask the different clients implementers to please do the few changes that are necessary so that we have metrics in standard metrics uh across our clients in a few couple of weeks if possible and yeah i think that would be all thank you great thank you it's very exciting to see this dashboard [Music] thanks okay anything else from anyone otherwise we could go ahead and uh called early today um there's one thing i realized that when i look at the mainnet validated con is that it's slowly creeping up to be to be the same as the printer number so um we don't have to make a decision um but i do think that we should increase the validated account on the prayer side whether that's post a terror or before a tear but we don't have to make a decision today but i just want to notify people that i agree with that sentiment yeah thanks for bringing it up terence it's uh definitely important to keep an eye on just that we probably don't want to fork pyramid and procter at the same time but uh we can probably get to potter you know after pure okay any final things otherwise we will wrap it up okay sounds like no so thanks for joining everyone uh again very very excited to see all the progress in all tier and uh we will keep pushing on that and uh yeah i think that'll be it thanks everyone thank you thank you thank you thanks for being on thanks