英文:
How does NEAR asynchronous actually works?
问题
根据文档、文章和...这是我对NEAR异步的理解。如果我理解有误，请纠正：
由于NEAR的异步设计和Nightshade算法，交易（或收据）不会在一个区块中处理。相反，它们创建了“收据”，这些收据将在下一个或下几个区块中执行，并且这些收据可能会生成其他收据，这些将被包括在并在下一个或下几个区块中执行。
这个机制引发了一些问题，比如Token Loss，因为“删除账户”操作和“退款或转移代币”操作不会在一个区块中执行，因此无法防止它们。
或者可能会出现“失败”的操作（尽管交易本身成功并且其他操作实际上已经执行）。
英文:
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).
答案1
得分: 2
你对NEAR协议的异步性质的理解大致是正确的。它确实采用了一种用于交易处理的异步模型，利用了Nightshade分片设计的强大功能。
在NEAR中，一旦由负责发送者帐户的分片处理，交易就会被转换为收据。然后，这个收据会被转发到负责接收者帐户的分片。实际的函数调用、代币转移或其他操作是在处理此收据时执行的。如果交易中的某个操作失败，其他操作仍然可以成功执行。
你关于这个设计引入的一些挑战也是正确的：
-
代币损失：在NEAR中，删除一个帐户需要先撤回帐户中的所有代币。然而，如果删除和代币转移不在同一笔交易中，那么在代币转移后但在帐户删除之前，其他人仍然有可能删除该帐户，导致代币丢失。
-
部分失败的交易：由于交易中的每个操作都是独立处理的，因此某些操作成功而其他操作失败是有可能的。这可能会引入合同开发的复杂性，并可能导致意外的结果。
为了解决这些和其他挑战，开发人员必须谨慎处理NEAR的异步性质，确保考虑到潜在的竞争条件和交易失败。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论