nearcore 2.12.0

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

Protocol Changes

• The contract runtime has been upgraded to use the new Wasmtime-based runtime.
• The contract runtime now allows for bulk memory instructions in Wasm code.

Non-protocol Changes

• Fix VM compilation and cache metrics (near_vm_runner_compilation_seconds, near_vm_compiled_contract_cache_*) not being reported for contract deployment, global contract distribution, and pipelining code paths. Add new near_vm_compiled_contract_memory_cache_hits_total metric to distinguish in-memory cache hits from disk hits. (#15580)
• Removed deprecated fields from EpochConfig, GenesisConfig, and ProtocolConfigView: num_block_producer_seats_per_shard, avg_hidden_validator_seats_per_shard, num_chunk_only_producer_seats.
• New EXPERIMENTAL_receipt_to_tx RPC method that resolves a receipt ID back to the originating transaction hash and sender account. Requires save_receipt_to_tx config enabled and all-shards tracking. (#15414)
• New sync handler (sync-v2) replaces the legacy sync implementation with a clean state machine. Nodes are routed through one of two paths based on how far behind they are: near-horizon nodes sync blocks directly, while far-horizon nodes follow the full pipeline (epoch sync, header sync, state sync, block sync). (#15335)
• Epoch sync proofs are now maintained incrementally at each epoch boundary instead of being derived on demand. Block headers are garbage collected alongside block bodies on non-archival nodes, reducing disk usage. (#15412)
• Validator key consistency check runs once per epoch to detect mismatches between the node's validator key and the key registered on chain. Misconfigured nodes will exit via panic. (#15417)
• State sync status now shows download and apply parts progress. (#15391)
• Fix: allow Disconnect message on Tier3 connections. (#15405)
• Fix: gracefully handle expired peer in peer_connection_attempt. (#15390)
• Archival nodes with split storage (cold store) will run a one-time migration on startup that is expected to take 1–2 hours depending on disk performance. Expect downtime. Nodes without cold store are not affected. (#15503)

Protocol upgrade voting

This release upgrades the protocol version from 83 to 84. Voting for protocol version 84 will start on Wednesday June 10th 00:00 UTC. To continue participating in consensus, you need to upgrade your node before this time.

If voting succeeds in one epoch, the protocol upgrade to version 84 is expected to happen 7-14 hours after the voting epoch ends.