Protocol Work Group Call #10 - near/dev/hub

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

1. 0:05

   hello again and welcome to the 10th near protocol work group call my name is Victor and it's really great seeing you all here again today um really excited for us to look at neb 539 and 522 so this is our agenda for today uh first we'll look at the objective for the call and next we'll introduce everyone that's involved and then we'll get into the main conversation of neb 539 and then move on to neb 522 um after that we'll talk about the implementation

2. 0:36

   and open it up to Q&A so hey if you're new here uh feel free to introduce yourself in the comments and drop any questions you may have and now let's take a look at the objective for today's call so we're here to publicly vote and arrive at a verdict for NEP 539 and NEP 522 uh we're also here to celebrate the time and effort that everyone has invested into this NEP and in this process there's four key

3. 1:06

   roles uh to neps uh there's the author who is the person that writes the proposal and presents it to the work group uh there's the moderator who facilitates this process uh the reviewer and approver now very quickly for everyone new here uh to visualize this process there's three phases the draft review and the voting and two possible outcomes approved and rejected uh all the roles I mentioned previously help move the net through these phases and towards the outcome uh when we do get to the voting

4. 1:35

   phase the work group has an open public discussion to arrive at the best decision in a transparent way which is why we're here today so yes before we jump into the NEP review I would like to quickly highlight the authors of this NEP uh we have yakob and WLW uh we have yob on the call today uh who's the author of neb 539 um thanks so much for your hard work and submitting the snap I'm playing the moderator role in facilitating this

5. 2:05

   call and now um let's have each word group member briefly introduce themselves for first time listeners on YouTube uh Marcelo would you like to go first uh yes sure thank Victor so hey everyone my name is Marcel vnet uh I was working uh for near and the protocal team some time ago for now I've been uh these last few years working on the protocol group reviewing uh all proposals will NPS uh excited to be

6. 2:41

   here awesome Michael you're next thanks seor hi everyone I'm Michael I used to work uh for near core as well um these days I'm at Aurora doing protocol work with them and still occasionally contributing to near core um but yeah very happy to be on the working group here talking about protocol changes it's very very exciting awesome U Marson hi Marson I also used to be a protocol engineer at near and currently I'm working on ZK sync and

7. 3:24

   ethereum nice uh B you're up next yeah right I'm B had of protocol near and um yeah working on protocol research and development happy to be here awesome okay great great all right uh so now I'd like to invite yakob one of the authors to share a summary of this NP um yob the floor is all yours thank you Victor um yeah just very briefly for those who are kind of confused why I'm here why I'm not here I

8. 4:07

   used to work for uh pagod full-time in the protocol team nowadays I'm uh working with the same people in the same team as a contractor for this specific project um so this is currently the only thing I'm doing in the the ecosystem but I have been kind of in various discussions throughout the whole time even when I was not in any uh contractual obligation uh but this is one thing that I've put a lot of time in

9. 4:39

   me and vatslav spent the last three months working hard on this designing simulating different congestion control strategies and this is kind of the the final bit that I'm going to explain here I don't have much time so I will just give a very brief overview here and I assume everyone with v power in the call did already read the details and kind of knows that's happening but for everyone else um today congestion is a problem

10. 5:09

    when too many um receipts too many transactions come in we don't have a way of dealing it properly when it comes to cross short communication so this slide here shows that RPC nodes just always accept new transactions in the transaction pool we have some limit how large it can grow but then shorts just always take new transactions in no matter what but they can only execute a certain amount each chunk so it it might happen that they accept more than they can chew

11. 5:43

    and in that case the late Reed skew just keep on growing and growing and you have to imagine like short zero can accept transaction and that produces a receipt which then produces another receipt for chart two and there is absolutely nothing limiting it and um yeah kind of the triangle here delayed receip scheme can grow Without Limits now can you go to the next slide please this is what we propose to change

12. 6:13

    we add a bunch of outgoing buffers um for each chart and kind of the red text show as well the the changes that we want to see even on the transaction pool level so very briefly um the outcut receipt buffers are used to ask the autard first do you actually have space to accept these transactions if your delayed receiv que is already too long then maybe I will keep it here on my side on the outgoing buffer that gives Better Properties for memory usage

13. 6:47

    of each Shard and then we compute congestion level for each chart that depends on this outgoing buffer as well as the delayed receipt Cube that already exists plus a sum of all the the the memory bits we we use to store these receipts kind of the summary of all of this gives a congestion level between zero and one and based on this we also make decisions on the transaction pool level um when we

14. 7:18

    see that new transactions are in there that are targeted towards The Shard that's fully congested then we just drop it and say like this short has too much work already let's not keep this here it will take a long time before it's executed anyway let's just tell the user we're dropping it now this is only a protocol level specification so we're not actually say tell whats are doing

15. 7:43

    we're just saying like on the protocol level we will drop them and will not accept them but we want as here written in like the top box reject transactions to conest charts on RPC nodes we want that to happen already there it's not part of the specification but that's intended to use and we provide all the information in the chunks so that RPC nodes have the the information that now

16. 8:07

    they shouldn't be accepting any any new transactions to these shorts and they can already drop it there and then we will get all these limits kind of on these different levels we have these different limits and in the end we hope that that reduces congestion that piles up in the system and hopefully everything is more stable and if you go to the next slide please for users this is kind of what they see instead of waiting for a long time and not knowing what's happening they will either

17. 8:40

    get a fast execution or they will know quickly that their transaction is going to be is rejected now they can retry and maybe in the future add transaction priority but that's not a part of this yet um we we can also put like explorers can decide to show these contest levels these are this information that that's available you can look at how contested is the system and uh yeah kind of one

18. 9:09

    downside here is now it becomes visible that depending on which chart you are on if you're on the same shart as a busy busc contract then you share the same congestion prevention um problems that this short has because of the busy busy account and that's it um yeah that's the summary of what's going on I'll give the word back to you Victor awesome uh thank you so much for your summary and for submitting the

19. 9:42

    proposal and uh yeah all your ongoing work of course throughout this process uh it's really great to see okay uh the community has reviewed and discussed this snap on GitHub uh along with the work group members so next I would like to invite Bowen one of the reviewers to summarize uh the advantages and concerns we saw in the comments um B you're you're y um so this this s is definitely uh major step uh

20. 10:17

    forward in terms of addressing uh the issues under congestion um it uh gives a much tighter uh latency guarantee for uh users who submit transactions when uh there is congestion um so the idea as Jacob just mentioned is that um uh you either uh get your transaction executed uh much faster or you know it's going to be executed uh withing some specific amount of uh blocks um or your transaction that get rejected right away

21. 10:48

    so that you don't um keep uh you don't get stuck in some kind of uh lingo state for very long um and uh yeah this also kind of helps us handle the not just like you know we sing a sh but for the entire system um and it's a great improvement over uh what we have now uh now regarding the limitations um of the this proposal uh I think one is that there is no uh thetical Bond on the uh

22. 11:19

    the receipt buffer sies um this is due to the different trade-offs that we have to make um we can uh it is possible to to have this seral Bond but then it would make other things suffer like the throughput of the system for example uh so we impose basically a soft limit uh that in uh in experiments have shown to work very well um and would um improve the uh serut of the system under congestion um and uh the this user

23. 11:53

    Behavior change this Behavior change of how transactions are handled is another point of concern um but um yeah I mean it's something it is a behavior change that people have to deal with but I think uh it is a actually a positive change because I think people would rather know the transaction failed uh when they submitted um right away rather than wait for inent amount of time uh and uh yeah finally this solution is definitely uh not very

24. 12:23

    simple and uh it introduces more uh cues and and changes to the state and also chunk headers and things like this um but and it need should be maintained going forward but I think the the tradeoff is worth it I think the Improvement it brings to the protocol um is uh definitely very beneficial uh to everyone in the ecosystem excellent uh thank you so much for sharing and uh great so now that

25. 12:56

    we've heard about the benefits and the concerns of let's take a look at each working group member's opinion which brings us to the voting phase okay so based on the net process we need a two-thirds majority to move forward with this neet and we've already had each work group member provide their voting indication on the NP itself and GitHub uh so here's the summary so yes uh we actually had all

26. 13:29

    four working group members uh leaning towards approval of the snip um the the slides will be updated right after this call um so before we formalize this decision I'd like to ask if any of the work group members have any final comments or concerns they'd like to raise yes Marcel yeah so first you know this was a large change so I mean big kudos for getting such a monster design Dock and implementation going the only Con in there that you probably mentioned

27. 14:01

    Jacob is that if someone's unlucky they keep being unlucky right like if you end up on The Shard with a very popular dup like you're stuck period like almost all of your transactions going to be rejected if this D app fails and that's why I'm stressing this is very important that users can easily see it on the Explorers they are affected and potentially giving them a way or an idea how to get out of the situation if this happens for too long this may be a

28. 14:32

    pathological case that again in reality we hope that it will not happen too many times that such drastic things will happen but again for users it can be very frustrating so we need a good interfaces for them to be like hey whatever you know exclamation mark yellow thing on dashboards or in different places where they can use near right awesome thank you so much for sharing that U Mar um and yes congratulations yob

29. 15:04

    um okay uh next I would like to invite yakob again to speak on the implementation of this snap uh yakob you're up uh okay yes so the implementation status is we're we're done with with the logic like we have implemented everything already to the point where it's merged to near core behind the feature flag but we're still working on the last integration test and we're still working on benchmarking the system on a higher

30. 15:37

    like testing it in lab environment is one thing but this is about congestion we have to actually spin up a full Network pull it on reload and see how that works um so yeah we're still working on that and we expect this to not like to be the majority of the work to be done but they possible that certain problems come up as we as we test it and stress it further um yeah I think that's pretty much all I can say about the implementation status there's a project

31. 16:11

    tracking issue in the on the near one board you can also take a look at that and I I keep updating that with the latest status with all the details and linked issues awesome thank you so much for that uh uh so now that we're done with NEP 539 we can move on to the conversational topic that is NEP 522 okay all right I would like to call upon Michael to share some of the benefits and concerns of the snip uh

32. 16:45

    Michael the floor is all yours thanks Victor so um first off think we're all on the same page that we do want something to be done about nonis like the the state today where you can be sending multiple transactions and have um only some of them get through because of the way like if transactions get reordered and a higher ANS gets in first um it could prevent trans earlier transactions with with lower ances from from being accepted afterwards and this this is a pain that shows up basically whenever

33. 17:26

    you end up with a an application that sends a significant amount of transactions so usually the way we suggest people solve this is to add more access keys this is one of the cool features of near as a platform is you can put in uh more more keys on on your accounts and so now you don't have that nons contention but uh it doesn't it doesn't fully solve the problem and adding more and more keys is its own kind of operational overhead so the goal

34. 17:58

    of this NEP to um make it easier to work with a single key and be able to send more transactions at once we're on board with as for the details of how to do that um it's you know still open for discussion which is which is why why we're talking about it now um so the The Proposal in the NEP is this idea of having random nonces where the um client is able to generate random knots doesn't

35. 18:29

    actually have to be true random but it's a detail they Generate random knots they send it off to the to to the chain and the way we we still prevent replay of transactions is the chain has to remember what random nonces have been used for some period of time and then after an expiry it's it's allowed to forget and then you could choose to reuse Nots if you wished um so so that's

36. 18:54

    that's the basic idea there um it's a very elegant solution for for clients right because clients actually don't have to keep very much chain State they do still need to know a recent block to sort of base their uh transaction on but um but otherwise it's just you know generate a number send it off no need to worry about um checking what the current kns is and getting it right um the drawback though is it's difficult to put bounds on this kind of thing how many

37. 19:25

    nonces does the protocol actually have to remember um and how are we making sure that we don't end up in a situation where we are doing a lot of database operations all at once you know if we if we get to a situation where a ton of nonces are expiring all at the same time and we suddenly have to purge a whole bunch of data out out of the database that could cause some some latency issues near cor

38. 19:50

    has seen that before in the past um talking about this offline with Bowen as well Bowen pointed out that there's potentially poor interaction here with the new stateless validation work that's happening is you just have to have non-inclusion proofs um on the stat validation so you basically show the sort of adjacent nonsters in the state cry um and then that generates the proof that the non doesn't exist you don't therefore you only need to spend send

39. 20:21

    two mer proofs in um per per transaction Fair yeah anyways um I say I say potential interaction like stateless validation um of course is still new it it's not launched yet so exactly how how we integrate with that is um not clear but I guess David already has a good idea for it so um so that's one side of this um because there's you know all this discussion around um how how we want to handle nonces I

40. 20:54

    did throw out there an an alternative proposal which was uh not my idea it was originally proposed by by Jonathan at at Aurora but basically what this lets you do is it lets you have multiple nones going at the same time so you have sort of a set of nones that are allowed to be in flight and they don't uh conflict with each other um this this proposal also has its drawbacks um basically the in the implementation it requires the access key that has this type of kns to be

41. 21:29

    a larger data structure so you do end up using more storage um it's also not as clean of an interface as as the random KN say because you you do need to still as the client keep some state right you still need to know something about what knotes have been used um it also has a maximum throughput um the like a parameter of the design is basically how many transactions you're allowed to have in parallel at once before they start

42. 21:53

    conflicting with each other um so so there's there there's TR up there the main advantage it though is that it does have clear bounds because it's based on sort of the current way in which we do transactions um where it's just a different type of access key that has a different way of checking whether or not a transaction is valid um so you're sort of guaranteed that is always one state read and right um so if I could just quickly talk about

43. 22:22

    bat if you don't mind meum go for it no this an open discussion please okay so on the two points one is the bounded size and the second one is the um uh amount you'd have to remove each time M um so I guess I would argue if you put a rigorous um limit on the um expiry time so a very short expiry Time by our normal standards um then the bound on the amount of storage used is the number of transactions that can be done in that

44. 22:52

    time which is a relatively well-known number it's sort of you know 330 times the number of seconds or a thousand sence number of seconds it's number we know um and in terms of the sort of large number of I iio operations you don't actually have to evict all the hashes each round um provided that you evict more than you create um you're kind of in a pretty good state so if you keep them around slightly too long it's not the end of the world um you can have a bounded number while still only like which is I guess would be somewhere around double

45. 23:25

    the potential number if you remove the um atmost the number of um transactions you can do in a single block Times by let's say 1.5 or 1.1 um so that would give you a bounding on the amount of iio you do to the trate um and would give you a bounding and then you already have a bounding on the number of transactions based on the number of transactions you can actually do so yeah what what do you guys think about that kind

46. 23:57

    of and I mean that that is unfortunately prohibitively expensive in the current architecture uh just like if if it's like 1.5 times the number of transactions it we know that um it will in some in cases where in the unfortunate case where it's like not being like cached or like cat miss it can take like few milliseconds uh maybe even longer for read and that is uh that as we have seen

47. 24:29

    uh quite a few times uh um yeah it caus uh chunk processing to take pretty long time and um yeah that is uh unfortunate uh uh situation that uh we would would like to avoid so okay interesting so we're unable to do 300 rights to the try in a block with current overhead it I mean it obviously depends on like the shape of the rights um but uh given that this is completely random like

48. 25:07

    people can put whatever uh they can like even construct it to cause um a lot of cash uh misses and so on yeah it's definitely possible that 300 random rights I mean I think I think Jacob probably know this uh better than me but it's uh not not ideal I say what do you think Jacob you was I mean we have had let's put it this way we have been putting a lot of effort removing as much of the database operations as we can

49. 25:44

    with implemented pre Fetchers that first were just like a hack and then it was used for more and more and more and more things and this if we were to add it it would probably also need a prefetcher so we were kind of fetching this is just talking about the reads just reading the right correct nons values ahead of time and can we do it yes probably we can get it to work um 300 additional database requests is definitely not trivial but probably we can get it done somehow we are mostly

50. 26:19

    worried about latency at the moment not bandwidth but as we add more shorts bandwidth also becomes more and more of a problem um so one side of the things and then with stateless validation a lot of this will be in memory anyway and then we are more worried about just the number of try accesses that each needs the miracle proofs included but we're also working hard to reduce the state witness size and anything we add on top

51. 26:45

    is just an additional burden so to summarize my view we can do it if we need but if there is an alternative that does not need as much overhead that is definitely preferred yeah the problem with rice today is really bad because you need to first read all the notes and and then do the r and you can actually construct the uh try in a way that makes it even worse like it makes really really bad um and

52. 27:15

    um yeah it it's a quite unfortunate situation I guess you'd be somewhat limited by it being a cryptographic has hash function but still you could work away and find some difficult strings in that uh no we're not hashing the keys so it's not we're not no not hashing the the transactions so storing the transactions with the random not is and the hashes yeah the random non it's random like it's you like you don't like people can put whatever in you that is true but you don't store theand random

53. 27:54

    NOS you store the hatch of the trans transaction that contains the random now obviously you have the ability to craft that transaction I'm just saying you it might be slightly harder to make a really nasty request yeah okay yeah yeah but yes but but yeah even I think even without malicious attacks it can be like just like yeah pretty expensive it's expensive if it's used that's yeah okay right right yeah I mean I yeah

54. 28:29

    yeah inre yeah I mean one one way to fix things that are expensive is to make sure that people have to pay more if they are using the feature right kind of as an alternative approach would be like hey if you're using the nons feature suddenly have to pay whatever five times more gas 10 times more gas for this fixed overhead yeah which in theory should cover all the pessimistic

55. 28:53

    scenarios there and it's kind of then it becomes a business question of you know does this feature still make sense if it costs whatever five times more would would people or the apps still use it awesome yeah I mean one thing I would say like Mar like you would be surprised by the level of undercharging we see like with storage right I think 5 is probably not even enough um um yeah but but I mean I think

56. 29:26

    uh yeah I I think the problems said there it's like just pretty difficult to deal with the storage right um and uh and then the ster pointed out in the St validation or then the problem shifts towards the uh withness size and and so on I mean you need two medal proofs that would be the in the in a pathological case yeah I mean I think it's yeah the proof yeah um per transaction yes which

57. 29:59

    is yeah not not ideal I suppose um I mean I I think the idea that Michael mentioned um is would would have uh lower overhead of all to the system I mean it would not work as well for the users who wish to send transactions um because it naturally limit the how par you can you can you can make the how much parallelism you can you can have um um but I think if uh if we want to do

58. 30:32

    something with s uh that would definitely be a change uh that would be uh I mean probably easier to implement as well but definitely um put less uh string on the on the protocol and and David just uh out of curiosity like what level of parallelism because I assume when you were making this this NEP you you you had a particular pain point in mind like particular project that you were that you were

59. 31:02

    having a difficulty with uh keeping crack of nonces and yeah what what level of parallelism do you think you actually need to have this issue be effectively resolved for for most most use cases so the most the most obvious pathological case is um sweat running a relayer um so I I think you could reasonably say that's going to be sort of 300 transactions a second um is I guess the difficulty is that like when you plan ahead and you know your thing is going

60. 31:30

    to need to scale it's it's I wouldn't say it's easy to do it's we've lost lots of engineering time on it uh the difficulty is when you have something that's going quite slowly and it works well and then everyone lands on your website and the thing just immediately Falls over which is kind of what we see more commonly um so yeah I think saturating A Shard is something we we will see relays do pretty soon um and that's certainly a pain Point um but generally yeah it's any wallet interaction we we see it as a large

61. 31:55

    source of our errors even in relative simple actions actually um just people try and do two things at once in the interface over a slow network connection and something silly happens in fact I would take the conservative approach like if we had something like this I would encourage us to actively like if you're not using if we had this feature and you weren't using it we should reject any transaction if

62. 32:19

    you have a transaction in flight because if we don't then the your ability for the transactions to get included with your current application architecture is by luck and not by um and and not not deterministic and so yeah I it's more like everybody is every everybody who who does not explicitly serialize all their transactions is running that risk when their when their application gets

63. 32:43

    some usage when they wall get some more usage and I would love to make that actually more explicit but there's no alternative right now I guess so one thing I'm I guess I'm not entirely following is with the alternative transaction don't you also write the triy each time you mutate the the bit set yes um but it's it's basically the same as the current status quo in the sense that the um and in the current access key model you're just writing the new nons you know whatever one you just

64. 33:17

    used um that that sort of like updates in place um now it's going to be the same kind of thing except the thing except what you're updating in place is is the bit set um so so I guess so if we so if we sort of got rid of the other Nots wouldn't you have the same number of Rights and reads if you if you so if we have to one write and one read to the bit set per transaction or one write and one read to the the non sort of incrementing value

65. 33:49

    currently um why could we not do one write and one read to a crypto hash um why why is that so much more expensive because it makes the try much deeper it creates the sub try that makes it um it's it's not actually a one to one translation like this that one read or one write translate to potentially like 20 qu read of Storage Note which which can translate potentially to like 400 actual database reads um okay that makes

66. 34:24

    sense yeah like with the alternative solution by I think Michael and others proposed it we only touch this Tru that holds information about the access key and that thing we're already touching we're already reading it we're already modifying it anyway and how much you change internal it doesn't really matter it's just same workload or the trans DB but if you have something else somewhere else in the try then that adds a lot of

67. 34:51

    additional work awesome uh than thank you so much everyone for sharing your opinions um great uh so now that we've heard about the benefits and the concerns of neb 522 I would like to point out that based on the neb process itself uh we will not be able to proceed uh with this net because we didn't pass the subject matter expert reviews so therefore it will be rejected um okay great um

68. 35:28

    but but I do want to still say that even though this particular NEP is sort of you know must be closed because process constraints yeah this is like we're following the process this is what we must do I would still like to see another NEP related to transactions opened up like I don't I don't think this should be the end of the conversation on on on this topic so yeah for what it's worth I think I think we should we should still see more work on

69. 35:51

    it I guess I'm just gon to say like just as a comment on the process I find it very very difficult to do uh complex neps when I'm not a proo engineer because kind of the problem I run into as I say like look here's a problem here's a solution that makes sense on the API side and then what I run into is like ah it's it's a budget to implement and that's kind of it's it's a very you know in some ways I wish the M process was a bit more like here's

70. 36:15

    a real problem I have and here's what a great solution would be um and then maybe sort of have a different step which is how do we influ this and I understand there sort of connected in a lot of ways but it makes it um you know I I think there're probably not that many NPS that make it through that are not from prodal Engineers um and it might make it seem a tiny bit exclusive but I appreciate how I can mind different on in the school

71. 36:42

    let awesome thanks so much David and thank you everyone with your reviews um so moving on to q&as uh does anyone have any questions they'd like to ask uh yes thanks um David for the feedback on the N process um I think the uh the suggestion basically like kind of like RP RFP suggestion is uh it's definitely a valuable one I think it's uh uh we don't have a formal process for that at the point um but I think there are people who like open up issues on the AP

72. 37:21

    repository and um basically uh kind of a feature wish list or something this something that they wish to be done um but I think the the NP process itself is designed to actually um have this uh very rigorous review process of U changes to the protocol that's why uh it is it has a lot of steps and it it takes long time potentially um and um people will point out problems in the in the

73. 37:53

    proposal uh the I mean yeah I think the idea is uh uh changes to the protocol are potentially or like maybe all of them are dangerous in one way or another so we want to make sure that uh uh they actually uh would be beneficial uh for the for the operations of the protocol U but also uh beneficial to the ecosystem as well um so yeah I think I I on the noun topic itself I do think this the

74. 38:22

    current status quo is quite suboptimal it causes a lot of problems um and it should be fixed uh I think yeah the problem the yeah the question here is that yeah we like what is the right way to uh to actually fix it um and that kind of balances the user demand and also like what actually works well for the protocol uh and then I think that's a difficult question to answer um yeah I guess I'd like to come back to

75. 38:56

    this at some point um and start by charging a lot for it if it is expensive I think we should charge for it I think there is demand and I think almost every application that is currently used by a lot of people um will fail underload which is a real problem right um but what what is the do do you see what is the problem you see with the propos uh the idea that Michael mentioned is it like the throughput would be concerned I think I think it's pretty tricky to use would be my guess

76. 39:28

    um and I think it would once again scale to a certain point um like and then the day when 500,000 users drop on your site is the day it just Falls over um and it will also probably lead to sort of longtail unreliability like I think it's I think it's it's a little bit dangerous because it's pretty good that's kind of my my problem with it it's it's sort of about you know it's if you do it

77. 39:53

    randomly it's about you know um 26 it was like you know 15 times better than it currently is you pick randomly and it's 256 times better if you do pick in the correct order um but um once again I think it will fail on the load and I think that's we get a lot of complaints in our um we get all complaints about unreliability of the protocol um and it isn't the protocol it's unreliable it's people's interactions with the protocol that fail um and I think the difference

78. 40:25

    between the perception of an unreliable protocol and unreliable protocol is almost meaningless MH um yeah I'm trying to think what that uh but like but I mean assuming like we Implement that idea right I assume that there will be API implemented on the client side SD case that provide interface to to that so that it's relatively easy for people to use yeah it's just that in a lot of use cases um people are using the same set of keys but they're using two different clients and they sort of Hit the same keys and

79. 41:03

    do the same thing so we can write clients that manage it correctly um but if they you know copy the key using in two different place ingressing over there's four different servers running um there's kind of not that much we can do um and that's yeah no I agree but I'm I'm okay with that like every Every evm Chain doesn't support that cleanly like that's that's I think if we can at least make it I think if we can at least get to a place where you have a really good sense of how your parallel whether

80. 41:36

    your parallel transactions or you know simultaneously running push transactions will succeed or fail for a single for a single client like that's still Leaps and Bounds Improvement yeah that is yeah and also I would argue it it it seems to me a bit weird that the the same key pair would be used on multiple different client that sounds like a security another great security practice in the first libraries so it's people calling into the wallet from

81. 42:08

    multiple websites on a shiy internet connection it's a classic and I guess the wallet should contain the non States but they tend not to the not is generally patched elsewhere I see see uh okay okay awesome all right uh so yeah thank you to everyone involved and present on the call uh we're very excited to work together and decentralize the development of near um but yes very quickly before we close of the meeting I want to quickly highlight

82. 42:47

    the ways you can get involved in the new developer ecosystem to everyone watching on YouTube uh if you have an idea in mind feel free to submit it using devop or you can find any of the other existing communities to collaborate with you can also submit your own neb and you can view all the nebs and check out their updates on GitHub in the discussions uh you're also very welcome to join our community telegram uh it's a great way to connect with others and see

83. 43:18

    announcements for meetings like this uh wow that was that was just a lag right there but um but yes you can also learn about devhub on our website and stay up to date on our social channels I'll post the recording for this meeting and upcoming calls on all the other channels as well so yes uh thank you everyone uh for showing up uh thanks Eric David yakob and the working group members uh really appreciate your time and yeah have a

84. 43:49

    great rest of the day and a wonderful weekend