Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose storage prefetching to contracts, to avoid reliance on cache as much #8932

Open
nagisa opened this issue Apr 19, 2023 · 1 comment
Open
Labels
A-storage Area: storage and databases T-contract-runtime Team: issues relevant to the contract runtime team

Comments

@nagisa
Copy link
Collaborator

nagisa commented Apr 19, 2023

Today our runtime relies heavily on the caches in the storage system in order to provide better performance and therefore lower execution cost. If we wanted to remove this cache, the costs to access storage would be outrageously high.

An alternative to on-demand caching could be to be predictive about it. As a most basic solution, we could just fetch the entire contract state into memory as we prepare the contract for execution, but that would only work for the smaller contracts. We could probably reasonably do so for those contracts that are limited to 100KiB state or-so.

In practice, most contracts can probably tell the majority of storage keys they will be accessing given the name of the function being invoked and the arguments passed in, well ahead of the function being invoked in the first place.

From there on any accesses to such pre-fetched storage keys would be comparatively free-ish, being stored in some HashMap in the main memory.

In cases a contract does, in fact, need to make decisions on what keys to fetch based on some other fetches (thus depending on I/O dependencies) they could probably afford to pay realistic storage fees.

The primary reason this operation could be cheaper than a regular storage access is its being able to fetch data from the storage in bulk. Having a mechanism to access multiple keys at once allows the runtime to tell that these accesses are independent and fetch all the keys at once in an optimal way. This would basically convert the accesses from queue-depth=1 to queue-depth=N.


In addition to a regular host function to “simply” read&write multiple keys, we will want a mechanism to inform the runtime that certain keys will be accessed in contract execution at the benefit of cheaper accesses during the execution.

This could be a special exported function which would return the keys accessed for given function call description. The contract runtime could then pre-fetch the keys in the background as it gets ready to execute the transaction. This function would need to be pure, and therefore most of the host functions would be unavailable (panic at runtime) for the contract when the runtime invokes this function.

@nagisa nagisa added A-storage Area: storage and databases T-contract-runtime Team: issues relevant to the contract runtime team labels Apr 19, 2023
@nagisa
Copy link
Collaborator Author

nagisa commented May 10, 2024

This is probably not something we will need to do anymore with memtrie enablement. cc #10965

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-storage Area: storage and databases T-contract-runtime Team: issues relevant to the contract runtime team
Projects
None yet
Development

No branches or pull requests

1 participant