Usage of account hashes vs. accounts in smart contracts

Currently NEP-21 defines account->balance map as:

#[near_bindgen]
#[derive(BorshDeserialize, BorshSerialize, PanicOnDefault)]
pub struct FungibleToken {
    /// sha256(AccountID) -> Account details.
    pub accounts: LookupMap<Vec<u8>, Account>,

Using hashes is problematic for reverse look-up reasons. For example, if I want to print out a human-readable CSV file for all token holder addresses. With current NEAR infrastructure in-place, this would be difficult. Events will probably makes this much easier.

Probably nothing needs to be done for this now, but this should be addresses in the future token standard examples, so that developers have an answer to the question “how to print out all token holders”.

Good question. In case the account_id is desired to have at the view method for iterations, you need to do 2 things:

• use UnorderedMap, so you can actually iterate on it
• store AccountId instead of account hash. You can address this by charging 64 bytes or actually computing the amount you need. Also UnorderedMap will require higher amount of tokens for storage due to replication of keys needed for iterator.