NEAR EVM Working Group Update [2021-01-15]

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

1. 0:04

   yeah and we are live okay alex we're gonna start with the agenda in the github discussion uh so so it uh or it appears that because of some strange reason zoom is not working correctly on my computer so if you are able to to leave this meeting and share the stuff then it would be good okay uh hold on let me show the screen oh host disabled screenshot uh yeah i'm i just made you host so you can do anything okay so today welcome everybody we have

2. 1:07

   a little bit more people than usual welcome welcome to the evm working groups uh weekly public sync today we're gonna do a little bit something different than than usual um normally we give team team member updates and like and this time those will be after after a meeting on github so we have a weekly update discussion which you can find in the near near core repository and over there the youtube link will be posted somebody can put it in there as soon as they notice it on youtube

3. 1:47

   and the agenda today is this so our current goal that we are working towards and let me edit and talk at the same time um so right now we we are planning our q1 um of objectives and key results and we are staffing the team and allocating the work so that's the near term near term objective and the midterm objective is our deployment to testnet which we'll talk about in a moment um alex and i prepared a short presentation

4. 2:34

   in order to help with the okr review and running so let's have a look at what we did last quarter let's talk about some of the important things we have to do in q1 and let's look at how we can do that so in the last quarter we had three okrs defined usability um evm and updated uvm and um destiny deployment we didn't quite make all of these okrs the one we did based on was usability and thanks mike especially over here this this is in pretty good

5. 3:22

   shape we have defined three key results in briefly uh internal tooling should should be updated to support the evm and that involves a number of repositories including the cli at the javascript api the web3 provider and that's all pretty much um in nice shape we can always do more but when we created this earlier this week we patted ourselves on the back on that one there are also substantial documentation updates we have i believe something like um

6. 4:03

   let's look actually here we have something like 10 different pages added to the documentation i not everything is being published yet okay of you are still pending but there will be a lot of moral stuff here in the ethereum compatibility section on the develop in the mailbox and this is all currently targeting beta nets because the bm is deployed on betterment um what we did less well is the last key result which was perhaps a little bit ill-defined

7. 4:42

   as in it's about truffle support for existing evm projects and in this case um we didn't really define what what we should use as the metric here and run out of time in measuring something useful on this so i've assigned as a 25 grade over here because i believe they're in in okay shape so this conservative estimate but we haven't uh we have any good measurements any on the metric we have a good metric and we have good measurements on it so i score as low on that

8. 5:21

   now on the next objective there was the updated evm that thing first of all involved updating us from the old old parity ethereum beta release that we were using at the beginning of the quarter to do something more recent which means this is open ethereum um we had planned to upgrade to open ethereum three um but we backtracked on that given given that it's a new new code base and uh it didn't have a lot of

9. 5:51

   deployment yet um so we we did a number of upgrades uh all the way until 272 which is where we are currently so that's the last part of the ethereum release just before the open ethereum team took over now since then we've opened discussions with the open ethereum team we have more insight into the roadmaps and and the procedures and quality assurance and whatnot and um we are planning to to upgrade soon to open ethereum three three two actually which was portable in hard fork

10. 6:25

    so uh in any case we uh for the adjusted objective we did uh dual network uh the second key key result was meta transaction support and on this um i believe that we can create ourselves a hundred percent a lot of work by bo mike and elia um by the way if anybody disagrees i feel free to speak up um and uh the last uh key result involved benchmarking this was a little bit ill defined and um we haven't really properly begun this work and so

11. 7:06

    we're gonna have to put it on there um then we had the aspirational objective which we did not achieve this this last quarter um in in other words a deployment destination and this this we have to get done this quarter it will not be aspirational for this quarter but um we did do many prerequisite things not not all of them captured here in in the key results um some things we did complete um

12. 7:39

    voted great work on the gas fees um that is a larger discussion i won't go into right now we have a lot of test coverage much more than we used to we can always have more but significantly we have for example the balance of test suite now working what we didn't even begin on is the bid on its planned bug bash so that will be this quarter as in an incentivized period of of attacking evm on the betterment similarly to the previous objectives of

13. 8:20

    benchmarking we haven't really measured yet the transactions per second that we are capable of on the evm uh however we would expect to reach this target just need to measure that and uh yeah we didn't deploy to this match in the last quarter so that was the last quarter and we learned many things from this this okr review which has been ongoing all week namely that we had somewhat ill-defined

14. 8:52

    okrs and we had not the not the best metrics on all of them it was hard to remember what exactly we meant in in in interpreting some of those metrics and they were more ambiguous than they might be so for q1 alex and i have done a bunch of work on on that but before that let's have a brief um digression so much of the work over the last few weeks or even last month has been about aligning everybody in the same direction because there's been a lot of differing visions for what the evm should represent to

15. 9:35

    never i believe we are getting some some substantial alignment now and one of the last very contentious issues um it's not a simple simple answer there are many traders to consider and people have somewhat maybe entrenched in some cases and in other cases heated views has been the choice of the base token for for the evm um so there's a whole discussion about this on the forum

16. 10:08

    but those interested can check that out let's load it up here long thread with uh 20 20 posts so if somebody has an interest in that question that's where you should look and perhaps participate now as it currently stands um so maybe to introduce this issue a little bit for those who haven't read the forum post as it currently stands the the near evm is using nero as in the near token as the base base currency

17. 10:48

    uh base uh token of of the evm as well this has a lot of benefits in terms of um for example being able to call out from the evm into into the near virtual machine based runtime um it has a lot of elegance and simplicity to it and it has been a popular choice in other evm compatible exchange they practically well actually every single one i've looked at they they've done the same

18. 11:19

    they they've adopted or created a utility token and in some cases also use the utility token for fundraising as in an ico of that utility token for example moon base with glimmer however there is a there is a contrary case to be made and that case is that from a business perspective um it would be highly preferable that we would be really genuinely 100 compatible with ethereum

19. 11:49

    um i've a little bit unpacked this here and on the forum in terms of what happens if we wanted to port something like uniswap say um so just looking at the uniform codebase digging into it um you can find stop talking about the the ui the dac itself not necessarily the contracts um digging into it you can find tons of places where f is hard coded as an assumption as in an actual text string as but also fundamentally assuming that we're operating on a chain

20. 12:26

    that has f so for example um any any any dap which is meant just for ethereum as in it hasn't been ported to a wide range of evm chains and that would be most of the apps right now um he's going to assume for example that it can get the fusd exchange rate as in the price of f from some oracle another and that would be one thing you have to change uh as i mentioned uh there's a ton of hard codings of s as a let's say a user interface concern

21. 13:00

    um you would have to deal with that in some similar way to how we do localization in applications as in you know this chain we're going to show near on this chain we're going to show glimmer and over here it's something else and then you know if you're on f we can actually say yes virtually none of the apps adapts have currently been coded with that in mind um all of them have assumed a simple view of the world as in

22. 13:24

    they are running on ethereum um why should they do anything and and so that's that's one one part of the problem that um porting something like unisrap right now would mean making it run on the near evm would mean uh forking a whole bunch of repos um at least two for the user interface and potentially potentially more we haven't followed the whole dependency hierarchy yet um and maintaining a long-standing or indeed indefinite fork

23. 13:59

    that would um do a search and replace of of all strings where we or they hard code if it would change all the price oracles um it would uh deal with all the code and there's a lot of it that assumes that there's an easy conversion to be done between s and w s um and probably more things that we haven't considered but those for starters and this would need to be done for every single dap pretty much that you would want to

24. 14:31

    port to the near uvm that's not a good proposition so after a lot of internal discussion debate alignment it does look like the most sensible thing for us to do from a business perspective is to adopt f as the base token for the near evm and how to do that is a big big question um which we can come to so let's move a little forward in order for us to be able to use f as the base token we need to be able to bring it over

25. 15:09

    as in one one f on on the near evm should represent in some form um an f on the f1 chain and some some chains for example define a smart chain they call this updated token which might make sense as nomenclature um we've been calling it bridge bridge assets as do some other other chains we can we can settle on something good for that so alex i'll hand it over to you to present how how you figured that we should do

26. 15:42

    this currently sure so the next couple of slides are the principle scheme of how we can implement the bridge to the evm this is not final we are just like thinking of how this can be implemented we were discussing it with eugene uh yesterday uh so this is what you can see here so on the slide you can see the left hand side with which which represents the ethereum blockchain right hand side which has which is the near blockchain uh the blue rectangle is the bridge

27. 16:15

    infrastructure that is currently there currently deployed and uh it has like the it is it is common for all of the connectors that are using this the infrastructure consists of uh several parts so there are some smart contracts on both blockchains that are light clients and their approvers uh the smart contracts that are able to check the facts that something has happened on on the other blockchain and there are in between blockry layers

28. 16:46

    and these uh these are just the services that are sending transactions to uh to light clients with the information about the other chain now this bridge infrastructure is used by uh by uh multiple connectors and uh people are and developers are able to develop their own connectors and to bridge their own information so in this specific case we would like to develop an athlocker smart contract and deploy

29. 17:18

    it to the ethereum blockchain and also update the evm pre-compile contract so it can also interact with it that it will go into act as a as a part of of this f locker f bridge here so uh on the slide there is a principle scheme for uh uploading of f for bridging f to near f or nf so so it works the following way first the user is calling in f locker account and this is going to be a payable

30. 17:58

    function so it deposits some f inside of athlocker account this account as a second step it emits an event and this event is mercurized in this particular block then without any user uh oh without any interaction with the users block relayers are submitting a block uh into the ethereum light client on near side it gets verified there is some kind of finality period that we need to wait for this uh block uh

31. 18:37

    to be to be able to be used so we can use this block uh to prove the events that happened there currently this it is about 25 blocks uh so so it's about seven minutes uh then uh the real layer or actually which can be in any account in the near native blockchain so near native account is scheduling a finalizing transaction that goes to one of the functions or one of the methods of the evm recompile within this transaction relayer is submitting

32. 19:16

    the information about the transaction that happened on the ethereum blockchain it actually submits the proof or this this the proof of the event that was emitted on the ethereum blockchain evm per compile uh checks the proofs by calling approver uh contracts which actually literally call the ethereum like client to check the the eth hash and stuff like that and in the end uh obviously uh everything gets back to the evm

33. 19:47

    precompile if everything is correct even pre-compile means near f and deposits it to the user account um there are multiple important thing in this scheme so first of all there is only a single user transaction required and this is a necessity of this scheme because if a user an ethereum user is not having a near account he is not able to schedule any call on the near side actually so that's why there should be somebody who who is scheduling this call for him

34. 20:21

    and that's why this setup should be should look like this so only single user transaction happening on the ethereum site potentially we can split uh evm pre-compile and and create an f minter smart contract there um which is going to just mint and burn nf and we can do this for uh for the separation of concerns uh so uh so we are not going to compose everything into single ev and precompile

35. 20:55

    but we need to assess whether we need to do it especially it depends on the on the on the other direction of the transfer you will see it on the next slide uh second uh another thing is that the re layer the actual so you can see here two different types of three layers the first one are inside of the bridge infrastructure and we are not talking right now about them they are just working and we assume that everything is good on

36. 21:21

    that side now we need to have a real layer that is going to finalize the user transfer and this relayer needs to have an account in uh evm and near evm and and just because this relayer is going to provide in this step number four his account or his address in order to be renumerated because in the first transaction that user schedules on the ethereum blockchain he specifies that there is a certain amount of nf that is going to be transferred to

37. 22:00

    the party that is going to relay the finalization transaction and this is the actual instant incentive for relayers to send these transactions because a relayer is going to pay some near for this finalization transaction execution um yeah and the last thing that we need to figure out how to do as you as you see here evm is a pre-compiled smart contract so it is going to be there at the very

38. 22:30

    start of the network um while the bridge is designed the way that prover and ethereum like clients are just ordinary smart contracts they are not there during the start but when executing the finalization transaction avm compile need to call prover which means that near a and then evm need to know where where this contract is located and that's why we need to have an ability to

39. 23:03

    to to say to evm where this where the this bridge is located so this is something that we still need to figure out how to do but uh in general uh yeah probably it can be done so um oh good at least with the full access key and then like deleting this full access key once the bridge is deployed so this is the principle scheme uh from from my points of view personally it is really good just because a user can for for the user from the user point of view the bridging transaction

40. 23:35

    is atomic so you schedule one transaction and then it just happens and uh also it is secure because you can see that uh there is no way uh a f uh is not landing on any account on near except for the user except for the user account there is no intermediate place where we are putting f where we are directly storing it inside of evm to the specified user account okay and if we go if we if we take a look at transfer back it is a little bit more complicated

41. 24:15

    because like we have we have now two parts now the user has an account on near side and the transfer obviously needs to be started there so user need to send a new transaction but unfortunately he is not able to send a near a loan transaction so he needs to call a method of the evm recompile to withdraw some funds but unfortunately he's not able to do this because what what we expect from user is to sign normal ethereum transactions which are not the new transactions so somebody so so what what what he can

42. 24:55

    do is to sign something and then every layer needs to be there to pay near fees for for the user um and uh and and and on the seconds yes so so relayer then relays the withdrawal transaction to evm precompile a pre-compiled contract is able to analyze it and and produce the and and burn some some nf from the user account and produce what is called execution outcome this is something this is something that it can be treated similarly to the events

43. 25:35

    uh in ethereum this execution outcome is is related to near light client on the ethereum side and then the user need to call on the ethereum side the finalization transaction uh number four which is like literally withdrawal and it works absolutely the same way how uh how on the near side so f locker uh checks the proof uh from the prover uh a smart contract deployed um inside of the bridge infrastructure and if everything's okay

44. 26:08

    atlocker releases some f and sends it to the user account two user interaction points here are required so one is on the near side the second is on the ethereum side this scheme can be upgraded with the relayer approach absolutely the same way how we have had uh on the previous slide so there there is every layer on the ethereum side that is incentivized with some f to be able to uh to to create a withdrawal transaction

45. 26:42

    so this is possible we can do it uh but it is not necessary like in the in the previous case the near side relaying is incentivized by by the fact that within this evm pre-compiled transaction execution actually the part of the fonts uh is transferred again to the relayer account inside of near evm so principle scheme is there for sure we need to implement this there is a hard connection that is going to be introduced in between

46. 27:23

    near evm precompile uh and the bridge but this is something that unfortunately should be done in this case all right thanks alex um i think we need to perhaps a little bit simplify this this whole section of the presentation next time present it and take the technical details after but in any case thank you everybody for holding all your questions let's deal with those after we finish the

47. 27:56

    um okr planning so we have considered what we ought to do this quarter and what we can do and alex and i think it looks something like this so the number one numero uno objective this quarter is to get evm on desnet with a full full punch list so we don't screw anything up and this is the outcome we would like i think we have to deploy a compatible evm the polling hard fork is coming perhaps february we'll see so we need to upgrade our implementation to support

48. 28:44

    all the new features in the brain hard fork and we should be capable of running any ethereum contract which is not using anything very strange so that's the first key result then we of course care very very much about devex we have done a lot of work in the last quarter which actually wasn't captured in the original key results because we adjusted the course along the way um on we've done our work on having an

49. 29:16

    rpc endpoint a website compatible rpc endpoint um which means that for an ethereum developer to be able to deploy his projects is ultimately just a matter of changing his endpoint url and that's beautiful that's how simple it needs to be so um we haven't defined yet the metric here but we would like something something like um when we work with partners um they'll be able to deploy their

50. 29:47

    projects community members will be able to deploy their projects um easily starting with a link to the onboarding documentation for how to do all this which should have been video tutorials and the like as well and go from zero to hey it works in about 30 minutes in the majority of cases you know for at the majority of cases um for the user experience somebody who's not a developer

51. 30:16

    but the one one million plus people who use metamask should be able to send a transaction to the evm in a fairly short order something like 10 minutes given that it takes as alex said seven minutes to transfer the assets over the bridge um now we'll need to coordinate of course with the sra team to make sure that before we go to to testnet that all of this is easy to maintain and we had a bit of our rehearsal on all of this last week when we actually took down pyramids

52. 30:54

    so we've done the post-mortem on that and yeah it wasn't a planned outage we've done the post-mortem on that and we'll aim to do better in the future and also improve all the procedures around us um performance is important we do want to start piping the load from s1 both both the various destinations and ultimately the magnet into the evm to make sure that we can handle that load so making sure we can will be something something very

53. 31:34

    important this quarter before we can consider moving forward with deployments and ultimately we need to put up a grand prize for come and hack us do your best now this this should be done just before just just after everything else is complete and just before we would then actually deploy to this next and note that the timelines here as in time frames one day of stress testing um a couple weeks of of a hackathon uh these these are the

54. 32:09

    success criteria it doesn't mean that we don't run these things for longer but if we can if we can have 24 hours of um piping the load from something something which can be called ethereum whether it's a destiny domain net then that's probably a pretty good indication that we're in good shape even if we break on the second day um and for security um of course ultimately this bounty should be extended for as long as uh

55. 32:41

    seems useful but if you have a couple couple of weeks of of people enough people so that's question for the metrics enough people attempting to break us and and we haven't suffered a major setback then things things look pretty okay that was the first object now the second objective is let's say a cross cross theme objective as in we'll want to collaborate with business development on partner support and very quickly some and other teams

56. 33:20

    and with the bridge team on making sure we can actually transfer f and erc20 tokens so this is pretty straightforward most of our partners should succeed importing or maybe it's better to call it deploying given that we don't really want it to be a porting effort we want it to be just another deployment so they should be able to deploy their apps to testnets once that's all all up and going and they should certainly be able to bring the liquidity over

57. 34:00

    once once you get that now the of course the third objective has to be that we go to maintenance now this i know that everybody would like to see this this quarter but i have to at this point deem it aspirational so we will we will work hard and uh i don't like crazy onboard everybody but it's not very likely this quarter i do think it can be soon after this quarter but unlikely this order so here we don't have as long of a list of

58. 34:40

    key results as on the test net because most of those things when they're done for testnet they're done for mainnet as well for example evm compatibility you know when we when we have achieved the berlin hard fork compatibility it doesn't need to be repeated here so in other words to go to mainnet right now the the list would look like something something like a bug bash hackathon

59. 35:07

    um a stress test and then ultimately the consensus problem getting all the validators to accreta is a good idea which is probably a project onto itself so that's pretty much it at the last thing in the presentation this is what the team looks like currently so we have four people permanently assigned one of them beginning next monday um and we have for for other people in supporting roles and we we appreciate you very much we

60. 35:41

    need all the support we can get thanks mike thanks elia and thanks thank you eugene um so we are hiring for both the bridge and evm teams and we also pay a decent finder's fee so talk to me and alex if if you know somebody who would be helpful to this endeavors okay so let's take some questions i'm sure people have them nobody come on i know you have some questions speak up uh just a just a quick question so um in ethereum i think the gas ceiling is 10 million right now

61. 36:41

    um in in our edm i'm not exactly sure how high we're going to allow it to go because of like the speed of the speed of the execution of the computation and then like affecting like block production because we have we have these one-second blocks and then we have other overhead like networking and stuff so i'm not sure if anyone can further elaborate on the performance i think eugene would be good for that

62. 37:11

    than you wanted to speak in any case um well right now i think we follow the same limit of 200 targas near gas that map to ethereum so you cannot overspend this limit in one function called i know you you faced an issue that you run out of evm gas just because of this limit so i'm not sure um how to address it so if it's an issue we may consider uh increasing this limit for edm

63. 38:01

    uh but yeah we we have mapping from near gas to evm gas and we have this one like thousand tera gas limit that we need to respect and it will be just the same for evm all right and uh you wanted to ask something as well yeah so i i think alex didn't cover the the proposal regarding the base near talking on the wheel so to to add the addition there in case you want to eventually issue

64. 38:59

    transactions on evm that are native to near so evm will not act as a pre-compile but it will actually act like a regular like uh as a like first party runtime on year and that will allow us to basically issue transactions that originate from your account on the vm and then just execute it in the same block so similar to local receipts on native runtime so you don't need to like go from one chart to another to execute it so for this you'll need to have

65. 39:49

    native near balance in your account in order to compute gas properly and my suggestion was to have double balances on your evm account so you would have knees for all the evm logic and so when you attach a value or call functions or so pretty much anything that you would expect from edm will use ethereum token um but then eventually we can add a precompiled to operate on native near balance and

66. 40:42

    that will allow us to essentially use both balances and later issue transactions from evm um using your gas so you don't need to convert knees to uh too near on the chain or pre-compile level or relight only layers so you will be able to communicate directly with rpc nodes and issue your transactions for this you will need to have near balance so it has benefits in the longer term because then boarding can be done same way as you do right now you you just like

67. 41:26

    transfer your ease from ethereum and start using its relayer network but then once you for example want to use local transactions you convert your is to native near uh straight on evm let's say there is like modified unison that uh converts to wrap here on the vm and then you can convert this or up near to native near on the vm as well so you don't need to leave evm chart in order to convert east

68. 41:58

    near and same way you can onboard from near to evm you you have your native mirror you dab like to dump the turn uh evm account and then you can issue conversion to to acquire ease so so native building will be able to do without without real air network and uh yeah go ahead yeah i'm sorry yeah i'm i mean one is like i'm pretty against actually adding ethereum transactions into the kind of chain

69. 42:44

    uh for like multiple reasons but like all of our like underneath kind of infra right that actually you know deals with transactions will now need to be modified to actually handle this know to like route them to a specific chart like there's a lot of kind of crap that needs to go into like supporting those so i feel like this this is like that premise itself is seems a little bit weird to me and and like

70. 43:17

    before making adjustments to to handle that we should like decide if if we ever will actually want this uh but specifically like on on the kind of implementation side of this i don't think we actually need to have dual balances instead we should just literally have a wrap near erc20 that is at the specific address and uh that like this is how generally it works and so you know all the stuff can be done pretty much using that

71. 43:52

    like you i don't think you need uh you need any like hard coding inside evm pretty much for that no i i think it's pretty critical that you you can issue your own transaction because relying always on uh relayer network will not work in a longer term so you and like having separate account is also a problematic like people will never want to like leave and if you have the ability to issue transactions

72. 44:25

    from metamask without real air network that goes straight to our pc eventually um then the relay network can rpc is the same thing like that whoever's serving rpc will just do the relaying as well like i mean the rpcs itself is the first problem in in the in the blockchain so so the you you can use your own validator i'm saying without real air network uh and you don't need to have native near account so

73. 44:58

    evm account should be enough regarding the implementation details of this it actually noticed complicated because you'll still need to eventually do the sign transaction upgrade which means we'll support a versioned version of sign transaction and just adding another enum there that is evm function call is fairly simple so and as for validation of this you just do the same validation we do these um

74. 45:37

    receipts before the block starts you charge your evm account for necessary amount of gas you convert it to receipt and then it became a local receipt in the execution so from implementation perspective is not as complicated as you may think uh success no no no no no no i don't i don't understand what you're saying uh because to to to for metamask to sign a transaction needs to be an ethereum transaction

75. 46:07

    so our nodes need to be able to accept only ethereum transaction signed bytes not not a signed transaction not a near signed transaction but yeah that's what i'm saying we can accept such transaction um and just drop it into signed ethereum transaction but like how how does that know when it is like like you now need to modify the rpc because we're doing the uh we'll need to upgrade so again i i don't want to take over this meeting to

76. 46:39

    discuss this like i i i mean i'm challenging this assumption we can we can we can take it offline to like but i i'm i'm excited let's uh let's talk about that after afterwards it needs a considerable depth um there's another question we should also uh find time to talk about with with the both of you guys certainly soon which is the question about how we're going to account for evm storage which already came up

77. 47:10

    in the last week i said we had we had a situation where the better net evm couldn't uh deploy more contracts given that it didn't have enough funds to handle the storage i think it had like half a megabyte store at that point and then we well we sent it more funds to unblock it but we need another solution um any thoughts are eugene anally on that and we can discuss in depth later

78. 47:37

    um yeah i think we just dropped this completely we we need to be just careful on how we um how we measure like as a store operations so we need to estimate how much we can abuse um the shark by just like filling the blocks with the store operations and like how fast the store storage can grow so you mentioned the concern was from a chain team that the sink will take longer like potentially

79. 48:24

    for the for the edm shark well not not longer just like out of um yeah out of the limit that is expected so let's say we exceed the the reasonable amount of year that we pre-allocated before like to be considered um then we we can never rebalance it obviously so it's not so it probably will have to be handled separately uh eventually and like sync needs to be redone to handle like evm shard if it becomes very like

80. 49:14

    popular okay sounds like we we need to have another uh soon conduct as well then afterwards all right i mean we can like i think both of those things let's let's create a thread first because we keep we keep having those conversations in meetings but then like there's some people who are not in the meeting so i think like actually having uh collect the facts first and then and then kind of make decisions sure okay where do you guys prefer should we put this on the full remote just here and

81. 49:45

    discussions maybe the forum makes sense it has broader visibility in case somebody in community wants to step in okay okay um all right well then um i would solve this with any other questions and if if we have none um it would actually end early and on time i aim to run these meetings so that we begin an end like clockwork so that everybody can count on that so i would like to uh uh really fast

82. 50:27

    reading uh the questions and answers from uh from our youtube stream so one person was was asking the question about uh when some kind of release dates and world maps so our next question our next so the short answer is that uh the ocrs are given some sense of it but we obviously are going to update the roadmap and going to share it publicly it is going to be there you will be able to access it

83. 50:52

    it will always be in the updated state on the same link another question was what's the role of the near token in evm and the question to this is that literally fees user pays f fees to the relayer who is actually relaying his ethereum transaction to near evm and relayer obviously need to send a new transaction so you need to attach them here you know to pay for the fees so near

84. 51:23

    token is something that is used for paying for the fees on the runtime level and obviously the gas uh is burnt so well all of the tokens that i paid for the gas they are burned so yeah user pays is to relay for their pays near to protocol uh and yeah everybody is happy okay um good to hear that we are getting some questions from the community that's uh very nice um we'll try to to um be more proactive about announcing

85. 52:00

    these meetings whenever they take place and also posting links to the recording everywhere okay does anybody else have something more to discuss all right so for team team members please uh post your updates um i'm creating here an update section you can post them just a text form uh over there and um with that i would say thank you to everybody who participated and watched and see you again next week

86. 52:38

    okay thanks thanks bye bye