build(deps): bump ring from 0.16.20 to 0.17.14 #389
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bumps [ring](https://github.com/briansmith/ring) from 0.16.20 to 0.17.14. - [Changelog](https://github.com/briansmith/ring/blob/main/RELEASES.md) - [Commits](https://github.com/briansmith/ring/commits) --- updated-dependencies: - dependency-name: ring dependency-version: 0.17.14 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
dependencies
dmitry-markin
approved these changes
May 8, 2025
lexnv
approved these changes
May 9, 2025
lexnv
added a commit
that referenced
this pull request
May 26, 2025
## [0.9.5] - 2025-05-26 This release primarily focuses on strengthening the stability of the websocket transport. We've resolved an issue where higher-level buffering was causing the Noise protocol to fail when decoding messages. We've also significantly improved connectivity between litep2p and Smoldot (the Substrate-based light client). Empty frames are now handled correctly, preventing handshake timeouts and ensuring smoother communication. Finally, we've carried out several dependency updates to keep the library current with the latest versions of its underlying components. ### Fixed - substream/fix: Allow empty payloads with 0-length frame ([#395](#395)) - websocket: Fix connection stability on decrypt messages ([#393](#393)) ### Changed - crypto/noise: Show peerIDs that fail to decode ([#392](#392)) - cargo: Bump yamux to 0.13.5 and tokio to 1.45.0 ([#396](#396)) - ci: Enforce and apply clippy rules ([#388](#388)) - build(deps): bump ring from 0.16.20 to 0.17.14 ([#389](#389)) - Update hickory-resolver 0.24.2 -> 0.25.2 ([#386](#386)) cc @paritytech/networking --------- Signed-off-by: Alexandru Vasile <[email protected]>
github-merge-queue bot
pushed a commit
to paritytech/polkadot-sdk
that referenced
this pull request
Jun 3, 2025
# Litep2p Becomes the Default Network Backend This PR finalizes the [litep2p](https://github.com/paritytech/litep2p) integration and makes it the default network backend for substrate-based chains. ## Litep2p Improvements After the stabilization, a forum post will follow with up to date information and more accurate measurements of the live impact of litep2p. ### CPU Usage Reduction **Litep2p consumes roughly 2x less CPU than the libp2p alternative**. This frees up resources for other usecases (subsystems) and enables running nodes on more cost-efficient hardware. This metric has been collected by the `networking::libp2p-node` metric of a live Kusama validator. This represents the CPU time spent on polling the networking task. Litep2p CPU consumption is on the left, using roughtly 1.3x CPUs, while libp2p on the right uses roughly 2.9-3x CPUs:  This metric has been collected by the NodeExporter of a live Kusama validator. Litep2p CPU consumption is on the left, using roughtly 230 CPU units, while libp2p on the right uses roughly 350 CPU units. This makes litep2p ~1.52 times more effiecient:  ### DHT Improvements and Authority Discovery Litep2p is able to discover peers faster via the Kademlia protocol than libp2p. This behavior manifests in faster discovery times for validators. For context, libp2p discovers 1K DHT records (authority records) in approximately 10 minutes, while litep2p discovers them in just 2.5 minutes (for more info see #7077 (comment)). This will improve issues we've seen with libp2p that causes validators to not receive rewards: - #8548 ### Stable Sync Peers Litep2p presents a more stable peer count in comparison with the libp2p backend. This ensures we can sync up faster than libp2p to the tip of the chain. In an older experiment, litep2p syncs to the tip of the chain in 526s, compared to 803s for libp2p. The stability of connections shows improvements for other protocols as well:  The previous image shows on the left the litep2p version and on the right the libp2p version. ### Revert Kusama Enablement This PR reverts #7866. Litep2p is now enabled by default, we don't need to selectively enable it on different chains. ### Litep2p 0.9.5 This release primarily focuses on strengthening the stability of the websocket transport. We've resolved an issue where higher-level buffering was causing the Noise protocol to fail when decoding messages. We've also significantly improved connectivity between litep2p and Smoldot (the Substrate-based light client). Empty frames are now handled correctly, preventing handshake timeouts and ensuring smoother communication. Finally, we've carried out several dependency updates to keep the library current with the latest versions of its underlying components. Fixed: - substream/fix: Allow empty payloads with 0-length frame ([#395](paritytech/litep2p#395)) - websocket: Fix connection stability on decrypt messages ([#393](paritytech/litep2p#393)) Changed: - crypto/noise: Show peerIDs that fail to decode ([#392](paritytech/litep2p#392)) - cargo: Bump yamux to 0.13.5 and tokio to 1.45.0 ([#396](paritytech/litep2p#396)) - ci: Enforce and apply clippy rules ([#388](paritytech/litep2p#388)) - build(deps): bump ring from 0.16.20 to 0.17.14 ([#389](paritytech/litep2p#389)) - Update hickory-resolver 0.24.2 -> 0.25.2 ([#386](paritytech/litep2p#386)) ### Fix peerset reserve only mode This has been move in PR: #8650 for ease of reviewing. The PR rejects non-reserved peers in the reserved-only mode of the litep2p notification peerset. --------- Signed-off-by: Alexandru Vasile <[email protected]>
pgherveou
pushed a commit
to paritytech/polkadot-sdk
that referenced
this pull request
Jun 11, 2025
# Litep2p Becomes the Default Network Backend This PR finalizes the [litep2p](https://github.com/paritytech/litep2p) integration and makes it the default network backend for substrate-based chains. ## Litep2p Improvements After the stabilization, a forum post will follow with up to date information and more accurate measurements of the live impact of litep2p. ### CPU Usage Reduction **Litep2p consumes roughly 2x less CPU than the libp2p alternative**. This frees up resources for other usecases (subsystems) and enables running nodes on more cost-efficient hardware. This metric has been collected by the `networking::libp2p-node` metric of a live Kusama validator. This represents the CPU time spent on polling the networking task. Litep2p CPU consumption is on the left, using roughtly 1.3x CPUs, while libp2p on the right uses roughly 2.9-3x CPUs:  This metric has been collected by the NodeExporter of a live Kusama validator. Litep2p CPU consumption is on the left, using roughtly 230 CPU units, while libp2p on the right uses roughly 350 CPU units. This makes litep2p ~1.52 times more effiecient:  ### DHT Improvements and Authority Discovery Litep2p is able to discover peers faster via the Kademlia protocol than libp2p. This behavior manifests in faster discovery times for validators. For context, libp2p discovers 1K DHT records (authority records) in approximately 10 minutes, while litep2p discovers them in just 2.5 minutes (for more info see #7077 (comment)). This will improve issues we've seen with libp2p that causes validators to not receive rewards: - #8548 ### Stable Sync Peers Litep2p presents a more stable peer count in comparison with the libp2p backend. This ensures we can sync up faster than libp2p to the tip of the chain. In an older experiment, litep2p syncs to the tip of the chain in 526s, compared to 803s for libp2p. The stability of connections shows improvements for other protocols as well:  The previous image shows on the left the litep2p version and on the right the libp2p version. ### Revert Kusama Enablement This PR reverts #7866. Litep2p is now enabled by default, we don't need to selectively enable it on different chains. ### Litep2p 0.9.5 This release primarily focuses on strengthening the stability of the websocket transport. We've resolved an issue where higher-level buffering was causing the Noise protocol to fail when decoding messages. We've also significantly improved connectivity between litep2p and Smoldot (the Substrate-based light client). Empty frames are now handled correctly, preventing handshake timeouts and ensuring smoother communication. Finally, we've carried out several dependency updates to keep the library current with the latest versions of its underlying components. Fixed: - substream/fix: Allow empty payloads with 0-length frame ([#395](paritytech/litep2p#395)) - websocket: Fix connection stability on decrypt messages ([#393](paritytech/litep2p#393)) Changed: - crypto/noise: Show peerIDs that fail to decode ([#392](paritytech/litep2p#392)) - cargo: Bump yamux to 0.13.5 and tokio to 1.45.0 ([#396](paritytech/litep2p#396)) - ci: Enforce and apply clippy rules ([#388](paritytech/litep2p#388)) - build(deps): bump ring from 0.16.20 to 0.17.14 ([#389](paritytech/litep2p#389)) - Update hickory-resolver 0.24.2 -> 0.25.2 ([#386](paritytech/litep2p#386)) ### Fix peerset reserve only mode This has been move in PR: #8650 for ease of reviewing. The PR rejects non-reserved peers in the reserved-only mode of the litep2p notification peerset. --------- Signed-off-by: Alexandru Vasile <[email protected]>
alvicsam
pushed a commit
to paritytech/polkadot-sdk
that referenced
this pull request
Oct 17, 2025
# Litep2p Becomes the Default Network Backend This PR finalizes the [litep2p](https://github.com/paritytech/litep2p) integration and makes it the default network backend for substrate-based chains. ## Litep2p Improvements After the stabilization, a forum post will follow with up to date information and more accurate measurements of the live impact of litep2p. ### CPU Usage Reduction **Litep2p consumes roughly 2x less CPU than the libp2p alternative**. This frees up resources for other usecases (subsystems) and enables running nodes on more cost-efficient hardware. This metric has been collected by the `networking::libp2p-node` metric of a live Kusama validator. This represents the CPU time spent on polling the networking task. Litep2p CPU consumption is on the left, using roughtly 1.3x CPUs, while libp2p on the right uses roughly 2.9-3x CPUs:  This metric has been collected by the NodeExporter of a live Kusama validator. Litep2p CPU consumption is on the left, using roughtly 230 CPU units, while libp2p on the right uses roughly 350 CPU units. This makes litep2p ~1.52 times more effiecient:  ### DHT Improvements and Authority Discovery Litep2p is able to discover peers faster via the Kademlia protocol than libp2p. This behavior manifests in faster discovery times for validators. For context, libp2p discovers 1K DHT records (authority records) in approximately 10 minutes, while litep2p discovers them in just 2.5 minutes (for more info see #7077 (comment)). This will improve issues we've seen with libp2p that causes validators to not receive rewards: - #8548 ### Stable Sync Peers Litep2p presents a more stable peer count in comparison with the libp2p backend. This ensures we can sync up faster than libp2p to the tip of the chain. In an older experiment, litep2p syncs to the tip of the chain in 526s, compared to 803s for libp2p. The stability of connections shows improvements for other protocols as well:  The previous image shows on the left the litep2p version and on the right the libp2p version. ### Revert Kusama Enablement This PR reverts #7866. Litep2p is now enabled by default, we don't need to selectively enable it on different chains. ### Litep2p 0.9.5 This release primarily focuses on strengthening the stability of the websocket transport. We've resolved an issue where higher-level buffering was causing the Noise protocol to fail when decoding messages. We've also significantly improved connectivity between litep2p and Smoldot (the Substrate-based light client). Empty frames are now handled correctly, preventing handshake timeouts and ensuring smoother communication. Finally, we've carried out several dependency updates to keep the library current with the latest versions of its underlying components. Fixed: - substream/fix: Allow empty payloads with 0-length frame ([#395](paritytech/litep2p#395)) - websocket: Fix connection stability on decrypt messages ([#393](paritytech/litep2p#393)) Changed: - crypto/noise: Show peerIDs that fail to decode ([#392](paritytech/litep2p#392)) - cargo: Bump yamux to 0.13.5 and tokio to 1.45.0 ([#396](paritytech/litep2p#396)) - ci: Enforce and apply clippy rules ([#388](paritytech/litep2p#388)) - build(deps): bump ring from 0.16.20 to 0.17.14 ([#389](paritytech/litep2p#389)) - Update hickory-resolver 0.24.2 -> 0.25.2 ([#386](paritytech/litep2p#386)) ### Fix peerset reserve only mode This has been move in PR: #8650 for ease of reviewing. The PR rejects non-reserved peers in the reserved-only mode of the litep2p notification peerset. --------- Signed-off-by: Alexandru Vasile <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bumps ring from 0.16.20 to 0.17.14.
Changelog
Sourced from ring's changelog.
Commits
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.