Protocol Community Meeting (May '22)

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

1. 0:10

   hey everyone welcome uh if you're just joining this is the pro public protocol meeting that we have every month at the second thursday of the month uh same time at eight o'clock uh pacific and um yeah today we're going to be talking about uh increasing the gas potentially on a single function call in addition to the the regular status update and kind of what protocols actively working on

2. 0:40

   so yeah um go ahead and do some introductions and we can go ahead and get started with the presentation uh bowen would you like to introduce yourself uh yeah hi everyone bowen uh probably already know me by this point uh but yeah i lead protocol research and development at pagoda yeah michael do you want to introduce yourself as well sure hi everyone i'm michael i work at aurora

3. 1:04

   which hopefully most of you are aware at this point is the evm compatibility compatibility layer on mir okay uh okay josh i'll go ahead and share my screen and get started cool yeah and uh as we're doing the presentation at any time you have any questions please feel free to ask them there's a little q a button at the bottom just go ahead and uh click on a question and just fire them off uh

4. 1:37

   as they come up and uh we'll uh answer them uh at points in in the presentation where we think that it's the most appropriate so go ahead all right cool uh let's get started uh so yeah the agenda is basically we'll first do the protocol updates and then we'll have the a discussion with michael on increasing customer made for single function call uh hopefully it's going to be interesting discussion uh uh yeah this is like we did not rehearse this before so i don't even know how

5. 2:07

   that will go so we will see okay so i just want to uh kind of give everyone update on what's coming next so the 1.26 release is going to mainnet next wednesday i think and there are actually quite a few feature improvements and uh fixes um so first of all the uh the client the new core client can now set the time of the pro to upgrade in the client what that means that before that time even if you adopt a new version uh it wouldn't the protocol

6. 2:40

   upgrade would not happen so it would start actually counting your vote your upgrade uh starting at that point uh in time so uh it just solved the problem uh before of some people uh kind of not not noticing the release and then upgrading their notes late and then they would kind of not be able to sync with the network after the network has been upgraded so this is a in our opinion a better way of doing the upgrade

7. 3:12

   and i should mention that it's not the case that the protocol will upgrade at exactly that time what happens is that after that time the the essentially the the vote will be counted and then uh the upgrade process would actually happen and then uh if things goes according to if everyone has actually upgraded this point then it should actually happen to epochs afterwards um okay so another notable feature is that uh the splitting of unused gas to attach to promises that we've discussed

8. 3:44

   i think maybe at the last meeting of the meeting before um so there was a a problem of like people writing uh smart contracts that involve cross-contract calls uh that that they often run into this problem that they need to kind of hard code the amount of gas they need to they want to attach for a a promise and then uh the problem with that is that one it's hard to predict how how much gas exactly you want to attach uh and the second that if uh if if whether you actually if the promised car actually consumes variable

9. 4:17

   amount of gas uh for example you do some storage related operations uh then it's actually difficult to set a hard-coded amount of gas so oftentimes people have to kind of give a much higher number than what it actually needs uh so this uh what this does is that they would actually split the they all use gas at the end of uh function calling to the promises uh it by default it was pretty equally but you

10. 4:41

    can specify by weight how much uh it the the use you want the unused cash to be split in addition to the hard-coded amount you specify so essentially you can do both it's not one or the other is you can do both um and and uh this we also talked about this before uh this caching of chinos to save gas um storage operations i think uh from uh uh actually michael's preliminary benchmark uh there is going to be a 20

11. 5:11

    uh gas saving for our transactions uh it's harder to say in general for near transactions because if the transaction is quite cheap or does not involve a lot of storage operations obviously the saving would be less uh but in general like yeah we are pretty happy with this change um and then we have this uh database compression that should uh resolve the or i should say mitigate the uh the size of the um the archival node storage uh

12. 5:41

    our maintenance our experiment shows that it would reduce the storage requirement for carbon nodes by 4.5 terabytes uh i i forgot the number on testnet but i think the other one i mean that's probably more important for everyone here uh so that's going to be a pretty huge saving for everyone who needs to operate an archive window and safe database migrations uh so essentially what this does is that uh if there is going to be a database migration uh in a release then you will

13. 6:12

    first uh write a checkpoint uh have a checkpoint write the snapshot and then and then start doing the migration and if uh if during the migration that fails you can still roll back to the snapshot and the database wouldn't be corrupted and we also have this uh kind of somewhat highly requested feature that you can specify the number of epochs you want to retain the data so before this number is hard coded and every node who enables who is not

14. 6:43

    archival node would retain data for five epochs and now you can configure this number uh in the config.json for the node um and there's also a bunch of security and performance-related fixes and and we'll keep working on more of them uh around around performance and as well as uh observability of of the neocore the client implementation of the protocol so yeah that's uh a lot of stuff in this release uh hopefully that's a useful

15. 7:14

    summary here um okay so yeah i'm actually reworking this uh this view of what we're working on uh for the entire broadca hopefully we can i can provide a much better view of this next time uh i understand that uh it is uh some something that we have not done very well historically of communicating the uh uh the the current work uh the current focus uh that we do on the protocol uh and yeah i'm actually working with uh josh and devrel on trying to

16. 7:47

    improve that so hopefully i can give a much better update next time okay so yeah josh do distinguishes start with the discussion or should we um yeah i don't i don't see any uh questions yet um but yeah again feel free to ask any questions if you have any questions about anything that was just presented uh please fire him off now um if not or if something comes up later yeah continue to

17. 8:13

    go ahead and post it in the q a section or in the q a button at the bottom and we could probably answer uh questions at the end of the discussion as well but yeah i don't see any questions right now but um but yeah um so yeah let's go ahead and uh have the discussion about the increase in gas limit and then yeah again if anybody has any questions or uh comments please feel free to uh to escalate oh we do have one that just came in oh um just to make sure the epoch feature would be available for the

18. 8:45

    index or nodes as well uh that's a good question it should be uh well actually i i i don't want to say that for sure because i'm not entirely sure how they configure uh their notes i i think should should work um but they have please check with the uh uh their team to uh to to confirm cool cool cool um yeah that was the the only question but uh yeah please feel free to keep keep firing away and we'll we'll answer them as we go um but yeah we can get go ahead and get to the discussion okay yeah so i just want to kind of give

19. 9:25

    a background of what exactly we're discussing here before i actually start the discussion uh so so right now uh we have uh this uh there is essentially like two gas limits that we have uh on here so one is this um trunk level gas limit um and it's set to a thousand tear gas uh this is essentially measures the amount of compute that can can be done in one chunk or is entering in one chart at every block

20. 9:57

    but there is also a separate limit for a single function call action meaning that if you call a smart contract there is a separate limit on how much gas you can consume in that function call and that limit right now is 300 targets it used to be 200 tera gas before and we actually increased that to 300 targets so the the the there is as you can see there's a difference between this number and the per chunk uh gas limit and this the difference is actually pretty large um

21. 10:29

    so the problem with that is that now we have seen more and more uh well at least a non-zero amount of expensive transactions is actually running out of the the gas limit of the uh the function called the single function call gas we made of 300 yes and but my understanding is that if let's say in this extreme case we actually um have those two numbers being equal uh basically for a single function call you can

22. 10:58

    attach a thousand tara gas then i believe those transactions would have been fine um so this is this essentially blocks some use cases uh maybe especially for aurora i think michael can talk more about that uh and i just want to know that this isn't necessarily something that other blockchains do um for example instagram doesn't have like a separate transaction uh per transaction customer i believe their transaction can consume as much gas as they won't as long as it stays

23. 11:29

    within the block instrument uh so yeah that's kind of the the background um yeah i think we can maybe start the discussion yeah michael feel free to jump in yeah so that last point is is sort of the the big one when we're talking about aurora because when people are moving their their dapps over from ethereum to aurora they essentially just want to port everything directly as is and on ethereum because the block gas

24. 12:00

    limit is is quite high people sort of assume that occasionally doing a really big transaction is fine and this ends up happening for for example rare events right think about if you're a defy lending platform and a position ends up getting liquidated that liquidation transaction can use up a whole lot of gas because it's effectively like a loop over all of their assets and and doing some operations on those and loops are like sort of notoriously expensive on on ethereum

25. 12:33

    so when you're just porting your logic one for one it's fairly common that these you know rare transactions these rare events end up being too big to fit in the 300 terror gas limit so what we've been doing at aurora and you know this is still something that we'll continue doing regardless of the outcome of this discussion is improving the efficiency of the aurora smart contract in its

26. 12:59

    execution of evm byte code so that effectively you're getting more evm gas per near gas than than we were before and we've made like leaps and bounds in in this regard so we have got gotten to the point where you know 90 95 of of transactions on aurora do fit in that 300 tera gas limit and of course the the upcoming um storage cash uh upgrade will also help with that um but but again we still have these sort of like long tail rare cases where i just don't think it's reasonable that

27. 13:39

    we'll get them fitting in 300 tear gas but fitting in a thousand hair gas does feel reasonable you know we've done some kind of back of the envelope style estimations on things and it seems like you should be able to fit a full ethereum block into a full near chunk if you're just trying to line up say the amount of computational work that's done in both and and yeah maybe michael you can give uh a bit more information on that like

28. 14:11

    what just like on the use cases that you've seen uh what is the kind of maximum amount of near gas that a transaction on aurora would consume so we we try to whenever we see uh out of gas error in the wild capture it and and measure it in a local environment that has no limits that we can see what the maximum is and usually it's sort of just hovering outside of the the range like you know 320 or something instead of 300.

29. 14:45

    um but every once in a while so right now we've actually got a benchmark um as part of the aurora code base that currently uses i think 720 terra gas and and this this was a transaction from a game it was some kind of like bookkeeping xp uh you know reward claiming something or other i didn't i didn't exactly follow the details of what exactly it was but the point is it's very similar to this uh liquidation use case that i was just talking about where it's an occasional event that just does a whole bunch of

30. 15:24

    bookkeeping on a bunch of resources and so it ends up using a lot of gas but again it's an event that doesn't happen that often um so liquidation is the other big example i don't think we have any liquidation benchmarks currently but i've i've sort of seen around 400 500 tear gas for for for those events when i've um profiled them in the past um and then the other big one that doesn't exactly fall into this category

31. 15:56

    of rare event but i think is still currently outside of the 300 tear gas is flash loans because flash loans are kind of a similar idea where you end up um doing a whole bunch of work um and and in in uh importantly the middle bit is a variable amount of work right like if you're writing this sort of flash loan defy contract the parts that you write are the you know borrow and then you run some unknown code that

32. 16:29

    the user has has provided and then you make sure that the loan was repaid or you revert the whole thing um so your parts at the beginning and end use some amount of gas and then there's some unknown amount of stuff that the user could want to do in in the middle and of course flash loans get used for things like arbitrage which could involve multiple trades across multiple different contracts

33. 16:54

    right you can you can definitely make really complicated transactions out of these things and so again we've seen examples where it exceeds 300 tera gas um i don't know exactly what the what the limitation on this is but of course if we do get all the way up to a thousand tera gas for a single function call uh i i feel like almost certainly everything would fit in there especially as we continue to improve the efficiency

34. 17:19

    of the edm on aurora so that we get again as much evm gas per tera gas as we can yeah so i guess maybe another question regarding this is that uh michael do you know uh for those super expensive uh transactions uh where do they spend most of their gas is it on like competition as you said doing the the loop which is notoriously expensive uh it depends so in the case of the video game that one was actually mostly

35. 17:51

    compute um which is which is still kind of interesting to me like i don't i don't really know what it's what it's doing under the hood there but okay you know i assume it's not doing anything more than like adding subtract adding and subtracting some numbers so the fact that it uses so much gas is a little bit crazy um but i mean that that is not actually efficient in israel right like at adding like adding numbers because like that's that's right it is not very efficient on

36. 18:16

    ethereum and then there's sort of like an extra layer of indirection because we are interpreting evm byte code inside a wasn't vm so that's very inefficient but um yeah we we do hope to continue to improve that but anyway so yeah that one's mostly compute um the liquidation transactions i think tend to be a lot of i o a lot of storage operations because those ones you're updating balances across a bunch of different contracts usually

37. 18:48

    and so you end up writing a whole bunch of keys and for flash loans it's probably variables again because sort of the biggest chunk of gas is the user provided code in the middle um that could be a bunch of compute but it's i would if i had to hazard a guess i would say more often than not it's going to be storage because the um operations like doing swaps on exchanges tend to be mostly storage

38. 19:21

    and most of the storage is reading not writing right because you you end up sort of reading um say the uh approval amount of a whole bunch of erc20s if you want to do those swaps you end up reading um just like the contract code out of these uh out of these um slots right because you have to basically in the evm go into the storage pull up the the evm code that we're going to interpret next and this is all happening in watson of course right so on mirror

39. 19:52

    this just looks like big storage reads and if you and if you call you know 20 different contracts as you're going through this arbitrage process in your flash loan then you know that ends up being quite a lot of io a couple questions oh i'm sorry i didn't mean to catch up on oh sure go ahead yeah no there's just a couple questions uh that people had um what one is uh what would be the downside of just

40. 20:18

    removing the gas limit all together what would be the implications of that uh all together you mean like removing the the per chunk gas limit as well yeah just like no gas limit like oh yeah then the what can happen is that uh people can maliciously attack the the blockchain by kind of sending a lot of other transactions so that is the one chunk takes let's say takes a day to process uh and then what will happen is that the chain essentially starts for one day

41. 20:50

    got it got it and then one one other question is uh is the chunk limit big enough to fit an entire ethereum block uh is a thousand tara gas enough in theory it should be we haven't uh there there's there's some complexities here because there's not a great uh mapping of ethereum gas onto near gas so when we ask the question is a thousand tera gas enough for any arbitrary execution that could have been done on ethereum in an ethereum block the answer might might

42. 21:30

    be no for for an arbitrary execution because again the mapping is in super precise you know some operations that are cheap on ethereum can be expensive on near and vice versa for example contract deployments inside aurora tend to be very cheap in terms of near gas even if they're very expensive in terms of evm gas um of course that that side of things you don't really care about when we're talking about just making things fit um but on the flip side there you can occasionally have you know a uh an

43. 22:02

    ethereum transaction that does a lot of work um but for whatever reason those evm op codes are not costed very heavily and then when we go and interpret it in mir it becomes a whole bunch of wasa mop codes for whatever reason uh and then it looks like a lot of gas on near so long story short is a thousand tear gas enough for an arbitrary ethereum block in theory it should be we should be able to make the interpretation process

44. 22:33

    efficient efficient enough so that it's possible as of today it probably isn't but i think the more important question is is a thousand tera gas enough for the use cases that we actually see so these these video games these d5 transactions and i think dan the answer to that question is yes there's a pretty narrow range of op codes and operations that these contracts tend to do and if we heavily optimize those we should definitely get them to fit in a thousand tera gas

45. 23:06

    and then just around round out this this discussion uh about uh how much stuff you could fit into a thousand tera gas um neer takes a very careful approach towards trying to correlate gas and compute time and this is related to what point was saying about making sure that the block time can stay consistent around one second right so one thousand tera gas is around one second of wall clock compute time under assumptions around you know certain hardware requirements on your node um

46. 23:40

    so what this means is basically can you compute a whole ethereum block in one second that's sort of like what the question comes down to and for any benchmark i've ever read about ethereum the answer to that question is definitely yes if you were just on a bare metal ethereum node you can always compute all of the transactions even in a full ethereum block within one second so hypothetically that means we should be able to do it on near as well it's just a question of how efficiently we can do that interpretation inside wasm

47. 24:13

    yeah i mean that two layer of virtualization definitely has non-zero overhead um but yeah i think as michael said uh there is no need to focus on any pathological cases right now because uh this isn't even like a angle of attack like if you if you try to invent some you know evm contract that would uh fit in a certain block and then doesn't fit on near but that doesn't do anything useful like i mean there isn't actually a point because if you try to run down here you still pay for the gas cost even

48. 24:47

    if the transaction fails uh because it runs out of gas so like there isn't there isn't basically no point in actually doing that so um as michael said we actually should focus more on use cases that we actually see okay um yeah i think maybe we can transition to talk more about um you know the the feasibilities of uh potentially increasing the uh the single function call uh gas limit um so there are actually some reasons uh i

49. 25:22

    mean people might be wondering why why the numbers are different um there actually are some reasons one is that basically let's say we actually increase this to uh the same same gas limit as per chunk then there will be two problems uh why is that we want to have some safety of margin uh for like a single call um single single function call so that uh let's say for some for whatever reason uh we undercharge uh there is uh some on on the charging on near and

50. 26:01

    and let's say a uh a function call can be uh i don't know cerax consume cerax more workload time than uh what the then the gas then how much more clock time it it should consume so basically um you can think of like a function card that consumes 300 tera gas but actually uh takes roughly one second to to execute uh so under the the current situation uh what we can do is let's say if we discover that as an emergency exit maybe we can lower

51. 26:34

    the the broadcast limit uh to uh other chunk estimate to let's say uh 300 tera guys or like 500 tera guys uh to kind of uh uh uh until we actually fix the underlying issue of that on the charge uh now if we actually increase this to be the the same gas limit as the chunk the chunk has limit then um if we decrease our limit then essentially that means that uh certain transactions uh that would uh uh that would fit into the casper mid will start actually not fitting into the gas

52. 27:05

    uh which would be like a which means that certain contracts may suddenly start failing on their own like nothing essentially like the contract is just like you know working fine suddenly stop working and people might you know the users of that contract might gets super angry um and that's in general something we we won't avoid doing uh basically breaking contract that has already been deployed

53. 27:28

    uh so that's one thing and another thing is that is more specific to how we charge gas today essentially the way we do it is that we kind of compare the cumulative amount of gas we consume in receipt execution after the receipt has been executed so what that means is that in theory today you actually can consume a maximum of uh 1300 targets in one chunk's execution despite the limit being uh one thousand

54. 28:03

    tera gas because uh let's say your last receipt after reaching the limit is actually three hundred tera gas uh and somehow all the received before accumulated uh 199 tara gas then we're still going to execute that uh last receipt because we don't actually know how much gas uh it would um consume before uh before we execute it we already know that it can consume a maximum of 300 so you you may end up consuming

55. 28:34

    uh 1299 tera gas and if we change the number to 1000 then like suddenly you can consume uh 2000 tara gas in or close to two thousand targets in one uh in one chunk and that would actually have a uh significant impact on um on the block oh that may have a significant impact on the block time so that may reduce the block time from let's say one second to uh to uh uh every two seconds which is that last uh that last issue

56. 29:04

    there should be able to be fixed in the in the node itself right like if if instead of always setting the maximum gas to whatever the limit is set in the transaction you can set it to whatever is like the the minimum between the limit of the transaction and what is remaining in the chunk so if you only have one tera gas left in the chunk it'll run for a bit and then immediately stop

57. 29:29

    it's like non-trivial logic of course because you have to distinguish between a case of oh it ran out of gas because it hit the transaction limit versus it ran out of gas because the chunk was was full so we gotta you know do it try it again next time um but but you know i do think that that sounds surmountable anyways yeah yeah i mean it definitely is a uh a solvable problem and the question is like do we actually want to do that because that is also a protocol change

58. 29:55

    right it's a change that changes the the behavior of the wrong time so yeah sure so that's why yeah it should be it should be discussed uh so basically there are two problems i just talked about one is regarding the kind of the safety margin the other one is kind of how the gas accounting currently works yeah i mean if i was king of near and got to make whatever decision i wanted i i would i would push for the the

59. 30:28

    protocol change uh at the very least of the uh current accounting the safety margin thing is is a different question like that's that's you know a question of like risk tolerance and yeah i i i admit i don't know enough about the gas estimation infrastructure to know how risky it actually is to uh increase the transaction limit to equal the junk clip and effectively removing that safety margin and of course like there's there's i

60. 30:59

    guess a sliding scale here right instead of 300 it could be 600 and uh and and then you still have some margin but it's smaller and you know i guess there's there's probably some optimum there depending on your risk appetite yeah yeah so so yeah right now we're pretty uh risk-averse uh in terms of setting that limit um but uh yeah as michael said that we could potentially consider uh changing that number to a larger one uh assuming we addressed the second

61. 31:28

    problem which is uh yeah easier to address um yeah so the the the i think one of the reasons why we're being quite careful here is that we've seen in the past uh that there are certain inaccuracies in our estimate and we were and sometimes we were able to construct uh pathological cases that actually consumes uh much more clock time than it actually should uh and that's why uh we have been pretty kind of careful with this and uh and don't really want to increase the

62. 32:03

    uh the limit drastically um but yeah uh i think that's you know there's still a pretty uh wide band between uh 300 tera gas and 1000 terabytes um so yeah i think potentially some some compromise could um could be made and um yeah for example michael like let's let's say hypothetically we increase this to 500 tear gas uh how or rather from your perspective what is a what is a number that would make the most sense for um or i guess the most uh

63. 32:45

    the most the optic i guess i guess optimal is not the best word um uh maybe the most uh it's like uh pareto optimal like way of of doing this um yeah what do you think um i mean all else aside uh you know sort of ignoring the the potential of of mis estimating costs or or being able to construct these pathological cases you know higher higher is better right like uh always there will always be another use case is sort of what we found so far especially as we've been doing these optimizations

64. 33:27

    like our experience has sort of been like okay we we've over the past uh you know four months or whatever we've we've increased the um amount of ethereum gas that can fit in uh in a near transaction by i think almost an order of magnitude so you know initially people were like oh yeah we'll be happy with a 20 increase we'll be happy with the 30 increase but then you know that sort of is the rhetoric we keep hearing so you know here we are 10x later it's like well we'd be happy with another 20

65. 34:08

    increase we're like okay you know we'll keep doing our best here but so i mean for from that perspective i feel like there there is no optimum it's just always higher it's better um from the perspective of you know what what have we seen so far i i think that like 720 750 tera gas is is the highest like real use case i've seen um again and actually presumably that would actually be lower if uh after this release after the 1.26 release right

66. 34:40

    which is correct yes yes that's right that will be lower after the uh after the storage caching improvement um and that's the other thing right it's not just about the limit it's about the efficiency right and so even even on our end we want to always be improving the efficiency so we can be fitting more ethereum gas in in each tear gas so i mean i think at the end of the day we are happy to accept whatever limits you guys want to

67. 35:13

    give like if you want to just go up to 400 you know awesome we love it that's that's great if you want to go all the way up to a thousand you know wow we are overjoyed you know can't can't believe it um but uh yeah there there will i i believe always be another use case that someone comes to us and says oh you know this doesn't quite work on aurora so there will always be more work to do

68. 35:36

    on our end well i mean michael this isn't like a decision we should be making single-handedly or like more generally like the protocol should not be in the in the hands of like a single team or a single entity right that's why we're having we're having this discussion i think if there is uh you know sufficient uh amount of uh uh you know people voting for it or like people thinking that this is a good idea uh then yeah we i mean we should actually uh seriously consider

69. 36:09

    changing this um because you know we i think yeah we should always do what the what's what is the best for the for the community and to support uh you know as many use cases as we possibly can while maintaining the safety and the uh security of the of the protocol yeah and also i think i think another aspect of this is like you know we don't have to go like all the way at once right like uh

70. 36:34

    because you know if you increase it by some amount you can always increase it a bit further if later down the road we uh we have more confidence in our uh estimation of the of the gas costs and uh yeah absolutely yeah um okay so yeah um i think maybe someone from aurora can submit a uh ap pull request to propose some number and then we can have a discussion there on how exactly we want that number to be and and also the uh the implementation as well um yeah

71. 37:13

    cool that that that sounds good um i guess and another another question for for you bowen is do you know of other projects that are hitting the gas limit and would like to see it higher uh actually yes so well in that case it matters less for them so sweat coin would actually also hit the the gas limit in or in a sense because what they're doing is essentially they're batching a whole bunch of the um the transactions together into one transaction this is to mostly reduce the

72. 37:45

    the overhead of sending multiple transactions because you also consume the uh the function called base cost pretty much every time and if you can like somehow batch it into like one function call then uh you know you don't you don't pay for that base cost every time and so they want to essentially batch as many as many transactions together uh as possible uh and that's why they would also run into into the

73. 38:07

    same problem of like uh one in one function call you can only fit uh you know 300 tara gas worth of kind of compute and they're actually their use cases it's pretty much all like storage read and writes essentially there's oh well no there's still some computer but it's like quite uh minimal i would say like maybe it's actually similar to like the d5 use cases on aurora as well um so yeah they they uh the need there is not as strong because you know they

74. 38:37

    always can break it up into multiple transactions it's just that it'll be uh it'll be definitely more desirable for them if there is a higher gas limit for a single transaction a single function call sure that makes sense but otherwise i'm not aware of anyone who is running something that just like uh just like in terms of doing like one function call would actually go outside

75. 39:07

    of the um the limit of one one function call action yeah i guess uh jordan gray in the chat here mentioned earlier that uh another possible use case that has sort of variable gas limits is custom function calls that get approved by a dow so i assume this is like triggering something based on a vote oh yeah i didn't i didn't i didn't really know what uh use case they have there like uh jordan do you want to join us and maybe talk about it

76. 39:45

    josh can we can we is it possible to yeah yeah i can bring him on hang on all right yeah it should ask you to rejoin as a panelist there you go hey jordan hey thanks for having me up um yeah so the dow use case is that uh people will put together a string of transactions and then propose that to a dow and predicting the gas for that can be especially difficult um so a lot of times they'll try just like throwing 300 tear grass gas at it and just guessing

77. 40:35

    uh so that's where we see it see the gas limits being hit a lot um oh interesting so so they actually hit the gas limit in practice what do they actually do um oh what what the calls are um sometimes it'll be things like uh creating a mint-based store or minting an nft uh buying an nft things like that okay the transactions themselves i don't think they're too gas heavy but it's just like figuring out the gas ahead of time and predicting it is the hard part oh so you're saying they're trying to do

78. 41:16

    multiple calls in the same transaction in the same function they do it like oh okay i see i see i think that seems to be i mean that seems to be a separate problem it should be mitigated by the feature we have in this release where it will actually spread the unused um gas equally or i mean you can specify the weight uh to to the all the promises that you create in that function call uh

79. 41:39

    so that um so that you don't run kind of out out of the uh the hard-coded gas gas number you put there or like i mean if if you think it's especially to equally split them then you can even omit the hard-coded gas number and they would actually just automatically split the the rest of the of the gas equally to each each promise so cool yeah looking forward to it thanks thanks for the explanation yeah sure thing uh okay yeah josh i think maybe it's good

80. 42:12

    time to have to do some like q a do you think that's yeah yeah absolutely okay um yeah so if anybody has any questions please feel free to drop them uh in the question and answer portion um or you can just drop them in chat i'll monitor both areas but but yeah we'll open it up for any any questions anybody has about this or any topic on protocol yeah also i think if people have

81. 42:43

    questions about aurora presumably michael can also answer them yeah i'm definitely happy to chat about that as well not a lot of questions people are a little a little shy today okay nope imagine one of those tumbleweeds rolling through the zoom call that's uh lib mill um just commented but uh but yeah um yeah we'll give it another minute or so and see if anybody has any questions

82. 43:33

    otherwise i think uh maybe we could end it early jordan did you have something else to add i didn't i just accidentally left i meant to pop down back into the audience but over there stuff that came up gotcha gotcha okay yeah i can uh hear you i could change your world to an attendee uh cool i got one question would aurora support other vms in the future um that's an interesting question um

83. 44:07

    that's not something that is on our roadmap we've been focusing pretty exclusively on on ethereum i know that there has been work so aurora of course is not just the evm engine there's also the the rainbow bridge under the aurora banner and i know that there has been work on a uh binance smart chain bridge as well so hypothetically aurora could start by expanding you know its bridges to other networks and then we could in theory i guess

84. 44:40

    think about doing like a native port of their uh virtual machine whatever that happens to be as well do you have a particular request for for a virtual machine you'd like to see no guarantees about whether or not we do it just curious about what you're what you're thinking yeah let us know let us know what you're thinking uh polka dot maybe yeah uh but polka dot doesn't have a wrong time on their own right like they the actual stuff happens in the parrot

85. 45:20

    chains yeah that was my understanding as well and that the parrot chain run times are like they can't implement themselves yeah exactly they're not they're not standardized yeah and then the whole thing is so basically essentially astronomers is wasn't based it's okay like they um yeah that essentially all their validator would just be able to run some watson code and then uh that's just how

86. 45:45

    they execute the the runtime or the transactions from power changes jordan commented octopus for substrate uh dapps chains wait i'm a bit confused on what is that a a comment or like a question or like it says octopus for substrate uh dap slash chains right oh come on oh yeah yeah yeah okay uh technically not a blockchain iota is going strong on wasm assembly network yeah i mean i guess uh short answer is aurora

87. 46:29

    is open to considering other other vms if there is you know suitable uh interest in and having that happen and of course if uh you know if someone is is interested in just like kickstarting that themselves you know starting you know a private project and then you know gathering a little bit of uh momentum in in the community of course you know like aurora can always provide some resources for it even if it's not officially funded by

88. 47:00

    by by aurora potentially like we you know we we are always trying our best to be a good near community and ecosystem contributor so you know we just want to see the ecosystem growing in general gotcha jordan clarified he said we meant to say was that you can run you could actually run polka dot dapps on near using octopus network um yeah any other questions i i have uh i have one question i don't know um yeah it's kind of it's kind of a big one but something i've been thinking about like as we're moving into sharding

89. 47:41

    and you know moving contracts um you know in the future it'll be like dynamically changing based on contract like if one app blows up we'll move that you know contract to a different shard aurora is one contract so like as you continue to grow and grow and grow in size like you know what happens when aurora becomes too big for one shard and you'd have to have multiple aurora contracts

90. 48:04

    and then they would start interacting with each other and now they're no longer synchronous i don't know it's a whole it's a whole big wormhole or a rabbit hole that that i've been thinking about but i don't know if you guys have thought about it i'm sure you've thought about it um but i don't know yeah no you you you totally nailed it that's like that is exactly the the sort of thought process that we've gone through as well

91. 48:28

    and and getting you know the the asynchronous uh basically simulating a synchronous environment in an asynchronous one is is not super easy so we our current feeling on the matter is we probably will not go down that route and instead probably at least to start with have independent aurora shards where they don't talk to each other or at least they don't talk to each other very much

92. 48:58

    you know there's bridges between them of course so that users can move their assets around but you won't necessarily be able to do an atomic smart contract call between contracts on on different aurora shards and and uh you know sort of medium term that seems pretty uh like like it covers most of most of the use cases right like if you're talking about things like a game where it just uses a lot of gas but doesn't care very much about

93. 49:30

    interoperability with other contracts because it's all sort of self-contained that kind of thing can definitely live in its own its own aurora shard and then of course the value that aurora is providing there is the fact that you can have written this game or the contracts for the game anyways in solidity and have the front end assume a web 3 interface and aurora can you know give you the ability to deploy

94. 49:54

    that civility contract and provide you the web 3 compatible rpc for that right so it still is providing value even if it's not providing exactly the same you know experience as ethereum because you can't you know arbitrarily call whatever contract you want if you live off in your own chart um but as sort of a starting point for for scale that seems that seems pretty reasonable of

95. 50:18

    course that model totally doesn't work for something like defy where atomic interoperability is the name of the game right like composing defy uh primitives and and into bigger d5 transactions and composing those big ones and even bigger ones right that that is what d5 is all about and that of course requires them all to be co-located on the same aurora shard so uh you know we'll we'll we'll keep thinking about that one you know and and see see where we get with it but uh but yeah definitely it's

96. 50:50

    something that is on our minds awesome thanks michael um yeah i haven't seen any other questions come in i guess one one last call for any questions for either bowen or michael um otherwise uh yeah we can probably wrap it up a little early um yeah we'll give it just one more um ah tatiana asks what is the plan for private shards uh well i mean that's i don't think either of us

97. 51:19

    would be the the best person to answer that uh so yeah uh josh can you send the link to calimero do you know their website um oh yeah that's right um yeah i can find it okay i i mean actually i already found it so there you go you're already on it there you go and uh yeah so i actually i don't know the the details of what exactly they're doing but yeah if you have questions feel free to

98. 51:49

    reach out to sandy uh who is running the uh karen marrow awesome cool cool uh any other any other questions another another last call cool well sounds good uh i think we can probably wrap it up a little early uh yeah i appreciate uh michael for joining the call uh uh yeah no problem thanks josh and bowen for having me this was a good discussion appreciate it and thanks to all the participants for

99. 52:30

    the for the questions it's always nice to see engagement yeah absolutely um is there there's not a current discussion um async uh or online there's not an ep for this right not yet not yet well yeah as soon as you have uh uh something uh drafted or or even if you have like a governance post that you wanna further further have the conversation that we can link to uh for the youtube video viewers uh when we post this after the call that would be awesome but yeah uh thank you so much everyone

100. 53:09

     for joining uh super appreciate it and um yeah we'll see you next time thanks everyone see you bye