mump2p: How It Actually Works
mump2p is already running on Ethereum Hoodi testnet.
But how does it actually integrate with a validator? What happens at the protocol level?
Here's the full technical picture.
mump2p runs as a sidecar alongside any standard Ethereum validator client like Lighthouse, Prysm, or Teku.
No changes to the validator client itself. no changes to consensus logic. no new hardware required.
It slots into the existing setup as an additional process that handles the data propagation layer.
The architecture is simple.
Gateways sit between validators and the Ethereum P2P network.
Each gateway works as a transparent acceleration layer.
A validator's consensus client communicates normally with its gateway, then the gateway handles propagation via mump2p to the rest of the network.
Validators don't change their operation. the propagation layer changes underneath them.
When a block arrives at a gateway :
1. The gateway receives the block from the proposer's consensus client
2. It fragments the block into RLNC coded packets using algebraic linear combinations
3. It begins broadcasting unique fragments to peer gateways immediately
4. Receiving gateways recode received fragments and forward fresh combinations downstream
No gateway needs the full block before forwarding. every hop contributes new information.
The Prometheus metrics architecture
Each gateway records key data points per block :
→ Slot time, the deterministic start
→ libp2p received timestamp, the Gossipsub path
→ mump2p received timestamp, the Optimum path
→ Gateway ID
Both protocols run simultaneously on every block. same block, same gateway, only the protocol differs.
This makes the comparison methodology airtight.
Data is scraped into Prometheus histograms every 5 seconds across all 30 gateways.
This produces percentile views, time series latency evolution, and fleet wide consistency checks.
• p50
• p95
• p99
This is the same infrastructure used for the published 6x result.
The 30 gateway global fleet is distributed across US, EU, and Asia.
Each gateway independently measures both protocols on every block.
The ~200-250ms spikes visible in the latency charts are cross continental propagation. physics, not protocol.
They appear consistently across all gateways for the same blocks, which is how they're identified and characterized.
The dual path measurement is the methodological key.
Because Gossipsub and mump2p run in parallel on the same block from the same gateway, external variables affect both protocols identically.
Network congestion, block size, and time of day hit both paths the same way.
The only variable is the propagation path.
The performance difference is attributable to the mump2p/RLNC design.
Client compatibility is complete today :
→ Lighthouse supported
→ Prysm supported
→ Teku supported
All three major Ethereum consensus clients can run mump2p as a sidecar today with zero infrastructure changes.
The long term architecture extends mump2p beyond a single sidecar.
As Flexnodes join the network, they extend the fragment relay layer globally.
More coverage. more coding diversity. more redundant propagation paths.
The sidecar today becomes the entry point into a global decentralized relay network.
Validator operator? Get on the waitlist.
getoptimum.xyz/ethereum-vali…