Protocol Working Group #17

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

1. 0:01

   Cool. All right. So, uh today we are here to discuss uh I believe we're going to introduce NEP uh 606 and 616. Is that right? Um and it's related to deterministic account IDs. Um who would like to present on that? Um I can all right um so yeah um there is a single NP 616 about the deterministic accounts so the do you want to me to share the screen maybe and maybe go over the text or I don't this is the first time that I'm doing this so yeah if you could show that would be

2. 0:49

   awesome okay um just a sec yeah just a high level overview of the changes. No need to get too too technical. Just uh All right. Something for posterity for people who are people in the community that are interested in in sort of what's going on at a high level.

3. 1:10

   All right. Um so um yeah the NP is basically to enable um sharded contracts but not directly by supporting some kind of something new for these sharded contracts but rather by by just introducing a new type of account ID and this account ID will be derived deterministically from the initial state that consists of the code of the contract plus the uh like the storage state of the contract because that's basically what defines the state of the contract. Um yeah and um um the idea was

4. 1:51

   um uh like the idea is borrowed from ton actually and this is like the second largest uh shed blockchain that I know. So there is nothing like specifically new here but still I think it's worth borrowing some ideas from them because this model showed really well for their uh blockchain and uh it fits quite nice into I think um yeah so the usual questions that come um to mind when you

5. 2:27

   start to think about how to implement these charted contracts um is that uh like first you need to verify somehow that another contract calling your contract executes the same code and uh this is issue number one um because when when you're being called nobody tells that hey I was executing this code and uh uh here's why you can trust me for example if we are talking the shed funible token wallets where each wallet uh resides in the in the like I have my own wallet and some other guy has his

6. 3:05

   own wallet and these are um separate smart contracts. So um when you do a transfer from um from the sender to the receiver uh the sender basically decreases his like deducts uh uh his balance subtracts from his balance and then the receiver um adds the value that it was transferred.

7. 3:29

   Um, and uh, but in order for me as a receiver to to make sure that I really can increase my balance, I should somehow have a guarantee that the sender actually subtracted uh, this amount from his balance. And so the the only option to make this the guarantee is to make sure that the code that I'm right now executing is the same code that he was executing the sender.

8. 4:00

   Um and that's why we need to to prove somehow that the contract that interacts with us right now um was executing some specific code. Um yeah. So the second um question that comes to mind is that who pays for deploying all of these um smart contracts and actually we can use the um the zero balance accounts for that um that were introduced I don't I don't remember in 4 91 I think I know that's the global contracts but somewhere here

9. 4:40

   I I don't remember um yeah so um but but sometimes The state can be bigger than 770 bytes which is the limit for zero balance accounts and that's why someone needs to pay for the creation of of this contract and the like then it comes um to a question who pays because if I want to send my if I want to on board my grandmother to crypto and I want to send her uh I don't know some some tokens then I don't want

10. 5:17

    to ask her to first prepay for her wallet contract that will hold her balance of these tokens and uh the user experience will be much uh more straightforward if I just can prepay for her but then if I pay for for the creation of um her wallet her deterministic contract that does something but in our context I'm right now talking about the uh shorted funible token wallets. Um then should I be able

11. 5:48

    to then um um like claim back the the amount of near that I paid for the storage costs. Um that's the second question. Uh then um there is another one uh about um what if her contract that I'm about to interact with was already created. But I don't know as a as as a as a sender. I don't know if some some contract was already deployed initialized or not. Okay. If if if I'm a human um I can do it offchain. I can

12. 6:33

    just query the blockchain and say hey like whether u my grandmother or whoever has uh already the wallet for the contract of wallet deployed. But then if if you think about other smart contract that like sometimes tokens are being sent and received by other smart contracts for example other D5 protocols and then um there is no way for this D5 protocol to ensure that for a smart contract to ensure that another smart contract already exists. So that's why

13. 7:08

    this smart contract when it is initiating the sending of the tokens, it should prepay anyway for for the creation of the receiver uh wallet of the wallet of the receiver. And um now what happens if it was already um like if it already exists then these funds should somehow get refunded to the initial sender and the initial sender can be considered as the um like the first guy into the chain of of sharded interactions between

14. 7:46

    the smart contracts that actually paid for everything for grading uh of this uh of this particular contract for initializing this one and and like this chain can be really long. For example, I can transfer these tokens. Then I'm like I'm basically supplying I don't know collateral to some DeFi lending protocol. then I'm getting in return some uh like uh liquidity provider tokens and then I can I can send them as well and like this chain of calls can be really long and it can involve a lot of

15. 8:21

    sharded interactions and therefore I should be the one who pays up front for um for the creation for the initialization deployment of these uh contracts. contracts and um each of them could have been uh existing already. So that's why there we also need the mechanism to refund all of the um all of the newer tokens that I attached to every for the every step.

16. 8:54

    And um the final question is about um uh what are the permissions on like if I own some own in in a semantic way own some shed smart contract for example it represents the like my my sharded funible token wallet and uh I'm able to send to to to send uh tokens from it then Um, how does it determine that I am the only one who can uh do it? I'm the only and maybe if we're talking not not only

17. 9:34

    about the shed funible token wallets or we can um talk about um a lot of different applications for that and uh the the question is who is allowed to to make some actions to take some actions on these accounts and um it turns out that the most flexible approach um in in in my opin uh was to um let the contract decide. So the contract decides what are the permissions. It like it it manages some something in uh inside of its storage.

18. 10:13

    it can keep the uh the owner of uh uh this contract or maybe some other roles and that's how the permission question is resolved and then um uh like basically this NAP is about answering all of these questions by introducing the the um concept of deterministic account ids. So if we have an account ID deterministically derived from the uh initialization state that is over here like this is a versioned one

19. 10:47

    but basically what we should look at is these two strcts. So the initialization state of the contract is its code and its code can be in this implementation um it's it can be a ref reference to the globally deployed contract code and this globally deployed contract code can be referenced by account ID or the hash of the code um and also the data that we populate into the storage of this um contract on the first initial initialization and so then we derive like but then we

20. 11:20

    define define how we derive the um how we derive account ID and um um there are some unresolved questions here I I wouldn't go here but like there are some unresolved questions about what the prefix should be but it should be different from from existing prefixes for example 0x will be the implicit Ethereum account ID but we need a different one so that the runtime Can the near core uh can

21. 11:55

    um understand um what should be the um costs and the fees like the um the storage fees uh and the gas fees for interacting with this account. Um and basically how we derive the account ID is we serialize this strct then hash it the serialized value here take the last 20 bytes the same for Ethereum and prepend like encoded in hex and then prepend zeros s and um the runtime and then we can make

22. 12:34

    like a lot of um magical things for example we can leverage that to ensure that the contract cont that has called us executes the same code as our contract. We're doing this by uh by constructing the initial initialization state for the caller contract inside of the runtime of our contract uh our function call. And then we just make sure that the one who called us the predecessor matches the derived um derived uh account ID from this stage.

23. 13:14

    And uh for every interaction with other smart with other sharded smart contracts that follow this deterministic account uh schema uh we need to introduce one more action that actually like the that actually initializates the states of the contract that we're about to interact with as an an action after which we put all of the actions like function calls that are that um interact with the contract as we want

24. 13:46

    to. And uh here we just pass the this state and it need but maybe in serialized for form already. And uh the runtime should ensure that um the account ID of the promise that we're creating right now is the same as uh as what account ID should be derived from um this state in it. Yeah. And then like a lot of um technical details I wouldn't go into them about refunds, how they are made, how the versioning of the uh state in it is made and the

25. 14:32

    um other host functions that we might need and that we actually need for this to work. Um basically this is the only host function besides the promise uh the action attachment to the promise. Uh this is the main um host function function. We need to to be able to query the code of the current contract that is being executed um in order to verify the caller. And uh these are just a bunch of um like helper um host functions that these were never

26. 15:11

    implemented but um some of them are exposed to through the just constant values but it might be better to um actually implement them. And this is needed to this one is needed to prevent um return bomb attack. in that that also is present in the NAP 141 standards for regular funible tokens. Um so just the like it's better to to introduce it now than never.

27. 15:42

    Um yeah like that's it and um I can talk about future possibilities as well but is it clear what this proposal is about at this stage? Yeah, why don't we take some questions and go from there? Yeah, Michael, you wanted to ask something? No, I just wanted to say great job.

28. 16:07

    Yeah, I I think I think that was a nice summary. Thank you. All right. Um, yeah. So as for the alternatives we have we had the uh sharded contracts uh that was initially proposed in the NAB 605 and um in comparison to to um this proposal uh the shed contracts or sharded context is also nice but it has two big limitations. first of all is that um we divide all of the smart contracts in two worlds in this approach uh in the

29. 16:49

    sharded world and not sharded world and unfortunately they cannot interact directly with it with with each other but there should be some router contract that um is the only one who allows to to to proxy all of the calls between the Charlotte contracts and not shard it.

30. 17:08

    But then it starts to uh but then the question the question arises like but this makes interaction from sharded world to non-sharded completely non-sharded because all of the calls should go through a single contract that is deployed on a single shard and therefore we're just hitting the throughput of of the of that single shard. Um and the second issue with this proposal is that with this one is that

31. 17:40

    um uh the the compatibility issue like um there is if if you try to to implement a sharded funible token standard in the um using the the appro described in the sharded context uh in AP then you um find yourself in a situation that you need to design such a shed smart sharded fungeible token wallet contract in a way that it allows user to help to hold not only his balance but also all of the

32. 18:21

    balances of all of other contracts and protocols that imply that this user is the only one who can um I don't know send funds from his wallet. Um yeah and more on that can be uh read in the uh comments um to the this nap I think or or somewhere in the discussion um yeah and um yeah as I've said the the idea was taken from ton um but actually from like like it it it differs a bit from uh ton's approach because I think

33. 19:04

    what sets Near apart is that in near you can have chains of promises while in ton you don't have that in in tone the only option to to understand that your cross contract call failed is that the message that you've sent to this uh smart contract then is sent back to you. it's bounced and the and you just uh have the flag that this message was bounced and so um it leads to the fact that you cannot refund really

34. 19:44

    uh because the amount and one of the reasons for that is that the amount of gas attached to the refund message is only enough to actually send the message. But like the amount of gas that that that you receive uh in the in this handling of failure function of your smart contract is very very low. You can't do really anything with it.

35. 20:15

    And um but but in we can have we can create chains of promises like call this contract and afterwards check the result of the promise and then uh do something. So it allows for refund mechanics and um um yeah it's like much um I don't know like much easier for developers to to design protocols. Also the the the another complication is that in tone if you do not attach enough gas there there is no difference between

36. 20:50

    gas and attached deposit and so on. But still if you don't attach enough tokens then your transaction fails in the middle and it cannot be recovered anyhow by any of the contracts that were uh that were mentioned in this chain of calls. And uh that that's why like uh they calculate every mill nanoton to to to to send over on the client. Uh and u like sometimes things can go wrong and that's that's why they just add one tone on top of every call just to like make sure that

37. 21:29

    that it will be delivered. Um so I think near is better in this perspective and also um another um different thing is that um um the wait a second uh I had something in in mind but I forget what what was it. Um yeah the the refunds and then okay never mind. Um yeah so the um what can can be done after we um approve this proposal. Um I hope we will uh is that uh first we can design

38. 22:20

    sharded D5 protocols and we we should start from a sharded funible token um implementation and um I've done some effort uh in this direction and um yeah I think it's here like the only the change in the nearest SDK um I've implemented only the nearest part but uh thanks to Jacob he was working on the uh new core part and the other crates that are um dependencies of both of them. Um

39. 22:54

    yeah so we start from shadow funible token there is already an implementation that I wasn't able to to to test because the near core is isn't ready so I don't know if it works but just based uh based on the code it should uh yeah um and what can come next is um I'm very bullish on this one uh so wallet extensions Uh there were a lot of talks recently about how we can um um enhance the account abstraction uh on

40. 23:34

    near and uh um for example near intense that's the one of the protocols on your blockchain it showed really well one of the reason um for it is that um it supports all of the wallets basically you can interact with this protocol and sign messages with Ethereum wallets near wallets but that's okay because near already supports those two but also Salana wallets tone wallets pass keys when you just touch the touch

41. 24:05

    ID on your computer and magically your intent is um applied so I think that um if we let smart contracts to um to verify signatures and keep track of the nonsense. Then it's much easier to upgrade just a globally deployed smart contract that implements some kind of wallet uh rather than asking for a protocol upgrade like for the whole new protocol. And uh this wallet contract it can uh support a lot of wallets from a lot of ecosystems.

42. 24:47

    And uh um it can have um like it will be basically a smart contract that implements this uh uh signature verification logic and non-striking logic but also it will be able to you will be able to install some arbitrary plugins. By just installing a plug-in I mean just whitelisting in like there will be a field in the contract in the R structure that defines the the storage layout of the contract. There

43. 25:16

    will be a field like um what what account ids can um send transactions on your behalf and then if you whitelist some account by default it's empty but if you whitelist some account ID and this account ID turns out to be another smart contract implementing uh social recovery function or two-actor authorization or whatever you can just nest these things and this creates a lot of um nice um improvements to the user experience and uh

44. 25:55

    yeah um but but in order to achieve this this will be achievable from day one except for paying for gas you will need some relayer so that you can sign um like if if we approve this proposal the NP616 You'll be able to write this smart contract, deploy globally, then u deploy per user um wallets that use this globally deployed smart contract and uh um how it will work is that you find some someone who the relayer who has the account on near

45. 26:39

    and uh it says that okay I will sign a transaction that will pay gas up front for your transaction only if you send me the signed message that uh shows that you will pay me back this amount of uh the am like equivalent amount of near that gas that I've paid for you. Um but uh relying on relayers is not the best like like it would be nice if we can allow for doing this without a layer.

46. 27:11

    For example, if this wallet contracts, I'm not talking about sharded funible tokens. I'm talking about like per user wallets like EOAS, but now they are contracts. Uh if this wallet contract just has Nero on its balance, then it it can pay for for its own uh transaction for its own gas. So maybe we can uh introduce also um some new kind of a receipt that doesn't have any predecessor.

47. 27:39

    It's like none. And um um what the validator will do is that it will um load the wasome contract the the the the contract code, load the storage um process this external call to this smart contract. the smart contract will verify the signature um increment the nons whatever and then it it will create promises to like call calls to other smart contracts and that's what the transaction begins with but I'm I don't know if it's if that's completely

48. 28:19

    possible in like current nearest architecture but um yeah but that's how things work in ton and um they showed really Well, because they can upgrade this um wallet contracts, they can introduce these nice features as social recovery, two factor authorization and etc. And uh yeah, I think like this is about the composibility part and uh um yeah um and what else? Um the collocation um um I I I had a lot of push back on that.

49. 29:02

    Uh so like uh Michael and Jacob uh were saying that Mir is designed in a way that it will never uh consider um uh organizing shards in some way that like that will never consider balancing all of the account IDs on shards in some way that some account ids are closer to to each other than other ones. Uh so I think yeah like it should be an NP problem to solve when you try to organize this graph where everyone

50. 29:37

    claims that hey I want to be close to this contract and this contract claims that like one at the time of deployment it wanted to be close to this contract and then you just start to think okay like even how do we design such an algorithm that does that but um that's just was my um suggestion I I don't know if it will be ever implemented But that might might be needed for um reducing the latency. So that every time that I send um like when I'm from

51. 30:10

    my um account like that I control on near when I interact with my third funible token wallet. It would be nice if this interaction doesn't take like a second but it takes less than a second. And uh yeah like if we could have located them on the same shard then it will be awesome because it can be even be processed in the same block I guess maybe I'm not sure about that. Yeah but uh again um this might be not possible because of the dynamic resharding thing.

52. 30:51

    Um yeah and uh the last but not least um there were a lot of talks about um about the storage model that is uh right now um used by near and uh um as far as I understand like there is an economic um how how do I say that economic mismatch because you pay only once for storing something for eternity which is not how the world works because usually you just rent some storage from big companies like Amazon or whatever and uh um there

53. 31:38

    are some blockchains that uh use this renting model for the storage um for example Salana and Ton as well and uh but the obvious question that comes to mind is that okay um if you want to pay like rent like let's say that once in several epochs we subtract from every account that is still active some amount of near. So what happens if this account doesn't have enough near to pay for its own storage and the idea is that um like the

54. 32:19

    same way that zero balance accounts exists you don't need to pay anything to to occupy 770 bytes then the same idea can be applied here that okay if your account doesn't have enough near to pay for it then let's say we're waiting for two more epochs just to give the user like enough time window to react on this. But then after some amount of blocks, some number of blocks, we say that okay, we hashed the state of the current state of the contract and we

55. 32:53

    put it instead of its uh current uh storage. So the storage now consists just of a single hash. Uh and uh then you you like and this account becomes frozen. Uh and what you can do to unfreeze it is you can pay near and get from somewhere the state and the validator will ensure that the hash of the state indeed is the same as it as the stored one and uh uh that's how it restores the state because

56. 33:40

    you now supply near. So that's that's also the idea. um um but it it's not directly uh connected to to this um entity. So um yeah, I think that's it. Um um yeah and one of the beautiful beautiful things is that the deterministic account ids are fully backwards compatible with existing ones meaning that you can interact from non-sharded contracts with sharded contracts and vice versa. Um yeah what else? And this

57. 34:21

    one also uh worth highlighting um when um like right now contracts can log some events like basically they are just bytes but then we have this uh format for events event JSON uh colon and then the JSON. Um, so when you build an indexer, this indexer tracks all of the events that were emitted by some specific smart contracts by some specific account on your but when you think about sharded

58. 34:58

    u contracts and sharded protocols then indexer it doesn't know what to track. It doesn't know all of the account ids that will be the ones who this indexer is interested in and um that's why all of the index indexing infrastructure should I think it should support the stateful like it should implement some stateful approach where it just has uh a forever growing map the sets of let's say we want to track funible token

59. 35:40

    transfers. So we want to track all of the mters that's the account who can mint some tokens and then all of the uh sharded funible token wallets the contracts that has um that have ever received these tokens because then you need to in to to index them because they might send to some some other contracts and you just add them to the set of all of the contracts that you need to index in order to just

60. 36:10

    keep track of all of the transfers of uh some particular token. Um yeah, but I think it's unavoidable even like it's not about this proposal. It's about shed contracts in general like if uh if you have just uh like your functionality is of your protocol for example the funible token protocol standard of the token if it's just um distributed across a lot of contracts and you don't know which contracts will

61. 36:44

    be created then you don't know which contracts to track the events coming the events coming from which uh contracts. Yeah. Um and um what else? Majority of these questions were resolved in the comments. Um the unresolved issues. Um I'm not quite sure that uh the refund mechanism is very flexible in in the in this NAB. I think it covers like the current needs but I'm but but we haven't built a lot of D5 protocols with that and basically not only D5 protocols

62. 37:30

    but sharded uh standards with it. So I might be wrong this that this approach of um refunds will be like sufficient enough for all of the use cases. Um, so maybe some someone here can raise their concerns about the refunds part, but it's like compared to other approaches when you call some function in order to refund. Uh, this one is much easier because it has the gas guarantees and um yeah, so yeah, I think I'll stop here.

63. 38:10

    Sorry for taking for too long. Uh, 40 minutes. Wow. Um, yeah. Uh questions, comments. I don't know that how is it supposed to go. Yeah, next step is going to be um so we don't have everyone here, but uh we can kind of do initial feedback and uh vote if you're able to then obviously the rest of the votes can be uh offline uh asynchronous.

64. 38:40

    Okay. I I thought the voting uh like is is this the voting or no? Yeah, I'll uh I'll speak briefly as I guess the only present uh working group member here. Um yeah, so the voting indications there I think I think are um the voting indications that we we would expect. Um if if Marcelo and Bowen were here, like I think they would vote yes.

65. 39:16

    Um so I think I think it is okay to take those as being legitimate thumbs up for the purposes of of the process here. Um obviously mine mine might as well. Um and um we didn't end up hearing from from Marson um which is not strictly necessary. I I believe we we do just use uh majority voting here. So uh three out of four is enough sort of regardless of what Marson ends up voting uh to to pass this. So that's that's exciting. Um you know officially I think this this does

66. 39:48

    mean that it does pass. Um although I I would be interested in in getting some feedback from him. he normally has some some pretty thoughtful insights um and you know sort of polishes NEPs in a nice way. So so if we if we could uh do that before this is all finalized and shipped I think that'd be cool. Um you know pending his availability obviously.

67. 40:13

    Um the only other comments I want to make about this because like we we did sort of have um an async discussion among members of the of the working group uh last week uh slash earlier this week and um some things that that were that were being raised about this are it not being particularly Nearesque, right?

68. 40:38

    the way the way that this works, you know, ultimately like one of one of Nar's primary features is the named account model. Um, you know, having these these nice human readable names is is useful. Um, but the the sort of counterargument is that the sort of useful human read human readable information is present just not on the ID itself. Right? the idea sort of a hash of things that could be presented

69. 41:08

    in in a nice human readable way. So, uh I think given that this is approved, we it would probably be nice to see um some work on the explorer side of things to be able to expand, for example, what the state init details were for a given deterministic account ID. Um, and that that would go a long way in into making these things a little bit a little bit more friendly to to look at just from a from from a user perspective because obviously like the the elegance of capturing the

70. 41:46

    um code plus initialization in a single cryptographic hash is is great for for a protocol like that that works really nicely. It works really great for contracts like you were saying the at the start of Cine um confirming that they they're they're running the things they expect and that they can trust each other. Um that that's all that's all excellent. The backwards compatibility

71. 42:09

    of this also an excellent uh feature that the original sharded charted contexts uh was a little bit less good on. Um, so yeah, all all of the positives we we agree as a group do outweigh the sort of I guess um again non-neerish nature of of the thing and and again can be made up for by some work on on the explorer side. Uh so I think that would be cool. Um the as as for some of the stuff you you mentioned at the end about you know uh shard dynamic resharting versus close to

72. 42:47

    and sort of storage work etc. I think I I think those are going to be those are discussions that have been ongoing for a long time and I think will continue to be ongoing for a long time if if we're being honest. So you know looking forward to continuing those discussions with yours. Um obviously you know you getting involved here with determinist deterministic account ids for pushing forward uh charted contracts was was great. So yeah having you involved in in

73. 43:13

    future discussions about you know how storage evolves or or how dynamic reharting evolves would be would be cool too. Uh so I think that's about it from my side. Again just to summarize this is approved. Yes. Exciting. and um we'll we'll try to sort of polish up some of the the last remaining open threads, but um it'll it'll go through.

74. 43:39

    I I also wouldn't mind, Jacob, if you have have anything else to say uh hearing from you from the implementation side on on the nearore side if there was um any sort of snags that that came up during your implementation work that maybe need to be addressed here.

75. 43:54

    Yeah, sure. So just briefly for context um so I've I've been working on the nearore side implementing this I've worked on the previous proposal as well together with aki and a lot of other people that were involved and we were basically ready to finalize this shorted context implementation when rseni came in with this in my opinion strictly better proposal to solve the same problem and uh we super happy thanks a lot for coming in just in time and

76. 44:25

    It it it took a bit for us to understand that our previous proposal wasn't quite as good because we were kind of already ready to ship. But now I've also implemented the second part. Um again many people have been involved in in the design. I've just kind of written it down in code and then made sure it actually works. Now comparing the two side by side because I have both full implementations I can say this is a much smaller change to the protocol

77. 44:57

    um which is really nice. The the actual deterministic accounts is like a super small change. It's just a verification on transactions change. So we have a new type of action that comes in and we have to verify that this is correct. The execution is pretty straightforward and when we execute we don't even have to do any checks because we all do it on the sender side.

78. 45:20

    Um so this is pretty nice. Um I think the only condition where the execution can fail is if there's not enough storage. And yeah I'm not going to open that whole discussion again. Storage isn't ideal but um maybe future changes can make that work. But right now we just keep the storage model as it is. And I think that that's great. We really have to like the small change in deterministic accounts.

79. 45:50

    What's worth raising is that the most most of the actual changes we have in your core now are related to the host functions that we're adding that go along to support this uh feature. So in the past we often had like specific NEPs just solving one specific feature and then if we needed something to support that would be like a separate NEP. Here we we have this all together and I like this approach. We have a a goal of what

80. 46:20

    we achieve and we bundle it all together so that it's actually useful. I think this is because our seni has like a good view on how to actually make things work rather than just a protocol view of like where do we have to pull which which lever. Uh so this is good but it means that now we have lots of changes specifically around the refund to um host function which redirects how uh after a failure the refund of that attached balance where this is

81. 46:55

    going to go and I think we need it I'm not going into technical details it's it's important to make this feature work but this actually needed required us to change the action received structure which is something we have never changed ever since the launch of Near. So it's like the first time we introduced a versioned field of that and there's like lots of of code changes and Anton who's

82. 47:19

    also in this call has already reviewed it and and we have tests for it and like we ready to ship this but that's probably the most interesting thing I can add at this point. um this is what caused the the biggest changes to the protocol in terms of actual code changes and the feature itself is really small and I think that's just a good sign.

83. 47:43

    Everything else is just sort of um our protocol showing that it has sort of holes that we need to fix and we are fixing all the holes that are specifically needed to make this work and that that's just naturally additional work.

84. 48:01

    Um by the way can we add an get refund to account it function as well? Can you Yeah, the explaining what you mean. Yes, there there was uh a question from I I didn't remember the the name of the guy. Um the first the first reviewer um so he he was asking about the init function instead of init storage and uh then I realized that some smart contracts might want to understand what account ID will the funds go if it

85. 48:45

    fails. And we can use this refund field that is set for the current receipt for all of the refunds because otherwise I I would need to duplicate this information inside of the payload that I'm sending to the contract while like it seems that the majority of the standards the contract standards that will evolve will likely need to refund to the same accounts uh that that near will be refunded in

86. 49:23

    case of failure or in case of already deployed smart contract. Uh yeah, so maybe we should get it as well because it's relatively small change I think as well. Okay. Yeah. So, are you asking that a smart contract should be able to look up what the predecessor sent the refund to field so that they can kind of forward it again?

87. 49:49

    Yeah. Yeah. This might be useful if if the contract itself wants to do some refund logic from from its execution. So, I don't know. Yeah, I think that makes makes sense. It's not included right now. It's a easy thing to add. Uh if we add it, I would ask you to also add it to like the N proposal. So it's kind of all written down there. Um yeah, from my side it makes sense to add, but probably should

88. 50:16

    be like written down and also people are not in the call can kind of raise concerns if they have it. Yeah, from my point of view technically makes sense and I I would also vote for doing that if we can. Cool. And by the way, answering Michael's question about not nearish account ids like the near near account ids were uh like it was possible to to have them named.

89. 50:46

    I think names should be implemented as NFTs like the ENS service. Uh the same way how it works you just create some NFD collection that is near and uh you you let others to derive to to create accounts and to to transfer ownership of these accounts and by the way this can create a market that you can sell your name and you can buy yourself a name. Uh and um yeah like uh um it may be easier for the developers to to understand these names but still

90. 51:35

    where the developers not not like grandmother will never use near CLI to send funds to USDT. tether token. Uh she just sees the wallet application on her uh on her phone and just taps confirmed. Um so I think yeah that's like we are going away from from named account ids but I think it it can be still implemented as an NFTs and uh um we don't lose anything by that.

91. 52:20

    Well, yeah. I don't want to um throw the conversation any further. There is actually a service that you can buy and sell near names already. Uh because the near name is a contract. So there you can actually do that. There is it's been around for a little while now. I forget the name of the website, but you can actually do that on near. Um, but it means that I'm also selling all of the tokens that are owned by this uh account ID, right?

92. 52:44

    By the contract. Yeah. Yeah. Yeah. Yeah. But what if I am a member of DA? I can't really sell my account like name because right yes those scenarios correct. Y totally cool. Um this was great. Uh if there no other further questions um I think we've come to resolution. So this is approved and those steps are are there uh for again for posterity sake um this will all be listed here and we will

93. 53:18

    have we publish this video uh as well on the on the YouTube account. Uh Jacob one thing I want to guess make sure we we kind of finalizing this call. What is the prefix for account ID is going to be? We have zero s in the proposal. I've implemented this way. It seems fine to me. Uh maybe Michael, what what did the the working group say? Uh what prefix should we use?

94. 53:43

    Uh we we didn't we didn't bike on on the prefix. So may maybe we should have um zeros sounds fine to me. Like S for sharded, you know, whatever seems seems okay. Um I guess um yeah, I it's already implemented that way. Let's let's stick with it. I don't I don't see a reason why it shouldn't be done that way.

95. 54:06

    So yeah, that that that seems okay. We'll we'll just agree to it now and you know, anyone else can uh forever hold their peace because they didn't show up for the call. Yeah, that's fine with me. Anyone I I talked to was like, "Yeah, it seems important, but actually I don't care.

96. 54:21

    Like it just has to be unique." Um so yeah, okay. If we It was there out for long enough. I think nobody had a very strong opinion. So let's go with Zeros. Um yeah, fine with fine money. And one more question. Uh what do we do next? Like uh there there is still a bunch of uh I I didn't resolve any of discussions because I think they're important for people who who are reading this proposal. Um and uh like most of the discussions were resolved. I like

97. 55:02

    from from my perspective uh we came to a conclusion on each of these questions. Uh but um uh like I understand the part about uh adding a new host function get refund too. I I'll do that. But should I change anything more in the text of the NEP or uh um should should I remove these for example unresolved questions?

98. 55:32

    Um yeah like uh yeah anything that is now resolved I think you should remove from or like maybe not remove um but like add what the resolution is or like maybe change the heading to you know I don't know discussion questions or something and yeah we we we we do want the final NP to be in a form such that it is good enough to be a specification if someone else was building another

99. 56:02

    near client, right? That that is that is the the standard that we that we want to hit. Some of the nps do better than others. But yeah, if if um if it has all of the details necessary for someone else to do the same implementation that Jacob has done, uh then then it's complete.

100. 56:20

     Yeah. Cool. And so I'll I'll rename I don't know remove some of these issues. But if we go one by one, did we answer all of them? Like the zero balance accounts, I get it. Like if the account is less than 770 bytes, then it's a zero balance account. All right. So non-refundable storage staking, we don't do anything about it, right?

101. 56:43

     Because it was never implemented, I think. Um yeah uh forwarding amount from state action as a touch deposit into later function calls instead of refunding this immediately. the like this happens um for example I'm I'm initializing the the SFT wallet contract of the receiver and I'm putting there like let's say let's say we don't have zero balance accounts uh and I'm putting there 0.5 m near and then it turns out

102. 57:14

     that is already deployed but what if the function call that happens after it's like receive and then it notifies the receiver. What if it it would be grateful if it can use the amount that was attached to the state in it instead of refunding the the um the amount that was used before the insulation back to the refund to um set it on the uh that was set on this receipt.

103. 57:52

     Do you understand the what I'm uh asking about, Jacob or Michael? Not quite. I I think I understand what you mean, but that that sounds complicated. I I I think I think it is better for the protocol if if actions are for the most part atomic as in like they they are self-contained. They do what they do. If you have actions that are influencing future actions, I think that that can can create some

104. 58:24

     potentially unforeseen consequences in terms of spooky action at a distance kind of thing. Um like where do these tokens come from? Who knows? Yeah. Yeah. Yeah. I agree because you don't know whether this contract exists or not. That's why you're attaching the states in it. And what if you you wanted to swap near for something? Then then you're just adding more near, but you're

105. 58:49

     expecting the same output. So, exactly. Yeah. Yeah. All right. And the last one, refunding via uh plain native transfers. Uh so I think we agreed on the fact that refunding with a function call like when you actually call some smart contract with a spec special function re uh receive refund uh that that seems a bit weird, right? Like uh or non-determin like it's it doesn't have the gas guarantees.

106. 59:21

     uh it's more complicated and the and and we don't know how to how to um express that this particular action failed. What you you should forward back all of the arguments of the function call name all of the arguments that that was supplied to it so that the contract that is handling this uh this refund can act on this. Right? So it it seems also complicated. So do we do we drop it here? Like just no.

107. 59:57

     Yeah, I think it's better if refunds are are simple simple transfers. That's that's already how how refunds currently work. Um it's better to keep it consistent. Uh and and again, it's also complicated from from a security perspective, right?

108. 1:00:16

     This is a a problem on on Ethereum endlessly, right? Where you can trigger logic by sending tokens like being able to do that is uh an an additional piece of complexity that that often creates security issues. So I think not being able to do that on near is is generally speaking a good thing and and I think that should be true of these refunds as well.

109. 1:00:39

     Okay, good. Um and one more question to Jacob I think. um when you're uh I I I think there there was a proposal that reduces the number of re the refund receipts because you process gas refunds and failed promise res uh refunds in this in a single receipt. So now did you decouple them? uh and like the question is what if I am paying for the gas and the set refund to was used in some sub some of the subsequent calls between the smart contracts and then some of the

110. 1:01:21

     part will go to this smart contract that claimed itself as a like passed itself in the set refund too but the cast refund will will be given back to me right or or no like how does it Yes, what you described that that's how it works. To elaborate briefly, there there was this recent the change that reduces gas refunds. Uh it it tried to do it in two different ways and one of them was retracted.

111. 1:01:51

     Um the one that's remaining is we no longer try to like we we changed the gas price that we used to charge at the at the moment of execution and previously we were like attaching more we purchased gas at the higher price than it was right now to accommodate with the fact that during execution gas prices could go up. So that's more near token per gas unit and that meant that in most cases it didn't rise or it didn't rise as much as it could have. So in the end we paid too much for gas and we had to refund

112. 1:02:32

     that difference. Now we just say well we just always use the gas price of the start of the transaction and then we don't care about this increase and therefore we don't have to do all these gas refunds. Um so that's kind of unrelated to this change.

113. 1:02:47

     What this change however does is it increases the number of refunds which is counter to what we wanted. Uh so we have a new way of making refunds and that's after trying to initialize uh deterministic account ID when it was already initialized then we will refund the the balance that was attached to it.

114. 1:03:13

     Um, I discussed it with a few people. Nobody seems to think this is a big problem primarily because we're actually going to pay for this refund. Whereas the refunds that we removed, those were kind of for free. So, they were like the gas was for the refund itself was purchased just the price of zero. So, we subsidized it for no good reason.

115. 1:03:37

     Um whereas this one we actually pay for it in in gas fees by the people calling it. It's a significant amount compared to like the full cost anyway. And I think there's not much to be complained about. Sure, we could make it slightly more efficient by not having this refund, but it would be drastically less usable.

116. 1:04:00

     So if you want to have this lazy initialization, you should also pay for the you should also have the ability to refund. So, lots of extra information. Did I actually answer your question or set? Yes. Yes. Thank you. All right. So, we're good. I think all of these are resolved. I will clean them or maybe I don't know maybe maybe provide the answers like uh FAQ section frequently asked

117. 1:04:31

     questions. I don't know like I'll do something about it. All right. Um and uh and after that uh like this will be considered as ready to be merged or what and then we can start to work on the shed funable talk standard right. Yeah. So from my point of view these things can kind of overlap a bit. So please clean up this NMP, make sure it's in a final state so that we can like archive it and people can have this as reference for for what it does. But we will already after we have like official

118. 1:05:11

     approval, we will start actually merging this into near core. The goal is to have it all in by the end of the week and have it ready for the next release cut. Uh that would be awesome if we can get that done. It my opinion it's okay if the NP is not merged by then yet. there can still be some sort of ongoing discussion and potential changes but like we know what we want now so we can actually get it shipped and then the

119. 1:05:36

     next step of actually making the contract standard which needs to be built on top I mean it has already started discussion and you can already start writing things more down and yeah so there's some overlapping here um from the process itself on the NP when it's merged I think maybe yeah people other people should comment on that but from implementation point of view I no longer have a blocker I will just get it done as soon as possible.

120. 1:06:08

     Nice to hear. And the final question for me is that uh in the NAP itself I have I have a lot of links to as you can see in the in the bottom left corner uh to the my draft pull request in near SDK RS. Is it a bad thing to like and you can you can see there are a lot of links like is it a bad thing to to have and Should I just remove them or just keep them because someone can just understand what I'm talking about? Because the the

121. 1:06:46

     the the pull request in your SDK it it's not in the in the state when it can be merged. You see, I I think it's fine to keep it there. Just please don't delete your branch. uh it it does have like the Git hash and all so you can't modify it but um if you delete it that the link will be dead and usually what we do in that case is we use the internet archive to to find it and maybe add that link but I don't know

122. 1:07:22

     maybe someone else has a strict requirement but I think don't make your life too hard here. Okay. All right. Thank you. Uh I I I I'm don't have any questions left. Right. Awesome. This was a great presentation. I appreciate everyone's time today and we will see you next time. Great. Take care everyone.

123. 1:07:46

     See you. Bye-bye. Thank you everyone. Bye.