When Hyperledger Besu parallel transaction execution is worth enabling
Parallel transaction execution is an optional Besu feature that executes a block's transactions in the background, on the optimistic assumption that they do not conflict. It requires the Bonsai storage format, so a node still on another storage layout cannot use it. If your private network has block processing that falls behind during busy periods, this is the first setting to evaluate, but only after confirming that your nodes already run Bonsai and that your team can test the change before it reaches production validators.
The benefit depends on how much your transactions touch the same accounts and storage slots, not on how many nodes the network has. When transactions are largely independent, background execution finds few conflicts and the node finishes blocks sooner. When many transactions read or write the same contract state, such as a shared balance or a popular token contract, conflicts force replays and the gain shrinks. Before enabling anything, measure block processing time and identify which contracts dominate your traffic. Adding validators or nodes will not address that bottleneck.
The PERFORMANCE configuration profile enables parallel transaction execution, so the profile is the simplest route to the setting, but it also changes other defaults. Review the Besu configuration profiles documentation against your existing configuration file before adopting it, and confirm with your platform team which values will override yours. Plan a rollback path, because switching storage formats or upgrading Bonsai data is not reversible without a backup taken beforehand.
Configuration options and when each fits
This table compares the default configuration, enabling parallel execution directly, and enabling it through the PERFORMANCE profile. Read each row against your storage format and your node's workload, since the profile changes more than this one setting.
| Option | What it changes | What it requires | When it fits |
|---|---|---|---|
| Default configuration | Transactions in a block run sequentially. Parallel execution stays off. | Nothing beyond your existing node configuration. Storage format can remain as it is. | Low transaction volume, or a node where you have not yet measured execution time as a constraint. |
| Parallel execution setting | Turns on optimistic background execution of a block's transactions. Conflicting results are replayed using cached background reads. | Bonsai storage format. Confirm your node runs Bonsai before enabling it, since the feature is optional and depends on it. | A busy private network where block execution time is the measured bottleneck and you can test the change on a non-production node first. |
| PERFORMANCE profile | Enables parallel transaction execution and changes other node settings that come with the profile. | Bonsai storage format, and a review of the full profile output against your own configuration file. | Teams that want the bundled tuning and accept the extra settings after reviewing them. Not suited to nodes with local overrides you must keep. |
| Bonsai storage format | Sets the world state format that parallel execution depends on for conflict detection. | Node migration to Bonsai. Confirm the upgrade steps and rollback needs for your Besu version before changing format. | Any node where you plan to test parallel execution. Forest is not the format this feature is documented against. |
| Conflict-heavy contract workloads | Many transactions touch the same accounts or storage slots, so background results are replayed more often. | Monitoring of block execution behavior before and after enabling the feature. | Likely to gain little. Test with your own transaction mix, since replays can offset the benefit. |
| Independent transfer or contract workloads | Transactions touch disjoint accounts and slots, so background results rarely conflict. | Representative load data from your network to confirm the benefit. | Most likely to benefit from parallel execution on a busy private network. Validate with your own traffic. |
| Change control for profile use | Profile values replace or adjust settings across the node, including ones you may have tuned for other purposes. | Written review of the profile output, a diff against your current configuration, and a documented rollback path. | Teams with change-controlled node configurations should always prefer an explicit, reviewed setting over an unreviewed profile. |
Where parallel execution helps and where it adds little
Parallel execution pays off only when a block's transactions rarely touch the same state and the node is spending its time executing rather than reading or syncing data. The cards below cover the checks that decide whether enabling it on a busy private network is worth the change.
Transaction overlap on hot accounts
Parallel execution assumes transactions in a block do not conflict. If most traffic hits one token contract, one settlement account or one shared counter, nearly every background result will conflict and need replay. Before enabling it, sample recent blocks and measure how many transactions write to the same addresses and storage slots. Ask your application team which contracts sit on the hot path, because a few popular contracts can cancel out the benefit for the whole block.
Bonsai storage requirement
Parallel execution requires the Bonsai storage format, so a node still on Forest cannot use it without a storage change. Confirm the current storage format on every node, not only on the validators you monitor. Moving to Bonsai is a planned change with its own disk and sync effects, and the release notes for the version you run should be read before the switch. Note that the Bonsai database upgrades automatically on first start, and older versions cannot open it afterward.
Replay cost under frequent conflicts
When a background result conflicts with earlier transactions, Besu replays the transaction using a cache of background reads. This keeps results correct, but a block full of conflicts can cost more than sequential execution would have. Measure replay frequency on a test node under realistic load before you roll it out. Look for a conflict rate that stays low across peak periods, not only average load, since replay cost rises exactly when blocks are fullest.
Consensus and block time limits
Permissioned networks often run QBFT with a fixed block period, so execution has a deadline. Parallel execution helps only if it finishes within that window on every validator. Check the block time you have configured and the gas used per block at peak. If validators regularly approach the block period, a faster execution path may matter more than any other tuning, but a slow replay path can make that worse.
Execution or disk and sync bottleneck
Parallel execution speeds up the execution step only. If a node is slow because of disk latency, state growth or initial sync, enabling it changes little. Profile where time goes using node metrics before deciding. Check disk I/O wait, database read latency and sync progress. A node limited by storage will need volume, cache or storage format work first, and that work should be scoped separately from the execution change.
Profile and rollout verification
The PERFORMANCE configuration profile enables parallel execution, so the setting arrives with other changes. Review what else the profile changes against your current configuration file before applying it. Roll out to one non-validator node first, compare block import times, conflict and replay counts, and resource use against a baseline, then extend to validators in a planned window with a tested rollback path.
How to enable and verify parallel execution on a private node
This sequence confirms that a node can run parallel execution, enables it on a test node, and checks the result in logs and metrics before any validator changes. The output is a documented, reversible rollout decision backed by evidence from your own node.
Confirm the storage format and Besu version
Check that the node uses the Bonsai storage format, since parallel transaction execution requires it and is optional. Confirm the Besu version on the node supports the feature and the JDK it needs (Besu 26.6.0 requires JDK 25 to build and run). Record the current version, storage format and data directory location so the change can be compared and reversed. Done when you have a written record of both values for every node in the test group.
Back up the node data before any upgrade
If the node is on an older Bonsai database, or the target Besu version will upgrade it, take a full backup first. The Besu 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and that older Besu versions cannot open an upgraded database, so a rollback depends entirely on this backup. Store it on a separate volume and confirm it can be restored. Done when a restore has been tested on a scratch host, not just when the copy finishes.
Upgrade the test node and start it
Upgrade a single non-validator test node to the chosen Besu version and let it start once so the Bonsai database upgrades. Watch the startup logs for database migration messages and for errors that would block sync. Confirm the node reaches the chain head and keeps pace with the network. Done when the node is syncing normally and no migration errors remain in the logs.
Enable parallel execution on the test node
Turn on parallel transaction execution in the test node configuration, either directly or through the PERFORMANCE configuration profile, which enables it according to Besu's profile documentation. Change only this setting in the first test so any difference in behavior can be attributed to it. Restart the node and confirm the setting is active in the startup output. Done when the node starts with the option on and you have a recorded configuration diff against the baseline.
Verify behavior with logs and metrics
Compare the test node against an unchanged baseline node on the same network for a representative period of block processing. Review logs for replayed transactions caused by conflicts, and review Prometheus metrics for block import time and sync lag. Check that state roots and block hashes match the baseline, which confirms correctness. Done when the test node shows matching chain state and the timing data supports or does not support the change for your transaction pattern.
Roll out to validators in stages
Apply the change to validator nodes one at a time, only after the test node results are accepted and the rollback path is documented. Keep quorum intact during each restart, and confirm the validator rejoins block production before moving to the next node. Keep the pre-upgrade backup until the change has run under normal load. Done when every validator runs the same configuration and version, and monitoring shows no new import errors or consensus stalls.
Rolling out parallel execution across validators and RPC nodes
Enabling parallel execution is a per-node change, so the rollout plan has to account for the fact that a private network runs several node roles at once. Validators, RPC nodes serving applications, and any archive or observer nodes may not share one configuration, and a single node running a different execution setting can behave differently under load than its peers. Before the first change, write down which nodes run which role, which ones serve your application traffic, and which ones an operator would touch first if something went wrong. Confirm the exact setting for your Besu version in the Besu parallel transaction execution documentation and the profile behavior in the configuration profiles documentation before you write it into any node's configuration.
Stage the change on non-validator nodes first, starting with a single RPC node that carries representative read traffic, and keep validators on their current settings until the RPC node has run through normal and peak periods without unexplained block import delays or replay behavior you cannot explain. Validators are where consensus happens, so treat them as the last step and change them one at a time, checking that each one keeps producing and importing blocks before moving to the next. Keep a record of which node runs which configuration at every stage, because mixed settings across a QBFT validator set are the main source of confusion during a rollout.
The rollback constraint shapes the whole plan. Besu upgrades the Bonsai database automatically on first start, and older Besu versions cannot open an upgraded database, so reverting a binary alone may not return a node to service. Take a backup of each node's data directory before the upgrade that accompanies the change, and confirm that you can restore it in a test environment. Use the release notes for the version you deploy, such as the 26.10.0 notes, to check the upgrade behavior, and record the exact recovery procedure in your runbook so that the on-call engineer does not have to reconstruct it under pressure.
Security and operational considerations
Parallel execution changes how a node processes blocks and depends on the Bonsai storage format, so the risks sit in upgrades, monitoring and release management. The cards below cover what to protect before change, what to watch after it, and where to test first.
Back up before the Bonsai upgrade
Enabling parallel execution requires Bonsai, and the Bonsai database upgrades automatically on first start. Older Besu versions cannot open an upgraded database, so a rollback depends entirely on a backup taken before that first start. Confirm that the backup is restorable on the same Besu version and that you have a tested procedure to return to the prior build. Keep the backup separate from the live data directory.
Watch block processing time
Parallel execution is meant to shorten block processing on a busy network, so you need a baseline to judge whether it helps. Enable metrics with --metrics-enabled and graph block processing time in Prometheus before and after the change. Compare the same workload and block period, because a quiet network can hide a regression. Alert on sustained increases rather than single slow blocks.
Keep JDK 25 in view
Besu 26.6.0 requires JDK 25 to build and run. Check the JDK version against the Besu release you plan to deploy, including build agents, container base images and host runtimes. A JDK mismatch can block a node from starting during a routine rollout, which may look like a parallel execution fault. Record the JDK version alongside each node's Besu version in your change records.
Test changes outside production
Turn on parallel execution first on a non-production node that syncs the same chain data and runs realistic transaction load. Test the Bonsai upgrade, the rollback from backup, and the metrics dashboards in that environment before touching validators. Confirm that the node keeps pace with the network and produces the same state roots as its peers. Only then move the setting to production nodes one at a time.
Track releases and removed features
Besu ships calendar releases roughly monthly, and the project has removed features in recent versions, including Clique consensus in 26.4.0. Parallel execution settings can change with later releases, so review the release notes before each upgrade. Confirm that your configuration profile and options still exist in the version you run. Treat a configuration you copied from an older example as untested until you verify it.
Questions teams ask before enabling parallel execution
What drives the cost of enabling parallel transaction execution in Besu?
The cost depends mostly on the state of your existing nodes, not on the feature switch itself. Enabling parallel execution is optional and is set through configuration, but it only works when the node uses the Bonsai storage format, so the main cost is any storage migration plus testing. Costs rise with the number of nodes, the number of environments you must validate, and how much change control your organization requires. Ask any partner for a quote that separates one-time work (assessment, configuration, load testing, runbook updates) from recurring work (monitoring, upgrades on the monthly release cadence, and periodic re-testing).
How long does it take to enable parallel execution on a private network?
The timeline depends on how many nodes run Bonsai already, how large your state is, and how formal your change process is. The configuration change itself is small, but each node must be verified under realistic transaction load before you rely on it. Ask the team doing the work to show a written sequence covering a non-production rollout, a measured comparison window, and a rollback path. Any duration in a proposal should be tied to that sequence and to your own environment, since no general figure applies across networks.
Does enabling parallel execution require a migration to Bonsai first?
Yes. Parallel transaction execution requires the Bonsai storage format, so a node still on another storage format must move to Bonsai before the option has any effect. Before you start, confirm the Besu version you run, because the Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and older Besu versions cannot open that upgraded database. Take a backup of the data directory before the upgrade so that rollback is possible, and test the restore path on a copy first.
What does the team need to provide before the work starts?
Plan for three inputs: a representative picture of transaction traffic, access to the nodes and their configuration files, and a named owner who can approve changes. Traffic data should show block fullness, transaction mix, and whether transactions frequently touch the same contracts or accounts, because that determines how often conflicts and replays occur. The owner should accept the maintenance window, the rollback criteria, and the monitoring plan. Ask the partner to list these inputs in the written scope so that gaps surface before any node is changed.
Can our own team enable parallel execution without an outside partner?
Yes, if your team already operates Besu nodes, understands the Bonsai migration, and can run a controlled load test with rollback. The configuration option is documented in the Besu profile and parallel execution references, so the technical change is not the hard part. The harder work is proving benefit on your traffic, setting alerts, and documenting the procedure for auditors and operators. If that skill set is missing, a fixed-scope engagement can cover the assessment and runbook while your team keeps ownership of the network.
How do we measure whether parallel execution actually helps our network?
Measure before and after on the same nodes and similar traffic. Record block processing time, transaction throughput, and the number of blocks where sync or import falls behind, and watch for signs that replays are frequent, since replays occur when background results conflict with earlier transactions. Metrics can be exported to Prometheus with the metrics option, which defaults to port 9545, and visualized in Grafana. A private network with light or sequential traffic may show little gain, so define the success criteria in writing before the test starts.
What could go wrong after we turn it on?
The main risks are an upgrade that cannot be rolled back without a backup, nodes that run different storage formats in the same network, and a performance change that is hard to attribute without baseline data. Test each Besu upgrade against a copy of your data before you apply it to production nodes, and confirm that every node in the network uses a compatible configuration. Keep the configuration file under version control so that any change can be traced and reverted quickly.
How DeployOpen scopes and supports Besu performance changes
DeployOpen plans and implements Besu nodes inside your own infrastructure, so a decision on parallel transaction execution is made against your measured load, storage format and upgrade path. Each engagement starts with a written scope, then moves through build, handover and optional ongoing support.
How we scope
- Review your current node storage format and confirm whether Bonsai is in use before any parallel execution change is proposed
- Record block processing times and transaction volume on the nodes that would enable the PERFORMANCE profile
- Agree in writing which nodes, environments and Besu versions the change covers, and what is excluded
How we build
- Apply the profile change to a staging copy of your network first, with configuration kept under version control
- Test transaction flows that touch shared contract state, and check replay behavior against your expected workloads
- Confirm the Bonsai database upgrade path and take a verified backup before any node is changed in production
How we hand over
- Deliver a configuration record showing the profile setting, Besu version, storage format and any rollback steps
- Document the metrics your team should watch to spot rising block processing time or unexpected replay activity
- Walk your operators through the rollback procedure and the conditions under which the change should be reverted
How we support
- Offer ongoing support as a retainer, covering reviews of each Besu release before your nodes are upgraded
- Re-test parallel execution settings after client upgrades or changes in transaction patterns on your network
- Ask your DeployOpen contact to confirm retainer terms and response arrangements in the written scope
