Hi Devs, how does the query_id work in a smart contract that can handle simultaneous transactions?
I'm designing a contract that allows "everyone" to send transactions in.
This is why I recall we defined the query_id in the TEP standard. However, the problem is that "the current use case for NFT Transfer or Jetton Transfer" doesn't involve high-load use cases!
In my contract, there might be 10 transactions, or perhaps more than 20 transactions in a single LT. What will happen in this case? And how should users select a query_id?
Should they just randomly pick a number? What happens if two third parties pick the same query_id?
Jul 30, 2023, 5:19 AM
Currently pretty often, users pick query_id = 0 so that should not be used for distinguishing transactions. A bit less frequently, they use current time or random number.
Most of the time, you do not need to store query_id and past requests in your contract: if you can process them on the fly, you just set query_id in outgoing messages equal to incoming one. Otherwise, the problem involves only optimizing message processing and does not depend on query_id much.
Most of the time, you do not need to store query_id and past requests in your contract: if you can process them on the fly, you just set query_id in outgoing messages equal to incoming one. Otherwise, the problem involves only optimizing message processing and does not depend on query_id much.
Jul 30, 2023, 8:24 AM
What do you mean by “doesn’t involve high load use cases”?
Jul 30, 2023, 8:27 AM
Total supply constantly increases due to validators receiving rewards for their work. Simultaneously, 1/2 of network fees is burnt (this is a deflation mechanism).
Jul 30, 2023, 8:51 AM
I believe these contexts could be optimized to be more easily understood. But I get your point. Yes, it seems that even using random numbers can still lead to unclear results.
Jul 30, 2023, 11:56 AM