NEAR Bridge Working Group Update [2021-03-05]

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

1. 0:13

   and we are live hello everybody welcome to the weekly uh bridge work group sync um on this course we are uh checking the status of uh of the project we're discussing uh multiple things that are connected to the bridge and uh to start with let me share my my desktop with you so i believe everybody is able to see yep okay so super cool um let's let's go over the the updates let's see what is happening uh in the bridge project so our status and current goal so we have the only

2. 0:57

   goal for now uh and this is the release in 10 days uh as many of you know uh according to the oak yards of the bridge team we uh we are planning to release the bridge uh on the main nets on march 15th this release means implies the releasing of the core bridge uh releasing the erc20 connector and uh also the the front end front so so these things are going to be available uh in 10 days so right now we are doing final checks uh final small changes to

3. 1:35

   to the code um and also we are like uh trying to do the checklist trying to create the checklist for all of the specific cases that we need to candle a handle in case something went wrong so we are just testing our ability to react fast and and to keep users funds safe uh this is our goal this is some this is the same thing that you're going to hear in one week because uh we're still going to to focus on this and yeah and that's it

4. 2:12

   so let's let's review what what we have done within the last week uh let's go to the to the weekly update so from my site it was a bit of hiring activities because the bridge team is still searching for to fill one additional position it seems like we have found uh a good candidate uh we just need to to do like the the final uh interview and if everything is going to be good with it uh the next uh week i'm going to announce that

5. 2:48

   we already filled this position um i was doing a little bit of uh work with f connector with uh kiddiel and evgeny uh so there we were like going back and forth a little bit uh with it and doing some additional additional discussions uh it was taking a little bit of my time um also also like just lots of small management tasks uh that were around the management of the issues uh like doing the checklist check lists

6. 3:32

   for the bridge upgrades and for the bridge upgrades um things like that um so lots of small tasks again just to make sure that everything is is there uh also there were a lot there were lots of communications and like i i understand that this is only starting um how to how to do the the proper rollout of the breach on march 15th so already some additional things need to be prepared like blog posts and uh some messaging and stuff like this so lots of small tasks

7. 4:12

   again nothing nothing major so just do not want to spend too much time on this so that's it for me for this week uh marcelo how was your week yeah first of all notice that the video is not been updated so we cannot see what you're writing okay let's let's wait let's wait a minute and then if if everything is okay then if it will unfreeze then we'll just continue if not then i would ask somebody else to to to stream but but i i can input the because we have the same

8. 4:55

   uh so so you you can just update us and i'm going to enter and if if it will not and somebody else was going to share it okay so this week i was working on several features that we were adding regarding the gradability like a feature implemented by jenny about housing the bridge he was integrating it all in test i was working on the nep141 standard integration like moving from an

9. 5:32

   ep 21 to an ep 141 and that's still not merged um yeah that were the main task but yeah a lot of discussion around how credibility will work how all the steps for deployment on 10 days will be on all the requirements we need okay what about the the screen well is it what about this no it's not updated at least okay not on the not in youtube let me see in soon it's not updating alex can you let me

10. 6:15

    share the screen i can share the same document okay i've done you the co-host and i'm going to stop sharing right now can you can you share it okay well good night yeah works super cool um so can you maybe update us also yeah what was what was in your week oh i was quite busy unfortunately mostly not with a bridge so not much on the on the bridge but in general preparing for the launch finishing i still have some

11. 7:21

    code to add to the version that we may like that i want to be included in the code that we are going to deploy what is what is that code so a bit of improvement to this admin controlled something that i've thought about it that solidity sometimes maps multiple state variables into a single storage slot so i want to add the function that only updates part of a storage slot to be able to update a single state variable without any kind of race conditions if any other state variable that also uses

12. 8:10

    the same slot can also be modified in the process basically it's like a store but with a bit mask to update only specif parts of a single slot another thing is that we want to actually know which storage slots a state variable is allocated to and so i've read documentation and solidity compiler can produce this information in addition to other output like contracts byte code and

13. 8:49

    abi and also it can produce the output in a format so-called combined json so it's a single json file that contains all compilation outputs and probably we may want maybe not for this deployment but later switch to using this combined json instead of having two files that we already using for each ethereum contract so currently we have a separate file for bytecode and separate

14. 9:22

    and another one for api and we can maybe switch to combine json to have just one file for everything and this will so probably as far as i remember we currently have like separate configuration values for locations of those two separate files for each contract so if we switch to a single file per contract we'll also reduce the amount of configuration and also i think solidity compiler can

15. 9:54

    only produce certain kinds of outputs in combined results so the separate files are kind of legacy if you want newer new features you need to use this anyway yeah well from my points of view we still need to keep somewhere the abi files if it's in combined json it's very easy to load from javascript code you just load the gestures on and some key within the json structure will

16. 10:26

    be api okay difficult than a separate file well sure yeah it's just uh the fact that we need to provide to to to the devs uh the api because this is the only way how they can call our methods okay sounds good um uh is that's it do you have anything else yes that's it okay uh kirill what's on your side yeah so this week my work was uh quite different diversified and i had as well a lot of

17. 11:10

    small tasks that were need to be i also had with alex and marcel upgradability discussion on this week regarding the rainbow bridge and its dependent contract i worked if you if you talk more specifically uh two pr's uh for the rainbow token connector which are 35 and 36 uh i was working on them for a little bit and i'm worked and these are merged at this time um i also spent some time working on

18. 11:48

    issue 21 which is about moving from an ap 21 to the ap 141 uh but this was uh like quite a good amount of code was submitted by elia yesterday so we keep to this pr and we'll work on this one perhaps women can fix to see if we need those i also stole your comments on this side um i uh also for a little bit improved the admin control contract in the auto upgrade bridge vr in the rainbow bridge and

19. 12:29

    spent quite a good amount of time on working on the east connector so first of all the apr number seven i worked on it and merged this and they created dpr number nine which contains uh some contract improvements uh and scripts uh that to make the interaction and testing of the connector easier and some tests along with it and this week we spent some time thinking with evgeny and alex and working together

20. 13:11

    and testing and fixing both sides of the connector and probably today we will have some more time with evgeny to finish this part of testing uh i mean both sides both deposit and withdrawal for the east connector between ethereum and near side okay super cool it sounds like lots of stuff uh pierre what's on your side as you can see i've put your name correctly in the template thanks um yeah so on my side i

21. 13:53

    finished the bridge selection drop down feature so that was early next week so that we can next week use this to redirect to the different versions of a bridge um so one for mainnet one for winkerbye and one for roxton um i also did some work on improving the network handling um and the account change handling from metamask so that the bridge um doesn't query wrong data on the on the wrong network so there's a

22. 14:35

    pr for this that's being reviewed um we discussed it with chad and so there are some extra changes that we want to do to improve the structure apart from that i fixed two other issues there was the double approval issue so now we're preventing users from initiating two ethereum transfers at the same time so that the approval doesn't get overridden so this was issue 97 and there was also another issue with the a failed uh checks into ethereum um

23. 15:21

    so now um like now retrying the the sync check if the sync check fails due to network problem then we can retry it successfully all right and the last thing we did some um some work on the hosting um testing the the hosting service so that next week it will be easy to deploy everything super cool super cool um so that's great uh i would like to um i would like to to ask evgeny to show everybody um

24. 16:10

    the our project uh on on the github so i it just that uh that's uh like we have we have everything that we have within at a glance so in that project i've i've just i've just cleaned up all of all of the tasks that that we need to do and uh uh before the actual release so there is not that much of the things that we need to do but but still it would be a good thing for um for us to take a look at so again you would would you can you

25. 17:00

    send me a link yeah sure no problem yeah so you can see here that i i've removed almost everything that was uh or like transferred into the issues uh all of the things that are not relevant for for the release um you can see that we still have some things uh to be done here uh and actually probably something is already updated so as far as i got it uh the admin locker your c20 locker 36 is already merged

26. 17:53

    yeah so the the thing that is in progress um yeah i believe yes yes yeah so i'm going to move it into i'm going to move it into done so that's good um um okay so so the the major things that that we have in front of us um it is only fun is the finalization of the movement to the np141 on the contract side uh once again this is this is the thing that that ilia was helping us with and now marcelo also added a couple of comments there and uh yeah we need to review this uh

27. 18:39

    a lot because this is uh a major change although we're using the vanilla implementation and that was checked multiple times but still we need to make sure that we've done everything correctly uh there are multiple questions there that are still open for example with metadata for the bridge tokens but but we i believe we can solve this and the next big thing here is that well we need to

28. 19:10

    actually to adapt uh the front end to this thing so so here this is going to be on your side um the change will be not very big but the way how how you're going to query uh schedule some of the transactions uh and some of the view calls uh is going to be changed so no major stuff uh but still needs to be adjusted um as you can see we have a couple of bugs uh also on the front end uh that still that we need to to do we need to change uh one major thing

29. 19:50

    uh for yourself to to just to keep uh uh to keep in front of you is that next monday uh we are going to have the main net upgrade that is going to reduce the the storage cost 10 times so that means it will be good for us to reduce the storage requirements in our everywhere where we have them so for example in the deployment of new tokens which is going to be pretty uh pretty important for uh for the ordinary users that are just bridging their fresh ear c20s is that

30. 20:31

    this week i think this week there was also some men that upgrade i thought that was yeah i also thought yeah i also thought that it was happening on the 1st of march but in fact the upgrade was not happening on this monday so yeah this upgrade is only on the on the test net at the moment and it will happen on on next monday the one bad thing right now is that after we include uh talking like any p141 the contract size increased 10 times so

31. 21:08

    okay okay well maybe then well still need to you know update update the storage requirements so this is this is how it is called so this is something that we need to do yeah something updated yeah yeah um then we also have one thing that we need to white list um 20 top uh erc20 tokens it's not a big task to do uh but it's it's just a question for for me that we need to uh we need to have enough veneer in order to fund this deployment transactions uh i'm going to take care about this

32. 21:50

    um and yeah and then probably that's it and only host the stuff and and yeah and and then you'll test the upgrades so our next week is going to be fixing all of this small and medium things and just testing the hell out of the upgrades doing it multiple times on the test net yeah that's it um thanks thanks steve guinea for sharing this with everybody so we can we can go come back to the to the md document so uh are there any

33. 22:30

    specific uh things that that you want to discuss today well there is um this thing that how how after we include an ep 141 the main function uh and how will it work will it be payable like every time it's used you should need to attach some nearest to it even if it is conducting here or do you want to have two separate functions there one for registering the user i'm playing storage long time and then

34. 23:08

    he's using uh i'm not a number of boxes but um yeah um so let me give a little bit of context for for everybody so nep141 changes the way how the token works uh and there is a split in between the token functionality or transfer functionality which is implemented in 141 and the what is called the account creation or storage handling uh that is uh the np145 and the reason why we have this this separation is that this smart contracts need to account for storage and

35. 23:54

    since uh for near blockchain uh the gas cost or execution and storage costs are separated we need to handle it somehow and if the user creates in the token contract in account which literally means that he becomes to becomes an owner of the tokens and he is having some of these tokens the contract need to enter some certain amount of information and store it on the blockchain literally this is the end this is the entry in the map

36. 24:28

    that this specific user is having this specific amount of tokens and contracts need to pay for this storage well not to pay but some tokens need to be locked so there are two two ways how we can handle this uh the meeting function or like this is the function that is called by a factory contract and the moment when when the the transfer gets finalized that either this function needs to require or every time some some tokens and most of the times these tokens will get

37. 25:02

    refunded back or we need to have a separate function for account creation uh and and then the the finalization will not require most of the times any deposit um i think that for now we can we can go with with the first option and well it is highly dependent on the understand that how we are going to see so if the standard will give us some clear uh guidance how uh how the storage should be

38. 25:35

    should be handled and if this is something that we are going to get from the from the berry pickers team um and they will do the implementation then we are just going to use this these functions and that's it and we can talk to them about it but but in the end this is on our side actually not on the on the way the standard is being used because like the the function called means is is the one the function that is uh needed for our users to actually make the transfer

39. 26:05

    um yeah one point to the other and paying storage needs to be done only once so it's like from a high-level point of view this is not directly and responsibility yeah yeah yeah so this is yeah i agree with you i agree with you um for the users that are doing the first transfer then in case we are doing the separation here then it will be it will be two transactions that that they would need to make first the create create the account and then and do the minton or like do the finalization of the

40. 26:44

    transfer yeah inside we're optimizing for the first user who is using our application yeah on the other side we are optimizing for the user that is using our application long term yeah let's uh let's let's discuss the following do we want to have the the deposit function of the um of the um of the factory payable do you want it to be payable the deposit function yeah what is the deposit that we drown so uh uh this is this is the function that is finally finalizing the transfer on the factory and then this this

41. 27:26

    function is called mint do we want this this function that is called by using because mint is not called by users mint is called by the factory yeah well but if mint is payable to repair yes yes so so my question my question yeah my question do we want to have a deposit function or deposit function to be payable and uh i'm saying here is that uh do we want to allow somebody to create so if the function is payable then then it needs to be confirmed

42. 28:08

    every time uh uh in the wallet do we want this function to be automatically confirmed at some point the the main use case of using uh of marking the function on spare even if you don't really need to like if you don't need the attachment here is about security however you don't want the user to be intrigued of adding a key that can be misused by somewhere but in the deposit case i don't think

43. 28:38

    there is any security issues because we're using it to pass a proof which needs to be valid and cannot like claim and transform any anyone else so there's no risk there on the location having access to calling this function so in theory we don't need it we still have the limitation that we need to register the account that's the main point of the discussion but from my point of view if there were no this limitation of registering account we should not pass this function

44. 29:09

    okay maybe maybe we can do the following way maybe we can maybe we can allow uh so let's let's not make this function payable are we able to attach to which we call this function though it is not payable with some attached deposit is it possible so if we have a payable function are we able to to call it uh with some attached deposit to the transaction without yeah if we can do this if we can do this then we can implement it in the smart way

45. 29:50

    so if for example then it checks whether the user has an account and if it doesn't have it then the function can check what is the amount of the deposit if it is enough then it creates an account but then i'm not sure you need to check that body but the distinction is that if you need to attach someone here you need to signal transaction with your full access key sure so you're saying that sometimes you're singing without it the opposite so you can't call a

46. 30:23

    payable food you can't call a non-payable function with a deposit but you can call a payable function without a deposit and maybe you can do it without confirmation well i guess we need to talk about we need to yeah possible in the current interface yeah look um so from my point of view from the from the storage management uh standards we they will have a view endpoint if you call to check whether the account is created so that means that we can handle it on the on the front end we

47. 31:09

    we can we can do the the correct way without scheduling some additional transactions and waiting for them to fail so so that will be smooth now the question question to appear how simple it will be uh to have non-fixed amount of steps uh or some some optional steps in the in the front end at the moment so from my point of view what what you need to do like from the front end you need to you need to query the

48. 31:50

    the user is registered or not so you don't need to to have like two separate uh to call to several functions we might as well have two separate functions called deposit that one attach some near one doesn't and the content only needs to figure out what function would we call okay i believe we still need confirmation uh in this function because uh imagine the following scenario for example uh we have like a lot of

49. 32:24

    near users who didn't want to uh like to use some specific token uh but someone from the ethereum for some reason uh sends some tokens uh to each user and in this case uh the user will need to to pay for the account creation for the specific token i believe this is uh a little bit strange but nobody it will happen only if he calls to this function to me function is the one who pays not not the owner of the tokens so most likely the one who will be paying will be the owner

50. 33:08

    but nobody malicious can just force you to pay for some tokens that you don't want okay i i just thought that we will as perhaps some notification on the front and side so for example if there is a pending transaction that user can approve uh in order to receive talking i mean if their layer does not process uh this specific transaction and we can display this part but but yeah for sure this still will be optional for the user either to what to call it to mean some

51. 33:48

    tokens or not yeah like the point is that the front end or the player or anyone won't be able to call the deposit function if the account is not registered without first attaching some nears and the user will not be forced to attach something here without signal with the wallet with its wallet so is it possible to do those two actions with a single near wallet redirect the account creation

52. 34:19

    and the minting yeah you can submit in a single like you can submit batch transactions so in that case in terms of front and um the account creation can be abstracted from and keep the same flow as now if the account exists then just mean directly and if it doesn't exist and request to action transfer um is there is there if marcelo in the bench transactions are we able to to require the the finality of the transactions

53. 35:05

    in specific order yeah i think so they are they they are actually processing the same uh in the same block synchronously that's my understanding i think a batch transaction has a condition that all actions need to have the same destination account so if account creation if we are creating an account and destination in the token contract and when we are doing a deposit the destination is the

54. 35:35

    bridge factory yeah so it's different uh what we can do we can just leave this uh in functions uh but not to call it like a batch transaction so for example uh their layer before relaying the specific transaction he will first query the token and check if the contract if the accounts is registered if it's registered he will call the surprise function to create a storage for the account and then he will be able to call the the non-payable deposit function

55. 36:15

    so this sure sure the problem the problem here is that from the front-end point of view is going to be one additional step and at the moment the the steps are uh as far as i understand they are pretty strict is this correct pierre yeah it's probably not that huge um because it's from the front end point of view it's mostly abstracted it's the library that manages the step that will change yeah um

56. 36:50

    yeah yeah we so it it means that we don't have a choice right it has to be two wallets yeah two different transactions well you can you can have one transaction one special transaction that register and deposit yeah yeah so we have we we may have two different functions like this the last option that i've added here uh so one deposit function is is not payable he is like how it should works when when the account is already created and another

57. 37:26

    function is registered account and deposit which is going to first register the account and then call the deposit function so we have a separate function so that one just registers the content another just deposits then we will only have to confirm one of them in the wallet one that create the account and the second one it can be a separate transaction but it won't need confirmation because the account would be already existing at that point okay uh

58. 37:58

    so are you saying about that we can we can create a register account account function in the in the factory and in this case we would be able to send the batch transaction register account need we can have a register account on the token as usual but then we can have two separate transactions so the user will only have to approve the first one register account because this one needs

59. 38:33

    an attached deposit the second one doesn't need uh yeah but somewhat somebody need to pay for this transaction it's it's not us who is going to pay for it it's user but do we need confirmation for just that doing doing do we mean guess for the transaction yeah i guess but why do what we need to or we need to or we need to add some keys permanent keys uh so so so with with some allowances that user is not confirming it and i i do not think that we are going to this way

60. 39:12

    at the moment well that's the point if you're not going this way then we can just leave everything as it is kind of because the full point is going that way to avoid confirming everything well not not not only these uh i think that it's also the question is what what what the person is seeing in front of him if he's saying that this transaction requires some deposited funds or this transaction just uh just

61. 39:42

    you just no transfer in in funds but you're just you're just paying for the gas so yeah so from my point of view like the best option will be the following we need to add to the factory a register account function this function is going to take uh is going to take a token account and and user account and then what this function is is it's payable what this function is going to do is to

62. 40:18

    call the register account function for the token account so this is a payable function and yeah and it will be in the factory account and since it is in the factory and deposit is is non-payable function and in case front-end checks that uh that there is no uh that there is no account created for a person then the front-end sends the bench transaction register account and then deposit

63. 40:50

    and in this case and then the user confirms it with a single signature that he is going to use some some money for it and deposit is going to be called after this then the account is registered and then everything is and and then the transfer is finalized in case the account is already there then that then the front end is going to schedule on the deposit and that's it what do you think i think this is probably a good solution

64. 41:22

    for now so that seems like a clutch because we are creating a proxy function that redirects to a function that could be called directly so probably we should ask quality to implement confirming multiple transactions at once so that at some point we could get rid of that but for now this seems kind of acceptable solution okay marcel what do you think yes okay so so i'm putting here solution

65. 42:12

    payable register account plus non-payable deposit okay also right now when the user withdraws all of it's run that function also responds to the user although the balance do we want i i think that let's let's not let's not do it let's let's not delete let's not delete it let's not delete the user account and just just have it uh so action item here is to check with uh wallet time on on removing

66. 43:02

    the proxy function above okay good good what additional things do you want to discuss so probably we need to we need to go to to the plan let's let's spend uh several minutes and on this let's let's figure out what we need to do next week so um so on my site what i want to do i want to to test the connector because though it is not though it is not connected with the with the release of the bridge still we need to move uh in this direction too

67. 43:55

    uh then obviously everything that is connected with with the the release of the bridge so i want to uh to do the upgrades of the bridge on the test net and then support support the release of the main net bridge so just to help all of you with a little bit of code with with some communications and stuff like that so my main focus for the next weekend yeah and onwards until the moment we are going to release this marcelo yeah so we did

68. 44:44

    this week several interfaces of data for our contracts and all our javascript code with the service needs to be updated accordingly it's not done yet and we need to check we already have a plan about how to test that all the deployment process and the great process in the future and will actually work so i'll be focused on having this and then just put all the attention on on the upgrade

69. 45:15

    it's on the deployment of the bridge itself like we we decided not to grade the bridge on on test nets and we decided to deploy new bridges and we will hopefully we will do it next week and then after that we can deploy the original magnet if everything goes smooth yeah good i'm good eugen so for me the main priority is supporting the those upgrades and deployments of bridge so if there is any

70. 45:54

    problem i will need to check with the code whatever so as i already said there are some little changes then i can get added to the code before we deploy it and uh that's it yeah okay super cool kirill what's on your side here um i believe the first priority will be uh to help guys uh with nap 151 migration uh if i know so i i will check this this code and review it and make sure that we are working like in the correct space and we are able to finish this

71. 46:41

    before the deployment and i will also most likely spend some time testing the connector with evgeny and i believe that i will join all the same activities that you and marcela will be doing on the next week with regards to the upgraded ability of the bridge and releasing the mainland bridge yep beer yes so the first thing will be to finish that pr with the ethereum network handling um which shouldn't take long and then i think the main focus

72. 47:26

    will be implementing the new um transaction flow on the near side yeah okay super cool um thanks everybody uh stay tuned for the updates uh so i'm checking the chat on on the youtube nothing is there yeah so stay tuned uh exciting time for the bridge team uh wish everybody luck and fixing all of the bugs and all the troubles as soon as possible and releasing the bridge to the mainland okay see you in the week uh have a nice weekend

73. 48:14

    and uh meet you on the next call bye everybody bye