Latest Hoodi Testnet Results

Now mumP2P protocol has graduated from our Devnet to Ethereum Hoodi Testnet, giving us a much more realistic environment to collect data in. Our initial numbers on Hoodi are as follows:

150 ms average block propagation time

Averaging 6.5x lower latency than Gossipsub’s 1000 ms

Simply put, this blows our June demo numbers out of the water. Even the fastest propagation times with Gossipsub are still above 1 second, making Optimum’s fast propagation layer a monumental opportunity for Ethereum scaling. 150ms propagation creates a clear path to reducing block times and finality, which will directly raise the standards for app performance and user experience. In this report, we’ll outline our methodology, sources for baseline Gossipsub metrics used in comparison, and what this data means for the future of Ethereum’s consensus layer.

Implementation and Methodology

Our Hoodi setup consists of 30 mumP2P-powered nodes globally distributed to mimic the geographic diversity of the entire Ethereum node set. Node operators run gateways as peers and connect their beacon nodes to them. Once a block arrives at one of these gateways, it enters the Optimum Network, which uses the mumP2P protocol to propagate the block across all mumP2P-enabled nodes, as well as to the rest of the Hoodi consensus layer network that is still using libp2p/gossipsub. Our latency measurements show the time it takes for a block to reach all other mumP2P-enabled nodes.

On the latency graph we see average propagation time around 140-150ms, with lows frequently dipping into the 120ms range and the occasional high up around 200ms. Overall, Optimum’s network maintains excellent consistency with the majority of blocks reaching all 30 mumP2P enabled peers between 130-170ms.

Speed Increase

For our comparison to standard Ethereum data propagation (Gossipsub) we used data from ethPandaOps, taking the lowest reported latency to create a fair and slightly conservative estimate of the speed increase. The low-end latency for Gossipsub clocks in around 1 second on a comparable set of nodes, making mump2p’s 150ms propagation a staggering 6.5 times faster!

While 6.5x lower latency is typical, mump2p frequently propagates blocks 7 or 8 times faster. Keep in mind that this comparison uses the fastest Gossipsub numbers, so in actuality the speedup could be even more dramatic at times when network traffic is high and Gossipsub tends to struggle. One of the Optimum Network's standout features is its ability to maintain low latency during periods of network congestion, which we observed in our previous Devnet testing with both larger and more frequent messages.

Why Speed Matters

The road to a buttery smooth blockchain user experience is paved with latency reductions and bandwidth increases. 6x faster block propagation is the infrastructure upgrade Ethereum needs to unlock its scaling potential. When the network can propagate blocks at 150ms, slot times can be reduced significantly, which will be felt by end users as faster transaction confirmations and finality. Increased throughput also targets another major pain point for users, L1 congestion fees. Optimum doesn’t just deliver low latency, it maintains it under heavy traffic. Just this month we saw another instance of gas fees spiking above $20, an occurrence which we aim to make a relic of the past. Since Optimum enables validators to propagate much more efficiently, it opens up their bandwidth to handle higher gas limit blocks which will mitigate fee spikes during high traffic periods.

6x faster propagation also makes validators more profitable, reducing missed or late attestations, as well as resource utilization. We’re looking into methods of extrapolating APY gains from this testnet data to give an idea of the economic impact Optimum will have for validators and ETH stakers. To put some perspective on potential economic effects, ETH staking is a $150 billion industry, with our current set of testnet partners already accounting for over $30 billion in staked ETH. With such a large addressable market, the APY boost that Optimum will provide could mean an additional 9-10 figures in network-wide validator profitability at full adoption. We plan on releasing data-backed APY impact estimates in the near future.

In Summary

Optimum network’s 150ms latency represents a 6x increase in Ethereum propagation speed. Speedup of this magnitude makes validators more profitable, Ethereum more user friendly, and raises the ceiling for what can be built atop the chain. Important note: This is only the first round of testnet improvements, we will continue to iterate and improve propagation speeds. More data and more testnet partners are frequently rolling in, keep an eye on our X account for the latest announcements as we work on scaling Ethereum and many more chains to come.

Abstract

In decentralized blockchain implementations, three properties are highly desirable: decentralization, security, and scalability. There is a widely held belief in the blockchain community—often referred to as the Blockchain Trilemma—that it is impossible to fully achieve all three simultaneously. As a result, much effort by protocol designers has focused on ensuring decentralization and security, while scalability has typically been left to be handled on a best-effort basis, with performance largely dependent on the processing and communication capacities of operators and participants. By leveraging the properties of Random Network Linear Coding (RLNC), we aim to enhance the scalability of any blockchain protocol while simultaneously improving decentralization and security, directly addressing the constraints imposed by current implementations.

The Trilemma Landscape: Navigating Competing Priorities

Blockchains emerged as one of the most popular distributed data structures after the introduction of Bitcoin in 2008 [18]. As per [2, 22], a blockchain can be considered an append-only data structure that stores a totally-ordered sequence of transactions. While relatively simple to implement on a single computing device, it becomes challenging to implement a blockchain in a decentralized manner using multiple, distinct, failure-prone (from crash to Byzantine failures) devices that communicate via messages.

Ethereum’s co-founder Vitalik Buterin [3] identified three properties as essential for the performance of distributed blockchain implementations: decentralization, referring to the large number of autonomous network devices that collectively implement and ensure the fault tolerance of the blockchain; security that refers to the implementation’s tolerance to malicious acts; and scalability that refers to the “speed” of the protocol in completing transactions. In the same article, Buterin introduced the term “Blockchain Trilemma”, raising concerns about the coexistence of these three properties. Buterin’s conjecture suggests that higher decentralization favors higher security, but negatively impacts scalability. Similarly, achieving higher scalability performance, requires either sacrificing decentralization for smaller networks or sacrificing security by bounding communication.

Following Buterin’s article [3], the blockchain community started seeking solutions to overcome the statement of the Trilemma and ensure the maximum performance for their proposed blockchain implementation. Let’s examine each property separately.

Decentralization. One of the core tenets used in blockchain implementations is decentralization, the distribution of control across a network of nodes rather than relying on a central authority. Decentralization offers multitudes of benefits: (i) tolerance of node failures, (ii) robustness against attacks as there are no sensitive central points, and (iii) resistance against node collusion when the majority of nodes are benign. In his article, Buterin [3], identified blockchains as architecturally and politically decentralized, yet logically centralized: they are built on top of multiple nodes (architectural decentralization), those nodes are controlled by multiple users (political decentralization), but the whole system needs to behave like a single device (logical centralization).

Protocols like Algorand [10] and Ethereum [7] aim to mitigate the challenges of decentralization, thereby avoiding the Trilemma and ensuring both security and scalability. Algorand [10] employs a protocol to reduce the number of nodes that participate in the consensus protocol. In contrast, sharding solutions, such as Danksharding [7], propose dividing the validators into smaller groups, each responsible to validate and agree on a different set of transactions.

Security. An adversary aims to violate the correctness of the system by either attempting to deviate the system from its sequential specification (and expected outcomes), or by preventing operations from terminating (i.e., denial of service). Buterin [3] identifies three potential security threats against blockchains:(i) Failures: when the adversary forces a set of nodes to stop operating, (ii) Attacks: malicious actions against a set of nodes to force them to diverge from the protocol, and (iii) Collusion: when nodes coordinate to “defeat” the protocol.

Protocols were also designed to deal with security concerns, and address the Trilemma conjecture. Such solutions can be found in optimistic rollups [13] and private pools [14]. Optimistic rollups were introduced to address security constraints while improving scalability performance. They propose collecting and validating transactions off-chain, and the submission of a collective outcome to the main chain. They follow all the security rules of the main chain and ensure that collected transactions are secure. Private pools, on the other hand, ensure security by assigning validation to a verified, whitelisted group of validators.

Scalability. Decentralization and security are crucial for the reliability of the blockchain, but scalability is an essential metric for its performance. Scalability captures the system’s capacity to handle increasing operational demands without compromising speed or cost-efficiency. A scalable blockchain should process a high throughput of transactions (measured in transactions per second) while keeping fees low and confirmation times fast, ideally without requiring excessive computational resources or centralization trade-offs. Since a blockchain is built on top of message-exchanging nodes, transaction latency is heavily dependent on the delay in delivering the messages required to complete a single transaction, which directly influences transaction throughput.

Contrary to decentralization and security, developers and providers of blockchains have not designed or considered protocol solutions to directly tackle transaction latency and enhance scalability at the network level. Instead, they rely on probabilistic and best effort scalability, which is driven by incentives provided to network maintainers and participants to boost their computation and/or network capabilities. Traditional blockchains like Bitcoin and Ethereum [1, 9], solely rely on the network’s capabilities, providing network-dependent scalability.

To improve upon simple network performance, some Ethereum Layer 2 solutions, like rollups [13], propose the utilization of computationally intensive nodes for merging together multiple transactions into a single transaction before committing the merged transaction onto the main chain. Those nodes are incentivized through rewards, based on the efficiency of their transaction merging process. Solana [23], on the other hand, incentivizes validator participation: a node may participate as a validator and receive rewards only if it offers high computational and network capabilities. In that sense, Solana relies on costly high-performance machines to deliver scalability. However, such solutions are still susceptible to network delays.

What are the limitations of best-effort scalability? Can we guarantee the completion of every transaction? Are those transactions completing quickly enough?

Scalability with Provable Guarantees

Ideally, we need solutions that offer provable guarantees on scalability performance. To achieve this, we first need to understand the key components and latency bottlenecks of blockchain transactions. The most important mechanism of every blockchain is to allow system maintainers to agree on a single sequence of transactions. This ensures that the system eventually reaches a stable and consistent state. Consequently, a State Machine Replication (SMR) [15] service is the backbone of all major blockchain implementations. Each node in the system executes the same operations in the same order, ultimately leading all nodes to the same state, which reflects the overall state of the system.

Significance of Consensus. To facilitate agreement on operations and their order, blockchain implementations address SMR by solving the consensus problem [16, 20]. Consensus is a well-known problem in distributed systems, where every node proposes a value, and all nodes must agree on one of the proposed values. The correctness of a consensus algorithm is governed by three requirements: (i) agreement: every node must decide on the same value. (ii) validity: the decided value must have been proposed by a node. (iii) termination: eventually, every node must decide a value. Agreement and validity define the safety, and termination the liveness properties of consensus. In the context of blockchains, nodes need to agree on the transaction blocks and the order in which they will be appended to the chain.

Unsolvability of Consensus. Fischer, Lynch, and Paterson (FLP) in [8] showed that fault-tolerant agreement is impossible to guarantee with certainty in an asynchronous system with the crash failure of a single node.

Solvability of Consensus. Following the FLP result, researchers focused on exploring how synchronicity may affect the solvability of consensus. Soon it was shown that consensus can be solved in synchronous fault-prone systems where nodes compute in sync, messages are delivered within known timing bounds, and execution proceeds in synchronous rounds. It was shown [17, 5] that f + 1 rounds, where f, the maximum number of nodes that may be byzantine or crash, are sufficient to solve consensus in the synchronous system. This triggered the question: How much synchrony is necessary to solve consensus?

Living in Partial Synchrony. Soon after [8], Dwork, Lynch, Stockmeyer [6], proposed an algorithm for solving consensus in a partial or eventual synchronous system, i.e. a system that experiences both periods of synchrony and some periods of asynchrony. As long as such a system eventually stabilizes and offers “long enough” windows of synchrony, we can solve consensus. It is noteworthy that the algorithm proposed by Dwork, Lynch, Stockmeyer [6], nearly three decades ago, serves as the fundamental algorithm employed in any Tendermint/CometBFT based SMR system [12]. Other prominent blockchains, such as Ethereum, Solana, BNB Chain, Cosmos-based chains, and others, also rely on partial synchrony to resolve leader-based consensus. Each leader needs to make decisions within a predefined time interval ∆,usually known as block time. Consequently, ∆ represents the synchrony window duration within which consensus must be solved. The value of ∆ is known to the nodes and is used to decide when it's time to move to the next consensus slot.

Timing Decisions. But what is the best ∆? Picking a large ∆ may delay the consensus decision, and in turn block finality and reduce transaction throughput and scalability. Very small values for ∆ may result in unproductive consensus attempts and thereby again decreasing throughput. Thus, there is a tradeoff involved in reducing the consensus slot Δ while potentially increasing the number of transactions finalized in a given time interval.

Consensus algorithms involve each node attempting to communicate its local value to the others, through a series of message exchanges. Similar to information propagation in social networks, gossip is used for propagating the proposed values among the nodes. Due to network disruptions, some messages may be lost, some may be delayed, some may be received at a node from multiple origins (i.e., duplicated), and some may be retransmitted. Such incidents may increase the time needed for information propagation and hence reaching consensus, inevitably resulting in large ∆ slots especially in larger networks. This motivates the decision in many blockchain solutions to limit decentralization for scalability.

The Promise of RLNC. In order to scale without compromising decentralization, it becomes necessary to devise low latency gossip (publish/subscribe) solutions to reduce the ∆ slot. Random Linear Network Codes (RLNC) [11], propose the division of message data into coded elements using algebraic equations over finite fields. To compensate for network losses and malicious (Byzantine) behavior, RLNC requires each node to collect only a subset of the generated coded elements (or equations) for recovering the original message. Furthermore, RLNC eliminates duplicates by enabling each intermediate node to randomly combine equations on the fly and generate novel, previously unseen coded elements. Consequently, each node discovers new information with every coded element received. These characteristics render RLNC resilient to decentralization, and (provably) achieve optimal throughput for message transfers [4].

As a result, RLNC enhances message delivery, reducing the consensus slot ∆ while making an increase to the number of transactions finalized within a given time interval possible. This implies scalability benefits without compromising either decentralization or security within the system.

We have proposed, implemented, and deployed a preliminary version of a new data propagation protocol called OptimumP2P, that extends the widely used Gossipsub protocol and incorporates RLNC at its core. We have compared OptimumP2P’s and Gossipsub’s performance in terms of latency and average delay. Our observations indicate that OptimumP2P offers substantial improvements. Analytical and experimental results (see plots and [19]) consistently demonstrate that gossiping with RLNC reduces both the average and the standard deviation of message propagation times across large networks. As the next step, we are planning to bring OptimumP2P to the service of current blockchain implementations, like Ethereum, by designing architectures to seamlessly integrate OptimumP2P with Ethereum validators allowing them to achieve higher throughput, lower latency and hence higher scalability.

Conclusions

With RLNC, a chain’s scalability becomes untethered from its decentralization and security, free from the binds of the classic trilemma.

OptimumP2P leverages RLNC, unlocking the trilemma by raising network performance and maintaining high performance as message sizes increase, while also keeping bandwidth requirements for network participants low. In practice this enables throughput scaling via larger blocks and shorter slot times, achieving the speed that users value so highly without the need to centralize the network.

References

[1] What is bitcoin fork? http://blog.cex.io/bitcoin-dictionary/what-is-bitcoin-fork-14622. Accessed: 2016-05-05.

[2] Anta, A. F., Konwar, K. M., Georgiou, C., and Nicolaou, N. C. Formalizing and implementing distributed ledger objects. SIGACT News 49, 2 (2018), 58–76.

[3] Buterin, V. The meaning of decentralization. Medium (Feb 2017). Accessed: May 2025.

[4] Deb, S., Medard, M., and Choute, C. Algebraic gossip: a network coding approach to optimal multiple rumor mongering. IEEE Transactions on Information Theory 52, 6 (2006), 2486–2507.

[5] Dolev, D., and Strong, H. R. Authenticated algorithms for byzantine agreement. SIAM Journal on Computing 12, 4 (1983), 656–666.

[6] Dwork, C., Lynch, N., and Stockmeyer, L. Consensus in the presence of partial synchrony. J. ACM 35, 2 (1988), 288–323.

[7] Feist, D. Danksharding. Ethereum Research (2022). Ethereum Research post introducing Dankshard-ing.

[8] Fischer, M. J., Lynch, N. A., and Paterson, M. S. Impossibility of distributed consensus with one faulty process. Journal of ACM 32, 2 (1985), 374–382.

[9] Foundation, E. Ethereum 2.0 networking specification. https://github.com/ethereum/consensus-specs, 2023. Accessed: 2023-10-10.

[10] Gilad, Y., Hemo, R., Micali, S., Vlachos, G., and Zeldovich, N. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles (New York, NY, USA, 2017), SOSP ’17, Association for Computing Machinery, p. 51–68.

[11] Ho, T., Medard, M., K¨otter, R., Karger, D. R., Effros, M., Shi, J., and Leong, B. A random linear network coding approach to multicast. IEEE Transactions on Information Theory 52, 10 (2006), 4413–4430.

[12] Jae Kwon. Tendermint: Consensus without mining. https://tendermint.com/static/docs/tendermint.pdf, n.d. Accessed: July 7, 2025.

[13] Kalodner, H., Goldfeder, S., Chen, X., Weinberg, S. M., and Felten, E. W. Arbitrum: Scalable, private smart contracts. Proceedings of the 27th USENIX Security Symposium (2018), 1353–1370. Introduces optimistic rollups via Arbitrum’s fraud-proof mechanism.

[14] Labs, U. Uniswap v4: The future of amms, 2023. Introduces customizable pools, including private variants.

[15] Lamport, L. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM 21, 7 (1978), 558–565.

[16] Lamport, L., Shostak, R., and Pease, M. The byzantine generals problem. ACM Transactions on Programming Languages and Systems (TOPLAS) 4, 3 (1982), 382–401.

[17] Lynch, N. A., and Fischer, M. J. Lower bounds on the time to assure interactive consistency. Information Processing Letters 16, 4 (May 1983), 187–189.

[18] Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system.

[19] Optimum. Comparing the performance of optimump2p and gossipsub, 2025.

[20] Pease, M., Shostak, R., and Lamport, L. Reaching agreement in the presence of faults. Journal of the ACM (JACM) 27, 2 (1980), 228–234.

[21] Raynal, M. Fault-tolerant message-passing distributed systems.

[22] Roughgarden, T. Foundations of blockchains lectures, 2022.

[23] Solana Labs. Solana: Fast, secure, decentralized blockchain. https://solana.com, n.d.

In our previous post

https://mirror.xyz/0xBfAC4db6d990A6cF9842f437345c447B18EbeF73/O9bMr1JIJ2tHqlZRagteksbxR13Wwced_IHfAQ_1mTE

—we walked through how validators can leverage OptimumP2P alongside their existing software and saw early test results showing 50%+ latency improvements. This post builds on that foundation and dives into the ways OptimumP2P improves blockchain performance so new use cases can thrive, exploring the impacts it can have for DeFi and DePIN in particular.

Classic L1s (general purpose smart contract platform)

Execution—i.e., the computation performed locally on each node—on major Layer-1s today is capable of keeping up with demand. Data propagation across the network is the current bottleneck. Fast, predictable block and blob propagation matters for validator economics, network resilience, and overall scalability. OptimumP2P alleviates this bottleneck by significantly reducing redundant network traffic and cutting end-to-end delays.

Wei Dai

@_weidai

Execution is not the bottleneck. Data propagation is.

Gossipsub is capping performance of many chains today (Ethereum included).

These graphs shows how much bandwidth and latency gossipsub is leaving on the table, relative to optimized propagation like OptimumP2P.

For testnet

Muriel Medard

@MurielMedard

4/ To illustrate the benefit of our OptimumP2P, I'll include below some of our Testnet data, which show the increasing gain with increasing message size of 4, 6 and 10 MB.

89

10:58 PM • May 7, 2025

Ethereum

Current Approach:

Ethereum relies on protocols like devp2p and libp2p (Gossipsub), for its networking stack. Every block and blob is redundantly relayed to every peer, which can waste bandwidth and introduce unpredictable latency—especially as blob sizes grow as they did post-Pectra upgrade.

https://ethereum.org/en/roadmap/pectra/#new-improvements

OptimumP2P Benefits:

• Reduced redundant traffic: Small, coded pieces avoid sending full blobs to every peer, freeing up capacity for larger blocks or more blobs per block.

• Low, Predictable Latency: OptimumP2P testnet has shown significantly less latency and improved consistency when sending different blob sizes at various publishing rates vs Gossipsub.

• Sub-Second State Sync: Consistent propagation times empower latency-sensitive apps (e.g., high-frequency trading, AIML) to run smoothly on Ethereum.

• Faster Finality: With blocks arriving reliably and quickly, the time to reach consensus shortens.

For testnet conditions with 36 nodes OptimumP2P is delivering 4, 6, and 10MB blocks per second all at ~1 sec delay. Gossipsub delivers 4MB blocks at 1.6 sec delay (60% latency increase), 6MB blocks at 2.6 sec delay (160% latency increase), and cannot consistently deliver 10MB blocks (2000+% latency increase).

Optimum

@get_optimum

𝐏𝐑𝐄𝐒𝐄𝐍𝐓𝐈𝐍𝐆: The first look at OptimumP2P in action

Test runs vs. Gossipsub show over 50% lower latency when delivering an average block sized message!

306

2:08 PM • May 28, 2025

Solana

Current Approach:

Turbine: Block Propagation on Solana

Learn about Solana block propagation, its comparison to Ethereum, and future research on data availability.

https://www.helius.dev

Turbine is a multi-layer block propagation mechanism used by a Solana cluster to broadcast ledger entries to all nodes. More recently, Anza introduced Alpenglow

Alpenglow: A New Consensus for Solana - Anza

Meet Alpenglow: Solana's new consensus protocol which highlights major performance gains. Learn more in the blog and linked white paper.

https://www.anza.xyz

with an upgrade to Turbine called Rotor. Rotor reduces some tree depth, but it still relies on Reed-Solomon code, resulting in redundant retransmissions and suffers loss accumulation, creating bandwidth waste and variable slot times.

Last month, we published a two-part Battles of the Code series to explain why RLNC-powered propagation is significantly faster and more resource-efficient than propagation mechanisms based on Reed-Solomon codes due to RLNC’s ability to recode.

https://mirror.xyz/0xBfAC4db6d990A6cF9842f437345c447B18EbeF73/GD-GGB8jlpv9wxwpLQzSFkJfT_F8fz91MxRoocI4L20

https://mirror.xyz/0xBfAC4db6d990A6cF9842f437345c447B18EbeF73/0q5fM2dl9B-o3UGToYHFwo67IfTJldPzdaHAFr7E12E

OptimumP2P Benefits:

• Increase Bandwidth & Reduce Latency (IBRL): RLNC recoding at every hop ensures only fresh coded packets traverse the network, cutting redundant traffic and freeing capacity for larger blocks or faster slots.

• Eliminate Loss Accumulation: Because data is recoded on the fly, missing data is regenerated continuously—avoiding the compounding packet losses that plague Turbine and Rotor.

• Predictable Sub-Second Propagation: Maintains consistent low-latency even under peak load—enabling shorter slot intervals without risking propagation stalls.

• Maximize Validator Performance: Uniform block delivery reduces skipped slots, strengthens consensus, and boosts on-chain throughput.

Any L1 can leverage OptimumP2P regardless of its virtual machine (VM) - potential examples include BNB Chain, Tron, Sui, Avalanche, Toncoin, etc. Downstream your favorite dApps on these chains - anything from the most popular DeFi platforms, to the hottest new onchain games- will all see a performance uplift as a result.

OptimumP2P transforms Layer-1 chains from bandwidth-constrained systems into high-throughput, low-latency platforms. OptimumP2P directly enhances validator rewards and on-chain scalability—setting the stage for the next era of base-layer performance.

Vertical-Specific Chains / Use cases

Beyond base-layer performance gains, specialized chains and use cases such as DeFi and DePIN, face unique bandwidth intensive demands. OptimumP2P’s coded propagation delivers the reliable and efficient synchronization these ecosystems need to thrive.

DeFi Chains

Central Limit Order Books (CLOBs), High-frequency trading (HFT), and automated market maker (AMM) protocols depend on sub-second propagation of orderbook and trade updates:

• Ultra-High Throughput: Transmit massive volumes of order-book and trade updates in parallel, effortlessly scaling to meet peak trading demand.

• Minimal Latency: Deliver every update in under 100 ms (and often under 50 ms regionally), ensuring traders see fresh prices almost instantly.

• Seamless User Experience: Faster, more consistent updates translate directly into smoother trades, fewer errors, and greater confidence for both retail and institutional users.

• Decentralize to Scale: Scale out without sacrificing speed or reliability, enabling truly decentralized DeFi infrastructure that rivals centralized exchanges.

DePIN Networks

Decentralized physical infrastructure networks built on-top of blockchains demand reliable node coordination at scale:

• Efficient Job Distribution: OptimumP2P improves coordination across GPU/compute/storage nodes.

• Graceful Node Churn: As nodes join or leave, networks remain resilient, avoiding data loss without sacrificing performance.

• Improved Task Completion: Higher performance and reliability means more consistent, timely responses for decentralized services.

Some of the DePIN use cases that stand to benefit include compute networks, IoT platforms, sensor mapping, and web data scrapers & aggregators.

DeFi and DePIN are two great examples (and there are quite a few more to explore) of specialized ecosystems which face acute data-intensity and latency demands that traditional gossip cannot meet. OptimumP2P’s coded propagation delivers the predictable high-performance these verticals require, unlocking new application possibilities and stronger user experiences. As data demands increase and chains need to scale, OptimumP2P isn’t just an alternative data propagation channel – it becomes essential infrastructure.

TL;DR

• OptimumP2P is a data propagation library that uses Random Linear Network Coding (RLNC)

• We ran identical simulations to prior Ethereum research, and observed over 2x faster message arrival times than Gossipsub

• We also ran experiments on real-world infrastructure, publishing 6 MB messages on a network of 36 nodes using first Gossipsub, and then OptimumP2P

• OptimumP2P's average latency in these experiments was over 2x better than Gossipsub

• We also observed that OptimumP2P scaled to larger message sizes (10 MiB and above), while Gossipsub started to fail to deliver messages under these circumstances

• Improvements to gossip benefit all levels of a blockchain ecosystem; scaling, validator profitability, user experience, and enabling new use cases that need low latency to thrive

Introduction

In peer-to-peer networks, nodes need to disseminate information to each other, a task known as gossip. Gossipsub is a widely-used algorithm to perform gossip in decentralized peer-to-peer networks, such as blockchains. Notably, Gossipsub is used to disseminate new beacon blocks on the Ethereum network.

Random Linear Network Coding (RLNC) is a form of network coding that has been studied in various settings, including gossip in peer-to-peer networks. Encoding messages to be gossiped using RLNC leads to faster propagation time (lower latency), and reduced duplicated transmissions (lower bandwidth usage). Indeed, it has been shown that incorporating RLNC into gossip leads to optimal behavior. OptimumP2P is a new RLNC-based fast data propagation protocol for any blockchain, starting with Ethereum.

We present the results of some simulations and experiments that we have run, comparing Gossipsub and OptimumP2P. The results confirm the theory: OptimumP2P is over twice as fast as Gossipsub, which does not utilize any network coding.

Simulation Construction and Results

We used the Ethereum tool Ethshadow to simulate gossip in an Ethereum-like network. This tool is built on the general-purpose simulation library Shadow. We built off the work of prior Ethereum research, running the same simulations as them with 1,000 nodes, 20% of which have the bandwidth of 1Gbps/1Gbps and 80% of which have 50Mbps/50Mbps. The publisher always has 1Gbps/1Gbps in order to get consistent simulation results. The latencies between pairs of nodes are based on real-world geographic locations.

We first ran a simple experiment, in which a single publisher publishes a single message. We varied message sizes from 128KB to 4096 KB, and observed significantly faster arrival times for all message sizes, as shown below. We remark that our observed performance of Gossipsub matches the results here, which give us confidence in our reproducibility.

We then ran simulations in which a single publisher published multiple messages (up to 64), with each message having a size of 128 KB. Once again, we observed notably faster arrival times in all cases.

From Simulation to Live Demo

Given the promising results in our simulation, we decided to test things out on real-world infrastructure. Our experiments were run on a cluster of 36 geographically distributed nodes, connected to each other. We compared the result of publishing 6 MB messages, at a rate of 2 messages per second. OptimumP2P achieved an average latency of 1.17 seconds for message delivery, compared to Gossipsub's average latency of 2.35 seconds.

We also varied the message size, from 2 MB to 10 MB. We observed that OptimumP2P scales to larger messages significantly better than Gossipsub, with the performance gap widening as message size increased. We also note that at 10 MB, Gossipsub no longer successfully delivered messages to nodes, while OptimumP2P continued to perform with consistently low latency. This behavior is characteristic of congestion, where delay increases highly non-linearly with load. Watch below as we run two of these tests.

Optimum

@get_optimum

𝐏𝐑𝐄𝐒𝐄𝐍𝐓𝐈𝐍𝐆: The first look at OptimumP2P in action

Test runs vs. Gossipsub show over 50% lower latency when delivering an average block sized message!

306

2:08 PM • May 28, 2025

We also measured the standard deviations of the latencies, and observed that Gossipsub’s standard deviation was twice as much as in the case of OptimumP2P. This is significant, because it is known from queueing theory that a greater amount of variation leads to overall worse performance for any system.

Conclusion

Our results with OptimumP2P confirm what is already well-established in the literature: there are significant performance improvements when Random Linear Network Coding (RLNC) is incorporated into gossip systems. The impact of these improvements is wide-ranging. Protocols like Ethereum can benefit from faster propagation of larger blocks and blobs, allowing them to accommodate increasing demand for blockspace and maintain high performance during periods of network congestion. Individual validators benefit from higher staking APY through more timely proposal and attestation of more profitable blocks, while also seeing lower operational costs from more efficient resource usage. Additional downstream benefits exist at the application and end user levels, which we'll explore in future pieces.

We hope you’re equally excited about the work Optimum is doing! To follow along as testnet progress continues, please follow us here on X and join the community on Discord.

Scale Any Chain

• Validators & Stakers

• L1/L2 Chains

• Apps

• End Users

What Does Standard Data Propagation Look Like Today?

And why is fast propagation crucial to scaling/speeding up chains?

When you make a transaction onchain it goes through several steps to reach confirmation. On Ethereum, this starts with the transaction being sent to an RPC node which connects the app you’re using to the blockchain. It then enters the mempool, a temporary holding area where pending transactions are collected before being included in a block. Next, the block is built and sent to the proposer via a relayer. The proposer is a randomly selected validator who kicks off the propagation process, broadcasting the chosen block out to the rest of the network. Once enough nodes to reach a ⅔ supermajority have received and attested to the block it is considered confirmed. Broadcasting proposed blocks around to other nodes is where OptimumP2P comes into play, speeding up that step significantly.

Today, Ethereum blocks are propagated using Gossipsub, a method of gossip that does not use data encoding. The advantage OptimumP2P has over Gossipsub is its use of erasure coding, specifically Random Linear Network Coding (RLNC). Coding the data in this fashion makes propagation faster, more reliable, and more bandwidth efficient.

Early OptimumP2P testing has shown 50%+ latency reduction with significantly less variation vs. GossipSub using average block-sized messages. As message size and frequency are increased, the performance gap widens until GossipSub can no longer reliably deliver messages while OptimumP2P remains highly performant.

Optimum

@get_optimum

𝐏𝐑𝐄𝐒𝐄𝐍𝐓𝐈𝐍𝐆: The first look at OptimumP2P in action

Test runs vs. Gossipsub show over 50% lower latency when delivering an average block sized message!

306

2:08 PM • May 28, 2025

It’s worth noting that approaches to data propagation vary by chain, and some already make use of erasure coding. Take Solana for example, which uses Reed-Solomon coding to achieve relatively fast propagation. However, OptimumP2P is chain-agnostic and RLNC is a significant upgrade to currently used codes such as Reed-Solomon & Raptor codes.

You can find a full analysis of RLNC vs. other erasure codes in our previous blog posts.

https://mirror.xyz/0xBfAC4db6d990A6cF9842f437345c447B18EbeF73/GD-GGB8jlpv9wxwpLQzSFkJfT_F8fz91MxRoocI4L20

https://mirror.xyz/0xBfAC4db6d990A6cF9842f437345c447B18EbeF73/0q5fM2dl9B-o3UGToYHFwo67IfTJldPzdaHAFr7E12E

Bottom line: OptimumP2P makes any chain faster. We are actively exploring opportunities to bring OptimumP2P to other L1 and L2 chains in addition to Ethereum. Now how do we implement OptimumP2P?

Permissionless Validator Level Implementation

OptimumP2P propagates blocks for validators. It is implemented on a validator’s machine, running as a sidecar alongside their Ethereum client software. OptimumP2P will be permissionlessly accessible, allowing validators to opt in to the fast data propagation network. Overhead is minimal, meaning any validator can take advantage of OptimumP2P regardless of hardware specs.

Now let’s look at how the fast data propagation process works. First, any received blocks are picked up from a validator by the Optimum Agent, a piece of software running on their machine that reads directly from their Ethereum Client. The block data is passed to the Optimum Service, an adjacent piece of software on the validator’s machine, where it is then broken into small coded shards (using RLNC) and sent out to other nodes. Once a node receives enough shards it can reconstruct the full block, but even before the full block is reconstructed a node can begin forwarding any received shards on to the next node. This is one of RLNC’s special properties that makes it so useful for fast data propagation. In addition to block propagation, OptimumP2P can be leveraged for faster transaction relay from RPC node to mempool, and faster blob propagation.

Important note: Ethereum validators can still perform standard data propagation (Gossipsub) alongside OptimumP2P, and will still use it to communicate with nodes that aren’t running OptimumP2P.

Effects of OptimumP2P Adoption: Speeds Increase, Costs Decrease

Now that we’ve established how OptimumP2P functions, let’s talk about why fast data propagation matters. Four groups of stakeholders are set to benefit from OptimumP2P; validators, the chain itself, app builders, and end users.

For validators, efficient, consistently fast propagation leads to higher APYs and lower operating costs. These economic effects that can be passed through to stakers as well. OptimumP2P propagation is significantly less bandwidth intensive than standard gossip, due to RLNC’s advantages (coded data sharding, timeslot efficiency). This means validators use less compute resources per data transmission, which lowers operating costs. Fast propagation is also important for block proposing, as slow propagation can mean a validator’s proposed block does not get included in the ledger, in which case they would lose out on block rewards. Being slow to receive new transactions could affect the ability to build MEV-optimized blocks, another source of validator revenue. We’re looking to better quantify these effects on validator economics as testnet progresses, and look forward to sharing our findings.

Efficiently using validator bandwidth enables scaling while retaining decentralization. RLNC-based propagation scales extremely well, maintaining high throughput across larger data sizes and higher frequencies than Gossipsub is capable of. This resource efficiency also means decentralization isn’t sacrificed as lower spec nodes can still participate effectively, as opposed to hardware-based scaling solutions that could push the network towards centralization. With regard to L2s, higher blob throughput enabled by OptimumP2P will improve rollup scaling in parallel with L1 scaling.

It’s important to note the potential of OptimumP2P to increase bandwidth & reduce latency operates under a network effect. As more nodes adopt OptimumP2P, data propagation speed and efficiency across the network rises, with maximum benefits being realized at full network adoption.

Now let’s look further downstream at how these performance gains are passed down to the application and user levels.

Second-order effects of OptimumP2P are felt at the application and end user levels. For app developers, OptimumP2P makes every interaction between the application & the chain quicker, moving closer to real-time performance. Milliseconds matter, and OptimumP2P opens the door for new use cases that require extremely low latency and high bandwidth.

OptimumP2P will be invisible to end users, as all good infrastructure should. Everything will simply feel faster. It’s a major quality of life improvement onchain, especially during periods of high congestion. The beautiful thing about RLNC based propagation is it doesn’t slow down when there’s more traffic on the network, throughput remains consistently high.

What’s Next?

We are currently in private testnet with a group of Ethereum node operators, where we’ve already been able to demonstrate 50%+ latency reduction vs. Gossipsub in a globally distributed network. We look forward to sharing more data and announcements from this round of testing soon. The next step is Hoodi Testnet, where we’ll get a much clearer picture of the scaling potential OptimumP2P can bring to Ethereum.

Time to scale the chains.

In the first part of this series, we explored how packet loss accumulates in block and fountain codes—even in simple network topologies such as daisy chains—and how the recoding capability of RLNC effectively mitigates this issue. In this follow-up article, we examine hierarchical topologies, such as trees, which have been adopted by Web3 protocols such as Monad and Solana. We present a simple example demonstrating that, even in tree-based architectures, RLNC can outperform both Raptor and Reed–Solomon (RS) codes by achieving lower latency.

1. From Daisy-Chains to Trees

As discussed in the first part of this series, loss accumulation in simple network topologies, such as multi-hop daisy-chains, was one of the striking disadvantages of block and fountain codes versus RLNC. Recall Fig 1[a], illustrating that a (generally small) number of transmitted shards can be lost at each hop along the path from the source to the receiver. Such loss is accumulated as the packets are passed from one hop to the next, so the more hops the packets need to travel, the more packets will be lost until they reach the receiver. The cumulative loss of encoded packets will either result in a failure of decodability or require substantial overhead.

Owing to recoding, RLNC does not suffer from loss accumulation. Missing pieces can be generated at each intermediate hop, and as a result the packet loss at the receiver will only reflect the losses at the previous hop. So, each intermediate node can forward either single-coded elements or recoded elements as soon as they can, without waiting for intermediate nodes to decode the value.

Networks, however, contain more complex interconnections than daisy-chain topologies. A slightly more complex topology are trees. Trees are hierarchical topologies stemming from a single node (the root), and then branching to intermediate (parent) and end (leaf) nodes. Trees have the important property of no cycles: starting from any node, no sequence of connections can lead back to the initial node. Interestingly, a tree topology can be imagined as a set of daisy-chains each starting from a branch node (Fig 1[b])! Each daisy-chain is marked with a different color in the figure, while the multi-color connection participates in two daisy-chains. Consequently, the tree structure does not compensate for the loss accumulation, but rather shares the same issue for both block and fountain codes.

Hierarchical tree-like topologies are adopted by two well-established Web3 protocols that also use erasure codes for information propagation in a decentralized environment: Solana’s Turbine [Y+17] and Monad’s Raptorcast [Lab23, Tea23] protocols.

Solana’s Turbine [Y+17] is a block propagation protocol designed to enhance data transmission across the network by breaking blocks into smaller packets, shreds, specifically by using R S codes, and distributing them rapidly and efficiently. Inspired by BitTorrent [Coh03], Turbine uses a tree topology (see Fig 2[a]) of the validators, where a leader produces a block, it splits the data into a sequence of batches, where each batch comprise 64 shreds where any 32 can be used to recover the original data (i.e. a code-rate of 1/2). A leader schedule is generated prior to each epoch, which occurs approximately every two days. The upcoming epoch is divided into fixed 400-millisecond slots, with a designated leader assigned to each slot. During its designated slot, the leader streams these shreds to a root validator, which in turn propagates to its children, which again then send the packets to their own children. This structure resembles a staged broadcast tree, where each layer of the tree further disseminates the data, reducing redundant transmissions and minimizing bandwidth usage. By breaking blocks into smaller chunks and leveraging RS coding, Turbine ensures that even if some shreds are lost, validators can reconstruct the full block without needing retransmission. This approach helps Solana achieve high-throughput while maintaining decentralization.

RaptorCast [Tea23], [Lab] is MonadBFT’s multicast protocol for block proposal dissemination using erasure coding based on a variant of Raptor codes (RFC 5053). Block proposals are split into fixed-size chunks and encoded into redundant packets, allowing the original block to be reconstructed from any sufficiently large subset. A two-level broadcast tree is used: the leader sends different chunk ranges to first-level validators, who then forward them to others. Validator responsibilities are proportional to stake weight, ensuring fair and efficient chunk distribution. This design fully utilizes network upload bandwidth while keeping propagation latency within 2× the network’s worst-case one-way latency. RaptorCast runs over UDP, and to compensate for packet loss, senders introduce configurable redundancy. Each block, typically of size 2MB, may generate thousands of chunks, distributed in contiguous ranges across all validators. This approach avoids retransmission overhead and tolerates faults without requiring bidirectional recovery.

2. Pushing Performance: Speeding-up Propagation with RLNC

To prevent the accumulation of shred losses—which can lead to decoding failures at the receiver—block and fountain codes typically adopt one of two strategies: (i) assume a fixed network topology (i.e., an upper bound on the number of hops between sender and any receiver) and generate a sufficient number of coded elements to compensate for losses; or (ii) decode the message at intermediate nodes, encode it anew, and forward it downstream at each hop.

Protocols like Turbine and RaptorCast follow approach (i): Turbine assumes a tree depth of two to three, depending on the number of active validators, while RaptorCast is based on a fixed two-level (two-hop) hierarchical structure. If these protocols were to add more layers as they scale, the number of hops would increase and throughput would decrease exponentially.

However, as we have discussed, that approach (i) is wasteful in terms of bandwidth for the same reason that the daisy-chain suffers when neither decoding or recoding are used.

Therefore, let us consider the following question: Is there a benefit to recoding over decoding following by a new coding? In particular, in a hierarchical structure if we allow decoding at intermediate nodes, is there a benefit to RLNC recoding? We shall see that the answer is ” yes” - there is a real benefit in latency, not being wasteful in terms of time.

Recoding provides RLNC with a distinct advantage in data propagation speed, as individually encoded elements can be forwarded downstream without the need for decoding at intermediate nodes. This advantage is illustrated in Fig. 3 for RLNC, RS, and Turbo code-based propagation. Assume the protocol executes in discrete time slots, where each time slot consists of a single broadcast round in which a parent node delivers one coded element to each of its connected children, corresponding to only one of the three protocols.

For the sake of conciseness, we depict shreds from the three approaches in the same figure. Faulty links—those that fail to send messages during a given timeslot—are shown in a lighter colored edge. A lightning icon appears on a node once it has received enough coded elements to decode the original message, with the icon color-coded to indicate which algorithm produced the elements used in decoding.

The figure compares the times taken for each coding strategy to propagate sufficient coded elements through the network. To prevent loss accumulation and decoding failure, block and fountain code approaches require each intermediate node to decode and re-encode the message before forwarding. In contrast, RLNC allows coded elements to be forwarded immediately without decoding, since loss accumulation and non-decodability are alleviated due to recoding.

Fig. 3[a] shows the initial setup of the system and the initial encoding produced at the root for each protocol. All three protocols start with four coded shreds and assume that any two coded elements (or shards) are sufficient to decode the original value. With fixed parameterization, the RS protocol generates exactly four coded elements, out of which any two can decode the message. Fountain and RLNC codes, on the other hand, produce unlimited combinations and can generate any number of coded elements.

At Timeslot 1 (Fig. 3[b]), one coded element from each protocol is delivered to two connected children (block and fountain codes are shown using the same symbol). Since none of the children receives two coded elements for the same protocol, they cannot decode the original data yet.

In Timeslot 2 (Fig. 3[c]), the root loses connection to the third child node but still manages to send coded elements to the first two children. The first child now has a pair of codes for all three protocols and successfully decodes the message. The rest of the children are still waiting for enough shards. An interesting point: during this timeslot, the first and third children of the root forward their RLNC shards to the lower level. As a result, one of the second-level nodes receives enough RLNC shards to decode the message.

It is worth highlighting that the first child performs recoding, producing shard number 7. Also, take note of the RS shred duplication at the leftmost node in the second level, which prevents it from decoding using RS codes. Under the same conditions, block and fountain codes require 6 timeslots to propagate the message to all nodes in the network. Web3’s currently hierarchical structures, used with legacy codes, are inherently wasteful of bandwidth and/or time. OptimumP2P (powered by RLNC) eliminates that wastefulness. In future articles, we shall explain also how removing the need for hierarchical structures is beneficial for fully using the network resources.

References

[Coh03] Bram Cohen. Incentives build robustness in bittorrent. In Workshop on Economics of Peer-to-Peer Systems, volume 6, pages 68–72. Berkeley, CA, USA, 2003.

[KMN] Battle of the Codes: RLNC vs Reed-Solomon & Fountain Codes. https://mirror.xyz/0xBfAC4db6d990A6cF9842f437345c447B18EbeF73/GD-GGB8jlpv9wxwpLQzSFkJfT_ F8fz91MxRoocI4L20 . Accessed: May 8, 2025.

[Lab23] Monad Labs. Monad: Parallel evm execution. https://www.monad.xyz/, 2023. Accessed: 2024-05-01.

[Lab] Monad Labs. Raptorcast. https://docs.monad.xyz/monad-arch/consensus/raptorcast. Accessed: 2024-05-08.

[Tea23] Monad Research Team. Raptorcast: Scalable communication for decentralized networks. Technical report, Monad Labs, 2023.

[Y+17] Anatoly Yakovenko et al. Solana: A new architecture for a high performance blockchain. https://solana.com/solana-whitepaper.pdf, 2017. Accessed: 2024-05-01.

Kishori Konwar (Optimum), Muriel Médard (Optimum/MIT), Nicolas Nicolaou (Optimum)

Abstract

Sending data over shaky or delayed connections often means it gets lost or delayed. The old way to deal with this was simply to resend anything that didn’t make it (like the TCP protocol does). But this approach has problems, especially on crowded networks where resending things just adds to the traffic jam and leads to further delays.

Erasure codes offer a different solution. They work by adding extra, often called redundant, information to help recover lost or damaged data. Basically, you break the original data into smaller pieces, then create some extra “coded” pieces using a special process. When you send these coded pieces (or shards), the receiver only needs to get some of them – not necessarily all – to rebuild the original data. This tolerance for missing pieces makes erasure codes great for unreliable situations like wireless networks, dynamic systems, and streaming applications.

With the rapid expansion of Web3 applications it is critical to answer the question: Which type of erasure codes are suitable for Web3 networks?

Random Linear Network Codes (RLNC) made their appearance in the early 2000s as an erasure coding solution for decentralized, highly dynamic environments such as the ones assumed in Web3 applications. Here, we argue that RLNC is a highly suitable candidate for Web3 network communication, outperforming conventional families of erasure codes, namely block erasure codes (e.g., Reed-Solomon codes) and fountain codes (e.g., Raptor codes).

1. Coding

When you send data over connections that aren’t reliable or tend to lose information, that data can get corrupted, mixed up, or just lost entirely. The usual way to deal with lost messages was just to send them again (like the TCP protocol often does). But this method had its problems, especially on crowded networks where sending things over and over could just make the congestion worse.

Erasure codes try to get around these issues. They use techniques that add extra, redundant information, which helps recover data that gets lost or damaged. How it works is, you divide the original data into smaller pieces (fragments). Then, you create some extra coded packets using a special process on those original pieces. When you send these coded pieces (sometimes called shards), the receiver doesn’t need to get all of them. They only need to receive a certain number of the pieces to figure out what the original data was. This makes the whole process tolerant to missing data. Because of this ability to handle lost pieces, erasure codes are really useful for tricky situations like wireless networks, systems spread across many computers that might change unexpectedly, and for streaming data smoothly.

Three of the commonly used types of erasure codes are block erasure codes (e.g., Reed-Solomon [RS60]), fountain codes (e.g., LT codes [Lub02], Raptor codes [Sho06]), and network codes (e.g, Algebraic Network Codes [KM03], Random Linear Network Codes [HMK+06]) each offering trade-offs between complexity, overhead, and adaptability.

Block-based codes like Reed-Solomon (RS) [RS60] and many others presented in [LJ04], are a foundational class codes that work by transforming data into a polynomial representation and adding systematic redundancy. They have traditionally been designed as error correcting codes but then repurposed for handling erasures. A (n, k) RS code works by splitting the data into k pieces and generating n − k additional coded packets, each of similar size to the un-encoded k pieces, creating a total of n shards. Any k out of n shards can be used to decode the original value, placing RS in the category of Maximum Distance Separable (MDS) codes. The ratio of the initial fragments k, over the total number of shards n, i.e. $$k/n$$, defines the coding rate, which is used to specify the number of erasures RS codes may tolerate. RS codes are widely used in storage systems like RAID arrays, optical media (CDs/DVDs), and QR codes owing to the fact that they are well understood. In network environments, RS codes as single source encoding mechanisms, meaning that coding is happening only at the source and decoding may happen at the targets.

Fountain codes, including LT [Lub02] and Raptor codes [Sho06], are rateless erasure codes, i.e. without predefined redundancy as in RS, designed for environments where loss rates are unpredictable. Unlike block codes, Fountain codes generate an unlimited stream of encoded packets, each constructed by combining original data shreds. The receiver can reconstruct the original data once it collects enough unique packets, eliminating the need for precise coordination between the sender and the receiver. This makes fountain codes suitable for one-to-many communication scenarios, such as multimedia streaming (e.g., DVB-H, IPTV), where the losses to different receivers may be different. Variants like Raptor codes [Sho06] reduce decoding overhead by preprocessing data.

Algebraic Network Coding (NC), represents a paradigm shift by allowing intermediate network nodes to combine (and not just forward) coded packets algebraically. The existence of NC was first discussed by Ahlswede, Cai, Li and Yeung in 2000 [ACLY00]. To be able to map network coding to actual coding Kötter and Médard [KM03] presented an algebraic framework for NC by representing the processes in each network node as algebraic equations and in turn the network response in the form of a matrix. They showed how matrix manipulations may allow both encoding and decoding of data. Decoding involves solving a system of linear equations once enough independent combinations are received. Random Linear Network Codes (RLNC) [HMK+06], further enhanced the applicability of the NC of [KM03] by allowing the selection of random coefficients in the generated equations, and hence, the generation of random linear combinations of original shards at each network node, which we refer to as recoding. In contrast to deterministic network coding, RLNC does not depend on any deterministic rules or predefined structures. This characteristic provides RLNC the ability to be superior over other approaches in decentralized and dynamic environments, such as wireless mesh networks, IoT systems, and 5G communications, where traditional codes struggle with fluctuating topology or intermittent connectivity. Furthermore, its ability to exploit path diversity and reduce redundant transmissions makes it uniquely suited for multicast and multi-hop scenarios [MAVPD25].

It is important to point out that RS codes are never better than RLNC. They are simply a degenerate, needlessly constrained version of a random code. That constraint arises from the fact that they were developed over half a century ago, for a different purpose. As seen in Figure 1 RS (left plot) simply poses unnecessary and often highly detrimental constraints (figure courtesy of Ken Duffy).

Table 1: Key Characteristics of RLNC, Reed-Solomon, and Fountain Codes

2. Let the Network Grow: The Power of Recoding

So, what’s the big deal with recoding? Well, let’s dive into how things work. Picture this: we’re sending data through a network, but it’s not always perfect. Sometimes, the network connections (the channels) drop packets, and that’s where erasure coding comes to the rescue. Imagine, for example, that every lossy channel drops 1 every 10 messages it transfers.

Now, let’s start with a simple setup: a single point-to-point connection. In this case, the source sends the data directly to the receiver. Using any coding technique the source would do the following: encodes the data, by adding some extra shards to make up for the lost packets, and then sends the shards to the receiver. In our example, if the receiver needs 10 shards to decode the value then the source will prepare 11 shards. So, the receiver gets enough shards to decode the original message, despite any losses from the network, and the delivery of the data to the receiver works at its best.

But what happens when we want to send data to multiple receivers at once? In such scenarios block codes fall short and fail to deliver. When block codes are used in a single-hop multicast setup, the source encodes the data based on specific coding parameter (n, k), and it divides the data into shards to be distributed to the receivers. Each receiver needs at least k shards to decode the original data. If some receivers will fail to collect k shards, they fail to decode the original data.

On the other hand, fountain codes and RLNC allow generation of coded packets indefinitely, which allow them to cope with different erasures at different receivers.

Communication over a wide area network (WAN) requires multiple hops, and often multiple paths exist between the source and the receiver. In such environments, both block and fountain codes may often fail to deliver the message. Both approaches assume that a single source is responsible for generating the coded elements from the original data, and therefore, a sufficient number of coded elements must reach the receiver to guarantee decodability. To do so, intermediate nodes need to forward the packets they receive. As shown in Figure 2(a), a (generally small) number of transmitted shards will be lost at each hop along the path from the source to the receiver. However, such loss is accumulated as the packets are passed from one hop to the next. So the more hops the packets need to travel, the more packets will be lost until they reach the receiver. The cumulative loss of encoded packets will either result in a failure of decodability or require substantial overhead.

One approach to cope with this is to decode the data at intermediate nodes, re-encode it, and then forward it to downstream nodes at each hop. While this may be feasible in simple networks, such as a daisy chain, it will fail in more complex topologies like the one shown in Figure 2(b). In such networks, splitting coded elements among intermediate nodes may prevent those nodes from collecting enough coded elements to decode.

In contrast, recoding at intermediate nodes when using Random Linear Network Coding (RLNC) — which does not require decoding — can actually assist in generating missing coded packets at each hop. As a result, the packet loss at the receiver will reflect only the losses incurred from the last hop. Consequently, the total loss remains comparable to that of a single-hop architecture. This ensures that decoding performance is preserved, allowing all data to be successfully decoded at the receiver. Furthermore, the network is fully utilized, as there is no downtime for decoding.

Owing to its ability to recode, RLNC is particularly well-suited for dynamic networks, where constant node churn and frequent changes in the path between source and receiver are common. Recoding in RLNC not only enables the creation of new encoded packets without prior decoding, but it also eliminates the need for distributed synchronization protocols, leveraging the inherent randomness of the coding process. This adaptability allows RLNC to dynamically optimize for changing network conditions, improving both latency and bandwidth efficiency.

Table 2: Scalability of RLNC, Reed-Solomon, and Fountain Codes

By harnessing the power of recoding, RLNC is uniquely equipped to handle scalability. In particular, all other coding approaches are unscalable. As the network grows, their throughput decreases with the number of hops, whereas RLNC is able to maintain a constant throughput. This means that it is necessary for a decentralized scalable network. In future pieces, we shall visit what are some of the practical consqeuences, even in cases where the number of hops is not large.

References

[ACLY00] Rudolf Ahlswede, Ning Cai, Shuo-Yen Robert Li, and Raymond W. Yeung. Network information flow. IEEE Transactions on Information Theory, 46(4):1204–1216, 2000.

[HMK+06] Tracey Ho, Muriel Médard, Ralf Kötter, David R. Karger, Michelle Effros, Jun Shi, and Ben Leong. A random linear network coding approach to multicast. IEEE Transactions on Information Theory, 52(10):4413–4430, 2006.

[KM03] Ralf K¨otter and Muriel M´edard. An algebraic approach to network coding. IEEE/ACM Transactions on Networking, 11(5):782–795, 2003.

[LJ04] Shu Lin and Daniel J. Costello Jr. Error Control Coding. Pearson Prentice Hall, 2nd edition, 2004.

[Lub02] Michael Luby. LT codes. In Proceedings of the 43rd Annual IEEE Symposium on Foundations of Computer Science (FOCS), pages 271–280, 2002.

[MAVPD25] Muriel Médard, Vipindev Adat Vasudevan, Morten Pedersen, and Ken Duffy. Network Coding for Engineers. 02 2025.

[RS60] Irving S. Reed and Gustave Solomon. Polynomial codes over certain finite fields. Journal of the Society for Industrial and Applied Mathematics, 8(2):300–304, 1960.

[Sho06] Amin Shokrollahi. Raptor codes. IEEE Transactions on Information Theory, 52(6):2551– 2567, 2006.

Memory—the component that enables computers to store, access, and update data efficiently—is a key element of every computer on earth. From your laptop to a supercomputer, all rely on memory. This architecture, first outlined by John von Neumann, has been the backbone of computing for decades. The memory bus facilitates data exchange between the CPU and RAM. RAM provides temporary storage for the operating system, software, and data in use, enabling programs to run efficiently.

At the surface, blockchains do resemble traditional computers. We have operating systems like the EVM and SVM, running on decentralized nodes and powering a growing ecosystem of applications. But dig deeper, and the gaps start to show. What we find is that most of the top level computing parts are recognizable while the memory unit is not only unrecognizable but also inefficient.

The Current Memory Bottleneck

Instead of a proper memory architecture, blockchains rely on a mashup of different best-effort approaches, creating critical bottlenecks and costly operations:

• Redundancy: Gossip networks have replaced memory buses but redundantly propagate the same data to multiple nodes, wasting bandwidth, slowing block confirmation, increasing overall system cost;

• Congestion: Inefficient networking stacks & state access cause unpredictable delays and cost surges in transaction processing;

• State Bloat: Full nodes must store all state data permanently, making retrieval costly and complex.

Today, most blockchain networks use gossip protocols to propagate data — broadcasting everything to everyone, redundantly. Bitcoin and Ethereum 1.0 relied on this approach, but it didn’t scale. Ethereum 2.0 had to rethink this with new wire protocols to cut down on message overload. Avalanche also had to push a software update to reduce "excessive gossip" between validator nodes as it was straining its network. Solana, on the other hand, sidestepped full history retention by storing only the recent state, relying on professional “warehouse nodes” to archive older data.

While today's solutions address data accessibility, they fail to solve the fundamental challenge of next-generation memory architecture—one that seamlessly integrates lightning-fast retrieval, atomic-level updates, and fluid real-time interactions. Existing technologies across platforms offer glimpses of this potential, but none deliver the comprehensive foundation required for a truly scalable world computer that can transform how we interact with decentralized information.

Despite years of R&D, this fundamental piece of architecture — memory — has yet to be solved. Until now.

Meet Optimum: The First Decentralized Memory Layer

Optimum is building the missing memory layer for Web3.

It’s the world’s first decentralized, high-performance memory infrastructure for any blockchain — designed to scale data access, reduce network strain, and power the next generation of dApps. Powered by Random Linear Network Coding (RLNC) — a proven, MIT-developed data encoding technique — Optimum turns sluggish, redundant networks into fast, efficient, scalable systems.

With Optimum, blockchains gain a memory bus and RAM that rivals the performance of modern computing. At its core, Optimum is building a provably optimal memory infrastructure that transforms blockchains into high-speed, scalable computing networks. The architecture is modular, permissionless, and easy to integrate via API.

Two Core Components of Optimum

OptimumP2P - A pub-sub protocol designed to replace outdated gossip networks with smart, coding-based data propagation. It dramatically cuts down redundancy and improves throughput — leading to higher APY for validators, faster transactions, and smoother user experiences for dApps, DEXs and more.

Optimum deRAM - A decentralized RAM layer that ensures Atomicity, Consistency, and Durability (ACD). deRAM gives applications real-time read/write access to blockchain state, enabling fast, cheap storage and access. This is what unlocks the next wave of latency-sensitive, on-chain use cases: trading, gaming, AI, and social.

What Powers Optimum: RLNC - The MIT-Incubated Breakthrough

At the heart of Optimum lies Random Linear Network Coding (RLNC), a breakthrough in data coding developed by MIT Professor Muriel Médard, Optimum’s co-founder and CEO.

RLNC has been refined over two decades. RLNC has garnered significant recognition for its transformative impact on data networks. It was honored with the IEEE Koji Kobayashi Computers and Communications Award in 2022 and has contributed to Muriel Médard’s election to the U.S. National Academy of Engineering.

Data coding has been around for decades and there are many iterations of it in use in networks today. RLNC is the modern approach to data coding built specifically for decentralized computing. This scheme transforms data into packets for transmission across a network of nodes, ensuring high speed and efficiency.

It’s a mathematical, provably optimal way to handle memory for distributed systems — and Optimum is the first to bring it on-chain.

Optimizing Web3 From Top to Bottom

High-performance Web3 memory powered by RLNC empowers faster data propagation, efficient storage, and real-time access, making it a key solution for scalability and efficiency.

Blockchains rely on data moving efficiently across a network of nodes. RLNC is an advanced encoding technique that transforms data into encoded fragments, allowing nodes to recover information efficiently from a subset rather than receiving everything.

Optimum's products include OptimumP2P and decentralized Random Access Memory (deRAM) deliver benefits across the entire blockchain ecosystem:

• For L1 and L2 blockchains: Faster block propagation, reduced bandwidth consumption, and optimized storage

• For validators: Accelerated data propagation, lower operational costs, higher APY and MEV income

• For dApp developers: Improved transaction relay and prioritization, enabling latency, throughput, and cost-sensitive apps

• For end users: Faster transactions and more responsive interfaces, improve user experience

Built by Experts, Backed by Leaders

Behind Optimum is a world-class founding team with deep expertise in distributed systems, cryptography, and high-performance computing.

Meet the Core Team

• Prof. Muriel Médard (Co-Founder) Twitter | LinkedIn

  • NEC Chair of Software Science and Engineering at MIT

  • Co-inventor of Random Linear Network Coding (RLNC)

  • Ranked #1 globally in network coding citations (Google Scholar)

  • U.S. National Academy of Inventor, U.S. National Academy of Engineering, American Academy of Arts and Sciences and German National Academy of Science.

• Dr. Kishori Konwar (Co-Founder) LinkedIn

  • Former Senior Engineer & Scientist at Meta, MIT PostDoc

  • Previously a Quant Developer at Goldman Sachs

  • Deep expertise in distributed systems and fault-tolerant computing

• Kent Lin (Co-Founder) Twitter | LinkedIn

  • Former Partner at GSR Ventures, a $4B global VC

  • Harvard MBA, President of Harvard Blockchain, Co-founder of Plug and Play Crypto

  • Founder of McKinsey Crypto DAO, with a focus on blockchain infrastructure and strategy

Advisors

• Prof. Sriram Viswanath

  • B.Tech. from IIT Madras, M.S. from Caltech, and Ph.D. from Stanford, all in electrical engineering

  • Recipient of the NSF CAREER Award and IEEE IT/ComSoc Best Paper Award

  • Renowned for his work on coding theory, data compression, and distributed algorithms

• Prof. Nancy Lynch

  • Former NEC Chair of Software Science and Engineering at MIT (predecessor to Muriel Médard)

  • Published the foundational consensus results in 1985

  • Creator of the DLS algorithm in 1988, a foundational precursor to modern consensus systems like Tendermint

Strategic Backers

Optimum recently announced the successful closure of its $11M seed round, led by 1kx, with participation from top-tier investors including Robot Ventures, CMT Digital, Spartan, Finality Capital, SNZ, Triton Capital, Big Brain, CMS, LongHash, NGC, Animoca, GSR, Caladan, Reforge, and more.

Optimum's angel investors include many renowned builders and investors, such as Abhijeet Mahagaonkar (CTO, Polychain), Arthur Cheong (Founder CEO CIO, DeFiance Capital), Gracy Chen (CEO, Bitget), Robinson Burkey (Co-founder CCO, Wormhole), Sandeep Nailwal (Co-founder, Polygon), Sankha Banerjee (Chief Economist, Babylon), Saurabh Sharma (GP, Jump Crypto), Tal Tchwella (Head of Product, Solana), and Zaki Manian (Co-founder, Sommelier), as well as co-founders of Aethir, Aztec, Espresso, Magna, Pyth, Quantstamp, Taiko, Zama, ZkCloud and more.

Our Vision: Scaling the World Computer, For Real This Time

Web3 doesn’t just need more block space or cheaper gas. It needs architecture that supports real-time data access, minimal latency, and scalable throughput—without compromising decentralization.

“If you think of Web3 as a world computer, what we’re building is the critical component every computer needs—memory,” says Muriel Médard, co-founder and CEO of Optimum. “With a high-performance memory layer, our goal is to scale every blockchain.”

By applying core ACID principles—Atomicity, Consistency, and Durability—in a decentralized context, Optimum enables a new paradigm: decentralized systems that can finally scale. This unlocks real-time, cost-sensitive applications in trading, gaming, AI, and beyond—previously bottlenecked by legacy blockchain architecture.

Final Thoughts: A New Standard for Web3

Optimum isn’t just patching symptoms—it’s solving the root problem. By introducing a true memory layer to Web3, Optimum has the potential to redefine decentralized computing from the ground up. We’re not just making blockchains faster. We’re making them smarter, more responsive, and ready for what’s next.

The world computer was never complete—until now.

Join Us!

Optimum is the first decentralized high-performance memory layer for the world computer, designed to eliminate scalability bottlenecks by enabling fast data propagation, efficient storage, and real-time access.

Optimum is now live on private testnet with OptimumP2P, actively onboarding L1s, L2s, validators, and node operators to experience the world computer’s missing memory layer in action.

• Learn more at getoptimum.xyz

• Follow Optimum on x.com/get_optimum.

• Check our open roles at jobs.ashbyhq.com/optimum