Protocol Community Meeting (June '22)

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

1. 0:10

   welcome to the june public protocol community meeting i'm joshua devrel uh today we are going to be discussing reduction of gas prices um and yeah we got a couple panelists that are joining us today um as always you have bowen from the protocol from the core team uh yeah if you want to do a quick intro bowen and then we'll go to marcelo and marco yeah so i'm born running protocol

2. 0:35

   research and development at pagoda and yeah nice to see you guys again marcelo yes i'm here sorry guys oh yeah no problem just like a quick intro just like we are yes um marcelo i am i'm currently in the protocol team we are very happy about everything about here and how it's going so hopefully we can move these discussions cool awesome and marco hi um i'm the co-founder of tonic decks we're building on near protocol i'm not

3. 1:20

   part of the coordinator team but i wrote this initial proposal proposal to reduce the gas floor price cool awesome glad to have you on um yeah so we'll go ahead we'll do um presentation from bowen uh go through a couple of slides if at any time you have any question at all please feel free to drop them in the q a button at the bottom of your screen and yeah we'll either answer them as they come if they're relevant or we'll wait till the ama at the end and answer your question but yeah feel

4. 1:52

   free to shoot off and fire off any questions comments that you have while we're doing the presentation and uh with that yeah i'll turn over to bowen okay yeah let's get started uh so agenda for today uh yeah i'll still provide updates on the protocol on the recent development as well starting uh and then we actually have two discussions today i invited marco to talk about his proposal to reduce the

5. 2:17

   minimum gas price on year and also invited the our team to discuss their proposal on cross-contract calls between aurora and other contracts near okay so let me give a quick update so the 1.27 release is going to be live from mainnet in two weeks uh so we did some refactoring of the the client actor uh which is an important part of the of our new core code uh to be more parallelizable and hopefully that would

6. 2:50

   improve the speed as well as our stability of the of the blockchain node uh and also we had a lot more observability instrumentations both in the form of metrics as well as in the form of logging so that would also provide us more insight into what went wrong when things do go wrong and then we actually fixed critical vulnerability in contract runtime this is already released so i can talk about it publicly it was released as a patch in uh 1.26.1 and

7. 3:20

   then we also obviously reported the release in 1.27.0 um i actually tweeted about it um it was a vulnerability that were like if a smart contract export is important it will cause entire network to crash um and and there is a nice post on um on the neocore discussion uh page where simonas summarizes the problem as well as uh how we fixed it uh and finally there's some uh network improvements uh we're switching the um uh serialization on the network layer

8. 3:54

   from uh bush to um to the protobuf uh it's as mostly uh doing that for the reason um for the extensibility uh the the core of the the message is still serializing boards is that there's like a a protobuf wrapper around it so that we can extend things and change things more easily um okay so that's what's what's upcoming and i just also just want to give an update on sharding um i know that a lot of people have questions around this and i know that we have been talking about

9. 4:26

   this for a while but it is um finally coming uh we're going to run stick wars uh which if people have been uh in the ecosystem for a while probably have seen this before um this will be the third time i think that we run stakeholders which is uh incentivized testnet to attract more violators to drawing uh that will start around mid july and that is to prepare for the phase one

10. 4:51

    of starting launch in september where would introduce this new type of viral data called trunk only producers um and hopefully that would bring the number of uh validator on near to um two or three hundred and um where whereas the uh today we only have a hundred values on the network um and yeah if you're interested uh you can still sign up right now at near.org decentralize and we will have more uh information published in the upcoming weeks on uh whether how exactly the program is going

11. 5:24

    to run and how you could participate and so on yeah so that's all the update i have right now so before i go into discussions uh is there any questions okay looks like there is no question um yeah then i guess we can proceed to the discussion so yeah i i'll let marco talk about his proposal to lower the minimum gas price on the air thanks bowen so i posted this in the near governance forum and wrote an ap for it but just to give a high level summary

12. 6:07

    the proposal is to reduce the minimum amount of gas you have to pay for or the minimum near price you pay for gas at the moment um right now on the near network if you go on explore.near.org you can see that in the minimum price asserting drop market do you want to present i can stop sharing and you can present if you want to present anything it's okay if you don't want to put no i don't

13. 6:31

    have slides okay okay um since the yeah everything's already written on the um uh governance proposal so i figured we would uh kind of verbally talk through it here but um yeah the current gas price is .001 near per t gas so um the the issue here is that the network utilization isn't that high so on average you know there's only maybe like 10 transactions a second a lot of that's aurora

14. 7:02

    each shard can support well over that so we're network like very under capacity but we have a minimum price on gas right so you know in theory equilibrium price if you had a totally free like you know free free market would be near zero right because there's plenty of block space but with this floor you still have to pay a like minimum amount that's not necessarily a problem for most applications because in practice

15. 7:27

    that comes out um you know pretty cheaply like for instance fungible token transfer right now is probably a little over half a cent um and then you know swap on refinance if you um already have a balance it's probably a bit over a cent like these aren't huge amounts the issue here is that um and like for certain applications like nfts or dows like those aren't as price sensitive or

16. 7:52

    transaction heavy so that's like perfectly acceptable but when you start getting into defy i think that's where even uh fractions of a cent make a difference um you know for instance uh we're in order book decks on near as of today there's two others as well this requires active liquidity provision so even things that would be free in like a you know um centralized environment would not be free in um like when building on near for instance quoting prices or canceling your orders

17. 8:24

    um so whenever these basic operations cost money um you're sort of offloading the cost to users by having this minimum gas price because if you if it costs you money to quote a price you'll quote less frequently or you'll quote a wider spread to reduce the risk the same thing applies for amms too if you know there's very small arbitrage opportunities this gas price can make it cost prohibitive to close the smallest one so in in a sense like even though it might not look like a

18. 8:55

    very high price to users at the um on like added surface uh you're offloading the cost by decreased market efficiency for every defy application because most d5 applications um or like markets in general require people to actively either provide liquidity or you know find arbitrage opportunities and close them so when you slow that down you're you're paying the price with like less efficient pricing on pretty much any asset on here

19. 9:37

    to summarize what uh demarco said uh i think i think i probably have this right here um yeah so so right now the current uh gas uh minimum gas price um is this this month uh and the network utilization as marco said is pretty low um and the fees are quite expensive um i mean they are cheap but they are expensive if you have to send a lot of transactions uh in cases like you know if you want to do on-chain decks or like even um especially other book based one like what tonic is doing um or

20. 10:09

    even in cases of aurora where like they're just like sending a lot of transactions um so that that would you know kind of accumulate and then become uh expensive for people um so so yeah that's kind of the the overall idea um and yeah i want to see if i think this was actually already discussed on the forum as well as um i think marco also submitted the pull request on the nap repository uh so i just want to see if

21. 10:40

    yeah there are you know people with different opinions or um or anyone in the audience who want to uh maybe charming and offer their um their idea on this yeah we only have one question uh right now it's uh asking if we can eventually move to a gasless chain like what aurora plus is currently doing uh that's a great question um i think that basically there are two parts right so i don't think moving to aurora plus means gasless or at least in the sense that it doesn't mean that that

22. 11:22

    everything's free because um yes with our approach you get some free transactions but once you you go above that limit you still have to pay um and then if if the question is more about whether we can adopt that model um actually yes that has that is something i've been thinking about um it's just that uh right now on here there's there's no way to do meta transactions um and and in order to get to that state we first

23. 11:47

    need to introduce some capability like that um but but yeah maybe i don't fully uh understand what you mean by gas stress like if you're talking about like um a blockchain which no no get surprised then i think that will become problematic because then people can um can can easily spam the entire network and actually prevent other people from from using it yeah actually we have the oral team here um anyone from the oral team wants to oh one corner you can make in this

24. 12:20

    regard is that this moderates pretty nice as matthias is pointing in the chat you are nonetheless paying the gas in some other way right so if you want to provide this from the near side probably we will need some sort of meta transactions right yep that is what it will take to happen on the near side and then it will be up to the provider to just provide you with near to the free transfer free transactions

25. 12:55

    awesome uh yeah if anybody has any other questions or comments please feel free to drop them in the q a at the bottom orange chat we'll monitor both those areas yeah let us know um so bowen i um in the discussion at the very end i think one point i wanted to bring up was the latest comments um where i think um you know someone mentioned like that they the network currently relies on a solid gas floor price more than uh like we've acknowledged i haven't worked

26. 13:26

    on the core near um implementation really so i can't say as to like you know i like from a high level economic perspective i think the case for this um reducing the gas flow price is strong but um if the implementation details or um things were missing that would make it impractical in the short term uh i don't think so are you referring to coming from jacob yes i i i'm not saying words related to the current implementation is is jacob right right now here

27. 14:13

    can we invite jacob to to talk about his it seems like jacob is in the meeting yeah go ahead and promote jacob to a panelist hey jacob are you able to uh chat with us can you hear me yes yes great okay that's good um yes so i've written this message just kind of to give a counter point of like maybe from a user perspective yes we want to increase it but from a validator perspective maybe

28. 15:07

    the reasons why we don't want to do it and there's a couple of points and i don't think i can uh repeat everything right now i've written there but um i do think there is a good reason why we need a gas for a price and mainly it's because i don't think dynamic gas pricing works well for us if we look into the future with dynamic charting the way we handle increasing workload is not by increasing the price

29. 15:40

    but by adding more shards so ideally we're always like right around the gas floor price and if that's too low then we have a fundamentally broken chain that just financially doesn't have the balance sheet that it needs right now we don't have dynamic charging so we maybe need some way to kind of uh adjust dynamically um to higher workload and that can be by increasing the price

30. 16:12

    that might be more important right now and i still think it doesn't really work right now because um that is probably the part that is implementation related right now when you send the transaction to the near blockchain you decide the number of gas units you're willing to burn not the number of tokens you're willing to burn so at the moment when you send it you have to kind of before you send you have to check what is the current gas price and think how much could this gas price be increased

31. 16:52

    before my transaction gets accepted and executed am i willing to pay that price and my suspicion is that nobody does that everyone is just kind of like sending however they want so if we so if there is more load than the system can handle i think the people will not actually stop sending um transactions immediately because it's not set up that way right now and that's a bit of a concern for me

32. 17:24

    personally it's like should we decrease the price and saying like yeah the dynamic price will kind of work out fine i'm just i i haven't seen anything yet that we actually have dynamic pricing working so that's my main concern yeah i i think okay um yeah i think i can answer both concerns so for your first concern i i don't think it actually makes sense to think of you know blockchain as like a

33. 17:55

    as a company where the goal is to to make money right like the um we should think more about near as like a common good like a common infrastructure for people to use and in that regard um the goal isn't necessary for like the the infrastructure to to make money on its own and the reason why we have gas prices more to to to basically be like a simple resistance mechanism and to to prevent um someone from cheaply spamming the

34. 18:21

    network so that others won't be able to use it um and i think it in that regard i mean i saw your comment about like this inflow versus outflow i i mean i don't think that's the the the best way to to think about it because um you can like i i tend to think more that the inflation is just part of how um the the system works and and and it isn't necessary to say that the goal um at least in the short term is to for there to be no inflation um

35. 18:57

    i mean sure eventually maybe we'll get into a state where there's a lot more charge and then a lot more usage and then uh the uh the kind of the uh uh we would enter a deflationary state but i don't think that will happen i don't think that is the intention um released today uh now to to answer your second question um i think we should decouple this from what can be done on the protocol level

36. 19:22

    versus what can be done on the on the tuning level sure like um i see your point that you know people might not be able to react to the uh gas price change but i don't think that that is like a argument for not changing the gas price right because like even today you still can't have that dynamic gas price change and people can still uh go into trouble if they they don't check gas prices i think that's just something we probably need to

37. 19:46

    address on the tooling level so that developers and you know everyone who's using near and in the water whatever have that information available for people to to see and i think that is a more like a separate concern from how the gas price is defined on the protocol level i agree with the um statement there i think with or with um like the users not being able to respond to gas

38. 20:13

    pricing because that's absolutely true for um you know someone just using the near web wallet but a large percentage of transactions are automated um transactions from sophisticated players like if you look at ref finance today you query the transactions about half of them come from the top three users which are bots um so i think yes like while the the you know retail user may not um be able to like very easily adjust their spend um their demand is like a little

39. 20:45

    less elastic versus someone like market makers or people running arbitrage bots or other kinds of heavily automated activities yeah yeah i mean these are fair points uh you know i'm not saying we cannot move ahead at all uh i i just wanted to kind of add to the discussion that right now gas for price is not completely useless as it might have seen yeah i don't i don't think it's completely useless yeah if like well basically if we let's say we don't have uh this floor price then

40. 21:24

    as i said it would actually be quite problematic because then like uh people can actually cheaply spend the network stop others from using them we actually uh we actually have done a drill like where we actually exercise the scenario what what happens when people can infinitely spam the network and basically it's like everyone who actually want to use it would have to wait like 10 minutes for the transaction to get processed uh which which is

41. 21:48

    far from my deal um there's also oh i was just gonna say there's also a comment from amelia saying that uh more to add on the protocol economic side that the reality of token economics is that locking near in the financial applications has a way larger impact on reducing supply than spend on tax uh transaction fees and generally going to price fees will be important to improve the usability uh no i think what it is managed dollar price fees like uh basically having uh

42. 22:21

    gas price in uh in your stores versus uh in year um yeah i agree with that assessment i mean until until crypto flips fiat yes that is definitely the case yeah and i i do think uh part of the uh uh the reason why near gas price seems high uh is because um the near token price itself uh the the change in your token price over the past year like you know when your first launch states uh in your startup terms is much cheaper than um what it is today

43. 23:02

    yeah i think another key point when um i wrote the proposal was the fact that yeah when your price doubles and it's a volatile asset right this can happen on a regular basis your cost for a transaction doubles despite demand for block space or computation being flat right so um this is kind of a way of blunting that i think it's a fair point to say you know should it be you know one i i

44. 23:25

    proposed um dividing it by ten um maybe the decrease doesn't need to be that large i think there's pretty much um there's probably diminishing benefits uh the further and further you decrease it it's kind of hard to truly price like you know or decide a rational price but i think uh to uh jacob's point it's like some function of utilization i think if we're in the low single digit percentage um depending on what you think the near

45. 23:57

    network can handle at the moment like um there's room to maneuver to where like you still rely on a you know gas floor price but it should be like i guess you should find some target utilization um on each shard that would that would work um because yeah i think most um it's not like you know ethereum with a more dynamic fee market but um i think we can agree that with utilization at you know under five percent probably even less um

46. 24:29

    we could we could easily cut it without causing probably like too much of a problem whether it's half or um three-fourths like we can pick a number that would work yeah yeah and and also i think yeah since we have another discussion i think i kind of want to wrap up the discussion here so i just want to say that um everything we say right now about the long term is uh um it's basically established on the

47. 24:53

    premise that uh you know nero will become successful in in the long term right if um if if if near is always at five percent utilization rate i i don't think that's what we want and um and if we can do something right now that maybe it's not perfect uh but it can help the network uh grow and gain more usage so that we can be successful in the long term i think that is something worth doing

48. 25:18

    um and yeah i want to thank uh marco for the proposal as well as the implementation i think the implementation is actually uh mostly ready and yeah thanks a lot uh marco for for the presentation here and uh yeah anyone has a question on this topic if not we can move on to the next discussion i don't see any questions yet but yeah if anybody thinks of any uh please feel free to again drop them either in the chat or the q a box at the below

49. 25:55

    and uh thanks for having me uh thanks for your input bowen and jacob as well yeah thanks markup maybe i think we can potentially move on to the next topic which i think will require more discussion and yeah marcelo do you want to just start the discussion i don't know whether you want to present something or because this is a quite complex topic um yes i can present the very same eip i wrote

50. 26:45

    let me try to do it let me close the link first so this is the link to the discussion and i will be presenting this ap uh first of all for starting here uh mentioning that this is um like what we want to do in android is allowing developers users of course to make cross-contract calls from smart contracts inside abroad to near smart contracts just a little bit of how why this is possible

51. 27:17

    it's because agroda is in itself use a smart contract on top of near and you usually interact with a lot of infrastructure outside of the system but the code of auto rights gives a smart contract so that's double but it's not allowed today it requires the the aurora contract provide this interface it has some security risks associated with it that way it has not been done so far

52. 27:47

    so let me present my screen and share two main approaches that we want okay i need permission to share my screen is this something you can give me quickly otherwise i can share something with you try now give me a second okay thinking this will work now okay let's take a sponsor yeah okay so this is a link to the where we're having the discussion it's in the aurora forum but the proposal itself you can clone it from

53. 28:43

    you can find it on uh on eaps vera improvement proposals um so let me quickly go through the through the through this proposal not quickly but let me go through this proposal and then let's uh i will mention one other alternative that we were considering okay so just to recap the main goal is to provide cross-native contract call for our contracts so that we can have interoperability between auto and near

54. 29:16

    one thing that i want to mention is that aurora contracts provide this a synchronous environment similar to what you have from heating today of course when we introduce this like whichever contract uses cross contract calls would be exposed to the near asynchronous environment right so that we are not going to we're not going to avoid it so i think this diagram here should be good can you see it fine

55. 29:48

    okay perfect so basically let's uh let me introduce which are the components of the system and then i will go through the workflow we will have a user that will trigger the cross contract call we will have sorry we'll have a user that will interact with some contract in aurora the user will interact with this contract but we're calling it a source aurora and in the end what we want to happen uh is that if some conditions uh apply we are going to make a cross contract

56. 30:20

    call to target near target near use smart contract on near side right so how this will work is that we will allow this to be executed in two transactions but it could be packed in a single uh near transaction the main idea is that the user will initiate a transaction to abroad you notice that this is a near transaction but we can call it another transaction system since it's like uh sorry interrupt myself i think i just want to clarify this also for the

57. 30:52

    audience so when you say source aurora you mean the aurora contract as it is deployed uh near today right no i mean yeah but that's a third question uh it's the it's the well it could be seen as the aurora contract but in particular inside the aurora in the near order contract particular contract inside of aurora so okay okay okay so it's like a solidity contract we were talking about here exactly let's call it that way the solubility contract inside of our anyway

58. 31:24

    from the near perspective this would be a call to laura right so from your perspective it's called within the aurora framework this is a call to a particular solidity contract right so the usual the user will initiate a transaction can you actually see my pointer button just to know yep so the user will initiate a transaction and eventually again some conditional supply the transaction will call this a special contract inside of aurora this

59. 31:56

    is also solidity contract this is still in the aurora context we'll call the functions with all relevant arguments we're not going into the details about which are the arguments but let's assume we pass here all the relevant arguments for making the promise and they will be stored they will be stored on this contract and then the transaction will proceed so no promise will be executed at that point and then in a separate transaction and by this i mean in a separate near transaction

60. 32:28

    uh you will call like the same user will need to call async aurora which is a contract on near protocol like it's a smart contract linear that will execute the scheduled transaction it will basically go back to our router will pull the payload and uh and we'll execute the promise later when it receives the payload uh yeah sorry what is the nature of our router is it a uh solidity smart contract within aurora or

61. 33:02

    is it a uh it does sound to me like it's a solidity contract within aurora it is indeed yeah all the first interactions happen uh within aurora it's a single near transaction with no uh promises or no cross-control calls yeah our other router it's a solid smart controller inside of our yeah i guess you know my question is why are source aurora and aurora router to different smart contracts because source however it's just an application let's say you are interacting with a tree solaris and you

62. 33:34

    want to swap between yeah yeah sorcerer is not implemented by us it's implemented by developers it's a like a router uh uh okay okay i see i see i think that's where it's go source or is also like a sync provided by auroras like a company it's a good feedback i would probably try to change this naming but mainly the idea is that we have a source contract and a target contract and we want to make a cross-contract

63. 34:09

    call between source and target that's the the rationale of this naming the good feedback that it could be updated um yeah an aurora router it's a contract also inside aurora right so uh keeping with the explanation of these designs that okay you will be able to call austin cabra and a single aurora will pull this payload and will execute the callback and when executing this promise like uh

64. 34:42

    syncablera will be able to execute everything that it receives from our router and it should be uh good to go okay um so let's uh sorry sorry marshall i think i didn't understand the second part so async aurora is a contract on near right correct and how does it pull payload from our router is it like a cross contract call it does to pull the payload or yeah it's a cross-country call yeah oh okay so the dashed lines are cross

65. 35:14

    contracts this dashed line here and the second one is probably some notation abuse it's like the callback right in some sense it's uh it's a cross-contract call but it's used to promise that it was and you receive the payload the promise payload you will execute the accuracy the actual cross control only at the moment in time does it make sense no yeah it makes sense yeah it just feels

66. 35:57

    to me that there's some uh um overhead that may be expensive here like you're doing like multiple like cross-country couches to pass the contacts around so so here's the thing let me go through the rational about why we need a sim card the main point is that we don't want to have arbitrary cross-contract calls started from our directly because of our contract i can near usually you do authentication by verifying which is the predecessor

67. 36:27

    account id right so basically aurora contract has let's say admin privilege maybe over itself and in particular maybe that can be addressed but in particular it has a lot of tokens associated like all tokens that are locked through the bridge like from near to aurora they ex they are like on the fungible token contract and then 241 they belong to aurora country right so if you send i don't know you ascend

68. 36:57

    from near to aurora contract they will like have a near point of view those usn will belong to the rare contract and then you will be the owner like some uh zero x address will be the owner inside of order but basically we are allowed uh allow arbitrary cross control from aurora and even could potentially still those funds right calling from aurora by calling the usn smart contract

69. 37:30

    and like in general this is some particular scenario it could also be like handle uh case by case but we would love to just avoid uh having this complexity inside of the contract like having this potential security hole inside of the contract like we are allowing everyone to make a return cross-country call from aurora that's something we don't want and that's something you usually don't want in your contracts um mostly the one in aurora which is a whole ecosystem right which it holds

70. 38:03

    like a lot of stuff like it's not possible but supposedly it would be possible somehow to trigger some uh i don't know upgrade the contract by calling itself somehow right that's the type of stuff that we need to avoid uh at all costs so that's why we need that's why we want to have a synchro and we need syncoda basically you will be able to call asynchronous from any other contract but the sim card will be a contract with no privileges it will yeah yeah i understand basically the

71. 38:34

    whole purpose is to pass through the call yeah yeah we want to yeah hide all the complexity of starting from aurora uh completely uh in the design rather than uh rather than analyzing case-by-case in the code where it's easy to miss some stuff right um if guinea capune is uh asked to speak uh on this topic real quick um but before that there was an earlier question just to clarify from someone they asked um aurora so aurora source router and

72. 39:11

    native all live within the aurora account on maintenance is that correct a resource on a router yes they are both solidity contracts inside of holder and a sim card it's a near contract um the same target here yeah gotcha cool and then yeah if kenny um go ahead you should be able to speak okay so what i want to say regarding this authentication parts marcel is right that we don't want arbitrary cross

73. 39:45

    contract calls from aurora and near contract but another issue that we need to think about is that the same near contract aurora represents multiple contracts within aurora and so the target near account needs a way to authenticate a specific contract within aurora so i don't see how the current design handles this so basically if it just checks predecessor account id in near it will see that it's yeah so it has address of the message so basically the

74. 40:32

    so basically the call from asynchronous to the target contract it shouldn't be just arbitrary call where the source aurora contract supplies completely arbitrary function name and message because because in this case the target near contract will not be able to authenticate the specific source aurora contract so probably there should be some call with a specific signature which will include

75. 41:05

    the address of the source contract so that the target contract would be able to trust it and then there will be probably so it should be not arbitrary function call it will be probably a specific con function like call from aurora and this function will have an argument that is an argument that is the contract the address the predecessor id essentially within aurora and then some payload and then if it's a specific function

76. 41:44

    it can be called directly from aurora contract because it's a specific function so it will not be confused for example with api of fundable tokens it will be a different function name and it will not be confused with any other things that or a contract can call it will be basically a special function that will be only used for this purpose yeah that's uh definitely possible right that we like as part of the standard rather than doing this we

77. 42:21

    only allowed to make calls to specific functions that we create like this is standard it's not very different than what we have today but it would remove part of the back and forth i want to highlight one thing is that in this approach that allows uh two transactions uh it allows to one of the good things well one of the good things that i didn't mention is that all this approach it could be executed in a single near transaction albeit it will be a little bit more expensive right than

78. 43:01

    if you would do two transactions but the process will be mostly the same but it will be initiated in a single run the second thing on this regard is that it will allow users to make uh two different transactions right it will allow the user to split their transactions over or to transactions when they want to make a cross-contract call outside of the system that could have its own benefits in some in some use cases so

79. 43:35

    well in some sense you need best of uh both worlds but uh i do like this alternative that you are mentioning about a specific method on another contract that's something we didn't ever wait uh but that's also another alternative that would decrease the complexity right because if this is a special method that won't allow running a special code that should be fine like well i also want to suggest an alternative uh which is like the the problem is that

80. 44:15

    you want when like let's say i have a triceratops contract that was called outside into near account like the near contract needs to ideally somehow being able to identify that this is a chai solaris right and so the one way to do this is for aurora account itself to serve as a factory for this uh kind of proxy accounts for each evm address so you can actually have edm address dot aurora which is a proxy for all the outgoing

81. 44:49

    messages that that evm address wants to send and so this way in here it will be specialized address dot aurora account that will be interacting with your accounts so pretty much and so your aurora is just like your aurora contract just needs to route the message to it's to the respective edm proxy like let's say tresolaris.aurora and then that one will actually interact with near and then pull back aurora with the response approach will that require deploying any

82. 45:31

    contract every time and for every new others that makes a cross-country call yeah so this will require the having i think this is a great idea except that it's going to be expensive right like it'd be great if you can if you can use that proxy without having to deploy a contract on the yes so this is where the delegate keys proposal and account extensions coming right because the idea there is like we need this pattern a lot

83. 46:00

    like there's a mask support that needs this and a lot of other things and so yeah then it's we can actually optimize like because it's going to be the same contract deployed many times we can actually not charge for it yeah yeah yeah you want like a module you can you can import yeah yeah well that like you can actually today deploy run execute the transaction and maybe remove the deployment like delete the

84. 46:25

    contract and you probably don't win anything by clicking the contract but yeah i mean the proxy contract right now like the the minimal size was like eight kilobytes i think or something so it's not and then i mean you know you can actually force the the contracts that actually call out to pay because it's not going to be users like it's not going to be from user space it's going to be from a contract space anyway so if they want to call out they they just need to you know

85. 46:54

    pay a little bit uh i mean and and like long term we should just you know allow same contract to be used without extra chemicals i think that is actually abusable right because then users can abuse it by like trying to call a lot of different contracts and then like it just like trained the balance of the whoever is paying for that and this is like create a lot of like those proxies and and like it it seems like an attack factor to me

86. 47:32

    no no because only the contract itself will be able to call these subcontracts right so usa exactly won't be able to trigger this pulse on another conflict we only want to be able to tell three solaris that aurora to make a call an aurora will have the lawyer that prevents other users to do it okay and carrier points out that like that maintenance burden which is true but um i mean it's it sounded like you have like sorcerer router which is also made of burden and also like by splitting transactions actually

87. 48:15

    it makes it super complicated this is actually possible in a in a single transaction after gasoline yeah i definitely think it would be much better if can be done in like a single transaction and that's a much better user experience for like our users we didn't consider this a suggestion by jenny i just listened to it just now and i think it's a good situation that addressed both parts right it's uh kind of secure from the restaurant point

88. 48:53

    uh we just don't want it to allow like arbitrary cross control in the very beginning when we were not thinking about authentication we were thinking about allowing arbitrary function calls on methods but anyway that we are right now providing authentication this means that the target near needs to support in some way the the current standard so if we are already forcing the target construct

89. 49:18

    to support some standard we might as well enforce to implement a particular function and that that should be enough yeah yeah but i mean requiring near near contracts to support like receiving messages for aurora seems pretty heavy well you you don't need it right you can't like for example if i'm a developer somehow i'm interacting with refinance i can like refinance doesn't need to know about this we can deploy like the developer can deploy another controller that implements this interface and

90. 49:55

    interacts through this proxy to refinance right that's also possible uh that is more heavy for the developer right like well it's pretty much you're pushing the thing i described to a developer right yeah without doing it yes yes i mean but there's also security issues now on the developer side they need to deal with around like like the asset ownership and stuff like this because like so so here's example right i'm i i'm try solaris i want to do a trade on finance right my assets are actually

91. 50:27

    on aurora account like they actually under our account so i need to be able to pull them out of our account and then trade it on our finance and put them back into our account like on near in near a system and then and then make the updates on my site right and so it needs to actually work in sync with uh on talking receivable inside aurora contracts because that's what's gonna happen when like i trade on refinance and so if you're pushing it on completely on

92. 50:57

    developer side to figure all this out like i i don't even know if they can like you you need to actually have aurora contract to manage on talking like all the near callback stuff needs to be managed on that side but the callback will not be managed by the other contract will be managed by the proxy contract right so that's what i'm saying like that that doesn't work because then try solaris doesn't have this money so again like

93. 51:23

    let's say try solaris wants to do a trade on under finance they need to actually withdraw funds from aurora account and then put them put the new font into aurora account otherwise they don't have them in charcel art unless there is a mirrored account for trisolaris that actually maintains all the balances going forward that sounds very complicated i mean it's complicated but it sounds the a lot of complication is exposed to the developers this way but it sounds to me

94. 51:57

    that it should be possible i of course i think the approach you suggested it's great but we cannot do it today right that's right you can it's i mean it just can't be a lot it's just more expensive yeah i mean i can't make deploying new contracts okay yeah yeah and and you can force it on developers to do it so like you don't need to yeah okay it's like 0.008 near i think so like the minimum proxy contract i'd say

95. 52:28

    nice thing yeah so this will be basically like some sort of stateless contract that we only have yeah and then like you know i can push the burden onto our team to push this like proposal to have uh the modules and global yeah actually what is the status of that discussion can you sure well there hasn't been active discussions recently yeah we can maybe discuss it next time so i mean i can share the

96. 53:03

    some of the old discussions but yeah i think we're kind of running out of time uh josh do we want to wrap things up here yeah sure um yeah there's a there's a couple minutes left um michael didn't make a comment i just want to make sure that uh you guys got it so that the the current proposal can do it all in one transaction just with multiple callbacks and he thinks the flexibility of allowing it to split over multiple transactions is an advantage because aurora transactions can use a lot of gas so

97. 53:34

    being able to do the aurora and near call separately could enable more complex use cases i don't know if anybody has a comment on that i mean i i think like developers can always decide to split into transactions i just like that's not like setting that as prerequisite is kind of limiting but if developers want you can always have a 235 cover you can always kind of record what you want to do and then call

98. 54:05

    the recorded stuff cool yeah um yeah we got like three minutes left so yeah if anybody has a uh final any final comments or questions oh it looks like we have one uh when's viper on aurora that's more interesting than doing cross-contract calls on aurora near matthias is asking sorry you didn't get the i didn't get the question fight wins viper aurora biker is that oh but it's the language right it's

99. 54:46

    already supported because aurora supports evm it's not available it's everything that compiles 3vm so if i understand correct bypass just another language right so you can compile it to evm by code and you can deploy the number it should be working i would expect if i'm not missing something cool awesome well i think that's all the questions that we have yeah i think that's watch marcelo and

100. 55:16

     if genny and all the people that have joined the discussions and very very awesome and uh uh yeah definitely a lot of food for thought here um so yeah thanks everyone for joining um we will be posting this recording in a couple hopefully tomorrow the next day uh so keep an eye out for it on youtube and also we'll post the links to the discussions that we're having both on the governance forum uh and i believe

101. 55:39

     yeah there's a uh the aurora post that we can uh add to that video call as well um for your raw enhancement proposal or improvement proposal sorry the aip um but yeah feel free to join again next month same uh time the second thursday of the month and uh yeah thanks again we'll see you next time see you guys bye