The Bigger the Message, the Clearer the Difference in Propagation 👀
This time, I looked at what kind of differences appear between Optimump2p and Gossipsub as message size increases.
Previously, we saw that Optimump2p showed lower latency than Gossipsub in both simulation environments and real-world infrastructure tests.
But what I found even more interesting this time was that the gap between the two approaches became larger as message size increased📈
According to the material, they tested different message sizes from 2MB to 10MB. What stood out was that Optimump2p maintained relatively stable performance even with larger messages, while Gossipsub seemed to struggle more as message size increased.
In particular, with 10MB messages, Gossipsub even failed to successfully deliver messages to nodes. This did not look like a case of simply becoming a little slower. It felt more like the propagation method itself could start to struggle under certain conditions.
The amount of data blockchain networks need to handle will likely continue to grow. Transaction volume will increase, block data can become larger, and blob data is becoming increasingly important in Ethereum as well.
If the data propagation method cannot reliably handle large messages, overall scalability will still be limited no matter how fast the execution layer becomes 👻
With small messages, most approaches may seem to work reasonably well. But when message size grows, data moves more frequently, and many nodes start exchanging information at the same time, the difference in propagation methods becomes much clearer.
The material connects Gossipsub’s failure to deliver large messages with congestion. As network load increases, delay does not just rise little by little. At some point, it can increase non-linearly and become much worse.
➜ In simple terms, when the network gets busy, it may not just slow down slightly. It can suddenly start to break down.
This is where the meaning of Optimump2p became clearer to me. Optimump2p uses RLNC to split data into coded pieces for propagation. The receiving node does not need to receive every original piece in the exact order. Once it collects enough coded pieces, it can reconstruct the original message.
That is why it seems able to operate more flexibly even with large messages or in more complex network environments 🧩
I think this result goes beyond simply saying that Optimump2p is faster. The key point is that it showed the possibility of holding up more reliably even when message size grows and the network becomes more loaded.
This could become an important point for blockchain scaling going forward. If Web3 is going to handle more data, execution speed alone is not enough. The way data spreads also needs to scale.
The result shown by
@get_optimum's Optimump2p felt like a meaningful signal in that direction 🚀