Skip to content

rpcpool/yellowstone-grpc

Repository files navigation

Yellowstone Dragon's Mouth - a Geyser based gRPC interface for Solana

This repo contains a fully functional gRPC interface for Solana, built and maintained by Triton One. It is built around Solana's Geyser interface. In this repo, we have the plugin and sample clients for multiple languages.

It provides the ability to get slots, blocks, transactions, deshred pre-execution transactions, and account update notifications over a standardised path.

For additional documentation, please see: https://docs.triton.one/rpc-pool/grpc-subscriptions

Known bugs

Block reconstruction inside gRPC plugin is based on information provided by BlockMeta, unfortunately, the number of entries for blocks generated on validators is always equal to zero. These blocks will always have zero entries. See issue on GitHub: solana-labs/solana#33823

Validator

solana-validator --geyser-plugin-config yellowstone-grpc-geyser/config.json

Plugin config check

cargo-fmt && cargo run --bin config-check -- --config yellowstone-grpc-geyser/config.json

Pre-commit hooks

Install repository hooks:

make install-hooks

The pre-commit hook will:

  • ensure commit signing is enabled (commit.gpgsign=true)
  • run cargo fmt --all -- --check and print a warning if formatting fails

Block reconstruction

Geyser interface on block update does not provide detailed information about transactions and account updates. To provide this information with a block message, we must collect all messages and expect a specified order. By default, if we failed to reconstruct full block, we log an error message and increase the invalid_full_blocks_total counter in prometheus metrics. If you want to panic on invalid reconstruction, change the option block_fail_action in config to panic (default value is log).

Filters for streamed data

Please check yellowstone-grpc-proto/proto/geyser.proto for details.

  • commitment — commitment level: processed / confirmed / finalized
  • accounts_data_slice — array of objects { offset: uint64, length: uint64 }, allow to receive only required data from accounts
  • ping — optional boolean field. Some cloud providers (like Cloudflare, Fly.io) close the stream if the client doesn't send anything during some time. You can send the same filter every N seconds as a workaround, but this would not be optimal since you need to keep this filter. Instead, you can send a subscribe request with ping field set to true and ignore the rest of the fields in the request. Since we sent a Ping message every 15s from the server, you can send a subscribe request with ping as a reply and receive a Pong message.

Slots

  • filter_by_commitment — by default, slots are sent for all commitment levels, but with this filter, you can receive only the selected commitment level

Account

Accounts can be filtered by:

  • account — account Pubkey, match to any Pubkey from the array
  • owner — account owner Pubkey, match to any Pubkey from the array
  • filters — same as getProgramAccounts filters, array of dataSize or Memcmp (bytes, base58, base64 are supported)

If all fields are empty, then all accounts are broadcast. Otherwise, fields work as logical AND and values in arrays as logical OR (except values in filters that works as logical AND).

Transactions

  • vote — enable/disable broadcast vote transactions
  • failed — enable/disable broadcast failed transactions
  • signature — match only specified transaction
  • account_include — filter transactions that use any account from the list
  • account_exclude — opposite to account_include
  • account_required — require all accounts from the list to be used in the transaction

If all fields are empty, then all transactions are broadcast. Otherwise, fields work as logical AND and values in arrays as logical OR.

Deshred transactions

SubscribeDeshred is a separate bi-directional stream for pre-execution transactions. Instead of waiting for Replay to execute a transaction and produce TransactionStatusMeta, the server reconstructs entries from incoming shreds and streams the decoded transaction as soon as it is available.

This gives you an earlier signal than the regular transactions stream, but it comes with less context:

  • available fields — slot, signature, is_vote, raw transaction, loaded_writable_addresses, loaded_readonly_addresses
  • unavailable fields — execution status, error details, logs, inner instructions, balances, compute usage, TransactionStatusMeta

loaded_writable_addresses and loaded_readonly_addresses contain addresses resolved from address lookup tables, so deshred filters can match both static account keys and dynamically loaded addresses.

Availability:

  • the protobuf API and Rust client expose SubscribeDeshred
  • this RPC is only available on Triton extension servers
  • the open-source yellowstone-grpc-geyser server in this repository currently returns UNIMPLEMENTED for SubscribeDeshred
  • the implemented version currently lives on the master-triton-ext branch

The deshred transaction filter supports:

  • vote — enable/disable broadcast vote transactions
  • account_include — match transactions that mention any listed account, including ALT-loaded addresses
  • account_exclude — exclude transactions that mention any listed account, including ALT-loaded addresses
  • account_required — require all listed accounts to be present, including ALT-loaded addresses

Entries

Currently, we do not have filters for the entries, all entries are broadcast.

Blocks

  • account_include — filter transactions and accounts that use any account from the list
  • include_transactions — include all transactions
  • include_accounts — include all accounts updates
  • include_entries — include all entries

Blocks meta

Same as Blocks but without transactions, accounts, and entries. Currently, we do not have filters for block meta, all messages are broadcast.

Limit filters

It's possible to add limits for filters in the config. If the filters field is omitted, then filters don't have any limits.

"grpc": {
   "filters": {
      "accounts": {
         "max": 1,
         "any": false,
         "account_max": 10,
         "account_reject": ["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"],
         "owner_max": 10,
         "owner_reject": ["11111111111111111111111111111111"]
      },
      "slots": {
         "max": 1
      },
      "transactions": {
         "max": 1,
         "any": false,
         "account_include_max": 10,
         "account_include_reject": ["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"],
         "account_exclude_max": 10,
         "account_required_max": 10
      },
      "blocks": {
         "max": 1,
         "account_include_max": 10,
         "account_include_any": false,
         "account_include_reject": ["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"],
         "include_transactions": true,
         "include_accounts" : false,
         "include_entries" : false
      },
      "blocks_meta": {
         "max": 1
      },
      "entry": {
         "max": 1
      }
   }
}

Unary gRPC methods

Ping

GetLatestBlockhash

GetBlockHeight

GetSlot

IsBlockhashValid

GetVersion

Examples

For a SubscribeDeshred CLI example, see examples/rust.

Note

Some load balancers will terminate gRPC connections if no messages are sent from the client for a period of time. In order to mitigate this, you need to send a message periodically. The ping field in the SubscribeRequest is used for this purpose. The gRPC server already sends pings to the client, so you can reply with a ping, and your connection will remain open. You can see in the rust example how to reply to the ping from the server with the client.

Projects based on Geyser gRPC

About

Triton's Dragon's Mouth Yellowstone gRPC service for high-performance Solana streaming

Topics

Resources

License

Stars

Watchers

Forks

Packages

 
 
 

Contributors