Deprecate mplex #3866
Deprecate mplex #3866
Conversation
specs/phase0/p2p-interface.md
Outdated
| 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. |
|
I am closing this issue because it seems stale. Please, do not hesitate to reopen it if this is a mistake |
|
Ok, reviving this old PR. It has been over a year since we brought this up. I think this is a reasonable amount of notice time. We are planning to remove mplex support from Lighthouse at the end of the year. cc @jxs |
Nice 👍 it would be good to get a status update from clients. cc @philknows @kasey @arnetheduck @lucassaldanha @sauliusgrigaitis Do all clients support QUIC now? |
Still WIP for us. We were working on it, but had to stop due to Fulu. We are planning to finish it ASAP now that Fulu is out of the door (🤞 ) |
|
Ditto nimbus, where it needs finishing - since we last wrote here, the quic backend for libp2p is has been completed but its integration into eth2 has not (high prio) |
|
@raulk do you have thoughts on this? |
|
In a testing phase for Lodestar. Needs some dusting up and monitoring for stability now that Fulu is shipped. |
|
The goal is to migrate to QUIC as a primary transport, keeping TCP+Yamux+Noise as a fallback transport stacking because ocassionally middleboxes block UDP traffic. In terms of sequencing, this is the safest way to conduct the shift:
If we agree on this, @MarcoPolo or I can submit an alternative PR that also removes spystream from the spec. |
My understanding is that UDP support is already a requirement for discv5. |
TCP+Mplex+Noise - we never made the move to yamux formally so mplex is the only supported fallback option in clients - the goal being to skip yamux entirely since it's a known dead end. |
Btw, we already have a de-facto hard requirement on UDP working (discv5), so dropping TCP is a strictly an increase in the ability for nodes to connect, removing TCP from the mix. |
I agree with that. There is no point in my opinion in spending engineering time with having an efficient Yamux implementation which will essentially act as a fallback when we have a battle tested TCP + Mplex in all clients. Maybe we can deprecate Yamux instead? |
|
@StefanBratanov, I'm not convinced we need a TCP fallback, but if we did we do not want to settle on mplex for the reasons listed here: https://github.com/libp2p/specs/pull/661/files |
|
I'm aware talk is cheap (especially cheaper than engineering effort) but I think having multiple robust networking paths (both UDP and TCP) is completely aligned with Ethereum's core principles (Durable and Reliable). The issue with TCP+Noise+Mplex is that the Mplex spec doesn't require flow control (and it's technically deprecated by libp2p)
Therefore I agree with @AgeManning and @raulk, that the consensus-spec should recommend support for (in order of preference)
And looking out further, maybe we deprecate the TCP+Noise+Yamux stack once every language has a Qmux implementation. But maintaining reliable network paths on both TCP and UDP should be required, in my opinion. The whole ethos of libp2p is that it's modular and can support a wide range of protocols simultaneously. So why not leverage that benefit? |
This is mostly a theoretical issue, ie the marginal benefit to ethereum of this feature is close to none due to how the protocol is structured (if a peer is stuck on one stream, it's likely dead/useless and can be disconnected anyway) - whatever benefit may be found is provided by quic already (and quic has other advantages).
The ethereum spec only needs to specify minimal support for interoperability - clients are free to support anything beyond that if they so desire (and can specify that in their own documentation). Practically, yamux is just as dead as mplex in terms of upstream support, so it doesn't contribute anything meaningful really that quic doesn't provide already - it is however a lot more complex than mplex (and because it was never required, several clients don't have hardened / performant implementations). Having it in this spec means the security surface of the protocol increases without any real benefit. |
12 participants
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