rust - 为什么我应该散列近协议(protocol) Unordered_Map 中的键？

Question

在近 NFT 示例中，为什么键位于 account_gives_access Unordered_Map 哈希中？ 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 查找的性能 攻击者的。

缓解攻击的方法是存储 key 的哈希值。哈希值将是 在可能的值之间平均分配。攻击者仍然可以执行 攻击，但生成特定的哈希值很困难，一些协议(protocol)是这么说的。

另一种缓解攻击的方法是使用 LookupMap，它使用 AVL 树，它会自动重新平衡其树。

这次攻击没有明显的威胁。攻击者能做的最糟糕的事情是 通过重复支付存储成本来惩罚一小部分关键值 将极其有限的键值范围推向字典树的更深处。因此，很可能 不值得支付哈希 key 的成本。

但是，对于存储大量键、散列键或 LookupMap 的树，可能仍然 值得考虑，因为很可能会导致不平衡的 trie。

回顾一下，我们回顾了以下成本的比较:

• 在存储和检索到 UnorderedMap 之前对每个键进行哈希处理
• 允许上述“攻击”
• 使用 LookupMap 代替 UnorderedMap

感谢@MikePurvis 的解释。