NEAR Protocol Community Group Call – March 15, 2023

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

1. 0:06

   thank you very much everyone for joining hi my name is Aki uh this is the second protocol community group meeting the last one took place three weeks or four weeks ago roughly that time kind of time period um for those of you who are new um this is a community group for people who are interested in the near protocol adding features to it following developments to it um just interested in extending the near

2. 0:40

   protocol and contributing to it in various ways um so the format is uh fairly straightforward um it's a free free fall discussion we're not taking any decisions here and so on Ori and I are posting the call but we're not by any means we're just here to facilitate discussion and uh encourage people to contribute and uh and just moderate a bit and we will also be taking notes and we will try to summarize the meeting offline

3. 1:19

   uh afterwards and I believe this meeting is being recorded so please keep that in mind if you want to share something that is security sensitive and so on um all right is there anything else I should add more or do you want to add something no I'm just excited to be here and see everyone and uh yeah quite a bit of topics so cool yeah so last time we had done uh like a or in introductions where people talked about who they are and

4. 1:52

   where they're from but like we got feedback that that took a bit long to do uh so maybe if somebody's uh you know want to say a few things about themselves Maybe please use the chat to do that so that people can read that offline uh and I would love to see people uh uh do that and but in the meantime we can uh let's get started and um so these are the proposed topics that we have uh and this is just based on what people

5. 2:23

   have proposed offline on various forms um and before we dive into them is there any uh does anybody have a strong feeling on any particular topic that they want to discuss first or in the order of the the topics here or should we just take the uh discuss them in the order that it's listed there right I don't say any big any uh comments so we can just take them in the current order then so garbut uh why

6. 3:05

   don't you start off something maybe you can start us up by introducing yourself a little bit too yeah absolutely uh so hi I'm garbet uh I'm from electron labs and uh so we have been uh building in the near ecosystem for more than a year now and uh I think our core contributions have been around ZK technology and one of the coolest things that we've built so far is a zika like transfer near

7. 3:30

   and uh going forward uh we are building a basically a decentralized bridge uh between ethereum and near uh that is actually already live on test net uh and uh it's a it's a basically a bridge very similar to the rainbow design that it's powered by light Giants uh except that uh we're not running these lifelines directly on chain but rather than uh creating ZK proofs of these like Clans uh which means that our uh like Trend

8. 3:57

   verification on chain is uh around 200 times cheaper uh which allows us to follow validity proofs approach as opposed to Rainbow so rainbow takes like 16 hours for a transaction to go from here to ethereum while using our approach or it takes us a couple of minutes because we can submit proof directly for each header right uh so yeah gearing for mainnet as we speak and uh while building the ZK technology for this uh Bridge uh realize that it has a lot more applications than just uh light

9. 4:28

   clients and and scaling in general and that is when I know the discussion with the on the protocol group I posted some questions that if if this can be actually used to scale the number of shards that Mia can handle at this point and uh yeah what I'll be presenting today is along those lines only uh I won't be presenting any I don't have any concrete ideas to present today that you know this is exactly how we can scale but the purpose of this presentation

10. 4:53

    would be sort of educational and just triggering his own thoughts maybe hopefully some from some of the core team that how to apply ZK where does it currently stand and what is the road map in terms of uh ZK technology itself going forward so I'll just summarize those things uh so I'll just try to share my screen at this point uh uh can you guys see my screen yeah great uh by the way government is do you have a link to this that we can share with

11. 5:26

    everyone later I will I will post a link to it I don't have immediately but I will okay thank you great oh yeah so I'll just get started right so I'll be talking in context of some of the work we're already doing uh because then we can actually talk about what we've done and uh you know show some numbers around uh yeah so basically uh what we've done so far uh is basically create a ZK proof of the near Lifeline uh so that essentially has three parts computationally speaking uh

12. 5:56

    one is the header Fields uh such as tracking of the voting power of each validator for example uh the second part which is the computationally most expensive part is the signatures of the valuator themselves the Ed 25519 signature scheme and finally we have the transaction vocal proof which allows us to map a particular transaction to a given header and uh in the current design uh what we've done is we've

13. 6:20

    created a ZK pover for the signature scheme itself so we can take in a batch of 100 validator signatures and create a sussing proof of that and uh if you want to verify these tools directly on Jail uh it will cost you millions of uh millions of gas and thousands of dollars on a per transaction basis uh but in our case uh we create uh we are able to verify these signatures for uh uh 227k gas right and add to that some of the overhead of the headers and the local

14. 6:50

    mobile proofs we can actually verify a single transaction and an entire header for 1.1 million Yas and these are actual numbers from an actual implementation that is live on test net today uh for the bridge that we have done uh in terms of gas cost uh in transaction cost it basically means uh 31 uh today uh and if you were to compare that with let's say without using zq compression uh we are achieving around 50 50 x scalability uh assuming

15. 7:21

    that we only have one uh 100 validators as the number of editor grows on here uh uh we basically give you around 200x scalability uh using the ZK approach as opposed to a non-zq approach where you're directly doing this on chain uh and this is basically a comparison with the current rainbow-based design also because this directly on jnrs of today right uh so these are actual numbers you know this is not Futuristic number this is actual implementation number that we have tested uh now if you talk about a bit more

16. 7:54

    about this approach this has a couple of limitations because it's using broad 16 as a system uh which means that uh it takes a lot of time to generate these proofs uh for a full value data set we can take up to 16 minutes uh and we can only prove up to around 100 signatures as the number of values on near rows will not be able to prove them and we just have to create more and more tools right and this is because with broad 16 if you go above a certain

17. 8:20

    amount of computation being proven uh it gets computationally more and more unfeasible to do it so we kind of hit that limit here and we can't really go above 200x scalability as of today uh so this is this is currently the implementation that we have uh that is live right now in our Bridge now of course these are quite a few limitations and if you are saying that we are infinitely scaling here we have

18. 8:42

    to do a lot better than this uh and that is where some of our future owner comes in something that we are researching right now and planning to start Devon this very soon uh so this is the concept of recursive groups uh something that Mina protocol does today or if you might have heard about plan Q2 for example or this is this is this is being done by zkeems also today uh so proof recursion is a very simple concept that you can actually create a proof that a given

19. 9:07

    proof is actually valid right so it's a proof ZK proof of a proof and uh it's quite trivial for a signal proof but it starts to become powerful when you start combining these multiple proofs together so you can create a proof that multiple proofs given to you are actually valid right and uh it gets really powerful when you actually scale this out uh so you can basically Supply a large number of proofs on the left side and successively uh recursively combine them

20. 9:34

    together and create a single aggregate move so this single from the right is proving all these proofs on this left side and every single one of these tools could have a large amount of computation being proven so every single one of these tools could be for example a single header a light client header and then use this single proof is proving let's say uh last 12 headers in a single to move right uh and the advantages of this approach is

21. 9:58

    as you can see that you can basically take advantage of parallelization here uh you can virtually have these millions of proofs being generated in parallel and then being combined together uh in a single group right uh and uh the big best property here is that the limit of uh parallelization has been the limit of number of machines you can get together uh together in a single instance and uh

22. 10:22

    this basically now scales the proving time now scales logarithmically now right so the more computation you have you basically uh so if you talk about pronky 2 for example which is the state of the art when it comes to recursive technology uh within within one minute you can prove trillions of constraints right and if you if you just go back a couple of slides uh over here we were proving uh

23. 10:45

    256 million constraints in 16 minutes but now with blonky two uh you can prove trillions of constraints and actually not just in virtually infinite constraints uh with an upper limit of one minute it doesn't really go above that because we have log scaling now uh and with one minute I think there's a theoretical roadmap that is all also people are working on this is slightly theoretical uh but people are working on

24. 11:09

    Hardware acceleration and uh even Advanced schemes compared to plonky 2 uh which will bring down the cost of roof generation to single digit seconds for very large amount of computes now uh once you have this kind of a technology uh and if you zoom out a bit uh you basically essentially have here is a computational compression engine which can take massive amounts of uh proofs or computation that needs to be proven and reduce it down to a very small amount of computational uh

25. 11:42

    verification cost right and uh ZK generally works with computational compression only that's the whole idea behind it but if you apply it a bit smartly uh you can actually reduce the data and the network requirements also quite significantly as means in certain cases right so I believe that Alexa at this point no one really has this in the market in terms of a generalized engine and I think this is a massive

26. 12:05

    opportunity uh for for us to actually grasp uh to build this right uh and let's get to straight away the use cases for it uh so the first use case is actually one that we are also building for ourselves so what you can do here is you can create a single proof that proves the entire consensus of the linear blockchain since Genesis so you download a single proof and that's it you have you have the entire chain being proven to you right so this removes the need to have any trusted RPC clients uh you can actually uh run a live client or

27. 12:39

    actually almost a full node inside a browser or the client side and this basically enables trustless bridging where the cost of the bridge and the overall performance of the bridge is very close to what centralized bridge is offered today right uh and uh just to add here you know as a side note uh this is again very much for the future that if you can somehow create ZK proofs of

28. 13:03

    the VM execution also the rust VM that we have uh we can actually turn near blockchain into a constant size blockchain where a single proof is essentially proving the entire history of transactions right but yeah this is quite theoretical uh something beyond our scope at least at this point but yeah at least the ultralight client thing that we've already started to research on uh and uh this is one more slide I just added just to kind of

29. 13:28

    summarize some of the thoughts I had a chance to discuss with a key on the protocol working group and woven also on the on the zulup chat uh so some ideas that I want to mention here that can actually help scale so the first one is uh something very similar to how Roll-Ups work where uh a single transaction right uh can be replaced with a proof and you don't actually have to do any consensus changes there you can simply put the zika proof inside the

30. 13:53

    transaction and this proof is actually proving a large number of other transactions right so you basically get this uh virtually Infinite computational Space in inside a single uh near block right so without increasing the number of charge you are able to increase the computational block space uh that we have available uh we'll we'll have to obviously think about how the data or requirements change here but at least we get rid of the computation overhead

31. 14:18

    another idea is uh that we can actually build constant size uh block headers with respect to the number of validators so as the number of values grows on here and it gets to let's say millions of validators uh we will have this very large block headers which can become increasingly costly to share around across charts uh and we can actually simply create a proof of validity for all the evaluators and actually not have

32. 14:41

    to add any of these uh these validators inside the uh inside the block header uh this similarly this can be extended to improving into short communication reducing the data requirements inside it uh again I'm still very much a noob in terms of uh Nightshade and the consensus and I'm not sure what data is being sent across uh but if some of the data is being sent across to verify something on

33. 15:05

    the other side I think this this kind of concept can really help uh uh yeah and I think Ilya also mentioned quite a while back around six seven months back that he does believe that Ezekiel has some potential there although I'm quite not sure at this point how that will work and that is where actually the protocol working group can come in uh yeah so we have already started to design the sockets uh for how uh the

34. 15:30

    light client will essentially fit inside plonky too uh and we are planning to start the dev on this very soon probably this weekend we already have some internal papers that we've built uh and uh yeah that's pretty much it and just wanted to mention again that our bridge is live uh which uses the current circum implementation not the prompt you do one and uh yeah that that's all I had to

35. 15:52

    present today thank you very much for the presentation Garrett that was very informative uh does anybody have any questions for any comments in General on the it looks like Bowen typed one question in oh no I think it uh or the answer that yeah I mean I was I was going to ask you exactly the exact question of why not using prank YouTube but the copia is already answering the presentation um so I mean yeah I think cross 16 is

36. 16:26

    more like a I mean technology moved very fast right this should not already consider like a older generation of proof systems yes yes yes precisely yeah yeah uh but they're also on the point of uh scalability yeah I think this definitely is the future um so I think with Decay um so I mean if like the the bottleneck of the system is purely execution then there's not much uh they can help because like someone still have to do the execution

37. 16:59

    um even with other they keep roofs but they but I don't think that is reporting that per se for us right so I think uh for us the the major bottleneck in the future will be um communication overhead and also uh kind of the verification overhead energy in both cases uh yeah the key proof is definitely uh the way to go in terms of uh resolving those bottlenecks yeah so when do you think we might start

38. 17:31

    hitting those kind of bottlenecks but we know or when do we need such technology yeah sure I mean the short answer is I don't know uh and the the long answer is I distinguish the current design can maybe scaled to a hundred yards I hope um but I think you know if you ask a question of how do you get to 10 000 shards I I'm pretty sure that we will hit some like bottleneck somewhere uh and I think that's where like you know if we have

39. 18:01

    um if we get to the kind of Holy Grail design where each Shard is pretty much like a JK roll up uh then yeah I definitely think it's possible for us to scale to uh something like 10 000 shorts but yeah I I think um the main problem there is like there is a long way to go to actually get ZK Watson to work right my understanding is that they are you know people working on it um but actually making sure that things

40. 18:37

    work properly and it's uh I I mean I think it's still like in the early stage of uh research and implementation when you say ZK wasn't do you mean proving uh whatever transaction the smart contract executed or yes yes basically basically the the end goal is that the entire there is a proof for the entire State transcription right so uh Moana had a question here all right so uh when it comes to interchart communication uh would I be correct if I said that or

41. 19:25

    from one shot to the other You're simply sending a lifetime proof uh of the first chart to the second shot while you're doing this cross cross shot communication would that be would that be like a correct assessment or a um I think partially yeah I think for the everything you need to prove that's kind of true but what the main problem there is that there's a lot a lot of like a data communication overhead right let's say um you want to

42. 19:53

    um for example um you the the I think the cross-sharp part is um it's okay but let's say you want um you want validators to rotate and rotate into some short red it's uh that that means they need to download all the data they need to let's say they need the state to actually verify that uh um there's some to actually execute some some broker chunks uh and then that that overhead is pretty pretty big right and then for the uh for the cross chart

43. 20:26

    communication that's mostly just sending uh kind of receipts between between different shards uh I mean yes that is also potentially getting like pretty going to get pretty big uh with the number of shards okay so yeah I think like if downloading the state is the limitation uh yeah I think uh yeah I'm not sure how it could help you there maybe there's some way uh but uh yeah again I don't understand actually yeah I think yeah so the the where exactly what happens you don't

44. 21:02

    need to download state right like if there is a proof for the entire State translation then like you uh everybody really just need to Value the the proof because today what they like the reason why they need to download stage because they need to validate the the uh The Shard and then the new state to actually do that uh and put you know which uh wish you could proves that's not really necessary called got it

45. 21:29

    okay but I think I think yeah we're talking about like not what's going to happen this year maybe even next year probably we're talking about what's going to happen like a couple years down the line cool I know that there are other topics on the agenda but I guess just to wrap up um I guess yeah is there any Next Step uh or request like for for government or the community now that we've talked about this yeah so from from our side actually we

46. 22:02

    are discussing this very actively in the VK working group uh so I I do have some requests to make but I think that would be the right uh platform to do that uh for this working group I think the goal was to just kind of introduce this idea that this kind of Technology where does it stand today and so that uh people thinking about protocol can start thinking about it that's all I think uh yeah yeah and for me personally I actually

47. 22:27

    don't know a lot about this technology it's still pretty new to me and uh so the more I'm getting introduced to it the more I'm learning about it and then I would love to find more nails that I can use this Hammer with you know and I'm sure we'll we'll find more use cases for it So yeah thank you very much Garrett and yeah I'm very happy to see your involvement here is any other comments for Carmen before

48. 23:00

    we move on to the next uh uh next topic all right um so I think uh the next one up is uh men who wanted to show some solutions for the congestion or proposed solutions for the congestion problem uh Min are you around in uh yeah I'm here um okay so I guess I'll propose sorry I'll share my screen um can you see my screen yes um okay so this is uh like a short design doc I wrote uh for the like I guess part of the solution that

49. 23:57

    will affect developer experience the most for the congestion problem um I will share the link of the stock uh later and uh please feel free to comment in the dark um like if you have any uh after thoughts um so um like to be honest the design is not completely finished yet there's still some unsolved issues I actually just realized some new issues this week um so really the uh kind of like the

50. 24:34

    goal of this presentation or discussion is to kind of gather more input um like different viewpoints from like everybody from the community um to see what are the you know potential uh impacts and so we can work on fix those so as a context uh to what's what is the congestion problem so basically we are worried that once near gets very popular um the blockchain will start to accept a lot more transactions then it can handle what will happen then is the transaction

51. 25:14

    will actually be queued up in the system they will be accepted uh but it will take a long time for them to um process like so right now when you once the transaction is accepted it's like it gets processed very fast but if the blockchain gets very popular it's possible that that delay will increase and in the worst case actually the delay is unbounded and we definitely do not want that to happen so as just consider

52. 25:50

    like an example so let's say that we have near social contract which is very popular and the new social contract sits in one Shard and like users can actually submit transactions that call near social from any shard so it's possible that uh just like in one block this on your social accepts The Shard of near social actually accepts more uh computation load then that block can handle so let's say if I submit like

53. 26:29

    every every Shard submit uh like full block of transactions to near social and then all those loads will actually need to be handled by The Shard that were near social it's sit at so that shower will actually though those transactions would just be queued up in the system um and then a backlock will start to actually um start to form in the near social Shard and if the com traffic keeps coming in this back clock will only just grow longer and longer

54. 27:08

    um so it will like the new transactions will actually take longer and longer to be problem processed and SSI in the worst case the latency is actually unbounded um and that basically makes you know social usable um so Solutions uh what are the solutions to this um we are considering multiple different approaches to um the problem um a few of them actually both require um the protocol to kind of break the guarantee that we provide today to cross-contract costs so today

55. 27:52

    um if the developer attached enough gas to a cross-contract call we actually guarantee that the cross-contract call will succeed um we actually think that this is almost too strong of a guarantee that protocol provides so as so today actually everybody if you submit a function call everybody just attached 300 hair gas um where it's actually like the transaction the program doesn't doesn't know at all how much

56. 28:30

    the transaction will actually spend but furthermore actually it doesn't know where which way which contract this gas will be spent I can submit um I can submit a transaction from mindanaire and but eventually it could go to social Diner which could go to another contract um and uh so uh this all kind of lead to the problem that the protocol can't efficiently limit the input to the system that's like the source of why the protocol could potentially accept more

57. 29:19

    computation loads than it can handle so so one solution we want to propose is that to break this guarantee which means that we no longer guarantee that a cross-contract car will always succeed if you attach enough gas um uh we well obviously we understand that this is a very big decision and impacts everybody in the ecosystem uh so we want to make this transition as smooth as possible uh which kind of lead to the kind of the two options we want

58. 30:10

    to provide to contract developers regarding to how their cross-contract costs will be handled so the first option is that so basically it's very similar to what you have today except that basically you have to write new callbacks um like right today I think a lot of the contracts already write callbacks for uh cross-contract costs to handle the failure cases um so if you choose this option since in the future like cross contract call any

59. 30:52

    cross contract call can fail so it's actually required that people write callbacks to handle the failure and this option uh we actually guarantee that like no cross contract call we don't provide any guarantee for cross-counter calls but we'll actually do guarantee that callbacks would be executed so as long as you write your callbacks that handles the failure cases of cross-contract calls

60. 31:23

    um the contract will actually uh be okay um the second option is that if a cost contract call fail we actually don't drop the con transaction immediately we simply just pause the transaction and the system the protocol will actually store the intermediate receipts so that the transaction can be resumed by the user later um the kind of Main difference of this approach from today

61. 32:08

    is that somebody needs to pay for the storage of these receipts because they will be stored by the system um so in this proposal we asked the contracts pay for the storage for receipt they create because we don't want to increase the uh upfront costs for transactions if we ask users to pay for it then we actually increase The Upfront cost for all transactions which is undesirable um however because

62. 32:49

    like then we we basically ask contracts to pay for this and the contracts will have to put a certain amount of money in their uh contracts to cover like the temporary stake for uh storing receipts um the storage the sake for these receipts will be refunded to the contracts after the receipts are executed so these uh storage is actually the stake is that it's only in charge temporarily so if you put

63. 33:30

    let's say for most contracts we estimate that 15-year will be enough to cover the storage for its traffic um yeah so this is basically uh the solutions that we're thinking about um the questions were like to ask to the community is that so basically we want to have a better understanding of how people handle like how people view about to cross-contracts cost today like do you actually write callbacks um or like like how often do people just

64. 34:23

    play not write any callbacks and just assume that we always attach a lot of gas to transactions and just assume that running out of gas never really happens um is there any questions yeah any feedback or questions from it yeah Alexander uh yeah yeah I have something um I would say that uh you know the first perception when you're talking about cross-contract goals it you know it kind of ring a bell because as a developer of smart contracts

65. 35:09

    uh cross-contract callbacks are most I would say painful and not really cool part uh um From perspective of uh development experience remember we have a topic of developers developer experience uh in this meeting and so I don't think we always develop Implement callbacks for the cross-contract calls but probably um in the end of the day we had to create many callbacks and many of them um are are implemented in a style of

66. 35:56

    some like implicit prediction or implicit requirements uh just because of uh different feedbacks from fellow developers and security audits that you don't handle this situation from this situation so the second part of my message is that proper handling and proper implementation of callbacks um also introduces or not and but it usually introduces security issues and security problems you know kind of almost always when we get some security

67. 36:36

    feedback from security audit uh it lays somewhere in the uh you know callback implementation so I don't think I don't say that what you say is completely you know like um is a bad idea but if you want to introduce option one uh where developer needs to trick with the cross-contract callbacks uh you know callback handlers um then it's probably better to introduce it somewhere deeper in the near is Decay so developer don't touch it

68. 37:14

    for sure and it introduces backward compatibility issues so we have to you know merge contracts to the new SDK but I you know if we face with the real congestion problem then we just don't have choice but anyways keep in mind that uh yeah callbacks and callback topics are kind of painful part in all this development experience yeah that makes a lot of sense uh okay uh so so like so what do you do today about your

69. 37:53

    cross-contract cost then I just you know accept the reality I mean um uh yeah could you specify this uh your question beside of this um yeah could you please what do you mean what what did with cross contract I mean like we just developed because uh we have to uh handle some business level uh cases I would say you know it's not that like we are um forced to create cross-conduct uh you know cross-counter callbacks uh

70. 38:39

    handlers uh yeah um I would say that for people who doesn't uh who or who never developed uh contracts for near protocol that Handler is a function which is called when the cross-contract call has been ended like you know and um it's usually is um executed uh in the context of the next block so it's kind of it's not uh synchronous I mean yeah yeah I see I I um well yeah I I think we can Implement

71. 39:25

    something in the SDK level uh but like like the specific logic of callbacks will still have to be determined by the contract because the SDK doesn't won't know what to do yeah yeah we usually have to create conditions like if the previous If the previous transaction a previous function was failed then do this else do do something else and it's literally I have to copy paste code from my old contracts like if promise is not succeeded like do

72. 40:09

    that it's already like kind of complicated so if I have to add another condition I will fail for almost sure and um let's think about Junior developers they they I think they struggle with it mm-hmm what if what if uh I don't I don't know if it's possible or not uh this is not my space but what if he had some sort of static analysis tools that could uh evaluate your contract and

73. 40:42

    highlight such issues right uh you could build your contract and run it through this tool and it would try to Pro give you some warnings I don't know if that is possible or not I mean how difficult it would be to build such a tool but that could be something that could help maybe or what do you think Alexander as a quick question I would say there are two uh took two cases one is ideal

74. 41:13

    and another is uh not ideal I mean the perfect case is that uh SDK has to provide you know means to develop contracts uh safely and that's it you know the model should be safe like a rest so uh rust without unsafe is developed in such a way that it's like 99 percent is safe and you like you expect there are no um uh side effects and such a tool which you mentioned uh would like just to work around I would I

75. 41:52

    feel but maybe if we don't have choice it would be my second choice you know and now we can use chat GPT just to drop there is a contract and you get your vulnerabilities that's it we already Christian questioning I see Russian Rises his hand ah question all right maybe it's a mistake yeah Michael made a comment that maybe uh there can be some macro magic to convert

76. 42:55

    asynga right into callbacks under the hood um yeah that can that's also a good interesting idea I mean that is what is happening with the rust ecosystem right when you're using async Gateway you can rust right effectively yeah when you use basically that converts it into these poll calls in the background and yeah so we could maybe do something similar so So Gone I was just gonna say this this I think sort of avoid some of the pitfalls that

77. 43:28

    Alexander was talking about because the async await usually leads people to write this nice imperative code that's relatively easy to follow that usually doesn't do something too horribly wrong and then as long as the the macros are are robust then uh you know you sort of offload that complexity from the developer and they just get to live in this nice world where they sort of read their code

78. 43:52

    line by line and it's like oh yes I do this I do this cross-contract call a wait for it to finish and then check the results make sure it's all good Etc do whatever logic I want with it afterwards and then of course in the case that there is no um no handling you want to do afterwards the SDK could automatically always return a result object so that so that at the very least the rust compiler is warning you about an unhandled result if we were talking

79. 44:20

    about this you know requirement to have callbacks always something like this I I think I think it'd be tricky to get it to work properly but um it might be you know a good future direction to go in so we actually have an example of this in the from another blockchain where async Gateway it's a the internet computer uses async Gateway for doing cross-contract calls so whenever you want to do uh whenever you whenever your contract calls another one

80. 44:52

    uh the the rust SDK or the SDK provides an async uh framework for doing that so you call the other smart contract and then then when you call a weight on it you essentially return you yield and you return out of the function and when the response comes back from the other contract whether it's a success or failure then your contract is uh restarted and continues from that point onwards and it relies on the rust uh ecosystem like the functionality that Russ is providing to build all of that

81. 45:29

    out so I was trying to find an example of that uh uh online but I couldn't find one quickly but uh maybe later on I can post something on Telegram yeah that's that's really neat yeah I think that kind of thing would be would be really nice to see in the near ecosystem as well of course it's equivalent to the callbacks thing right it's just the Asic await is a little bit easier for developers to parse yeah and it doesn't have these pitfalls that

82. 45:55

    Alexander's talking about that it forces you to effectively forces you to have the call back then so yeah and I think to summarize it depends on how you introduce this uh work around or feature I mean if we solve the problem of uh congestion um if we're talking about option one so it depends on how we introduce this change and it would be nice to see some more easy natural way to you know handle it yeah so

83. 46:33

    like we we our we're not saying we're definitely gonna we're only gonna introduce option one or option two like we could potentially give you the option of you choose which option you want so the the job I often do is like the contracts will need to pay for a bit more money for the storage uh of receipts or this money will be passed to you the users but it's like temporary money but you still have to put a little bit more money um in

84. 47:10

    you're a contract I feel like the option I'm sort of taking the time maybe we have to switch to another topic but just as a final note from my side about option two is that it seems more tricky and um I I feel like Adventure yeah if you know playing with gas is always at some bad experience just keeping in mind uh uh what do you mean by playing with gas uh I'm sorry uh I mean that if the option to is around some gas calculations

85. 47:56

    um maybe I have to dig more into the option too but uh um it just feels more tricky yeah option two increases the amount of storage staking that you need to do right so you need to stake more tokens yeah it's not about gas it's about you need to oh yeah okay okay um yeah see someone else has a hand up I just noticed that uh not sure who the uh yes yeah uh yeah I thought we have a solution it doesn't require us to drop receipt right is there some problem with the solution

86. 48:36

    you mean the solution that you proposed I think it's Robin Wright a professional solution yeah Robin asked Robin solution also requires dropping risk it doesn't the system doesn't drop directly but if the simulation is wrong the receipts will fail it's gonna happen less likely but we still need to handle that the simulation is wrong oh but that's not dropping receipt right that so in that case receipt would fail because you run out of cash right that's similar to how it felt today

87. 49:14

    yes but what happens today is that you just always attach enough gas like at least you have an option of doing that but like if you have like the simulation then like it's kind of out of develops control I'm I'm sorry I think maybe we're going a bit too deep into this and uh I wonder if we should maybe move on to a different topic because I don't think everybody in the call knows what Robin's proposed solution is so

88. 49:44

    yeah okay sounds good yeah uh or well before we move on though I mean uh does anybody have any more feedback for Min um any other comments for her um is there a place that can share the stock like do you have a telegraph yeah yeah there's a telegram group yeah yeah um you can ping me offline and I can send you the link and so on okay thank you all right cool thank you man um so we don't have a lot of time left uh

89. 50:22

    but I think we had great discussions so far so I'm happy that we did the uh that we did that uh orange Joe uh or Joe uh do you think we can discuss the development experience experience in the next say five minutes or so or do you think we'll need more time I mean we can start the discussion and we can continue it next time too uh yeah sure we could yeah we could start I have a little different perspective than Alexander maybe so again let's kind of give some feedback and then uh next call we can go more into it sure

90. 50:56

    sounds good yeah so I'll give a quick overview and then I'll kind of dive into so I um I come from a very heavy web to background before going into crypto uh I built a lot of platforms like SAS based platforms uh really heavy into API driven type of work when I started building on near a little over a year ago um what really uh attracted me to it is before even getting into the smart

91. 51:27

    contracts is actually uh how impressive the API SDK is and that was actually what kind of hooked me at first and so I think it's a really and where there's such a push for like you know hey anyone who knows JavaScript can kind of come into the ecosystem for myself that was building a lot of you know back-end systems to be able to have a really robust um API SDK really kind of hooked me like

92. 51:57

    oh okay I can do a lot of really interesting stuff here and then as I transitioned into building actually smart contracts um that transition actually was easier than I when I tried on other chains so I did like the whole thing I think everyone kind of did for a while right I tried out solidity I tried to build something on eth um you could do all the basic stuff and then you go a little bit more complex um it was not as intuitive for me so I

93. 52:26

    kind of backed off um I've had a job in the past year too where I've been building on some other chains did some work on this and I I did some work on Aptos uh and when I compare the work I did there to the stuff I do on mirror um it's really like a breath of fresh air to build back on mirror it is really so much easier and more straightforward even like where I know as a problem we're working out a lot of the kings of

94. 52:56

    like you know you know the call guessing just now right another thing that we're still kind of working out but anyone who has started to develop on some of these games and having to go through that process uh you know understand it's required underneath the nuances this is honor our smaller and really start to run into that into more stuff where you can certainly build their interest station

95. 53:27

    before you use it foreign well I think my audio cut yeah it was a bit choppy at a moment yeah Hey Joe um I think yeah we're almost out of time but um I would love to continue this in our next call is that okay totally absolutely that sounds great okay uh do we all want to meet in two weeks again okay

96. 54:29

    cool so we will go ahead and schedule uh in two weeks so thank you all very much