2

阅读此处的一些文档并看到交易定义的一部分是所有操作都“在接收者的帐户之上”执行，并且接收者帐户是“交易将被路由到的帐户”。

同样在 nearlib SDK 中，事务接口包含一个名为 signTransaction 的方法，该方法需要receiverId作为参数

async function signTransaction(receiverId: string, nonce: number, actions: Action[], blockHash: Uint8Array, signer: Signer, accountId?: string, networkId?: string): Promise<[Uint8Array, SignedTransaction]> {

但是查看 nearcore 支持的交易列表，我想知道为什么其中一些交易需要接收器。

为什么除了可能、、、和之外的任何交易都需要Transfer“接收者AddKey” ？DeleteKeyDeleteAccount

而且我认为“接收者”的概念过于字面意思，就像“他们收到交易的结果或影响”一样？相反，这不是正确的思考方式吗？

或者在某些情况下receiverId 是可选的，但接口只需要一个值来避免验证麻烦？

这是我认为受支持交易的完整列表

pub enum Action {
    CreateAccount(CreateAccountAction),
    DeployContract(DeployContractAction),
    FunctionCall(FunctionCallAction),
    Transfer(TransferAction),
    Stake(StakeAction),
    AddKey(AddKeyAction),
    DeleteKey(DeleteKeyAction),
    DeleteAccount(DeleteAccountAction),
}
4

2 回答 2

3

从概念上讲，每笔交易总是有一个发送者和一个接收者，即使有时它们可​​能是相同的。因为我们总是将交易转换为发送给接收者的收据，所以在概念上它们是否相同并不重要，即使在实现中可能存在差异。

于 2019-11-19T17:17:39.500 回答
2

不幸的是，我们没有一个好名字来表示我们所说的“接收者”。在我们的代码中的某些地方，我们也将其称为“参与者”，因为它实际上是指执行操作的帐户，而不是发出要执行的操作的帐户（也称为“发送者”）。

DeployContract, Stake, AddKey, DeleteKeyrequire receiver==sender，换句话说，只有账户本身可以添加/删除密钥、抵押和部署自己的合约，没有其他账户可以这样做。

DeleteAccount同理，只需要receiver==sender一个例外：如果账户由于存储租金即将用完并且低于某个系统定义的阈值，任何其他账户都可以删除它并索取余额。

CreateAccount, FunctionCall, 并且Transfer不需要receiver==sender. 在CreateAccount receiver执行时不应该存在的情况下，将实际创建。

请参阅实现此逻辑的代码：https ://github.com/nearprotocol/nearcore/blob/ed43018851f8ec44f0a26b49fc9a863b71a1428f/runtime/runtime/src/actions.rs#L360

于 2019-11-19T19:41:52.827 回答