Protocol Working Group Meeting – September 6, 2022

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

1. 0:11

   welcome hello wherever you are this is our first sneer protocol community working group meeting which is very exciting my name is oriakobam and i'm a technical program manager from pagoda and very excited to kick off this group and discuss a protocol proposal today so just to go over the agenda first we will give a quick update on the nep process and working groups which may be a familiar concept to some of you some of you might be learning about it

2. 0:41

   which is great next we will do some brief introductions as we have a few panelists joining us today and then we will get into the main discussion if it's efficient signature verification host functions nap364 and then we will open it up to q a and if at any times you have questions feel free to drop them in the q a button on the screen and we'll we'll try to answer them you know as we go or we'll save time for the end so just to give a little bit background on

3. 1:14

   the nep process and the working groups so pagoda currently owns a lot of the software development for the entire near ecosystem and we recognize that in order to make meaningful progress and make decisions in a more decentralized way we need to make it easier for the community to get involved so the first step is that we've introduced a more formalized nap process near enhancement proposal earlier to help provide a mechanism for for anyone

4. 1:44

   to submit proposals provide rationale and build consensus and so we've been getting nap submissions and we wanted to figure out a way how do we move them forward review them make decisions and determine the next steps so that they're not just sitting in an idle state indefinitely and so that's exactly where the working groups come in so the working group is really a way to operationalize the review of those naps and pagoda in the short term has selected a few leading subject matter

5. 2:16

   experts to help bootstrap the first three working groups so contract standards protocol and wallet standards and we've already had the first contract standards meeting a couple weeks ago and now we're continuing with the protocol working group and putting these groups into practice really will be a gradual approach and require flexibility as we work with the community to to figure out

6. 2:39

   what works and what doesn't but in the long term we really want to introduce more groups to handle various ecosystem needs and empower the community to to run them and speaking of iteration that's why we're here today is to actually kick off the the protocol group and and continue to bootstrap this process so before we get into the the contents just wanted to cover the the roles that

7. 3:04

   are involved in this in this process so there are four key ones author which is the person who writes the proposal and presents it to the working group moderator the person who facilitates the process and helps validate the the proposal meets the guidelines and progresses forward reviewer subject matter expert the person who assesses the technical viability feasibility and then approver

8. 3:29

   the working group member who helped make the final decision and so this may sound confusing if you're not familiar with the process so here is a diagram to kind of illustrate it so basically there are three stages draft review and voting and two outcomes approved and rejected and all the roles that i just mentioned helped move an ndp through this process uh towards the outcome and so today we're here to do

9. 3:57

   this part of the process which is moving the you know an ep that has been in the review stage and making a decision on it so let's go ahead and actually get to introductions so i would like to hand it off to our first working group member to introduce themselves bowen please take it away hey everyone i'm bowen from pagoda uh head of protocol at pagoda most really work on research and development of the protocol and yeah very excited to be here

10. 4:34

    i guess i'm next uh hi everyone marcelo good to see you again in this working group i'm working with pawrora only in the protocol team and hi i'm martian i'm also from pagoda i'm one of the developers for the protocol great thank you all right next we're going to introduce the moderators so max hey everyone uh i'm max also from pagoda but i'm not an approver i'm just here to make sure we follow the process and answer the questions and facilitate

11. 5:15

    yeah hey everybody i'm vlad um i'm helping ori with moderating this uh it's worth groups and i'm also part of the working group for contract contract standards so you can see me more often than other people on this call but i'm happy to help to move things forward yeah so i guess i'll reintroduce myself hi i'm ori and yeah i just wanted to add that i i'm playing a moderator role in this process and so yeah really just trying to help iterate on on these

12. 5:56

    working groups so feel please reach out you know if you have any questions and yeah now i'd like to turn it over to the nap author that we have here today so plus hello hello guys nice to meet you all thanks for inviting me um i work at composer finance and what essentially what we're trying to do is with a broader ecosystem that initially is you know the cosmos ecosystem uh we're trying to bring some

13. 6:21

    really interesting technology standard that they have which is ibc so that we can enable trustless bridges across different chains and um you know we are more like bulk a lot native but near is our first um kind of attempt to make this happen uh outside of cosmos which is you know the native ecosystem and ours which is polka dots so so for us this is super exciting to to introduce a few elements that we believe that needs to be implemented in order to have

14. 6:53

    this up and running and i'm very happy to to be part of this discussion and panel and entire process thanks plus and we're very happy to have you here and we're happy that you took the time to to submit this this nep and discuss it here today so speaking of that i think we can jump right into the nep discussion so efficient signature verification host functions and i'd like to turn it back

15. 7:17

    to you blast actually and and maybe have you provide more context just high level on this and this nep why you believe it is important and then after that we will go into the the working group members to discuss it so take it back away yes so you know as i said the idea is to be able to enable ibc which is a protocol for communicating between different chains in a trustless way what does trustless mean is that you essentially do not need to trust on an actor that holds you know more power

16. 7:50

    than others um for example it could be you know usually like a multi-sig chain or you know a node that has some you know rights that other people don't have this this protocol is kind of agnostic to anything the only thing that requires is like lines um that essentially validate the state of the other the chain on on another chain and this is something that you know nier actually has that was probably the main reason

17. 8:16

    that brought us to you know start with with with you guys um and you know when we started sort of thinking okay what is the delta for for us really implementing this we we thought okay there's a lot of things that we need to add and we really didn't know how how to you know structure everything um onto 180p multiple mdps and and this is like kind of a learning process for us as well and that's i'm saying this because as you can see on the title it says host functions uh and we just like

18. 8:46

    really like narrow it down in the very very end to just like a single host function uh which is you know this signature verification um so that's a bit like if you go to the discussion of everything you you're gonna see a lot of you know history and things that have been removed and really like try to make you know just one change and make it work and yeah so the whole point of this is to say okay how can we introduce this

19. 9:13

    operation which is uh verifying that a signature is is valid or not uh in a way that is cost efficient because this like clients or most of them they they are you know using the very fine proof-of-stake uh consensus so essentially you do have a batch of signatures that you need to from from this validator set and you need to verify this is really like an expensive operation that you do need to

20. 9:38

    do very often so so both it has to be cost effective and also it is ideal is is if you can actually manage to process everything inside one transaction uh so yeah what we did is we with the help of of the of the core devs really like kind of figured out how far away we were if we would implement this uh through wasm and we noticed that it was like a very very uh big change and that was not possible for us to do this uh without really putting this uh primitive

21. 10:10

    inside uh the host functions suite and that's that's why we're here and that's why we've been you know trying to make this work the best we could inside your parameters and framework great thank you very much for that intro blast so yeah we've had the working group members take a look at this nep and make some comments and so i'd like to invite bowen to uh summarize some of the benefits um and and concerns that we saw from the comments so uh bowen please

22. 10:44

    take it away uh yeah so there are a number of benefits uh so obviously the ad25519 signature verification wouldn't enable various breaches and as uh mentioned with the make ibc um and also it will allow smart contracts to verify transaction signatures as well because uh ed2519 also happens to be uh the uh the curve that we use for transactions on the air as well and and finally the nice thing about the implementation is that uh while ed25199 signatures uh have already been

23. 11:22

    used extensively in the protocol today it is used for both transaction designing and also validators with signed blocks or chunks so from that point of view it has you know already been something that the protocol uses widely and introducing uh this as a host function in the runtime wouldn't actually uh pose much new risks uh because the implementation has already been used uh pretty much since the main networks right so

24. 11:55

    next we're going to go into the concerns yeah so one of the concerns uh raised during the review process is that the ap does not specify the exact behavior of the edt 519 verification function it is not a blocking concern the implementation uses uh what we already use in your core uh so the ed2519 and there are the reason why this is a concern is that there are different variants of the ed2519 signature verification uh and it it is important

25. 12:34

    as part of the protocol specification to say exactly what this variant is and and i think uh while this is not blocking for moving forward which is a proposal it would be nice for the author to actually annotate in the proposal itself uh what is the exact behavior of this uh ed255199 signature verification function bone if i if i may add from the moderator point of view i know that

26. 13:03

    there was another concern rise just this morning from alexey claudiv regarding like implementation uh defining the return values and like possible error handling for for the inputs and he suggested to also address them before merging the app just wanted to make sure we are all on the same page okay okay is that the const is that concern on the implementation or on the proposals on the under any pizza so it derives from

27. 13:35

    the implementation so it was informed by implementation informed by implementation but but okay maybe i don't fully understand the concern is that uh is that something missing from the uh ap the proposal itself the suggestion there is to strictly define what should be the return value when you uh submit an invalid length of signature or like publicly yeah that's that's very fair um

28. 14:05

    so very similar concern i feel okay yeah i guess uh i'd like to invite other working group members to yeah share their their their thoughts and opinion as well at this point so who would like to go first um i'd love to ask um this is uh not a blocking thing for this nap to be immersed but i see one of the main rationals it's to add this uh add these host functions so that we can verify like client signatures from other chains uh most importantly uh from pogba if i

29. 14:45

    recall correctly uh but as uh marcin was pointing out there are other kind of signatures that are also required uh for this like line to work potentially so the question is uh last do you have any plan for these other uh signatures do you expect this is enough or what about it yes so so this is uh so when i started researching i also saw the same the same file the same link that was you know shared and not being a poker expert myself i thought you know because vocal supports the type of

30. 15:24

    signatures and they're using they used in different accounts i thought okay we need to have the three type of signatures but then um going a bit deeper into the implementation of the like clients the pogo currently has a like line that's called granpa that uses ed2551 and then another one that is beefy that is not yet rolled uh that is it use dc dsa so i think like the one that was a

31. 15:47

    bit the left behind that was snorkel um on the bulk side we don't need it uh that doesn't mean that it cannot be needed by somebody else so that's why i thought in the beginning you know the more the merrier but uh yeah given that it is really like a strict process um you know i think anybody that comes afterwards they would have kind of a template that they can follow very closely uh and add any other one got it so to be clear it's not completely mandatory to have these other

32. 16:21

    signatures right not for like clients from pogo okay nicely yeah i think that in this this signature it's significantly easier given a near already support tv on its core uh but uh it'd be maybe this is not the place that would be interesting to discuss as well what kind of uh if other type of centers could be added as well to near uh protocol if this is something uh we want to have at the core level for example now uh helium will be depending on bls signatures

33. 17:00

    uh so that could be something interesting as well uh a little bit more invasive probably you wanted to say something mustang right so what you're saying blast is that if this nep goes through you will be able to implement your light client working in a single transaction right correct okay interesting good because one thing i was worried when i was writing that comment was like that you know we're gonna add this but then you're gonna need all the other types of signatures so you still need to have

34. 17:32

    like a very complex you know multi-transaction code so adding this would not help but if you're saying that this can be done in one thing then yeah yes yes that's that's what we we have budgeted and should be enough of course just one more thing it depends also on the valid validator size and this is also something that will grow so as it grows you know there will be more constraints but i guess we'll figure this out in the future okay are there any other comments from

35. 18:06

    working group members concerns or just sort of opinion on how you're leaning or are you ready to to move forward i guess to to the decision i take silence as we're ready to move forward okay cool so the next part is in the processes where we get to the actual vote and i'd like to invite uh bowen to kind of yeah represent sort of the the working group uh working group's decision based on the the comments we

36. 18:38

    just heard and that we saw in the on the thread yeah so the working group members have already voiced their opinion on github so i'm just summarizing the decision for the working group as a whole uh if people are interested feel free to go to the mps shop to look at the detailed comments from each of the working group members but in general we think that the benefits of this amp outweighs the

37. 19:04

    the concerns or the disadvantages it brings and we think it's important uh to enable uh ed2519 signature verification uh at at runtime so that various bridges can be enabled and i would like to point out that this is not only useful for um ibc uh between our like bridges between here and polkadot that also enable other type of bridges um and one interesting use case is actually enable uh bridges between different uh implementation of the near chains um and i don't know

38. 19:34

    whether anyone from calimer is here but this is an interesting use case that enabled the bridge between the public near chance some of the private near chains as well uh so so yeah the working group is in support of this proposal and here i'm representing the working group to give the proposal an approval and yeah we can move to the next steps okay great so yeah so uh as four next steps um as

39. 20:08

    mentioned previously there are still some uh lingering concerns uh from word various people um as summarized there there are many two concerns one is that the ap should specify the exact behavior of the ed2519 signature verification function that is used uh in nearest runtime and the second concern is what vlad just brought up is that the the error handling should be specified exactly so that uh um the there is a defined it is defined on

40. 20:41

    the protocol level how uh each invalid case is handled um and then after those are addressed i think the implementation is uh already there uh as there is a link um that's uh shared on this slide uh for those who are interested feel free to take a look i think the implementation is almost complete except the one of the concerns that uh vlad brought up just now and once that is approved i think we can merge the implementation as well as the

41. 21:13

    ap proposal itself and and finally when uh the ap is actually live or the the feature is live on mainnet uh we can update the status of the ap yeah i guess maybe i i'll pause here to ask uh blas do you have any question regarding the next steps i i would like to reiterate particularly on um on the i understand very well the the concern of you know handling the error cases but i fully don't i don't

42. 21:46

    fully understand what it is expected in terms of the concern uh the second concern like uh can you can you can you repeat which one is the second one but i guess it's linked to the particular implementation of the of the of the curve itself but that that is where i'm just like a bit in doubt of what it is that you guys need for me yeah i think it is uh sufficient to specify which ed25519 implementation is used so that there is no confusion as i said because there are different variants so i think it is likely

43. 22:20

    sufficient to specify in the proposal itself that this ed2519 refers to this uh specific incrementation as defined by uh the the ed25519 dalek library that is currently used in the implementation of the protocol perfect okay are there any other comments about the next steps or decision i can also enable you to talk if that's easier here i will do that i want to elaborate a bit about this

44. 23:06

    implementation concern because it was me who raised it so just telling to use the same function that is in ed245199 daily crate is not real enough because this crate can it has multiple modes for ed25519 verification which depends on the specific function being used and also on rust features which are used for that crate so these variants have different behaviors so we need to specify which exact one is going to be used and

45. 23:48

    now we understand that it's the same that we are using for our verification of signatures and transactions and the various validator messages but i think we need to specify this explicitly okay any responses or other comments okay so yeah we will also post um this in the actual nep itself after like just so everyone is uh aware of the discussion and the decision and i guess i'd like to move it to q a now so if anyone has any uh

46. 24:26

    questions you know from just from the attendees uh on on this nep the decision this process and that would be the time to to surface those so we'll give a minute for people to to gather their thoughts okay there's a comment from ilya all good thanks for being transparent definitely nice to be explicit about security parameters and implementation details for host functions all right i don't see any did we get any other questions during the call i don't think we we did okay

47. 25:02

    in that case i just wanted to reiterate that we're going to be posting this meeting recording and upcoming meetings on uh near.org developer governance and yeah i'd like to just say a huge thank you uh to to blast the author for for submitting this and for for coming here today to talk about this nep as well as for the working group members you know the panelists uh and the community everyone who's really involved we all want to make you know the

48. 25:34

    protocol better and this is this is uh one step uh closer to doing that so so very excited about that and yeah i think with that we can end a little bit early and give everybody 30 minutes back if you all want that so yeah thank you again everybody have a good rest of your your day and evening and more to come soon you