Releases: near/nearcore
2.6.0-rc.1
CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.6.0-rc.1
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: TRUE
SECURITY_UPGRADE: FALSE
Protocol Changes
- Implemented support for global contracts: NEP-591
- Implemented Optimistic Block to remove doubled chunk execution latency from block & chunk production flow #10584
Non-protocol Changes
No Changes
Protocol upgrade voting
Voting for protocol version 77 will start on Monday 2025-04-14 19:00:00 UTC
Protocol upgrade to version 77 is expected to happen 12-24 hours later on Tuesday 2025-04-15 between 7:00 and 19:00 UTC
Required config update after protocol upgrade
After the network upgrades to protocol 77 we will ask node operators to update some config values to make the chain produce blocks at a faster rate. We will share the exact instructions after the protocol upgrade.
Database migration
This release includes a database migration from version 43 to version 44.
When neard 2.6 is started for the first time, it will start the migration and convert the database to the new version. Please don’t interrupt the migration, if you interrupt it you will have to restore the database from a pre-migration snapshot.
On testnet validator and rpc nodes the migration takes about 5 seconds.
On testnet archival nodes the migration takes about 60 seconds
No additional disk space is needed for the migration.
Rollback from 2.6 to 2.5
If a node experiences issues after updating from 2.5 to 2.6, it’s possible to roll it back to 2.5, but it requires manual action to undo the database migration.
Rolling back is only possible before the protocol upgrade - after the protocol upgrade the network will move to a new version that isn’t compatible with neard 2.5
The rollback procedure has been tested, but it’s fairly new and there’s still a possibility that something will go wrong. Please keep the logs from the rollback process in case you run into any issues.
To roll back a node from 2.6 to 2.5, do the following
- Stop the node
- Using a 2.6 neard binary, run
./neard database rollback-to25and confirm the rollback. After confirmation the rollback process will start. Please don’t interrupt the rollback process, it could corrupt the database. Wait for the process to finish. - Database will be rolled back to the version used by neard 2.5
- Start the node using neard 2.5 binary
Be patient, preparing a big archival database for rollback can take up to 5 minutes.
2.5.2
CODE_COLOR: CODE_RED_MAINNET
RELEASE_VERSION: 2.5.2
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: TRUE
Protocol Changes
Nothing scheduled for this release.
Non-protocol Changes
Improve performance and fix incorrect assumptions/behaviour in the indexer.
Filter out transactions that have already expired instead of processing them.
Note
Indexer and validator nodes should be upgraded immediately.
2.5.1
CODE_COLOR: CODE_YELLOW_MAINNET
RELEASE_VERSION: 2.5.1
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Protocol Changes
Nothing on top of 2.5.0.
Non-protocol Changes
This release fixes the issue where validators were missing chunks.
Protocol upgrade voting
The voting schedule was shifted from 2.5.0 to give more time for adoption:
Voting for protocol version 74 will start on Tuesday 2025-03-11 22:00 UTC.
Voting for protocol version 75 will start on Sunday 2025-03-16 10:00 UTC.
Voting for protocol version 76 will start on Tuesday 2025-03-18 18:00 UTC.
Notes
For detailed notes about resharding, refer back to the 2.5.0 release.
2.5.0
We identified an issue in this release, please upgrade to 2.5.1
CODE_COLOR: CODE_YELLOW_MAINNET
RELEASE_VERSION: 2.5.0
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
ShardIdsshould 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-03-09 10:00 UTC.
Voting for protocol version 75 will start on Tuesday 2025-03-11 18:00 UTC.
Voting for protocol version 76 will start on Sunday 2025-03-16 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.5.0-rc.3
CODE_COLOR: CODE_GREEN_TESTNET
RELEASE_VERSION: 2.5.0-rc.3
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Protocol Changes
Nothing on top of 2.5.0-rc.2
Non-protocol Changes
- Indexer: Fix a bug where the indexer would skip the entire first block of the epoch with a new shard layout if there is a missed chunk in the newly created shard.
- Metrics: Change
near_client_tracked_shardsto use shard uid instead of shard index.
Protocol upgrade voting
No protocol upgrade scheduled.
2.5.0-rc.2
CODE_COLOR: CODE_GREEN_TESTNET
RELEASE_VERSION: 2.5.0-rc.2
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Protocol Changes
Nothing on top of 2.5.0-rc.1
Non-protocol Changes
- State sync: Resolve the race condition that causes the state dumper node to have a bad state snapshot and be unable to generate state parts.
Notes
Information regarding resharding and hardware requirements can be found in 2.5.0-rc.1 release notes.
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.
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
ShardIdsshould 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:
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