-
Notifications
You must be signed in to change notification settings - Fork 168
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
Add fork provider for non-state data #1466
Comments
@kariy can I take this? Thanks |
Assigned! Let me know if you have any questions or require more context on the issue. |
@fishseabowl I've updated the issue description for more context. Thanks for the contribution 🙂 |
Hey @fishseabowl. Any updates on this? Let me know if there's something blocking you. |
@kariy Thank you. I'm currently handling this. If I have any questions, I'll message you. |
@kariy Do you know where is a code example using the starknet-provider API, e.g. if I call API /// Returns all events matching the given filter
async fn get_events(
&self,
filter: EventFilter,
continuation_token: Option<String>,
chunk_size: u64,
) -> Result<EventsPage, ProviderError>; |
@fishseabowl I'm not sure about the example but you can refer to the RPC specs here to know what each of the params are used for. |
Some example of code from starknet-rs @fishseabowl: https://github.com/xJonathanLEI/starknet-rs/blob/400deb6f058447e8b67316a92ecd9ad3b6d4330c/starknet-providers/tests/jsonrpc.rs#L795. The chunk size is expected to be |
Currently
katana
only provides forked data for state-related info (eg storage, nonce, class hash) thru theSharedStateProvider
. We should extend the forking functionality to also allow fetching non-state data as well (eg block, events, tx) from the forked network.We can extend the
Backend
to handle more request types.Proposed solution
We can mimic
ForkedStateDb
where it usesSharedStateProvider
as the underlying db forCacheStateDb
by creating similar forked provider type specifically for theCacheDb
instead, that handles non-state data (ie block, tx). UnlikeSharedStateProvider
, we don't have to implement the provider traits as most of the traits are mainly for abstracting over the db layout. We only need to fetch data that can only be fetched from the RPC. So, that means we only need to implement fork handlers for data that can only be obtain from the Katana RPC.Regarding caching (ie storing the fetch forked data into local storage), ideally we can store the fetched data directly into the main storage, but how the storage is laid out at the moment isn't very friendly to unordered insertion like this case. Maybe we can have the forked provider type to include a storage to store the data fetched from the forked RPC.
The text was updated successfully, but these errors were encountered: