Deprecate mplex #3866
Deprecate mplex #3866
Conversation
| Overlay multiplexers are not necessary with QUIC since the protocol provides native multiplexing, | ||
| but they need to be layered atop TCP, WebSockets, and other transports that lack such support. |
There was a problem hiding this comment.
I think this paragraph about QUIC is valuable. I think we shouldn't lose it. Maybe should we change the topic to "Why are we using yamux?" instead and remove the mplex part?
There was a problem hiding this comment.
A better question might be "why don't we go straight to QUIC and skip yamux as a requirement"
There was a problem hiding this comment.
A better question might be "why don't we go straight to QUIC and skip yamux as a requirement"
Yeah, and the answer is that it's not easy to find a stable QUIC library for some programming languages and we decide to make QUIC optional instead, but preferable.
There was a problem hiding this comment.
the rarity-of-implementation argument can be said of yamux too which is libp2p-only - https://blog.cloudflare.com/http3-usage-one-year-on saw 30% quic traffic share last year, meaning that any language that doesn't have a quic will have one soon.
ie in nim-libp2p, we have a yamux that hasn't been battle-tested really but it's kind of pointless spending time on it knowing that it's on its way out and entirely useless outside of a narrow libp2p window.
mplex otoh has been working for the consensus layer for years now so a few more months to get quic in place is not going to make any difference.
|
From what I gather I guess it would be nice to set a rough timeframe for Nimbus and Teku to be ready. Would someone like to suggest a rough time frame? We can also target a fork if we want? |
|
From nimbus, our preference would probably be to go straight to QUIC and skip the yamux step, given that yamux is pretty much a dead end anyway (de-facto unmaintained). |
|
I would support going straight to QUIC and skipping |
|
From Teku perspective, as mentioned we still have work to do on |
|
Ok. Looks like consensus is to move straight to QUIC. I'll keep this issue open and try and make a tally of progress. So we know how close we are to being able to shift. |
Mplex was a simple stream multiplexer created in the early days of libp2p.
It has since been deprecated and is now potentially becoming a security vulnerability as it is inefficient and unmaintained.
The general recommendations are to use yamux or QUIC.
Lighthouse currently supports mplex and yamux over TCP and QUIC. We are hoping to deprecate mplex and remove support for it in the near future.
We don't want to harm other clients in this process, so we are hoping for some visibility on this deprecation.
Current Progress