如何解决NEAR 协议 Fungible Tokens 逻辑 NEP-21
我有以下问题: fungible Token example 和 NEP-21 本身。
-
escrow allowances > 0
是一种可能的情况,但是account balance = 0
。 这是合法的流程吗?为什么? - 它从不检查
account_id
是否存在。为什么?安全吗? - 任何人都可以拨打:
inc_allowance/dec_allowance
?
对于 let owner_id = env::predecessor_account_id();
将自动创建新帐户,新的托管津贴(如果不存在)。这个逻辑正确吗?为什么?
-
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
静默“创建”一个帐户真的实用吗?
-
transfer_from
永远不会检查owner_id
作为帐户的真正所有者。是否有逻辑来保护仅由真实所有者进行的转让? - 为什么可替代代币没有名称/标题?
- NEAR 协议是否有一些用于 Fungible Tokens 交换的标准或逻辑?
解决方法
当托管额度 > 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 协议是否有一些用于 Fungible Tokens 交换的标准或逻辑?
我们有合作伙伴致力于实施类似的事情,但我认为我们没有标准。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。