Все ли транзакции NEAR blockchain требуют учетной записи получателя?

Прочитав здесь некоторую документацию, вы увидели, что часть определения транзакции состоит в том, что все действия выполняются "поверх учетной записи получателя", а также что учетная запись получателя является "учетной записью, на которую будет направлена ​​транзакция".

также в SDK nearlib интерфейс транзакций включает метод 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, DeleteKey, а также DeleteAccount?

amd Я слишком буквально понимаю идею "получателя", как "они получают результат или влияние транзакции"? а вместо этого думать об этом неправильно?

или ReceiverId является необязательным в некоторых случаях, но интерфейсу просто требуется значение, чтобы избежать ошибок при проверке?

вот что я считаю полным списком поддерживаемых транзакций

pub enum Action {
    CreateAccount(CreateAccountAction),
    DeployContract(DeployContractAction),
    FunctionCall(FunctionCallAction),
    Transfer(TransferAction),
    Stake(StakeAction),
    AddKey(AddKeyAction),
    DeleteKey(DeleteKeyAction),
    DeleteAccount(DeleteAccountAction),
}
Источник

2 ответа

Решение

К сожалению, у нас нет подходящего названия для обозначения того, что мы называем "получателем". В некоторых местах нашего кода мы также называем это "актером", потому что на самом деле это относится к учетной записи, над которой выполняется действие, в отличие от учетной записи, выдавшей действие для выполнения (также известного как "отправитель").

DeployContract, Stake, AddKey, DeleteKey требовать receiver==senderДругими словами, только сама учетная запись может добавлять / удалять ключи, размещать и развертывать контракт на себе, никакая другая учетная запись не может делать это за нее.

DeleteAccount то же самое, это требует receiver==sender за одним исключением: если баланс учетной записи скоро закончится из-за аренды хранилища, и она ниже определенного системного порога, любая другая учетная запись может удалить ее и потребовать оставшийся баланс.

CreateAccount, FunctionCall, а также Transfer не требуют receiver==sender. В случаеCreateAccount receiver не должен существовать в момент выполнения и будет фактически создан.

См. Код, реализующий эту логику: https://github.com/nearprotocol/nearcore/blob/ed43018851f8ec44f0a26b49fc9a863b71a1428f/runtime/runtime/src/actions.rs

Источник

Концептуально у каждой транзакции всегда есть отправитель и получатель, хотя иногда они могут быть одинаковыми. Поскольку мы всегда конвертируем транзакцию в квитанцию, которая отправляется получателю, концептуально не имеет значения, являются ли они одинаковыми, даже если в реализации может быть разница.

Источник
Другие вопросы по тегам