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.