This release contains the changes from polkadot-stable2509-2 to polkadot-stable2509-3.
ℹ️ Please note:
This is a patch release for the latest stable version: stable2509. If your nodes are already running on this stable release,
you should upgrade to this patch version to get the latest fixes.
The tag corresponding to the current patch release polkadot-stable2509-3 and matching the old pattern will be
available under polkadot-v1.20.3.
The following crates were updated to the corresponding versions:
- pallet-staking-async-rc-client@0.4.1
- sc-network@0.53.1
- cumulus-test-relay-sproof-builder@0.22.1
- pallet-staking-async@0.5.2
- sc-rpc-spec-v2@0.53.1
- cumulus-pallet-parachain-system@0.23.2
- parachains-runtimes-test-utils@26.0.1
- xcm-emulator@0.23.1
- asset-hub-westend-runtime@0.36.2
- cumulus-client-parachain-inherent@0.20.1
- cumulus-client-consensus-aura@0.26.2
Changelog
Changelog for Node Dev
ℹ️ These changes are relevant to: Those who build around the client side code. Alternative client builders, SMOLDOT, those who consume RPCs. These are people who are oblivious to the runtime changes. They only care about the meta-protocol, not the protocol itself.
[#10525]: fix(rpc-spec-v2): best block not announced immediately after initialised
Description
Fixes polkadot-api/polkadot-api#1244
The current chainHead_v1 implementation is not spec-compliant, as it states:
- Generates an
initializednotification- Generates one
newBlocknotification for each non-finalized block- Then a
bestBlockChangednotification- When a new block arrives, generates a
newBlocknotification- When the node finalizes a block, generates a
finalizednotification
And the current implementation only emits the bestBlockChanged notification after initialized if the best block is different from the finalized block.
PAPI recently is using this part of the spec as an assumption. Most chains are unaffected, but those that produce blocks on-demand (e.g. manual-seal) then have polkadot-api hanging until there's a higher block different than the finalized one.
Integration
This PR doesn't change any of the APIs of the node. Upgrade should be automatic.
Review Notes
This PR removes that condition so that the bestBlockChanged notification is always emitted. All tests are updated to this new behavior
[#10154]: aura/slot_based: Reduce authoring duration of the last produced block
This PR adjusts the block authoring to stop producing blocks 1 second before the scheduled slot change.
This introduces a safety buffer to prevent blocks from being authored too late wrt when next author is expected to produce a block.
- 2s blocks / 3 cores: The authoring duration of the last block is reduced from 2s to 1s.
- 500ms blocks / 12 cores: The authoring duration cannot be reduced past 500ms, therefore the last two blocks are no longer authored
[#10479]: cargo: Update yamux to 0.13.8 to avoid panics
This PR updates rust-yamux to 0.13.8 from 0.13.6:
This aims at not polling sockets past the point they return errors, effectively avoids panics when tungstenite websocket connections are used in combination with rust-yamux.
The fix was backported on 2512 but not on 2509
[#10541]: test-utils/fix: Parachains test-utils relay parent descendants mock data
This PR ensures that the parachains test-utils crate has 2 relay parent descendants for testing purposes.
Effectively fixes a panic because we missed this mock data for chains that started with RP_offset > 0:
Unable to verify provided relay parent descendants. expected_rp_descendants_num: 1 error: InvalidNumberOfDescendants { expected: 2, received: 0 }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Detected in:
Unblocks:
Inspired by a similar fix I've introduced in:
[#10362]: net/peerset: Optimize substream opening duration for SetReservedPeers
While triaging the Versi-net, I've discovered that the connection between collators and validators sometimes takes less than 20ms, while at other times it takes more than 500ms.
In both cases, the validators are already connected to a different protocol. Therefore, opening and negotiating substreams must be almost instant.
The slot timer of the peerset artificially introduces the delay:
- The
SetReservedPeersis received by the peerset. At this step, the peerset propagated theclosedSubstreamto signal that it wants to disconnect previously reserved peers. - At the next slot allocation timer tick (after 1s), the newly added reserved peers are requested to be connected
This can introduce an artificial delay of up to 1s, which is unnecessary.
To mitigate this behavior, this PR:
- Transforms the
enum PeersetNotificationCommandinto a structure. Effectively, the peerset can specify directly to close some substreams and open other substreams - Upon receiving the
SetReservedPeerscommand, peers are moved into theOpeningstate and the request is propagated to the litep2p to open substreams. - The behavior of the slot allocation timer remains identical. This is needed to capture the following edge cases:
- The reserved peer of the
SetReservedPeersis not disconnected, but backoff / pending closing. - The reserved peer is banned
- The reserved peer of the
cc @paritytech/networking
Detected during versi-net triaging of elastic scaling: #10310 (comment)
Changelog for Runtime Dev
ℹ️ These changes are relevant to: All of those who rely on the runtime. A parachain team that is using a pallet. A DApp that is using a pallet. These are people who care about the protocol (WASM, not the meta-protocol (client).)
[#10311]: [Staking] Async Elections Post AHM
Staking elections can be configured so they run as soon as the era starts, but their results are buffered and only sent to RC after the end of session n - 2 and before start of session n - 1, assuming the new validator set must activate at end of session n.
This helps us avoid difficulty of timing the election precisely as elections are long running and can sometimes take longer than usual.
See documentation for pallet_staking_async::Config::PlanningEraOffset and pallet_staking_async_rc_client::Config::ValidatorSetExportSession to learn more.
Rust compiler versions
This release was built and tested against the following versions of rustc.
Other versions may work.
- Rust Stable:
1.88.0
Docker images
The docker images for the polkadot node binary and the polkadot-parachain binary can be found at Docker hub (will be available a few minutes after the release has been published):
You may also pull it with:
docker pull parity/polkadot:stable2509-3
or
docker pull parity/polkadot-parachain:stable2509-3