nearcore 1.31.0

Protocol Changes

• An empty protocol upgrade to facilitate migration of the network interfaces in the next version.

Non-protocol changes

• Enable TIER1 network. Participants of the BFT consensus (block & chunk producers) now can establish direct TIER1 connections between each other, which will optimize the communication latency and minimize the number of dropped chunks. To configure this feature, see advanced_configuration/networking. #8141, #8085, #7759
• /status response has now two more fields: node_public_key and validator_public_key. The node_key field is now deprecated and should not be used since it confusingly holds validator key. #7828
• Added near_node_protocol_upgrade_voting_start Prometheus metric whose value is timestamp when voting for the next protocol version starts. #7877
• neard cmd can now verify proofs from JSON files. #7840
• In storage configuration, the value trie_cache_capacities now is no longer a hard limit but instead sets a memory consumption limit. For large trie nodes, the limits are close to equivalent. For small values, there can now fit more in the cache than previously. #7749
• New options store.trie_cache and store.view_trie_cache in config.json to set limits on the trie cache. Deprecates the never announced store.trie_cache_capacities option which was mentioned in previous change. #7578
• New option store.background_migration_threads in config.json. Defines number of threads to execute background migrations of storage. Currently used for flat storage migration. Set to 8 by default, can be reduced if it slows down block processing too much or increased if you want to speed up migration. #8088,
• Tracing of work across actix workers within a process: #7866, #7819, #7773.
• Scope of collected tracing information can be configured at run-time: #7701.
• Attach node's chain_id, node_id, and account_id values to tracing information: #7711.
• Change exporter of tracing information from opentelemetry-jaeger to opentelemetry-otlp: #7563.
• Tracing of requests across processes: #8004.

Protocol Upgrade Voting

Voting for upgrading to protocol version 58 will start on 2023-02-13 15:00:00 UTC

Database Upgrade

The release needs a database upgrade, which takes about 1 minute for an RPC node, and about 2 hour and 10 minutes for an Archival node.

Config update note

Please note that you may need to update config.json file. Please ensure that config.json doesn't mention fields db_migration_snapshot_path or use_db_migration_snapshot. Recommended to enable DB-migration snapshots like this:

"store": {
    "migration_snapshot": true
}

CODE_COLOR: CODE_YELLOW_MAINNET
RELEASE_VERSION: 1.31.0
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: TRUE
SECURITY_UPGRADE: FALSE