P2P Flashblocks Propagation

[0xForerunner]

Our team was discussing today what the optimal way to distribute flashblocks to consuming nodes is. I feel the websocket proxy method feels a bit forced like pushing web2 apis on something that should really be web3 based. As well, a websocket proxy could be vulnerable do a DDOS attack where some bad actor consumes all available connections on the proxy and is able to take advantage of MEV opportunities without competition.

I've got a very WIP implementation of what distributing flashblocks over the p2p layer could look like instead! Basic flow:

• rollup-boost should be in charge of authorizing who has permission to build blocks
• rollup-boost signs a message authorizing a builder to build a block with a specific payload_id
• signed Authorization is included in modified ForkChoiceUpdated with attrs call to builder
• builder receives Authorization, begins building blocks and publishes them over the flashblocks peering layer as a new libp2p capability utilizing the existing peer set
• flashblocks published over the peering layer contain the builders signature along with it's authorization for that payload_id
• nodes receive the flashblocks and validate their authorization

I'm posting a draft PR here just in case you're curious to take a look. It's absolutely not ready so please don't leave any comments on implementation. I'm really please with how easy it is to add p2p capabilities on top of reth!

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
rollup-boost	Ignored	Preview		Nov 5, 2025 6:14pm

[rorupuntou]

u.u

[haardikk21]

I wonder if we can have the optionality of choosing between websocket and p2p, or both rather than entirely replacing it. For example, consumers consume from the websocket stream primarily since it's faster and fallback to p2p messages if they get disconnected/rate-limited etc on the WS stream.