NEAR Live Contract Review | Episode 3: Whitelist and Staking Pool Factory

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

1. 0:02

   hey hello everyone uh today we're gonna review two contracts instead of one and we will include uh contracts that involve cross contract calls and talk about promises and how they work at near soon if you want to learn more how composibility works this is a good session to watch so let me present my c11 tab all right so today contract first contract that we're gonna take a look is called a whitelist contract and it is used on the mainnet

2. 0:52

   to whitelist staking pools and this is important for the reason that um the distribution of tokens was done through smart contracts and um we use lockup contracts that we'll eventually review in this series but um the way it works the lockup is a standalone contract that holds tokens that's supposed to be for example released over a period of time so let's say the tokens are released over two years and linearly getting allocated every block

3. 1:38

   so what we wanted to do is we wanted to give an ability to stake these tokens including the tokens that are not released yet which means you should be able to delegate all of the tokens that you have locked for for example two years and start earning rewards on them this is done on a smart contract and a lockup contract essentially calling a stake in pool contract that we reviewed before and transfers tokens from one contract

4. 2:18

   to another and contracts or the tokens from local contract leaves the the account and go to the account of the staking pool so if a staking pool doesn't provide guarantees that are required such as you can return these tokens then it means let's say i build a customs taking pool that allows me to not only stake them but also withdraw them to any account then this type of operation will allow

5. 2:58

   you to get liquid assets before the release period ends so you will be able to strong and this is not the desired behavior that's why we introduced the whitelist where custom implementation of the staking pools that are approved by a near foundation can can be used by lock-up contracts at the same time we wanted to give an ability to create news taking pools that are already approved by anyone

6. 3:40

   without going through approval from near foundation this allows anyone to create a new staking pool through a stake involved factory and a stake in pool factory is the second contract that we'll review today so the way it works is when a lockup contract wants to delegate before they can transfer funds out to this contract they first need to select a staking pool when you do a select staking pool lockup issues a transaction to check if a given account id

7. 4:17

   is whitelisted in whitelist contract and if it's returns true which means the account is whitelisted then the lock-up contract can continue with delegation so it allows the lock-up to actually transfer to this contract it means that the remote contract the staking pool country has some guarantees and apis that the local contract expects and it's not going to lock tokens of the owner or steal tokens from the local contract

8. 4:54

   it also was important for um investing schedules of employees of near inc it was on like four-year resting schedule and that allowed to in case an employee leaves the job or was terminated allows foundation to issue a specific transaction to the lockup of their that person to unstake everything from the stake and pull these drivers and from the sticking pool and return the invested amount back to newer foundation

9. 5:34

   so that's the background about lockups and whitelist so let's look at the whitelist country it's actually a fairly simple contract and it doesn't really have a lot of logic and majority of stuff we already know it uses a new api that called the lookup set it is similar to an ordered set it's a persistent collection but it doesn't have iterators so you cannot iterate over the keys or of the values

10. 6:09

    elements of the set you can only check if a given account like you give an element is present or not present and you can add it to the set but you cannot check what elements are present in this set and by doing this it improves the efficiency of storage and access from multiple reads to a few reads so the contract contains um a few fields first the foundation account id this is the account id that controls the white list it means

11. 6:50

    this account can whitelist uh stacking books by one and also it can white list stake and pool factories so the factory is a contract that can create a new staking pool instance um the way it works is the when you issue a transaction towards the stake input factory that is whitelisted by this contract it creates a new account as a stab account of the factory in our case on the mainnet it's called pullv1.near is the

12. 7:40

    stakingpool factor that we use and it creates a contract so for example bison trails dot pool v1 dot near on which it deploys a valid staking pool a white list is taking pool code that this factory can produce and we'll go into factory later but at the same time it also can white list this given um stacking pool so here's how it works um the contract has insulat initialization which only takes a

13. 8:21

    foundation account id now a foundation has a higher permission on this contract so there is a bunch of getters so you can check if a given stake input is white listed so this how lockup contract checks if the pool is white listed it basically just check if an element is present in a set and the second way it also can check if the factor is white listed so this is not really needed

14. 8:51

    and no one calls it so this is a method that can be called both by a factory and by foundation so what we do we check that this taking this method adds a new stakingpool account id to a whitelist it checks if the account id is valid then it's cool we check if this is a factory so we check in a set that the color of this method is present in the white list of the factories so if if it's called by stake input factory

15. 9:41

    then it's okay if not then it has to be a foundation account id otherwise and the contract will fail and this method will paint if we pass the permission check then we just add this taking pool to to the white list can i ask a question um i guess it's kind of interesting to me that there are multiple factories i was kind of thinking would there be one factory is that big for sharding reasons or what is there a reason for that so right now we have only one implementation for the staking poll

16. 10:21

    but in theory we can modify this implementation when we introduce for example slashing and a staking tool has to um has to have a permission well it needs to maintain some minimum balance it's some other change that we need to modify a validated contract so over the investing period of like everyone which will in place is like four years a lot of stuff can happen around the network and we need to have an ability

17. 10:54

    to change the um change the staking pools potentially so if a logic of state input changes that's right it allows for kind of like upgrading all right it allows kind of like create a new factory that is like a better version or like it supports something that was not supported before maybe it not allows to change a reward fee um instantly but only allows it to change after like a seven days period waiting period or some other idea on the

18. 11:36

    modification and that will be a different factor so remos removes taking pool can only be killed by the foundation um and factory can also be only called by foundation into basics just adds to a white list of the factory accounts like this and remove factory also only by foundation and removes the factory account id so let's say the first factory expires the foundation can basically

19. 12:11

    remove the factory from whitelist as well as remove all the previous pools from the whitelist so now you will not be able to select one of the previous taking polls from a lookup contract and finally just a check that this is called by foundation which is a comparison so this is a very simple contract and it just operates on internal sets and the only like true method that is visible by outside is is this uh they can pull whitelisted

20. 12:55

    and there are some methods that were called by foundation so foundation actually probably you should only one call and this is to whitelist the factory and it didn't do anything else okay so this whitelist contract any questions on a whitelist country so it's doesn't have any cross-contract calls it's fairly simple just a bunch of setters and getters these permissions i've got a couple questions here okay um so one thing that i've been looking at or looking for

21. 13:36

    is where does the model of application development on uh near or in general on blockchain applications differ enough from you know web development or whatever where somebody would be surprised what you just said about like mike's question and your response uh what would be surprising for a web developer that you need to think about the lifetime of this application measured in you know the life of the constraints of the users and their investing schedules which could potentially be like four years is the case that you just you just presented right that

22. 14:15

    you wouldn't think about a design having to survive versioning uh intact over that many years you would you would just think about swapping out the existing code base or whatever and that's a big difference in what we're talking about so have you had have you here's my question have you sort of um do you have an intuition about this or have you kind of figured out like what are the the triggers in your mind when you're designing a contract

23. 14:46

    that make you stop and think um this is immutable you know for some period of time or whatever the constraint is do you have like a way of thinking about this that you could share that that's explicit i think that's what i'm asking well the way smart contracts usually behave which is not true on the theorem on a bunch of them is um they are immutable on itself well on ethereum every contract

24. 15:17

    interior is immutable but they use a proxy contract that allows to upgrade the endpoint um for certain contracts that are very critical to tokens like in this case our core contracts essentially they are completely immutable and we think about them as we will deploy them once and likely you'll not be able to change them because otherwise you'll have to do a hard fork and convince all validators to do some type of code migration so

25. 15:59

    it is important to because the control over them has to be done on a contract level instead of on some centralized entities so for example while foundation still maintains large control over the staking pose here by having ability to remove state imposed it doesn't have a control to blacklist particular um entity in real world from deploying a staking pool so they still can create

26. 16:37

    a stake and pull as much anonymity as possible and create without asking the permission to become a validator on the mainland so something comes from decentralization the other comes from limitation over the control of the and the trust towards this so while foundation is supposed to support the network it's possible that in some scenarios the foundation can be forced to do something bad for the network let's say government

27. 17:17

    comes in and like tries to force them if they have less ability to do this then it has a higher security over the network so when we design a contract we think okay what is the like um i would say either the amount of value in this country or the ability of this contract to influence the the network in general so if it's a small value then it's okay to keep the credibility so long as the community trusted if it's a large value then it's not okay and when we actually

28. 17:59

    gonna get to look up contract and the way it's designed you can see how for example a vesting was designed to on one end allow foundation to actually um withdraw the remaining funds but at the same time prevent the foundation from withdrawing the vested funds so it's kinda like a legal way of doing things except written into the code so whitelist is very critical contract because it allows um people to before the funds are locked um

29. 18:51

    majority of funds are kind of controlling the network through local contracts into staking pools through this particular white list so it was important to design it in such a way that it keeps decentralization and security of the network without giving control to the foundation as much so that there's some logic and you potentially like let's say something happened and foundation becomes acting maliciously let's say

30. 19:28

    you were able to create and use taking pool through a factory and delegate to the staking pool now the foundation cannot really prevent you from delegating to this taking tool i don't know if i answered this question but let's uh move on to the more technical discussion yeah that's great i appreciate the answer okay so so this is the white list and essentially what we care about

31. 19:59

    is the interface um recently we had a talk and like how to do this better so ideally you just expose a trade for the methods that you think are going to be called by the other contracts so his white list is one method and then um at stake and pool is another method a change okay so the stake and pool factory contract is a contract that's internally internally has the code of a staking pool contract in rust you do this

32. 20:44

    you can do this by using a macro include bytes it basically takes a file a local file and embeds it into the binary as a vector like robots vector so what happens there is within this web assembly binary we can have some piece of memory allocated which represents a binary of this particular staking pool okay so let's get back to the top um so this again the structure there was some information about the gas

33. 21:34

    we'll come back to this later um there's a rewards fee for action that's just copied from um from staking pool contract that we reviewed before there are the arguments of taking pull that it takes and there's a trades and external contracts so this is the high level interface that we use to call certain contracts we have two of them first is it can be any name we call it excel because it represents

34. 22:16

    our own contract and it contains a callback to to a method on stake input create and the second trade is for a whitelist contract that we just saw called adds taking pool so here it is that's taking pull exactly the same interface except um the trades in rust are like interfaces in like java for example and we just define the interface of a remote contract so let's go first through the scenario so when staking pull

35. 23:07

    first insulation of the factory when a factor is created we verify that it was not initialized and we verified that the white list accounted you so we take the account id of the whitelist contract during the initialization of the stack input factory we need to know the whitelist account id or whitelist taking bull whitelist account id this is where the whitelist contract is deployed in order to whitelist our newly created

36. 23:40

    staking tools the instances of the sticking pool so we remember this and create also a set of already created accounts there are a few getters and the main the way you enter this contract you have us now now that's taking pool factory is created it's called pool v1.near for example and foundation white listed the factory on a white list contract by issuing another transaction so now this pool factory let's say is white listed

37. 24:20

    it means it has the permission to white list the new staking pools that it creates so now a validator comes in and they want to create a stake and pull for themselves the way it works they call creates taking pool and it takes a bunch of arguments so first argument is a prefix let's say it's a bison trails without suffix of this current account id and this is comes from account names of near so account can

38. 25:09

    only create a subaccount or very long account so stake input factory creates sub account under itself so it will be bisontrails.pull v1.near so in this case this will be bison trails owner id is the account id of the owner of the staking pool as we discussed before so all these three items are essentially arguments that you would pass to a staking pool when you first create it

39. 25:49

    so it's an argument that you can approximate towards the staking tool so for example this can be bisontrails.near this can be their staking pool or this taking key from running a validator node and some rewards for example 10 percent note that this method also payable it means it takes incoming attached deposit and the first thing it does is say like hey did you attach enough deposit

40. 26:23

    and the deposit that you need to attach is certain year so this has a lot of zeros but this is because it's in your 10 year so you need to attach certain year and mostly because you need to cover the state for the contract itself on the stake on a newly created stacking pool so the contract is fairly large it's 250 kilobytes and you need at least 25 near for this but also it takes some extra money to cover this um price guarantee font and stuff like this

41. 27:10

    this is actually a good place to point out i know i've heard before on discord and from partners who are confused why you cannot just add a lot of gas in certain cases and this is one of those cases i believe where like you you do have to have an attached deposit because you cannot attach this much gas to this transaction so this is a really good example of all right also also we cannot convert gas to near um

42. 27:42

    within a contract so gas ideally separation stays the same it's only used for computation and some write read operations and cross contract calls and balance is used for state storage and transfers so in our case this will create a new account and creating a new account on year requires to pay for the storage of this account and storage in our key is going to be not only the account itself but also the contract of this account

43. 28:23

    and in our case this is the um well um this is the code of the staking pool contract so next thing we do we verify that the prefix doesn't have a dot it means it's not a sub account itself then we create a new staking pool account id by concatenating our account id without this new prefix and we verify that the news taking pool account id is valid so basically if any of this a third fails the near protocol will refund the tokens

44. 29:16

    so if a transaction fails with attached deposit the attached deposit will go back to the sender to the predecessor because only predecessor can attach a balance so that's safe to do like a bunch of asserts in this type next we verify that the owner id of the staking pool is valid this is basically just a bunch of extra helpers that are also verified on the staking pool and to make sure if you

45. 29:55

    pass the correct arguments or slightly incorrect arguments you better fail early before you do this trying to create to avoid burning gas and locking the tokens that you spent finally we check using insert that the staking pool doesn't exist so basically insert will return true if it's a unique new unique element and return false if if the element already exists in a set so this is how rust headset

46. 30:42

    works same way an ordered set works so if the pool name already exists we will not add this taking pool or try to create this account again and now we can insert for that so insert does two things it adds this element to the storage as well as return true if the element is unique and didn't exist before or returns false if the element already present so it looks like that no op in this case

47. 31:27

    it's uh i think cross does this it's for not sure which other language has similar epa so we can go to for example hashmap to see what adds a value to the set if the set did not have this value present true is returned it just said did have this value present false it returned finally we use um somewhat not the highest level api but the somewhat like a medium level api so we don't use our raw cost methods but at the same time we

48. 32:20

    don't use high level interface like this so the way it works we create a new promise so this creates a temporary record temporary structure in our newer sdk and it remembers the receiver of this promise so you can think about as this method gonna issue a transaction towards or this contract will issue the transaction towards um that given account id so we will call non-existing account id is taking pool account id

49. 33:01

    of course it's not a transaction but a receipt but it's a technical detail next thing you say this is the first action on top of this promise so we start batching actions into this promise first action is create account so this method or this action will create a new account or it will fail if account already exists then we deposit the attached balance so we deposit entire deposit that

50. 33:31

    was passed to us so we don't keep it in this factory and it will go with this same receipt on the remote account next we deploy a contract as i explained uh this is a macro that pretty much creates a static slice which we convert to a vector that will pass to to a deploy action so this will deploy code on the remote account you can only deploy a code on the account you control but create account gives you permission for

51. 34:22

    only this particular transaction to act like your owner of this account so you can do deploy contract and you can do stake for example and some other stuff on behalf of this contract in the first transaction that you do finally we initialize the contract the stake and pull contract using uh serda api so we take this structure and we serialize this into json the method name called

52. 34:55

    you the first argument is the attached deposit to this function call so we don't need it because it doesn't expect it and next is the amount of gas that you take from your current amount of gas and immediately like take it out and kind of say it will go to this promise so let's say our method was called this hundred tera gas tear gas is a kind of unit that is roughly human understandable so you have hundred tera

53. 35:31

    gas when you entered and we say beginner pass base multiplied by two bases 25 tera gas so we will pass immediately 50 tier gas to to the function call of this method so this 50 tara gas is um so it means we only left with less than 50 targets because we already burned someone some logic before plus every action that you include into this promise will also cost you some gas and for

54. 36:14

    example a deploy action cost you to transfer the bytes over the one chart one account to another so finally uh we use then then is similar how like javascript works it creates um it attaches the dependency on a promise before so ideally we should say like okay finalize assumption but we don't have it because it will happen afterwards so think about this as this is the first promise and we say then once it completes

55. 37:05

    do this the second promise um so the way it works is you called let's say let's use bison trails example again buy some dot bisontrails.near called this contract pullv1 dot near to create bisontrails.poolv1.near we first create a promise to bisontrails.poolv1 dot near and then we attach a callback to this api is not great in terms of it uses positional arguments for two different things but it calls ourselves back the current

56. 37:57

    account i did so it will call pullv1.near after this promise has executed so let me just write this in comments so buy from trails but near calls pull v1.near the method create taking pull blah blah blah now this method um creates a promise to it creates a promise to buy some trails 2v1 dot near this like multiple so let's just call it like this and it also creates a promise to itself so

57. 39:09

    on the method on taking pool but this method depends on the callback from bison trail cell so it needs it needs a result of this method before this method starts and it passes three arguments here it passes the staking pool account id it passes the touch deposit and predecessor account id so who called us um what account tried to be created and how much tokens was attached in case we need to do a refund

58. 40:06

    now if this is successfully executed then this method will receive a result of execution saying it was success if it failed to execute let's say there was some misconfiguration that this method will also be called but will receive a callback saying it failed okay so and we returned this promise after then it means we returned not this promise but we returned on stake in pool create now why it's important is because

59. 40:57

    now this method result depends on the result of this promise so the transaction doesn't completely starts in parallel instead it now depends on execution of this particular method does it make sense so far yeah i think so um one thing i think is that's interesting is that first when you highlighted the first promise the create account transfer deploy contract yes that is an example of a batch call right right so yeah if there's like confusion about terminology like that's

60. 41:44

    a bash call but there's also a promise so if any one of those actions failed then it would revert yes so entire thing going to return failure to to this promise but this promise will still be executed if this is scheduled and started to execute them so let's look at the callback and um there's a callback basically a method first thing we do we say that it can only be called by current contract so

61. 42:27

    means no one else can call this promise because technically because it's technically public right so people can't technically call it but then that's how you check to make sure that it's not yes anyone else next thing we do we use another utility method helper method same is the dependency that the the creation of the sticking pool succeeded or failed so we do this the following way we use two end methods first to check that number of results is one

62. 42:58

    this is invariant you because we already know that no one can call this two and second is if the result is success and um so yeah if if the method executed successfully then we return true if the promise failed to like then it will be false so now we know if the staking pool was created or not and we have logic so if it was created it means it was good so we continue so again we also attached 50 gas to the callback so now we are in

63. 43:53

    callback it means we only have 50 gas 50 targets if we succeed then we'll log in okay the pool was successfully created let's whitelist it we call another promise from a callback and attach 25 tara gas so now we call stake and pull whitelist account id so the whitelist contract we call the whitelist and say hey now you can whitelist the staking pool that i just created because i pass this argument in towards the callback and

64. 44:40

    we return this promise so we don't stop the execution yet because we want to only complete the entire transaction once the white listing completes so raz doesn't have a return because if the last value without demi colon is given then it's a return value and if the creation failed it can fail for i assume only one reason is if you put invalid reset the key or restrict the key as we discussed

65. 45:21

    briefly before so if it's like some weird curve that you created your sticking key then it will fail and the reason how it fails is it means the deposit that you passed to the staking proof of creation will be refunded to us not to the predecessor so we have 13 year on this contract and we need to return them back to the sender so we are not locking them the first thing we do we remove

66. 46:04

    it from list of staking pools that were created because this was not successful so we're saying creation failed we're going to refund you the attached deposit so now it's not a real attached deposit because the callback doesn't receive the touch deposit it flies through a separate refund receipt that usually arrives first as then a callback and and it also takes the predecessor account that you again in our case the if we call end predecessor account i did

67. 46:48

    that will be asked because this is a callback but we need to know who should we return tokens to and the way we do this we create a promise using new predecessor accounted and we say return the tokens that were attached before but as you can see we do not return this promise we just say that's it we don't care if it succeeds or fails the basic return of value false saying the pool failed to be created

68. 47:30

    so what happens now the the transaction continues to be executing but the value will be returned to the front end so front end to like usually near cli you'll immediately know that the transaction has failed you may not get your money back yet so you're still waiting for this particular refund to execute in the next block but you already know that the pool was not created so you can continue and this is an example of how you can do

69. 48:03

    a parallel promise so if we go back to this example there's two scenario let's say success and success this method is executed and then it basically calls um i think it calls something like whitelist dot near or maybe something like this add baking pool and passes the arguments to add stake input so this transaction started here will wait on the result of this now because it's redirected to promise

70. 48:47

    and in case of a failure what happens is um this method creates um a call to buy some trails near this transfer of x amount of tokens but it does this in parallel because it immediately returns top so here it's just returns false so this method will immediately get false and this is how a stake input factor works that's it so it looks like we didn't need an order it and order it set here because there is no get there oh this it has a getter

71. 49:51

    so it checks how many stick and pulls were created and we can possibly to check it's on the main net one second that's prepared so i can demonstrate um how it works for now you can ask a question yeah this is really really good um i guess i'm curious what happens if you didn't have the return value promise or value or when do you need to return promise versus promise or value right so here uh this method uses promise

72. 50:42

    because it's only one outcome it always returns promise but this method can either return a promise in this case this returns a promise and we call dot into which we'll call it or convert it to promise of value enough which is just either a promise or some type of value well in this case we don't want to return a promise because transfer will succeed but we don't want to return success

73. 51:16

    we want to return false instead we could also has like call back on the transfer to make sure we like return false later but that's not important for this okay thanks and occasionally i think we can look at the staking pool view it doesn't return a promise but it does check somewhere here so it does internally state that it doesn't return a promise it just ignores it so it does it in parallel as well just

74. 52:04

    for validation of this taking key and for things like transfer you don't like nothing can really go wrong right well it can fail if the account doesn't exist as a counselor will fail and in this case you will receive um an error like and file or promise trailer instead of promise success so let me quickly switch to terminal okay so we can call um a view method on our mynet pull v1 near

75. 52:57

    and that returned us that total 88 stake and pull contracts will create it on the main net under this uh given probably one we can also check another field which is minimum attached balance it just returns um 30 minutes in here and the way i usually check it i'm going to do something like this so i basically divide it by 10 and 24 and it tells me the number cool yeah it's really good thank you okay any other questions because we this time

76. 53:49

    we actually fit into the timeline so this is good i've i've got a couple questions um yeah i'm uh there's so there's one uh set of questions around the gas uh you had a bunch of constants for gas and i was wondering did you discover those empirically by like running through the contract in the code and then code them in or is there some way to discover that while you're designing

77. 54:13

    yeah good question so and then some more questions about promises if we have time yeah so 25 for the base um it came from the reason because when you do a promise and a callback in one method it cost about 20 teragast just for this without attaching any gas because a promise with the currencies cost around five or like four point six tera gas and dependencies costs around ten tera gas

78. 54:47

    so when you do two code method switches first call and a second callback this is about 9.2 tera gas and then you do a dependency on first to another to the second one it's 10 targets so this is going to change soon once you adjust it because it was taking into account compilation and correctly estimating this value so that will be down dramatically um so when you attach base two you consider that the remote method might need to do one promise

79. 55:26

    or like one promise with a callback so i usually say how many promises you need to attach like call if it's two so for example promise is a callback then it has to be base for the basic computation and two basis for first promise and the second promise and it kind of combines recursively this is the complication for near do it sync execution so you need to know how much gas you need to pass

80. 55:59

    to at each asynchronous call including your own callback the good thing is if you currently overestimate it a little then you do refunds there was consideration to remove this refunds but it's not finalized and clear and then are you i mean you're talking comfortably about these numbers that you just you just quoted two or three different numbers off the top of your head is is that because you have

81. 56:31

    built this intuition over time or are you using some utility to help kind of give you this uh sense of of what costs are because these costs can change over time as well so i wonder how do you maintain the current intuition about the cost of things right so the costs um can go down so like we're trying to guarantee that the cost will only go down um and there is a mechanism to to enforce it so let's say we need to increase some cost

82. 57:03

    instead of increasing this cost we can bring down the cost of all other methods and increase the price of gas or decrease the supply of gas that effectively will balance out the cost um uh there is a configuration file in the near core that explains every all fees and mostly we figured out this from experiments so we have a simulation test for some contracts which allows you to pass limited amount of gas and you can check

83. 57:43

    if it succeeds or fails but uh we'll probably publish more guidelines on the gas once you upgrade fees at the same time it's currently unclear like this entire guess is like a mystery especially around storage and like all the fees but because function calls for dominating the cost of this um it was more expensive okay uh thanks for that um the the second question i had was about the

84. 58:22

    external interface for the contract calling itself staking pool factory had an external interface set up to call itself uh early on in your your presentation and it wasn't clear to me why you did this i guess lines 86 to 91 but it makes sense because that's the callback that you're registering to be informed of what happened when you try and deploy and fund the uh the other contract right that that's that's the reason for this you want to treat yourself you want to set up this external interface

85. 58:56

    if you're expecting a call back basically from a promise that's what this is for so this is just a high level it allows you to pass positional arguments that will later be serialized into the json but it's similar how you do this particular call so here you explicitly pass the arguments through the serialization here you implicitly pass three arguments and this uh macro will create a structure for you for the input that will serialize it

86. 59:30

    so this is a choice that you've made you could have written lines 200 to 205 similarly to you know 190 to 194. is that right yes they're not that much different okay i think we have a kind of a conflict meeting so we need to jump well thank you everyone here help us and listen to this thanks thanks again see you bye thank eugene