For the last few months, we’ve been working on a new implementation of Fiber on Ethereum. Fiber is a mempool service that consists of a network of highly optimized nodes.
Fiber is built with 3 pillars in mind:
Recently, the engineering team at Paradigm unveiled a new open-source execution client called Reth. In short, reth aims to be an execution client to serve a large user base, including power users like MEV searchers, RPC node operators, block builders, and more. It will do so by making reth highly performant, but also very configurable, so that users can tweak and tune the settings to find the optimal setup for their use case. No other execution client is doing this, so this is big positive for the space.
In our journey of creating the ideal network topology for our Fiber nodes, we had to determine the critical geographical regions of the Ethereum p2p network. We will define these "hotspots" as regions where the most transactions are originally broadcasted from.
Because Fiber is a mempool service, we need to be able to deliver transactions to users as fast as possible, which also means making sure we sufficiently cover these hotspots. In essence, we want to make sure we're as close to the original broadcaster is possible, which in p2p terms means either being directly connected to it, or only 1 or 2 hops away. Each hop will introduce a non-trivial amount of latency, which is something we need to minimize.