为什么我要在NearProtocol UnorderedMap中散列密钥？

Question

在近NFT示例中，为什么account_gives_access UnorderedMap散列中的键是？https://github.com/near-examples/NFT/blame/master/contracts/rust/src/lib.rs

pub struct NonFungibleTokenBasic {
    pub token_to_account: UnorderedMap<TokenId, AccountId>,
    pub account_gives_access: UnorderedMap<AccountIdHash, UnorderedSet<AccountIdHash>>, 
    pub owner_id: AccountId,
}

Answer 1

UnorderedMap类型使用trie。攻击者可以通过反复将键推到trie上，从而使trie的一侧深度被推入深度，从而破坏trie的平衡。这将降低对攻击者下面名称的trie查找的性能。

attock的一个缓解措施是存储密钥的散列。散列将在可能的值中平均分配。攻击者仍然可以执行攻击，但是生成特定的散列是很困难的，因此一些协议说。

攻击的另一个缓解措施是使用一个LookupMap，它使用一个AVL树，它自动地重新平衡它的树。

这次袭击并没有太大的威胁。攻击者所能做的最糟糕的事情就是惩罚一小部分键值，通过反复支付存储成本，将极有限的键值范围推到trie上。因此，可能不值得为散列密钥付出代价。

但是，对于存储大量密钥的树，哈希键或LookupMap可能仍然值得考虑，因为不平衡的trie很可能会导致这种情况。

概括而言，我们检讨了以下两项成本的比较：

在存储和撤回到UnorderedMap

• Allowing之前，
• 对每个密钥进行散列--使用LookupMap而不是UnorderedMap

进行

• 上面描述的“攻击”

谢谢@MikePurvis的解释。