[PERCH] Request for Node Operators to run and test Optimum (mump2p)

Department of Decentralisation
1

Below is a post in response to PERCH: Protocol Evaluation and Request Coordination Hub and the APM Framework. Thank you for this opportunity to engage with the Lido Community.

TLDR

Optimum is requesting that Lido Curated Module node operators run and test mump2p, a gossip protocol that accelerates Ethereum block propagation using Random Linear Network Coding (RLNC). On Mainnet, mump2p has been measured propagating 2.42x faster with 7.88x lower variance compared to the libp2p baseline, translating into measurable improvements in head vote accuracy and attestation timeliness - both established drivers of validator APR.

mump2p fits the APM framework as a Protocol delivered via a Sidecar, runs in parallel to libp2p, and can be opted in or out at any time with a single peer list config change.

We are proposing an one-month PERCH testnet evaluation on Hoodi.

Background

Ethereum’s consensus layer relies on libp2p’s Gossipsub, which was designed for reliability over speed. Latency has become a meaningful constraint on validator income: late block arrival reduces head vote accuracy, increases the risk of missed attestations, and compresses the window available to block builders when assembling payloads. As the consensus layer becomes more performance-sensitive, propagation latency translates directly into validator rewards and network efficiency.

This matters particularly for Lido: because of its share of Ethereum’s staked ETH, performance gains across its operator set compound into network-wide benefits - stronger consensus and better geo-diversity - while also supporting stETH’s competitiveness through more consistent validator rewards.

What is mump2p?

mump2p is a gossip protocol built on libp2p that uses RLNC to improve message propagation. Instead of transmitting whole messages between peers, mump2p breaks messages into coded shards that can be independently forwarded and mathematically recombined. Any intermediate node can generate new coded shards from its current set without waiting for the full message, enabling faster, more fault-tolerant propagation.

Mapped to the APM taxonomy:

  • Mechanism: Faster CL messages propagation (blocks, attestations)
  • Protocol: mump2p, an RLNC-coded gossip protocol
  • Sidecar: Optimum Gateway, run alongside the beacon node

The Gateway is a sidecar, it requires no changes to validator software, no modifications to consensus behavior, and introduces no new slashing conditions. mump2p is live on both testnet and mainnet.

Full protocol documentation: mump2p Protocol
Gateway user guide: Optimum Gateway
Learn more about Optimum and the vision behind mump2p: Free and faster Ethereum beacon block propagation

Details of Request for Testing

Number of Participants: Multiple Lido Curated Module operators are currently running mump2p on Hoodi, operating in excess of the validator key threshold set by the APM Framework. We invite additional Lido operators to express interest by replying to this thread and completing the application form below.

Application Form to join the Testnet: Optimum (mump2p): Lido PERCH Participation Form

Testing Outline

  • Software and/or protocols to be used: mump2p is the gossip protocol used on the Optimum Network with the repo here, documentation on testing here, and documentation to learn more can be found here.
  • Networks: Hoodi
  • Duration: One month

Requirements

  • Expected Impact: Operators add the Optimum Gateway as a sidecar container alongside their existing beacon node, as outlined in the documentation. Setup takes 1–2 hours per operator, hands-on engineering support from Optimum is available. The Gateway is compatible with Prysm, Teku, Lighthouse, Nimbus, and Lodestar.

Alignment with Ethereum Roadmap

  • Faster block and attestation propagation strengthens consensus, reduces reorg risk, and creates headroom for higher gas limits and shorter slot times.
  • Coded shards add redundancy at the gossip layer, improving network resilience.
  • Reduced propagation latency narrows the performance gap between validators in network hubs and those in underserved regions, strengthening geo-diversity.

Neutrality and Inclusivity

  • Open to any Lido Curated Module operator with no exclusivity, no commitments, and no dependency on specific validator software.

Licensing

Adherence to Community Standards

  • Fits the APM framework taxonomy as a Protocol delivered via a Sidecar.

Security Best Practices

  • Sidecar, not validator software. The Gateway runs alongside the beacon client. It relays gossip traffic between the local CL and the mump2p mesh. It does not access validator keys, does not sign attestations or blocks, and does not change consensus duties. If the Gateway stops, there is no fallback needed as the CL client never stopped sending and receiving traffic from its libp2p/GossipSub peers.
  • Clear trust boundaries. Security is designed around boundaries operators control:
    • Local CL client — the gateway only forwards what the paired beacon client publishes; operators should restrict the CL-facing port to their intended client.

Call to Action

  • Lido Curated Module operators: Reply to this thread and complete the signup form to join the one-month Hoodi evaluation. Setup is a sidecar alongside your existing beacon client (~1–2 hours; Optimum support available).
  • Lido community & security reviewers: Questions and feedback welcome on this thread. We will publish the ProbeLab audit report and operator security guide alongside the public gateway repo; happy to share advance copies with reviewers engaged on this PERCH.
  • Timeline: Testing runs for one month on Hoodi; a closing performance summary will be posted to the Research Forum.

Resources

7 Likes
2

InfStones participated in OptimumP2P’s private testnet to evaluate its RLNC-based approach to faster and more efficient Ethereum block propagation.

During our testing, we operated the infrastructure alongside our validator setup and assessed its performance, reliability, and integration requirements.

Our experience showed that OptimumP2P provides a practical way to improve data propagation while reducing latency and bandwidth demands, without modifying validator software or consensus duties.

We had a positive experience working with the Optimum team, whose support made the testing and integration process smooth and effective.

4 Likes
3

As a representative of Ebunker NO, allow me to share our experience collaborating with OptimumP2P. In the testnet environment, we indeed observed a noticeable reduction in ETH network latency. We are excited to see Lido considering Optimum’s solution, and we would be delighted to participate in further testing.

4 Likes
4

HashKey Cloud ran the Optimum Gateway on Hoodi. Setup was straightforward — about an hour as a sidecar alongside our existing beacon client, with no changes to our CL stack, signing setup, or consensus duties. We measured roughly 200ms lower average attestation propagation on our nodes, which is a meaningful improvement at the margin where head vote accuracy is decided.
Working with the Optimum team was a pleasure — responsive, hands-on, and quick to answer questions during integration. The opt-in/opt-out design and clean separation from validator keys make this low-risk to evaluate. We’d encourage other operators to join the Hoodi run.

4 Likes
5

Blockdaemon participated in the Optimum Gateway trial on the Hoodi network. Over the course of the trial we observed an overall improvement in our attestation performance, including head, target and source votes.

Implementation: Deploying the Gateway was very straightforward. The documentation was clear, which allowed us to automate the rollout of the Optimum sidecar quickly across our infrastructure.

Maintenance: Ongoing maintenance has been minimal. We have rarely had to make changes to the Gateway, and neither CL nor EL client upgrades have impacted it.

Monitoring: Optimum exposes Prometheus metrics out of the box, which made it easy to fold the Gateway into our existing monitoring stack.

Based on this experience, we would strongly support deploying Optimum more widely on Hoodi to expand the testing set and gather more data.

3 Likes
6

Stakely has been running the mump2p Gateway on our Hoodi infrastructure and can confirm a smooth experience: quick setup, clear documentation, and zero incidents. No interference with our beacon nodes and no overhead on the host.

The sidecar approach keeps the risk profile low, which makes this an easy test to support. Happy to continue through the Hoodi evaluation and looking forward to the aggregated propagation data across operators.

1 Like
7

FP Validated(@FP_Validated) here. We’ve been running the pilot on Hoodi since late July, with the gateway paired to a validating beacon node. Stable so far, and setup effort matched what others described in this thread.

Since the stated goal is head vote accuracy and attestation timeliness, we’re measuring validator-side impact with misses classified by root cause (propagation-addressable vs next-proposer misses), following the methodology the Optimum team suggested. We open-sourced the tool we built for this: beacon-attestation-forensics. Other participants can use it to get cause-separated numbers from their own nodes.

We’ll post a full write-up once our measurement window closes.

2 Likes
8

Hi, stakefish here, we are interested in running Optimum Gateway on Hoodi.

2 Likes
9

SenseiNode would like to join the one-month Hoodi evaluation. Signup form completed.

The geo-diversity point resonates with us: as a LATAM-based operator, propagation latency relative to the main network hubs is a real constraint, so we are keen to measure what RLNC-coded gossip delivers from our regions specifically. Happy to share regional latency data as part of the closing summary if useful.

Nicolas Breil, SenseiNode

2 Likes
10

We measured mump2p on 36 mainnet full nodes for 11.5 days

With the block arrival latency each consensus client records for itself, difference-in-differences against untreated controls, plus a full parallel-trends stress test back to February.

A few things that came out of it:

  • Blocks arrived earlier on 3 of 6 clients: lighthouse ~120 ms, prysm ~60, grandine ~30 to 50. Lodestar half that, and half of it is control drift. Teku flat. Nimbus refuted, the treated nodes actually got slower.
  • The load-bearing evidence is within-host: machines that crossed a fleet rebuild with unchanged IP, consensus build and execution build moved anyway.
  • The gateway barely registered as a gossipsub mesh peer, 6.91 to 6.96 against a target of 8.
  • These were full nodes with no validators attached, so the attestation path was never exercised.

This is an early build v1.1.1.

Full writeup, per-client numbers, trend tests and confounder analysis: Measuring mump2p on mainnet: earlier blocks on three clients, none of it significant · StereumLabs Docs

2 Likes
11

Thank you for running an independent test and sharing your findings openly. We’ve looked into the results and identified a factor that may explain why the test didn’t show a statistically significant effect, along with a way to address it.

During your testing window, global acceleration was active across Ethereum mainnet, meaning blocks relayed through our network could benefit both mump2p and non-mump2p nodes. This made it difficult to isolate mump2p’s direct impact, and we should have communicated this upfront.

After October 26, we plan to switch to a setup where only registered operators receive acceleration, enabling a cleaner comparison. Results will be available through the console.

Our methodology is public here: Notion. In short, each operator is its own control: we measure block arrival at the operator’s own gateways relative to slot start, plus on-chain attestation outcomes, against that operator’s baseline from before global acceleration was switched on.

We welcome more independent analysis from operators and would encourage sharing results in this thread. If anything in the methodology is unclear, or you’d like help getting more interpretable results, happy to provide support.

2 Likes
12

Hi all, a quick update from the PERCH evaluation side.

The one-month Hoodi measurement window with the participating curated module operators is wrapping up. Thank you to everyone who connected keys and kept us posted on changes to your setups along the way.

What the Hoodi test was designed to show: that the mump2p gateway runs stably alongside libp2p and your existing validator setup, with no changes to client software, keys or consensus logic, and no added slashing risk. Alongside stability, we’ve been tracking whether blocks reach your nodes earlier via mump2p than over libp2p, and the on-chain metric that late block arrival most directly affects - wrong head votes on canonical blocks. Hoodi’s network conditions (missed and orphaned slots in particular) make attestation outcomes noisy, so those on-chain numbers are a directional read rather than a precise measure of impact. In our separate mainnet testing, we’ve been able to get a cleaner read on validator performance with very positive results.

What’s next:

  • We’ll post the fleet-level Hoodi summary on this thread once we’ve completed the end-of-window review.
  • Any next steps for Lido delegated stake on mainnet will be coordinated with Lido after the PERCH report is shared and reviewed by the Lido Team.
13

Hi all, closing out the PERCH evaluation. The one-month Hoodi measurement window ran from 17 September to 15 October with six curated module operators participating: P2P, Rocklogic, Ebunker, Stakefish, HashKey Cloud and Stakely. Below is the fleet-level summary.

Short version: the gateway ran alongside existing setups for the full window without incident, blocks reached Lido nodes 407 ms sooner over mump2p than over public libp2p across the four weeks, and wrong head votes fell 45% against the June control week, with Lido holding well below the Hoodi network’s wrong head rate in every week.

What the Hoodi test was designed to show

That the mump2p gateway runs stably alongside libp2p and your existing validator setup, with no changes to client software, keys or consensus logic, and no added slashing risk. Alongside stability, we tracked two performance reads. The first is block arrival: whether blocks reach your nodes earlier via mump2p than over public libp2p. The second is the on-chain outcome that late block arrival most directly affects: wrong head votes. A wrong head vote is an attestation that voted for a head which turned out not to be canonical, because the block arrived too late to be seen.

How it was measured

  • 267 of 307 Lido validator keys on Hoodi across the six operators. Only keys active in both the control and treatment windows with at least 95% duty coverage are counted, so the comparison is like for like.
  • Control: 16 to 23 June, before any gateway was connected. Treatment: four consecutive weeks, 17 September to 15 October, with gateways connected.
  • Attestation outcomes come from on-chain data via Xatu and are reported at the fleet level, aggregated across participating operators, as agreed when the window opened. With roughly 15 keys per operator on Hoodi (0x02 keys), per-operator numbers are too thin to read.
  • Wrong head rates are also shown relative to the full Hoodi validator set over the same windows. Hoodi’s network-wide rate moved a lot between June and October, so the relative read matters as much as the raw one.
  • Block arrival compares timing at the mump2p gateways against public Xatu sentry nodes over the same slots. Each operator can check this independently against their own gateway metrics in Grafana.

Block arrival (17 September to 15 October, 180,327 slots measured)

  • Blocks arrived 407 ms sooner over mump2p than public libp2p: p95 arrival from slot start 1,614 ms to 1,207 ms (-25%). The weekly lead ranged from 382 to 420 ms, so the result held steadily across the window.
  • Propagation spread 6.6x tighter: p95 minus first arrival 463 ms to 70 ms
  • Late blocks (p95 arrival after 4 s) 5.8x fewer: 1.97% of slots to 0.34%
  • 71% of slots were accelerated by mump2p, measured at 16 mump2p gateways against 24 to 31 public Xatu sentries per week

image
image904×448 65.9 KB

Attestation outcomes (17 September to 15 October)

  • Wrong head votes down 45% against the control week: 0.847% to 0.469% of attested head votes. Every treatment week came in below the control: -79%, -62%, -12%, -26%.
  • Relative to the network: Hoodi’s own wrong head rate fell from 2.18% in June to between 0.54% and 1.98% across the four treatment weeks, so part of the drop reflects the network itself. Netting that out, Lido sat at 0.39x the network rate in June and 0.40x across the window (0.34x, 0.44x, 0.52x, 0.32x by week) - consistently around 60% below the network.
  • Wrong head votes on canonical slots, the category mump2p targets most directly, fell 60% on a weekly average against the control (3,123 to 1,264), and between 35% and 82% in any given week.
  • Missed block proposals fell from 14.5% (46 of 317) in the control week to 2.0% (36 of 1,804) across the four weeks. Proposal outcomes on Hoodi are heavily shaped by network conditions, so this is shown for context rather than as a mump2p effect.

image
image908×165 71.1 KB

image
image913×589 82 KB

Reading the results

  • Hoodi’s network conditions swung widely over the window, with the network-wide wrong head rate ranging from 0.54% to 1.98% week to week. That is why the fairer read is Lido relative to the network. On that read, Lido held its position at around 0.4x rather than pulling further ahead.
  • Gains narrowed after week 2. Lido’s wrong head rate was 0.18% and 0.32% in weeks 1 and 2, then 0.74% and 0.63% in weeks 3 and 4, tracking the network’s own deterioration in those weeks. Missed proposals edged up from 1.3% to 2.9%, still well below control. Single weeks on Hoodi should be read with caution for this reason.
  • Late inclusions behind non-canonical slots, which mump2p does not address, ran 14% to 32% above control.
  • Taken together, the Hoodi phase shows the integration works and carries no operational risk, with a directional signal that block propagation and head-vote outcomes improve. The clearer performance read comes from mainnet, where network conditions are stable enough to measure it.
  • Hoodi results should not be read as a forecast of mainnet performance. The testnet is small, conditions are noisier, and the absolute figures are not comparable.
  • On stability: the gateway ran alongside existing setups for the full window with no changes to validator software, keys or consensus logic, and no slashing events.

image
image941×275 43.8 KB

What’s next

  • The Lido team is reviewing the report. Any next steps for Lido delegated stake will be coordinated with Lido once that review is complete.
  • Participating operators are welcome to keep their gateways running in the meantime - nothing changes on your side.
  • Thank you to everyone who connected keys and kept us posted on changes to your setups.
2 Likes