NearPromise and transaction atomicity #316
-
|
Hi, Would like to know what are the best practices around using NearPromise and transaction atomicity? For example, if in my smart contract I do an assertion to check if a transfer can be made and then use NearPromise.Transfer() to do the transfer - what other checks should I add? From documentation I read that promise might/will run in another block. So, in theory my assertion could run in block 10 and the transfer in block 20, correct? Which means anything might happen in blocks 11-19 and by the time the transfer starts the assertion could be wrong already. This is just a simple scenario, but what if my assertion involves getting some state information from another smart contract, then do some state changes locally and then call a third contract which also changes some state change and, in the end, perform many transfers. Without any distributed transaction capability in Near - how could I achieve all of that safely? As I understand all of these operations run separately, potentially in separate shards and separate blocks. I technically cannot even perform a proper revert (call revert in all the parts) because things might happen during the revert procedure leaving everything in an inconsistent state. Am I missing something here? Is there some synchronization layer in Near core I can hook into to lock some information which all parts can access? But even then,, how do I force an Assert and Transfer into the same procedure and to not run in different blocks because I cannot revert a transfer... |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
If transfer promise is scheduled, then it subtracts the balance immediately. But the remote execution (deposit) can happen later. Similar to the function calls with attached deposits. If you schedule it successfully during the current receipt execution, then it will be executed at some point in the future. So if you do assert and then transfer, you should be fine. As for reverts, the way it's usually done on NEAR is to track required information locally if you can (e.g. current token balances for your contract/users). If you can't track it locally, then you need to try to accumulate required resources first before doing transfers, e.g. pull all the resources into this contract, then make transfer distribution. Without a concrete problem example, it's hard to suggest the solution. |
Beta Was this translation helpful? Give feedback.
If transfer promise is scheduled, then it subtracts the balance immediately. But the remote execution (deposit) can happen later.
Similar to the function calls with attached deposits. If you schedule it successfully during the current receipt execution, then it will be executed at some point in the future. So if you do assert and then transfer, you should be fine.
As for reverts, the way it's usually done on NEAR is to track required information locally if you can (e.g. current token balances for your contract/users). If you can't track it locally, then you need to try to accumulate required resources first before doing transfers, e.g. pull all the resources into this contract, then make …