search

solana-labs / solana

Web-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.
https://solanalabs.com
Apache License 2.0
12.92k stars 4.13k forks source link

Feat: allow geyser to request account snapshot from validator #31242

Closed linuskendall closed 1 month ago

linuskendall commented 1 year ago

Problem

Currently if a geyser plugin wants to access account state outside of account state that has been updated it needs to use the JSONRPC api to fetch account state from the validator. This adds unnecessary serialization/deserialization of JSON data between validator and plugin. It would be handy if there was a way for plugin to ask the validator to deliver account state for example into the ACC stream.

Proposed Solution

A few different possibilities come to mind:

1) The admin socket could have a command that we can send to trigger delivery of account updates to the plugin in a similar way to how this happens during startup.

2) The plugin itself could request particular accounts, set of accounts or all accounts from the validator.

3) Geyser could have a hook into the account snapshotting routines so that when the validator generates an account snapshot to disk it also calls back to geyser (plugin could then decide what to do with the snapshot accounts, e.g. filter them).

4) Geyser could connect into the RPC client by having some kind of channel that it can send RPC requests to the validator over.

5) We do none of this and let geyser use JSONRPC to communicate with the validator. We can improve speed of this by adding unix socket support for IPC between plugin and validator.

linuskendall commented 1 year ago

This could work well together with #30352 .

lijunwangs commented 1 year ago

I am a little confused by the following Currently if a geyser plugin wants to access account state outside of account state that has been updated it needs to use the JSONRPC api to fetch account state from the plugin. I do not get the plugin need to access from the plugin part. Can you shed more light on the use case? Are you trying to support obtaining account state from your plugin which your plugin does not have handle and keep in the database?

linuskendall commented 1 year ago

I am a little confused by the following Currently if a geyser plugin wants to access account state outside of account state that has been updated it needs to use the JSONRPC api to fetch account state from the plugin. I do not get the plugin need to access from the plugin part. Can you shed more light on the use case? Are you trying to support obtaining account state from your plugin which your plugin does not have handle and keep in the database?

Sorry I meant the validator :)

lijunwangs commented 1 year ago

Thanks, I understand now it is the plugin to load account state from the validator. But I am not sure I understand what is the use case making it necessary. At the validator startup, all accounts are notified from the snapshots. After that is finished, when the account is modified, it will be notified as well. So for such plugin, you should have all the state. I think what probably makes sense is the case, there was an account which you were not interested in earlier and at runtime decided to watch it and you request its original state. Or for a plugin dynamically loaded after startup? @linuskendall

linuskendall commented 1 year ago

The main issue is the one raised in the PR #32094 . Maintaining complete state inside the plugin for every account makes the plugin very bloated and complex. For the use case of something like gRPC subscriptions, currently the plugin only process account updates for the accounts that it has active subscriptions. However, clients do request the ability to access snapshots of accounts, especially at the start of the stream.

In order to implement that we would need to make the plugin considerably more complex if it not only needs to deal with subscriptions but also needs to keep a complete locally resolved state (ie. at all commitment levels for all accounts).

lijunwangs commented 1 year ago

I think the option 5 sounds the simplest

We do none of this and let geyser use JSONRPC to communicate with the validator. We can improve speed of this by adding unix socket support for IPC between plugin and validator.

linuskendall commented 1 year ago

However, since the stated goal @.***) is to remove the RPC server from the validator … it doesn’t seem like 5 is really the long term choice here.

On Fri, 21 Jul 2023 at 23:22, Lijun Wang @.***> wrote:

I think the option 5 sounds the simplest

We do none of this and let geyser use JSONRPC to communicate with the validator. We can improve speed of this by adding unix socket support for IPC between plugin and validator.

— Reply to this email directly, view it on GitHub https://github.com/solana-labs/solana/issues/31242#issuecomment-1646051701, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHOYRJZRR7ORM6J2LLWB4LXRK6WZANCNFSM6AAAAAAXCJKKBY . You are receiving this because you were mentioned.Message ID: @.***>