The Flashblocks Websocket Proxy is a service that subscribes to new Flashblocks from rollup-boost on the sequencer. Then broadcasts them out to any downstream RPC nodes. Minimizing the number of connections to the sequencer and restricting access.
⚠️ WarningThis is currently alpha software -- deploy at your own risk!
Currently, this project is a one-directional generic websocket proxy. It doesn't inspect any data or validate clients. This may not always be the case.
You can build and test the project using Cargo. Some useful commands are:
# Build the project
cargo build
# Run all the tests (requires local version of redis to be installed)
cargo test --all-features
Builds of the websocket proxy are provided.
The only configuration required is the rollup-boost URL to proxy. You can set this via an env var UPSTREAM_WS or a flag --upstream-ws.
You can see a full list of parameters by running:
docker run ghcr.io/base/flashblocks-websocket-proxy:master --help
The proxy supports distributed rate limiting with Redis. This is useful when running multiple instances of the proxy behind a load balancer, as it allows rate limits to be enforced across all instances.
To enable Redis integration, use the following parameters:
--redis-url- Redis connection URL (e.g.,redis://localhost:6379)--redis-key-prefix- Prefix for Redis keys (default:flashblocks)
Example:
docker run ghcr.io/base/flashblocks-websocket-proxy:master \
--upstream-ws wss://your-sequencer-endpoint \
--redis-url redis://redis:6379 \
--global-connections-limit 1000 \
--per-ip-connections-limit 10When Redis is enabled, the following features are available:
- Distributed rate limiting across multiple proxy instances
- Connection tracking persists even if the proxy instance restarts
- More accurate global connection limiting in multi-instance deployments
If the Redis connection fails, the proxy will automatically fall back to in-memory rate limiting.