Stabilize `near_sdk::store` collections

[austinabell]

Work started in #815 to stabilize, but for each of them:

• Docs are up to date

• Compatibility/tradeoffs with near_sdk::collections documented

  • Potentially convenience migration function added to the legacy collection to convert it to the new one?

• High-level explanation updated in https://github.com/near/sdk-docs

• [x] Vector

• [x] LookupMap

• [x] LookupSet

• [x] Removing the cache on LookupSet should be explored and finished benchmarking to compare the difference, since that one likely doesn't need a cache https://github.com/near/near-sdk-rs/pull/917

• [x] UnorderedMap

• [x] UnorderedSet

• [ ] TreeMap

• [x] Lazy

• [x] LazyOption

[austinabell]

Very skeptical to stabilize TreeMap. Would be nice to have an optimization that doesn't involve brute force searching when iterating. The collection is pretty unusable as-is

[itegulov]

Very skeptical to stabilize TreeMap. Would be nice to have an optimization that doesn't involve brute force searching when iterating. The collection is pretty unusable as-is

Shared my perspective on this in https://github.com/near/near-sdk-rs/issues/928, lmk what you think there

[bugproof]

I don't really get why the new near_sdk::store::Vector doesn't use u64 anymore but u32, if you plan on having more than u32::MAX items you cannot do this with this change. I guess your only option will remain only UnorderedMap/LookupMap. I'd like to know the reason behind this breaking change.

[austinabell]

I don't really get why the new near_sdk::store::Vector doesn't use u64 anymore but u32, if you plan on having more than u32::MAX items you cannot do this with this change. I guess your only option will remain only UnorderedMap/LookupMap. I'd like to know the reason behind this breaking change.

The primary reason is that a few of the std APIs used in conjunction with this (namely iterators) use usize, and having the indices be u64 in a 32-bit wasm architecture, can lead to silent bugs and foot guns.

Do you plan to have more than 4 billion entries in your Vector? It intuitively doesn't seem economically or technically feasible to store that many entries on chain, even with small value serializations. I'd say if you have an extreme example like this and you need that, I'd just fork that specific collection and change the indices; it would be a simple enough change to make.

[bugproof]

https://users.rust-lang.org/t/are-there-any-negative-implications-of-using-u64-in-wasm32/57419/2

Do you plan to have more than 4 billion entries in your Vector?

No, it's an extreme example but it's possible to reach that theoretically. There are 8 billion people in the world. Dapps should be able to scale to handle huge loads to be able to compete with web2 based platforms. Even fungible token contracts practically could reach over 4 billion entries if you have 4 billion near accounts and each has X amount of USDT