Closed acuarica closed 3 years ago
Another possibility would be to use the intrinsic linked list of blocks to retrieve Corgis.
If we go with this alternative, we will need to query the RPC for linked transactions. The CI deploy script query previous transactions to get the previous created accounts, it might be useful:
https://github.com/epam/corgis/blob/20f55f9ef2509fd37484b8ba05a5c1f2f195f312/ci/deploy.mjs#L86-L138
From Sherif@NEAR in the Discord chat on how use RPC as a linked list:
the video includes some very relevant discussion about storage strategies for apps with high frequency data updates and moderately large data sets.
Eugene is taking advantage of NEAR's low cost of overwriting data (vs writing new data) to replace the previous post with each new one.
He finds older posts by following a linked list of posts using block height as the reference to the next post.
Assuming a constraint of one post per block per user (blocks are 1 second so that's very reasonable), this means each post can be queried directly via RPC using user account and block height to traverse the tree
His frontend grabs the most recent post from the blockchain then hits validator RPC nodes for previous 10 posts before switching to hit archival RPC nodes until 100 posts are loaded
also discussed in this video:
- dynamically estimating storage costs of a contract
- upgradeable contracts
source code: https://github.com/evgenykuzyakov/near-fm
Just for reference, Rust contracts binaries are bloated.
Dict
is now using LookupMap
. Storage was reduced almost 50% when creating a corgi.
After measuring gas usage by contract (see #165), we might want to optimize how contract stores data.
We could improve data storage by using a
LookupMap
instead of anUnorderedMap
. As described in [1],LookupMap
does not permit to traverse its elements. However, since we are using a linked list to traverse those elements in insertion order, we could be better of withLookupMap
.[1] https://docs.near.org/docs/concepts/data-storage#rust-collection-types