nearcore 2.3.0-rc.1
Voting for protocol version 72 will start on Monday 2024-10-07 10:00 UTC
- A pre-release, not marked stable on GitHub.
- The newest stable release in the 2.3 line: nearcore 2.3.1
- Newest nearcore: nearcore 2.14.0
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_thresholdto 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 inBlockHeaderto 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 newlarge_read_overheadis introduced for reads of values over 4k. See https://github.com/near/nearcore/issues/11925 and https://github.com/near/nearcore/pull/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
PartialChunkscolumn in the Cold DB. Instead, archival nodes will reconstruct partial chunks from theChunkscolumn. - 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