Table of Contents
- Key Takeaways
- 1. The Deepest Layer of Ethereum: The Networking Layer
- 2. Optimum's Technical Approach
- 2.1 RLNC
- 2.2 The Architecture and Parameters of mump2p
- 2.3 Security Model
- 2.4 Integration with Ethereum: The Sidecar Architecture
- 3. Impact on Validator Revenue
- 3.1 Slot Timing Games and the Expansion of Available Time
- 3.2 Rising MEV Bid Values
- 3.3 Improvement in Head Vote Accuracy
- 3.4 Reduction in Bandwidth Costs
- 4. Implications and Open Questions
- 4.1 Implications for Ethereum's Roadmap
- 4.2 Open Questions
- 4.3 Expansion to Multichain
- 5. Closing Thoughts
Researcher
Related Projects
Key Takeaways
- Discussions around Ethereum's scalability have largely centered on two domains: the execution layer and the consensus layer. The networking layer, or the gossip protocol that determines how data propagates between validators, has received relatively little attention, and Optimum is a project that targets exactly this area.
- Optimum's flagship product, mump2p, is a data propagation protocol built on RLNC (Random Linear Network Coding), a protocol co-invented by Optimum's CEO and MIT professor Muriel Médard. It is designed to replace GossipSub, Ethereum's existing gossip protocol. Early test results shows that Optimum records an average block propagation speed 2.42x faster than the GossipSub baseline (2.50x faster on a median basis). while propagation variance ran approximately 7.88x lower than libp2p (2.81x lower on a std-dev basis), meaning both faster and far more consistent delivery.
- From a validator's perspective, an additional 50 to 150ms of slot time raises the average MEV bid value by 13 to 16 percent and can lift the network-wide head vote accuracy from 98.6 percent to between 98.8 and 99.1 percent. According to Optimum's analysis, major validator operators accounting for 36 percent of Ethereum's total stake could see their staking rewards rise by roughly 0.66 to 1.97 percent, about 6 to 19 extra ETH per year on a 32,000 ETH stake.
- Optimum runs in parallel with existing consensus clients as a sidecar without requiring any consensus changes, which keeps adoption friction low. The more fundamental implication, however, lies in what this means for Ethereum's future roadmap. Scaling scenarios such as shorter slot times, larger blobs, and accommodating a greater number of validators all presuppose the throughput limits of the networking layer.
1. The Deepest Layer of Ethereum: The Networking Layer
When discussing Ethereum's scalability, most conversations revolve around the execution and consensus layers. Beneath these two layers, however, lies an even more fundamental domain: the networking layer, where validators deliver blocks and attestations to one another. In Ethereum's case, peer-to-peer (P2P) communication relies on libp2p and a gossip protocol built on top of it called GossipSub.
The issue is that GossipSub is fundamentally a protocol built on redundant transmission. The way a gossip protocol works can be roughly described as follows. When a node receives a new message, it forwards that message identically to all of its directly connected neighbors. If a node is connected to six neighbors, the same message is replicated six times and flows through the network.
This redundant transmission scheme may seem wasteful at first glance, but it is a reasonable choice in a blockchain network environment where no central party exists and where it is impossible to verify in advance which nodes are online at any given moment. Ensuring that messages still reach their destinations even when some nodes temporarily miss them is the most important goal, and this is precisely why Ethereum has adopted a gossip protocol with censorship resistance and network stability as its P2P standard.
That robustness, however, comes at a cost. The inefficiency of the same data being transmitted repeatedly across the network becomes more visible as the volume of data and the number of nodes grow. This inefficiency can be observed in Ethereum's current block propagation metrics. GossipSub-based block propagation in Ethereum takes about one second on average. Considering that Ethereum's slot time is 12 seconds and the attestation deadline is four seconds after the start of the slot, taking one second for block propagation is no small burden on validators. The time that passes before a validator receives a message directly cuts into the room they have to decide when to propose a block or to observe higher-value bids.
Optimum aims at precisely this point. Optimum's mump2p is a next-generation gossip protocol that steps into the place of GossipSub. On the Ethereum Hoodi testnet, it recorded an average block propagation time of about 150ms, demonstrating performance more than six times faster than GossipSub. Even so, mump2p does not change the consensus algorithm, does not require replacing node clients, and does not demand any additional hardware. It simply runs as a sidecar alongside the existing validator infrastructure while maximizing validator efficiency.
This article examines the technical approach Optimum takes to address the limitations of Ethereum's networking layer, the tangible impact this shift has on validator economics, and how it connects to Ethereum's future roadmap.
2. Optimum's Technical Approach
2.1 RLNC
Optimum seeks to resolve the inefficiencies of existing gossip protocols through its own protocol called RLNC (Random Linear Network Coding). To explain RLNC in simple terms, it is like dividing a message into small pieces and then randomly mixing those pieces to create new units of data. Each node, upon receiving this mixed data, can either forward it as is to another node or, once enough pieces are gathered, reconstruct the original message.
Existing gossip protocols operate as follows. If a node receives 1MB of block data, it transmits that entire 1MB to all of the other nodes it is connected with. If it has six neighboring nodes, 6MB flows out into the network, of which 5MB is essentially redundant. In addition, the receiving side must wait until the message arrives in full before it can re-propagate the message to the next node.

Source: Optimum
RLNC redesigns this structure by splitting the message. The sending node divides the 1MB message into k equally sized fragments and then produces n coded shards through random linear combinations of those fragments. In plain terms, each fragment is multiplied by a different random weight, and the results are added together to create a single shard. By simply varying the weights applied to the same fragments, it is possible to generate a virtually unlimited number of distinct shards.
In RLNC, a receiving node can reconstruct the original message by collecting just k mutually independent shards out of those generated. Because a missing shard can be replaced by other shards, the system gains robustness against packet loss.

Source: Optimum
So far, this resembles the erasure coding techniques commonly seen in data availability protocols, but RLNC differentiates itself through recoding and composability.
In the case of GossipSub, for node A to receive a message from node B and pass it to node C, the message must arrive in full first. In RLNC, however, an intermediate node does not need to know what the shards it received actually represent. It can simply generate a new random linear combination of those shards and forward it to the next node. This means that node A can immediately create a new shard and send it to node C even while it has only received some of the shards. As a result, the entire network functions like a pipeline, with the data flow continuing without interruption.
2.2 The Architecture and Parameters of mump2p
mump2p is a protocol that applies RLNC to Ethereum's P2P environment.
A mump2p node is structured by layering RLNC logic on top of a standard libp2p host. Each node leverages the peer discovery, secure communication, and network transport functions provided by libp2p as is, while maintaining a mesh structure similar to GossipSub. The difference is that the RLNC logic activates as messages flow across the mesh.
The operation of mump2p is divided into two stages: message publish and receive.
- Publish: A node divides the message into a predetermined number of fragments and then generates more coded shards than the number of fragments, distributing them to mesh peers in a round-robin manner. Since each peer receives a different set of shards, the same message is never redundantly transmitted.
- Receive: A node checks whether received shards contain new information and discards duplicate shards. Once enough independent shards have been collected, the node attempts to decode the original message. If a node holds shards above a certain threshold, it also generates new recoded shards and forwards them to other peers.
Several parameters come into play in the operations above, and the breadth of tuning available is one of the more interesting features of mump2p. For example, dividing a message more finely increases resilience to packet loss but adds computational overhead, while increasing the number of mesh peers improves message delivery speed and stability at the cost of higher bandwidth usage. In other words, rather than forcing a single fixed configuration, Optimum offers the flexibility to adjust trade-offs based on network conditions and validator priorities.
2.3 Security Model
The most notable threat in an RLNC-based system is the pollution attack. If a malicious node injects invalid shards into the network, other nodes that attempt to decode messages based on those shards may fail to reconstruct them. In a worse scenario, an invalid shard may be recoded together with valid shards, propagating corrupted data throughout the entire network.
mump2p defends against this with a multi-layered approach called source authentication. The original message data is hashed to create a unique identifier, and this identifier along with the publisher's signature is bound to the message. After a node decodes a message from the shards, it verifies the reconstructed data against the publisher's original signature and hash.
If this verification fails, the node knows that at least one of the shards it received was polluted. Identifying exactly which shard was malicious may be complex, but the system can trace which peers sent invalid shards, lower their reputation scores, and gradually isolate them from the network. In short, even when recoding occurs at intermediate nodes, data integrity is verified end-to-end.
In addition, because mump2p is built on top of libp2p, it directly inherits the standard security features that libp2p provides. Communication between nodes is encrypted using Noise or TLS, and defense mechanisms against attempts by malicious nodes to take over the entire network or isolate specific peers (such as Sybil attacks or eclipse attacks) are automatically applied. In other words, mump2p has not redesigned its security infrastructure from scratch but can be understood as adding a layer of defense against RLNC-specific threats on top of a proven P2P security base.
2.4 Integration with Ethereum: The Sidecar Architecture
No matter how excellent the technology is, actual adoption is difficult if the friction of deployment is high. Ethereum validators tend to be conservative in operating their infrastructure reliably and are extremely cautious about replacing consensus clients or modifying validator key configurations. Optimum has taken this reality into account and has implemented its service so that it can be adopted with minimal changes.
mump2p is deployed as a sidecar known as the Optimum Gateway. This gateway runs as a separate process from the consensus clients that validators already operate, such as Lighthouse, Prysm, and Teku, communicating with them through simple API calls.
The sidecar operates as follows.
- It reads block data from the validator's Ethereum client.
- It encodes the data with RLNC and transmits it over the Optimum network.
- It decodes RLNC shards received from the Optimum network and delivers them to the validator's client.
The most important design point is that mump2p operates in parallel with GossipSub. Validators run GossipSub and mump2p simultaneously, and attestation is possible whether the block arrives faster through mump2p or through GossipSub. Even if the sidecar goes down, the validator's ability to attest and propose blocks is not affected. This additive integration minimizes the additional risk borne by operators.
Optimum does not access validator keys and plays no role in leader election or signing. The consensus mechanism itself remains unchanged. Only the way data moves between nodes changes. This non-intrusive design is the reason Optimum has been able to integrate with major validators within a short period of time.
Through this architecture, Optimum has been able to recruit key players in the Ethereum validator market for the early phase of its testnet, including Kiln, P2P.org, Everstake, Blockdaemon, Infstones, Luganodes, and Ebunker. According to Optimum, more than 40 testnet partners are currently connected on Hoodi, together representing roughly $30B worth of ETH stake. With mainnet integration now underway, updated mainnet participation figures are expected to follow.

That said, the Optimum network is not composed of validators alone. For validators to enjoy fast RLNC-based propagation, accelerator nodes that relay and recode the coded shards are required. Optimum refers to the nodes that serve this accelerator role as Flexnodes. Over the longer term, Optimum envisions a permissionless model in which anyone can participate as a Flexnode operator by providing their bandwidth. In other words, the Optimum network has a dual structure consisting of validators (the demand side of the acceleration service) and Flexnodes (the supply side).

Source: Optimum
Initial measurements clearly demonstrate the effectiveness of the sidecar architecture. Early test results show that, mump2p delivers an average propagation speed 2.42x faster than libp2p (2.50x on a median basis), and just as important for validator predictability, propagation variance runs about 7.88x lower than libp2p (2.81x lower on a std-dev basis). In absolute terms, median (p50) latency drops from 132ms on GossipSub to 53ms on mump2p, and the tail improves just as sharply: p95 falls from 425ms to 170ms, with the standard deviation narrowing from 124ms to 46ms. This combination of speed and consistency is what directly benefits validators' attestation timing and reward predictability.
What is striking is that these figures are not the result of a one-off measurement in a controlled environment. Optimum deployed 30 gateways distributed around the world and designed the experimental setup so that every block was propagated simultaneously through both mump2p and GossipSub paths. By measuring the performance of the two protocols side by side on identical traffic, Optimum has fundamentally precluded criticism that the results could be due to cherry-picking or measurement in incomparable environments.
For reference, the one-second block propagation time used as the comparison baseline for GossipSub was the fastest value measured by ethPandaOps' xatu-mimicry infrastructure, which Optimum adopted as a conservative benchmark. This implies that the six-fold gap may widen further under actual average conditions.
3. Impact on Validator Revenue
Reducing block propagation time from one second to 150ms is technically impressive, but analyzing how this actually affects validator revenue is essential. According to research published in March 2026 by the Optimum team and Professor Medard, validator revenue generated through Optimum arises along three paths.
3.1 Slot Timing Games and the Expansion of Available Time
When Ethereum validators propose a block, they face an implicit trade-off. The earlier the block is proposed, the higher the likelihood that it propagates sufficiently across the network to receive attestations from other validators. The later it is proposed, the more builder bids they can observe and the greater the chance of selecting a higher-value block.
This trade-off is an inherent optimization problem that validators must solve given Ethereum's slot structure. Validators typically calculate their safety margin based on the time it takes for a block to reach 80 percent of nodes (p80 propagation delay) and wait until enough nodes can see and attest to the block within the four-second attestation deadline before proposing it.
Optimum converts the effect of mump2p into additional available slot time. In other words, the difference in p80 delay between GossipSub and mump2p is the amount of extra time by which a validator can delay its proposal while still maintaining the same safety margin. Expressed as a formula, it looks like this.

Here, Q(p) represents the time it takes for a block to reach p percent of nodes, so Q(80%) has the same meaning as the previously mentioned p80 propagation delay. Δmump2p refers to the difference in p80 delay between GossipSub and mump2p, which represents the additional slot time that a validator can secure without sacrificing safety.

Source: Optimum
According to Optimum's analysis, validator rewards consist of consensus layer rewards and execution layer rewards, and many of these reward components are directly affected by network latency. Securing additional available slot time therefore means gaining room to improve these latency-sensitive reward components. The measurements indicate that 50 to 150ms of additional slot time translates into an APR increase of roughly 0.66 to 1.97 percent for the largest validator operators. While these figures may seem small, they are far from negligible when applied to the $100B ETH staking market as a whole.
That said, the magnitude of this increase varies across operators. According to Optimum's analysis, operators that maintain conservative safety margins and use slot time earlier benefit more from the additional slot time, while operators that already aggressively exploit timing games and maximize their use of slot time see relatively limited marginal effects. In short, the impact of adopting mump2p plays out differently depending on each operator's current operational policy.
3.2 Rising MEV Bid Values
The most direct path by which additional slot time translates into revenue is MEV bid selection. Most Ethereum validators today rely on a PBS (Proposer-Builder Separation) structure in which they propose blocks built by external builders rather than constructing blocks themselves. About 91.6 percent of validators connect with external builders through MEV-Boost, the standard implementation of this structure, and builders submit bids to validators in exchange for having their blocks selected. The later a validator proposes, the more time builders have to bundle additional transactions and construct more refined transaction ordering, which leads to higher bids.

Source: Optimum
Optimum analyzed bid tracking data from major MEV relays over the course of one week in March 2026. The results showed that 50 to 150ms of additional slot time translated, on average, into a 13 to 16 percent relative increase in bid value, with 20 to 30 percent of cases showing increases of more than 30 percent. Cumulative additional revenue over the week amounted to between 150 and 190 ETH.
One case illustrates this effect plainly. According to Optimum's analysis, there were slots in which a bid higher than the one selected by the validator arrived just 60ms later and was missed. Sixty milliseconds falls exactly within the range of additional slot time provided by mump2p, which clearly shows that there is real revenue currently being missed by validators due to the limitations of the networking layer.
As mentioned earlier, this effect can be achieved simply by deploying the sidecar without taking on any additional risk. Validators keep their existing safety margins intact and merely gain the room to observe bids for longer.
3.3 Improvement in Head Vote Accuracy
Validators act not only as block proposers but also as attesters. A validator's attestation consists of several components, among which the head vote, a vote on what the current head of the chain is, is the most time-sensitive. To produce an accurate head vote, the validator must receive the current head block in time. If propagation is delayed, the validator may vote on the wrong head or vote so late that the vote cannot be included in the next slot's attestation.
The head vote reward can be approximated as follows.

Here, a_val refers to the head vote accuracy of an individual validator, and a_net refers to the head vote accuracy of the network as a whole. The reward is therefore affected by both individual performance and network-wide conditions.

Source: Optimum
According to Optimum's analysis, as of March 2026, Ethereum's network-wide head vote accuracy stood at about 98.6 percent. A 50 to 150ms reduction in network latency could lift this figure to between 98.8 and 99.1 percent, which translates to roughly 1,000 to 2,000 ETH of additional annual revenue across the network.
About 0.6 percent of slots in Ethereum are missed, and in those slots head vote accuracy becomes zero regardless of any validator or network performance improvements. The theoretical maximum head vote accuracy is therefore around 99.4 percent. This means that more than half of the 0.8 percentage point gap between the current 98.6 percent and the theoretical limit of 99.4 percent could be closed through improvements at the networking layer alone.
3.4 Reduction in Bandwidth Costs
Beyond the revenue side, mump2p also reduces validators' operational costs. Unlike GossipSub, where the same message is transmitted multiple times in duplicate, RLNC distributes coded shards in a non-redundant manner.
For large node operators running hundreds or thousands of validators, bandwidth costs are an operational expense that cannot be ignored. Savings on the order translate directly into margin improvements on cloud infrastructure costs, which carries particular significance for institutional stakers running large numbers of nodes in adjacent data centers.
4. Implications and Open Questions
4.1 Implications for Ethereum's Roadmap
The most interesting implication of Optimum lies not in the improvement of validator APR itself, but in how this connects with Ethereum's future roadmap.
- The possibility of shorter slot times: Ethereum's 12-second slot time partly reflects the current limitations of the networking layer. Block propagation takes nearly a second, and attestations and their aggregation also require time. If propagation can be reduced to 150ms, discussions around reducing slot time may enter a new phase.
- Larger blobs and PeerDAS: A core goal of the EIP-4844 and Danksharding roadmap is to process more blob data while still allowing validators to verify it safely. Data availability sampling techniques such as PeerDAS allow validators to confirm availability without downloading the entire dataset, but they presuppose efficient data propagation as their foundation. Coded propagation schemes like RLNC have a structure that can be flexibly combined with data availability sampling.
- Validator decentralization: The Ethereum Foundation has been making various efforts to lower the barriers to entry for validators. However, in the current GossipSub-based environment, a validator's performance depends heavily on where it sits: operators in well-connected hubs receive blocks early and consistently, while nodes in geographically remote locations live in the tail of the propagation distribution. This is precisely where mump2p's gains are largest. Because coded propagation compresses that tail, poorly-located nodes benefit more than the average node suggests: in early testing, p95 propagation latency fell from 425ms to 170ms and the standard deviation narrowed from 124ms to 46ms, and on Hoodi even cross-continental propagation peaked at just 200 to 250ms against a roughly one-second GossipSub baseline. The decentralization stakes are real. Research attributes today's validator concentration around the Atlantic corridor to exposure to propagation variance, with Ethereum's liveness coefficient trending toward a level where a single regional outage could halt the chain. By making delivery consistent regardless of location, mump2p removes much of the economic incentive to co-locate, allowing operators outside the corridor, including solo stakers on ordinary connections, to deliver performance comparable to institutional operators.
4.2 Open Questions
The technology and measurement results presented by Optimum are impressive, but there are also questions that must clearly be resolved before mainnet deployment.
- The incentive structure of the Flexnode network: Optimum is not a system composed solely of validators. Flexnodes form a global data acceleration network in which anyone can provide bandwidth and help propagate data across the network. However, the specifics of how Flexnode operators are rewarded and how those rewards are funded have not yet been disclosed in detail. Optimum refers to this exchange of payments and services as its Latency Marketplace. It is expected that validators will pay for the acceleration service through this Latency Marketplace and that those payments will be distributed to Flexnode operators, but details such as the pricing mechanism, settlement cycle, and the role of any token remain undisclosed.
- Actual validator adoption: Although mump2p is an additive system, its effect depends on the validator adoption rate. If only a small subset of validators runs mump2p, the blocks they receive will still propagate through GossipSub, and the blocks they propose will reach GossipSub validators through GossipSub. For the network effects of mump2p to materialize, a certain threshold of adoption is required.
- The absence of a penalty mechanism: As mentioned in Section 2.3, Optimum employs an approach in which nodes that send polluted shards have their reputation scores lowered and are isolated from the network, but no explicit financial penalty such as slashing has been identified. Whether this is sufficient to deter malicious behavior on mainnet appears to be an area that will require further verification.
4.3 Expansion to Multichain
Optimum's vision does not stop at the single network of Ethereum. From the outset, Optimum has implemented mump2p in a chain-agnostic design, and its official documentation explicitly notes the possibility of extending to Solana's Turbine and to interchain packet routing in Cosmos/IBC. Solana, in particular, has a slot time of only about 400ms, meaning that even propagation delays on the order of 100ms can have a critical impact. The value of RLNC-based acceleration may therefore be even greater on Solana than on Ethereum. In December 2025, Optimum made this direction clear by publishing a separate blog post analyzing Solana's data propagation stack (Turbine, ShredStream, JetStreamer). Using its early testnet results on Ethereum as a stepping stone, Optimum has thus opened the door to expansion into any high-performance chain where data propagation is the performance bottleneck.
5. Closing Thoughts
What makes Optimum's approach interesting is not that it introduces a new hypothesis but that it brings information-theoretic results already proven in academia over the past several decades into a blockchain context. RLNC is a framework that Professor Muriel Médard has been developing since the early 2000s, and its mathematical foundation is solid. What Optimum has done is engineer this technology into a form suitable for libp2p and Ethereum validator infrastructure, and design a sidecar architecture that minimizes the friction of mainnet deployment.
If Ethereum's networking layer evolves toward mump2p, it is closer to opening a path toward shorter slots, larger blobs, and more decentralized validators. What Optimum is trying to solve, then, is not the surface-level problem of validator yield but the deepest point of the scalability limits Ethereum will face over the next decade or so.
The importance of this becomes clearer in light of the use cases now moving onchain. Stablecoins are maturing into a mainstream settlement rail, real-world asset tokenization is bringing larger and more frequent flows of value onto the chain, and an emerging agentic economy points toward a future in which autonomous agents transact continuously at machine speed. Each of these trends places heavier demands on throughput and latency, and none of them scales comfortably on a networking layer that spends close to a full second propagating every block. Seen this way, upgrading how data moves between nodes is not a peripheral optimization but a precondition for the next wave of onchain applications.
Optimum is currently operating a waitlist for Ethereum validators and is preparing for mainnet integration. If the results from the Hoodi testnet are reproduced on mainnet and validator adoption crosses a critical mass, we may soon witness a paradigm shift in Ethereum's networking layer. The change may not be as visible as a consensus algorithm or EVM upgrade, but its impact will be no less broad than that of any higher-layer change.
The report is based on the independent research of the author sponsored/funded by Optimum. The author of this report may have personal holdings or financial interests in assets or tokens discussed herein. However, the author affirms that no transactions have conducted using material non-public information obtained in the course of research or drafting. This report is intended solely for general information purposes and does not constitute legal, business, investment, or tax advice. It should not be used as a basis for making any investment decisions or as guidance for accounting, legal, or tax matters. Any references to specific assets or securities are made for informational purposes only and should not be construed as an offer, solicitation, or recommendation to invest. The opinions expressed herein are those of the author and may not reflect the views of any affiliated institutions, organizations, or individuals. The opinions and analyses expressed herein are subject to change without prior notice. In addition, beyond the individual disclosures included in each report, Four Pillars, may hold existing or prospective investments in some of the assets or protocols discussed herein. Furthermore, FP Validated, a division of Four Pillars, may already be operating as a node in certain networks or protocols discussed herein or may do so in the future. Please see below links in the footer for FP Validated's participating network disclosures and for broader disclosure details.



