Protocol Work Group Call #7 – January 10, 2023

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

1. 0:04

   hello hello hello and welcome to the seventh near protocol work group call uh my name is Victor I'm a developer advocate for near developer Hub and I will be moderating this call uh I know I'm just meeting some of you for the first time today and it's a pleasure to have you all here uh I'm excited for us today to look at a net proposal and make a decision about it okay and so for our agenda today we

2. 0:29

   will discuss the objective for the call and provide some context about our near developer ecosystem and our n process um next we'll introduce everyone that's involved then we'll get into the main um conversation of neb 488 after that we'll open it up to a Q&A and talk about uh next phase so yeah feel free to introduce yourself in the comments you can drop any questions or feedback or you could just raise your hand if you have a

3. 0:58

   question okay so to get started we'll discuss the purpose of today's call um we're here to publicly vote and arrive at a verdict for NEP 488 uh we're also here to celebrate the time and effort that everyone has invested into this NEP uh I know it takes a lot of time and effort and people to also make this happen so uh we really appreciate that and yeah uh before we jump into to the before we jump into today's call uh I would like to have a talk about our

4. 1:29

   decentralized home base for developers that is near Dev hog and so at near Dev hog we bring together individuals and organizations to help build an open source near developer ecosystem uh we provide social structure tools to allow anyone build um in the near ecosystem and Beyond and now our main tool for interacting is near devh hope.org as you can see on your screens is the Gateway for developers to make meaningful impact on and um developers can share ideas

5. 2:02

   connect with other developers in the ecosystem access resources get support and find communities working on a variety of areas so you could go from tooling to zero knowledge and you can also create your own communities okay so for work groups we have formal work groups like this one who help make decisions in various ecosystem areas such as protocol um so these work these groups have selected

6. 2:28

   recognized experts to engage with the community and also help review proposals uh in a timely and fair manner of course um so for example uh they help make decisions on technical proposals that want to get integrated across the ecosystem such as protocol Improvement and so neps uh you can submit an idea for a technical proposal using a NEP uh it allows anyone propose an idea to the ecosystem when a newp is submitted uh it's when a newp is submitted it's

7. 3:00

   submitted to the relevant work group uh which will then be reviewed and then it will be moved through our net process and so for the roles and responsibilities well uh in terms of participants uh there are four key roles in the net process uh there's the author or champion who is the person who writes the proposal and presents it to the work group um there's the moderator Yours

8. 3:24

   Truly U me who facilitates this process and helps ensure the net progresses we also have a reviewer which is a subject matter expert who reviews the technical visibility of the proposal and an approver who is a work group member and this person contributes to the voting that ultimately makes the decision so what is the life cycle like for a NEP um just to visualize this process you can see there are three phases so there's the draft review and

9. 3:57

   the voting and two possible outcomes which is approved or rejected um now all of these roles mentioned previously help move the net through these phases and towards the outcome so most of the activity happens asynchronously on the NP itself on GitHub um but when we do get to the voting phase uh the work group has an open discussion to arrive at the best decision in a transparent way which is why we're all gathered here

10. 4:25

    today and so before we jump into the review I would like to highlight the participants who were heavily involved in this NP uh first we have Olga um so shout out to you I see you uh here um who is the author of The NEP 488 so thank you so much for your hard work and submitting this NEP um I'm playing the moderator role in facilitating this call we have Michael EOG and EV Jenny as reviewers and um they did the technical assessment um we also have the work

11. 4:57

    group members who include Marcelo m B maren and Bowen oh and shout out to aie and Owen as well um H I think in the interest of time uh maybe we can skip introductions because a lot of you probably already know each other but please feel free to get active in the chat and say hi and with that I would like to move on to the actual net discussion okay so first we'll have the author Olga present a summary of the NP and why she

12. 5:35

    believes it's important and then we'll have the work group discuss their findings and ultimately arrive at a decision yeah hello everyone I'm and uh first of all I would like to tell a little bit about the story why we need this snap in the first in the first uh the reason why we create this naap this quite very huge um the story is that I'm work in the r Bridge team and we have a bridge between which connect near and

13. 6:06

    eum and in eum to uh for validating the blocks it's it's it's switched from the proof of work to the proof of state and for to validate the block we need to validate basically BL signature to check that block is correct and to verify that blocks created on the ethereum is right on the near part but it is very time consuming uh all the stuff is time consuming we cannot currently uh check validate the signature B signature on

14. 6:36

    the near because it's take we become round out of gas it's have a limitation of three gas per operation um So currently to make our Bridge works we validate the B signature off chain that is not great we would like to do it always in on chain to make it uh trustless basically and it is the reason why we create this snap it also have the story Frost we would like just to validate the B signature but uh after some iterations we came up with uh to

15. 7:08

    support basically the operation on B crew not just validating the B signature and it's make uh all of that more flexible and we uh can achieve the few goals first of all the main goal is to validate the B signature for the make our breach cross and uh there is another um another thing that we can do wonderful things that we can do for example we can verify the the the case Nar uh for example previously it was based on the in

16. 7:44

    cre curve that already supported on near but it's already um it's some new attacks appeared and it's not so safe anymore so we can uh update to the new version new more popular and more safe queue and update the our old projects or create new one in more safe way and we can uh support the we can validate the signature or we can validate some stuff where it is uh necessary to validate especially the to perform the operation on the B so it is the main idea of this

17. 8:24

    proposal I think also another stuff that it is uh similar to The Proposal in eum which y 2537 each basically the same and in Aurora in the blockchain we when it will be we can also support this pre- compiles as well so I think basically that's all about the snap the main the main stuff about power awesome thank you so much for your summary and for submitting The Proposal as well you know and your ongoing work throughout this process uh the community has reviewed

18. 9:03

    and talked about this snip on GitHub along with the work group members um so next I would like to invite Marcelo to summarize some of the great things and concerns we saw in the comments yeah thank you uh thank you Victor uh so well Olga did a great summarizing the motivation uh for this net which is kind of what the uh what I will be discussing this net uh enable like part of the ecosystem is already

19. 9:35

    working on bringing CK to near and this has proven to be quite a difficult task mostly because the lack of a primitive required uh for CK uh for CK tooling and this is something that they will be enabled uh by this this net like having efficient uh be less primitive enable enable this and most importantly a shortterm imp act that this will have is uh that we will be uh we will have uh a trustless Rainbow Bridge as we used to

20. 10:07

    have uh when the theum was on proof of work which I think it's uh the main selling point of the Rainbow Bridge like it's uh one of the only few uh really trustless bridge out there and it's not the case today because uh the moving from proof of work to proof of stake made it uh impossible to have it on near um so yeah this is like the main uh the main motivations uh to have this so

21. 10:38

    these are some concerns that were highlighted uh during the discussion uh first concern uh which was making this NEP specification self-contained uh this one itself uh was a little bit debatable in the sense that the whole specification of BLS it's quite well documented in other places but at the same time we need to uh like the whole new protocol need to be selfcontain like if someone it's going

22. 11:07

    to implement a new um uh a new validator like a new client they need to know exactly how it's implemented in the in our main client like in all the clients right now it's only one client so we need to be really specific about uh how we are implementing the uh this specification so there were trade off between how much propositive do we want in these specifications or not I think

23. 11:32

    we achieve a a good tradeoff a good tradeoff here uh the regional let me go through the next concern the regional test case in the net specification lack consistency and Clarity well yeah um yeah I was following the the whole process of net and I thank well all of the reviewers for all the great review they did and Olga for taking care of uh of most of this uh yeah and I think she did a great job here and uh well there were some

24. 12:04

    concerns about choice or return types uh and values I cannot elaborate too much here uh hopefully we got to some like this is mostly about making interfaces uh suitable both for uh Rainbow Bridge and for CK uh I cannot talk too much about how CK will be using uh will be using this but hopefully uh what we have today should be uh enough to at least kick off uh work on CK and we should be able to iterate in the future in case uh in case we need it

25. 12:42

    yeah awesome thank you so much for that um so now that we have heard about the findings uh let's give an opportunity to each work group member to share their opinions uh which brings us to the voting phase okay so based on the net process we need two-thirds we need a two-thirds majority um to move forward with this NP and we've already had each work group member provide their voting indication on the

26. 13:12

    NP itself on GI up um but here's the summary so we had Marcelo Michael and Bowen lean towards approving the SNB um and I see Marsen hasn't provided his voting iation um Maring if you have any further opinions could you share your thoughts sure sure this is because your your your update latency is too slow I did update a couple hours back Victor you did not refresh only you were using some reliable fast chain to do this oh

27. 13:51

    my God anyway that's a separate discussion uh so yes the tldr yes I support this and actually big Kudos Olga this was fantastic to read even for people who did not know exactly how BLS curves normally work you adding a small like FYI here's the here are the basics we're super helpful so for future in my opinion we should be also using this as an example of a well-written net thank you the only small comment I would add

28. 14:17

    is take another look at the names of the host functions uh because you are referencing the EIP 2537 I think or ethereum and the namings are a little bit off give example here you say pairing check versus on ethereum it's usually just called pairing um we might consider having similar lean named functions just to you know if people CM then they will know like oh it's the same pairing and otherwise it's like oh

29. 14:42

    pairing check does it do something different Etc ETA but overall yeah thank you awesome thank you so much for sharing Marson so are we comfortable moving forward with an approval for the snap can I get a thumbs up of reaction in the in the call okay awesome all right congratulations Olga um okay so let's talk about some of the next um the next phase uh who will be implementing and the implementation updates um Olga I invite you to speak on this and of course any other person can

30. 15:23

    indicate they want to speak by raising their hands so okay what I need it look like I need to do something now I'm not get it yeah I think that basically it's we already have some kind of I can say draft implementation something like that it's basically I had I already did some test and I think it's basically work uh it is based on the B EST Library I I found it's quite reliable even without any modification um so I can say that currently it is uh

31. 16:04

    ready ready for review but it's also need a lot of work to add a lot of test I think the test uh test part it is the most difficult one in that NAB yeah one question what kind of gas savings are we expecting you do any kind of backup the envelope calculation of how much theoretically the gas would have cost before and after um yes I did the calculation but I have I don't have the number right now the most important thing that now we within the gas limit previously we 10 times not within glass

32. 16:38

    limit previous was 4,000 teras Mar yeah yeah and now we within time gas limit and is the main different for me the most important start part uh yeah and we quite have I think something like for B signature verification for our case in R bridge is going to take a think around 100 teras I think out of 300 something like that it's not the and moreover I do the some it is approximate gas calculation we also need to do it more accurately in do here with iteration I do it some quick in the

33. 17:17

    Quick Way um it's also the future work that we need to we need to done yes I just wanted to add as well that um uh we have uh engaged an external security researcher to do an audit of the specification and implementation and that will the plan is uh that only once the audit is s completed successfully and they have not found any issues will this will will we be actually be merging and

34. 17:51

    like enabling things and be ready to push things on Main net so that is an additional requirement that we have for this work that it has surp pass a successful L yeah sure okay all right uh I'm going to make a note of that and we'll update the slides after this meeting um thank you so much for sharing uh so in that case uh I guess we can move on to Q&A are there any additional questions that would like to be asked at this

35. 18:27

    point okay we're going to take that as a no and so yeah well thank you so much everyone involved and present on the call uh we're very excited to work together and decentralize the development of near um oh but just before you all run off uh I want to quickly highlight the ways you can get involved in the near developer ecosystem and so uh if you have a specific idea in mind you can submit it using devop or you could find existing communities to collaborate with you can

36. 19:08

    also submit your own NEP and start the conversation and you can view all the NPS and check out their updates on GitHub and hey you can also join our community telegram it's a really great way to connect with others and see announcements for meetings like this and of course you can learn about devop on our website and stay up to date on our social channels we'll post the recording for this meeting and of course upcoming calls on our various

37. 19:39

    channels so yes thank you everyone and have a great rest of the day