P2P Flashblocks Propagation #373
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
|
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. |
| RUN cargo install cargo-chef --version ^0.1 | ||
|
|
||
| RUN apt-get update \ | ||
| && apt-get install -y clang libclang-dev |
There was a problem hiding this comment.
I have this now:
RUN apt-get update \
&& apt-get install -y clang libclang-dev gcc
Should be fine.
There was a problem hiding this comment.
Yeah I'm asking is this a necessary addition. It was working previously, so what addition made this a necessary change
There was a problem hiding this comment.
TBH it was a while ago and I'm not sure :p
| hex = "0.4" | ||
|
|
||
| # Reth deps, use 4231f4b to get latest op-alloy | ||
| reth-optimism-payload-builder = { git = "https://github.com/paradigmxyz/reth", rev = "4231f4b" } |
There was a problem hiding this comment.
These dependencies should be pinned to v1.9.3
There was a problem hiding this comment.
1.9.3 doesn't have the latest op-alloy which is causing problems
There was a problem hiding this comment.
Why can't we just match the alloy versions from reth?
There was a problem hiding this comment.
I'd have to downgrade op_alloy_rpc_types_engine since we're already depending on the newer version here.
Co-authored-by: 0xOsiris <djosiris@proton.me>
There was a problem hiding this comment.
Pull request overview
This PR introduces a P2P-based flashblocks propagation mechanism to replace the WebSocket-based approach. The implementation uses libp2p to distribute flashblocks across nodes with cryptographic authorization, improving fault tolerance for HA sequencer setups. The key innovation is using signed authorization tokens from rollup-boost to control which builder can publish flashblocks, with graceful failover support through StartPublish/StopPublish messages.
Key Changes:
- Adds P2P flashblocks protocol specification with authorization and security model
- Implements cryptographic authorization using ed25519 signatures
- Adds RLP encoding/decoding for flashblocks and authorization structures
- Introduces FlashblocksP2PArgs for configuring P2P mode alongside existing WebSocket mode
- Refactors RpcClient to support optional flashblocks authorization keys
Reviewed changes
Copilot reviewed 14 out of 15 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| specs/flashblocks_p2p.md | Comprehensive specification for P2P flashblocks protocol including authorization, security, and multi-builder coordination |
| crates/rollup-boost/src/server.rs | Refactors server initialization to support both WebSocket and P2P flashblocks modes |
| crates/rollup-boost/src/client/rpc.rs | Adds FlashblocksP2PKeys and authorization logic to fork choice updates |
| crates/rollup-boost/src/flashblocks/args.rs | Splits flashblocks args into WebSocket and P2P variants with validation |
| crates/rollup-boost/src/cli.rs | Adds extensive CLI argument parsing tests for P2P configuration |
| crates/rollup-boost-types/src/authorization.rs | Implements Authorization structure with signing, verification, and RLP encoding |
| crates/rollup-boost-types/src/flashblocks.rs | Adds manual RLP encoding/decoding for FlashblocksPayloadV1 |
| Cargo.toml | Adds ed25519-dalek, blake3, hex dependencies and updates reth to rev 4231f4b |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
4 participants
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-boostshould be in charge of authorizing who has permission to build blocksrollup-boostsigns a message authorizing a builder to build a block with a specificpayload_idAuthorizationis included in modifiedForkChoiceUpdatedwith attrs call tobuilderbuilderreceivesAuthorization, begins building blocks and publishes them over theflashblockspeering layer as a new libp2pcapabilityutilizing the existing peer setpayload_idI'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!