BuilderNet v1.3
BuilderNet v1.3 is the culmination of close collaboration with searchers, OFAs, and other orderflow providers to integrate BuilderNet directly with their production workflows. This release improves both the user experience for sending bundles to BuilderNet nodes, and the testing, observability, and deployment experience for operators to facilitate faster iteration in the future.
Improvements
Upgraded eth_sendBundle API
BuilderNet v1.3 provides an upgraded eth_sendBundle API, which includes new fields for backrun OFAs that are widely supported by other block builders. This allows backrun OFAs to submit directly to BuilderNet with better performance and customization. Specifically, these new (optional) fields were added:
| Field | Description |
|---|---|
droppingTxHashes | A list of transaction hashes contained in the bundle, that are allowed to be removed from the bundle (but not allowed to revert). This feature is typically used to allow the builder to merge multiple OFA backruns together. |
refundPercent | An integer between 1-99, which indicates much of the total priority fee + coinbase payment to refund. A payout transaction transferring the refund amount will be appended immediately following the bundle in the same block. The cost of the payout transaction is deducted from the overall refund. |
refundRecipient | An address that the funds from refundPercent will be transferred to in the payout transaction. If not specified, they will be sent to the from address of the first transaction. |
BuilderNet now also supports bundle cancellations with eth_sendBundle. To cancel a bundle, send a new eth_sendBundle request with the same replacementUuid and an empty list of transactions. This matches the standard behavior supported by Beaverbuild and Titan.
See the BuilderNet API Reference for more information and details.
Improved cancellations
In addition to these API-level changes, BuilderNet v1.3 also makes several upgrades to the performance and reliability of bundle cancellations. To ensure cancellations are correctly processed, v1.3 adds support for block level cancellations on MEV-Boost relays and continues bidding even when the block value decreases. To reduce the latency for processing cancellations, BuilderNet nodes now submit only to regional relays (shaving off an estimated ~50ms in network latency). We have also introduced a time limit to prevent slower bundle merging strategies from arbitrarily delaying cancellations, and an initial set of spam prevention techniques to reduce the load on the builder. The latter drove a 2x decrease in p99 e2e latency.
Together we expect these changes will make BuilderNet a much better venue for users that require fast updates to their bundles.
Additional end-to-end latency metrics
rbuilder now includes additional e2e latency Prometheus metrics.
Here’s an screenshot of p99 e2e latency over a couple of days:
Prometheus metrics can be sent to multiple endpoints
The v1.3 release supports multi-endpoint support for Prometheus metrics, allowing builder nodes to send monitoring data to multiple destinations simultaneously.
rbuilder on/off switch to simplify deployments
The rbuilder on/off switch feature introduces a new configuration option that allows operators to safely control the builder's participation in block building. This switch can be toggled without requiring a full restart, making it particularly useful during maintenance windows, upgrades, or when troubleshooting issues.
When turned off, the rbuilder gracefully stops accepting new bundles and participating in block building, while maintaining its connection to the network. This enables smooth transitions during deployments and provides an additional safety mechanism for operators.
Configurable merging algorithms
This release enables the dynamic configuration of merging algorithms, instead of requiring a new BuilderNet version release to change them.
Local devnet environment support
BuilderNet release images are now capable of running in a local devnet mode. This allows developers to test and develop locally without needing to deploy on the main BuilderNet network. Specifially noteworthy improvements include:
- BuilderNet playground codebase which integrates BuilderNet images with Builder Playground (this is an alpha state and work-in-progress)
- TDX VM images in qcow2 format, which can be used to run locally in QEMU.
- Configurable BuilderHub URL for image builds.
The local devnet is based on this Builder Playground PR: https://github.com/flashbots/builder-playground/pull/101
We are actively working on the local devnet and expect to have more news around this soon.
Versions
The reproducible build toolchain for BuilderNet v1.3 is based on [email protected] (commit 05638f3).
| Project | New Version | Commit |
|---|---|---|
| rbuilder-operator | v1.0.1 (prev v0.1.5) | 43b7902 |
| orderflow-proxy | v0.3.3 (prev v0.2.6) | 7c84264 |
| CVM Proxy | v0.1.6 (prev: v0.1.0) | 8e5c9a1 |
| Operator API | no change, still v0.7.0 | a8296e4 |
| Reth | no change, still v1.0.8 | |
| Lighthouse | no change, still v5.3.0 | |
| HAProxy | no change, still v3.0.6 |
Changes & Pull Requests
| Project | Changes |
|---|---|
| rbuilder / rbuilder-operator | v0.1.5...v1.0.1 (83 PRs) |
| orderflow-proxy | v0.2.6...v0.3.3 (24 PRs) |
| cvm-reverse-proxy | v0.1.0...v0.1.6 (13 PRs) |
Services Configuration
| Service | Configuration |
|---|---|
| Operator API | meta-confidential-compute@d8bcb39 |
| HAProxy | meta-evm@bd51f7e |
| Lighthouse | meta-evm@bd51f7e |
| Orderflow Proxy | meta-evm@bd51f7e |
| Rbuilder | meta-evm@bd51f7e |
| Reth | meta-evm@bd51f7e |
Artifacts
Signed artifacts are stored at https://builder-artifacts.flashbots.net/buildernet-images/.
The specific TDX VM image for the BuilderNet v1.3 release is buildernet-v1.3.0-azure-tdx-d17a02695c1acc0800aff80e86efbe0e5919843184e6562d8d572894ab43d149
Measurements
These are the new live measurements for BuilderNet v1.3.0:
{
"measurement_id": "buildernet-v1.3.0-azure-tdx-d17a02695c1acc0800aff80e86efbe0e5919843184e6562d8d572894ab43d149.wic.vhd",
"attestation_type": "azure-tdx",
"measurements": {
"4": {
"expected": "966f0aa4b6f6952e601712cfe78f71a6ae61467a425a92d0800c754e98933d78"
},
"9": {
"expected": "af03ec5b7f02f5b9779f04bc837b8cbbf85d5b0386d5f387d8b99e8f0d9a1fa4"
},
"11": {
"expected": "3aede0e78b33f4197175b73468be54f168a46719c063b7c4f27c10984e614b38"
}
}
}
Reproducible Builds
BuilderNet v1.3 supports fully reproducible TDX image builds. The image you build will produce the exact same TDX measurements as our reference builds.
The main entry point for the image builds is the flashbots/yocto-manifests repository, and for this release specifically the [email protected] (commit 05638f3).
To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman:
git clone https://github.com/flashbots/yocto-manifests.git
cd yocto-manifests
git checkout v1.3.0
make image-buildernet
You can confirm that the hash of your build matches the expected one:
make measurements-buildernet
Build host specs:
- Ubuntu 22.04 x64 (Linux kernel 6.8.0-49-generic), fully updated system
- Intel Xeon Gold 6312U, 48vCPUs, 512GB memory
Join the conversation on the BuilderNet forum and the BuilderNet Telegram group!