All Core Devs - Consensus #52

Transcript

[Music] for [Music]

[Music] [Music]

[Music] [Music] okay uh to the 50c call does that mean it's been two years it's it yes because we missed a couple along the way so it's definitely been two years okay um all right cool so here is

the crazy on the agenda today um we will start with testing and release updates you saw the V10 release um I think it's pretty much the same as the candidate release other than some additional testing and things uh as I mentioned last time uh Shia uh and myself and Proto a bit um are looking to like revamp the way the test vectors are output um which will be some changes on your end on how you induct them in but will uh greatly reduce test generation time and reduce the disc footprint which will allow us to greatly hopefully extend the amount of test vectors um you know

throwing more random things and lots more operations and that kind of stuff so that's in the works um it's probably not a huge priority to ship that in the next few weeks uh but next four or 6 weeks probably get that out um maybe maybe we'll wait and get main that out first and then change test vectors under your feet um cool any other testing updates yeah quick beon beon fuz update that's okay yep

um cool so over the last few weeks um we've been running our structural differential fza and um we found two consensus related vulnerabilities on on prism the first one um was an off by one bug in the committee index validation of the uh attestation processing and the second one was um basically using the wrong Epoch uh when validating slashings for POS slashings um these are all fixed now that's what we can I guess talk about um there was also one minor non- exploitable spec Divergence for teu uh in the proposed uh slashing processing so that was uh found on prism a few weeks ago we uh started working uh with

a future eum foundation team member uh we joining the devops team there to uh essentially automate our deployment and monitoring um of of those fuzzers scale on our AWS infrastructure he's built a bunch of uh pretty handy anable scripts are pretty much ready um and he should get that done actually today or tomorrow in continuing the work on the custom fuz fuzzing engine sorry um it's it's working but we only the mutation based version working actually uh structured inputs so uh The Next Step next thing we're working on now is adding that structural um part of um for for that custom fer um I'll be writing this up in a blog post um hopefully uh push that out over the next couple of days but

that's pretty much it any questions for Edie I mean on that note there's actually going to be two people who are going to be joining def Foundation very soon to help with security and I guess we're still looking for talent and you know people interested so anyone's listening and knows any you talented hacker please um send an email to E2 security at e.org yeah additionally I think we're going to put out a few rfps um first to try to find some more external teams to help with testing um of various things some Network testing load testing in chaos

testing that kind of stuff uh so if you're keen on that kind of stuff keep your eyes peeled for those rfps great um we're going to move any other testing discussion very cool uh moving on to um all of yall are very aware uh Proto's been driving getting some V10 test nuts up toled is up and and I believe there was an Epoch with 100% attestation and participation which is pretty cool um and that's looking stable I know there were a few things to work through I know um but all well there um and then there was some

conversation past 36 hours about what to do with a larger scale test net uh Proto has prepared a track with 100,000 validators and keys um and I believe the intention is to share those uh amongst the client teams and the EF uh to kick that off off deally next week so we can get this going firmly before main that launch um and I woke up and there was a lot of conversation around what that actually means what uh Pont Pont is that how you say that can an Australian correct me correct y Pont um what the fate of Pont be uh it seems like we will kind of kick

it off ourselves then open it up uh make the config and stuff available uh for others to join um so that people can test one configurations and stuff um and to have that at least and then Circle back on the conversation after Genesis to think about what a sustainable test net in the long run will like you know should we up the ejection balance um should we change the Q limits and stuff and that config uh for the sustainability and kind of user experience around that um that said um I believe in the conversation that I caught up with this morning we hadn't picked um when we're actually kick this off so the the

deposit contract's there we just need to set the config which uh we can kind of tune the Genesis time uh however we want at this point um Proto what are your thoughts I know there's some ends up being on your end I know there's this configuration work uh for clients and getting various nodes up um is this something that we are looking at to do Tuesday looking to do Wednesday Thursday of next week so the original ID was to launch on Tuesday um this is a well go and with too I think we have better idea like what the efforts are are involved with getting another test open running so I'd like just get some feedback from uh

clients if they confirm um if they can confirm Tuesday uh or alternatively move it uh forward a few days I think Tuesday is fine on our end a couple of days wouldn't hurt though but we could do Tuesday for our pris as well yeah good with Tuesday uh for Te say no to in a couple more days so is good I'm hearing Tuesday although a couple days look better I think we can

just do Wednesday just as well so maybe should just go for Wednesday yeah that seems reasonable a little less weekend work exactly okay let's go for Wednesday I'll set the configuration uh assume we can do the same Genesis time noon UTC works for me yeah cool um so if this is going to be a utility to uh validators over the next handful of weeks maybe state in your Discord to not be overzealous on the amount of Gorly

eth they dump into this thing because uh one whale could block up the EQ at the current limits um and so maybe encourage validators to to try one or two um obviously that's not in our control uh but hopefully it can be somewhat of utility to validators and the P okay any anything else on this before we move on uh so about the uh the best will be running for at least a few more days wanted to give a shout out to the beacon CH Explorer will help us get more insight into this so it that is performing relatively well if I can say so

myself um and going like in the last few days I wanted to test like some miscellaneous things like the new light slasher and these kind of things where now that we have enough that we control and that we good good Insight in andal things really well yeah great um and as for madasha well for Pont um we will get a a launch pad up at a subdomain so that people can practice using that um and for madasha I'm based off of my read I think we're going to at least publicly Sunset

support for it next week um I think that there maybe there's some will keep running nodes to test non-f finality and some edge cases and stuff but uh I think publicly will kind of stay fully degrade starting you know over the next few weeks um anyone opposed to publicly sunsetting and and stopping active support okay all right padasha so one thing to keep in mind actually by is um people I think validators may maybe do wants to have some kind of environment where they can test their setup before

they actually uh spin spend one up live so if that's not madasha then what would we direct people to so Pont uh Pont we're going to kick that on validators that we control and uh next week also open it up uh for deposits and we'd be committing to run for some longer period of just yes at least through uh main net Genesis after which a couple weeks have a conversation about what we might do to make a test net more sustainable and user friendly in the long term no that makes sense great um and I guess for that's in the

activation queue currently and is close uh can keep running their nodes and they will be activated um because of the way the que works so great maybe for the new test net we could make the cues faster so that people can get in more quickly and test their setups yeah I'm not terribly opposed um I know some are hesitant to change configuration uh if this is one of you know one of the reasons is to test just test main net configuration anybody have any thoughts on that I'd prefer really plain main net parameters just to make sure that we're

testing the right thing especially during launch let me do whatever yeah again I'm going to encourage the community um you know try a validator or two not I'd also lean towards having the main net conf for now I think it's helpful understanding if the the times that they can expect to run like the the wait times and stuff they're expect on Main net right we could also ask people to exit voluntarily as well too that would help as well if people exit cleanly instead

of just shutting off their nodes yeah I agreed I'll put that in Zen in as well okay anything else on test Nets before we move on to client updates so one thing we working on some like shorter lift does not or just focus on Genesis so we have a configuration file ready to go into a client do genesis then repeat it over and over again ideally so I think like this is an

effort we can run in par of like this thing where we do want to repeat Genesis more often and to enable us to like configure the client without changing the internals right so like that looks like dash dash data dur and things in Lighthouse a very specific uh testnet configuration um what do what do you do one very shortlived Genesis uh every week until Genesis what what's the goal here the intent something like that sandscript like for now right now we'll just focus on the pure moment Genesis

that's big enough and soon enough as it is yeah but then after that it does help to repeat Genesis more often yeah and I guess specifically we we've seen time and time again that the Genesis uh can be brittle um and we we've seen kind of minor issues pop up in a lot of our our test Nets so that's the that's the motivation right there but I mean sure testing Genesis is good but there's no actual expectation that will launch main net without a bit in main net in time and I think everybody's baking in stat and expecting people to run with this

baked in state yeah you know on on 1.0 day MH but we've also seen other issues um I guess often I guess that following eth One issues uh State mismatch match issues boot note issues those um like and just being able to find peers I I mean maybe we don't have to do it every week until Genesis but I would want to get another couple in um if possible yeah but that might be something signal clearly like one or two more

well I don't know I don't know when Genesis is but I think it's super important that we're clear in the in signaling to people that they do need to update on this SP on on the week that that main it will happen right I agree uh that if you're validating in Genesis you should expect to be uh updating your software in that time and and being pretty active during the time uh and I will the S Sigma prim's Communications on that and the recent blog I think really good and if you want to communicate to your users in a similar way I think that' be really valuable yeah also just to remind everyone I think I like posted this in everyone's uh issue is like have some way of quickly updating all your users

that they need to um install something like so that even if it happens one hour before Genesis and you want to push something then you get all the sters and not just yeah leave it to chance right so I think everyone should have like an email list for critical issues very much agreed okay let's move on to client updates starting with Nimbus hi um so uh it was uh very buzzing the last two weeks uh starting with

networking uh we have improved again uh the tracking of resources uh so um in the past it was uh Futures and memory now we are uh tracking streams and channels we are also um uh we have fixed some uh Gossip sub audit issues uh This was done late one was not tested enough um three weeks ago uh when it was uh time for it to be audited so we tested a bit uh later uh on the core part um what we had a Toledo release we are using gosip 1.1 now on it uh a lot of documentation

changes uh regarding infra uh some users mention that um uh they didn't like being forced using websocket gtps support we have also significantly improve uh if one uh chain uh sync and monitoring and we uh pre-released 0.6 two days ago uh with a pril Linux binaries and we are planning to do a new release uh today as well and uh with that we are gradually moving away from make files and we will provide pre-compiled executable for all major platforms so right now it's Linux but we plan also for Windows Mac and arm builds we are also uh significantly um

reworking uh or uh release management uh for mainnet so we are creating sanity checklists we will create a mailing list something that one mentioned uh just a bit before uh some monitoring and the support coverage plan for team members and also we uh have Lessons Learned in uh when we did a directory rename uh for consistency or permission changes uh for security because uh those created TR uh troubles for users uh either they were holding databases or they were used in system d uh automated scripts and didn't work after uh changes that we made so we will improve uh how we deal with uh

those breaking changes uh also we used to have a way to create deposits and validator keys from nus now uh to avoid confusion and uh fight scam attempts uh this is now undocumented and developers only so uh there is really only one way to deposit and it would be a if EF um uh Launchpad and that's it for us got it thank you how about load star hello uh so we uh have not yet released

uh a new new release of floar we've been wanting basically trying to get to uh full spec 1.0 candidate uh compatibility and at this point we've uh got it down to everything but dis V 5.1 so that's really what we're focusing on this week we um uh finish with a rough draft of our blst integration of course it's a lot faster to use blst uh we may hold off on on that until we can address like the browser compatibility issue U because right now it only

works in nodejs um and we uh other things we've gotten about 80% of the standard API almost everything I guess but like the validator Status End points which I think are still possibly in in in in play um and our validators using the standard API so that's good great thank you let's do prism hey guys so in the last two weeks we have closed all the ongoing issues with our uh trail trail of bits audit

and the audit report should be online and the people can take a look we have made improvements to our initial syncing process we have made it better at the exploring Forks during periods of non-f finality we are currently working on conforming to the E2 standard apis and we are working on testing uh Pi growing as well and uh we're also working on the slasher interchange format and uh um the most important work for our our mainnet V1 releas and we are working on a set of issues that we want to close before November 24 and you can

track those in our Milestone um within the uh repo so yeah that's it thank you cool thank you Terrence Light House hello everyone Paul here um so last week or this week we published a blog post about our plans for a version release um as discussed earlier we're encouraging everyone to update in the week before Genesis to so that they can get uh the Genesis State they don't have to do the listening to F1 waiting for Genesis thing um so if you're going to be working if you're going to be using Lighthouse um from Genesis and I recommend reading that blog post on Sigma Prime was it lighthouse. Sigma

prime. um we're also working on the standard API um implementing it and providing feedback to the spec um our implementation is quite close and we're working on events now um the slasher is in the final review stage a release next week is lightly likely we're running eight of these slashes on Toledo um we're setting up a production staking and monitoring infrastructure uh our second Lighthouse Security review has been completed uh no criticals were found uh we're working to address the points raised um this week and before Genesis and we're feeling pretty confident for Genesis in a few weeks uh everyone's working hard to complete preis issues and PRS that's it from me great thanks

Paul and teu yeah hey uh so um we have published mayet ready release and we'll be making main the default uh in release candidate next week um we now have mostly complete implementation of the common API uh and we are going to decate Legacy API uh on the next release uh we have completed uh almost all spec uh released in to dat zero updates so the last one remaining is uh Gossip message ID is now ready to be merged uh and will be in the next release

hope um we had the feature to support us uh for snapshot sync from State alone and it's actually very effective and allows to get fully up and run in um in a couple of minutes or so um we've made significant improvements to memory consumption uh by utilizing the Proto array more widely and also we have a couple of serious issues uh fix it uh one is related to uh out of memory uh after long periods of non-f

finalization and another one is um um related to uh stability of death on E one main net and also uh there's a work around uh transaction size limitation in in for that's it from tile excellent thank you and I believe that is everyone for today great let's move on to research updates who wants to get us started small update about oops go

ahead okay I have a short one uh about weak subjectivity so Lighthouse prism teu and nus support um weak subjectivity sync starting from a block route uh um and we have one major block Explorer who's going to support um who's going to be an E2 weak subjectivity provider right from Genesis that's ether scan Beacon ch. is going to do it shortly after launch I'll be making a release for the week's objectivity server that everyone on this call is encouraged to run but uh overall it's it's a great job everyone uh E2 will have weak subjectivity security right from

Genesis thanks for getting that out the door did you yeah moving on so great I've so um on uh data availability sampling phase one um I uh wrote up a uh kind a pre-pack of two versions of data availability focused phase one one of which the uh basically assumes the beacon proposer is the bottleneck for all blocks and the other assume assumes That's The Shard proposers that have the primary responsibility uh so both of those uh and I think we're still in the process of and of

discussing them understanding what the trade-offs are uh understanding what the trade-offs of uh having kind of formal in protocol chaining of blocks versus not bothering with that uh and a bunch of other finer grains tra uh tradeoffs but generally moving forward and trying to get to a a concrete spec as soon um as soon as that makes sense um and then in addition there's still kind of small research questions to do with the availability sampling popping up like how to calculate these how to verify as proofs of uh proofs of a block size as efficiently as

possible and so forth and so just working through those two um another spec related thing that I've started to do is uh separated oh I did a of draft PR separating out the light client us back into or the uh basically into its own file so that it's of theoretically independent of phase one uh so the goal of this is to basically try to of modularize the phase zero thing so that we we don't we're not kind of hamstring into a particular order and we can just do things in whatever order they become ready in and

like clients are theoretically or the like client protocol changes are theoretically really simple so we should be able to do those very quickly so the pr exists yeah nice thank you um any other research updates yes txrx has a small update um we are working on the executable beon chain proposal um The Proposal is about ens enshrining E1 execution into Bon chain H and making it first class citizen with the respect to consensus um comparing to e one sh this

proposal uh significantly reduces the communication complexity between execution and data shards and it also opens an opportunity for advanced use cases like instant deposits and instant withdrawals and many other use cases that require synchronous ex synchronous process um document is almost ready and going to be published pretty soon uh on This research and uh yeah like since the next week so awesome thank you

m any other updates um Denny I have a couple of figures that I would like to show is that possible uh [Music] yeah all right can you see it yes okay good um so we did a a short experiment with um with the clients uh all five of them and we were trying to see um how to behave uh and in terms of resources um and synchronization with the chain so the figure that you can see here um is basically uh the time is in the x-axis

uh so we run all the clients for um one to two days sometimes even more almost three days uh depending on sometimes they crash and you have basically here the y-axis is the the synchronization slot in thousands and so um well from from this figure we can see um for example that light houses and Prisma ones that kind of are bit faster uh to synchronize in comparison to the others lot start take several hours to actually start like four hours start actually sinking um process and there are a couple of flat moments for Lighthouse uh in hours 10 to 12 and hours and I will come back to this in the next figure the next

couple of figures we also analyze the number of peers uh that each client connect because these are reported in the locks and so you see here for the same five clients so using the same colors um the number of peers they are connected um te is the one that is usually connected to more Piers over 70 and um Lighthouse is yiy but there's a couple of hours where the the the number of connections drops uh for some time and again I we come back to this a little bit later there is something happen at this point I'm not really sure what it is uh but we start we're still investigating uh prism is super stable in terms of number of beers ni is always kind of around 30 um and then um well lotar and Inus also kind of or less

stable between 20 and 40 years between 20 and 30 for lot star um we analyze uh the disk usage for all the five clients so in this figure you have actually two y AIS uh so because we want to compare how the dis usage relates to synchronization with the chain um we see that te has a kind of interesting behavior in kind of a zigzag in which the uh it goes up and then it goes down dramatically and this is repeated periodically so we believe there is some kind of cleaning process that happens in in Te client makes this pattern maybe the te guys can explain this

better um and then uh well nimus and prism have uh both quite low dis C uh but there is a weird thing that happens for there is a sharp rise in this qes after our I think number three and then uh it stabilized and then it drops again so I think at this kind of cleaning process that happened and then it came back uh and it was uh going steadily again until um our 19 or 20 where it it start to increase uh The discus sharply I don't know if this was um a nonf finalization um period or something related to this um but uh it arrived to the point where uh itated the whole dis of of this um 35 GB

um so it crashed at that point it could not sink anymore um and so the the flat becomes line I I have to precise that all the clients were running on on the same noes but they were running at different times so teu and Lighthouse were running together in two different noes in par prman Nimbus were running uh two days later in the same two nodes and then lot star uh two days later and then U CPU usage um we can see that um pris nimus and L star it's usually around 50% of CPU users and not with just one core but two threads so the reer threading it since this three not three clients are not kind of are not using hyper trading so they use probably just one trade it stays about

50% most of the time te and lighthouse on the other hand they do um have about 100% utilization of the CPU most of it except for the moments where uh the synchronization got becomes flat in the case of Lighthouse and then we see that uh the there is a clear uh kind of 0% usage of CPU at that time uh that also happens for uh prism at some point I think in hour 35 or something like this there was one hour in which the there was no synchronization so the sying line became flat and there was Zero CPU users for like 1 hour or so we also measured uh memory and so uh in this case we can see that teu and and um Prisma are the

ones that use more memory so they not had about 5 GB of memory uh we see some kind of periodic sharp uh decreases on prism as um yes on prism memory usage so I don't know if this is some kind of state cleaning or something that happens periodically inside the client but it's kind of periodically um in terms of um memory resources the one that is more light is nimus uh so it looks like this is a client that is really made for um you know light uh hardware and so it requires uh little memory usage and then uh in between we have and and L star again Lighthouse have this um like flat lines of memory when when when there is

the synchronization issues uh and this C start to increase we can see that also the memory start to increase until the L hour 24 when the C so become flat and then the memory and becomes kind of flat um we also analyzes uh network but I don't want to make this too long so I'm going to just stop here and we're going to publish report on all this so um if uh people from the C can um have some explanations for some of these things or or you think this is something inter come to reach us and maybe we can discuss so I'm going to post um in the chat uh a first draft of this report and uh I we will be happy to receive as much feedback as

possible that's it thank you uh can you say when you did um tests because uh I guess clients are changing a lot from weeks to weeks yes uh all all the tests were done uh pretty much last week um so I can I can uh from which time and which time uh from which time to which time each client was was running and we can also provide you the version of the client that we use um and any other details that that you need yeah we can post all that in the report I think it's not in the in the in the draft that I will uh post the link right now but uh we can we can add this into the report yes cool thanks Leo share a if you have

some stuff you want to get some input on uh share it before um and then we can just bring it up for questions rather than going over it all live okay uh but thanks um cool other research updates okay great networking um thank you for the feedback on the issue I opened up a couple weeks ago um we been kind of had my hands full with uh things uh but I have a a work in progress PR to update based off of that conversation

and I'll get that up for review today um that's with the kind of how to handle block sync and weak subjectivity in some cases there um any other networking items people want to discuss today just quick tested the scoring parameters that that have been suggested on Toledo um they seem to be early well so uh we're merging that down or have merged out down to master so if other people are looking for scoring parameters the ones we suggesting to suit the network great have you uh dropped an ad serial note up there to see what happens not yet um I kind of want some

uh some validators in there I talked to prto about that gotcha uh and you've been working on some you know uh modification of the client to make it evil is that work still in progress yeah uh that one I've kind of put on a hole because we're focusing on some main net things but I I should take that off by and get that back in there to see to test this SC yeah got you other networking items other networking items okay great um General spec

discussion um what do people think about the idea of kind of unbundling all the post zero items more and basically treating them as kind of separate components with no kind of necessary Assumption of sequential so the three I'm thinking of in particular would be one is charting the other the second is like lines and the third is the merge um I'm Pro especially because on the sharting and the merge stuff there's a lot of like so the exact timeline is unclear I think it'd be good to have

light client infrastructure beginning to be developed before anyway I think it's a very good idea wasn't the point though that you would want to have a light client infrastructure before the match so um you can basically continue just continuously have light Clan support for for each one yeah absolutely in terms of dependency support before the merge is definitely strongly preferred but I guess I'm not worrying about this because light client support is by far the easiest of the three items and so like I'm recommending we even sticking it stick it into the first Fork after Genesis like five months after or

whatever if we can right I mean from a from a consensus standpoint like client support is extremely minimal and reuses uh infrastructure that we have been using uh Gossip and committees essentially gossip and a committee um and so even even the complexities of supporting like clients uh then we can build on after but uh getting that support kind of native into the consensus is very easy so something that I makes sense to ship asap okay I mean you heard that you heard

that coin me about stability I've rej juggled the road map again does anyone actually listen to this call at this point do we still think that that phase two is is like has any will ever have like any meaningful um uh instantiation anymore or is that just basically something that that is just an outdated term at this point then it's probably an outdated term in that it implies that it will happen um but I personally think we have enough on our plate in terms of data availability

charting and merge uh to get done and kind of see how the rest of the ecosystem develop you know if in that me in the meantime uh the use of data availability for scaling and things is like a total unbelievable flop uh then that would be information to continue moving forward with a fbl phase 2 but in terms of R&D effort I think that it's definitely on ice right now y that makes a lot of sense to me cool anything else on just general spec and thank you Trenton I'm glad that you're listening Kevin

too but yeah any anything else great uh open discussion I think that probably a lot of yall saw that we uh the EF announced this like staking Community grants round I just want to plug that here um anything this is really to kind of enhance and start to support more actively things beyond the core infrastructure the the core client stuff uh so if you're listening and you're building stuff that makes the client the validation experience more delightful or you want to start building something in that domain uh check it out on the EF blog there's a form and you can it's not it's not on the blog but I will Vlog about it tomorrow uh there's a

a link but check it out I post it on Twitter um and client teams if you have some stuff uh that you would like to see and it's not on that wish list or you have some uh teams that you're friendly with uh that you want to get involved with this please share okay anything else before we close [Music] today I wanted to bring extra attention to the slashing database regeneration problem um that seems especially important for people taking on at at home and and on unreliable storage media

like SD cards on Raspberry Pi um does anyone have any insight as to tough this is to implement and what it might take to get this through so specifically this is um looking back at consensus and constructing the slashing database as best as you can from messages that actually got on chain correct correct this is for the condition where um you have backups for your validator keys and everything M but um the storage media you're using um for the machine that's running your validator client that fails and you lose your slashing database but you still have your keys so you can restart your validator and you would need to regenerate your slashing

database from onchain data right which gets you potentially in a good spot not guaranteed I this can be done independent of the clients now that we have this interchange format so maybe maybe we want to support um a script that uses the common can can do this independent and give you that format and then you can uh bring it into any client rather than asking all clients to implement it at this point asking for um opinions about how tough or easy this is and what path um is the best to go ahead if we're going to regenerate it from chain then we're only going to get when never going to get like things that we cast like like

say way in the future like a few hours in the future or whatever so we're only going to get things up to like the time now because they're the only things that exist on chain so perhaps instead of bothering with like going back through all the history and collecting everything we just use the slashing interchange format as like a like a low water mark we just say like you know from now or last Epoch just never produce another infestation again yeah that actually makes a lot of sense the so the format does have this like minimal format where you just say don't do anything before now uh that that stops you from joining a chain that's not finalizing potentially so that would be the only disadvantage of that and that might so I agree like most in most of the time that solves that

problem but there are times where you would want something more advanced and that's yeah yeah you're right so if justification is not advancing then you won't be able to produce anation yeah yeah that's a good [Music] point so it's never going to be perfect like fully agreed it could be that someone got at a stage on the never publish it and uh and then yeah right uh they just use it to slash you later but I mean that case is very rare I would guess and most of the time it's just like you innocently lost your storage for some reason yeah you could that's a good point you could also argue that if

there's a lot of there's not much finalization there's quite potentially a lot of forking so it's probably not super safe in that case but that's that's just a a guess I mean an ideal we can't we can't understand you there's a lot of wind right sorry it's windy we can an ideal implementation would would search uh M Pools and uh I don't know block explorers and stuff yeah um I suppose a block Explorer could provided as a service um I have a question related to that Paul you mentioned the like if you sign things far in the in the future and maybe had broadcasted them or something uh and

that's in particular an issue because you can create these surround conditions and that was something that Doner brought up on an eth research post um and a small note in the validator guide made it into the recent release on essentially a validator should kind of protect itself from signing things that Advance time in very unexpected ways into the future to prevent these inescapable uh message signings that create really bad surround conditions um are clients have of that and is there any um effort to try to protect users against this case not from our end it sounds a bit

tricky because you you're into timing territory like if you can't trust your system F gets pretty hairy we we I I would personally wasn't aware of it I'm not aware of any works on our end to do m so my suggestion would be like stop like refuse to start the valid dat CL client if the last entry in the slashing datab datase is more than x hours more than say six hours which shouldn't happen in normal operation um and if you're just restarting after an extended outage then you probably have an operator present anyway and they can just set an override flag yeah I know this happened and like start anyway so that that seems like a

very simple solution that should cover almost everything yeah the case is the case is definitely concerning you know if somebody gets you to assign essentially the last Epoch of all time uh as your target then you've created this like ultimate surround condition for yourself um let's I'd say client teams think about a little bit and maybe we'll we'll bring it up in in some internal chats uh it's definitely something I think worth considering on how to protect the users there okay anything else today before we

close great good meeting appreciate youall coming uh um and happy Paramount launch thanks everyone thanks guys thank you [Music] everybody for [Music]

[Music] than [Music] [Music]