2.5.0-rc.1

CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.5.0-rc.1
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Protocol Changes

• [Feature] Resharding V3 - a new implementation for resharding and two new shard layouts for the production networks. NEP-568 (near/NEPs#568) This will happen with protocol version 75 and 76.
• [Feature] Cross-shard bandwidth scheduler - manages transferring receipts between shards, enabling higher throughput of cross-shard receipts and better horizontal scalability. NEP-584 (near/NEPs#584). This is enabled in protocol version 74.

Non-protocol Changes

• State sync: Moved the state sync point in the current epoch. Nodes need to wait a couple of blocks at the beginning of the epoch before starting state sync process. #12102 This is not a protocol change but will be enabled in protocol version 74.
• Parallelize transaction validation (including signature checks) before verify_and_charge_transaction, significantly improving throughput for transaction processing on the nodes. #12654
• Starting from this release the ShardIds should be considered arbitrary identifiers. In particular they will no longer be in the range [0, num_shards) and will not be in the order of accounts they include.

Protocol upgrade voting

This release will perform 3 protocol upgrades.
Voting for protocol version 74 will start on Sunday 2025-02-16 18:00 UTC.
Voting for protocol version 75 will start on Monday 2025-02-17 18:00 UTC.
Voting for protocol version 76 will start on Tuesday 2025-02-18 18:00 UTC.

Notes

State sync

Fast NEAR is the new provider of state parts for state sync. The new bucket is called fast-state-parts. The old bucket state-parts is deprecated and will be phased out with the next release.
We have updated the configs to reflect the change. If you need to manually change your config.json, set state_sync.sync.ExternalStorage.location.GCS.bucket to fast-state-parts.

Resharding

There are two new shard layouts included in this release. The network will undergo two resharding events and the number of shards will increase from 6 to 8 shards.

In the period leading up to resharding the nodes will need to load the shards that will be resharded into memory. This should not have an effect on the validator nodes because these nodes should have single shard tracking and memtrie enabled already. This will have an effect on the RPC, archival and any other nodes that track all shards and do not have memtrie enabled. Once the network is past the final resharding the node can be restarted to reduce the memory usage.

Starting from this release the ShardIds should be considered arbitrary identifiers. In particular they will no longer be in the range [0, num_shards) and will not be in the order of accounts they include.

Recovery if it crashes during resharding

If neard is restarted or crashes immediately after the transition to the new protocol upgrade 75(SimpleNightshadeV4) or 76(SimpleNightshadeV5), there's a chance that the process won't be able to start correctly because resharding got interrupted.

The error you will see is:
Chain(StorageError(MemTrieLoadingError("Cannot load memtries when flat storage is not ready for shard s3.v3, actual status: Resharding(CreatingChild)")))

To remediate run the following command until completion:
neard flat-storage resume-resharding --shard-id 3

And finally start neard again.

Hardware requirements

After the binary update until the last resharding (in protocol version 76), nodes that track the state need to load shard 2 and 3 into memory. This includes RPC, archival, indexers and validators with the exception of chunk validator nodes (outside of top 100) because they do not track any shards. To successfully go through resharding these nodes need at least 64GB of memory.

As with all the hardware requirements, validators that expect to become producers are also encouraged to have 64GB of memory. This is valid for validators between top 21 and 25.

The high memory requirements are in place from the moment of the binary update until the resharding process is finished in the epoch where protocol version 76 is adopted. After that, nodes that do not load memtries can be downscaled.

2.4.0

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

Protocol Changes

• [Optimization] Relax Congestion Control to allow more transactions to be accepted and buffered. #12241 #12430
• [Optimization] Exclude contract code from the state witness and distribute it separately. #11099
• [Bug fix] Fix invalid cost used for wasm_yield_resume_byte. #12192

Non-protocol Changes

• [Feature] Enable Epoch Sync: A capability to bootstrap a node from another active node. #73
• [Feature] Enable Decentralized state sync: To participate in providing state parts to peers, your node may use a small amount of additional network bandwidth. Snapshot generation should not require significant storage, as snapshots are essentially hard links to database files, which are cleaned up at the end of each epoch. #12004

Protocol upgrade voting

Voting for protocol version 73 will start on Sunday 2024-12-15 12:00 UTC

Notes

We deprecated the default config file link (previously mentioned in docs) for the sake of role based config links.
For mainnet, these links are:

• validator node config
• rpc node config
• archival node config

The change mentioned above is also reflected on https://near-nodes.io/validator/deploy-on-mainnet#run-the-node

2.4.0-rc.2

CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.4.0-rc.2
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Non-protocol Changes

• Several fixes which improve the speed and robustness of state sync (#12507).
• Fix Epoch Sync not starting sometimes (#12563).

While not mandatory, the patch is highly recommended for the syncing and catch-up mechanism to function reliably and stably.

2.4.0-rc.1

CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.4.0-rc.1
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: TRUE
SECURITY_UPGRADE: FALSE

Protocol Changes

• Relax Congestion Control to allow more transactions to be accepted and buffered. #12241 #12430
• Exclude contract code from the state witness and distribute it separately. #11099
• Fix invalid cost used for wasm_yield_resume_byte. #12192

Non-protocol Changes

• Enable Epoch Sync: A capability to bootstrap a node from another active node. #73
• Enable Decentralized state sync: To participate in providing state parts to peers, your node may use a small amount of additional network bandwidth. Snapshot generation should not require significant storage, as snapshots are essentially hard links to database files, which are cleaned up at the end of each epoch. #12004

Protocol upgrade voting

Voting for protocol version 73 will start on Sunday 2024-11-24 15:00 UTC

2.3.1

CODE_COLOR: CODE_RED_MAINNET
RELEASE_VERSION: 2.3.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: TRUE

Non-protocol Changes

• Relaxes size limit on receipts
• Adds a tx_root check when validating a chunk state witness

This release fixes an issue that could lead to unexpected behavior when processing blocks. Please upgrade as soon as you're able.

2.3.0

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

Protocol Changes

• Sets chunk_validator_only_kickout_threshold to 70. Uses this kickout threshold as a cutoff threshold for contribution of endorsement ratio in rewards calculation: if endorsement ratio is above 70%, the contribution of endorsement ratio in average uptime calculation is 100%, otherwise it is 0%. Endorsements received are now included in BlockHeader to improve kickout and reward calculation for chunk validators.
• Changes the way receipts are stored in the state for the purpose of correct gas and size calculations in congestion control
• Storage compute costs for function calls are lowered (read_base, has_key, read_value, touching_trie_node) and a new large_read_overhead is introduced for reads of values over 4k. See #11925 and #12044

Non-protocol Changes

• RPC: started using non 200 HTTP codes for some errors, see the details here
• Added documentation and a reference script to recover the data lost in archival nodes at the beginning of 2024.
• Archival nodes only: Stop saving partial chunks to PartialChunks column in the Cold DB. Instead, archival nodes will reconstruct partial chunks from the Chunks column.

Protocol upgrade voting

Voting for protocol version 72 will start on Tuesday 2024-11-05 10:00 UTC

2.3.0-rc.4

CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.3.0-rc.4
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Non-protocol Changes

• Changes state sync logic so that nodes will download parts from GCS instead of from peers, as it was before this release.

This release is marked as CODE_YELLOW because it may help with some of the issues we have seen on testnet, and nodes (especially validators) should upgrade at their earliest convenience

2.3.0-rc.3

CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.3.0-rc.3
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Non-protocol Changes

• Fixes an issue with state sync downloads that led to nodes falling behind the chain: #12205

2.3.0-rc.2

CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.3.0-rc.2
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Non-protocol Changes

• Fixes an issue with sustained high CPU usage related to state sync requests: #12197

2.3.0-rc.1

CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.3.0-rc.1
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Protocol Changes

• Sets chunk_validator_only_kickout_threshold to 70. Uses this kickout threshold as a cutoff threshold for contribution of endorsement ratio in rewards calculation: if endorsement ratio is above 70%, the contribution of endorsement ratio in average uptime calculation is 100%, otherwise it is 0%. Endorsements received are now included in BlockHeader to improve kickout and reward calculation for chunk validators.
• Changes the way receipts are stored in the state for the purpose of correct gas and size calculations in congestion control
• Storage compute costs for function calls are lowered (read_base, has_key, read_value, touching_trie_node) and a new large_read_overhead is introduced for reads of values over 4k. See #11925 and #12044

Non-protocol Changes

• Added documentation and a reference script to recover the data lost in archival nodes at the beginning of 2024.
• Archival nodes only: Stop saving partial chunks to PartialChunks column in the Cold DB. Instead, archival nodes will reconstruct partial chunks from the Chunks column.
• Decentralized state sync: Before, nodes that needed to download state (either because they're several epochs behind the chain or because they're going to start producing chunks for a shard they don't currently track) would download them from a centralized GCS bucket. Now, nodes will attempt to download pieces of the state from peers in the network, and only fallback to downloading from GCS if that fails. Please note that in order to participate in providing state parts to peers, your node may generate snapshots of the state. These snapshots should not take too much space, since they're hard links to database files that get cleaned up on every epoch.

Protocol upgrade voting

Voting for protocol version 72 will start on Monday 2024-10-07 10:00 UTC