Releases: near/nearcore
2.6.5
CODE_COLOR: CODE_YELLOW_MAINNET
RELEASE_VERSION: 2.6.5
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Non-protocol Changes
- This release fixes a bug which caused chunk producers to sometimes crash when processing contract deployments. We recommend all validators to upgrade to 2.6.5 to prevent these crashes.
This change can cause nodes to output warnings like "Failed to reed solomon decode deployed contracts". This is expected, it doesn't mean that there's something wrong with the node.
2.6.4
CODE_COLOR: CODE_GREEN_MAINNET
RELEASE_VERSION: 2.6.4
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Non-protocol Changes
- Fix a performance issue which sometimes caused nodes started from empty state (synchronized using epoch sync, not from a snapshot) to experience heavy CPU usage when serving header sync requests
2.7.0-rc.2
CODE_COLOR: CODE_GREEN_TESTNET
RELEASE_VERSION: 2.7.0-rc.2
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Protocol Changes
- Fix an unintended change introduced in
2.7.0-rc.1that removedStateChangeCauseenum variant from the middle. Nodes with2.7.0-rc.1are not able to answer state changes queries for old data if state changes includeBandwidthSchedulerStateUpdate. (#13835)
Non-protocol Changes
- Fix a performance issue which sometimes caused nodes started from empty state (synchronized using epoch sync, not from a snapshot) to experience heavy CPU usage when serving header sync requests. (#13814)
Protocol upgrade voting
No protocol upgrade scheduled.
2.7.0-rc.1
CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.7.0-rc.1
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: TRUE
SECURITY_UPGRADE: FALSE
[2.7.0-rc.1]
Protocol Changes
One more shard will be added
A new shard layout for production networks (#13324), using 650 as the split boundary #13609. The number of shards will increase from 8 to 9 shards.
Non-upgraded validators will be kicked out after the voting epoch
When the protocol update version voting takes place, validators that did not upgrade to the latest version will be scheduled for removal (aka kickout) in the epoch the new version takes effect (#13375). This helps avoid missed blocks in the first epoch of the new version, as un-upgraded validators would produce invalid blocks. Upgrading the node after the voting took place won’t prevent the kickout.
- With 2.7.0, non-upgraded nodes won’t be able to progress after the voting epoch.
- In future network upgrades, non-upgraded nodes would be able to progress in the epoch between voting and the network ugprade.
If you don’t upgrade your node in time, it will corrupt your database and require a reset (e.g. from snapshot or using Epoch Sync).
Other changes
-
Implement NEP-536: Reduce the number of refund receipts by adding removing pessimistic gas pricing. Also introduce a gas refund penalty but set it to 0 to avoid potential negative impact. (#13397)
-
Implement P2P sync for state sync headers. (#13377)
-
Enable saturating float-to-int conversions in runtime. (#13414)
-
Add RPC query for viewing global contract code. (#13547)
Non-protocol Changes
-
Add promise batch host functions for global contracts. (#13565)
-
Stabilize
EXPERIMENTAL_changesRPC method and rename it tochanges. (#13722) -
Rename
TxRequestHandlerActortoRpcHandlerActorto reflect the change in the scope of its responsibilities. Otherwise its API change is fully backward-compatible, so the dependent services can handle it by simply renaming the type where it is mentioned explicitly. (#13259)
Protocol upgrade voting
Voting for protocol version 78 will start on Wednesday 2025-07-02 03:00:00 UTC.
Protocol upgrade to version 78 is expected to happen 7-14 hours later on Wednesday 2025-07-02 between 10:00 and 17:00 UTC.
Notes
Hardware requirements
After the binary update until the resharding (in protocol version 78), nodes that track the state need to load shard 0 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. On Testnet, 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 78 is adopted. After that, nodes that do not load memtries can be downscaled.
Recovery if it crashes during resharding
If neard is restarted or crashes immediately after the transition to the new protocol upgrade 78 (SimpleNightshadeV6), there's a chance that the process won't be able to start correctly because resharding got interrupted.
The error you might see is:
Chain(StorageError(MemTrieLoadingError("Cannot load memtries when flat storage is not ready for shard s10.v3, actual status: Resharding(CreatingChild)")))
To remediate run the following command until completion:
neard flat-storage resume-resharding --shard-id 0
And finally start neard again.
Rollback from 2.7 to 2.6
If a node experiences issues after updating from 2.6 to 2.7, it’s possible to roll it back to 2.6, but it requires manual action to undo the database migration.
Rolling back is only possible before the end of the voting epoch - after that the network won’t be compatible with neard 2.6.
Please keep the logs from the rollback process in case you run into any issues.
To roll back a node from 2.7 to 2.6, do the following:
- Stop the node.
- Using a 2.7 neard binary, run
neard database rollback-to26and 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, it should be instant. - Database will be rolled back to the version used by neard 2.6.
- Start the node using neard 2.6 binary.
Tracked shards config
The new way of specifying the tracked shards in config.json, is to use the tracked_shards_config field (introduced in #13154).
- For validators, use:
"tracked_shards_config": "NoShards". - To track all shards (e.g. RPC or archival nodes), use
"tracked_shards_config": "AllShards".
This config field cannot be used simultaneously with any of these deprecated fields (doing so will result in a panic at the neard startup): tracked_shards, tracked_accounts, tracked_shadow_validator, or tracked_shard_schedule.
Block production delay
It is advised (though not mandatory) to use the reduced (from 100ms to 10ms) block production delay (introduced in #13523). Doing so, would slightly improve your node performance. You can do it by changing the value in config.json: consensus.doomslug_step_period={"secs":0,"nanos":10000000}
2.6.3
CODE_COLOR: CODE_GREEN_MAINNET
RELEASE_VERSION: 2.6.3
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Non-protocol Changes
- Allow chunk-only validators (outside the top 100 validators, not chunk producers) to join the Tier 1 network. This reduces latency of messages sent and received by chunk validators and improves the chunk endorsement rate.
2.6.3-rc.2
CODE_COLOR: CODE_GREEN_TESTNET
RELEASE_VERSION: 2.6.3-rc.2
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Non-protocol Changes
- Allow chunk-only validators (outside the top 100 validators, not chunk producers) to join the Tier 1 network. This reduces latency of messages sent and received by chunk validators and improves the chunk endorsement rate.
2.6.3-rc.1
CODE_COLOR: CODE_GREEN_TESTNET
RELEASE_VERSION: 2.6.3-rc.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Non-protocol Changes
- Allow chunk-only validators (outside the top 100 validators, not chunk producers) to join the Tier 1 network. This reduces latency of messages sent and received by chunk validators and improves the chunk endorsement rate.
2.6.2
CODE_COLOR: CODE_GREEN_MAINNET
RELEASE_VERSION: 2.6.2
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Non-protocol Changes
- Enabled TCP_NODELAY on all peer connections to reduce latency. Improves chunk endorsement rate for validators.
2.6.2-rc.1
CODE_COLOR: CODE_GREEN_TESTNET
RELEASE_VERSION: 2.6.2-rc.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Non-protocol Changes
- Enabled TCP_NODELAY on all peer connections to reduce latency. Improves chunk endorsement rate for validators.
2.6.1-rc.1
eda51b5CODE_COLOR: CODE_GREEN_TESTNET
RELEASE_VERSION: 2.6.1-rc.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE
Protocol Changes
Nothing on top of 2.6.0-rc.2
Non-protocol Changes
- Improved chunk distribution to speed up chunk validation and improve endorsement rate.
Protocol upgrade voting
No protocol upgrade scheduled.