Skip to content

Releases: libp2p/go-libp2p

v0.26.4

24 Mar 00:03
Compare
Choose a tag to compare

This patch release fixes a busy-looping happening inside AutoRelay on private nodes, see #2208.

v0.26.3

17 Mar 01:02
a1e6aa4
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.26.0...v0.26.3

v0.26.2

01 Mar 22:52
59a14cf
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.26.0...v0.26.2

v0.26.1

01 Mar 21:09
c738a48
Compare
Choose a tag to compare

Retracted

This release included some changes not intended for a patch release. The issue came from a bug in our release automation tooling. More details here: #2153.

New release coming soon.

What's Changed

Full Changelog: v0.26.0...v0.26.1

v0.26.0

23 Feb 08:21
a415d56
Compare
Choose a tag to compare

πŸ”¦ Highlights

Circuit Relay Changes

Removed Circuit Relay v1

We've decided to remove support for Circuit Relay v1 in this release. v1 Relays have been retired a few months ago. Notably, running the Relay v1 protocol was expensive and resulted in only a small number of nodes in the network. Users had to either manually configure these nodes as static relays, or discover them from the DHT.
Furthermore, rust-libp2p has dropped support and js-libp2p is dropping support for Relay v1.

Support for Relay v2 was first added in late 2021 in v0.16.0. With Circuit Relay v2 it became cheap to run (limited) relays. Public nodes also started the relay service by default. There's now a massive number of Relay v2 nodes on the IPFS network, and they don't advertise their service to the DHT any more. Because there's now so many of these nodes, connecting to just a small number of nodes (e.g. by joining the DHT), a node is statistically guaranteed to connect to some relays.

Unlimited Relay v2

In conjunction with removing relay v1, we also added an option to Circuit Relay v2 to disable limits.
This done by enabling WithInfiniteLimits. When enabled this allows for users to have a drop in replacement for Relay v1 with Relay v2.

Additional metrics

Since the last release, we've added additional metrics to different components.
Metrics were added to:

  • AutoNat: Current Reachability Status and Confidence, Client and Server DialResponses, Server DialRejections. The dashboard is available here.
  • Swarm:
    • Early Muxer Selection: Added early_muxer label indicating whether a connection was established using early muxer selection.
    • IP Version: Added ip_version label to connection metrics
  • Identify:
    • Metrics for Identify, IdentifyPush, PushesTriggered (#2069)
    • Address Count, Protocol Count, Connection IDPush Support (#2126)

We also migrated the metric dashboards to a top-level dashboards directory.

Changelog

Contributors

Contributor Commits Lines Β± Files Changed
Sukun 11 +2979/-696 76
Marten Seemann 5 +52/-3619 33
Marco Munizaga 11 +865/-520 35
Prithvi Shahi 5 +66/-21 10

Full Changelog: v0.25.1...v0.26.0

v0.25.1

10 Feb 03:08
5741b6c
Compare
Choose a tag to compare

What's Changed

Patch update to fix some test-utils used by https://github.com/libp2p/go-libp2p-kad-dht

See the release notes for v0.25.0 for more details on this release.

Full Changelog: v0.25.0...v0.25.1

v0.25.0

09 Feb 16:39
f0af39e
Compare
Choose a tag to compare

πŸ”¦ Highlights

Metrics

We've started instrumenting the entire stack. In this release, we're adding metrics for:

Our metrics effort is still ongoing, see #1356 for progress. We'll add metrics and dashboards for more libp2p components in a future release.

Switching to Google's official Protobuf compiler

So far, we were using GoGo Protobuf to compile our Protobuf definitions to Go code. However, this library was deprecated in October last year: https://twitter.com/awalterschulze/status/1584553056100057088. We benchmarked serialization and deserialization, and found that it's (only) 20% slower than GoGo. Since the vast majority of go-libp2p's CPU time is spent in code paths other than Protobuf handling, switching to the official compiler seemed like a worthwhile tradeoff.

Removal of OpenSSL

Before this release, go-libp2p had an option to use OpenSSL bindings for certain cryptographic primitives, mostly to speed up the generation of signatures and their verification. When building go-libp2p using go build, we'd use the standard library crypto packages. OpenSSL was only used when passing in a build tag: go build -tags openssl.
Maintaining our own fork of the long unmaintained go-openssl package has proven to place a larger than expected maintenance burden on the libp2p stewards, and when we recently discovered a range of new bugs (this and this and this), we decided to re-evaluate if this code path is really worth it. The results surprised us, it turns out that:

  • The Go standard library is faster than OpenSSL for all key types that are not RSA.
  • Verifying RSA signatures is as fast as Ed25519 signatures using the Go standard library, and even faster in OpenSSL.
  • Generating RSA signatures is painfully slow, both using Go standard library crypto and using OpenSSL (but even slower using Go standard library).

Now the good news is, that if your node is not using an RSA key, it will never create any RSA signatures (it might need to verify them though, when it connects to a node that uses RSA keys). If you're concerned about CPU performance, it's a good idea to avoid RSA keys (the same applies to bandwidth, RSA keys are huge!). Even for nodes using RSA keys, it turns out that generating the signatures is not a significant part of their CPU load, as verified by profiling one of Kubo's bootstrap nodes.

We therefore concluded that it's safe to drop this code path altogether, and thereby reduce our maintenance burden.

New Resource Manager types

  • Introduces a new type LimitVal which can explicitly specify "use default", "unlimited", "block all", as well as any positive number. The zero value of LimitVal (the value when you create the object in Go) is "Use default".
    • The JSON marshalling of this is straightforward.
  • Introduces a new ResourceLimits type which uses LimitVal instead of ints so it can encode the above for the resources.
  • Changes LimitConfig to PartialLimitConfig and uses ResourceLimits. This along with the marshalling changes means you can now marshal the fact that some resource limit is set to block all.
    • Because the default is to use the defaults, this avoids the footgun of initializing the resource manager with 0 limits (that would block everything).

In general, you can go from a resource config with defaults to a concrete one with .Build(). e.g. ResourceLimits.Build() => BaseLimit, PartialLimitConfig.Build() => ConcreteLimitConfig, LimitVal.Build() => int. See PR #2000 for more details.

If you're using the defaults for the resource manager, there should be no changes needed.

Resource Manager optimized metrics

We moved away from OpenCensus to the prometheus SDK. Metrics hot path now has no allocations and a test to ensure this behavior in the future. See #1955 for more details.

Websockets: change underlying library

From the unmantained https://github.com/gorilla/websocket to https://github.com/nhooyr/websocket. More details here: #1982.

Other Breaking Changes

We've cleaned up our API to consistently use protocol.ID for libp2p and application protocols. Specifically, this means that the peer store now uses protocol.IDs, and the host's SetStreamHandler as well.

What's Changed

Read more

v0.24.2

31 Dec 04:40
8231591
Compare
Choose a tag to compare

This patch release fixes two panics that could occur in the WebTransport code path.

What's Changed

Full Changelog: v0.24.1...v0.24.2

v0.24.1

12 Dec 06:28
47f9ea1
Compare
Choose a tag to compare

This patch release:

  • fixes a race condition in WebTransport, leading to streams not being accepted occasionally: quic-go/webtransport-go#53
  • includes the role (remote / local) in QUIC error messages: quic-go/quic-go#3629
  • fixes a bug in the routed host, that didn't always report the right error on connection failures: #1946

What's Changed

Full Changelog: v0.24.0...v0.24.1

v0.24.0

06 Dec 10:04
4c74181
Compare
Choose a tag to compare

Breaking Changes

Constructor options

  • removed the deprecated libp2p.DefaultStaticRelays and libp2p.StaticRelays options. Static relays can be configured as an option to libp2p.EnableAutoRelay
  • libp2p.Security now requires passing in a constructor (previously, it also allowed passing in a fully constructed security transport)
  • libp2p.Muxer now requires passing in a fully constructed muxer (previously, it also allowed passing in a muxer constructor)
  • Removed libp2pquic.DisableReuseport and libp2pquic.WithMetrics. These options are now available in the quicreuse package (quicreuse.DisableReuseport and quicreuse.WithMetrics), and can be enabled by using the libp2p.QUICReuse option (example: libp2p.QUICReuse(quicreuse.NewConnManager, quicreuse.DisableReuseport, quicreuse.WithMetrics)).

Under the hood, we now use fx in the construction of the host, which lead to a great simplification of our setup logic (see #1858 for details).

QUIC Versions

When we first rolled out QUIC support in 2020, QUIC wasn't an RFC yet (in fact, we were involved in the standardization process at the IETF!). Back then, we rolled out support for QUIC draft-29. This version is almost identical to RFC 9000, so there was never a good reason to force an update.

Now that rust-libp2p is shipping QUIC support, we decided to finally initiate the update. We do so by introducing a new multiaddress component: /ip4/1.2.3.4/udp/4001/quic now denotes a multiaddr that uses QUIC draft-29 (as it has before, we're just making it explicit now). QUIC v1 would use /ip4/1.2.3.4/udp/4001/quic-v1.
We intend to keep support for QUIC draft-29 for roughly half a year, and disable listening on draft-29 addresses after that.

Depending on how you configure your node, you might need to update the addresses you're listening on (i.e. change quic => quic-v1 in the addresses, or duplicate the QUIC addresses).

πŸ”¦ Highlights

WebTransport

We added experimental WebTransport support in our last release. Since then, we're using some magic to allow running QUIC and WebTransport on the same port. This means that users who've already configured port forwarding / firewall rules for QUIC don't need to do anything to allow WebTransport connections to their node.

Optimized Stream Multiplexer Selection

When dialing a TCP connection to another libp2p node, we perform the following steps:

  1. TCP 3-way handshake: 1 RTT
  2. multistream-select to negotiate the security protocol (TLS 1.3 or Noise): 1 RTT
  3. security handshake: 1 RTT
  4. multistream-select to negotiate the stream multiplexer (yamux or mplex)

In total, this handshakes takes 4 RTTs. In this release, we optimize this handshake by inlining the stream multiplexer negotiation into the security handshake. On the wire, this looks very different for TLS 1.3 and for Noise, but the result is the same: we know which stream multiplexer to use when the handshake finishes, and can therefore save one roundtrip on every handshake. Head to the specification to learn how this works in detail.

🐞 Bugfixes since v0.23.4

Changelog

Read more