时间戳

首页 > 解决方案 > NEAR 协议可替代代币逻辑 NEP-21

smartcontracts - NEAR 协议可替代代币逻辑 NEP-21

问题描述

我有关于： 可替代令牌示例和NEP-21本身的问题。

  1. escrow allowances > 0当, 但是时，这是一种可能的情况account balance = 0。它是合法的流动吗？为什么？
  2. 它从不检查是否account_id存在。为什么？它安全吗？
  3. 任何人都可以拨打：inc_allowance/dec_allowance？

并且let owner_id = env::predecessor_account_id();将自动创建新帐户，新的托管津贴（如果不存在）。这个逻辑正确吗？为什么？

  1. get_account总是创建一个新帐户。看起来是多余的。

例如：

fn get_account(&self, owner_id: &AccountId) -> Account {
    assert!(env::is_valid_account_id(owner_id.as_bytes()), "Owner's account ID is invalid");
    let account_hash = env::sha256(owner_id.as_bytes());
    self.accounts.get(&account_hash).unwrap_or_else(|| Account::new(account_hash))
}

将为新创建“始终”新帐户owner_id。并且有可能永远不会使用该帐户。那么默默地“创建”一个帐户真的很实用get_account吗？

  1. transfer_from永远不会检查owner_id为帐户的真正所有者。是否有逻辑来保护仅由真实所有者进行的转让？
  2. 为什么可替代令牌没有名称/标题？
  3. NEAR 协议是否有一些可替代代币交换的标准或逻辑？

标签： smartcontractsnearprotocol

解决方案

当托管限额> 0，但账户余额= 0时，这是一种可能的情况。这是合法流动吗？为什么？

AFAIU 津贴只是防止滥用的合理上限。两个帐户可以有两个相同帐户的备抵加起来大于帐户余额的数字。

它从不检查 account_id 是否存在。为什么？它安全吗？

在分片区块链中，如果没有异步跨合约调用，就不可能检查账户是否存在，因为其他账户可能存在于不同的分片上。此外，当我们收到来自其他分片的回复时，可以创建/删除该帐户。

任何人都可以致电：inc_allowance/dec_allowance？

它只能由所有者调用，参见：https ://github.com/near/near-sdk-rs/blob/master/examples/fungible-token/src/lib.rs#L106

而对于 let owner_id = env::predecessor_account_id(); 将自动创建新帐户，新的托管津贴（如果不存在）。这个逻辑正确吗？为什么？

是的。我不确定，为什么这会是矛盾的。

get_account 总是创建一个新帐户。看起来是多余的。

它可能是多余的，但在这种情况下，编译器也可能对其进行优化：https ://github.com/near/near-sdk-rs/blob/master/examples/fungible-token/src/lib .rs#L213

transfer_from 永远不会检查 owner_id 作为帐户的真正所有者。是否有逻辑来保护仅由真实所有者进行的转让？

此检查中暗示：https://github.com/near/near-sdk-rs/blob/master/examples/fungible-token/src/lib.rs#L174-L180如果不是托管，env::predecessor_account_id()则应等于owner_id。因此，收据/交易必须是从所有者的帐户发送的。

为什么可替代令牌没有名称/标题？

我们正在努力将元数据添加到我们的合同中，请在此处查看我们的第一季度 OKR： https ://airtable.com/shrw0AD36eIbfEW02

NEAR 协议是否有一些可替代代币交换的标准或逻辑？

我们有合作伙伴致力于实施类似的东西，但我认为我们没有标准。

推荐阅读