Protocol Work Group - July 8 - NEP-642,645

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

1. 0:01

   Perfect. Hey everyone, welcome to another uh working uh another meeting from the uh protocol working group. Today we are here to discuss uh or to present two NEPs. One is NEP 642 about increasing the cost of accounts of creating accounts and the other one is NEP 645 about uh adding quantum transaction signatures to the protocol.

2. 0:29

   Uh if I think we have everyone here so we can just start with NEP 642. Uh John, if you want, you should be able to just share share your screen and explain a little bit about what the what the NEP is about. So take it away. All right. Yeah, you should be seeing the slides now. Yeah. So NEP 642 account cost increase.

3. 0:58

   What is that about? Uh we have a bit of a problem in the current protocol where when you create an account it takes up some storage and this storage cost some near that cost like the cost of the transaction to create the account but the price of the storage is lower than the price of the storage that you would pay if you use storage deposits. So if you for example save some data in a

4. 1:22

   contract state. So now we have this mismatch where creating the account takes up storage and it's cheaper than the other ways of taking up storage and this is not great. Ideally in a sound protocol storing data should cost exactly the same no matter where the bites come from.

5. 1:39

   So we want to fix this mismatch and what we are proposing is to increase the cost of creating the account so that creating the account actually costs as much as the storage uh would cost using storage deposits which fixes this gap. And what this means more exactly is that we will increase the cost of creating an account from about 0.008 0008 near to around 7 million new which is around 10 times uh more than

6. 2:10

   before but still fairly cheap compared to other blockchains. Um for the details I won't go into deep but in general we are looking for a way to increase the the cost without doing braing changes and the best way seems to be to increase the gas price because if we increase the gas price 10 times then the cost of all transactions increases 10 times including transactions that that create an account. But we don't

7. 2:40

   really want to increase the cost of all transactions. We want to only increase the cost of the create account action. So we will do a bit of a trickery. We will say that we purchase the gas at a higher price at a 10 times higher price.

8. 2:55

   But then we will usually burn at a normal price and for any surplus left over we will get a refund. However, if there is if an account was created, then we will take the money from the surplus the tokens and we will use them to pay for the account creation. This is very similar to the pessimistic gas pricing that we used to have in the past. Now, we're bringing back something similar uh because it is a good way of paying for

9. 3:24

   the account creation. So I have some diagrams uh like let's say we have a simple transaction that just burns 100 tar gas doesn't create any any any accounts. So previously as in in the current protocol you would purchase this gas at the normal 1x price you would burn at the normal 1x price and you would not have any refunds because you burnt exactly what you purchased unless you have some lef over then you would have a refund for that but let's say there is no refund right now. So now the

10. 3:56

    situation is going to change. We are going to purchase the gas at a 10 times higher price than before. And then with this purchased gas, we will burn some of it or like we burn all of it. Burn 100 gas. But we are burning it at a lower price at the at the 1x price. And then we have some price surplus because we paid more than we spent on burning. And this surplus will be refunded back to the to the owner of the transaction. So in the end they pay 10 times more but they get nine times

11. 4:29

    more in the refund and in the end the cost stays the same. But this is for transactions that do not create an account. If the transaction does create an account then we do something different with the surplus. We see that there is this 9x that would usually be refunded but now this will be used to pay for the account creation. So if we created the account then we will subtract 7 million from this surplus and

12. 4:57

    we will refund less to the to the auto and this covers the the increased cost of creating the account. Um yeah so yeah in general you pay more up front for the gas. If you create an account then this increased uh gas price pays for the account. If not then everything is refunded and the final transaction cost stays the same.

13. 5:27

    However uh even if the final cost is the same you will have to pay 10 times more upfront to cover the initial gas price. This is something that could cause some problems but uh yeah should should be good overall. Uh yeah and for the pros and cons uh the biggest pro is that we will have fair storage pricing no matter where the data comes from. You will pay the same for the storage and we are increasing the protocol security and sustainability

14. 6:00

    overall increasing the soundness of the of the protocol. There are some cons like the higher cost of creating the account obviously because we will charge more. Uh there is the higher upfront cost of starting the transaction. You will have to pay 10 times more for the gas up front but you will get refunded later.

15. 6:18

    Uh and there could also be more like there will be more refund receipts which can cause higher latency in some cases. But overall as the protocol team we believe that this is uh worth doing and some of those cons can be mitigated later by optimizing refunds and doing other follow-up work.

16. 6:41

    Yeah. And that's it. For more details, please read the NEP. Uh yeah, perfect. Thank you so much. And actually I I like the diagram. If that diagram is not in in the NEP, we might want to consider actually adding it. It's it's it's always nice to to to have some uh visual cues about what the NEP is doing.

17. 7:02

    Now, uh Jacob, uh you were one of the subject matter experts reviewing the the NEP and you did cast a positive vote. Will you like just you know to to spare a few words about the the NEP and and what you like about it and what worries you if any?

18. 7:19

    Yep, sure. So it it's a bit of a odd one because it's not a super exciting new feature that adds anything. It's like nobody is waiting for this to to land, but it's a necessary one. So our model of pricing storage never has been perfect and we've made changes like with Memry and and things like that that make storage more expensive to maintain and it's kind of longtime overdue to to fix that and it's not an easy thing to do

19. 7:51

    and the team uh most notably Yan but also the rest of the team came up with quite a brilliant way to actually make this change charge more without breaking existing contracts. Specifically, we we keep all the gas unit prices like all the costs in gas stay the same is but but the price in year that we pay for it is increased. So that's like the smallest friction we can uh that we could came up with and it and it seems to be working fine.

20. 8:23

    concerns is kind of what Jan already mentioned um like more receipts that's kind of okay um for the protocol level like the protocol team kind of deal with that for users we are back to what we had with pessimistic gas pricing that we have to pay more near upfront than we actually need to execute the transaction and that has consequences for anything that signs a transaction that can be a normal wallet that that just signs it with a

21. 8:55

    full access key or it can also be a function called access key with a allowance. So these allowances have to be priced higher so that you can even start a transaction even if you can't really use all of the allowance. So there's like a couple of annoyances, but we we've kind of started um communicating this early, tried to figure it out and and like it again, we're basically just going back to what we had be before we removed pessimistic

22. 9:26

    gas pricing and it was just an annoyance. It has always worked. So yeah, I'm happy to go forward with this. it's necessary and I think the team did a great job of really making sure it it it's the best solution that we can have.

23. 9:41

    Perfect. Thank you so much. Uh Arsen, you were also a subject matter expert uh reviewing this. You also approved it. Is there anything further that you will want to add besides of you know what Jan and Jacob already said? Um yeah, I I agree with um everything mentioned above. Um, I'm not a big fan of limited gas in general. Uh, like I would love if the protocol finds a way to um pay infinite amount of gas if you have infinite amount of money. Um but

24. 10:19

    that goes deep into other restrictions um with with how protocol um works and how resharding works and protocol upgrades and etc. So um yeah, I think this proposal is the I don't know least invasive way of fixing things and um we're we don't really break any assumptions that we guaranteed that um users will have because there was no never like some constant gas price which protocol

25. 10:59

    um promised uh to always purchase the gas ads and um yeah like um so we're we're not breaking assumptions here but only make it more secure though it's um like quite a complication to the logic of the uh new core but still um fixes some of historic concerns. So, so yeah, perfect. And yeah, infinite gas, that would be nice. That sounds like a new NEP. So, we can open an issue and and

26. 11:38

    have a discussion there. Uh, so you both as subject matter experts review it and approve it. And in order to approve an NP formally, we need um approvals from the working group. Actually two group uh two working group members have approved already the NEP but as synchronously they could not join today because it's July and they are in vacations but Marcel and Michael have already approved

27. 12:01

    this NEP. So for all intended purposes the NEP is approved and thank you so much Jan for all the work uh to anyone that has ever championed an NEP. It's a lot of work and it's a lot of like talking with a lot of people. So thank you so much. This kind of contributions really really really helped the the protocol. And with that said, we move from NEP 642 to NEP 645 about postquantum transaction signatures.

28. 12:29

    Um, Adam, would you like to take over and uh presently briefly? Yes, sure. Thank you. Uh, so let me without further ado tell you what is this about. Uh in this snap uh we are addressing the threat of quantum computers potentially breaking existing uh signature schemes uh used in near blockchain.

29. 13:03

    Uh it's not a threat that has materialized yet, but it is uh highly possible that uh in the nearest future uh quantum computers powerful enough will be available to uh actually break the existing elliptic curve schemes that that we are using.

30. 13:29

    So we need to provide our users a way to secure against this threat before it happens. uh what we decided to do is to introduce introduce another uh scheme that would be the third one uh in near it's MLDDSA 65 it's standardized uh uh scheme uh it has been recommended by the research team following car also some external uh recommendations as far as I understand and it is uh the middle member of the MLDDSA family. Uh everybody's welcome to

31. 14:23

    read more about it but um not uh the capability and we don't have enough time to dive deeper into this. Uh what's important is that we're basically adding another signature scheme that is resistant to quantum based attacks. Uh yeah, how it works? Pretty simple. uh the new kind of of uh access key could be added uh based on MLDDSA65 public key and then it can be used for signing transactions uh and uh we have implemented this and

32. 15:08

    stabilized protocol version 85 which is uh part of the upcoming 2.13 release existing schemes are untouched. Uh and uh also that the new scheme cannot be used before the relevant protocol feature is activated. So it is a strictly optin feature and we will probably need to to wait some time until it rolls out and there is proper wallet support etc. But we want to be ready here. Uh we've made a bunch of uh design decisions.

33. 15:54

    First, as I've already mentioned, oh, Anton just messaged that Ledger released support for it. That's great news. Uh, right on time. Uh, but, uh, back to where I was saying, uh, it's it's yet another scheme. It's not a replacement.

34. 16:16

    The existing schemes are not being deprecated now because obviously users need time to migrate and it's only ledger and who knows how many wallets are uh new users using. So uh we need to uh wait some time. We can possibly duplicate this all the schemes uh later on but for now this is just uh just an opt-in feature. uh we have decided to store just the hash of the public key on chain instead of the full

35. 16:57

    public key because uh MLDDSA65 public keys are quite large compared to uh the existing ones. Uh we went with SHA free uh 256bit version. Uh it has been researched and uh assessed as secure enough uh so that uh no attacker could uh create another key uh uh that would collide with this hash even using uh quantum computer.

36. 17:41

    uh there is a a nuance related to the uh verification cost which is also a bit higher than uh the verification of of existing signatures. So we have added additional 100 gig gas uh per signature fee. Uh again it does not affect the users of of the existing schemes in any way.

37. 18:13

    Uh the general impact is yeah uh we're shipping it in 2.13 release. uh users from the upgrade on will be able to add these access keys and transactions and delegate actions could be signed with them. Uh we have added like proper accounting for for everything and Rosetta RPC support as well. uh one caveid is that uh now the view access key will return the key hash. So wallets indexers uh whoever consumes needs to

38. 19:05

    match this uh like hash the key to compare against it. Uh similarly uh everybody who who needs to handle these keys needs to update to a newer version of of the SDK which which supports this uh this scheme otherwise it would just result in an in an error uh of unknown curve. Uh the scope of this uh upgrade was initially a bit larger but uh due to limited time frame we deferred uh

39. 19:52

    several uh sibling features to another release and another net. So that would be implicit accounts, validator keys and uh and some tooling. So the net uh 645 is really bare bones just uh you can add a a new key and you can sign transactions with it and if you do so you're safe against quantum attacks. That's it. Perfect. Thank you. Thank you so much.

40. 20:31

    And so happy to hear that we're actually getting postquantum. Uh did someone raise your hand? Yeah. Are any meeting? I'm just wondering uh so if it's an optin feature for users then they should be able to somehow add new keys to their accounts and to delete them in order to rotate. Right. So as far as I understand add key and delete key actions now support these uh new keys. And the question is uh in order to

41. 21:08

    add [clears throat] the MLDDSA65 uh key to my account. Should I create an add key action which contains the full public key or only it hash? And the same one about the lead key. Only hash is is required there. All right. So like the only place where the full public key um is visible is only when you sign a transaction and broadcast it to the network. Yes, that's correct. Cool. Thanks.

42. 21:50

    Perfect. Uh if no one else has any questions, uh we had two subject matter experts reviewing the NEP, that was Darus and Simon. Uh both of you uh give an approval to it. Darus, would you like to say anything about uh the the NEP, what you like about it, what worries you and in general why you approve it?

43. 22:17

    Um sure. Uh I think that um several ideas that was used in the implementation uh was very good uh such as using the hash so that the tree size remains smaller uh minimally invasive and uh ready to ship uh very soon. Um only concerns I had which I also raised is that um maybe later future changes will be needed uh future scheme might needed to be added for validator signatures. Um and in such case we might have to do all

44. 22:50

    the downstream work again. Um but overall because we don't know when the quantum computer is coming um I need to approve it because it's ready for use. Perfect. Amazing. Simon, anything you would like to to add to this? Yeah, from my perspective, I think already moving to postquantum is an amazing thing that we need to do anyway uh in order for the chain not to die because if quantum computer arrive and we still do not have we still did not

45. 23:22

    migrate to post content then yeah we have to expect some money getting stolen somehow. So it's a necessity. Um on the other side like the scheme MLDDSC65 is like is um a scheme that's uh basically standardized by the Nest. So it's you know one of one of the best. It's security of category 3 meaning it's not the lowest category of security that was approved by the NS but it's not the highest. So it's not an overkill in terms of uh public key sizes and so on

46. 23:57

    uh and the signature sizes. um and uh having like having the idea of hashing the public key and using SHA 3 is also secure. So in my opinion it's fine. Uh we went through a couple of rounds of um polishing the uh the NAP but now I think it's in a good state to be approved.

47. 24:18

    Perfect. Thank you so much. And we do have uh here two members of the protocol uh working group. Uh, Yun, would you like to cast your vote on the NEP? Um, I don't think I am a uh the indie comedy, so I don't know if I can cast my vote.

48. 24:41

    Okay. But Anton is I am Yes. And I obviously support both of these NEPs. Uh, we extensively discussed them and they are quite necessary today in my opinion. Perfect. Perfect. Then what I'm going to do is I'm just going to require one other working uh protocol member to just uh approve the NEP on the on the GitHub uh PR. But for all intended purposes, if two SME and one protocol group member say yes, the NEP can be considered uh approved. Also, it's it's going to be merged into the protocol soon.

49. 25:21

    And with that, I would like to say Adam, thank you so much. and also to the to to the reviewers Darish and Simon because this really helps the protocol growing. And that's it. We had two NPS. We saw two NPs. Both of them are approved.

50. 25:38

    Thank you so much for joining and see you around in the next uh protocol meeting. Bye everyone.