All Core Devs - Consensus #68

Transcript

[Music] [Music] [Music] [Music]

[Music] [Music] so [Music]

so [Music] [Music] [Applause]

[Music] so so

[Music] [Music] so [Music] [Music]

great stream should be transferred over if you're in the youtube chat you can let us know that you can hear us here's the agenda slightly mixed up things today because we had a devnet launch this morning so altair devnet won launched this morning two hours ago the fork happened about an hour ago um perry you helped coordinate run that can you just give us and the people on the internet an update on on the status yes one launched about um two ish hours ago and we fought at epoch 10 we seem to still be finalizing and

hovering around the 80 participation rate so still figuring out some some issues with the time but we seem to be doing okay cool um okay great uh i we can discuss once we get to altair a bit of the planning stuff but just wanted to give a quick update on that thanks to everyone for getting up early and or staying up late okay let's run into client updates we can start with prism yeah hey guys terence here so the last two weeks we have mostly been optimizing

a tear so mostly optimized scene um across the uh sync community uh receiver side of things and uh we made a decent progress on that and uh unfortunately um this morning with the test net uh we had the issue where um we were not able to uh propagate block to the peers so it sounds like something to do with the peering related thing what you're trying to figure out so we'll give you guys an update once we figure out and hopefully today and the quick question are you receiving block synaptic stations are you following the canonical chain you just

can't get your own blocks out so what we suspect is that um we had a bug in the sync validation pipeline for the p2p so we basically failed the same committee object which we should not be failing because of that we started banning peers right away so therefore we don't have any good peers at the end gotcha yeah and so other than that uh mostly on the feed zero side um we are enhancing our slasher so we're working on basically the ability to backfill attestations once using to the head so working on

that and then other than that um we are done with the e2 api implementation so now just testing so that's really exciting as well and that's pretty much it thank you thank you and lodestar i don't know if we have any for one from lodestar uh lodestar was on the devnet launch this morning i think they proposed the first block and looks like they're following the head um other than that i'm sure they're working on light clients and other fun things how about uh grand dean is that how you

pronounce that hi so it's actually a lithium world warden which is pronounced grandina okay so so this is what i'm gonna do so we had a small release with small fixes and then some other optimizations in the last couple of weeks we were working on on the experiment that i talked last time uh we are trying to uh to run a couple of uh forex at the same time and we found some interesting interesting idea that i would like to share during the during the marriage discussion which uh i believe will be later in this call is

it correct uh yes we will there's a couple discussion points mikhail brought up and we can uh discuss what you want to bring up then okay fantastic thanks that's all from me great thank you lighthouse hello cool here um so we're pretty much up to date with altair we're still working on merging some of the features and optimizations um getting the front prs merged into our unstable branch um we've also started working on optimizing lta we've done a few things one of them we've added a one pass method to get all of the unslashed participating indices and balances and also the eligible indices so we've

been running that on the test nets and it seems to be doing well so far we've realized we've had to change some metrics and some of our valid validator inclusion apis because altair tracks um attestations differently so we don't we don't necessarily know whether or not they are tested before we knew like did they test did they get enough station in this um epoch or not and now we we know like did they get a timely source at the station in um so we had to change some of our metrics and external facing apis to reflect that better it's not a big deal but um the interesting thing that i imagine other clients will come across as well um

we have been doing lots of upgrades to our network we upgraded the c5 and the b2b packages um and done quite a fair bit of refactoring of various parts of it um so we're gonna include um that in our 1.5.0 release which we've been working working on really hard there's been lots going on in my house actually um to get this released out it's going to be a big big change to lighthouse um so we're currently trying to get all the features finished for that so we can move on to doing testing for it and we'll probably cut some beta um pre-release candidates um as well since it's such a big change uh that's it from us gotcha and

such a big change this is a lot of the things underneath the hood or will expose big changes for end-users yeah most of it is under the hood kind of as it feels like it is always um but this would be a few features um yeah not a whole lot of like changing things just kind of new features and lots of under the hood things gotcha cool and nimbus our focus has been on out there as well uh we've had to develop the codes kind of on a hurry to participate in this nets so we are still trying to test it and improve it as we go along um there are some

very few missing features such as our validation is not entirely complete and now we still have a lot of progress to do on the light client sync side of things other than this there has been some progress on the phase noaa phase zero features such as wix objectivity sync which we have partially implemented but we are missing features such as the block backfilling and pruning of the database to achieve a steady state operation with a fixed size database our rest api and validator grant based on it is also another development track

that we are actively working on we've concluded tests uh involving running a combination such as a lighthouse body data clamp with a nimble beacon node and vice versa and now this seems to be working so we invite other teams that are already taking advantage of the api of the rest api to try to test the compatibility with us nice thank you taku yeah hi um we've been really polishing off the outer stuff so um i'll lay out a devnet so i shut down

because uh got the official ones now which is good um been doing some some profiling around that just the last tweaks to the the rest apis making sure they all align and a bunch of testing around there has been the main things um user facing uh there's a migration tool for moving archive nodes with the full state over to level db without having to do a full resync which is nice um yeah but that's about it for us i think great thank you and uh mr daplai and joined us you want to give us a quick update on loadstar sure

hi all so we have updated our logs polished all the ecosystem libraries things got out of date and we've been working hard on providing meaningful examples so everything is as usable as possible we have been stress testing the note against medieval editors in preparation for the test net that went quite well we have also been working hard on improving a tester performance with metrics and other little improvements at the same time we optimized the gossip handlers and we added an optimization to cache the signature domains once the fork info is known which has been helping a lot reduce

hashing and we have continued more progress on our rest base light client how do we need it from a weak section state and how to generate and cache the information on the node site so it's not extremely heavy memory wise that's it thank you got it thank you and uh congrats on being on the devnet this morning thank you and the first block um okay so moving on we're moving on to most of discussion around everything is altair but we will specifically now discuss i'll tear um alex shalway

myself and a bit some others spent a lot of time uh enhancing testing uh and a lot of what came out in beta one yesterday was just enhanced test coverage um sounds like everyone got those passing which is good i kind of hoped that we would hit it hit a corner case and trip you up but we didn't we still have a little bit of stuff on our list to get on the testing infrastructure some other corner cases and some more random test vector generation um and probably expect to see like a beta two with no future adjustments in a week time uh beta we moved from alpha to beta this is um everyone had been on a devnet at that

point which means everyone had touched all the features and provided feedback as needed so moving into beta signaling things are firming up a bit so that's that oh also jim as you all know did some analysis on the choice of the sink aggregator selection constant and suggested upping that from 4 to 16 which was a good suggestion and that's the only substantive change in beta 1. the test nets are on alpha 8 so that's the one difference as adrian mentioned we could you know on monday change that constant from 4 to 16. if we don't do it in a very coordinated way

we'll see the um sync committees some of that probably drop off a bit and have some scatteredness there but everything else will still be live so we can try that experiment uh monday tuesday if y'all want planning so two weeks ago we said we were gonna do a couple of devnets and we did and we were gonna say that if things went well we wanted to target maybe the last week of july for which is after ecc for upgrading pyrmont as of this morning we have uh at least one client that is still sorting out some issues on devnet one so that is not a full 100 systems go but i would like to open up

for discussion on when we think is a good target for that pyrmont fork um or if we should be discussing you know some iterative devnet launches i know there's a there's a decent amount of overhead each time we do this so i kind of want to turn it over to you to get some opinions on um timeline and path obviously last week of july um with pyrmont would be probably aggressive given some of the the issues we saw this morning um but we could talk about a week later two weeks later or we could wait and do a couple more devnets before we set a date on that any burning opinions and thoughts on how we want to move forward on this

i think the main concern i have right now is that we haven't seen the sync committee stuff working particularly well at all um 50 to 70 is the best we do at the moment in terms of we're getting signatures in there um i think we know the problems right but i'd be quite keen to see it actually work and okay we should we should be able to do 100 attestation effectiveness or occlusion correct data stations and pretty close to 100 signatures as well and when you say we know the problems we think it is a mixture of one prism's offline currently and two that choice of four rather than 16 so we're seeing non-aggregators on some of the subnets at least a significant amount of time yeah i think so um

there might still be some gossip problems um because we are seeing we are seeing like signatures missing but that might be the prism nodes gone so right um i i'm hoping hopeful that those two things you mentioned uh are all that's going wrong there okay yeah so i would tend to agree which puts us testing this between now and two weeks from now and there's two ways to do that one is to shore up devnet one and the other would be to launch another devnet um are we in favor of

targeting the beta 1 updates for monday tuesday they don't have to be in a super coordinated measure we just kind of have to set okay do it by the end of tuesday get your nodes updated with that that one configuration value and then we'll monitor what happens on wednesday sounds good to me on screen to me okay is is getting those nodes and releases updated by end of tuesday so we can monitor on wednesday is that is that reasonable we're good on that timeline yep okay yep great so let's do that and then we'll take a look at what's going on and then we'll make an informed decision on whether we want to do

a devnet launch the following week maybe with more validators and then we'll be here again in two weeks and can make a more informed decision on when to fork if and when and how to fork pyramid so yeah that sounds good sorry were you saying suggesting another test net launch next week as well no i'm suggesting we get these beta 1 updates we do monitoring and at the end of the middle to end of next week we can make a call on whether we want to do a devnet launch the following week or if devnet 1 will serve our purposes for further testing

that sounds pretty comfortable to me sounds alright for us as well okay yep excuse us okay cool um [Music] great i know there's a lot of continued work on monitoring testing fixing improving altair so i suspect that's what's a lot that's going to happen the next couple weeks regardless of the better beta 1 stuff is there anything else related to altair that we'd like to discuss at this point i would just like to say that just to say that we're gonna drop our devnet zero nodes um soon i think everyone the other client devs are intending to as

well great perfect kill him okay so we have a path forward um hopefully someone wrote that down we'll circle back and make sure that information shared on some channels and we will move on with any research updates people would like to share today easy

okay so there were um a handful of points we did cancel the merge call this morning um there's not a ton of content there uh right now as everyone's working on london i'll tear but miguel did have a few points that he wanted to bring up today and looks like we have plenty of time mikhail would you like to go through these thanks danny okay so yeah at least this short um yeah the first one is the [Music] mix hash for using it for rendao and exposing it in the evm for the context we had the discussion um where we been discussing uh what field of the

premerge mainnet block to use to uh feed the rendao into it um like we had to turn we have discussed two alternatives one is the difficulty and obviously in the difficulty case we will not need to update the evm context because difficulty is exposed by the difficulty of code but it has other implications like the difficulty is participating in the total difficulty computation and in the functions rule and the other one is to use the mix hash which is only

um participated by participating in the verifying the fork puzzle whether it's correct or not and not used anywhere if i understand correctly and uh yeah but in this case we will have to expose the mix cache to the edm and use it in sd return value for the difficulty up code and mica has like a particular proposal for this one um micah do you want to i have a quick question is mixed hash not exposed in the evm today it's not exposed okay yeah and so this is kind of a compromise

between uh getting randomness into the evm through the difficulty op code but not uh not accidentally having that value filter out into the other places that difficulties used throughout the code base right now also like the mix hash is always 32 bytes so if we just zero them we can save like yeah and difficulties can be a one byte value if it's set to zero so we'll save some space here as well gotcha sorry micah did you have some stuff i didn't mean to cut you off uh no not really just for those that

didn't follow along with all core devs um in the guest client difficulty is internally managed as i believe an 80 bit value and so there's some risk if we try to use difficulty whereas mix hash as michael said is 32 bytes always so less risk of on that front all right and do you think it also reduces the risk of accidentally having longest chain rules and stuff filter in there because difficulty will always be zero instead of so that works unclear to me because if you're using difficulty at all for your

longest chain rule i feel like you're totally broken since you should be relying on the consistent client for that so i'm not clear well you get to at least throw zero in there uh which would break your longest chain fork choice rule probably is the idea that maybe a client accidentally has both proof of work longest chain and proof of stake longest chain running side by side and this way we guarantee the proof of work won't work yeah if you get a zero in there you you definitely guarantee that you're not that if you have bugs with your and you're accidentally using a long chain rule you're probably going to find it more quickly than if say you put in one yeah sure i guess

yeah i find that i also find this bug unlikely but yes but okay sorry no go ahead um we should not consider it as a one all right has a constant uh value set to one but if we set a render there it will be like 32 bytes and and uh it could be the case uh when the client has failed to switch to the new fork choice rule but and still following the total difficulty rule and it seems okay like because the rendau is pretty

huge value it will over or overbeat any of work difficulty values so yeah i mean you would almost you'd also need to have a valid mix hash right it's like you have to have someone who's mining on this chain and then a client who's also got still following the old chain fork choice rule but is also following the proof of state consensus rule like it just it seems like a really bizarre yeah bugs to me yeah i think that's more and for me it's more of an argument for doing zero instead of one rather than the randomness stuff but uh do you foresee any particular issue i mean i i think this makes sense especially because of the

uh the 32 byte constant size there yeah are there any issues you might see arise from my point of view i think the the 32 bytes being able to save 31 bytes in the header is pretty significant like um we'd like to trim down the header you know in a fork later but nice if we can just from the get go have a 31 byte shorter header than otherwise and so that's convincing to me the i think the trade-off here is do we deal with the from a complexity standpoint either we deal with the complexity potential complexity and go ethereum because they're using 80 bits for that 13th value or seventh value whatever it is eighth eighth value in the header um or do we deal with the complexity of having

to touch the evm and change what that op code what slot in the header that opcode points to so there's basically there's two complexity choices we have to make here and if they are deemed equal then it feels like the space savings wins out if one of them is deemed to be more complex overall then it feels like the space saving may not be worth on the the way that the the difficulty variable is because we can clean up the block header sorry you cut out and i started talking over you i apologize um the way the difficulty value is it can be a minimum of one byte is there a maximum so in the geth code base specifically 80 bits so whatever uh ten bytes is that

right i think like they store it internally as far as the header is concerned it's just rlp and so it can be up to i don't know 40 billion bits or whatever it is yeah so do we also kind of cut a dos vector out at its legs by uh by using the the constant 32 byte size um what would the dos vector be here infinite rlp encoded byte size for different oh yeah or is that just all over maybe but i mean i think technically yeah we've already got that problem everywhere so like when you're rlp decoding this like you already have to deal with that because there are a bunch of 256 or sorry there are a bunch of rlp encoded

quantities in the block header right and someone could create a block that you know has those set to giant um any one of those so i don't think there's any sort of new issues being brought up here normal to be any that we are you already need to have sane limits yeah exactly your your block header decoder needs to be able to deal with someone putting in a giant value for the length of these quantities gotcha and i think i think by convention we just assert that none of them will ever be more than 256 bits so i suspect that most clients decode under that assumption got it yeah so i i think uh mikhail if we just get this written in a public place and

probably source a little bit of more feedback on the execution layer side um we can find the right trade off here yeah sounds good i could probably draft a specification for um let's change right and discuss it okay okay and then next mix update checkpoint between the merge fork and terminal proof of work block what's on your mind um yeah um that could potentially be the case uh

yeah for the context uh we have the merge happening in two like steps first step is the merge fork on the beacon chain which enables the logic that is required to embed the execution payload into the beacon chain and the next step is the actual transition which is signified by the proof of work chain reaching out the transition total difficulty and we will have like likely a week between these two events uh it will give us some time to react if something bad happens at the emerge fork um

so and uh yeah the point about the week's objectivity period here is that what if the weak subjectivity checkpoint happens between these two steps between the merge fork and between the transition process um then we will have to uh first question is whether it's possible and whether we should even discuss this and the second one would yeah so okay so let's a week subjectivity checkpoint is really just something that's been finalized within the time period that you deem safe to load from and so it certainly could happen you can certainly choose something on that range unless

it's deemed unsafe by our discussion and we figure out something around it um what do you see as an issue in using such a point yeah if it happens like between the fork and the transition process uh the nodes that the fresh nodes that starts with this weak subjectivity checkpoint will have to somehow compute the transition total difficulty or get it somewhere uh we are not storing the transition total difficulty in the beacon state so it will not be presented in the beacon state uh

we use like transition store for this purpose and yeah there are two options whether we include it into these whether we include the transition store into weak subjectivity data which is i'm not sure about um or we include it into the begin state or we uh somehow pre prevent this uh checkpoint happening before the transition process right and remind me exactly how that the difficulties calculated dynamically the first one data included after the fork or something like that uh it's like yeah it's the ethon data that is presented in the beacon state

you're in the up upgrade to merge right and you can't historically compute that necessarily from starting in the middle unless you walk back the block tree and asked for a proof about the state at that time right okay right um i mean the easiest thing is to once that forks happen serve wich subjectivity states at that fork point and uh not in between and then once the uh transition is finalized to only serve them

after that point um there's also another point to bring up here is that there's not super robust standards on the serving of this right now although everyone's been working on it with respect to clients there's a little bit of work on standards but so we should probably evolve the two together but i agree it's it's probably simplest to avoid that week um it's also at a certain point it's it's likely never mind i was going to say it was unsafe to try to do the transition process not live later but once things

are finalized you just will have a fork to follow from proof of stake so you don't really worry about if things have been forking out proof work after yeah yeah i was also wondering how clients plan to help plans to plan to work with these weak subjectivity checkpoints and serve the state so it depends on our like decision regarding this point and depends on on this as well right um

i'm okay writing this problem down and having this conversation in over the next couple of months um i also i think we should highlight that it's pretty important for the exhibitivity sync standards and a lot of the r d that's been going on to really shore up prior to the merge yep i agree completely okay is anybody else want to chime in on this discussion topic before we move on and a couple of questions uh just if if something goes wrong in that one week

will is it expected the clients will ship with the ability to cancel somehow like for a clan line flag or is the expectation that during that week we hack out a fix and then get it delivered to everybody that's not yet been discussed do you have a strong opinion one way or the other um a weak opinion that having it with one week window is pretty tiny to devaffix and get it shipped so weak preference for shipping with cancellation but i don't know how complex that's going to be and if the complexity is super high maybe not worth it right and additionally there's been discussion around shipping with whether we should ship with a um terminal proof of work block manual

override so in the event that there's say we never get to the the total difficulty because there's uh some sort of attack on proof work side there's all sorts of forking and it just never gets there or something like that the ability to manually as a community select a terminal proof of work block and just build from there both of those types of flags i guess we should hash out yeah then we can i don't know if we have this cancellation option uh built in to the clients um i'm just thinking about whether it could be abused by anyone or accidentally triggered or something like that

right i mean the cancellation option on the um would be essentially for the beacon node 2 you could expose dash dash override terminal difficulty and put that at you know infinity um which would stall the that would that would be able to use the same code path but update the constant to pretty much stall indefinitely that'd be nice okay um put it on the to be discussed and hash out more lists okay and mikhail uh did you want to

bring up that last point um i know actually um yeah let's just try to bring it up and i'll see yeah i can give the context because i i brought it up uh originally um so there's this notion of a terminal proof of work block this is really once you have a canonical chain going from before proof of stake it is the last proof of work block that made it in there and there's rules on what this can be to really trigger the the transition currently the rule is that terminal proof of work block must be greater than a total difficulty uh that total difficulty is calculated uh prior and just a constant in the uh in the

the chain when i was working on some other documentation uh i assumed that we had this condition where not only must that terminal proof work block be greater than uh the target total difficulty but that its parent greater than equal to it's but it's parent must be less and this would give less optionality on the selection of that block it must be like a block on the cusp of transitioning into that terminal uh proof work difficulty um and it allows if you wanted to on the preferred client to really like reject a lot of incoming block gossip um during the transition period and and make

things potentially safer or potentially just like less surface for variants to happen um and from that perspective it made sense to me to add that additional condition but mikhail brought up the fact that you could have a potential application layer liveness or even reversion issues so take in the extreme uh we hit the minimum terminal proof-of-work total difficulty value on the proof-of-work chain uh but the beacon chain is not live for two epochs

and then the beacon chain comes on and so the proof work chain continues to be built and then the beacon chain all of a sudden comes back online live it's been 12 minutes and must then select the terminal proof of work block from 12 minutes ago because of the way that rule was constructed and so the proof of stake chain would then build from 12 minutes ago take over override the previous proof of work uh fork choice and essentially do a 12 12-minute revision reversion um that was the counter to what i thought was a reasonable proposal i think we we wanted to present it here happy to

discuss it here if people want it's kind of a lot of moving parts but mainly just wanted to get it out as a point of r d discussion if the proof of work clients rejected blocks that went beyond that wouldn't that resolve the issue well there would be build a proof of work change but though there'd be two issues there i mean so there's two if you leave that rule in there there's there's two ways it could go you could do rejection so you have liveness failure or you could build and then you have the reversion issue i guess if you have the rule in there you'd rather the liveness sorry but i mean you're saying you have a liveness failure and because the beacon chain is offline

right i mean you will have that in the future too right i mean that's normal if the content is offline then you you will have so why why why should we make this special rule so that at that particular point um the proof of work chain could continue well you might right you might make the rules such that uh you just don't have the hiccup because if in two epochs they could select what is the highest difficulty uh for the first proof of stake block after the chain um then you you just have a continuous chain but you might open up a tack surface i don't know i mean i guess that would maybe incentivize proof of work to dos or break the beacon chain for as

long as possible at the transition uh epoch which is maybe a bad incentive right so i mean i i think there should just be one block like there shouldn't be we shouldn't try to select a later block right and i mean if the beacon chain is offline then like i mean you're trying to get a higher service level for the transition time then we will have at an at any later time basically like if either of the two is online it should still work but that's not true before and that's not true after so why should it be true at the transition height yeah i think i think i agree with you and that the especially the fact that all of a sudden

if if miners can figure out how to take down the beacon chain they can have they can mine for longer uh that's not i don't think that's a good incentive yeah like one of the one of my concerns is that if we want to enforce this more strict condition we will have to add more rules and if we want to um to block to stop gossiping blocks above the terminal blocks the terminal wall candidates so we will have to also introduce this restriction on the in the gossip

why i mean that doesn't matter if they're gossip like as long as they're not i mean well incorporated into what the execution layer sees as its canonical change whether it's so they shouldn't but you still have to but i mean that's but i mean they execute the if one client at the like at the block height that we're deciding has to switch consensus right right but it has to do that either way the ethylene client doesn't know the transition total difficulty currently because that's calculated dynamically in the beacon chain at the peaking chain four and then the transition the override on the fork choice on the execution layer right now is actually just being communicated that there's a proof of stake block

um right so there's a little bit that doesn't sound that doesn't sound safe that doesn't sound safe to me because that means there's a race condition where there could be another proof of work block um and some people still follow it and only later it gets communicated to the beacon client that actually that block was never valid well it's a it's it's it's an override on the fork choice so essentially it's it's any yeah there's a there's a race condition there like in that because like they or like for example imagine someone is running these two and at the at the transition there is two goes down because i mean that's actually not

unlikely at all like because like i mean this is like the biggest fork that we've potentially ever had right so like what if what if some eth2 client crashes at the transition height then all the eth1 clients that are connected to this particular client will just keep working with proof of work yeah so that that just doesn't seem safe to me like it can't be that if one client wait for an e2 signal to change their yeah i'm not necessarily excited i i see what you're saying i'm not claiming that it is safe i'm just claiming the way that that communication protocol works right now is is the delivery of that proof of stake block is really that the triggering right this is your fork choice and and and it feels like maybe the the easter client needs a way to

tell these one client hey like this is the height at which right which which it could and it could a week prior given the the exactly figured um that's just additional complexity in that communication kind of single-use communication protocol but uh i think definitely worth discussing after that i tend to agree with think right there um if the proof-of-work client continues on proof of work chain for too long eventually it will not be able to reorg back to the proper transition right and so if it goes down for you know half a day or whatever which is not unreasonable then you're stuck like you have to resync everything right especially because we're we're looking at i think each proofwork

client has different values for maximum reorg but they're not incredibly deep yeah so we might probably need to communicate this transition total difficulty down to the sufficient client right to avoid these kind of cases yeah it does seem safer okay yeah that's a good find action okay and yeah i i do i think intuitively i think it makes sense that once the beacon chain's supposed to take over we should and it has a liveness failure we should act as though the beacon chain has taken over and there's a loudness failure there could be a slight lightness

failure due to partitioning proof of work network like a kind of temporal partitioning when the block is not fully propagated but that should be recovered in a block okay um so i think we have a little bit of work to think through a couple of these things and um also get a bit more concrete proposal maybe prior to all core devs next week for the mix hash continue to mix ash discussion um anything else on mikhail's points before we move on

okay uh so alias you had something you want to bring up with respect to merge and your client investigations yeah so you so this this was built on top of my previous ideas of running the two runtimes so we introduce a term that is called the fork time it's a kind of runtime that contains everything needed to run a fork except except the shared components so for example api endpoint is a shared component it's it's one instance for for the world four times uh so basically a client is able to run multiple forks at the same time so we are thinking that this approach could be

useful uh in a marriage so um so the main motivation is that uh during the marriage that there could be some some terrible incidents that we may not have thought about to handle it basically so if client is using the uh two runtime two four two four times to run to run let's say if you fork from out here probably not but let's say we fork our emerge from the out there so instead of regular hard working out here and hoping that everything will go well

we could have a two run times and these four times which one is running the out here basically there is no interruption and the ltr is running after the merge and another fourth time is trying um is trying to um to do a proper marriage with with the provoke chain so if if the marriage is successful then we have a social consensus where we just stop building on out here and then basically forget about that and if the merge is not successful then we can basically drop this attempt and

do again a social consensus on on the next time then when we will try to attempt again after the uh after we fix the cases which uh broke the first attempt so this also would uh would decrease the motivation for adversaries to try to do a coordinated attack because we just publicly say that we we are going to to attempt to merge you know as much as as it needs as it gets successful so so this is a kind of a very high uh level uh approach and this is for me it looks like

it's just a safe way uh comparing to to the current designs where basically the alter or another fork which will be used to follow from for the merge so this is just a safer way as we we still uh will we will be running the the old fork and we can always bolt and make again the attempts to merge on that older fork does the does that make it make sense for you so there's a lot there i think one i i am excited to see someone experiment with the the multiple runtimes to handle forks uh but i think the second thing is that most clients

don't run like this and it might introduce significant complexity to try to get them to run like that uh yeah and make it a dependency on the fork and then i think the main the main pushback that is probably worth pondering is that failure of a fork is probably hard to define it's probably very difficult to codify uh so you could have a social consensus where you like run dash dash revert and go back to the chain that was still being built in parallel but often i think more often than not a failure in a fork would look more like emergency fixes and working through it and getting to a success state rather

than an abort um and defining what an abort is might be difficult okay so yeah i think i i get your idea but the the key thing for for me is that as i thought it was mentioned even this call that this fork is probably going to be one of the most complex forex theorem so uh i don't know i mean yeah i think this this is a great uh argument that that it brings complexity

really complex and some some clients may be really hard to to change to this approach but on the other hand you will see that that well for me it at least looks like it's a safer way to try to fork marriage any other reactions so is the idea that you continue to run you continue to build blocks on the old chain and the new chain so you basically

you double up what you were doing before yeah yeah but this is is is this question for more that that we the decline is already doing a lot of computation and this this will be a double computation that's that's a bad thing or or the your idea is different we'll be doubly computation double database and double bandwidth especially on those attestation topics which on our resource constrained devices which there are mainnet validators on relatively resource constrained devices i i think that's certainly probably breaking a promise um of by going from 100 to 200 and doubling

resource requirements for a stretch of a week or two um okay and and the same thing could be okay go ahead i was just gonna say i think there's something to be said as well for just committing to a fork you know just testing it um putting all our energy into making sure that that fork goes well um as opposed to spreading a bunch of energy as to try to back ourselves up in in the case of failure yeah and i think that that plays a little bit into my worry which which is even defining failure and i think that 95 of failure cases we would work through

dynamically and not do a revert um and so then you end up planning for and doing significant development for my estimate is maybe a bad estimate but for those five percent of cases failure cases i don't know we're all very afraid of complexity yeah that that was the idea to try to to make it a bit more safer than it is now adrian yeah i was just gonna say some of the most disastrous code and difficult code to write is actually failover code when you're running two things at once and then trying to decide

which one's the real one and switch between them it gets real messy real fast okay um any other comments on this i would i mean certainly an interesting thing to discuss um and maybe further discussion can happen on ether r d if people are interested in chatting more about it yeah i think a proper write-up would be quite useful it's hard to take it all in on a call at one a.m there's potentially ideas in there that

we could learn from and so a good writer would be useful and sally is based off of your past two weeks of investigation of forking does it look like you will be utilizing this uh multi-run time infrastructure yeah so so basically we we will try that for althea and but the problem is that it's a major change in the code base as the code base was not designed to run too far times at once but this week we got the code compiled which is a big achievement in

lasting language uh but i think it will take a couple of weeks or maybe even a month it's a bit hard to estimate this uh to to get the code actually working and i think after that maybe i can come back with a with our same more more solid findings from this approach uh yeah maybe you know there is a chance that during this this attempt to do this four-time thing uh we will just figure out that it's not worth the efforts it could be so but otherwise

uh we will try to do that for the out here so the phase one sorry is zero uh if if everything will go great then phase zero will run in one fourth time and the ltr well why don't you keep us updated over the next uh month month and a half uh on on that r d project and we can kind of keep the discussion yeah definitely yeah definitely cool okay let us move on um i think we we did some spec discussion with respect to the merge is there anything other uh and spec wise people want to talk

about today okay and any other discussion points or closing remarks the sync committees are already looking better on the devnet um prism seems to be producing blocks and inclusion rates are as high as 97.98 on the sync committees in fact that block has 100 so that's really promising yeah oh

that's great so i would i would suspect on the order of the probability of not having um aggregators on different subnets from jem's analysis which i think is in a spreadsheet that shall we put out we should probably see some like drop-offs in in sub committee sections as we monitor over the course of hours and days uh which might be interesting yeah we are definitely seeing that okay cool cool uh and are they in contiguous blocks um so we could we could spot them even with prism out you'd see the contiguous box of zeros okay um good and we're we're seeing the same kind of

spiky thing so i suspect it's still happening occasionally okay but generally much much better so validation looks like validation of what we see as the issues and we will patch it up and monitor them wednesday by wednesday all right great uh thank you everyone congrats on the devnet launch progress progress talk to y'all soon thanks all thanks for watching [Music] [Music]

so [Music] so [Music] [Music] [Applause]

[Music] [Music]

[Music] [Music] you