NEP-652 Approved: Fixing Missed Chunks and Improving NEAR Network Stability

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:01

   Okay, and now we're recording. So, hello everyone and welcome to a new working uh group uh protocol working group meeting where we're going to be discussing NP 652 early chunk producer reassignment. Uh this is uh one of the meetings that we do so the community can later go and see what the progresses are being made in the protocol. Uh Stefan, you were the one championing the NEP. Thank you so much for the contributions because this is how the protocol moves uh forward and yeah if you can make a short

2. 0:34

   introduction for the NEP the floor is yours. Uh yeah so I can't share my screen because I just changed to Google Chrome and I have to yes restart Google Chrome from scratch. So I'll just talk about based on the two that I have.

3. 0:49

   Uh so basically it's introducing an early chunk producer reassignment mechanism. Um, and to paint a picture about why it exists today, an offline chunk producer keeps receiving uh chunk production slots until the epoch ends. So if a chunk producer goes down, uh the shard it is producing for becomes more unstable and starts missing chunks. Uh the existing key count only affects the

4. 1:18

   validator set uh two epochs later. uh so that malfunctioning chunk producer can in the worst case be down for two epochs and still miss chunks and every assigned lot will just become a misch. Um and what this early chunk producer reassignment mechanism changes is that it will detect this uh chunk production failure during the current epoch that we are in and then it will exclude the failing producer from uh future slots in

5. 1:55

   the current shard for that current epoch and then these slots will be reassigned to the other working producers. Um yeah, one thing to keep to keep in mind, this is not an immediate validator removal from the validator set. The old mechanism still kicks in to epox later, but during the current epoch, uh the shard will be more stable.

6. 2:24

   Perfect. Thank you so much. Um I know that uh so this was this had two subject matter experts assigned. One was Jan uh Malininoki who was uh not able to join uh but they gave their approval on the NEP and then the second one was uh Michael right uh who is not only anme subject matter expert but he's also part of the uh of the working group. Michael, anything you would like to say about uh

7. 2:56

   you know advantages, disadvantages, what you like, what you don't like and your general uh idea like if you want to approve or disapprove this nap. Uh sure. Yeah. Um so in general I think I think this NEP is beneficial to to the protocol and I do recommend that we approve it. Um obviously keeping stability and chunk production is is important. Um, the only thing that I was thinking about that could be an issue with this is this idea of an adaptive corruption attack where a malicious

8. 3:30

   entity is basically trying to artificially leverage how much stake they have available by targeting specific uh participants in the protocol. and and this this NEP basically proposes effectively increasing the stake of the remaining non-b blacklisted validators.

9. 3:50

   So, so we can we can imagine that if if we had a chunk producer who was malicious but didn't have enough stake on their own to control the shard, they could intentionally try to, you know, uh mess with the network connection of some other validator so that so that they get hit by this early kickout mechanism and then increase their their own weight and then maybe they they have more ability to do something malicious.

10. 4:15

    All that said, I don't think that's actually an issue here because we already have stateless validation, right? The chunk producers are only part of the equation. The stateless validators are the ones who have to actually endorse a chunk. So even if it was true that a 100% of the stake was malicious producers, they still couldn't put through a uh say invalid state transition because the stateless

11. 4:41

    validators, the honest stateless validators would would reject it. Um, so yeah, from my perspective, I think I think this is not really changing anything about the the current safety properties of the protocol, which again relies mostly on on on stateless validators for for safety. Um, and then does have some improvements on on the livveness side because uh we are preventing some some chunks from getting missed. So, you know, overall thumbs up from me. Thanks Stefan for for writing it up. Really appreciate it.

12. 5:14

    Nice. And I do like the points that you you're bringing up actually. So I do think that we will need to um did we Stephan did we update the NEP to reflect this because otherwise it would be nice at least to add it as a section of like you know discussions that that or potential problems that were discussed during the the NEP production and and and and review.

13. 5:39

    This discussion I did not add it in but I can do it afterwards. Perfect. Two thumbs up then. Uh and then we also have um Anton who is also part of the working group. Uh so if you would like to say anything about NP and the the vote that you would like to cast be that approval or disapproval.

14. 5:59

    Yeah. Um I mean there's not much to it beyond what has already been discussed. Uh I think the only thing that I would like to highlight additionally is that this is not some sort of like out ofthe- blue premature optimization madeup scenario. We are addressing very specific issue that we observed on test net in the past and we were I think we were actually very close to the same thing on mainet earlier this year where

15. 6:24

    this mechanism if present would have saved some network instability like network was working but some shards were not feeling too well because of like some larger validators going offline and recovery took way longer than we would it'd like to be. So this is this is solving a very real issue, not a a potential theoretical one. So yes, and that's why I'm also voting in favor.

16. 6:49

    Perfect. Thank you so much also for that comment. Uh this is literally exactly why we do this kind of of NEP meetings. Perfect. Is there anyone else uh on on the present people that would like to say something? But if not otherwise for all intended purposes we have two subject matter experts that vote yes and we have two protocol group members that voted yes. So the NEP is uh approved. Do

17. 7:14

    we have a timeline when this is going to come live to test net and mainet out of curiosity? Well on test net it's uh already live. Okay. One minute I think in two weeks or three weeks. Perfect. Okay. Well, then if no one else has no further questions or anything to add, we can just call it a day. Thank you so much everyone for joining. Uh thank you so much, Stefan, actually for challenging the the NEP and catch you in the next one.

18. 7:52

    Bye everyone.