All Core Devs - Consensus #133

Transcript

[Music] [Applause] for for

over here I guess

Tim Beiko: okay Zoom should be live on my stream let's see if it shows up on YouTube

Alex Stokes: okay okay I think I see it I know I see it so thank you T um okay yeah I I tried Barnabas um okay sorry again for the technical difficulties uh here's the agenda we'll go ahead and get started we're a few minutes behind um I'm apparently really bad at operating OBS

so apologies um let's see here this is consensus layer call 133 and yeah the agenda is uh not too pack today so we'll kind of see how things play out and yeah I think we'll just go ahead and hop in so first up uh Roberto had an update on confirmational Research he's been doing Roberto I think you wanted to uh share some content

Roberto Saltini: great yeah thank you yeah yeah so this is a work done by myself AA Francesco Luca and Chi um we've been working on this for a while um just give something I think ad presented some time

ago but given that has been some time I so thought of giving a brief overview what the confirmation rule is and it's um it's an algorithm that allows determining whether a block will always be part of the canonical chain um even though is of course if a block is finalized we we know that but this the idea is to be able to apply this to blocks that are not finalized yet and you know another way it it can determine that um a block will never be reor out under some assumption that we'll see later so there are two properties um one is safety which is basically what I just said essentially when the confirmation

rule says that the block is confirmed then it means that will this block will always be part of the canonical chain of any Hest validator but there is also another property that is uh one that we kind of been busy working on that um it's actually not that easy to get is monotonicity mean meaning that that if a validator sees that a block is confirmed now it will keep seeing that block has confirmed so the two things are different you know it could be that um you see a block that is confirmed and it will be safe but then in say in few minutes you check it again and the algorithm says that it is

actually not confirmed even though it's actually safe so and kind of the two properties they like uh fight with each other in a way uh you know trying to achieve both as been as bit of a challenge that's one of the thing uh we've been working on um so just very quickly now it works um it's kind of it's bit more complicated than this but overall um the kind of the the the algorithm looks at two aspects of gaspa lmd and FFG for lmd we look at the ratio between the weight for a block and the maximum weight and this must be larger than what you see on the right hand side half yeah

whatever is written there half of this one plus the weight of proposed boost divide by maximum weight plus beta um this must be must be verified for all the blocks uh in a chain until you you want to the finalized one and then for the FG component we check you again high level uh we check the we check the essentially the FFG that is supporting a um the checkpoint for Block minus what uh beta is again the um the the maximum um adversary weight uh minus basically what can be slashed plus uh Yus bet which is the weight of the

Honest multipli by the rati of the Honest multipli by the weight of the remaining slots this must be larger than two3 of the total um weight of paper and this um the paper we show this this allows to together with other conditions to ensure that um this block will never be filtered out by the um for Choice filtering Rule and so the two things together that I we allow to determine the this block is is safe so I spoke before there are some assumptions made in terms of safety um I think the pretty expected properties um we need to assume the network is good synchronous

um you know we have finality for when we assume the network is not synchronous um Al we assume that given us any sequence of slots we know that no more than b of the state controlled by by these committees is bisan timee is pretty standard it's pretty uh I say sort of probabilistic property we assume again V is less than one thir and also we assume the B time validators cannot delay for more than one ook the inclusion of attestations that justify a checkpoint from the previous ebook so basically um if by the end of the current ook enough attestations have been sent to justify

the checkpoint from the current ook by the end of the next e these attestations will be included in a block in one in one CH so in a way you can think of this like there will be at least one honest proposal true there are limitations on the Block size but know another way is also to potentially think of a change where you allow to include more attestations if those uh end up justifying a block ter in terms of to actually to achieve monotonicity uh we need stronger assumptions uh beta must be less than one six and also in in a way we assume that there is a new check checkpoint that is there is

always new checkpoint that is Justified in future in books uh actual assumption is more complicated this but you can think it in this way lastly another point that another point that been working on that wasn't present in the first first work uh was it's been dealing with entry exits rewards and penalties so section five the paper so we in the paper we present algorithms in increase order of complexity we start with just considering lmd cost then we move to considering FFG and then we also cons initially considering only basically no changes to the validator set except for

slashing and then in the last section we we show an algorithm that can actually deal with entry exits rewards and penalties actually the algorith structure of the algorithm is exactly the same as the one that doesn't deal with this problem the other thing that changes on the thresholds that I show you before so those thresholds um in the say more extended algorithm they also have components that take taking into account the reward uh ratio penalty ratio and CH ratio um currently there is um so spe the old spec PR of the confirmation rule

has been updated as well um with the uh to reflect the algorithm that you have in the paper um algorithm there is the one that does not assume entering exit rewards and penalties just because um there wasn't enough time and again as I said it's just the only difference here some factors that must be multiplied in the form but the overall structure is the same so in our opinion that spec PR is ready for review and for comments and this is all from me

Alex Stokes: great thanks uh do you mind dropping a link to

the slides or if there's somewhere people could follow up with your work that' be really ni yeah here and drop a few leads great thanks anyone have any questions okay also a PR IND the specs

repo great yeah thanks Roberto thank you okay uh I wanted to keep that up first uh just go ahead and uh work around the time zones with Roberto so next up we'll move to Electra um again there was a quick question about EIP 7547 this is the inclusion list EIP uh Andrew is asking essentially if you know the EIP won't go in to Electra should we change the CFI status um I think that was I don't know if any on the call but either way that

was basically the question um generally I think we if we CFI something it's there's no like formal bearing on inclusion in this sense and so we don't really un CFI things I don't know if anyone feels differently

Tim Beiko: um I guess yeah usually what we do is we just un CFI it when we have a final scope for the fork and we just remove everything that's been CFI and just keep the stuff that's included um if it's simpler if like we really agree now that we're not going to do this we can all we can remove it from the list

now um but yeah uh no strong opinion it get to delay for the time being

Alex Stokes: yeah I mean in some sense CFI is almost like a moral status you could imagine if something's been CFI it's always

cied

Tim Beiko: yeah at least for this Fork right um and then can discuss for the next one so yeah yeah I guess I can change

okay

Alex Stokes: okay uh next up wanted to get into dead Net Zero and everything there so the first thing to call out uh there was a spec release

v150 alpha1 uh I think this is mainly bug fixes for the Petr specs uh also peros test vectors so thank you everyone who got that together in particular shawe um I can go grab a link to them in a second just so everyone has that um otherwise yeah I think uh were there any questions or things to call out on the spec there I think it was pretty straightforward just fixing some bugs from the alpha Zero release yeah shall we uh yes so we have received um at least

two issues of the test vectors in the latest uh spec uh test Vector release so I think I can I will share the link to the chat later um if any clients have have tested and uh just let me know if you encounter some issues and and I expected that we will have another hot fix of the test Vector early next week yep great thank you okay uh next up I did want to talk

about uh just general progress and where everyone is um let's see Barnabas dropped this uh progress tracker in the chat we go ahead and take a look here um yeah do client teams want to give an update how are we feeling about defit zero implementation progress

Sean Anderson: uh so for Lighthouse I'd say we're making progress were mostly focused on the changes related to um moving the adastation index um because we were talking about that in Discord a bit but it does end up being it touches like a lot of the Cod base um so that's the majority of our

Focus right now um we're actually like staging our implementation differently than per EIP we're sort of like implementing all the IPS for different components of the code base as we go so it doesn't quite map to the progress tracker but um solid progress and we're grinding I would say great sounds good anyone else

oh yeah yeah go ahead pleas all right thanks for sir

Gajinder Singh: yeah we are we have also made decent progress and uh we uh for 7549 we are working upon

few things uh but mostly uh things seem done as of now we are making few changes regarding uh with uh treating the partial all request in the new format um but yeah we should be ready pretty soon and for etherum GS I just want to add uh yes on that on that end as well we are doing good for 76 uh we have Incorporated 7685 and so are sort of integrated into individual eips yeah thanks

Alex Stokes: great H so back to back to tle um we are complete on

6110 and 7,02 and we are close to be ready for for the max EB um viip and work in progress for the attestation one this is 7549 um we yeah we what is missing there mostly is the aggregation logic but for now I guess we should be able to follow um a chain in theory so yeah uh still working progress there and finalizing maxb the tldr is

there

James He: uh giving an update for prism um

all of the eips are are being worked on uh but we're taking a similar approach to Lighthouse where uh we're sort of handling um cross components we're doing like all the block changes all the state changes uh sort of separately and uh the 7549 um slowed us down a little bit uh because of uh how many things it touches uh but we're we're making progress

Saulius Grigaitis: so for granted team we uh we progressed a lot on all the eips except that there is really huge work still

need to be done on on attestations refactoring so I did raise this question on telegram uh but it feels from from the update from the other teams it feels that other teams are progressing quite good and it doesn't feel that the teams will not not be able to to do this huge factoring so correct me if if I understood that in correctly

Alex Stokes: yeah it sounds pretty good so far uh I think Dustin you're going to give in a Mis update

Dustin Brody: yeah so I

in I'm going to Echo in terms of um say what White House was saying about like um I'm not implementing I'm going you know EIP by EIP but uh rather uh say sort of set of test vectors by set of test vectors or set of sort of portion of codebase codebase by portion of portion of a of codebase um that being said uh um viewing it by EIP I think I would say as far as I can tell we're okay on 6110 um for from this is the CL side obviously um 6110 70002 um and and um 7251 I I believe

those should all be I mean at least okay enough for for devet zero um a as usual as and this is I I would agree that this is uh 7549 is it's a challenge um and it's I don't know it it's it's underway um and I will I guess my Approach here is to try to to make sure that there's something it can Min the kind of following the chain is my um I mean criteria here um so there may or may not be able for for some for for the 7549 stuff um I'll just say this for

example nimus has no intention of posting attestation slashings like it's not it's fixable it's not worth fixing in time um that's one of the things affected one the little bits of Fallout from 7549 we need another

you just mean for de zero right

Dustin Brody: yeah yeah eventually be in but I'm saying like it's not it won't break consensus and other clients but you know we've had but um we're we're attempting to get this working we have it looks maybe okay but I but but for

very um uh limited view of okay honestly like this this yeah I don't know it hopefully it'll work well enough

Alex Stokes: great

um nimus

Dustin Brody: does a lot of type level stuff in it constru and it's yeah so yeah the rest are there yeah

Alex Stokes: cool yeah yeah I'll take well enough um great I think that was every s team and yeah it sounds like things are progressing well enough um ideally we should be looking at De zero say in 10

days so I know again it's like a very tight timeline but um sounds like everyone is moving towards that so I think we keep things as is uh there was this question brought up of maybe changing demet Zer scope um it sounds like again this attestation factor is like pretty involved for everyone but also it sounds like at least one or two teams are pretty confident that that part will be fine so yeah I guess this is now your chance uh if we want to have this conversation we can we can talk about this but I think generally we should keep as is for the time being does anyone feel incredibly strongly otherwise going back uh for T will be a

super pain and I would I would think that we will stick we would stick into the attestation no matter what so if the thing is to participating or not participating in Dev at zero I would say if we go back I don't know if te will will will be able to particip debate at point right and the thing is we do just need one cl and one El to start devet so if it takes a day or two after say this 10day deadline for others to join uh we can still make progress on the actual initial devet as other people around on their implementations so I know it's a very tight timeline and yeah it's I'm sure very stressful for everyone but it

sounds like we can make it so I would lean towards uh keeping everything as is for now

Dustin Brody: so I I guess one I'm I'm a little less concerned with whether it's in in devet zero and um I think that's sure uh but but the question of I guess my concern is that this seems to have have have potentially snuck in a little bit as a let me say it was framed and during the ACD call as as a

more um minor change that ended up being um and and part of this I think is in terms of the logic of the change there wasn't a huge amount um in some at some level it's quote unquote just moving field around it was not pages of of uh you know if then statements but and and so I I guess I have some kind of process concern there of of sort of I I think that there was a process failure in a way

Sean Anderson: yeah I kind of get that definitely looks a lot simpler spec out than like

actually an mation and it seems like I don't know like how do we readjust our I guess Fork scoping after we start the implementation if we if we want to in the future

Dustin Brody: yeah exactly I think I think that's a good way of putting it and to say that I think every one of these these um eips which was considered uh which has been considered people have looked at in their various ways kind of the well phrase it in various ways rois the the risk return uh the the the benefit cost benefit some kind of

relativly speaking a ratio is it worth implementing this EIP and this one was framed as kind of well why not is isn't it kind of nice um and maybe but and to add to that I think there's some sorry was just adding to to your comment about saying that the initial framing of that was also that it will be some very nice benefits in term of networking and there has been a little bit of misconception initially and then this turn out that it's just block space that benefits for it in the current form and and you're right that we

probably underestimated the impact in the in all code bases because touching the testation that is simply the same for since phase zero uh has been underestimated how how painful would have been to to change the the format even just adding a a field

yep

Alex Stokes: yeah I mean I think that makes sense what everyone's saying you know takeaways I think in the future When We Touch types we should just be very mindful of this um again it seems like I mean there are benefits it's not that it's useless

EIP and if anything I think it does lay the groundwork for future changes around networking that would unlock even more benefits so I think the EAP stays in uh yeah definitely hear everyone that this is a big change you know implementation wise but sounds like we'll make it work yeah

that plan uh yeah just

dapplion: just to remind a bit I think what what happened here is the the original EIP had slightly different implementation uh it only um set the index to to to zero so uh by not having the type change um the fix was supposed to

be smaller but then mik proposed some really nice benefits that we should do and that I think this mutation through the process is I think what what we missed and as you recognized that's what increased the scope in terms of implementation um so yeah for next time if an EAP mutates we should be mindful of uh the consequences even if it's already considered for inclusion

Alex Stokes: right and just to like you know I guess State the obvious like this is the process right like we have theps you know if they sound good enough to everyone then we you know include them

in some sense and it is the point of like then Downstream implementation of that to like sort of raise these issues I think everyone's just feeling a little extra pain because of pretty tight timelines so yeah I hear everyone and yeah these are all things we should be keeping in mind moving forward and um yeah that being said I do think that will make it happen so I'm feeling pretty good about it

Sean

Sean Anderson: um something we're trying to move more towards in Lighthouse is more flexibility with like individual EIP implementations so the like ability to enable disable single features and that

would let us like more easily pull things out of forks move them to separate Forks um if we could like similarly move towards something like that at the spec level to that would be even better because then it'd be easier to get like vectors that are testing like individual features and then different combinations of features um and yeah it might help in snare like

those

Alex Stokes: yeah in general we have this like features notion in the cons specs that gives you that um um I think again maybe just due to the timelines it's like we didn't necessarily have these test vectors these independent ones per EIP just

ready to go uh Terrence asked a question let me go look at this link uh right yeah so Terrence was asking about an addition to 7549 um this was making essentially the representation a little more flexible on chain and yeah that is out of scope for devnet zero and yeah the idea would probably be to include it in later Dev Nets but again we are focusing on just de9 zero for now and then we'll handle

that down the road okay well thanks everyone for your comments I think that was some good reflection and yeah definitely things we should all keep in mind moving forward uh is there anything else otherwise we can move on to uh another presentation on a new EIP

Gajinder Singh: could we maybe get a timeline on like when is the first CL would be ready because we initially tried to do it like last week and now we push time to like the sixth of

May

Barnabas Busa: but is any C team actually can see if they would be ready by next week Monday

Sean Anderson: uh we wouldn't be ready by Monday now I think 10 10ish days we're targeting we might be have something for Monday but maybe probably high probability with being broken so we were thinking more about targeting me the next week to have something more stable but I even see the benefit if we have something kind of

working to spin up some Dev Nets by Monday or or Tuesday and see where they break

Gajinder Singh: yeah we'd be doing the stuff locally so the cost of stuff feeling is extremely low

Barnabas Busa: yeah I think devet zero could possibly wait uh till Kenya and then we would just do all local testing all next still

Alex Stokes: okay great sounds like everyone will be very busy good luck with the

rest of implementation uh so next up I think this is uh Vil he wanted to give a short presentation over EIP 7684 uh would you like to do that

yeah yeah uh I'm going to post two links into the call uh chat so be with me for now yeah uh so there is an EAP 7684 by by D line uh the G is U at this moment when there is deposit coming for invalid data uh on beon chain to the that already

exists uh then it doesn't matter what withdrawal credentials are in the deposit that is common what only matters what are withdrawal credentials are for the valid data that already exists so imagine there is uh for example a malicious not operator who is accepting a delegated stake they um provide deposit data to the client client posts a deposit transaction and uh the malicious validated front runs this transaction with their own deposit with their own withdrawal credentials and uh the Staker who wanted to just delegate uh their other will be gifting them to their malicious not

operator uh this is so-called deposit from TR vulnerability uh it's a pretty subtle one like it was pointed out out it I think like half a year before the Bon chain launched but um it was actually found in the code of Rocket pool and Lio back in the day and both protocols had to both protocol teams had to like uh fix it ASAP uh just before the launch of Rocket pool as far as I remember um this is mostly mitigate in largest protocols and probably mitigated uh in the largest cust custodial services like exchanges and custodies uh though the second one is like just probably true uh there is

no way of checking but these mitigations are pretty cumbersome or Capital inefficient like there are basically two one is just in time checking the deposit like Li does with a special committee to check it uh this is the was in the trust model and costs uh development costs uh operation and like increases brittleness um there are there is an option of only allocating stake to the valid data that are predeposited but this limits uh like this makes model Capital efficient because if there is not enough stake coming then this pre poost validators are just sitting there

like doing nothing um and uh um uh this makes the process of St delegation uh like two-step process which is uh like makes it more cumbersome and worse user experience most of the stake and existence actually just wi it they don't uh like clients the stakers don't check that the valid data is not on chain the not operator does not provide a mitigation uh that that is entirely like a TR tissue uh I don't think it has been uh exploited in uh like uh in actual um life there is I

think like five or six deposit deposits that override Z credentials but they mostly look like Honus mistakes like uh Zer zero withraw credential something like that um but there is like s six 84 proposes a pretty simple uh fix here now B withdrawals are um uh possible when a deposit comes with a withdrawal credential that is different from the valid data that is actually resistent on Bon chain uh this uh uh uh other can immediately be withdrawn to the back to the

um uh execution layer maybe with like some fee to prevent spam or something that um I think like I'm not sure like I'm pretty sure that it's pretty late to get anything to pectra at this point but I'm pretty sure this is would be a good change for etherum taking mechanism

Alex Stokes: got it thanks uh I've had time to look at the CIP in depth uh I hear you on the concern does anyone else have any thoughts or comments at the moment otherwise we might need a few minutes to digest

I guess one question is you know if we wanted to move ahead with this EIP uh would you be pushing for Electra the fstar fork or you're more just wanting to raise awareness today

um U

I like uh my intuition that is like a super small uh proposal that is uh like entirely can feed like in I in I I don't know but like not much work uh but I'm not a client developer and uh that's like what I wanted to understand what the feeling people have like is it something that is so small that can fit into pectra last minute

or uh uh if it's even desirable to write what's the public sentiment on this or that is like just something that uh I'm presented for now to raise awareness

yeah that why

dapplion: yeah so regarding complexity um so unless someone finds a clever more clever way to do it than than what I found there is a an interesting cirk about uh withdraws and after EIP 61110 there is a recursive dependency on building blocks the execution layer

needs to be supplied from the consensus layer what are the withdrawals that have to be uh processed and then the the block of the consensus cannot be dependent on these withdrawals otherwise we have a a recursive dependency so the solution of thep is to evict immediately any withdraw that attempts to to have a different withdraw credentials but because of this recursive dependency we cannot immediately withdraw a deposit um what that means is that we have to accumulate the withdrawals in

the state and then process them afterwards and after EIP 61110 the amount of deposits is not bounded anymore and I think the maximum number at corrent gas uh parameters is about 1,200 which means that either we will have we can have an unbounded cue of pending withdrawable deposits on the state or we have to remove the cap of withdrawals if we want to evict all these uh undesirable withdrawals at deposit sorry within the next block um so that's something that we have to talk with the execution teams to

see how much of an issue it is it to have unbounded withdrawals or up to 1,300 so it's it's not terribly complex but definitely I don't I would not consider something trivial and yeah I I think it's it's good that that we look at this solution and see if we can find something uh simpler but I'm I'm not sure if this F this fits for

Electra

Alex Stokes: right yeah thanks I mean I think we probably need a couple months just to digest consider different Sol and then get to like sort of final EIP so you know that process will need to play out and then ultimately um you know I guess this is the place to come

back once that's done and then we can we can see where things have stacked up

dapplion: yeah as a final comment I think to to motivate uh this solution this does not this affects every single uh LSD or future L protocol and especially for those that want to be maximally trustless um definitely all the solutions involve some sort of um heavy tradeoff or centralized actor so it's definitely an an equalizing Force um agnostic to any specific LST

yeah in general like this is a tax on

development instead of like a straight blocker uh for implementing like trust things but it's a pretty significant tax actually a lot of efforts going into into like mitigating this

Alex Stokes: okay good to know so yeah everyone just uh please take a look when you have time and yeah we'll keep it on our radar okay uh next I wanted to leave some time for

pios

Alex Stokes: uh I don't know if anyone has any update there I know the

client teams have been pretty busy with pectra um there has been some work on the spec lately um like I said there are some pest spectors even released in this alpha 1 cons specs release so it's really exciting to see the progress there I don't know if anyone else has anything they want to discuss right now with respect to puros either an implementation update or spec update spec questions anything like that

uh fallout are

Gajinder Singh: I've been working on PS for last two weeks and uh basically uh we'll try a local lar to loar uh all custody uh testet and if that works uh

then we'll try to integrate with any other peer that is out there

great good to hear yeah line

dapplion: Lighthouse uh I think as of yesterday we can we have completed sampling sampling uh Lighthouse only testet so we can so as of now we can produce blogs with with um garbage extended data we are not actually using ckcg Library yet I think um we can custody we can serve custody and we can do sampling um something some specifics of what we are going for we are going for

trailing da at the moment we are not using yet the new um Network charts formula but we plan to do that uh this week and we implemented a a feature that was suest gested by the Codex team I think where we allow so as a Cody serving we allow people to request the samples before we have them and then we put that request on hold and we will resolve this request once we get the cost to the samples from Gossip so will be cool to agree on the set of features with everyone otherwise we'll have interrupt problems that's it for me

M yeah

Nishant Das: so on on prism send uh we've been

making good progress on P implementation um we are right now in the process of trying to get a prism to prism node working so we have integrated all the uh ckg period methods so it seems to be working for us um we still running into issues with u getting the columns got without um having a Blog proposed with the extended columns being received by the other prison peers but we we are positive that uh by interrup we would be able to communicate with other clients at least as the current spec as it

is

Alex Stokes: okay that's great is yeah just an update from te I don't have the details but uh there is a branch in working progress and we could have something um yeah we could hack something maybe during the the interrupt but not sure

okay

Alex Stokes: sounds good uh yeah that line I think I might have glossed over this was did you have a question around the spec or like sort of what what to initially

Target

dapplion: uh yeah so the I think the the two questions and I'm not sure if the spec is per on this so first one is if we're going to do trailing da or same slot da I'm not I don't think we have a agreed on either way yet and then the second one is um this this feature of if someone request your custody column that you are supposed to have but you don't yet have instead of returning immediately uh resource unavailable you hold this request for some time in the expectation that you will get the column and if you do not after some time out then the request

gets canceled and that that's okay but if you get the custody with a within this window then you resolve the request and what that allows is to have uh a zero zero lack um dissemination mechanism without actually having to do many retries or having go amplification

Alex Stokes: right the latest I heard on the first point with regards to the trail for choice I think uh Lighthouse was thinking that they would not do it but then the latest I heard is that they would do it so I'm not sure anyone else has enough implementation to have like a strong view on that right now

dapplion: yeah I can summarize we had a a chat

internally about this and I think the what we realize is that if you don't do trailing da then the the timing game pressure would be very very high um because you are you will be supposed to perform all the sampling within a very short time window between when you receive the block and when you have to attest um so those peers that do not have very very fast internet connections they will suffer um as Builders and proposers will delay the block as much as possible to get enough boates at the expense of the slowest peers on the network uh if we do trailing da then at least you would have 12 seconds and then there is no much pressure you only have

like the situation will not be worse than today we just have you just have to um brush the block soon enough

all

Alex Stokes: right yeah I wonder if there's a middle ground we've talked before about moving the out to say like 8 seconds rather than four which with respect to timing games maybe doesn't change much

but

dapplion: no I think that that wouldn't that doesn't fit as anything because then you will just publish the blog later right yeah

what is yeah so

Potuz: uh I can't speak for pier D but if by training the a it's only this uh um it's on for choice is this

implementation of filtering the branches where you don't have them and act like that that would be a very simple change in for choice for prison so it's easy to implement

Alex Stokes: okay that's good to hear uh it seems like yeah the the consensus seems to be leaning towards trailing

all is

Saulius Grigaitis: yeah for uh I think for test net maybe it makes sense to uh to not do this trailing for choice just for just to try and to see maybe it you know maybe the all the way does just doesn't work on a small test net for some reason

so then we can automatically roll out that uh that would be one argument the other argument that so far the fork Choice was always um uh always protected from from these blocks that uh are not available so so far the the current approach is is to include include the block only when is the data available is true so so so this traing for choice is a I would say very different approach than we have now

Alex Stokes: right yeah there's another comment from nant uh we should just increase the

custody count and not use trailing you geter the guarantees from go up so yeah it sounds like we're actually kind of undecided on this you do have a point that maybe just for like initial implementations it's simpler to do nont triling like synchronous within the same slot uh so there there's some benefit there although it kind of sounds like we are undecided

dapplion: yeah I think I think practice in practice it doesn't matter like um we definitely don't want to do that for mayet eventually but for an initial interrup people can just sample whenever they want and it should be fine

because it's it it only impacts your local view of the

for choice right yeah yeah

Nishant Das: for interop I don't think we need to actually align so much on how we're going to sample because it just matters for your local view so you could have some nodes doing trailing and some ndes not doing and technically Network should still function fine

right

Alex Stokes: so then I guess it sounds like uh do whatever is easiest for your implementation at least to get started

and I guess we can come to some uh stronger consensus on this down the line okay thanks everyone for that um anything else anyone would like to bring up I think otherwise uh yeah we can go ahead and close out the call here in a few minutes s your hand is still up I don't know if that was from the last time I'll assume it was unless you say

something I guess just the conversation now does kind of bring to mind that uh we might eventually want to break out for puros the big inness some these things but that can happen after we get the first stet running yeah okay yeah I mean that sounds like it for the the day I do have one final remark uh we'll go ahead and cancel the next ACDC uh many of us will be working at an interrupt so it will not make sense to have the call that means the next ACDC

will be May 30th at the usual time so uh I'll post again in the usual channels just to remind everyone but just uh keep that in mind and I think that's it thanks everyone

thanks by bye bye bye record

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.