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

Question

我有以下问题： fungible Token example and 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 作为帐户的真正所有者。是否存在保护仅由真实所有者转让的逻辑？
为什么可替代代币没有 name/title？
NEAR 协议 是否有一些可替代代币交换的标准或逻辑？

Answer 1

It's a possible situation when escrow allowances > 0, but account balance = 0. Is it legal flow and why?

AFAIU 津贴只是防止滥用的理智上限。两个账户可以对同一个账户有两个津贴，总和大于账户余额。

It never checks account_id exists or not. Why? Is it secure?

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

Anyone can call: inc_allowance/dec_allowance?

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

And for let owner_id = env::predecessor_account_id(); will be created new account, new escrow allowance automatically (if not exist). Is that logic correct and why?

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

get_account always created a new account. It looks redundant.

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

transfer_from is never check owner_id as the real owner of the account. Is there logic to protect transferring only by real owners?

在这个支票中暗示：https://github.com/near/near-sdk-rs/blob/master/examples/fungible-token/src/lib.rs#L174-L180如果不是托管的情况，那么env::predecessor_account_id()应该等于owner_id。所以 receipt/transaction 一定是从所有者的帐户发送的。

Why fungible token doesn't have a name/title?

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

Do the NEAR Protocol have some standard or logic for Fungible Tokens exchange?

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

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

NEAR Protocol Fungible Tokens logic NEP-21

smartcontracts

nearprotocol