Based on the documentations, articles and ... here what i understand of NEAR asynchronous. Please correct me if i am wrong:
Due to NEAR asynchronous design and Nightshade algorithm. Transactions (or receipts) are not being processed in one block. instead they create receipts which will be executed in the next block(s), and also those receipts may generate other receipt, that will be included and executed in the next block(s).
This mechanism raises some problems like Token Loss that is because the deleting account action and refund or transfer token actions are not being executed in one block and therefore can not be prevented.
Or a failed action (while the transaction itself was successful and other actions actually got executed).
Your understanding of NEAR Protocol's asynchronous nature is largely correct. It is indeed built with an asynchronous model for transaction processing which leverages the power of the Nightshade sharding design.
In NEAR, a transaction is converted into a receipt as soon as it is processed by the shard responsible for the sender's account. This receipt is then forwarded to the shard responsible for the receiver's account. The actual function call, token transfer, or other actions are performed when this receipt is processed. If an action within a transaction fails, other actions can still be executed successfully.
You're also correct about some challenges this design introduces:
Token Loss: In NEAR, deleting an account requires all tokens in the account to be withdrawn first. However, if the deletion and the token transfer are not in the same transaction, it's possible for someone else to delete the account after the tokens are transferred, but before the account is deleted, resulting in a loss of tokens.
Partially failed transactions: Since each action in a transaction is processed independently, it's possible for some actions to succeed while others fail. This can introduce complexities in contract development and can potentially lead to unexpected results.
To address these and other challenges, developers must carefully handle the asynchronous nature of NEAR, ensuring to account for potential race conditions and transaction failures.