1.39.1

CODE_COLOR: CODE_GREEN_MAINNET
RELEASE_VERSION: 1.39.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

This release includes performance optimisations in the pre-fetcher logic and the network stack.
To benefit from these optimisation you need to update the node config store.claim_sweat_prefetch_config to include:

"claim_sweat_prefetch_config": [
      {
        "receiver": "claim.sweat",
        "sender": "token.sweat",
        "method_name": "record_batch_for_hold"
      },
      {
        "receiver": "claim.sweat",
        "sender": "",
        "method_name": "claim"
      }
],

This release does not contain a protocol upgrade.

Full Changelog: 1.39.0...1.39.1

1.39.1-rc.1

CODE_COLOR: CODE_GREEN_TESTNET
RELEASE_VERSION: 1.39.1-rc.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

This release includes performance optimisations in the pre-fetcher logic and the network stack.
To benefit from these optimisation you need to update the node config store.claim_sweat_prefetch_config to include:

"claim_sweat_prefetch_config": [
      {
        "receiver": "claim.sweat",
        "sender": "token.sweat",
        "method_name": "record_batch_for_hold"
      },
      {
        "receiver": "claim.sweat",
        "sender": "",
        "method_name": "claim"
      }
],

This release does not contain a protocol upgrade.

Full Changelog: 1.39.0...1.39.1-rc.1

1.39.0

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

Protocol Upgrade Voting

This release contains a protocol upgrade. Voting for upgrading to protocol version 66 will start on Wednesday 2024-04-10 03:00:00 UTC.

What's Changed

• This release introduces a change in the default behaviour of broadcast_tx_commit,send_tx, tx, EXPERIMENTAL_tx_status RPC methods. The default behaviour no longer waits for refund receipts. If you do need to wait for refund receipts, you need ask about it explicitly by using TxExecutionStatus::Final option ("wait_until": "FINAL" in the json request). More information in the docs.
• This release decreases the function call base execution cost to 1TGas.
• Introduces more trie values prefetching to optimise the contract execution.

Full Changelog: 1.38.2...1.39.0

1.38.2

CODE_COLOR: CODE_GREEN_MAINNET
RELEASE_VERSION: 1.38.2
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

This release includes important performance optimisations.
This release does not contain a protocol upgrade.

Fixes

• prefetch v2

Full Changelog: 1.38.1...1.38.2

1.38.1

CODE_COLOR: CODE_GREEN_MAINNET
RELEASE_VERSION: 1.38.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

This release includes important performance optimisations.
This release does not contain a protocol upgrade.

Fixes

• tracing: instrument contract cache operations

• vm: store compiled contracts directly in the filesystem

• Reapply "near-vm: use a recycling pool of shared code memories instea…

• refactor: move CompiledContractCache to vm_runner::cache module

• vm: AnyCache

• config: default max_loaded_contracts

• near_vm: change LimitedMemoryPool to create new maps if dry

• backport: optimization: do not load the wasm contract code if it is a…

• vm: do not hold a lock while executing the contract

• vm: don't hold lock while potentially compiling

Full Changelog: 1.38.0...1.38.1

1.38.0

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

Protocol Upgrade Voting

This release contains a protocol upgrade. Voting for upgrading to protocol version 65 will start on Wednesday 2024-03-20 14:00:00 UTC. Depending on epoch durations, resharding is expected to happen around Wednesday 2024-03-20 18:00 UTC +/-4h, and protocol adoption is expected to happen around Thursday 2024-03-21 10:00 UTC +/-4h. Resharding and adoption times are only estimates, since many factors influence them.

Managing Resharding

This protocol upgrade includes resharding of shard 2. Which means that after protocol upgrade we will have 6 shards. New shard split is defined by these border accounts vec!["aurora", "aurora-0", "game.hot.tg", "kkuuue2akv_1630967379.near", "tge-lockup.sweat"]

Important points:

• Resharding will happen in the epoch RIGHT AFTER protocol voting epoch (and RIGHT BEFORE actual protocol upgrade).
• If your node fails to reshard before protocol upgrade, it will not be able to continue being a part of the chain. If that happens, you should restart from a Pagoda provided backup.
• Resharding creates a database snapshot that is deleted right after resharding is finished. This snapshot will not take extra space at first, but you may notice a progressive increase of data folder size up to around 50GB higher than before. There should no longer be an issue with the data directory increasing to an unmanageable size.
• To monitor resharding you can use metrics near_resharding_status, near_resharding_batch_size, and near_resharding_batch_prepare_time_bucket. You can read more here /~https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding.md#monitoring.
• If you observe problems with block production or resharding performance, you can adjust resharding throttling configuration. Read more here /~https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding.md#monitoring.
• RAM usage during resharding is around 8-10GB.

Full resharding doc can be found here /~https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding.md.

Protocol Changes

• Resharding v3 - resharding of shard 2 implemented by #10725

Known issues

• This release removes state snapshot compaction configuration options, as they are no longer needed. Your node may emit a warning that those configuration options are not recognized, but this is not an issue.

1.37.3

CODE_COLOR: CODE_YELLOW_MAINNET
RELEASE_VERSION: 1.37.3
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

This release includes important performance optimisations.
This release does not contain a protocol upgrade.

Fixes

• Return in-memory cache of loaded artifacts #10788
• Support Included transaction status #10796

1.38.0-rc.2

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

Protocol Upgrade Voting

This release contains a protocol upgrade. Voting for upgrading to protocol version 65 will start on Tuesday 2024-03-12 18:00:00 UTC.

Fixes

This release applies the fixes included in 1.37.2 on top of 1.38.0-rc.1, as well as a minor metrics fix

1.37.2

Fixes

Fix an issue where flat storage is not properly updated during resharding.

1.38.0-rc.1

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

Protocol Upgrade Voting

This release contains a protocol upgrade. Voting for upgrading to protocol version 65 will start on Tuesday 2024-03-12 18:00:00 UTC.

Resharding

This release schedules another resharding operation that will split shard 2 to address congestion issues that have been occurring on mainnet. This contains no functional code changes on top of 1.37.1 aside from scheduling this new resharding operation. After the new protocol version is voted on, nodes will begin another reshard of shard 2, which is expected to take a couple hours. After the new protocol version is adopted, there will be 6 shards.