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

Leader schedule over geyser #31446

Closed linuskendall closed 1 month ago

linuskendall commented 1 year ago

Problem

Efforts such as https://github.com/blockworks-foundation/lite-rpc would go along way to help reduce the burden and horizontally scale solana nodes.

Geyser (such as our https://github.com/rpcpool/yellowstone-grpc) could pretty much serve as the core functionality that feeds something like lite-rpc with currently one major exception - the leader schedule (see https://github.com/blockworks-foundation/lite-rpc/commit/e1c5c1fcdd20c0a83b591f990a6a40cd28257769).

Proposed Solution

If we could have the validator send a message to geyser with the current leader schedule each time the geyser starts and then send a notification whenever the leader schedule updates, this could be handled fully in geyser plugins.

mschneider commented 1 year ago

It would actually be better to receive VoteAccounts, currently exposed via rpc as getVoteAccounts which is required to confirm blocks based on the actual vote transactions as they get added to the ledger and can be used to construct the leader schedule.

mschneider commented 1 year ago

While we are at it, we should add a context slot and epoch to that data

CriesofCarrots commented 1 year ago

It would actually be better to receive VoteAccounts, currently exposed via rpc as getVoteAccounts which is required to confirm blocks based on the actual vote transactions as they get added to the ledger and can be used to construct the leader schedule.

Geyser already provides account updates, with slot data: https://github.com/solana-labs/solana/blob/5178d4d49b347ed615b124b9d1527ff3198a8e65/geyser-plugin-interface/src/geyser_plugin_interface.rs#L296-L301 (Epoch seems unnecessary to me, since you can figure that out with math.) Is there some reason this won't work for vote accounts?

mschneider commented 1 year ago

getVoteAccounts returns the effective delegated stake, which is not recorded on the vote account afaik but would require subscribing to roughly more than 500,000 stake accounts

ripatel-fd commented 1 year ago

getVoteAccounts returns the effective delegated stake, which is not recorded on the vote account afaik but would require subscribing to roughly more than 500,000 stake accounts

@mschneider getVoteAccounts cannot be used to recover the leader schedule. The leader schedule is derived from active stake delegations at the epoch boundary, whereas getVoteAccounts returns whatever delegations are currently active.

mschneider commented 1 year ago

We can publish getVoteAccounts only at the epoch boundary that's enough