rbuilder builds Ethereum blocks for MEV-Boost relays in Rust

What a block builder actually does

rbuilder is described as an open-source implementation of an Ethereum MEV-Boost block builder written in Rust, with the emphasis on speed, designed to provide a delightful developer experience so that community members can contribute and researchers can use it to study block building. The mechanism is described in the feature list and it is more concrete than the name suggests. The included algorithm builds blocks by sorting the orders by either effective gas price or total profit and then trying, and the README is honest that they might fail, to execute them to create the block. The implementation lives in ordering_builder.rs. The economics are worth understanding before the code, because the reason a builder exists at all is that in a proof of stake Ethereum the proposer does not build the block. A builder competes to assemble a profitable block and proposes it to relays, and the relay serves it to the proposer. A builder that loses the race gets its block orphaned, which is where the reorg loss warning comes from.

Backtesting is the mode that makes it research

rbuilder can be run in two modes, and the first is the one that makes the project usable without stake. Backtesting means building blocks on historical data, and rbuilder does it by using the mempool-dumpster's open database of transactions so that anyone can backtest block building on previous blocks. If you have historical bundles you can plug those in instead. The builder also pulls the on-chain block to compare its local block building against what actually landed, which turns the tool into a measurement instrument rather than just a builder, and historical data is stored locally in an SQLite database to support rapid testing and iteration. There is a noob guide wiki page for backtesting. That combination is what makes rbuilder a research tool rather than a production binary: you can run your ordering algorithm against a real block and see the profit difference without competing with anyone.

The live path needs five things lined up

To run rbuilder live you need a specific set of components, and the README lists them as requirements rather than as suggestions. A Reth node for state, using the reth_datadir setting. The Reth node must expose an ipc interface for mempool transaction subscription, through the el_node_ipc_path setting. The Reth node must be configured to flush every block, with the engine persistence threshold and the engine memory block buffer target both set to zero. A CL node that triggers new payload events, and it must be additionally configured to trigger a payload event every single time. A source of bundles that sends eth_sendBundle, mev_sendBundle and eth_sendRawTransaction as JSON RPC calls, configured through jsonrpc_server_port, and by default rbuilder takes raw transactions from the Reth node mempool. And relays to submit to, through the relays setting. Two optional integrations are also documented: a block processor API as a sink for submitted blocks, and Prometheus or Grafana for metrics served on the telemetry port at the /debug/metrics/prometheus path, plus tracing of all events inside the builder served on the same port under /debug/tracing with start and stop.

Running it is a config file and one command

The running instructions are two steps. Prepare a config file based on the config-live-example.toml in the examples/config/rbuilder directory, and then run rbuilder run with the path to that config file, with the field documentation in docs/CONFIG.md. The README includes sample command lines for a Lighthouse consensus client and for a Reth node, which is a practical detail because the Reth flags are the part that has to be exactly right, since the flush-every-block requirement and the IPC exposure are both expressed as Reth command line options. The sample Reth invocation enables the auth rpc with a jwt secret, opens both http and websocket endpoints on localhost, sets the rpc max connections to 429496729, and enables the trace, web3, eth and debug APIs on both. The Lighthouse sample runs with the always-prepare-payload flag and a prepare-payload-lookahead of 8000, which is the setting that makes the CL client send payload events on every block rather than only when it needs to.

The test relay lets you build without submitting

There is a test-relay tool in the repository for testing a live builder without submitting blocks to live production relays. The standalone binary implements the MEV-Boost Relay API that a builder needs in order to function, and the test relay only performs block validation and compares profits between builders that submit to it, without actually sending blocks to the network. It exposes several Prometheus metrics about the blocks it received, and the invocation takes a relay flag, a validation URL and a CL clients list:

./test-relay \
    --relay "https://boost-relay-hoodi.flashbots.net" \
    --validation-url "http://localhost:8545" \
    --cl-clients "http://localhost:5052" 

The relay flag can point at a live relay, and the README lists mainnet, Hoodi and Sepolia endpoints. When a validation URL is passed, the blocks produced by rbuilder are validated by the execution layer node, which must support the Flashbots validation API such as flashbots_validateBuilderSubmissionV3. The point of the tool is that a builder developer can run the full loop, including relay interaction and validation, without competing for real blocks or risking real money.

Workspace layout, build profiles and reproducible builds

The Cargo workspace lists fourteen members and marks eight as default. The core is crates/rbuilder, with rbuilder-primitives holding the shared types, rbuilder-config the configuration, rbuilder-utils the helpers, rbuilder-operator and rbuilder-rebalancer for the operational side, and reth-rbuilder as the Reth integration. The rest are tools, with eth-sparse-mpt, sysperf, test-relay and bid-scraper, the last of which is the component that scrapes builder bids from relays. The build profiles are the part that shows how seriously this is taken. There is a dev profile with line-tables-only debug info and split debuginfo set to unpacked, with a comment noting that debuggers may provide less useful information and that the section should be uncommented if you are using a debugger. There is a debug-fast profile that inherits release but keeps full debug symbols for use with perf, a maxperf profile with fat LTO, one codegen unit and no incremental compilation, and a reproducible profile with thin LTO, panic set to abort and the same single codegen unit. The Makefile detects the architecture and, on x86_64, selects the reproducible profile with target-cpu set to x86-64-v3, the build ID removed from the link, symbol name metadata hashes cleared, path prefixes remapped, and the timestamp taken from the last git commit.

Bundle merging, nonce handling and benchmarking

Two features are worth singling out because they are the ones a builder without them gets wrong. Bundle merging drops bundles that target transactions which have already been included in a pending block, and the bundles that should be dropped are marked in the reverting_tx_hashes field. Smart nonce management identifies and handles nonce dependencies between bundles and transactions, which is the part that decides whether a block executes at all rather than reverting on the node. Beyond that there is backtesting support for mempool transactions and other data, multiple algorithms with the design intended to be upgraded to handle several block building strategies, and use of Reth, described as a fast, efficient and user-friendly Ethereum node written in Rust. The benchmarking setup is based on Criterion.rs, every pull request receives a benchmark report hosted in S3, and you can run the benchmarks with make bench and open the report with make bench-report-open, with the benchmarks living in the benches directory of the rbuilder crate. The licence is dual, MIT or Apache-2.0, and the default branch is develop.

Editorial conclusion

Adopt rbuilder if you are researching how Ethereum blocks get built, and you want a builder you can run against historical data before you point it at a live relay. Do not adopt it as a production revenue system, because the README warns about reorg losses even though they are rare, and because a builder competes against other builders on the same relays. Verify first that you have a Reth node exposing the ipc interface for mempool transaction subscription, that it is configured to flush every block with the persistence and memory buffer thresholds at zero, and that your relays and bundle source are set up as the config file expects before you run the builder against mainnet.

Frequently asked questions

Official sources

1. flashbots/rbuilder on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases