Hyperledger Besu Clique networks after Clique was removed in 26.4

The short answer is that a node running Besu 26.4.0 or later cannot start on a pure Clique network, and it cannot produce blocks there either. Clique is the proof-of-authority consensus that signs each block with an authorized signer's key and records the signer set in the chain's genesis and in the epoch and voting data stored in block headers. Besu 26.4.0 removed that consensus engine, so the new client has no code path that validates existing Clique blocks or continues signing new ones. The release notes are the authority on the exact startup error, so confirm the behaviour there rather than relying on this summary.

The practical problem is that the chain's history stays in the database. An upgraded node has to read that history to sync and to verify state, and it cannot interpret Clique blocks, so the node does not get to a working state on the existing chain. Nothing in the supplied release information documents an in-place conversion of a live Clique chain to QBFT, so you should not plan on one. Before any production node is upgraded, run the target Besu version against a copy of your chain data in a non-production environment, record exactly what happens on start, and keep a backup of the data directory so you can return to a Besu release that still runs Clique.

Moving off Clique leaves more to rebuild than the chain. Start with the node and validator keys. Besu documents that the local node private key file is not encrypted. If your policy requires hardware-backed key storage, plan a security module plugin such as the Besu HSM plugin, enabled with the --security-module option, and confirm with the plugin's maintainers that it supports the key types and signing flow your validators will use on the new QBFT network. Decide before cutover whether new validator keys are generated, whether existing node keys carry over, and who holds the key material during the move. Those decisions change the backup and recovery steps you write later.

Next, rebuild the permissioning files for each node. Besu's local permissioning uses a node permissions configuration for connections to known participants and an account permissioning configuration for onboarding rules, suspended accounts and restricted actions. Clique networks often relied on a small, informal peer list, so the allowlists for the new network should be written from a fresh membership record, not copied from old node files. Reconfirm the JSON-RPC surface as well. Besu supports either a username and password credentials file or JWTs validated against a public key, and it does not terminate HTTPS natively. Your reverse proxy or gateway must provide TLS, and each calling application needs a credential or token it can present.

Finally, build the inventory of applications that call the RPC, and the monitoring that will watch the new network. Ask each application owner which methods they use, which node they connect to, how they authenticate and what happens when that node is down. Metrics are exposed for Prometheus with --metrics-enabled on the default port 9545, so confirm that scrape targets, alert rules and dashboards exist for every validator before go-live. The reader must provide this inventory with named owners and written approvals for each integration change, and a signed list of keys, permission entries and credentials that the network team will issue. Without that list, the migration cannot be scoped or quoted.

A written scope for leaving Clique should start by naming every system the move touches: each Besu node and its host, the validator and non-validator roles, the genesis file and any chain configuration files, the permissions configuration files, the JSON-RPC consumers that depend on the current endpoints, and the monitoring and key storage around each node. The scope should also state which Besu release each node will run after the move. Because Besu 26.4.0 removed Clique and the network cannot be restarted on pure Clique, the target design is not optional, so the document must name the consensus target (a QBFT network) and the genesis settings that define it. Ask the implementation partner to list what is out of scope too, such as application changes, smart contract changes or data migration of historical state, so that nothing is assumed to be included. The client should confirm the validator and node counts in writing before any work starts. The scope should list each validator by operator and host, the number of non-validator nodes, and the fault tolerance the chosen validator count gives. It should also record how validator keys are stored today and how they will be stored after the move, including whether an HSM or the security module option will be used, since the local node private key file is not encrypted by default. Acceptance tests belong in the scope as numbered checks with a pass condition for each: all nodes start on the target release, the chain produces blocks under the new consensus, every expected peer connects, transactions submit and finalize from each API consumer, metrics reach the monitoring stack, and a restored backup starts cleanly. The scope must include a rollback plan with a named backup point. The Besu 26.10.0 release notes state that an upgraded Bonsai database cannot be opened by older Besu versions, so a backup taken before the upgrade is the only route back, and the scope should say who takes it, where it is stored and how restoration is tested. Finally, the document should list what the reader provides: access to hosts and cloud or data center accounts, the change window, named operator contacts for each validator, approval authority for the cutover, and the existing configuration files. DeployOpen works through a fixed-scope written agreement agreed before work starts and does not publish a price list, so a quote follows from this written scope. Ask for that agreement to state deliverables, acceptance criteria and timelines, and to show which items would change the price if the environment differs from what was described.