Client Config

client_config request type

This endpoint allows you to get the client configuration of the NEAR node.

Live Response

Responses from the selected endpoint appear here after you run a request.

Live response output will appear here after you run a request.

Request reference

application/json

This operation accepts a JSON-RPC body over POST to /.

Required request inputs: yes

{
  "jsonrpc": "2.0",
  "id": "fastnear",
  "method": "client_config",
  "params": []
}

Request schema

2.0

Example: fastnear

client_config

Empty array as this method takes no parameters

Example:

Response reference

200 application/json

Successful response

Response schema

2.0

stringnumber

ClientConfig where some fields can be updated at runtime.

Not clear old data, set true for archive nodes.

Horizon at which instead of fetching block, fetch full state.

Behind this horizon header fetch kicks in.

Duration to check for producing / skipping block.

Time between check to perform catchup.

Chain id for status.

Config for the Chunk Distribution Network feature. This allows nodes to push and pull chunks from a central stream. The two benefits of this approach are: (1) less request/response traffic on the peer-to-peer network and (2) lower latency for RPC nodes indexing the chain.

URIs for the Chunk Distribution Network feature.

Time between checking to re-request chunks.

Number of threads for ChunkValidationActor pool.

Multiplier for the wait time for all chunks to be received.

Height horizon for the chunk cache. A chunk is removed from the cache if its height + chunks_cache_height_horizon < largest_seen_height. The default value is DEFAULT_CHUNKS_CACHE_HEIGHT_HORIZON.

Number of threads to execute background migration work in client.

Configuration for a cloud-based archival writer. If this config is present, the writer is enabled and writes chunk-related data based on the tracked shards. This config also controls additional archival behavior such as block data and polling interval.

Determines whether block-related data should be written to cloud storage.

Default: false

Interval at which the system checks for new blocks or chunks to archive.

Default: [object Object]

If true, the node won't forward transactions to next the chunk producers.

Time between running doomslug timer.

If true, transactions for the next chunk will be prepared early, right after the previous chunk's post-state is ready. This can help produce chunks faster, for high-throughput chains. The current implementation increases latency on low-load chains, which will be fixed in the future. The default is disabled.

Re-export storage layer statistics as prometheus metrics.

Epoch length.

Options for epoch sync.

Number of epochs behind the network head beyond which the node will use epoch sync instead of header sync. At the consumption site, this is multiplied by epoch_length to get the horizon in blocks.

Default: 2

Timeout for epoch sync requests. The node will continue retrying indefinitely even if this timeout is exceeded.

Graceful shutdown at expected block height.

Configuration for garbage collection.

Maximum number of blocks to garbage collect at every garbage collection call.

Default: 2

Maximum number of height to go through at each garbage collection step when cleaning forks during garbage collection.

Default: 100

Number of epochs for which we keep store data.

Default: 5

How often gc should be run

Default: [object Object]

Expected increase of header head height per second during header sync

How much time to wait after initial header sync

How much time to wait after some progress is made in header sync

How much time to wait before banning a peer in header sync if sync is too slow

Period between logging summary information.

Enable coloring of the logs

plaincolored

Maximum wait for approvals before producing block.

Maximum duration before skipping given height.

Gas amount

Minimum duration before producing block.

Minimum number of peers to start syncing.

Number of block producer seats

Maximum size of state witnesses in the OrphanStateWitnessPool. We keep only orphan witnesses which are smaller than this size. This limits the maximum memory usage of OrphanStateWitnessPool.

OrphanStateWitnessPool keeps instances of ChunkStateWitness which can't be processed because the previous block isn't available. The witnesses wait in the pool until the required block appears. This variable controls how many witnesses can be stored in the pool.

Limit the time of adding transactions to a chunk. A node produces a chunk by adding transactions from the transaction pool until some limit is reached. This time limit ensures that adding transactions won't take longer than the specified duration, which helps to produce the chunk quickly.

Produce empty blocks, use false for testing.

Configures whether the node checks the next or the next next epoch for network version compatibility.

NextNextNext

Listening rpc port for status.

Save observed instances of invalid ChunkStateWitness to the database in DBCol::InvalidChunkStateWitnesses. Saving invalid witnesses is useful for analysis and debugging. This option can cause extra load on the database and is not recommended for production use.

Save observed instances of ChunkStateWitness to the database in DBCol::LatestChunkStateWitnesses. Saving the latest witnesses is useful for analysis and debugging. This option can cause extra load on the database and is not recommended for production use.

Whether to persist state changes on disk or not.

save_trie_changes should be set to true iff - archive if false - non-archival nodes need trie changes to perform garbage collection - archive is true, cold_store is configured and migration to split_storage is finished - node working in split storage mode needs trie changes in order to do garbage collection on hot.

Whether to persist transaction outcomes to disk or not.

Whether to persist partial chunk parts for untracked shards or not.

Skip waiting for sync (for testing or single node testnet).

Number of threads for StateRequestActor pool.

Number of seconds between state requests for view client. Throttling window for state requests (headers and parts).

Maximum number of state requests served per throttle period

Options for syncing state.

Configures how to dump state to external storage.

Zstd compression level for state parts.

Default: 1

Syncs state from the peers without reading anything from external storage.

Peers

Whether to use the State Sync mechanism. If disabled, the node will do Block Sync instead of State Sync.

Additional waiting period after a failed request to external storage

How long to wait for a response from centralized state sync

How long to wait for a response from p2p state sync

How long to wait after a failed state sync request

How often to check that we are not out of sync.

Sync height threshold: below this difference in height don't start syncing.

Maximum number of block requests to send to peers to sync

While syncing, how long to check for each step.

One of multiple possible types

Limit of the size of per-shard transaction pool measured in bytes. If not set, the size will be unbounded.

Upper bound of the byte size of contract state that is still viewable. None is no limit

Time to persist Accounts Id in the router without removing them.

If the node is not a chunk producer within that many blocks, then route to upcoming chunk producers.

Data structure for semver version and github tag or commit.

Default:

Number of threads for ViewClientActor pool.

If true, the runtime will do a dynamic resharding 'dry run' at the last block of each epoch. This means calculating tentative boundary accounts for splitting the tracked shards.