\"\n}"
- }
- ]
- },
- {
- "name": "web3_sha3",
- "request": {
- "method": "POST",
- "header": [],
- "body": {
- "mode": "raw",
- "raw": "{\n \"jsonrpc\": \"2.0\",\n \"method\": \"web3_sha3\",\n \"params\": [\n \"0x68656c6c6f20776f726c00\"\n ],\n \"id\": 1\n}",
- "options": {
- "raw": {
- "language": "json"
- }
- }
- },
- "url": {
- "raw": "http://{{rpc-http-host}}:{{rpc-http-port}}",
- "protocol": "http",
- "host": ["{{rpc-http-host}}"],
- "port": "{{rpc-http-port}}"
- },
- "description": "Returns a [SHA3](https://en.wikipedia.org/wiki/SHA-3) hash of the specified data. The result value\nis a [Keccak-256](https://keccak.team/keccak.html) hash, not the standardized SHA3-256.\n\n#### Parameters\n\n`DATA` - Data to convert to a SHA3 hash.\n\n#### Returns\n\n`result` (*DATA*) - SHA3 result of the input data."
- },
- "response": [
- {
- "name": "web3_sha3",
- "originalRequest": {
- "method": "POST",
- "header": [],
- "body": {
- "mode": "raw",
- "raw": "{\n \"jsonrpc\": \"2.0\",\n \"method\": \"web3_sha3\",\n \"params\": [\n \"0x68656c6c6f20776f726c00\"\n ],\n \"id\": 1\n}",
- "options": {
- "raw": {
- "language": "json"
- }
- }
- },
- "url": {
- "raw": "http://{{rpc-http-host}}:{{rpc-http-port}}",
- "protocol": "http",
- "host": ["{{rpc-http-host}}"],
- "port": "{{rpc-http-port}}"
- }
- },
- "code": 200,
- "_postman_previewlanguage": "json",
- "header": null,
- "cookie": [],
- "body": "{\n \"jsonrpc\": \"2.0\",\n \"id\": 53,\n \"result\": \"0x5e39a0a66544c0668bde22d61c47a8710000ece931f13b84d3b2feb44ec96d3f\"\n}"
- }
- ]
- }
- ]
- }
- ],
- "event": [
- {
- "listen": "prerequest",
- "script": {
- "type": "text/javascript",
- "exec": [""]
- }
- },
- {
- "listen": "test",
- "script": {
- "type": "text/javascript",
- "exec": [""]
- }
- }
- ]
-}
diff --git a/versioned_docs/version-23.10.0/global/postman.md b/versioned_docs/version-23.10.0/global/postman.md
deleted file mode 100644
index a9afe58649b..00000000000
--- a/versioned_docs/version-23.10.0/global/postman.md
+++ /dev/null
@@ -1,15 +0,0 @@
-:::info Besu JSON-RPC APIs documentation in Postman format
-
-View the [Besu JSON-RPC APIs documentation](https://www.postman.com/hyperledger/workspace/hyperledger-besu/collection/11610746-f334929f-c8c3-43ed-bb73-69a6f0d728d8) in the Postman format and obtain example requests in multiple coding languages.
-
-#### Run in Postman
-
-Click the following button to fork the collection and run requests directly on your local network.
-
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://god.gw.postman.com/run-collection/11610746-f334929f-c8c3-43ed-bb73-69a6f0d728d8?action=collection%2Ffork&collection-url=entityId%3D11610746-f334929f-c8c3-43ed-bb73-69a6f0d728d8%26entityType%3Dcollection%26workspaceId%3Dc4b60b6f-9f15-42d0-8327-7ebabca6f0fd#?env%5BBesu%20node%20on%20local%20host%5D=W3sia2V5IjoicnBjLWh0dHAtaG9zdCIsInZhbHVlIjoibG9jYWxob3N0IiwiZW5hYmxlZCI6ZmFsc2V9LHsia2V5IjoicnBjLWh0dHAtcG9ydCIsInZhbHVlIjoiODU0NSIsImVuYWJsZWQiOmZhbHNlfV0=).
-
-#### Download collection
-
-Alternatively you can [download the JSON collection file](../assets/postman/postman_collection.json).
-
-:::
diff --git a/versioned_docs/version-23.10.0/global/test_accounts.md b/versioned_docs/version-23.10.0/global/test_accounts.md
deleted file mode 100644
index ae819b23ed3..00000000000
--- a/versioned_docs/version-23.10.0/global/test_accounts.md
+++ /dev/null
@@ -1,51 +0,0 @@
-:::danger **Do not use the test accounts on Ethereum Mainnet or any production network.**
-
-The following accounts are test accounts and their private keys are publicly visible in this documentation and in publicly available source code.
-
-They are not secure and everyone can use them.
-
-**Using test accounts on Ethereum Mainnet and production networks can lead to loss of funds and identity fraud.**
-
-In this documentation, we only provide test accounts for ease of testing and learning purposes; never use them for other purposes.
-
-**Always secure your Ethereum Mainnet and any production account properly.**
-
-See for instance [MyCrypto "Protecting Yourself and Your Funds" guide](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds).
-
-:::
-
-:::info "Test Account 1 (address `0xfe3b557e8fb62b89f4916b721be55ceb828dbd73`)"
-
-Private key to copy :
-
-```text
-0x8f2a55949038a9610f50fb23b5883af3b4ecb3c3bb792cbcefbd1542c692be63
-```
-
-Initial balance : 200 Eth _(200000000000000000000 Wei)_
-
-:::
-
-:::info "Test Account 2 (address `0x627306090abaB3A6e1400e9345bC60c78a8BEf57`)"
-
-Private key to copy :
-
-```text
-0xc87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3
-```
-
-Initial balance : 90000 Eth _(90000000000000000000000 Wei)_
-
-:::
-
-:::info "Test Account 3 (address `0xf17f52151EbEF6C7334FAD080c5704D77216b732`)"
-
-Private key to copy :
-
-```text
-0xae6ae8e5ccbfb04590405997ee2d52d2b330726137b875053c36d94e974d162f
-```
-
-Initial balance : 90000 Eth _(90000000000000000000000 Wei)_
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/_category_.json b/versioned_docs/version-23.10.0/private-networks/_category_.json
deleted file mode 100644
index 865a111a8b4..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Private networks",
- "position": 1
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/_category_.json b/versioned_docs/version-23.10.0/private-networks/concepts/_category_.json
deleted file mode 100644
index d373a29254a..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Concepts",
- "position": 4
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/index.md b/versioned_docs/version-23.10.0/private-networks/concepts/index.md
deleted file mode 100644
index efffe0e3a05..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/index.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Concepts
-description: private networks concepts overview
-sidebar_position: 3
-tags:
- - private networks
----
-
-# Concepts
-
-This section provides background information and context about private network features.
-
-The following features are shared with [public networks](../../public-networks/index.md) and the content can be found in the public networks section:
-
-- Transactions:
- - [Transaction types](../../public-networks/concepts/transactions/types.md)
- - [Transaction pool](../../public-networks/concepts/transactions/pool.md)
- - [Transaction validation](../../public-networks/concepts/transactions/validation.md)
-- [Network ID and chain ID](../../public-networks/concepts/network-and-chain-id.md)
-- [Events and logs](../../public-networks/concepts/events-and-logs.md)
-- [Genesis file](../../public-networks/concepts/genesis-file.md)
-- [Node keys](../../public-networks/concepts/node-keys.md)
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/_category_.json b/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/_category_.json
deleted file mode 100644
index 7299170da97..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Permissioning",
- "position": 3
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/index.md b/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/index.md
deleted file mode 100644
index ad3678f68fd..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/index.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Permissioning
-sidebar_position: 1
-description: Besu permissioning feature
-tags:
- - private networks
----
-
-# Permissioning
-
-A permissioned network enables node permissioning and account permissioning, allowing only specified nodes and accounts to access the network.
-
-:::caution Permissioning is not privacy
-
-In peer-to-peer networks, node permissioning enforces rules on nodes you control.
-
-Permissioning requires a distributed network of trust across the network where participants agree to follow the rules. One bad actor can decide not to follow the rules. Nodes can take action to prevent the bad actor adding to the chain but they cannot prevent the bad actor from allowing access to the chain.
-
-Besu also implements [privacy](../privacy/index.md).
-
-:::
-
-## Node permissioning
-
-Use node permissioning to restrict access to known participants only.
-
-![Node Permissioning](../../../assets/images/node-permissioning-bad-actor.png)
-
-## Account permissioning
-
-Use account permissioning to:
-
-- Enforce onboarding or identity requirements.
-- Suspend accounts.
-- Restrict the actions an account can perform.
-
-![Account Permissioning](../../../assets/images/enterprise-ethereum-account-permissioning.png)
-
-## Specify permissioning
-
-You can specify permissioning [locally](#local) or [onchain](#onchain).
-
-### Local
-
-[Local permissioning](../../how-to/use-permissioning/local.md) works at the node level. Each node in the network has a [permissions configuration file].
-
-Local permissioning affects your node but not the rest of the network. Use local permissioning to restrict use of your node (that is, the resources under your control). For example, customers able to access your node.
-
-Local permissioning does not require coordination with the rest of the network and you can act immediately to protect your node. Your rules are not enforced in blocks produced by other nodes.
-
-### Onchain
-
-[Onchain permissioning](onchain.md) works through a smart contract on the network. Specifying permissioning onchain enables all nodes to read and update permissioning configuration from one location.
-
-Onchain permissioning requires coordination to update the rules. The network might not be able to act immediately (for example, the smart contract might enforce a minimum of number of votes before changing permissioning rules).
-
-When you update onchain permissioning, the update applies across the network and new blocks abide by the updated rules. For example, blocked accounts can no longer add transactions to the chain.
-
-The following diagram illustrates applying local and onchain permissioning rules.
-
-![Permissioning Flow](../../../assets/images/PermissioningFlow.png)
-
-
-
-[permissions configuration file]: ../../how-to/use-permissioning/local.md#permissions-configuration-file
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/onchain.md b/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/onchain.md
deleted file mode 100644
index 908a3418f9b..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/onchain.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Onchain permissioning
-description: Onchain permissioning
-sidebar_position: 1
-tags:
- - private networks
----
-
-# Onchain permissioning
-
-Onchain [permissioning](index.md) uses smart contracts to store and administer the node, account, and admin allowlists. Using onchain permissioning enables all nodes to read the allowlists from a single source, the blockchain.
-
-:::danger
-
-When using onchain account permissioning, a node checks permissions when importing blocks. Meaning, a node only imports blocks in which all transactions are from authorized senders. If you disable onchain account permissioning and your node accepts blocks without enforcing this rule, your node cannot re-synchronize with other nodes that enforce onchain account permissioning rules (your node goes into forked state).
-
-:::
-
-:::note
-
-Custom smart contracts and dapps can be implemented to work with onchain permissioning.
-
-:::
-
-## Permissioning contracts
-
-:::caution
-
-The permissioning contract has multiple interfaces, and each interface maps to a specific version of the [Enterprise Ethereum Alliance Client Specification](https://entethalliance.org/technical-specifications/). Ensure that you [specify the permissioning contract interface] being used when starting Besu.
-
-:::
-
-### Allowlists
-
-Permissioning implements three allowlists:
-
-- Accounts, which can submit transactions to the network.
-- Nodes, which can join the network.
-- Admins, which are accounts able to update the accounts and nodes allowlists.
-
-:::caution Using account permissioning and privacy
-
-Account permissioning is incompatible with [random key signing](../../how-to/use-privacy/sign-pmts.md) for [privacy marker transactions](../privacy/private-transactions/processing.md).
-
-If using account permissioning and privacy, a signing key must be specified using the [`--privacy-marker-transaction-signing-key-file`](../../reference/cli/options.md#privacy-marker-transaction-signing-key-file) command line option and the corresponding public key included in the accounts allowlist.
-
-:::
-
-:::tip
-
-If nodes are not connecting as expected, set the [log level to `TRACE`](../../../public-networks/reference/cli/options.md#logging) and search for messages containing `Node permissioning` to identify the issue.
-
-Ensure the [`--p2p-host`](../../../public-networks/reference/cli/options.md#p2p-host) command line option has been correctly configured for all nodes with the externally accessible address.
-
-If you change your network configuration, you may need to update the node allowlist.
-
-:::
-
-## Bootnodes
-
-When a node joins the network, the node connects to the [bootnodes](../../how-to/configure/bootnodes.md) until it synchronizes to the chain head, regardless of node permissions. After synchronization, the Account Rules and Node Rules smart contracts apply the permissioning rules.
-
-If a synchronized node loses all peer connections (that is, it has zero peers), it reconnects to the bootnodes to rediscover peers.
-
-:::info
-
-All bootnodes must be on the nodes allowlist.
-
-:::
-
-
-
-[specify the permissioning contract interface]: ../../how-to/use-permissioning/onchain.md#specify-the-permissioning-contract-interface-version
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/plugin.md b/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/plugin.md
deleted file mode 100644
index a4f62031d8b..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/permissioning/plugin.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Permissioning plugin
-description: Plugin based permissioning
-sidebar_position: 2
-tags:
- - private networks
----
-
-# Permissioning plugin
-
-You can define complex [permissioning](index.md) solutions by building a plugin that extends Hyperledger Besu functionality.
-
-The plugin API provides a `PermissioningService` interface that currently supports connection permissioning and message permissioning.
-
-## Connection permissioning
-
-Use connection permissioning when deciding whether to restrict node access to known participants only.
-
-## Message permissioning
-
-Use message permissioning to propagate different types of devP2P messages to particular nodes. For example, this can be used to prevent pending transactions from being forwarded to other nodes.
-
-## Register your plugin
-
-To enable permissioning in your plugin, implement the `PermissioningService` interface and register your providers.
-
-```java
-@AutoService(BesuPlugin.class)
-public class TestPermissioningPlugin implements BesuPlugin {
- PermissioningService service;
-
- @Override
- public void register(final BesuContext context) {
- service = context.getService(PermissioningService.class).get();
- }
-
- @Override
- public void start() {
- service.registerNodePermissioningProvider((sourceEnode, destinationEnode) -> {
- // perform logic for node permissioning
- return true;
- });
-
- service.registerNodeMessagePermissioningProvider((destinationEnode, code) -> {
- // perform logic for message permissioning
- return true;
- });
- }
-
- @Override
- public void stop() {}
-}
-```
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/pki.md b/versioned_docs/version-23.10.0/private-networks/concepts/pki.md
deleted file mode 100644
index 97cec02eab0..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/pki.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: Public key infrastructure
-sidebar_position: 5
-description: Public key infrastructure
-tags:
- - private networks
----
-
-# Public key infrastructure
-
-:::warning
-
-Public key infrastructure (PKI) support is an early access feature, and functionality and options may be updated between releases.
-
-:::
-
-Hyperledger Besu's public key infrastructure allows you to use certificates issued by a trusted authority to manage node and account identities in the following ways:
-
-- Node permissioning - Only authorized nodes can connect to other nodes in the network using TLS for the P2P communication.
-- Block proposal permissioning - Only blocks proposed by authorized validators are accepted.
-
-Supported keystore and truststore formats used to store the certificates include PKCS11, PKCS12, and JKS.
-
-## Node permissioning
-
-Allow TLS communication between nodes by using certificates issued by a trusted authority to connect to other authorized nodes in the network.
-
-When receiving connection requests, the incoming connection must be from another authorized node. Similarly, when connecting to a node the initiator ensures that the remote node is authorized to participate in the network.
-
-[Configure TLS for the P2P communication using the Besu command line options](../how-to/configure/tls/p2p.md).
-
-## Block proposal permissioning
-
-:::caution
-
-Only private networks using the [QBFT consensus protocol] support block proposal permissioning.
-
-:::
-
-Use certificates issued by a trusted authority to ensure only authorized validator nodes can propose new blocks in the network. The block hash is signed by the validator private certificate and included in the header of the proposed block as a [CMS (Cryptographic Message Syntax)]. This is used by other validators to verify that the proposer is authorized to create a block in the network.
-
-[Configure block proposal permissioning using the Besu command line options](../how-to/configure/block-proposal-permissioning.md).
-
-[QBFT consensus protocol]: ../how-to/configure/consensus/qbft.md
-[CMS (Cryptographic Message Syntax)]: https://en.wikipedia.org/wiki/Cryptographic_Message_Syntax
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/plugins.md b/versioned_docs/version-23.10.0/private-networks/concepts/plugins.md
deleted file mode 100644
index 70ee78f7ca4..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/plugins.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Plugins
-sidebar_position: 6
-description: Plugins overview
-tags:
- - private networks
----
-
-# Plugins
-
-You can extend Hyperledger Besu functionality by building Java plugins or using existing open source Besu plugins. Use the Plugin API to take data from any Besu network, public or permissioned, and feed it into an application or system.
-
-For example, create a plugin to add more monitoring functionality or stream event data to a third-party application. The API exposes data about the following components:
-
-- Blocks
-- Balances
-- Transactions
-- Smart contracts
-- Execution results
-- Logs
-- Syncing state.
-
-![Besu plugin API](../../assets/images/Hyperledger-Besu-Plugin-API.png)
-
-The plugin API provides access to [interfaces](../reference/plugin-api-interfaces.md) allowing you to build the plugin.
-
-:::info
-
-View the [plugin API webinar](https://youtu.be/78sa2WuA1rg) for an example of how to build a plugin.
-
-For more information about the available interfaces, see the [Plugin API Javadoc](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/index.html).
-
-:::
-
-## Install plugins
-
-To allow Besu to access and use the plugin, copy the plugin (`.jar`) to the `plugins` directory.
-
-:::caution
-
-If not already present, you must create the `plugins` directory one directory level below (`../`) the `besu` executable.
-
-:::
-
-Each plugin in the directory has the following lifecycle events:
-
-- **Register** - Executed when Besu starts. Besu checks plugin compatibility and registers plugins.
-- **Start** - Plugins start after being successfully registered.
-- **Stop** - Besu stops plugins.
-
-:::note
-
-The order in which Besu calls plugins during lifecycle events is not guaranteed.
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/poa.md b/versioned_docs/version-23.10.0/private-networks/concepts/poa.md
deleted file mode 100644
index 40d07a75c53..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/poa.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: Proof of authority consensus
-sidebar_position: 1
-description: Besu proof of authority consensus protocols comparison
-tags:
- - private networks
----
-
-# Proof of authority consensus
-
-Besu implements the QBFT, IBFT 2.0, and Clique proof of authority (PoA) [consensus protocols](../how-to/configure/consensus/index.md). PoA consensus protocols work when participants know each other and there is a level of trust between them. For example, in a permissioned consortium network.
-
-PoA consensus protocols have faster block times and a much greater transaction throughput than the Ethash proof of work consensus protocol used on the Ethereum Mainnet.
-
-In QBFT, IBFT 2.0, or Clique, a group of nodes in the network act as validators (QBFT and IBFT 2.0) or signers (Clique). The existing nodes in the signer/validator pool vote to add nodes to or remove nodes from the pool.
-
-:::note
-
-For the rest of this page, the term validator is used to refer to signers and validators.
-
-:::
-
-## Properties
-
-Properties to consider when comparing QBFT, IBFT 2.0, and Clique are:
-
-- Immediate finality.
-- Minimum number of validators.
-- Liveness.
-- Speed.
-
-### Immediate finality
-
-QBFT and IBFT 2.0 have immediate finality; there are no forks and all valid blocks get included in the main chain.
-
-Clique does not have immediate finality. Implementations using Clique must be aware of forks and chain reorganizations occurring.
-
-### Minimum number of validators
-
-To be Byzantine fault tolerant, QBFT and IBFT 2.0 require a minimum of four validators.
-
-Clique can operate with a single validator but operating with a single validator offers no redundancy if the validator fails.
-
-:::tip
-
-Byzantine fault tolerant is the ability to function correctly and reach consensus despite nodes failing or propagating incorrect information to peers.
-
-:::
-
-### Liveness
-
-Clique is more fault tolerant than QBFT and IBFT 2.0. Clique tolerates up to half of the validators failing. QBFT and IBFT 2.0 networks require greater than or equal to two-thirds of validators to be operating to create blocks. For example, an QBFT and IBFT 2.0 network of:
-
-- Four to five validators tolerates one unresponsive validator.
-- Six to eight validators tolerates two unresponsive validators.
-
-Networks with three or less validators can produce blocks but do not guarantee finality when operating in adversarial environments.
-
-:::caution
-
-We recommend using QBFT or IBFT 2.0 networks with at least four nodes in production environments.
-
-:::
-
-### Speed
-
-Reaching consensus and adding blocks is faster in Clique networks. For Clique, the probability of a fork increases as the number of validators increases.
-
-For QBFT and IBFT 2.0, the time to add new blocks increases as the number of validators increases.
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/_category_.json b/versioned_docs/version-23.10.0/private-networks/concepts/privacy/_category_.json
deleted file mode 100644
index e1382c18fd5..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Privacy",
- "position": 2
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/flexible-privacy.md b/versioned_docs/version-23.10.0/private-networks/concepts/privacy/flexible-privacy.md
deleted file mode 100644
index ea40eca8c52..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/flexible-privacy.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Flexible privacy groups
-sidebar_position: 3
-description: Flexible privacy groups
----
-
-# Flexible privacy groups
-
-Flexible [privacy groups](privacy-groups.md) use smart contracts to store and maintain the group membership. You can [add and remove members to and from flexible privacy groups](../../how-to/use-privacy/flexible.md).
-
-:::tip
-
-Because group membership for flexible privacy groups is stored in a smart contract, flexible privacy groups are also known as onchain privacy groups.
-
-:::
-
-:::danger
-
-Flexible privacy groups are an early access feature. Don't use in production networks.
-
-The flexible privacy group interfaces might change between releases. There might not be an upgrade path from flexible privacy groups created using v1.5 or earlier to enable use of flexible privacy group functionality in future versions.
-
-We don't recommended creating flexible privacy groups in a chain with existing [offchain privacy groups](privacy-groups.md).
-
-:::
-
-## Group management contracts
-
-The privacy group management contract bytecode is hard-coded into Besu and when you create a privacy group, the contract bytecode is part of the genesis state of the privacy group.
-
-:::caution
-
-All members of a flexible privacy group must be using the same version of Besu. If using different versions, the private state within the privacy group may become inconsistent.
-
-:::
-
-In the default implementation of the group management contract, the signer of the private transaction that creates the privacy group is also the owner of the group. Only the owner can add and remove participants, and upgrade the management contract.
-
-The owner is identified by the signing key. Transactions to add and remove participants, or upgrade the management contract, must be signed by the same key that signed the group creation transaction.
-
-## Flexible privacy group IDs
-
-When creating a flexible privacy group, generate the privacy group ID for the group outside of Besu and pass the ID as a parameter.
-
-The [web3js-quorum library](../../how-to/use-privacy/flexible.md) generates a unique privacy group ID and passes the ID to Besu when creating a privacy group.
-
-:::caution
-
-When generating a privacy group ID, you must ensure the ID is unique across all network participants. If you create a privacy group with an existing privacy group ID, the existing privacy group is overwritten.
-
-To ensure unique privacy group IDs, we recommend using 256-bit SecureRandom.
-
-:::
-
-## Multi-tenancy
-
-When using [multi-tenancy](multi-tenancy.md) with flexible privacy groups, each user provides a JSON Web Token (JWT) which allows Besu to check that the user has access to functionality and data associated with a privacy group.
-
-Using multi-tenancy with flexible privacy groups is more complex than with [offchain privacy groups](privacy-groups.md) because users may be added and removed from flexible privacy groups. When a user is added to a privacy group, they get access to all existing data in the privacy group. After being removed from a privacy group, a user retains access to already existing data in the privacy group, up to the block containing the [privacy marker transaction (PMT)](private-transactions/processing.md) that removed them (the removal block). A removed user doesn't have access to data in the privacy group that happens after they were removed.
-
-In particular, when multi-tenancy is enabled and a user requests access to a privacy group they were once a member of but later removed from, Besu allows the user access to the following functionality and data associated with the privacy group:
-
-- Private transactions using `priv_getTransaction` and private transaction receipts using [`priv_getTransactionReceipt`](../../../public-networks/reference/api/index.md#priv_gettransactionreceipt) from blocks up to (and including) the removal block.
-
- :::note
-
- A removed group member may have access to some private transactions after the removal PMT in the same block.
-
- :::
-
-- Using [`priv_call`](../../../public-networks/reference/api/index.md#priv_call) on blocks up to (and including) the removal block.
-
-- Private logs using [`priv_getLogs`](../../../public-networks/reference/api/index.md#priv_getlogs) for blocks up to (and including) the removal block. When the `toBlock` is greater than the removal block, `priv_getLogs` still returns logs up to the removal block.
-
- :::note
-
- When a user is removed from a privacy group, any log filters they've created are also removed and can't be accessed. A user can only create and access filters for a privacy group they are currently a member of.
-
- :::
-
-All other [`PRIV` API methods](../../../public-networks/reference/api/index.md#priv-methods) fail for the removed group member.
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/index.md b/versioned_docs/version-23.10.0/private-networks/concepts/privacy/index.md
deleted file mode 100644
index 0888bbe40e3..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/index.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: Privacy
-sidebar_position: 1
-description: Privacy
----
-
-# Privacy
-
-In Besu, privacy refers to the ability to keep transactions private between the involved participants. Other participants cannot access the transaction content or list of participants.
-
-:::danger
-
-For production environments requiring private transactions:
-
-- We recommend using a network with a consensus mechanism supporting transaction finality. For example, [IBFT 2.0](../../how-to/configure/consensus/ibft.md).
-- Tessera must be [highly available and run in a separate instance to Besu].
-
-Using private transactions with [pruning] or [fast sync](../../../public-networks/reference/cli/options.md#sync-mode) isn't supported.
-
-:::
-
-## Private transaction manager
-
-Besu uses a private transaction manager, [Tessera](https://docs.tessera.consensys.net/), to implement privacy. Each Besu node that sends or receives [private transactions](private-transactions/index.md) requires an associated Tessera node.
-
-
-
-![Tessera Nodes](../../../assets/images/TesseraNodes.png)
-
-
-
-Private transactions pass from the Besu node to the associated Tessera node. The Tessera node encrypts and directly distributes (that is, point-to-point) the private transaction to the Tessera nodes participating in the transaction.
-
-By default, each participant in a privacy-enabled network uses its own Besu and Tessera node. [Multi-tenancy](multi-tenancy.md) allows more than one participant to use the same Besu and Tessera node.
-
-:::tip
-
-Private Transaction Managers are also known as Enclaves.
-
-:::
-
-## Privacy-enabled networks
-
-When enabling privacy in a [private network](../../get-started/system-requirements.md), there's an assumed level of trust among the node operators, since all are members of the private network.
-
-:::caution
-
-Inefficient contracts deployed accidentally or deliberately can cause performance issues in privacy-enabled networks because gas isn't required in private transactions.
-
-:::
-
-In contrast, gas is required in Ethereum Mainnet and public testnets because they are trustless environments.
-
-Privacy-enabled networks should have a mechanism to establish trust offchain. Node operators should be informed on:
-
-- Guidelines for use, responsibilities, and good behavior.
-- Smart contract security, so contracts deployed on the network use resources efficiently.
-- Consequences for malicious activity.
-
-Privacy-enabled networks should run development and test environments that closely resemble production, so contracts can be tested, and potential issues can be found before they're deployed in production.
-
-## Reorg-compatible privacy
-
-In v1.4, using private transactions in a network using a consensus mechanism where forks occur (that is, PoW algorithms or Clique) is an early access feature.
-
-Do not use private transactions in production environments using consensus mechanisms where forks occur.
-
-
-
-[highly available and run in a separate instance to Besu]: ../../how-to/use-privacy/tessera.md
-[pruning]: ../../../public-networks/concepts/data-storage-formats.md#pruning
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/multi-tenancy.md b/versioned_docs/version-23.10.0/private-networks/concepts/privacy/multi-tenancy.md
deleted file mode 100644
index d04b9606eb8..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/multi-tenancy.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Multi-tenancy
-sidebar_position: 4
-description: Multi-tenancy
----
-
-# Multi-tenancy
-
-By default, each participant in a privacy network uses its own Besu and Tessera node.
-
-Multi-tenancy allows multiple participants to use the same Besu and Tessera node. Each participant is a _tenant_, and the operator is the _owner_ of the Besu and Tessera node.
-
-:::info
-
-The operator is responsible for [configuring multi-tenancy](../../tutorials/privacy/multi-tenancy.md), and has access to all tenant data.
-
-:::
-
-![Multi-tenancy](../../../assets/images/Multi-tenancy.png)
-
-:::tip
-
-Ensure the multi-tenant Tessera node client API is configured to allow access only by the multi-tenant Besu node. Access to your data is secured through Besu using multi-tenancy mode.
-
-If not configured to allow access only by the multi-tenant Besu node, other Tessera clients, including other Besu nodes, might be able to access tenant data.
-
-To secure access, you can [configure TLS between Besu and Tessera](../../how-to/configure/tls/client-and-server.md) with the [`WHITELIST`](https://docs.tessera.consensys.net/en/stable/HowTo/Configure/TLS/#whitelist) trust mode.
-
-:::
-
-Multi-tenancy validates that tenants have permission to use the specified HTTP or WebSocket JSON-RPC requests, and the tenant has access to the requested privacy data. Private data is isolated and each tenant uses a JSON Web Token (JWT) for authentication.
-
-You can [create the JWT either externally or internally](../../../public-networks/how-to/use-besu-api/authenticate.md).
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/plugin.md b/versioned_docs/version-23.10.0/private-networks/concepts/privacy/plugin.md
deleted file mode 100644
index fbc34fb440f..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/plugin.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: Privacy plugin
-description: Privacy plugin
-sidebar_position: 5
----
-
-# Privacy plugin
-
-You can define your own strategy for private transactions by building a plugin that extends Hyperledger Besu functionality.
-
-The plugin can take many forms, but it must provide Besu with a private transaction when required.
-
-:::danger
-
-The privacy plugin is an early access feature and plugin interfaces are subject to change between releases.
-
-:::
-
-## Configuration
-
-Enable the privacy plugin by starting Besu and including the `--Xprivacy-plugin-enabled` command line option. The registered plugin must implement the `PrivacyPluginPayloadProvider` interface.
-
-## Use the payload provider interface
-
-The privacy plugin must define the [privacy marker transaction (PMT)] payload. Use the payload to retrieve the contents of the private transaction which could be a link to a location in an enclave, or an encrypted form of the private payload itself.
-
-Besu doesn't need to know how the private transaction is distributed, it just needs to know what the private transaction for the PMT is.
-
-### Send transactions
-
-When submitting a private transaction using [`eea_sendRawTransaction`](../../../public-networks/reference/api/index.md#eea_sendrawtransaction), the signed transaction must be sent to `0x000000000000000000000000000000000000007a` to indicate which [privacy precompiled contract](private-transactions/processing.md) is being used.
-
-The transaction flow is as follows:
-
-1. The JSON-RPC endpoint passes the private transaction to the private transaction manager (for example Tessera).
-2. The private transaction manager sends the private transaction to the privacy plugin.
-3. The plugin decides what data to store onchain in the payload, for example the encrypted and serialized private transaction.
-4. The plugin returns what needs to be stored in the payload for the PMT.
-5. The private transaction handler creates a PMT for the private transaction, and propagates the PMT using devP2P in the same way as a public Ethereum transaction.
-
-### Mine transactions
-
-The process of mining transactions happens in reverse to sending transactions.
-
-1. The Mainnet transaction processor processes the PMT in the same way as any other public transaction. On nodes containing the [privacy precompile contract](../../../public-networks/reference/api/index.md#priv_getprivacyprecompileaddress) specified in the `to` attribute of the PMT, the Mainnet transaction processor passes the PMT to the privacy precompile contract.
-
- :::note
-
- Nodes receiving the PMT that do not contain the specified privacy precompile contract will ignore the PMT.
-
- :::
-
-1. The privacy precompile contract queries the plugin for the private transaction using the PMT.
-1. The privacy precompile contract passes the private transaction to the private transaction manager. The privacy group ID specifies the private world state to use.
-1. The private transaction manager executes the transaction. The private transaction manager can read and write to the private world state, and read from the public world state.
-
-## Transaction factory
-
-An additional extension is available to help you define how PMTs are signed. Currently, Besu supports fixed or random key signing for PMTs.
-
-The extension allows you to use a more dynamic approach, for example different keys for different groups.
-
-Your plugin needs to register the `PrivateMarkerTransactionFactory` interface which is called before submitting a PMT to the transaction pool. The responsibility then lies with the plugin to sign and serialize the PMT.
-
-[privacy marker transaction (PMT)]: ../../how-to/use-privacy/access-private-transactions.md
-
-## Register your plugin
-
-To enable Besu to use your privacy plugin, you must implement the `PrivacyPluginService` interface and you must call `setPayloadProvider`.
-
-```java
-
-@AutoService(BesuPlugin.class)
-public class TestPrivacyPlugin implements BesuPlugin {
-
- private PrivacyPluginService service;
-
- @Override
- public void register(BesuContext context) {
- service = context.getService(PrivacyPluginService.class).get();
- }
-
- @Override
- public void start() {
- service.setPayloadProvider(new PrivacyPluginPayloadProvider() {
- @Override
- public Bytes generateMarkerPayload(PrivateTransaction privateTransaction, String privacyUserId) {
- // perform logic to serialize the payload of the marker transaction
- // in this example we are serialising the private transaction using rlp https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/
- return org.hyperledger.besu.ethereum.privacy.PrivateTransaction.serialize(privateTransaction).encoded();
- }
-
- @Override
- public Optional getPrivateTransactionFromPayload(Transaction transaction) {
- // perform logic to deserialize payload from the marker transaction
-
- final BytesValueRLPInput bytesValueRLPInput =
- new BytesValueRLPInput(transaction.getPayload(), false);
-
- return Optional.of(org.hyperledger.besu.ethereum.privacy.PrivateTransaction.readFrom(bytesValueRLPInput));
- }
- });
- }
-
- @Override
- public void stop() {
-
- }
-}
-
-```
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/privacy-groups.md b/versioned_docs/version-23.10.0/private-networks/concepts/privacy/privacy-groups.md
deleted file mode 100644
index 8521efe7810..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/privacy-groups.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: Privacy groups
-sidebar_position: 2
-description: Privacy groups
----
-
-# Privacy groups
-
-A privacy group is a group of nodes identified by a unique privacy group ID by Tessera. Tessera stores each private transaction with the privacy group ID.
-
-The Besu nodes maintain the public world state for the blockchain and a private state for each privacy group. The private states contain data that is not shared in the globally replicated world state.
-
-:::caution
-
-The privacy group implementations described below are offchain privacy groups and cannot have their group membership updated.
-
-[Flexible privacy groups are an early access feature](flexible-privacy.md).
-
-:::
-
-## Privacy types
-
-Besu implements two types of privacy:
-
-- Enterprise Ethereum Alliance (EEA) privacy, where private transactions include `privateFor` as the recipient.
-- Besu-extended privacy, where private transactions include `privacyGroupId` as the recipient.
-
-Both privacy types create privacy groups and store private transactions with their privacy group in Tessera.
-
-
-
-![Privacy Groups](../../../assets/images/PrivacyGroups.png)
-
-
-
-:::note
-
-For clarity, the Tessera nodes are not shown in the previous diagram. To send private transactions, each Besu node must have an associated Tessera node.
-
-:::
-
-### Access between states
-
-A contract in a privacy group:
-
-- Can read or write to a contract in the same privacy group.
-- Can read from the public state including public contracts.
-- Cannot access contracts from a different privacy group.
-
-A public contract cannot access a private contract.
-
-### Enterprise Ethereum Alliance privacy
-
-In the privacy implementation complying with the [EEA Client Specification](https://entethalliance.org/technical-documents/) the group of nodes specified by `privateFrom` and `privateFor` form a privacy group with a unique privacy group ID provided by Tessera.
-
-The previous diagram illustrates two privacy groups enabling:
-
-- A, B, and C to send transactions that are private from D.
-- A, C, and D to send transactions that are private from B.
-
-Using EEA-compliant privacy, to send private transactions between A, B, and C, A initializes a contract in a private transaction with B and C specified as the `privateFor` and A specified as the `privateFrom`. Initializing the contract creates a privacy group consisting of A, B, and C. For the ABC private state to remain consistent, A, B, and C must be included on transactions (as either `privateFrom` or `privateFor`) even if they are between only two of the three parties.
-
-To send private transactions between A, C, and D, C initializes a different contract in a private transaction with A and D specified as the `privateFor` and C specified as the `privateFrom`. Initializing the contract creates a privacy group consisting of A, C, and D. For the ACD private state to remain consistent, A, C, and D must be included on transactions (as either `privateFrom` or `privateFor`) even if they are between only two of the three parties.
-
-### Besu-extended privacy
-
-The Besu-extended privacy implementation creates a privacy group using [`priv_createPrivacyGroup`](../../../public-networks/reference/api/index.md#priv_createprivacygroup) with private transactions sent to the privacy group ID.
-
-Using the same privacy groups as in the previous example.
-
-Using Besu-extended privacy, to send private transactions between A, B, and C, A creates a privacy group consisting of A, B, and C. The privacy group ID is specified when sending private transactions and A, B, and C are recipients of all private transactions sent to the privacy group.
-
-To send private transactions between A, C, and D, A creates a privacy group consisting of A, C, and D. The privacy group ID of this group is specified when sending private transactions with A, C, and D as recipients.
-
-## Multi-tenancy
-
-When using [multi-tenancy](multi-tenancy.md) with privacy groups, each user provides a JSON Web Token (JWT) which allows Besu to check that the user has access to functionality and data associated with a privacy group.
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/private-transactions/_category_.json b/versioned_docs/version-23.10.0/private-networks/concepts/privacy/private-transactions/_category_.json
deleted file mode 100644
index 465b0be5572..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/private-transactions/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Private transactions",
- "position": 1
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/private-transactions/index.md b/versioned_docs/version-23.10.0/private-networks/concepts/privacy/private-transactions/index.md
deleted file mode 100644
index c149089080d..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/private-transactions/index.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-description: Private transaction overview
----
-
-# Private transactions
-
-Private transactions have the same parameters as public Ethereum transactions, with the following additions:
-
-- `privateFrom` - The Tessera public key of the transaction sender.
-- One of the following:
- - `privateFor` - The Tessera public keys of the transaction recipients.
- - `privacyGroupId` - [The privacy group to receive the transaction](../privacy-groups.md).
-- `restriction` - Whether the private transaction is `restricted` or `unrestricted`:
-
- - `restricted` - Only the nodes participating in the transaction receive and store the payload of the private transaction.
- - `unrestricted` - All nodes in the network receive the payload of the private transaction, but only the nodes participating in the transaction can read the transaction.
-
- :::info
-
- Besu implements `restricted` private transactions only.
-
- :::
-
-The `gas` and `gasPrice` are used by the [privacy marker transaction (PMT)](processing.md), not the private transaction itself.
-
-:::info
-
-Because gas isn't required in private transactions, inefficient contracts deployed accidentally or deliberately can cause performance issues in privacy-enabled networks. Ensure your network has a mechanism to [establish trust offchain](../index.md#privacy-enabled-networks).
-
-:::
-
-You can [create and send private transactions](../../../how-to/send-transactions/private-transactions.md).
-
-## Besu and Tessera keys
-
-Besu and Tessera nodes both have public/private key pairs identifying them. A Besu node sending a private transaction to a Tessera node signs the transaction with the Besu node private key. The `privateFrom` and `privateFor` parameters specified in the RLP-encoded transaction string for [`eea_sendRawTransaction`](../../../reference/api/index.md#eea_sendrawtransaction) are the public keys of the Tessera nodes sending and receiving the transaction.
-
-:::info
-
-The mapping of Besu node addresses to Tessera node public keys is offchain. That is, the sender of a private transaction must know the Tessera node public key of the recipient.
-
-:::
-
-## Nonces
-
-A nonce is the number of previous transactions made by the sender.
-
-[Private transaction processing](processing.md) involves two transactions: the private transaction distributed to involved participants, and the privacy marker transaction (PMT) included on the public blockchain. Each of these transactions has its own nonce. Since the PMT is a public transaction, the PMT nonce is the public nonce for the account.
-
-### Private transaction nonce
-
-Besu maintains separate private states for each [privacy group](../privacy-groups.md). The private transaction nonce for an account is specific to the privacy group. That is, the nonce for account A for privacy group ABC is different to the nonce for account A for privacy group AB.
-
-### Private nonce validation
-
-Unlike public transactions, private transactions are not submitted to the [transaction pool](../../../../public-networks/concepts/transactions/pool.md). The private transaction is distributed directly to the participants in the transaction, and the PMT is submitted to the transaction pool.
-
-Unlike [public transaction nonces](../../../../public-networks/concepts/transactions/validation.md), private transaction nonces aren't validated when the private transaction is submitted. If a private transaction has an incorrect nonce, the PMT is still valid and is added to a block. However, in this scenario, the private transaction execution fails when [processing the PMT](processing.md) for the private transaction with the incorrect nonce.
-
-The following private transaction flow illustrates when nonce validation occurs:
-
-1. Submit a private transaction with a [nonce value](#private-transaction-nonce).
-1. The private transaction is distributed to all participants in the privacy group.
-1. The PMT is created and submitted to the transaction pool with a nonce of `0` if using one-time accounts. If using a specific account with [`--privacy-marker-transaction-signing-key-file`](../../../reference/cli/options.md#privacy-marker-transaction-signing-key-file), the public nonce for that account is obtained and used for the PMT.
-1. The PMT is mined and included in the block.
-1. After the block containing the PMT is imported, and the PMT is processed, the private transaction is retrieved from the private transaction manager and executed.
-
- If the private transaction was submitted with a correct nonce in step 1, the nonce is validated as correct. If an incorrect nonce was submitted, the private transaction execution fails.
-
-### Private nonce management
-
-In Besu, you call [`eth_getTransactionCount`](../../../../public-networks/reference/api/index.md#eth_gettransactioncount) to get a nonce, then use that nonce with [`eea_sendRawTransaction`](../../../reference/api/index.md#eea_sendrawtransaction) to send a private transaction.
-
-However, when you send multiple transactions in row, if a subsequent call to `getTransactionCount` happens before a previous transaction is processed, you can get the same nonce again.
-
-You can manage private nonces in multiple ways:
-
-- Let Besu handle it. You just need to wait long enough between calls to `sendRawTransaction` for the transactions to process. The current window is around 1.5 seconds, depending on block time.
-
- Public transactions deal with this issue, but the window is shorter, since you can use the transaction pool to take into account pending transactions (by using `eth_getTransactionCount("pending")`).
-
- For private transactions, the window is longer because private transactions aren't submitted to the transaction pool. You must wait until the private transaction's corresponding PMT is included in a block.
-
-- Manage the nonce yourself, by keeping track of and providing the nonce at each call. We recommend this if you're [sending many transactions that are independent of each other](../../../how-to/send-transactions/concurrent-private-transactions.md).
-
- :::note
-
- You can use [`priv_getTransactionCount`](../../../reference/api/index.md#priv_gettransactioncount) or [`priv_getEeaTransactionCount`](../../../reference/api/index.md#priv_geteeatransactioncount) to get the nonce for an account for the specified privacy group or participants.
-
- :::
-
-- Use [Orchestrate](https://docs.orchestrate.consensys.net/en/stable/) for nonce management. We recommend this for enterprise use.
-
-:::tip
-
-The [web3js-quorum library includes an example](https://github.com/ConsenSys/web3js-quorum/blob/9a0f9eb1b91a4a0d93801f77782b509ae2e7314c/example/concurrentPrivateTransactions/concurrentPrivateTransactions.js) of nonce management when [sending concurrent private transactions](../../../how-to/send-transactions/concurrent-private-transactions.md). The example calculates the correct nonces for the private transactions and PMTs outside of Besu.
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/private-transactions/processing.md b/versioned_docs/version-23.10.0/private-networks/concepts/privacy/private-transactions/processing.md
deleted file mode 100644
index 196f2b9e7e0..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/concepts/privacy/private-transactions/processing.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: Private transaction processing
-sidebar_position: 1
-description: Private transaction processing
----
-
-# Private transaction processing
-
-Processing [private transactions](index.md) involves the following:
-
-- **Precompiled contract**: A smart contract compiled from the source language to EVM bytecode and stored by an Ethereum node for later execution.
-
-- **Privacy marker transaction (PMT)**: A public Ethereum transaction with a payload of the enclave key. The enclave key is a pointer to the private transaction in Tessera. The `to` attribute of the PMT is the [address of the privacy precompiled contract](../../../reference/api/index.md#priv_getprivacyprecompileaddress).
-
- The PMT is [signed with a random key or the key specified on the command line].
-
-Private transaction processing is illustrated and described in the following diagram.
-
-![Processing Private Transactions](../../../../assets/images/PrivateTransactionProcessing.png)
-
-1. Submit a private transaction using [`eea_sendRawTransaction`](../../../reference/api/index.md#eea_sendrawtransaction). The signed transaction includes transaction parameters specific to private transactions, including:
-
- - `privateFor` or `privacyGroupId`, which specifies the list of recipients.
- - `privateFrom`, which specifies the sender.
- - `restriction`, which specifies the transaction is restricted to the transaction participants.
-
-1. The JSON-RPC endpoint passes the private transaction to the Private Transaction Handler.
-
-1. The Private Transaction Handler sends the private transaction to Tessera.
-
-1. Tessera distributes the private transaction directly (that is, point-to-point) to the Tessera nodes specified in `privateFor` or belonging to the privacy group identified by `privacyGroupId`. All recipient Tessera nodes store the transaction. Tessera associates the stored transaction with the transaction hash and privacy group ID.
-
-1. Tessera returns the transaction hash to the Private Transaction Handler.
-
-1. The Private Transaction Handler creates a PMT for the private transaction. The Private Transaction Handler propagates the PMT using devP2P in the same way as any other public Ethereum transaction.
-
- :::tip
-
- If you want to sign the PMT outside of Besu, use [`priv_distributeRawTransaction`](../../../how-to/send-transactions/private-transactions.md#priv_distributerawtransaction) instead of [`eea_sendRawTransaction`](../../../reference/api/index.md#eea_sendrawtransaction).
-
- :::
-
-1. Besu mines the PMT into a block and the PMT is distributed to all Ethereum nodes in the network.
-
-1. The Mainnet Transaction Processor processes the PMT in the same way as any other public transaction. On nodes containing the [privacy precompile contract](../../../reference/api/index.md#priv_getprivacyprecompileaddress) specified in the `to` attribute of the PMT, the Mainnet Transaction Processor passes the PMT to the privacy precompile contract.
-
- :::note
-
- Nodes receiving the PMT that don't contain the privacy precompile contract ignore the PMT.
-
- :::
-
-1. The privacy precompile contract queries Tessera for the private transaction and privacy group ID using the transaction hash.
-
-1. The privacy precompile contract passes the private transaction to the Private Transaction Processor. The privacy group ID specifies the private world state to use.
-
-1. The Private Transaction Processor executes the transaction. The Private Transaction Processor can read and write to the private world state, and read from the public world state.
-
-:::danger Recommendations
-
-- We recommend using a network with a consensus mechanism supporting transaction finality. For example, [IBFT 2.0](../../../how-to/configure/consensus/ibft.md).
-- Tessera must be [highly available and run in a separate instance to Besu](../../../how-to/use-privacy/tessera.md).
-
-Using private transactions with [pruning] or [fast sync](../../../../public-networks/reference/cli/options.md#sync-mode) is not supported.
-
-:::
-
-
-
-[signed with a random key or the key specified on the command line]: ../../../how-to/use-privacy/sign-pmts.md
-[highly available and run in a separate instance to Besu]: ../../../how-to/use-privacy/tessera.md
-[pruning]: ../../../../public-networks/concepts/data-storage-formats.md#pruning
diff --git a/versioned_docs/version-23.10.0/private-networks/get-started/_category_.json b/versioned_docs/version-23.10.0/private-networks/get-started/_category_.json
deleted file mode 100644
index 3b3ed44eda6..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/get-started/_category_.json
+++ /dev/null
@@ -1,9 +0,0 @@
-{
- "label": "Get started",
- "position": 2,
- "collapsed": false,
- "link": {
- "type": "generated-index",
- "slug": "/private-networks/get-started"
- }
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/get-started/install/_category_.json b/versioned_docs/version-23.10.0/private-networks/get-started/install/_category_.json
deleted file mode 100644
index 043580c1474..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/get-started/install/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Install Besu",
- "position": 2
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/get-started/install/binary-distribution.md b/versioned_docs/version-23.10.0/private-networks/get-started/install/binary-distribution.md
deleted file mode 100644
index 74dcba7e6f4..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/get-started/install/binary-distribution.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: Install binary distribution
-description: Install or upgrade Hyperledger Besu from binary distribution
-sidebar_position: 3
-tags:
- - private networks
----
-
-# Install binary distribution
-
-## MacOS with Homebrew
-
-### Prerequisites
-
-- [Homebrew](https://brew.sh/)
-- Java JDK
-
-:::caution
-
-Hyperledger Besu supports:
-
-- MacOS High Sierra 10.13 or later versions.
-- Java 17+. You can install Java using `brew install openjdk`. Alternatively, you can manually install the [Java JDK](https://www.oracle.com/java/technologies/downloads).
-
-:::
-
-### Install (or upgrade) using Homebrew
-
-To install Besu using Homebrew:
-
-```bash
-brew tap hyperledger/besu
-brew install hyperledger/besu/besu
-```
-
-To upgrade an existing Besu installation using Homebrew:
-
-```bash
-brew upgrade hyperledger/besu/besu
-```
-
-:::note
-
-If you've upgraded your MacOS version between installing and upgrading Besu, when running `brew upgrade hyperledger/besu/besu` you may be prompted to reinstall command line tools with `xcode-select --install`.
-
-:::
-
-:::note
-
-When upgrading Besu, you might be prompted to fix the remote branch names in Homebrew by using the command `brew tap --repair`.
-
-:::
-
-To display the Besu version and confirm installation:
-
-```bash
-besu --version
-```
-
-To display Besu command line help:
-
-```bash
-besu --help
-```
-
-## Linux / Unix
-
-### Prerequisites
-
-- [Java JDK 17+](https://www.oracle.com/java/technologies/downloads/)
-
-:::note Linux open file limit
-
-If synchronizing to Mainnet on Linux or other chains with large data requirements, increase the maximum number of open files allowed using `ulimit`. If the open files limit is not high enough, a `Too many open files` RocksDB exception occurs.
-
-:::
-
-:::tip
-
-We recommend installing [jemalloc](https://jemalloc.net/) to reduce memory usage. If using Ubuntu, you can install it with the command: `apt install libjemalloc-dev`.
-
-:::
-
-### Install from packaged binaries
-
-Download the Besu [packaged binaries](https://github.com/hyperledger/besu/releases).
-
-Unpack the downloaded files and change into the `besu-` directory.
-
-Display Besu command line help to confirm installation:
-
-```bash
-bin/besu --help
-```
diff --git a/versioned_docs/version-23.10.0/private-networks/get-started/install/index.md b/versioned_docs/version-23.10.0/private-networks/get-started/install/index.md
deleted file mode 100644
index 5c6fb933f52..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/get-started/install/index.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Installation options
-description: Options for getting started with Hyperledger Besu
-sidebar_position: 1
-tags:
- - private networks
----
-
-# Installation options
-
-Get started with the [Developer Quickstart](../../../private-networks/tutorials/quickstart.md). Use the quickstart to rapidly generate local blockchain networks.
-
-You can also install the following:
-
-- [Docker image](run-docker-image.md)
-- [Binaries](binary-distribution.md)
-
-## Build from source
-
-If you want to use the latest development version of Hyperledger Besu or a specific commit, build from source. Otherwise, use the [binary] or [Docker image] for more stable versions.
-
-View the [Hyperledger Wiki] for instructions to install Hyperledger Besu from source.
-
-
-
-[Hyperledger Wiki]: https://wiki.hyperledger.org/display/BESU/Building+from+source
-[binary]: binary-distribution.md
-[Docker image]: run-docker-image.md
diff --git a/versioned_docs/version-23.10.0/private-networks/get-started/install/run-docker-image.md b/versioned_docs/version-23.10.0/private-networks/get-started/install/run-docker-image.md
deleted file mode 100644
index bc84eefbb97..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/get-started/install/run-docker-image.md
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Run Besu from Docker image
-description: Run Hyperledger Besu using the official docker image
-sidebar_position: 2
-tags:
- - private networks
----
-
-# Run Besu from a Docker image
-
-Hyperledger Besu provides a Docker image to run a Besu node in a Docker container.
-
-Use this Docker image to run a single Besu node without installing Besu.
-
-## Prerequisites
-
-- [Docker](https://docs.docker.com/install/)
-
-- MacOS or Linux
-
- :::caution
-
- The Docker image does not run on Windows.
-
- :::
-
-## Expose ports
-
-Expose ports for P2P discovery, GraphQL, metrics, and HTTP and WebSocket JSON-RPC. You need to expose the ports to use the default ports or the ports specified using [`--rpc-http-port`](../../../public-networks/reference/cli/options.md#rpc-http-port), [`--p2p-port`](../../../public-networks/reference/cli/options.md#p2p-port), [`--rpc-ws-port`](../../../public-networks/reference/cli/options.md#rpc-ws-port), [`--metrics-port`](../../../public-networks/reference/cli/options.md#metrics-port), [`--graphql-http-port`](../../../public-networks/reference/cli/options.md#graphql-http-port), and [`--metrics-push-port`](../../../public-networks/reference/cli/options.md#metrics-push-port) options.
-
-To run Besu exposing local ports for access:
-
-```bash
-docker run -p :8545 -p :8546 -p :30303 hyperledger/besu:latest --rpc-http-enabled --rpc-ws-enabled
-```
-
-:::note
-
-The examples on this page expose TCP ports only. To expose UDP ports, specify `/udp` at the end of the argument for the `-p` Docker subcommand option:
-
-```bash
-docker run -p :/udp
-```
-
-See the [`docker run -p` documentation](https://docs.docker.com/engine/reference/commandline/run/#publish-or-expose-port--p---expose).
-
-:::
-
-To enable JSON-RPC HTTP calls to `127.0.0.1:8545` and P2P discovery on `127.0.0.1:13001`:
-
-```bash
-docker run -p 8545:8545 -p 13001:30303 hyperledger/besu:latest --rpc-http-enabled
-```
-
-## Start Besu
-
-:::danger
-
-Don't mount a volume at the default data path (`/opt/besu`). Mounting a volume at the default data path interferes with the operation of Besu and prevents Besu from safely launching.
-
-To run a node that maintains the node state (key and database), [`--data-path`](../../../public-networks/reference/cli/options.md#data-path) must be set to a location other than `/opt/besu` and a storage volume mounted at that location.
-
-When running in a Docker container, [`--nat-method`](../../../public-networks/how-to/connect/specify-nat.md) must be set to `DOCKER` or `AUTO` (default). Don't set [`--nat-method`](../../../public-networks/how-to/connect/specify-nat.md) to `NONE` or `UPNP`.
-
-:::
-
-You can specify [Besu environment variables](../../../public-networks/reference/cli/options.md#specify-options) with the Docker image instead of the command line options.
-
-```bash
-docker run -p 30303:30303 -p 8545:8545 -e BESU_RPC_HTTP_ENABLED=true -e BESU_NETWORK=goerli hyperledger/besu:latest
-```
-
-:::caution "Unsupported address type exception"
-
-When running Besu from a Docker image, you might get the following exception:
-
-```bash
-Unsupported address type exception when connecting to peer {}, this is likely due to ipv6 not being enabled at runtime.
-```
-
-This happens when the IPv6 support in Docker is disabled while connecting to an IPv6 peer, preventing outbound communication. IPv6 is disabled by default in Docker.
-
-[Enable IPv6 support in Docker](https://docs.docker.com/config/daemon/ipv6/) to allow outbound IPv6 traffic and allow connection with IPv6 peers.
-
-:::
-
-### Run a node for testing
-
-To run a node that mines blocks at a rate suitable for testing purposes with WebSocket enabled:
-
-```bash
-docker run -p 8546:8546 --mount type=bind,source=/,target=/var/lib/besu hyperledger/besu:latest --miner-enabled --miner-coinbase fe3b557e8fb62b89f4916b721be55ceb828dbd73 --rpc-ws-enabled --network=dev --data-path=/var/lib/besu
-```
-
-## Stop Besu and clean up resources
-
-When done running nodes, you can shut down the node container without deleting resources or you can delete the container after stopping it. Run `docker container ls` and `docker volume ls` to get the container and volume names.
-
-To stop a container:
-
-```bash
-docker stop
-```
-
-To delete a container:
-
-```bash
-docker rm
-```
diff --git a/versioned_docs/version-23.10.0/private-networks/get-started/start-node.md b/versioned_docs/version-23.10.0/private-networks/get-started/start-node.md
deleted file mode 100644
index 4d7162a5927..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/get-started/start-node.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: Start Besu
-description: Start Besu on a private Ethereum network.
-sidebar_position: 3
-tags:
- - private networks
----
-
-# Start Besu
-
-Use the [`besu`](../reference/cli/options.md) command with the required command line options to start a node.
-
-## Prerequisites
-
-[Besu installed](install/binary-distribution.md)
-
-## Local block data
-
-When connecting to a network other than the network previously connected to, you must either delete the local block data or use the [`--data-path`](../../public-networks/reference/cli/options.md#data-path) option to specify a different data directory.
-
-To delete the local block data, delete the `database` directory in the `besu/build/distribution/besu-` directory.
-
-## Genesis configuration
-
-To define a genesis configuration, create a [genesis file](../../public-networks/concepts/genesis-file.md) (for example, `genesis.json`) and specify the file using the [`--genesis-file`](../../public-networks/reference/cli/options.md#genesis-file) option.
-
-When you specify [`--network=dev`](../../public-networks/reference/cli/options.md#network), Besu uses the development mode genesis configuration with a fixed low difficulty. A node started with [`--network=dev`](../../public-networks/reference/cli/options.md#network) has an empty bootnodes list by default.
-
-Predefined genesis configurations for named networks are in the [Besu source files](https://github.com/hyperledger/besu/tree/master/config/src/main/resources).
-
-## Confirm node is running
-
-If you started Besu with the [`--rpc-http-enabled`](../../public-networks/reference/cli/options.md#rpc-http-enabled) option, use [cURL](https://curl.haxx.se/) to call [JSON-RPC API methods](../reference/api/index.md) to confirm the node is running.
-
-- `eth_chainId` returns the chain ID of the network.
-
- ```bash
- curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' localhost:8545
- ```
-
-- `eth_syncing` returns the starting, current, and highest block.
-
- ```bash
- curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' localhost:8545
- ```
-
- For example, after connecting to Mainnet, `eth_syncing` will return something similar to:
-
- ```json
- {
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "startingBlock": "0x0",
- "currentBlock": "0x2d0",
- "highestBlock": "0x66c0"
- }
- }
- ```
-
-## Run a node for testing
-
-To run a node that mines blocks at a rate suitable for testing purposes:
-
-```bash
-besu --network=dev --miner-enabled --miner-coinbase=0xfe3b557e8fb62b89f4916b721be55ceb828dbd73 --rpc-http-cors-origins="all" --host-allowlist="*" --rpc-ws-enabled --rpc-http-enabled --data-path=/tmp/tmpDatdir
-```
-
-You can also use the following [configuration file](../../public-networks/how-to/configuration-file.md) on the command line to start a node with the same options as above:
-
-```toml
-network="dev"
-miner-enabled=true
-miner-coinbase="0xfe3b557e8fb62b89f4916b721be55ceb828dbd73"
-rpc-http-cors-origins=["all"]
-host-allowlist=["*"]
-rpc-ws-enabled=true
-rpc-http-enabled=true
-data-path="/tmp/tmpdata-path"
-```
-
-:::caution
-
-The following settings are a security risk in production environments:
-
-- Enabling the HTTP JSON-RPC service ([`--rpc-http-enabled`](../../public-networks/reference/cli/options.md#rpc-http-enabled)) and setting [`--rpc-http-host`](../../public-networks/reference/cli/options.md#rpc-http-host) to 0.0.0.0 exposes the RPC connection on your node to any remote connection.
-- Setting [`--host-allowlist`](../../public-networks/reference/cli/options.md#host-allowlist) to `"*"` allows JSON-RPC API access from any host.
-- Setting [`--rpc-http-cors-origins`](../../public-networks/reference/cli/options.md#rpc-http-cors-origins) to `"all"` or `"*"` allows cross-origin resource sharing (CORS) access from any domain.
-
-:::
-
-## Run a node on a private network
-
-To run a node on your private network specifying a genesis file and data directory:
-
-```bash
-besu --genesis-file=/genesis.json --data-path= --rpc-http-enabled --bootnodes=
-```
-
-Where `` is the path to the directory to save the chain data to. Ensure you configure a peer discovery method, such as [bootnodes](../how-to/configure/bootnodes.md).
-
-:::note
-
-You might need to set [`--tx-pool-limit-by-account-percentage`](../../public-networks/reference/cli/options.md#tx-pool-limit-by-account-percentage) to 1. The default value is suitable for Mainnet, but may cause issues on private networks.
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/get-started/system-requirements.md b/versioned_docs/version-23.10.0/private-networks/get-started/system-requirements.md
deleted file mode 100644
index 18666307ee7..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/get-started/system-requirements.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: System requirements
-description: Ensure you meet the system requirements to sync and run Besu.
-sidebar_position: 1
-tags:
- - private networks
----
-
-# System requirements
-
-Private network system requirements depend on many factors, including:
-
-- Size of the world state for the network.
-- Number of transactions submitted to the network.
-- [Block gas limit](../../public-networks/reference/genesis-items.md#genesis-block-parameters).
-- Number and complexity of [JSON-RPC](../../public-networks/how-to/use-besu-api/json-rpc.md), [PubSub](../../public-networks/how-to/use-besu-api/rpc-pubsub.md), or [GraphQL](../../public-networks/how-to/use-besu-api/graphql.md) queries handled by the node.
-
-Participation in private networks is typically restricted in some way, so the volume of traffic is much lower than on Mainnet, resulting in lower system requirements.
-
-## Determining system requirements
-
-To determine system requirements, check CPU and disk space requirements using [Prometheus](../../public-networks/how-to/monitor/metrics.md). Grafana provides a [sample dashboard](https://grafana.com/grafana/dashboards/10273) for Besu.
-
-## Java Virtual Machine size
-
-Depending on your environment and network setup, the minimum Java Virtual Machine (JVM) memory requirement for private networks is 4 GB.
-
-JVM memory requirements are highest when syncing, but will reduce after the node is synchronized to the chain head. Monitor your system to determine your actual JVM memory needs.
-
-## VM requirements
-
-If you set up your own VM locally using a VM manager such as [VirtualBox](https://www.oracle.com/virtualization/virtualbox/):
-
-- Ensure you enable Intel Virtualization Technology (VTx) and Virtualization Technology for Directed I/O (VT-d) in the BIOS settings.
-- On Windows, you might need to disable Hyper-V in the Windows Feature list.
-
-We recommend you create a VM with the following attributes:
-
-- Memory size: Set to 6 GB (recommended)
-- Create a virtual hard disk with at least 10 GB (20 GB recommended)
-- Virtual hard disk file type: VDI (if you need to share it with other apps, use VHD)
-- (Optional) You can create a shared directory to copy block files or genesis files from the host computer to the VM. For details on how to create a shared directory, see "Share Folders" in the [Oracle VirtualBox documentation].
-
-## Disk type
-
-Use [local SSD storage](https://cloud.google.com/compute/docs/disks) for high throughput nodes (validators and RPC nodes). Read-only nodes can use a lower performance setup.
-
-You can use local SSDs through [SCSI interfaces](https://en.wikipedia.org/wiki/SCSI). For higher performance in production settings, we recommend upgrading to [NVMe interfaces](https://cloud.google.com/compute/docs/disks/local-ssd#performance).
-
-
-
-[Oracle VirtualBox documentation]: https://docs.oracle.com/en/virtualization/virtualbox/6.1/user/
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/_category_.json b/versioned_docs/version-23.10.0/private-networks/how-to/_category_.json
deleted file mode 100644
index ba43c43036f..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "How to",
- "position": 3
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/backup.md b/versioned_docs/version-23.10.0/private-networks/how-to/backup.md
deleted file mode 100644
index d81cca0621c..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/backup.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Backup and restore
-description: Backing up and restoring Besu
-sidebar_position: 7
-tags:
- - private networks
----
-
-# Backup and restore Besu
-
-In a decentralized blockchain, data replicates between nodes so it's not lost. But backing up configuration and data ensures a smoother recovery from corrupted data or other failures.
-
-## Genesis file
-
-The genesis file for a network must be accessible on every node. We recommend storing the genesis file under source control.
-
-## Data backups
-
-If installed locally, the default data location is the Besu installation directory.
-
-We recommend mounting a [separate volume to store data](../get-started/install/run-docker-image.md). Use the [`--data-path`](../../public-networks/reference/cli/options.md#data-path) command line option to pass the path to Besu.
-
-The default data location is the Besu installation directory, or `/opt/besu/database` if using the [Besu Docker image](../get-started/install/run-docker-image.md).
-
-Having some data reduces the time to synchronize a new node. You can perform periodic backups of the data directory and send the data to your preferred backup mechanism. For example, `cron` job and `rsync`, archives to the cloud such as s3, or `tar.gz` archives.
-
-## Data restores
-
-To restore data:
-
-1. If the node is running, stop the node.
-1. If required, move the data directory to another location for analysis.
-1. Restore the data from your last known good backup to the same directory.
-1. Ensure user permissions are valid so you can read from and write to the data directory.
-1. Restart the node.
-
-## Corrupted data
-
-If log messages signify a corrupt database, the cleanest way to recover is:
-
-1. Stop the node.
-1. Restore the data from a [previous backup](#data-backups).
-1. Restart the node.
-
-## Find peers after restarting
-
-The process for finding peers after restarting is the same as for [finding peers after upgrading and restarting].
-
-
-
-[finding peers after upgrading and restarting]: ../../public-networks/how-to/upgrade-node.md#find-peers-on-restarting
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/_category_.json b/versioned_docs/version-23.10.0/private-networks/how-to/configure/_category_.json
deleted file mode 100644
index 49e1f9da31b..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Configure",
- "position": 1
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/block-proposal-permissioning.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/block-proposal-permissioning.md
deleted file mode 100644
index c164fadeddd..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/block-proposal-permissioning.md
+++ /dev/null
@@ -1,292 +0,0 @@
----
-title: Block proposal permissioning
-description: Block proposal permissioning
-sidebar_position: 7
-tags:
- - private networks
----
-
-# Block proposal permissioning
-
-:::info
-
-Only private networks using the [QBFT consensus protocol] support block proposal permissioning.
-
-Block proposal permissioning is an early access feature, and functionality and options may be updated between releases.
-
-:::
-
-You can configure [block proposal permissioning](../../concepts/pki.md#block-proposal-permissioning) to ensure only authorized validator nodes can propose blocks in the network.
-
-Use certificates issued by a trusted authority to ensure validators are authorized to propose blocks.
-
-## Configure block proposal permissioning
-
-**Prerequisites**:
-
-- A configured network. For example, [see steps 1 to 5 in the QBFT tutorial](../../tutorials/qbft.md).
-- A keystore containing the certificate and key for each network node.
-- A truststore containing all the trusted certificates for the network.
-
-Start Besu and include the following command line options on the required nodes:
-
-```bash
-besu --Xpki-block-creation-enabled=true \
---Xpki-block-creation-keystore-type="pkcs12" \
---Xpki-block-creation-keystore-file="keystore" \
---Xpki-block-creation-keystore-password-file="keystore.password" \
---Xpki-block-creation-crl-file="crl2.pem" \
---Xpki-block-creation-keystore-certificate-alias="validator" \
---Xpki-block-creation-truststore-type="pkcs12" \
---Xpki-block-creation-truststore-file="truststore" \
---Xpki-block-creation-truststore-password-file="truststore.password"
-```
-
-In the command line:
-
-- Enable block proposal permissioning using [`--Xpki-block-creation-enabled=true`](#xpki-block-creation-enabled).
-- Specify the keystore type and keystore file using [`Xpki-block-creation-keystore-type`](#xpki-block-creation-keystore-type) and [`--Xpki-block-creation-keystore-file`](#xpki-block-creation-keystore-file).
-- Specify the text file containing the password to unlock the keystore file using [`Xpki-block-creation-keystore-password-file`](#xpki-block-creation-keystore-password-file).
-- Specify the optional [certificate revocation list (CRL)] file using [`Xpki-block-creation-crl-file`](#xpki-block-creation-crl-file).
-- Specify the alias of the certificate to be included in blocks proposed by this validator using [`Xpki-block-creation-keystore-certificate-alias`](#xpki-block-creation-keystore-certificate-alias).
-- Specify the truststore type and truststore file using [`Xpki-block-creation-truststore-type`](#xpki-block-creation-truststore-type) and [`Xpki-block-creation-truststore-file`](#xpki-block-creation-truststore-file).
-- Specify the text file containing the password to unlock the truststore file using [`Xpki-block-creation-truststore-password-file`](#xpki-block-creation-truststore-password-file).
-
-## Command line options
-
-### `Xpki-block-creation-crl-file`
-
-
-
-# Syntax
-
-```bash
---Xpki-block-creation-crl-file=
-```
-
-# Example
-
-```bash
---Xpki-block-creation-crl-file=/home/cert/cert.crl.pem
-```
-
-# Environment variable
-
-```bash
-BESU_XPKI_BLOCK_CREATION_CRL_FILE=/home/cert/cert.crl.pem
-```
-
-
-
-Path to the optional certificate revocation list (CRL) file.
-
-### `Xpki-block-creation-enabled`
-
-
-
-# Syntax
-
-```bash
---Xpki-block-creation-enabled[=]
-```
-
-# Example
-
-```bash
---Xpki-block-creation-enabled=true
-```
-
-# Environment variable
-
-```bash
-BESU_XPKI_BLOCK_CREATION_ENABLED=true
-```
-
-
-
-Enable PKI integration. The default is `false`.
-
-### `Xpki-block-creation-keystore-certificate-alias`
-
-
-
-# Syntax
-
-```bash
---Xpki-block-creation-keystore-certificate-alias=
-```
-
-# Example
-
-```bash
---Xpki-block-creation-keystore-certificate-alias=validatorA
-```
-
-# Environment variable
-
-```bash
-BESU_XPKI_BLOCK_CREATION_KEYSTORE_CERTIFICATE_ALIAS=validatorA
-```
-
-
-
-Alias of the certificate to be included in the blocks proposed by this validator. The default is `validator`.
-
-### `Xpki-block-creation-keystore-file`
-
-
-
-# Syntax
-
-```bash
---Xpki-block-creation-keystore-file=
-```
-
-# Example
-
-```bash
---Xpki-block-creation-keystore-file=/home/cert/keystore.jks
-```
-
-# Environment variable
-
-```bash
-BESU_XPKI_BLOCK_CREATION_KEYSTORE_FILE=/home/cert/keystore.jks
-```
-
-
-
-Keystore file containing the key and certificate for PKI block creation.
-
-### `Xpki-block-creation-keystore-password-file`
-
-
-
-# Syntax
-
-```bash
---Xpki-block-creation-keystore-password-file=
-```
-
-# Example
-
-```bash
---Xpki-block-creation-keystore-password-file=/home/cert/password.txt
-```
-
-# Environment variable
-
-```bash
-BESU_XPKI_BLOCK_CREATION_KEYSTORE_PASSWORD-FILE=/home/cert/password.txt
-```
-
-
-
-Text file containing the password to unlock the keystore file.
-
-### `Xpki-block-creation-keystore-type`
-
-
-
-# Syntax
-
-```bash
---Xpki-block-creation-keystore-type=
-```
-
-# Example
-
-```bash
---Xpki-block-creation-keystore-type=JKS
-```
-
-# Environment variable
-
-```bash
-BESU_XPKI_BLOCK_CREATION_KEYSTORE_TYPE=JKS
-```
-
-
-
-PKI keystore type. Valid options are `JKS` and `PKCS12`. The default is `JKS`.
-
-### `Xpki-block-creation-truststore-file`
-
-
-
-# Syntax
-
-```bash
---Xpki-block-creation-truststore-file=
-```
-
-# Example
-
-```bash
---Xpki-block-creation-truststore-file=/home/cert/truststore.jks
-```
-
-# Environment variable
-
-```bash
-BESU_XPKI_BLOCK_CREATION_TRUSTSTORE_FILE=/home/cert/truststore.jks
-```
-
-
-
-Truststore containing the trusted certificates for PKI block creation.
-
-### `Xpki-block-creation-truststore-password-file`
-
-
-
-# Syntax
-
-```bash
---Xpki-block-creation-truststore-password-file=
-```
-
-# Example
-
-```bash
---Xpki-block-creation-truststore-password-file=/home/cert/password.txt
-```
-
-# Environment variable
-
-```bash
-BESU_XPKI_BLOCK_CREATION_TRUSTSTORE_PASSWORD_FILE=/home/cert/password.txt
-```
-
-
-
-Text file containing the password to unlock the truststore file.
-
-### `Xpki-block-creation-truststore-type`
-
-
-
-# Syntax
-
-```bash
---Xpki-block-creation-truststore-type=
-```
-
-# Example
-
-```bash
---Xpki-block-creation-truststore-type=JKS
-```
-
-# Environment variable
-
-```bash
-BESU_XPKI_BLOCK_CREATION_TRUSTSTORE_TYPE=JKS
-```
-
-
-
-PKI truststore type. Valid options are `JKS` and `PKCS12`. The default is `JKS`.
-
-[QBFT consensus protocol]: ./consensus/qbft.md
-[certificate revocation list (CRL)]: https://www.securew2.com/blog/certificate-revocation-crl-explained
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/bootnodes.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/bootnodes.md
deleted file mode 100644
index 11787681a04..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/bootnodes.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: Bootnodes
-description: Configuring bootnodes
-sidebar_position: 3
-tags:
- - private networks
----
-
-# Configure bootnodes
-
-You can use bootnodes to initially discover peers. Bootnodes are regular nodes used to discover other nodes.
-
-In private networks for development or testing purposes, specify at least one bootnode.
-
-In production networks, [configure two or more nodes as bootnodes](#configure-bootnodes-in-a-production-network).
-
-:::tip
-
-Bootnodes and static nodes are parallel methods for finding peers. Depending on your use case, you can use only bootnodes, only static nodes, or both bootnodes and static nodes.
-
-To find peers, configure one or more bootnodes. To configure a specific set of peer connections, use [static nodes](../../../public-networks/how-to/connect/static-nodes.md).
-
-:::
-
-:::note Mainnet and public testnets
-
-For Mainnet and the Sepolia and Goerli testnets, Hyperledger Besu has an internal list of enode URLs and uses this list automatically when you specify the [`--network`](../../../public-networks/reference/cli/options.md#network) option.
-
-:::
-
-## Specify a bootnode
-
-To start a node, specify a bootnode [enode](../../../public-networks/concepts/node-keys.md) for P2P discovery, using the [`--bootnodes`](../../../public-networks/reference/cli/options.md#bootnodes) option.
-
-```bash
-besu --genesis-file=privateNetworkGenesis.json --data-path=nodeDataPath --bootnodes=enode://c35c3ec90a8a51fd5703594c6303382f3ae6b2ecb99bab2c04b3794f2bc3fc2631dabb0c08af795787a6c004d8f532230ae6e9925cbbefb0b28b79295d615f@127.0.0.1:30303
-```
-
-The default host and port advertised to other peers for P2P discovery is `127.0.0.1:30303`. To specify a different host or port, use the [`--p2p-host`](../../../public-networks/reference/cli/options.md#p2p-host) and [`--p2p-port`](../../../public-networks/reference/cli/options.md#p2p-port) options.
-
-By default, peer discovery listens on all available network interfaces. If the device Besu is running on must bind to a specific network interface, specify the interface using the [`--p2p-interface`](../../../public-networks/reference/cli/options.md#p2p-interface) option.
-
-## Configure bootnodes in a production network
-
-A network must have at least one operating bootnode. To allow for continuity in the event of failure, configure two or more bootnodes in a production network.
-
-We don't recommend putting bootnodes behind a load balancer because the [enode](../../../public-networks/concepts/node-keys.md#enode-url) relates to the node public key, IP address, and discovery ports. Any changes to a bootnode enode prevents other nodes from being able to establish a connection with the bootnode. This is why we recommend putting more bootnodes on the network itself.
-
-To ensure a bootnode enode doesn't change when recovering from a complete bootnode failure:
-
-1. Create the [node key pair](../../../public-networks/concepts/node-keys.md) (that is, the private and public key) before starting the bootnode.
-1. When creating bootnodes in the cloud (for example, AWS and Azure), attempt to assign a static IP address to them. If your network is:
-
- - Publicly accessible, assign an elastic IP.
- - Internal only, specify a private IP address when you create the instance and record this IP address.
-
-We recommend storing the bootnode configuration under source control.
-
-To allow for failure, specify all bootnodes on the command line (even to the bootnodes themselves).
-
-:::tip
-
-Having each bootnode list the other bootnodes increases the speed of discovery. Nodes ignore their own enode in the bootnodes list so it isn't required to specify different bootnode lists to the bootnodes themselves.
-
-:::
-
-## Add and remove bootnodes
-
-Adding new bootnodes is a similar process to creating bootnodes. After creating the bootnodes and adding them to the network, update the [`--bootnodes`](../../../public-networks/reference/cli/options.md#bootnodes) command line option for each node to include the new bootnodes.
-
-When adding bootnodes, you don't need to restart running nodes. By updating the [`--bootnodes`](../../../public-networks/reference/cli/options.md#bootnodes) option, the next time you restart the nodes (for example, when [upgrading](../../../public-networks/how-to/upgrade-node.md)), the nodes connect to the new bootnodes.
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/_category_.json b/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/_category_.json
deleted file mode 100644
index bc0d5770af5..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Consensus",
- "position": 1
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/add-validators-without-voting.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/add-validators-without-voting.md
deleted file mode 100644
index 70d875e33a0..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/add-validators-without-voting.md
+++ /dev/null
@@ -1,309 +0,0 @@
----
-title: Add and remove validators without voting
-description: How to add or remove validators without voting
-sidebar_position: 5
-tags:
- - private networks
----
-
-# Add and remove validators without voting
-
-[QBFT](qbft.md) or [IBFT 2.0](ibft.md) network conditions might not allow voting to change validators. For example, if a majority of the current validators are no longer participating in the network, a vote to add or remove validators won't be successful. You can bypass voting and specify new validators using a transition in the genesis file.
-
-:::caution
-
-- In most cases, add or remove validators [by voting or smart contract for QBFT](qbft.md#add-and-remove-validators); or [by voting for IBFT 2.0](ibft.md#add-and-remove-validators). Use transitions only when voting isn't possible. Using transitions requires coordinating a rolling update of all the nodes in order to pick up the configuration at the correct block height. Using transitions also leaves the validator overrides permanently in your genesis configuration.
-- Transitions are a Besu-specific feature. If you run a mixed-client QBFT network, you can't use transitions to change the validators.
-
-:::
-
-To add or remove validators without voting:
-
-1. In the genesis file, add the `transitions` configuration item where:
-
- - `` is the upcoming block at which to change validators.
- - ` ... ` are strings representing the account addresses of the validators after ``.
-
-
-
- # QBFT syntax
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- },
- "transitions": {
- "qbft": [
- {
- "block": ,
- "validators": [
- ,
- ...
-
- ]
- }
- ]
- }
- },
- ...
- }
- ```
-
- # QBFT example
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- },
- "transitions": {
- "qbft": [
- {
- "block": 25,
- "validators": [
- "0x372a70ace72b02cc7f1757183f98c620254f9c8d",
- "0x9811ebc35d7b06b3fa8dc5809a1f9c52751e1deb"
- ]
- }
- ]
- }
- },
- ...
- }
- ```
-
- # IBFT 2.0 syntax
-
- ```bash
- {
- "config": {
- ...
- "ibft2": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- },
- "transitions": {
- "ibft2": [
- {
- "block": ,
- "validators": [
- ,
- ...
-
- ]
- }
- ]
- }
- },
- ...
- }
- ```
-
- # IBFT 2.0 example
-
- ```bash
- {
- "config": {
- ...
- "ibft2": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- },
- "transitions": {
- "ibft2": [
- {
- "block": 25,
- "validators": [
- "0x372a70ace72b02cc7f1757183f98c620254f9c8d",
- "0x9811ebc35d7b06b3fa8dc5809a1f9c52751e1deb"
- ]
- }
- ]
- }
- },
- ...
- }
- ```
-
-
-
-2. Restart all nodes in the network using the updated genesis file. You can make a rolling update of the nodes, as long as they're all up before the transition block is processed.
-3. To verify the changes after the transition block, call [`qbft_getValidatorsByBlockNumber`](../../../reference/api/index.md#qbft_getvalidatorsbyblocknumber) or [`ibft_getValidatorsByBlockNumber`](../../../reference/api/index.md#ibft_getvalidatorsbyblocknumber), specifying `latest`.
-
-:::caution
-
-Don't specify a transition block in the past.
-
-Specifying a transition block in the past can result in unexpected behavior, such as causing the network to fork.
-
-:::
-
-## Override smart contract validators
-
-When using [QBFT contract validator selection](qbft.md#add-and-remove-validators-using-a-smart-contract), if network conditions require it, you can bypass the smart contract and specify new validators in the genesis file. For example, you lose quorum for your current list of contract validators, and you can't perform a transaction to vote more in.
-
-This requires temporarily [switching to block header validator selection mode](qbft.md#swap-validator-management-methods).
-
-To bypass the smart contract and specify new validators:
-
-1. In the genesis file, add a `transitions` configuration item where:
-
- - `` is the upcoming block at which to change validators.
- - `` is the validator selection mode to switch to. In this case we'll switch to the `blockheader` mode temporarily.
- - ` ... ` are strings representing the account addresses of the validators after ``. These validators only need to be sufficient to progress the chain and allow a new contract to be deployed.
-
-
-
- # Syntax
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4,
- "validatorcontractaddress": "0x0000000000000000000000000000000000007777"
- },
- "transitions": {
- "qbft": [
- {
- "block": ,
- "validatorselectionmode": ,
- "validators": [
- ,
- ...
-
- ]
- }
- ]
- }
- },
- ...
- }
- ```
-
- # Example
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4,
- "validatorcontractaddress": "0x0000000000000000000000000000000000007777"
- },
- "transitions": {
- "qbft": [
- {
- "block": 2555,
- "validatorselectionmode": "blockheader",
- "validators": [
- "0x372a70ace72b02cc7f1757183f98c620254f9c8d",
- "0x9811ebc35d7b06b3fa8dc5809a1f9c52751e1deb"
- ]
- }
- ]
- }
- },
- ...
- }
- ```
-
-
-
-1. Restart all nodes in the network using the updated genesis file. You can make a rolling update of the nodes, as long as they're all up before the transition block is processed.
-1. Deploy a new contract to the blockchain containing the desired list of validators.
-1. In the genesis file, add another `transitions` configuration item where:
-
- - `` is the upcoming block at which to change validators.
- - `` is the validator selection mode to switch to. In this case we'll switch to `contract` mode.
- - `` is the address of the new smart contract.
-
-
-
- # Syntax
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4,
- “validatorcontractaddress”: “0x0000000000000000000000000000000000007777”
- },
- "transitions": {
- "qbft": [
- {
- "block": 2555,
- "validatorselectionmode": "blockheader",
- "validators": [
- "0x372a70ace72b02cc7f1757183f98c620254f9c8d",
- "0x9811ebc35d7b06b3fa8dc5809a1f9c52751e1deb"
- ]
- },
- {
- "block": ,
- "validatorselectionmode": ,
- "validatorcontractaddress":
- }
- ]
- }
- },
- ...
- }
- ```
-
- # Example
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4,
- "validatorcontractaddress": "0x0000000000000000000000000000000000007777"
- },
- "transitions": {
- "qbft": [
- {
- "block": 2555,
- "validatorselectionmode": "blockheader",
- "validators": [
- "0x372a70ace72b02cc7f1757183f98c620254f9c8d",
- "0x9811ebc35d7b06b3fa8dc5809a1f9c52751e1deb"
- ]
- },
- {
- "block": 2755,
- "validatorselectionmode": "contract",
- "validatorcontractaddress": "0x0000000000000000000000000000000000009999"
- }
- ]
- }
- },
- ...
- }
- ```
-
-
-
-1. Restart all nodes in the network using the updated genesis file. You can make a rolling update of the nodes, as long as they're all up before the transition block is processed.
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/clique.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/clique.md
deleted file mode 100644
index 6bf2aecf81f..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/clique.md
+++ /dev/null
@@ -1,158 +0,0 @@
----
-title: Clique
-description: Hyperledger Besu Clique Proof-of-Authority (PoA) consensus protocol implementation
-sidebar_position: 4
-path: blob/master/config/src/main/resources/
-source: rinkeby.json
-tags:
- - private networks
----
-
-# Configure Clique consensus
-
-Besu implements the [Clique](https://eips.ethereum.org/EIPS/eip-225) proof of authority (PoA) [consensus protocol](index.md). Private networks can use Clique.
-
-:::danger
-
-Clique is not suitable for production environments. Use only in development environments.
-
-:::
-
-In Clique networks, approved accounts, known as signers, validate transactions and blocks. Signers take turns to create the next block. Existing signers propose and vote to [add or remove signers](#add-and-remove-signers).
-
-You can [create a private network using Clique](../../../tutorials/clique.md).
-
-## Genesis file
-
-To use Clique in a private network, Besu requires a Clique [genesis file](../../../../public-networks/concepts/genesis-file.md).
-
-A Clique genesis file defines properties specific to Clique.
-
-```json title="Example Clique genesis file"
-{
- "config": {
- "chainId": 1981,
- "berlinBlock": 0,
- "clique": {
- "blockperiodseconds": 15,
- "epochlength": 30000
- }
- },
- "coinbase": "0x0000000000000000000000000000000000000000",
- "difficulty": "0x1",
- "extraData": "0x000000000000000000000000000000000000000000000000000000000000000001a54556254bfa3db2daa7673435ec63649925c50000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
- "gasLimit": "0x1fffffffffffff",
- "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
- "nonce": "0x0",
- "timestamp": "0x5c51a607",
- "alloc": {},
- "number": "0x0",
- "gasUsed": "0x0",
- "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
-}
-```
-
-The properties specific to Clique are:
-
-- `blockperiodseconds` - The block time, in seconds.
-- `epochlength` - The number of blocks after which to reset all votes.
-- `extraData` - [Extra data](#extra-data) including the initial signers.
-
-### Extra data
-
-The `extraData` property consists of:
-
-- 0x prefix.
-- 32 bytes of vanity data.
-- A list of initial signer addresses (at least one initial signer is required). 20 bytes for each signer.
-- 65 bytes for the proposer signature. In the genesis block there is no initial proposer, so the proposer signature is all zeros.
-
-### One initial signer
-
-![One Initial Signer](../../../../assets/images/CliqueOneIntialSigner.png)
-
-### Two initial signers
-
-![Two Initial Signers](../../../../assets/images/CliqueTwoIntialSigners.png)
-
-### Post-Merge configuration
-
-After [The Merge](../../../../public-networks/concepts/the-merge.md), the following block fields are modified or deprecated. Their fields **must** contain only the constant values from the following chart.
-
-| Field | Constant value | Comment |
-| --- | --- | --- |
-| **`ommersHash`** | `0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347` | `= Keccak256(RLP([]))` |
-| **`difficulty`** | `0` | Replaced with `prevrandao` |
-| **`mixHash`** | `0x0000000000000000000000000000000000000000000000000000000000000000` | Replaced with `prevrandao` |
-| **`nonce`** | `0x0000000000000000` | |
-| **`ommers`** | `[]` | `RLP([]) = 0xc0` |
-
-Additionally, [`extraData`](#extra-data) is limited to 32 bytes of vanity data after The Merge.
-
-## Connect to a Clique network
-
-To start a node on a Clique private network, use the [`--genesis-file`](../../../../public-networks/reference/cli/options.md#genesis-file) option to specify the custom genesis file.
-
-## Add and remove signers
-
-Existing signers propose and vote to add or remove validators using the Clique JSON-RPC API methods. Enable the HTTP interface with [`--rpc-http-enabled`](../../../../public-networks/reference/cli/options.md#rpc-http-enabled) or the WebSocket interface with [`--rpc-ws-enabled`](../../../../public-networks/reference/cli/options.md#rpc-ws-enabled).
-
-The Clique API methods are disabled by default. To enable them, specify the [`--rpc-http-api`](../../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../../public-networks/reference/cli/options.md#rpc-ws-api) option and include `CLIQUE`.
-
-The methods to add or remove signers are:
-
-- [`clique_propose`](../../../reference/api/index.md#clique_propose).
-- [`clique_getSigners`](../../../reference/api/index.md#clique_getsigners).
-- [`clique_discard`](../../../reference/api/index.md#clique_discard).
-
-To view signer metrics for a specified block range, call [`clique_getSignerMetrics`](../../../reference/api/index.md#clique_getsignermetrics).
-
-### Add a signer
-
-To propose adding a signer to a Clique network, call [`clique_propose`](../../../reference/api/index.md#clique_propose), specifying the address of the proposed signer and `true`. A majority of signers must execute the call.
-
-```bash title="JSON-RPC clique_propose request example"
-curl -X POST --data '{"jsonrpc":"2.0","method":"clique_propose","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73", true], "id":1}'
-```
-
-When the signer creates the next block, the signer adds a vote to the block for the proposed signer.
-
-When more than 50% of the existing signers propose adding the signer, with their votes distributed in blocks, the signer can begin signing blocks.
-
-To return a list of signers and confirm the addition of a proposed signer, call [`clique_getSigners`](../../../reference/api/index.md#clique_getsigners).
-
-```bash title="JSON-RPC clique_getSigners request example"
-curl -X POST --data '{"jsonrpc":"2.0","method":"clique_getSigners","params":["latest"], "id":1}'
-```
-
-To discard your proposal after confirming the addition of a signer, call [`clique_discard`](../../../reference/api/index.md#clique_discard) specifying the address of the proposed signer.
-
-```bash title="JSON-RPC clique_discard request example"
-curl -X POST --data '{"jsonrpc":"2.0","method":"clique_discard","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73"], "id":1}'
-```
-
-### Remove a signer
-
-The process for removing a signer from a Clique network is the same as [adding a signer](#add-a-signer), except you specify `false` as the second parameter of [`clique_propose`](../../../reference/api/index.md#clique_propose).
-
-### Epoch transition
-
-At each epoch transition, Clique discards all pending votes collected from received blocks. Existing proposals remain in effect and signers re-add their vote the next time they create a block.
-
-Define the number of blocks between epoch transitions in the [Clique genesis file](#genesis-file).
-
-## Limitations
-
-In Clique, blocks created by in-turn validators are published immediately. Out-of-turn validators create blocks that are published after a short delay. In-turn blocks have a higher difficulty than out-of-turn blocks, which allows small forks to resolve to the chain with more in-turn blocks.
-
-However, when the out-of-turn delay is shorter than the block propagation delay, out-of-turn blocks may be published before in-turn blocks. This may cause large, irresolvable forks in a network.
-
-:::tip
-
-We recommend using a more updated consensus protocol such as [IBFT 2.0](ibft.md) or [QBFT](qbft.md).
-
-:::
-
-
-
-\*[vanity data]: Signers can include anything they like as vanity data.
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/ibft.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/ibft.md
deleted file mode 100644
index de26b5a2a2b..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/ibft.md
+++ /dev/null
@@ -1,501 +0,0 @@
----
-title: IBFT 2.0
-description: Hyperledger Besu IBFT 2.0 proof of authority (PoA) consensus protocol implementation
-sidebar_position: 3
-tags:
- - private networks
----
-
-# Configure IBFT 2.0 consensus
-
-Besu implements the IBFT 2.0 proof of authority (PoA) [consensus protocol](index.md). IBFT 2.0 is supported for existing private networks, but [QBFT](qbft.md) is the recommended enterprise-grade consensus protocol for private networks.
-
-In IBFT 2.0 networks, approved accounts, known as validators, validate transactions and blocks. Validators take turns to create the next block. Before inserting the block onto the chain, a super-majority (greater than or equal to 2/3) of validators must first sign the block.
-
-Existing validators propose and vote to [add or remove validators](#add-and-remove-validators).
-
-You can [create a private network using IBFT](../../../tutorials/ibft/index.md).
-
-:::danger
-
-Configure your network to ensure you never lose more than 1/3 of your validators. If more than 1/3 of validators stop participating, new blocks are no longer created, and the network stalls. It may take significant time to recover once nodes are restarted.
-
-:::
-
-:::tip
-
-You can use a plugin to securely store a validator's key using the [`--security-module`](../../../../public-networks/reference/cli/options.md#security-module) option.
-
-:::
-
-## Genesis file
-
-To use IBFT 2.0, Besu requires an IBFT 2.0 [genesis file](../../../../public-networks/concepts/genesis-file.md). The genesis file defines properties specific to IBFT 2.0.
-
-```json title="Example IBFT 2.0 genesis file"
-{
- "config": {
- "chainId": 1981,
- "berlinBlock": 0,
- "ibft2": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4,
- "blockreward": "5000000000000000",
- "miningbeneficiary": "0xfe3b557e8fb62b89f4916b721be55ceb828dbd73"
- }
- },
- "nonce": "0x0",
- "timestamp": "0x58ee40ba",
- "extraData": "0xf83ea00000000000000000000000000000000000000000000000000000000000000000d594c2ab482b506de561668e07f04547232a72897daf808400000000c0",
- "gasLimit": "0x1fffffffffffff",
- "difficulty": "0x1",
- "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365",
- "alloc": {}
-}
-```
-
-The properties specific to IBFT 2.0 are:
-
-- `blockperiodseconds` - The minimum block time, in seconds.
-- `epochlength` - The number of blocks after which to reset all votes.
-- `requesttimeoutseconds` - The timeout for each consensus round before a round change, in seconds.
-- `blockreward` - Optional reward amount in Wei to reward the beneficiary. Defaults to zero (0). Can be specified as a hexadecimal (with 0x prefix) or decimal string value. If set, then all nodes on the network must use the identical value.
-- `miningbeneficiary` - Optional beneficiary of the `blockreward`. Defaults to the validator that proposes the block. If set, then all nodes on the network must use the same beneficiary.
-- `extraData` - RLP encoded [extra data](#extra-data).
-
-:::caution
-
-We don't recommend changing `epochlength` in a running network. Changing the `epochlength` after genesis can result in illegal blocks.
-
-:::
-
-:::caution Invalid block header error
-
-When adding a new node, if a `TimeStampMoreRecentThanParent | Invalid block header` error occurs, the genesis file of the new node specifies a higher `blockperiodseconds` than the imported chain. The imported chain makes new blocks faster than the genesis file allows and Besu rejects them with this error. This error most often occurs when importing chains from older versions of Besu.
-
-Decrease the `blockperiodseconds` in the new IBFT 2.0 genesis file to a lower value that satisfies the block header validation.
-
-:::
-
-If the error reads `| TimestampMoreRecentThanParent | Invalid block header: timestamp 1619660141 is only 3 seconds newer than parent timestamp 1619660138. Minimum 4 seconds`, decrease the `blockperiodseconds` from 4 seconds to 3 seconds to match the imported chain.
-
-After you update the new genesis file, if the imported chain has a `blockperiodseconds` value set lower than you prefer, you can adjust it by [configuring the block time on an existing IBFT 2.0 network](#configure-block-time-on-an-existing-network).
-
-The properties with specific values in the IBFT 2.0 genesis files are:
-
-- `nonce` - `0x0`
-- `difficulty` - `0x1`
-- `mixHash` - `0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365` for Istanbul block identification
-
-To start a node on an IBFT 2.0 private network, use the [`--genesis-file`](../../../../public-networks/reference/cli/options.md#genesis-file) option to specify the custom genesis file.
-
-### Extra data
-
-The `extraData` property is an RLP encoding of:
-
-- 32 bytes of vanity data.
-- A list of validator addresses.
-- Any validator votes. No vote is included in the genesis block.
-- The round the block was created on. The round in the genesis block is 0.
-- A list of seals of the validators (signed block hashes). No seals are included in the genesis block.
-
-In the genesis block, the important information in the extra data is the list of validators. All other details have empty values. Formally, `extraData` in the genesis block contains `RLP([32 bytes Vanity, List, No Vote, Round=Int(0), 0 Seals])`.
-
-:::info
-
-RLP encoding is a space-efficient object serialization scheme used in Ethereum.
-
-:::
-
-#### Generate extra data
-
-To generate the `extraData` RLP string for inclusion in the genesis file, use the [`rlp encode`](../../../../public-networks/reference/cli/subcommands.md#rlp) Besu subcommand.
-
-```bash title="Example"
-besu rlp encode --from=toEncode.json
-```
-
-Where the `toEncode.json` file contains a list of the initial validators, in ascending order. To write the validator address and copy it to the `toEncode.json` file, use the [`public-key export-address`](../../../../public-networks/reference/cli/subcommands.md#export-address) Besu subcommand. For example:
-
-```json title="One initial validator in toEncode.json file"
-["9811ebc35d7b06b3fa8dc5809a1f9c52751e1deb"]
-```
-
-Copy the RLP encoded data to the `extraData` property in the genesis file.
-
-### Block time
-
-When the protocol receives a new chain head, the block time (`blockperiodseconds`) and round timeout (`requesttimeoutseconds`) timers start. When `blockperiodseconds` expires, the protocol proposes a new block.
-
-If `requesttimeoutseconds` expires before adding the proposed block, a round change occurs, with the block time and timeout timers reset. The timeout period for the new round is two times `requesttimeoutseconds`. The timeout period continues to double each time a round fails to add a block.
-
-Usually, the protocol adds the proposed block before reaching `requesttimeoutseconds`. A new round then starts, resetting the block time and round timeout timers. When `blockperiodseconds` expires, the protocol proposes the next new block.
-
-:::danger
-
-If more than 1/3 of validators stop participating, new blocks can no longer be created and `requesttimeoutseconds` doubles with each round change. The quickest method to resume block production is to restart all validators, which resets `requesttimeoutseconds` to its genesis value.
-
-:::
-
-Once `blockperiodseconds` is over, the time from proposing a block to adding the block is small (usually around one second) even in networks with geographically dispersed validators.
-
-An internal network run by ConsenSys had four geographically dispersed validators in Sweden, Sydney, and two in North Virginia. With a `blockperiodseconds` of 5 and a `requesttimeoutseconds` of 10, the testnet consistently created blocks with a five second block time.
-
-#### Tune block timeout
-
-To tune the block timeout for your network deployment:
-
-1. Set `blockperiodseconds` to your desired block time and `requesttimeoutseconds` to two times `blockperiodseconds`.
-1. Reduce `requesttimeoutseconds` until you start to see round changes occurring.
-1. Increase `requesttimeoutseconds` to the value where round changes are no longer occurring.
-
-:::tip
-
-View [`TRACE` logs](../../../../public-networks/reference/api/index.md#trace-methods) to see round change log messages.
-
-:::
-
-Use a [transition](#transitions) to update the `blockperiodseconds` in an existing network.
-
-### Optional configuration options
-
-Optional configuration options in the genesis file are:
-
-- `messageQueueLimit` - In large networks with limited resources, increasing the message queue limit might help with message activity surges. The default is 1000.
-- `duplicateMessageLimit` - If the same node is retransmitting messages, increasing the duplicate message limit might reduce the number of retransmissions. A value of two to three times the number of validators is usually enough. The default is 100.
-- `futureMessagesLimit` - The future messages buffer holds messages for a future chain height. For large networks, increasing the future messages limit might be useful. The default is 1000.
-- `futureMessagesMaxDistance` - The maximum height from the current chain height for buffering messages in the future messages buffer. The default is 10.
-
-### Post-Merge configuration
-
-After [The Merge](../../../../public-networks/concepts/the-merge.md), the following block fields are modified or deprecated. Their fields **must** contain only the constant values from the following chart.
-
-| Field | Constant value | Comment |
-| --- | --- | --- |
-| **`ommersHash`** | `0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347` | `= Keccak256(RLP([]))` |
-| **`difficulty`** | `0` | Replaced with `prevrandao` |
-| **`mixHash`** | `0x0000000000000000000000000000000000000000000000000000000000000000` | Replaced with `prevrandao` |
-| **`nonce`** | `0x0000000000000000` | |
-| **`ommers`** | `[]` | `RLP([]) = 0xc0` |
-
-Additionally, [`extraData`](#extra-data) is limited to 32 bytes of vanity data after The Merge.
-
-## Add and remove validators
-
-Existing validators propose and vote to add or remove validators using the IBFT 2.0 JSON-RPC API methods. Enable the HTTP interface with [`--rpc-http-enabled`](../../../../public-networks/reference/cli/options.md#rpc-http-enabled) or the WebSocket interface with [`--rpc-ws-enabled`](../../../../public-networks/reference/cli/options.md#rpc-ws-enabled).
-
-The IBFT 2.0 API methods are disabled by default. To enable them, specify the [`--rpc-http-api`](../../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../../public-networks/reference/cli/options.md#rpc-ws-api) option and include `IBFT`.
-
-The methods to add or remove validators are:
-
-- [`ibft_getPendingVotes`](../../../reference/api/index.md#ibft_getpendingvotes).
-- [`ibft_proposeValidatorVote`](../../../reference/api/index.md#ibft_proposevalidatorvote).
-- [`ibft_discardValidatorVote`](../../../reference/api/index.md#ibft_discardvalidatorvote).
-
-To view validator metrics for a specified block range, use [`ibft_getSignerMetrics`](../../../../public-networks/reference/api/index.md#ibft_getsignermetrics).
-
-:::note
-
-If network conditions render it impossible to add and remove validators by voting, you can [add and remove validators without voting](add-validators-without-voting.md).
-
-:::
-
-### Add a validator
-
-To propose adding a validator to an IBFT 2.0 network, call [`ibft_proposeValidatorVote`](../../../reference/api/index.md#ibft_proposevalidatorvote), specifying the address of the proposed validator and `true`. A majority of validators must execute the call.
-
-```bash title="JSON-RPC ibft_proposeValidatorVote request example"
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_proposeValidatorVote","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73", true], "id":1}'
-```
-
-When the validator proposes the next block, the protocol inserts one proposal received from [`ibft_proposeValidatorVote`](../../../reference/api/index.md#ibft_proposevalidatorvote) into the block. If blocks include all proposals, subsequent blocks proposed by the validator will not contain a vote.
-
-When more than 50% of the existing validators have published a matching proposal, the protocol adds the proposed validator to the validator pool and the validator can begin validating blocks.
-
-To return a list of validators and confirm the addition of a proposed validator, use [`ibft_getValidatorsByBlockNumber`](../../../reference/api/index.md#ibft_getvalidatorsbyblocknumber).
-
-```bash title="JSON-RPC ibft_getValidatorsByBlockNumber request example"
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_getValidatorsByBlockNumber","params":["latest"], "id":1}'
-```
-
-To discard your proposal after confirming the addition of a validator, call [`ibft_discardValidatorVote`](../../../reference/api/index.md#ibft_discardvalidatorvote), specifying the address of the proposed validator.
-
-```bash title="JSON-RPC ibft_discardValidatorVote request example"
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_discardValidatorVote","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73"], "id":1}'
-```
-
-### Remove a validator
-
-The process for removing a validator from an IBFT 2.0 network is the same as [adding a validator](#add-a-validator) except you specify `false` as the second parameter of [`ibft_proposeValidatorVote`](../../../reference/api/index.md#ibft_proposevalidatorvote).
-
-### Epoch transition
-
-At each epoch transition, IBFT 2.0 discards all pending votes collected from received blocks. Existing proposals remain in effect and validators re-add their vote the next time they create a block.
-
-An epoch transition occurs every `epochLength` blocks. Define `epochlength` in the [IBFT 2.0 genesis file](#genesis-file).
-
-### Minimum number of validators
-
-IBFT 2.0 requires four validators to be Byzantine fault tolerant. Byzantine fault tolerance is the ability for a blockchain network to function correctly and reach consensus despite nodes failing or propagating incorrect information to peers.
-
-### Maximum number of validators
-
-As the number of validators increase, the message complexity increases, which can decrease performance. In [network tests](https://wiki.hyperledger.org/display/BESU/Maximum+Validator+count+for+an+IBFT2+Network), IBFT 2.0 handles up to 30 validators with no loss of performance.
-
-Non-validator nodes don't affect performance and don't count towards the maximum limit.
-
-## Transitions
-
-The `transitions` genesis configuration item allows you to specify a future block number at which to change IBFT 2.0 network configuration in an existing network. For example, you can update the [block time](#configure-block-time-on-an-existing-network-deployment), [block reward](#configure-block-rewards-on-an-existing-network-deployment), or [mining beneficiary](#configure-the-mining-beneficiary-on-an-existing-network-deployment).
-
-:::caution
-
-Do not specify a transition block in the past. Specifying a transition block in the past could result in unexpected behavior, such as causing the network to fork.
-
-:::
-
-### Configure block time on an existing network deployment
-
-To update an existing network with a new `blockperiodseconds`:
-
-1. Stop all nodes in the network.
-1. In the [genesis file](#genesis-file), add the `transitions` configuration item where:
-
- - `` is the upcoming block at which to change `blockperiodseconds`.
- - `` is the updated value for `blockperiodseconds`.
-
-
-
- # Syntax
-
- ```bash
- {
- "config": {
- ...
- "ibft2": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- },
- "transitions": {
- "ibft2": [
- {
- "block": ,
- "blockperiodseconds":
- }
- ]
- }
- },
- ...
- }
- ```
-
- # Example
-
- ```bash
- {
- "config": {
- ...
- "ibft2": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- },
- "transitions": {
- "ibft2": [
- {
- "block": 1240,
- "blockperiodseconds": 4
- }
- ]
- }
- },
- ...
- }
- ```
-
-
-
-1. Restart all nodes in the network using the updated genesis file.
-1. To verify the changes after the transition block, call [`ibft_getValidatorsByBlockNumber`](../../../../public-networks/reference/api/index.md#ibft_getvalidatorsbyblocknumber), specifying `latest`.
-
-### Configure block rewards on an existing network deployment
-
-To update an existing network with a new `blockreward`:
-
-1. Stop all nodes in the network.
-1. In the [genesis file](#genesis-file), add the `transitions` configuration item where:
-
- - `` is the upcoming block at which to change `blockreward`.
- - `` is the updated value for `blockreward`.
-
-
-
- # Syntax
-
- ```bash
- {
- "config": {
- ...
- "ibft2": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- "blockreward": "5000000000000000"
- },
- "transitions": {
- "ibft2": [
- {
- "block": ,
- "blockreward":
- },
- {
- "block": ,
- "blockreward":
- },
- {
- "block": ,
- "blockreward":
- }
- ]
- }
- },
- ...
- }
- ```
-
- # Example
-
- ```bash
- {
- "config": {
- ...
- "ibft2": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- "blockreward": "5000000000000000"
- },
- "transitions": {
- "ibft2": [
- {
- "block": 10,
- "blockreward": "6000000000000000"
- },
- {
- "block": 15,
- "blockreward": "75000000000000000"
- },
- {
- "block": 20,
- "blockreward": "0"
- }
- ]
- }
- },
- ...
- }
- ```
-
-
-
- :::note
-
- You can add multiple `blockreward` updates in one transition object by specifying multiple future blocks.
-
- :::
-
-1. Restart all nodes in the network using the updated genesis file.
-
-### Configure the mining beneficiary on an existing network deployment
-
-To update an existing network with a new mining beneficiary:
-
-1. Stop all nodes in the network.
-1. In the [genesis file](#genesis-file), add the `transitions` configuration item where:
-
- - `` is the upcoming block at which to change `miningbeneficiary`.
- - `` is the updated 20-byte address for `miningbeneficiary`. Starting at ``, block rewards go to this address.
-
-
-
- # Syntax
-
- ```bash
- {
- "config": {
- "chainId": 999,
- "berlinBlock": 0,
- "ibft2": {
- "blockperiodseconds": 1,
- "epochlength": 30000,
- "requesttimeoutseconds": 5,
- "blockreward": "5000000000000000000",
- "miningbeneficiary": "0x0000000000000000000000000000000000000001"
- },
- "transitions": {
- "ibft2": [
- {
- "block": ,
- "miningbeneficiary":
- },
- {
- "block": ,
- "miningbeneficiary":
- }
- ]
- }
- },
- ...
- }
- ```
-
- # Example
-
- ```bash
- {
- "config": {
- "chainId": 999,
- "berlinBlock": 0,
- "ibft2": {
- "blockperiodseconds": 1,
- "epochlength": 30000,
- "requesttimeoutseconds": 5,
- "blockreward": "5000000000000000000",
- "miningbeneficiary": "0x0000000000000000000000000000000000000001"
- },
- "transitions": {
- "ibft2": [
- {
- "block": 10000,
- "miningbeneficiary": "",
- },
- {
- "block": 20000,
- "miningbeneficiary": "0x0000000000000000000000000000000000000002",
- }
- ]
- }
- },
- ...
- }
- ```
-
-
-
- :::note
-
- Setting the `miningbeneficiary` to an empty value clears out any override so that block rewards go to the block producer rather than a global override address.
-
- :::
-
-1. Restart all nodes in the network using the updated genesis file.
-
-
-
-_[vanity data]: Validators can include anything they like as vanity data. _[RLP]: Recursive Length Prefix
-
-```
-
-```
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/index.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/index.md
deleted file mode 100644
index 8ea4813a032..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/index.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Consensus protocols
-description: Besu consensus protocols
-sidebar_position: 1
-tags:
- - private networks
----
-
-# Consensus protocols
-
-Besu supports the following consensus protocols:
-
-- [QBFT](qbft.md) (proof of authority) - The recommended enterprise-grade consensus protocol for private networks.
-- [IBFT 2.0](ibft.md) (proof of authority) - Supported for existing private networks.
-- [Clique](clique.md) (proof of authority) - Not recommended for production use.
-- [Proof of stake](../../../../public-networks/concepts/proof-of-stake/index.md) - Used on Ethereum Mainnet and public testnets.
-- [Ethash](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/) (proof of work) - Can be used in [small development networks](../../../tutorials/ethash.md).
-
-See a [comparison of the proof of authority consensus protocols](../../../concepts/poa.md).
-
-The `config` property in the genesis file specifies the consensus protocol for a chain.
-
-
-
-# Ethash
-
-```json
-{
- "config": {
- ...
- "ethash": {
- ...
- }
- },
- ...
-}
-```
-
-# Clique
-
-```json
-{
- "config": {
- ...
- "clique": {
- ...
- }
- },
- ...
-}
-```
-
-# IBFT 2.0
-
-```json
-{
- "config": {
- ...
- "ibft2": {
- ...
- }
- },
- ...
-}
-```
-
-# QBFT
-
-```json
-{
- "config": {
- ...
- "qbft": {
- ...
- }
- },
- ...
-}
-```
-
-
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/qbft.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/qbft.md
deleted file mode 100644
index 727f2662887..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/consensus/qbft.md
+++ /dev/null
@@ -1,695 +0,0 @@
----
-title: QBFT
-description: Hyperledger Besu QBFT proof of authority (PoA) consensus protocol implementation
-sidebar_position: 2
-tags:
- - private networks
----
-
-# Configure QBFT consensus
-
-Hyperledger Besu implements the QBFT proof of authority (PoA) [consensus protocol](index.md). QBFT is the recommended enterprise-grade consensus protocol for private networks.
-
-In QBFT networks, approved accounts, known as validators, validate transactions and blocks. Validators take turns to create the next block. Before inserting the block onto the chain, a super-majority (greater than or equal to 2/3) of validators must first sign the block.
-
-Existing validators propose and vote to [add or remove validators](#add-and-remove-validators).
-
-You can [create a private network using QBFT](../../../tutorials/qbft.md).
-
-:::caution
-
-Configure your network to ensure you never lose more than 1/3 your validators. If more than 1/3 of validators stop participating, new blocks are no longer created, and the network stalls. It may take significant time to recover once nodes are restarted.
-
-:::
-
-:::tip
-
-You can use a plugin to securely store a validator's key using the [`--security-module`](../../../../public-networks/reference/cli/options.md#security-module) option.
-
-:::
-
-## Genesis file
-
-To use QBFT, define a [genesis file](../../../../public-networks/concepts/genesis-file.md) that contains the QBFT properties.
-
-The genesis file differs depending on the [validator management method](#add-and-remove-validators) you intend to use.
-
-:::note
-
-You can use a [transitions](#transitions) to change the `blockperiodseconds` or validator management method of the network at a later time.
-
-:::
-
-
-
-# Block header validator selection
-
-```json
-{
- "config": {
- "chainid": 1337,
- "berlinBlock": 0,
- "qbft": {
- "epochlength": 30000,
- "blockperiodseconds": 5,
- "requesttimeoutseconds": 10
- }
- },
- "nonce": "0x0",
- "timestamp": "0x5b3d92d7",
- "extraData": "0xf87aa00000000000000000000000000000000000000000000000000000000000000000f8549464a702e6263b7297a96638cac6ae65e6541f4169943923390ad55e90c237593b3b0e401f3b08a0318594aefdb9a738c9f433e5b6b212a6d62f6370c2f69294c7eeb9a4e00ce683cf93039b212648e01c6c6b78c080c0",
- "gasLimit": "0x29b92700",
- "difficulty": "0x1",
- "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365",
- "coinbase": "0x0000000000000000000000000000000000000000",
- "alloc": {
- "64d9be4177f418bcf4e56adad85f33e3a64efe22": {
- "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
- },
- "9f66f8a0f0a6537e4a36aa1799673ea7ae97a166": {
- "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
- },
- "a7f25969fb6f3d5ac09a88862c90b5ff664557a7": {
- "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
- },
- "f4bbfd32c11c9d63e9b4c77bb225810f840342df": {
- "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
- }
- },
- "number": "0x0",
- "gasUsed": "0x0",
- "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
-}
-```
-
-# Contract validator selection
-
-```json
-{
- "config": {
- "chainid": 1337,
- "berlinBlock": 0,
- "qbft": {
- "epochlength": 30000,
- "blockperiodseconds": 5,
- "requesttimeoutseconds": 10,
- "validatorcontractaddress": "0x0000000000000000000000000000000000007777"
- }
- },
- "nonce": "0x0",
- "timestamp": "0x5b3d92d7",
- "extraData": "0xe5a00000000000000000000000000000000000000000000000000000000000000000c0c080c0",
- "gasLimit": "0x29b92700",
- "difficulty": "0x1",
- "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365",
- "coinbase": "0x0000000000000000000000000000000000000000",
- "alloc": {
- "64d9be4177f418bcf4e56adad85f33e3a64efe22": {
- "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
- },
- "9f66f8a0f0a6537e4a36aa1799673ea7ae97a166": {
- "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
- },
- "a7f25969fb6f3d5ac09a88862c90b5ff664557a7": {
- "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
- },
- "f4bbfd32c11c9d63e9b4c77bb225810f840342df": {
- "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
- },
- "0x0000000000000000000000000000000000007777": {
- "comment": "validator smart contract",
- "balance": "0",
- "code": "0x608060405234801561001057600080fd5b50600436106100a5576000357c0100000000000000000000000000000000000000000000000000000000900480639692ea25116100785780639692ea2514610113578063b4ec9ac114610126578063b7ab4db514610139578063c76f24371461014e57600080fd5b80631c5a9d9c146100aa578063508adcfc146100bf57806351b42b00146100db5780635dc43899146100e3575b600080fd5b6100bd6100b8366004611399565b610161565b005b6100c860035481565b6040519081526020015b60405180910390f35b6100bd6104aa565b6100f66100f1366004611399565b61074e565b6040805193845260208401929092521515908201526060016100d2565b6100bd610121366004611399565b610bbd565b6100bd610134366004611399565b610deb565b6101416110a3565b6040516100d291906113c9565b6100bd61015c366004611399565b611105565b3360009081526001602052604090205460ff1661019c5760405160e560020a62461bcd02815260040161019390611416565b60405180910390fd5b600160a060020a03811661021b5760405160e560020a62461bcd02815260206004820152602860248201527f63616e6e6f742061637469766174652076616c696461746f722077697468206160448201527f64647265737320300000000000000000000000000000000000000000000000006064820152608401610193565b60005b6000548110156102b7576000818154811061023b5761023b611505565b600091825260209091200154600160a060020a03838116911614156102a55760405160e560020a62461bcd02815260206004820152601b60248201527f76616c696461746f7220697320616c72656164792061637469766500000000006044820152606401610193565b806102af816114b8565b91505061021e565b33600090815260016020526040902054610100900460ff16156103345733600090815260016020526040812054815484929162010000900460ff1690811061030157610301611505565b9060005260206000200160006101000a815481600160a060020a030219169083600160a060020a03160217905550610432565b600054610100116103b05760405160e560020a62461bcd02815260206004820152602e60248201527f6e756d626572206f662076616c696461746f72732063616e6e6f74206265206c60448201527f6172676572207468616e203235360000000000000000000000000000000000006064820152608401610193565b3360009081526001602081905260408220805461ff001981166101009081178355845460ff16620100000262ffff001990921691909117179055815490810182559080527f290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563018054600160a060020a038416600160a060020a03199091161790555b600160a060020a0382166000818152600260205260408082208054600160a060020a03191633908117909155915490519192917fbdea108da876d927928b65816d521f940fd6dc068dc0e02ba434e0ed0f2d915f9161049e916001909182521515602082015260400190565b60405180910390a35050565b3360009081526001602052604090205460ff166104dc5760405160e560020a62461bcd02815260040161019390611416565b6000546001106105315760405160e560020a62461bcd02815260206004820181905260248201527f63616e6e6f742064656163746976617465206c6173742076616c696461746f726044820152606401610193565b33600090815260016020526040902054610100900460ff166105be5760405160e560020a62461bcd02815260206004820152602860248201527f73656e64657220646f6573206e6f74206861766520616e20616374697665207660448201527f616c696461746f720000000000000000000000000000000000000000000000006064820152608401610193565b336000908152600160205260408120805461ff0019169081905581546201000090910460ff1691908190839081106105f8576105f8611505565b60009182526020822001548154600160a060020a03909116925081906106209060019061148a565b8154811061063057610630611505565b60009182526020822001548154600160a060020a03909116925082919060ff861690811061066057610660611505565b60009182526020808320919091018054600160a060020a031916600160a060020a03948516179055838316825260028152604080832054909316825260019052908120805462ff000019166201000060ff8716021790558054806106c6576106c66114ec565b6000828152602080822060001990840181018054600160a060020a03199081169091559301909355600160a060020a03851680825260028452604080832080549094169093558154835190815293840191909152339290917fbdea108da876d927928b65816d521f940fd6dc068dc0e02ba434e0ed0f2d915f910160405180910390a3505050565b336000908152600160205260408120548190819060ff166107845760405160e560020a62461bcd02815260040161019390611416565b60005b600160a060020a03851660009081526004602052604090205481101561082357600160a060020a038516600090815260046020526040812080546001929190849081106107d6576107d6611505565b6000918252602080832090910154600160a060020a0316835282019290925260400190205460ff1615610811578361080d816114b8565b9450505b8061081b816114b8565b915050610787565b5060026003546108339190611465565b831115610b8657600160a060020a038416600090815260046020526040812061085b9161135f565b600160a060020a03841660009081526001602052604090205460ff1615610ab0576003805490600061088c836114a1565b9091555050600160a060020a038416600090815260016020526040902054610100900460ff1615610a89576000546001106109325760405160e560020a62461bcd02815260206004820152603860248201527f63616e6e6f742072656d6f766520616c6c6f776564206163636f756e7420776960448201527f7468206c617374206163746976652076616c696461746f7200000000000000006064820152608401610193565b600160a060020a03841660009081526001602052604081205481546201000090910460ff169160029181908490811061096d5761096d611505565b6000918252602080832090910154600160a060020a0316835282019290925260400181208054600160a060020a0319169055805481906109af9060019061148a565b815481106109bf576109bf611505565b60009182526020822001548154600160a060020a03909116925082919060ff85169081106109ef576109ef611505565b600091825260208220018054600160a060020a031916600160a060020a039390931692909217909155805480610a2757610a276114ec565b6000828152602080822083016000199081018054600160a060020a0319169055909201909255600160a060020a0392831682526002815260408083205490931682526001905220805460ff909216620100000262ff0000199092169190911790555b600160a060020a0384166000908152600160205260409020805462ffffff19169055610b32565b60038054906000610ac0836114b8565b909155505060408051606081018252600180825260006020808401828152848601838152600160a060020a038b16845293909152939020915182549351915160ff16620100000262ff0000199215156101000261ff00199215159290921661ffff199095169490941717169190911790555b600160a060020a03841660008181526001602090815260409182902054915160ff909216151582527f94154efdb7741591680558a88682943a481f1a468cb81f46fe7f8cead2e40519910160405180910390a25b826002600354610b969190611465565b610ba190600161144d565b6002600354610bb09190611465565b9196909550931192915050565b3360009081526001602052604090205460ff16610bef5760405160e560020a62461bcd02815260040161019390611416565b60005b600160a060020a038216600090815260046020526040902054811015610d4b57600160a060020a0382166000908152600460205260409020805433919083908110610c3f57610c3f611505565b600091825260209091200154600160a060020a03161415610d3957600160a060020a03821660009081526004602052604090208054610c809060019061148a565b81548110610c9057610c90611505565b6000918252602080832090910154600160a060020a03858116845260049092526040909220805491909216919083908110610ccd57610ccd611505565b60009182526020808320919091018054600160a060020a031916600160a060020a039485161790559184168152600490915260409020805480610d1257610d126114ec565b60008281526020902081016000199081018054600160a060020a0319169055019055610d4b565b80610d43816114b8565b915050610bf2565b50600160a060020a0381166000818152600460205260409020546003543392917f91ad81c76cda7c0ccc324838ae74757eab38b250da52daab154daf408cb3bcba91610d9990600290611465565b610da490600161144d565b600160a060020a0386166000908152600160208181526040928390205483519586529085019390935260ff909216159083015260608201526080015b60405180910390a350565b3360009081526001602052604090205460ff16610e1d5760405160e560020a62461bcd02815260040161019390611416565b600160a060020a038116610e765760405160e560020a62461bcd02815260206004820152601f60248201527f6163636f756e7420746f2062652061646465642063616e6e6f742062652030006044820152606401610193565b600160a060020a03811660009081526001602081905260409091205460ff16151514610f0d5760405160e560020a62461bcd02815260206004820152602a60248201527f6163636f756e7420746f2072656d6f7665206973206e6f74206f6e207468652060448201527f616c6c6f77206c697374000000000000000000000000000000000000000000006064820152608401610193565b60005b600160a060020a038216600090815260046020526040902054811015610ffb57600160a060020a0382166000908152600460205260409020805433919083908110610f5d57610f5d611505565b600091825260209091200154600160a060020a03161415610fe95760405160e560020a62461bcd02815260206004820152602a60248201527f73656e6465722068617320616c726561647920766f74656420746f2072656d6f60448201527f7665206163636f756e74000000000000000000000000000000000000000000006064820152608401610193565b80610ff3816114b8565b915050610f10565b50600160a060020a0381166000818152600460209081526040822080546001810182558184529183209091018054600160a060020a0319163390811790915591839052546003549192917f91ad81c76cda7c0ccc324838ae74757eab38b250da52daab154daf408cb3bcba919061107490600290611465565b61107f90600161144d565b60408051928352602083019190915260009082018190526060820152608001610de0565b606060008054806020026020016040519081016040528092919081815260200182805480156110fb57602002820191906000526020600020905b8154600160a060020a031681526001909101906020018083116110dd575b5050505050905090565b3360009081526001602052604090205460ff166111375760405160e560020a62461bcd02815260040161019390611416565b600160a060020a03811660009081526001602052604090205460ff16156111c95760405160e560020a62461bcd02815260206004820152602b60248201527f6163636f756e7420746f2061646420697320616c7265616479206f6e2074686560448201527f20616c6c6f77206c6973740000000000000000000000000000000000000000006064820152608401610193565b60005b600160a060020a0382166000908152600460205260409020548110156112b757600160a060020a038216600090815260046020526040902080543391908390811061121957611219611505565b600091825260209091200154600160a060020a031614156112a55760405160e560020a62461bcd02815260206004820152602760248201527f73656e6465722068617320616c726561647920766f74656420746f206164642060448201527f6163636f756e74000000000000000000000000000000000000000000000000006064820152608401610193565b806112af816114b8565b9150506111cc565b50600160a060020a0381166000818152600460209081526040822080546001810182558184529183209091018054600160a060020a0319163390811790915591839052546003549192917f91ad81c76cda7c0ccc324838ae74757eab38b250da52daab154daf408cb3bcba919061133090600290611465565b61133b90600161144d565b60408051928352602083019190915260019082015260006060820152608001610de0565b508054600082559060005260206000209081019061137d9190611380565b50565b5b808211156113955760008155600101611381565b5090565b6000602082840312156113ab57600080fd5b8135600160a060020a03811681146113c257600080fd5b9392505050565b6020808252825182820181905260009190848201906040850190845b8181101561140a578351600160a060020a0316835292840192918401916001016113e5565b50909695505050505050565b6020808252601f908201527f73656e646572206973206e6f74206f6e2074686520616c6c6f77206c69737400604082015260600190565b60008219821115611460576114606114d3565b500190565b6000826114855760e060020a634e487b7102600052601260045260246000fd5b500490565b60008282101561149c5761149c6114d3565b500390565b6000816114b0576114b06114d3565b506000190190565b60006000198214156114cc576114cc6114d3565b5060010190565b60e060020a634e487b7102600052601160045260246000fd5b60e060020a634e487b7102600052603160045260246000fd5b60e060020a634e487b7102600052603260045260246000fdfea26469706673582212200c3e9c07521b155532c0de1605aae52f4ae953670f0afb0f30d320580b93213d64736f6c63430008070033",
- "storage": {
- "0000000000000000000000000000000000000000000000000000000000000000": "0000000000000000000000000000000000000000000000000000000000000002",
- "290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563": "0000000000000000000000009a6d82ef3912d5ab60473124bccd2f2a640769d7",
- "290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e564": "00000000000000000000000065463bf6268e5cc409b6501ec846487b935a1446",
- "aedead2c33b41c31b4afd2246c6bf5131c209d4b0ca6c2247778ac7be7443a00": "0000000000000000000000000000000000000000000000000000000000000101",
- "33784757d5da236467d27a7c5b0cc5aa9026ca3b79e29106a67a5e93c292a523": "0000000000000000000000000000000000000000000000000000000000010101",
- "35aba1eb0bbe741ac01e5b6ce584bc042b1a0b7d115eb8f7dd02a1a1de2fd14d": "000000000000000000000000fe3b557e8fb62b89f4916b721be55ceb828dbd73",
- "0d9217f0a1f7c602fd67052d20171ff73b156d1b87ea258cb6a5d94f71298158": "000000000000000000000000627306090abab3a6e1400e9345bc60c78a8bef57",
- "0000000000000000000000000000000000000000000000000000000000000003": "0000000000000000000000000000000000000000000000000000000000000002"
- },
- "version": "0x01"
- }
- },
- "number": "0x0",
- "gasUsed": "0x0",
- "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
-}
-```
-
-
-
-The QBFT properties are:
-
-- `blockperiodseconds` - The minimum block time, in seconds.
-- `epochlength` - The number of blocks after which to reset all votes.
-- `requesttimeoutseconds` - The timeout for each consensus round before a round change, in seconds.
-- `blockreward` - Optional reward amount in Wei to reward the beneficiary. Defaults to zero (0). Can be specified as a hexadecimal (with 0x prefix) or decimal string value. If set, then all nodes on the network must use the identical value.
-- `validatorcontractaddress` - Address of the validator smart contract. Required only if using a contract validator selection. The address must be identical to the address in the `alloc` section. This option can also be used in the [transitions](#transitions) configuration item if swapping [validator management methods](#add-and-remove-validators) in an existing network.
-- `miningbeneficiary` - Optional beneficiary of the `blockreward`. Defaults to the validator that proposes the block. If set, then all nodes on the network must use the same beneficiary.
-- [`extraData`](#extra-data) - RLP encoded [extra data](#extra-data).
-
-:::caution
-
-We don't recommend changing `epochlength` in a running network. Changing the `epochlength` after genesis can result in illegal blocks.
-
-:::
-
-:::caution Invalid block header error
-
-When adding a new node, if a `TimeStampMoreRecentThanParent | Invalid block header` error occurs, the genesis file of the new node specifies a higher `blockperiodseconds` than the imported chain. The imported chain makes new blocks faster than the genesis file allows and Besu rejects them with this error. This error most often occurs when importing chains from older versions of Besu.
-
-Decrease the `blockperiodseconds` in the new QBFT genesis file to a lower value that satisfies the block header validation.
-
-If the error reads `| TimestampMoreRecentThanParent | Invalid block header: timestamp 1619660141 is only 3 seconds newer than parent timestamp 1619660138. Minimum 4 seconds`, decrease the `blockperiodseconds` from 4 seconds to 3 seconds to match the imported chain.
-
-After you update the new genesis file, if the imported chain has a `blockperiodseconds` value set lower than you prefer, you can adjust it by [configuring the block time on an existing QBFT network](#configure-block-time-on-an-existing-network).
-
-:::
-
-The properties with specific values in the QBFT genesis files are:
-
-- `difficulty` - `0x1`
-- `mixHash` - `0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365` for Istanbul block identification
-
-To start a node on a QBFT private network, use the [`--genesis-file`](../../../../public-networks/reference/cli/options.md#genesis-file) option to specify the custom genesis file.
-
-### Extra data
-
-The `extraData` property is an RLP encoding of:
-
-- 32 bytes of vanity data.
-- If using:
- - [Block header validator selection](#add-and-remove-validators-using-block-headers), a list of validator addresses.
- - [Contract validator selection](#add-and-remove-validators-using-a-smart-contract), no validators.
-- Any validator votes. No vote is included in the genesis block.
-- The round the block was created on. The round in the genesis block is 0.
-- A list of seals of the validators (signed block hashes). No seals are included in the genesis block.
-
-When using block header validator selection, the important information in the genesis block extra data is the list of validators. All other details have empty values in the genesis block.
-
-:::info
-
-When using contract validator selection to manage validators, the list of validators is configured in the `alloc` property's `storage` section. View the example smart contract for more information on how to generate the `storage` section.
-
-:::
-
-Formally, `extraData` in the genesis block contains:
-
-- If using block header validator selection: `RLP([32 bytes Vanity, List, No Vote, Round=Int(0), 0 Seals])`.
-- If using contract validator selection: `RLP([32 bytes Vanity, 0 Validators, No Vote, Round=Int(0), 0 Seals])`.
-
-:::info
-
-RLP encoding is a space-efficient object serialization scheme used in Ethereum.
-
-:::
-
-#### Generate extra data
-
-To generate the `extraData` RLP string for inclusion in the genesis file, use the [`rlp encode`](../../../reference/cli/subcommands.md#rlp) Besu subcommand.
-
-```bash title="Example"
-besu rlp encode --from=toEncode.json --type=QBFT_EXTRA_DATA
-```
-
-Where the `toEncode.json` file contains a list of the initial validators, in ascending order. To write the validator address and copy it to the `toEncode.json` file, use the [`public-key export-address`](../../../../public-networks/reference/cli/subcommands.md#export-address) Besu subcommand. For example:
-
-```json title="Initial validators in toEncode.json file"
-[
- "0x4592c8e45706cc08b8f44b11e43cba0cfc5892cb",
- "0x06e23768a0f59cf365e18c2e0c89e151bcdedc70",
- "0xc5327f96ee02d7bcbc1bf1236b8c15148971e1de",
- "0xab5e7f4061c605820d3744227eed91ff8e2c8908"
-]
-```
-
-Copy the RLP encoded data to the `extraData` property in the genesis file.
-
-```bash title="RLP encoded data"
-0xf87aa00000000000000000000000000000000000000000000000000000000000000000f854944592c8e45706cc08b8f44b11e43cba0cfc5892cb9406e23768a0f59cf365e18c2e0c89e151bcdedc7094c5327f96ee02d7bcbc1bf1236b8c15148971e1de94ab5e7f4061c605820d3744227eed91ff8e2c8908c080c0
-```
-
-When you start the network, the four nodes previously specified in `toEncode.json` are the validators for the network.
-
-### Block time
-
-When the protocol receives a new chain head, the block time (`blockperiodseconds`) timer starts. When `blockperiodseconds` expires, the round timeout (`requesttimeoutseconds`) timer starts and the protocol proposes a new block.
-
-If `requesttimeoutseconds` expires before adding the proposed block, a round change occurs, with the block time and timeout timers reset. The timeout period for the new round is two times `requesttimeoutseconds`. The timeout period continues to double each time a round fails to add a block.
-
-Usually, the protocol adds the proposed block before reaching `requesttimeoutseconds`. A new round then starts, resetting the block time and round timeout timers. When `blockperiodseconds` expires, the protocol proposes the next new block.
-
-:::danger
-
-If more than 1/3 of validators stop participating, new blocks can no longer be created and `requesttimeoutseconds` doubles with each round change. The quickest method to resume block production is to restart all validators, which resets `requesttimeoutseconds` to its genesis value.
-
-:::
-
-Once `blockperiodseconds` is over, the time from proposing a block to adding the block is small (usually around one second) even in networks with geographically dispersed validators.
-
-#### Tune block timeout
-
-To tune the block timeout for your network deployment:
-
-1. Set `blockperiodseconds` to your desired block time and `requesttimeoutseconds` to two times `blockperiodseconds`.
-1. Reduce `requesttimeoutseconds` until you start to see round changes occurring.
-1. Increase `requesttimeoutseconds` to the value where round changes are no longer occurring.
-
-:::tip
-
-View [`TRACE` logs](../../../../public-networks/reference/api/index.md#admin_changeloglevel) to see round change log messages.
-
-:::
-
-Use a [transition](#transitions) to update the `blockperiodseconds` in an existing network.
-
-### Optional configuration options
-
-Optional configuration options in the genesis file are:
-
-- `messageQueueLimit` - In large networks with limited resources, increasing the message queue limit might help with message activity surges. The default is 1000.
-- `duplicateMessageLimit` - If the same node is retransmitting messages, increasing the duplicate message limit might reduce the number of retransmissions. A value of two to three times the number of validators is usually enough. The default is 100.
-- `futureMessagesLimit` - The future messages buffer holds messages for a future chain height. For large networks, increasing the future messages limit might be useful. The default is 1000.
-- `futureMessagesMaxDistance` - The maximum height from the current chain height for buffering messages in the future messages buffer. The default is 10.
-
-### Post-Merge configuration
-
-After [The Merge](../../../../public-networks/concepts/the-merge.md), the following block fields are modified or deprecated. Their fields **must** contain only the constant values from the following chart.
-
-| Field | Constant value | Comment |
-| --- | --- | --- |
-| **`ommersHash`** | `0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347` | `= Keccak256(RLP([]))` |
-| **`difficulty`** | `0` | Replaced with `prevrandao` |
-| **`mixHash`** | `0x0000000000000000000000000000000000000000000000000000000000000000` | Replaced with `prevrandao` |
-| **`nonce`** | `0x0000000000000000` | |
-| **`ommers`** | `[]` | `RLP([]) = 0xc0` |
-
-Additionally, [`extraData`](#extra-data) is limited to the 32 bytes of vanity data after The Merge.
-
-## Add and remove validators
-
-QBFT provides two methods to manage validators:
-
-- [Block header validator selection](#add-and-remove-validators-using-block-headers) - Existing validators propose and vote to add or remove validators using the QBFT JSON-RPC API methods.
-
-- [Contract validator selection](#add-and-remove-validators-using-a-smart-contract) - Use a smart contract to specify the validators used to propose and validate blocks.
-
-You can use [transitions](#transitions) to swap between block header validator selection and contract validator selection in an existing network.
-
-For block header validator selection, initial validators are configured in the genesis file's [`extraData`](#extra-data) property, whereas the initial validators when using the contract validator selection method are configured in the genesis file's `storage` section.
-
-### Add and remove validators using block headers
-
-Enable the HTTP interface with [`--rpc-http-enabled`](../../../../public-networks/reference/cli/options.md#rpc-http-enabled) or the WebSockets interface with [`--rpc-ws-enabled`](../../../../public-networks/reference/cli/options.md#rpc-ws-enabled).
-
-The QBFT API methods are disabled by default. To enable them, specify the [`--rpc-http-api`](../../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../../public-networks/reference/cli/options.md#rpc-ws-api) option and include `QBFT`.
-
-The methods to add or remove validators are:
-
-- [`qbft_getPendingVotes`](../../../reference/api/index.md#qbft_getpendingvotes).
-- [`qbft_proposeValidatorVote`](../../../reference/api/index.md#qbft_proposevalidatorvote).
-- [`qbft_discardValidatorVote`](../../../reference/api/index.md#qbft_discardvalidatorvote).
-
-To view validator metrics for a specified block range, use [`qbft_getSignerMetrics`](../../../reference/api/index.md#qbft_getsignermetrics).
-
-:::note
-
-If network conditions render it impossible to add and remove validators by voting, you can [add and remove validators without voting](add-validators-without-voting.md).
-
-:::
-
-#### Add a validator
-
-To propose adding a validator, call [`qbft_proposeValidatorVote`](../../../reference/api/index.md#qbft_proposevalidatorvote), specifying the address of the proposed validator and `true`. A majority of validators must execute the call.
-
-```bash title="JSON-RPC qbft_proposeValidatorVote request example"
-curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_proposeValidatorVote","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73", true], "id":1}'
-```
-
-When the validator proposes the next block, the protocol inserts one proposal received from [`qbft_proposeValidatorVote`](../../../reference/api/index.md#qbft_proposevalidatorvote) into the block. If blocks include all proposals, subsequent blocks proposed by the validator will not contain a vote.
-
-When more than 50% of the existing validators have published a matching proposal, the protocol adds the proposed validator to the validator pool and the validator can begin validating blocks.
-
-To return a list of validators and confirm the addition of a proposed validator, use [`qbft_getValidatorsByBlockNumber`](../../../reference/api/index.md#qbft_getvalidatorsbyblocknumber).
-
-```bash title="JSON-RPC qbft_getValidatorsByBlockNumber request example"
-curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"], "id":1}'
-```
-
-To discard your proposal after confirming the addition of a validator, call [`qbft_discardValidatorVote`](../../../reference/api/index.md#qbft_discardvalidatorvote), specifying the address of the proposed validator.
-
-```bash title="JSON-RPC qbft_discardValidatorVote request example"
-curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_discardValidatorVote","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73"], "id":1}'
-```
-
-#### Remove a validator
-
-The process for removing a validator is the same as adding a validator except you specify `false` as the second parameter of [`qbft_proposeValidatorVote`](../../../reference/api/index.md#qbft_proposevalidatorvote).
-
-#### Epoch transition
-
-At each epoch transition, QBFT discards all pending votes collected from received blocks. Existing proposals remain in effect and validators re-add their vote the next time they create a block.
-
-An epoch transition occurs every `epochLength` blocks. Define `epochlength` in the QBFT genesis file.
-
-### Add and remove validators using a smart contract
-
-Users can create their own smart contracts to add or remove validators based on their organizational requirements. View the [example smart contract](https://github.com/ConsenSys/validator-smart-contracts) for more information on how to create and deploy the smart contract.
-
-You can pre-deploy the validator smart contract in a new QBFT network by specifying the contract details in the [genesis file](qbft.md#genesis-file). For existing QBFT networks you need to compile and deploy the contract using a transaction, then obtain the contract address from the receipt and use that in a [transition](#swap-validator-management-methods).
-
-:::info
-
-You can't use the JSON-RPC methods to add or remove validators when using a smart contract to manage nodes.
-
-You must interact with the contract functions using transactions.
-
-:::
-
-:::note
-
-If network conditions render it impossible to add and remove validators using a smart contract, you can [override smart contract validators](add-validators-without-voting.md#override-smart-contract-validators).
-
-:::
-
-### Minimum number of validators
-
-QBFT requires four validators to be Byzantine fault tolerant. Byzantine fault tolerance is the ability for a blockchain network to function correctly and reach consensus despite nodes failing or propagating incorrect information to peers.
-
-## Transitions
-
-The `transitions` genesis configuration item allows you to specify a future block number at which to change QBFT network configuration in an existing network. For example, you can update the [block time](#configure-block-time-on-an-existing-network), [block reward](#configure-block-rewards-on-an-existing-network-deployment), [validator management method](#swap-validator-management-methods), or [mining beneficiary](#configure-the-mining-beneficiary-on-an-existing-network-deployment).
-
-:::caution
-
-Do not specify a transition block in the past. Specifying a transition block in the past could result in unexpected behavior, such as causing the network to fork.
-
-:::
-
-### Configure block time on an existing network
-
-To update an existing network with a new `blockperiodseconds`:
-
-1. Stop all nodes in the network.
-2. In the [genesis file](#genesis-file), add the `transitions` configuration item where:
-
- - `` is the upcoming block at which to change `blockperiodseconds`.
- - `` is the updated value for `blockperiodseconds`.
-
-
-
- # Syntax
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- },
- "transitions": {
- "qbft": [
- {
- "block": ,
- "blockperiodseconds":
- }
- ]
- }
- },
- ...
- }
- ```
-
- # Example
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- },
- "transitions": {
- "qbft": [
- {
- "block": 1240,
- "blockperiodseconds": 4
- }
- ]
- }
- },
- ...
- }
- ```
-
-
-
-3. Restart all nodes in the network using the updated genesis file.
-4. To verify the changes after the transition block, call [`qbft_getValidatorsByBlockNumber`](../../../reference/api/index.md#ibft_getvalidatorsbyblocknumber), specifying `latest`.
-
-### Configure block rewards on an existing network deployment
-
-To update an existing network with a new `blockreward`:
-
-1. Stop all nodes in the network.
-2. In the [genesis file](#genesis-file), add the `transitions` configuration item where:
-
- - `` is the upcoming block at which to change `blockreward`.
- - `` is the updated value for `blockreward`.
-
-
-
- # Syntax
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- "blockreward": "5000000000000000"
- },
- "transitions": {
- "qbft": [
- {
- "block": ,
- "blockreward":
- },
- {
- "block": ,
- "blockreward":
- },
- {
- "block": ,
- "blockreward":
- }
- ]
- }
- },
- ...
- }
- ```
-
- # Example
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- "blockreward": "5000000000000000"
- },
- "transitions": {
- "qbft": [
- {
- "block": 10,
- "blockreward": "6000000000000000"
- },
- {
- "block": 15,
- "blockreward": "75000000000000000"
- },
- {
- "block": 20,
- "blockreward": "0"
- }
- ]
- }
- },
- ...
- }
- ```
-
-
-
- :::note
-
- You can add multiple `blockreward` updates in one transition object by specifying multiple future blocks.
-
- :::
-
-3. Restart all nodes in the network using the updated genesis file.
-
-### Swap validator management methods
-
-To swap between block header validator selection and contract validator selection methods in an existing network:
-
-1. Stop all nodes in the network.
-2. In the [genesis file](#genesis-file), add the `transitions` configuration item where:
-
- - `` is the upcoming block at which to change the validator selection method.
- - `` is the validator selection mode to switch to. Valid options are `contract` and `blockheader`.
- - `` is the smart contract address, if switching to the contract validator selection method.
-
-
-
- # Syntax
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 5,
- "epochlength": 30000,
- "requesttimeoutseconds": 10
- },
- "transitions": {
- "qbft": [
- {
- "block": ,
- "validatorselectionmode": ,
- "validatorcontractaddress":
- }
- ]
- }
- },
- ...
- }
- ```
-
- # Example
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 5,
- "epochlength": 30000,
- "requesttimeoutseconds": 10
- },
- "transitions": {
- "qbft": [
- {
- "block": 102885,
- "validatorselectionmode": "contract",
- "validatorcontractaddress": "0x0000000000000000000000000000000000007777"
- }
- ]
- }
- },
- ...
- }
- ```
-
-
-
-3. Restart all nodes in the network using the updated genesis file.
-
-### Configure the mining beneficiary on an existing network deployment
-
-To update an existing network with a new mining beneficiary:
-
-1. Stop all nodes in the network.
-2. In the [genesis file](#genesis-file), add the `transitions` configuration item where:
-
- - `` is the upcoming block at which to change `miningbeneficiary`.
- - `` is the updated 20-byte address for `miningbeneficiary`. Starting at ``, block rewards go to this address.
-
-
-
- # Syntax
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 5,
- "epochlength": 30000,
- "requesttimeoutseconds": 10
- },
- "transitions": {
- "qbft": [
- {
- "block": ,
- "miningbeneficiary":
- },
- {
- "block": ,
- "miningbeneficiary":
- }
- ]
- }
- },
- ...
- }
- ```
-
- # Example
-
- ```bash
- {
- "config": {
- ...
- "qbft": {
- "blockperiodseconds": 5,
- "epochlength": 30000,
- "requesttimeoutseconds": 10
- },
- "transitions": {
- "qbft": [
- {
- "block": 10000,
- "miningbeneficiary": "0x0000000000000000000000000000000000000002",
- },
- {
- "block": 20000,
- "miningbeneficiary": "",
- }
- ]
- }
- },
- ...
- }
- ```
-
-
-
- :::note
-
- Setting the `miningbeneficiary` to an empty value clears out any override so that block rewards go to the block producer rather than a global override address.
-
- :::
-
-3. Restart all nodes in the network using the updated genesis file.
-
-
-
-_[vanity data]: Validators can include anything they like as vanity data. _[RLP]: Recursive Length Prefix
-
-[GoQuorum]: https://consensys.net/docs/goquorum/en/stable/
-[View the example smart contract]: https://github.com/ConsenSys/validator-smart-contracts
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/contracts.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/contracts.md
deleted file mode 100644
index a38c58e3894..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/contracts.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: Pre-deploy a contract
-description: Pre-deploying contracts in the genesis file
-sidebar_position: 5
-tags:
- - private networks
----
-
-# Pre-deploy contracts in the genesis file
-
-To pre-deploy contracts when starting Besu, specify the contract code in the [genesis file](../../../public-networks/concepts/genesis-file.md).
-
-:::tip Contract code in the genesis file
-
-```json
-{
- ...
- "alloc": {
- "0x0ffd23af8eebc60b3cfdeed6f814988757237314": {
- "balance": "0x100000000000000000000000000000000000000000000000000",
- "code": "0x6080604052600436106043576000357c010000000000000000000000000000000000000000000000000000000090048063010fc84214604857806355241077146070575b600080fd5b348015605357600080fd5b50605a60a7565b6040518082815260200191505060405180910390f35b348015607b57600080fd5b5060a560048036036020811015609057600080fd5b810190808035906020019092919050505060ad565b005b60005481565b80600081905550807f04474795f5b996ff80cb47c148d4c5ccdbe09ef27551820caa9c2f8ed149cce360405160405180910390a25056fea165627a7a7230582038cb7ea327af8f73feabcfbff64498f1e74831e67f7c75286760d3845c6747c70029",
- "storage": {
- "7aa07e0c924147697605046b7c2c32645b7bbfb41e0ac5d0a84ac93cbb759798": "0000000000000000000000000000000000000000000000000000000000000001",
- "cea2b0602db61f92b76ec4402875cc38eedc9fc425cb1b697fc2265d50fc20fb": "0000000000000000000000000000000000000000000000000000000000000001",
- }
- }
- },
- ...
-}
-```
-
-:::
-
-The contract code in the genesis file defines the:
-
-- Address.
-- Balance.
-- Bytecode.
-- Key value pairs for contract storage.
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/curves.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/curves.md
deleted file mode 100644
index 72edb764a18..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/curves.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Alternative elliptic curves
-description: Using alternative elliptic curves in Besu
-sidebar_position: 8
-tags:
- - private networks
----
-
-# Configure alternative elliptic curves
-
-:::caution
-
-Configuring alternative elliptic curves is an early access feature.
-
-:::
-
-By default, Besu uses the Ethereum standard `secp256k1` elliptic curve (EC). However, when running nodes in a private network, it is possible to configure an alternative elliptic curve.
-
-The configuration for what elliptic curve Besu will use is done in the network configuration section of genesis file, using the [`ecCurve`](../../../public-networks/reference/genesis-items.md#Configuration_Items) key:
-
-```bash
-{
- "genesis": {
- "config": {
- "ecCurve": "secp256k1",
- [...]
- },
- [...]
-}
-```
-
-:::danger Important
-
-All nodes in the network **MUST** use the same elliptic curve. Nodes with different EC configuration from the network won't be able to send messages to other nodes or verify transactions and blocks.
-
-:::
-
-Besu supports the following elliptic curves:
-
-- `secp256k1` (Ethereum default)
-- `secp256r1`
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/free-gas.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/free-gas.md
deleted file mode 100644
index 9eccfd2666d..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/free-gas.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Free gas network
-description: Configuring free gas networks
-sidebar_position: 2
-tags:
- - private networks
----
-
-# Configure free gas networks
-
-Transactions use computational resources so have an associated cost. Gas is the cost unit and the gas price is the price per gas unit. The transaction cost is the gas used \* gas price.
-
-In public networks, the account submitting the transaction pays the transaction cost, in Ether. The miner (or validator in PoA networks) that includes the transaction in a block receives transaction cost.
-
-In many private networks, network participants run the validators and do not require gas as an incentive. Networks that don't require gas as an incentive usually configure the gas price to be zero (that is, free gas). Some private networks might allocate Ether and use a non-zero gas price to limit resource use.
-
-:::tip
-
-We use the term _free gas network_ to refer to a network with a gas price of zero. A network with a gas price of zero is also known as a _zero gas network_ or _no gas network_.
-
-:::
-
-:::note
-
-Some pre-crafted transactions require the deployment account to have gas available. For example, the transaction that creates the smart contract in [EIP-1820](https://eips.ethereum.org/EIPS/eip-1820).
-
-:::
-
-In a free gas network, transactions still use gas but the gas price is zero, meaning the transaction cost is zero. Transaction cost = gas used \* 0 (the gas price).
-
-## Configure free gas in Besu
-
-When gas is free, limiting block and contract sizes is less important. In free gas networks, we increase the block size limit and set the contract size limit to the maximum value.
-
-### 1. Set the block size
-
-If you want to remove gas from consideration and don't mind blocks potentially taking longer to create, in the genesis file set the block size limit (measured in gas) to the maximum accepted by Hardhat (`0x1fffffffffffff`). In the genesis file, specify `gasLimit` following the `config` key.
-
-```json
-{
- "config": {
- ....
- },
- ...
- "gasLimit": "0x1fffffffffffff",
- ....
-}
-```
-
-If you are more concerned about blocks arriving on time and don't have expensive individual transactions, set `gasLimit` to a value closer to the amount of gas your validators can process in the configured block time.
-
-### 2. Set the contract size
-
-In the `config` section of the genesis file, set the contract size limit to the maximum supported size (in bytes).
-
-```json
-(
- "config": {
- ...
- "contractSizeLimit": 2147483647,
- ...
- }
- ...
-}
-```
-
-### 3. Start Besu with a minimum gas price of zero
-
-When starting nodes, set the [minimum gas price](../../../public-networks/reference/cli/options.md#min-gas-price) to zero.
-
-
-
-# Command Line
-
-```bash
---min-gas-price=0
-```
-
-# Configuration File
-
-```bash
-min-gas-price=0
-```
-
-
-
-# Command Line
-
-:::danger Important
-
-In a free gas network, ensure the [minimum gas price](../../../public-networks/reference/cli/options.md#min-gas-price) is set to zero for every node. Any node with a minimum gas price set higher than zero will silently drop transactions with a zero gas price. You can query a node's gas configuration using [`eth_gasPrice`](../../../public-networks/reference/api/index.md#eth_gasprice).
-
-:::
-
-### 4. Enable zero base fee if using London fork or later
-
-If your network is configured to use the `londonBlock` or a later hard fork, then you must also enable the `zeroBaseFee` configuration. You must set this on all your nodes. Once it is set, future blocks produced by that node will set a `baseFee` of 0. This is required because the London hard fork (EIP-1559) introduced a non-zero `baseFee` into the block which normally means transactions require gas.
-
-```json
-{
- "config": {
- "londonBlock": 0,
- "zeroBaseFee": true,
- ...
- },
- ...
-}
-```
-
-## Configure free gas in Hardhat
-
-If using Hardhat to develop on your free gas network, you also need to configure free gas in Hardhat.
-
-Like setting block and contract size limits to their maximum values for Besu, set the transaction gas limit in Hardhat to the maximum possible.
-
-:::info
-
-Besu does not support private key management. To use Besu with Hardhat, you must configure a [Hardhat wallet](../../../public-networks/how-to/develop/hardhat.md).
-
-:::
-
-### Update `hardhat.config.js`
-
-Update the `hardhat.config.js` file:
-
-1. Set the gas price to zero.
-
- ```js
- gasPrice: 0;
- ```
-
-1. Set the gas limit for a transaction (that is, contract creation) to be the block gas limit - 1.
-
- ```js
- gas: "0x1ffffffffffffe";
- ```
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/tls/_category_.json b/versioned_docs/version-23.10.0/private-networks/how-to/configure/tls/_category_.json
deleted file mode 100644
index dbda63e2b5b..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/tls/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "TLS",
- "position": 6
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/tls/client-and-server.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/tls/client-and-server.md
deleted file mode 100644
index 5ee1722415d..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/tls/client-and-server.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-title: Client and server TLS
-sidebar_position: 1
-tags:
- - private networks
----
-
-# Configure client and server TLS
-
-Hyperledger Besu supports TLS for client and server communication. For example, you can configure TLS for communication between [EthSigner](https://docs.ethsigner.consensys.net/en/latest/Concepts/TLS/) and Besu, and Besu and [Tessera](https://docs.tessera.consensys.net/HowTo/Configure/TLS/).
-
-The following diagram displays an example client and server TLS configuration.
-
-![Besu client and server TLS](../../../../assets/images/Besu_TLS.png)
-
-Configure TLS communication from the command line.
-
-## Prerequisites
-
-- Besu's password-protected PKCS12 keystore
-- File containing the keystore password
-
-## Configure client TLS
-
-Allow clients (for example a dapp, curl, or EthSigner) to send and receive secure HTTP JSON-RPCs.
-
-**Client prerequisites**:
-
-- [Configure the client for TLS]
-- Client's PKCS12 keystore information
-
-### Create the known clients file
-
-The known clients file allows clients with self-signed certificates or non-public certificates to connect to Besu.
-
-Create a file (in this example, `knownClients`) that lists one or more trusted clients. Use the format` ` where:
-
-- `` is the Common Name specified in the client certificate.
-- `` is the SHA-256 fingerprint of the client certificate.
-
-```bash title="Example"
-ethsigner 8E:E0:85:9F:FC:2E:2F:21:31:46:0B:82:4C:A6:88:AB:30:34:9A:C6:EA:4F:04:31:ED:0F:69:A7:B5:C2:2F:A7
-curl FC:18:BF:39:45:45:9A:15:46:76:A6:E7:C3:94:64:B8:34:84:A3:8E:B8:EA:67:DC:61:C0:29:E6:38:B8:B7:99
-```
-
-You can use [`openssl`](https://www.openssl.org/) or [`keytool`](https://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html) to display the SHA256 fingerprint.
-
-```
-keytool -list -v -keystore -storetype PKCS12 -storepass `.
-```
-
-### Start Besu
-
-```bash
-besu --rpc-http-enabled --rpc-http-tls-enabled --rpc-http-tls-client-auth-enabled --rpc-http-tls-keystore-file=/Users/me/my_node/keystore.pfx --rpc-http-tls-keystore-password-file=/Users/me/my_node/keystorePassword --rpc-http-tls-known-clients-file=/Users/me/my_node/knownClients --rpc-http-tls-cipher-suite=TLS_AES_256_GCM_SHA384 --rpc-http-tls-protocol=TLSv1.3,TLSv1.2
-```
-
-The command line:
-
-- Enables the HTTP JSON-RPC service using the [`--rpc-http-enabled`](../../../../public-networks/reference/cli/options.md#rpc-http-enabled) option.
-- Enables TLS for the HTTP JSON-RPC service using the [`--rpc-http-tls-enabled`](../../../../public-networks/reference/cli/options.md#rpc-http-tls-enabled) option.
-- Enables TLS client authentication using the [`--rpc-http-tls-client-auth-enabled`](../../../../public-networks/reference/cli/options.md#rpc-http-tls-client-auth-enabled) option.
-- Specifies the keystore using the [`--rpc-http-tls-keystore-file`](../../../../public-networks/reference/cli/options.md#rpc-http-tls-keystore-file) option.
-- Specifies the file that contains the password to decrypt the keystore using the [`--rpc-http-tls-keystore-password-file`](../../../../public-networks/reference/cli/options.md#rpc-http-tls-keystore-password-file) option.
-- [Specifies the clients](#create-the-known-clients-file) allowed to connect to Besu using the [`--rpc-http-tls-known-clients-file`](../../../../public-networks/reference/cli/options.md#rpc-http-tls-known-clients-file) option.
-- specifies the Java cipher suites using the [`--rpc-http-tls-cipher-suite`](../../../../public-networks/reference/cli/options.md#rpc-http-tls-cipher-suite) option.
-- specifies the TLS protocol version using the [`--rpc-http-tls-protocol`](../../../../public-networks/reference/cli/options.md#rpc-http-tls-protocol) option.
-
-:::note
-
-Set [`--rpc-http-tls-ca-clients-enabled`](../../../../public-networks/reference/cli/options.md#rpc-http-tls-ca-clients-enabled) to `true` to allow access to clients with signed and trusted root CAs.
-
-:::
-
-## Configure server TLS
-
-Allow Besu to securely communicate with the server (Tessera).
-
-**Server prerequisites**:
-
-- [Configure the server to allow TLS communication]
-- Server's certificate information
-
-### Create the known servers file
-
-Create a file (in this example, `knownServers`) that lists one or more trusted servers. The file contents use the format `: ` where:
-
-- `` is the server hostname
-- `` is the port used for communication
-- `` is the SHA-256 fingerprint of the server's certificate.
-
-```bash title="Example"
-localhost:8888 3C:B4:5A:F9:88:43:5E:62:69:9F:A9:9D:41:14:03:BA:83:24:AC:04:CE:BD:92:49:1B:8D:B2:A4:86:39:4C:AC
-127.0.0.1:8888 3C:B4:5A:F9:88:43:5E:62:69:9F:A9:9D:41:14:03:BA:83:24:AC:04:CE:BD:92:49:1B:8D:B2:A4:86:39:4C:AC
-```
-
-:::note
-
-If you are unsure whether requests use the hostname or an IP address, configure both in the file.
-
-:::
-
-### Start Besu
-
-```bash
-besu --privacy-tls-enabled --privacy-tls-keystore-file=/Users/me/my_node/keystore.pfx --privacy-tls-keystore-password-file=/Users/me/my_node/keystorePassword --privacy-tls-known-enclave-file=/Users/me/my_node/knownServers
-```
-
-The command line:
-
-- Enables TLS with the server using the [`--privacy-tls-enabled`](../../../reference/cli/options.md#privacy-tls-enabled) option.
-- Specifies the keystore using the [`--privacy-tls-keystore-file`](../../../reference/cli/options.md#privacy-tls-keystore-file) option.
-- Specifies the file that contains the password to decrypt the keystore using the [`--privacy-tls-keystore-password-file`](../../../reference/cli/options.md#privacy-tls-keystore-password-file) option.
-- Specifies the trusted servers using the [`--privacy-tls-known-enclave-file`](../../../reference/cli/options.md#privacy-tls-known-enclave-file) option.
-
-
-
-[Configure the client for TLS]: https://docs.ethsigner.consensys.net/en/latest/HowTo/Configure-TLS/#server-tls-connection
-[Configure the server to allow TLS communication]: https://docs.tessera.consensys.net/HowTo/Configure/TLS/
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/tls/p2p.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/tls/p2p.md
deleted file mode 100644
index 3121d25c520..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/tls/p2p.md
+++ /dev/null
@@ -1,261 +0,0 @@
----
-title: Peer-to-peer TLS
-sidebar_position: 2
-description: Configure P2P TLS communication
-tags:
- - private networks
----
-
-# Configure P2P TLS
-
-You can configure TLS to secure the P2P communication between nodes by ensuring only authorized nodes can communicate with each other. Use certificates issued by a trusted authority to connect authorized nodes in the network.
-
-:::caution
-
-P2P TLS is an early access feature, and functionality and options may be updated between releases.
-
-:::
-
-Besu supports PKCS11, PKCS12, and JKS keystore and truststore types for P2P TLS.
-
-## Configure P2P TLS
-
-**Prerequisites**:
-
-- A configured network. For example, [see steps 1 to 5 in the QBFT tutorial](../../../tutorials/qbft.md).
-- Each node requires a keystore that contains the node's certificate and key.
-- A truststore containing all the trusted certificates for the network.
-
-Start Besu and include the following command line options on the required nodes:
-
-```bash
-besu --Xp2p-tls-enabled=true \
---Xp2p-tls-keystore-type="PKCS12" \
---Xp2p-tls-keystore-file="keystore" \
---Xp2p-tls-keystore-password-file="keystore.password" \
---Xp2p-tls-crl-file="crl2.pem" \
---Xp2p-tls-truststore-type="JKS" \
---Xp2p-tls-truststore-file="truststore.jks" \
---Xp2p-tls-truststore-password-file="truststore_password.txt"
-```
-
-In the command line:
-
-- Enable TLS for P2P communication using [`--Xp2p-tls-enabled=true`](#xp2p-tls-enabled).
-- Specify the keystore type and keystore file using [`--Xp2p-tls-keystore-type`](#xp2p-tls-keystore-type) and [`--Xp2p-tls-keystore-file`](#xp2p-tls-keystore-file).
-- Specify the text file containing the password to unlock the keystore file using [`--Xp2p-tls-keystore-password-file`](#xp2p-tls-keystore-password-file).
-- Specify the optional [certificate revocation list (CRL)] file using [`--Xp2p-tls-crl-file`](#xp2p-tls-crl-file).
-- Specify the truststore type and truststore file using [`--Xp2p-tls-truststore-type`](#xp2p-tls-truststore-type) and [`--Xp2p-tls-truststore-file`](#xp2p-tls-truststore-file).
-- Specify the text file containing the password to unlock the truststore file using [`--Xp2p-tls-truststore-password-file`](#xp2p-tls-keystore-password-file).
-
-## Command line options
-
-### `Xp2p-tls-crl-file`
-
-
-
-# Syntax
-
-```bash
---Xp2p-tls-crl-file=
-```
-
-# Example
-
-```bash
---Xp2p-tls-crl-file=/home/cert/cert.crl.pem
-```
-
-# Environment variable
-
-```bash
-BESU_XP2P_TLS_CRL_FILE=/home/cert/cert.crl.pem
-```
-
-
-
-Path to the optional certificate revocation list (CRL) file.
-
-### `Xp2p-tls-enabled`
-
-
-
-# Syntax
-
-```bash
---Xp2p-tls-enabled[=]
-```
-
-# Example
-
-```bash
---Xp2p-tls-enabled=true
-```
-
-# Environment variable
-
-```bash
-BESU_XP2P_TLS_ENABLED=true
-```
-
-
-
-Enable TLS for P2P communication. The default is `false`.
-
-### `Xp2p-tls-keystore-file`
-
-
-
-# Syntax
-
-```bash
---Xp2p-tls-keystore-file=
-```
-
-# Example
-
-```bash
---Xp2p-tls-keystore-file=/home/cert/keystore.jks
-```
-
-# Environment variable
-
-```bash
-BESU_XP2P_TLS_KEYSTORE_FILE=/home/cert/keystore.jks
-```
-
-
-
-Keystore file containing the key and certificate to allow TLS for P2P communication.
-
-### `Xp2p-tls-keystore-password-file`
-
-
-
-# Syntax
-
-```bash
---Xp2p-tls-keystore-password-file=
-```
-
-# Example
-
-```bash
---Xp2p-tls-keystore-password-file=/home/cert/password.txt
-```
-
-# Environment variable
-
-```bash
-BESU_XP2P_TLS_KEYSTORE_PASSWORD_FILE=/home/cert/password.txt
-```
-
-
-
-Text file containing the password to unlock the keystore file.
-
-### `Xp2p-tls-keystore-type`
-
-
-
-# Syntax
-
-```bash
---Xp2p-tls-keystore-type=
-```
-
-# Example
-
-```bash
---Xp2p-tls-keystore-type=JKS
-```
-
-# Environment variable
-
-```bash
-BESU_XP2P_TLS_KEYSTORE_TYPE=JKS
-```
-
-
-
-Keystore type that allows TLS for P2P communication. Valid options are `JKS`, `PKCS11`, and `PKCS12`. The default is `JKS`.
-
-### `Xp2p-tls-truststore-file`
-
-
-
-# Syntax
-
-```bash
---Xp2p-tls-truststore-file=
-```
-
-# Example
-
-```bash
---Xp2p-tls-truststore-file=/home/cert/truststore.jks
-```
-
-# Environment variable
-
-```bash
-BESU_XP2P_TLS_TRUSTSTORE_FILE=/home/cert/truststore.jks
-```
-
-
-
-Truststore containing the trusted certificates that allows TLS for P2P communication.
-
-### `Xp2p-tls-truststore-password-file`
-
-
-
-# Syntax
-
-```bash
---Xp2p-tls-truststore-password-file=
-```
-
-# Example
-
-```bash
---Xp2p-tls-truststore-password-file=/home/cert/password.txt
-```
-
-# Environment variable
-
-```bash
-BESU_XP2P_TLS_TRUSTSTORE_PASSWORD_FILE=/home/cert/password.txt
-```
-
-
-
-Text file containing the password to unlock the truststore file.
-
-### `Xp2p-tls-truststore-type`
-
-
-
-# Syntax
-
-```bash
---Xp2p-tls-truststore-type=
-```
-
-# Example
-
-```bash
---Xp2p-tls-truststore-type=JKS
-```
-
-# Environment variable
-
-```bash
-BESU_XP2P_TLS_TRUSTSTORE_TYPE=JKS
-```
-
-
-
-Truststore type. Valid options are `JKS`, `PKCS11`, and `PKCS12`. The default is `JKS`.
-
-[certificate revocation list (CRL)]: https://www.securew2.com/blog/certificate-revocation-crl-explained
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/configure/validators.md b/versioned_docs/version-23.10.0/private-networks/how-to/configure/validators.md
deleted file mode 100644
index 0a5be8501e4..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/configure/validators.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: Validators
-description: Configuring validators in production networks
-sidebar_position: 4
-tags:
- - private networks
----
-
-# Configure validators in a production network
-
-As when [configuring bootnodes](bootnodes.md):
-
-1. Create the [node key pair](../../../public-networks/concepts/node-keys.md) (that is, the private and public key) before starting the validator.
-1. When creating validators in the cloud (for example, AWS or Azure), attempt to assign static IP addresses to them. If your network is:
-
- - Publicly accessible, assign an elastic IP address.
- - Internal only, specify a private IP address when you create the instance and record this IP address.
-
-We recommend storing validator configuration under source control.
-
-## Number of validators required
-
-Ensure you configure enough validators to allow for redundancy. IBFT 2.0 tolerates `f = (n-1)/3` faulty validators, where:
-
-- `f` is the number of faulty validators
-- `n` is the number of validators.
-
-## Adding and removing validators
-
-You can [vote validators in or out of the validator pool].
-
-## Validators as bootnodes
-
-Validators can also be bootnodes. Other than the [usual configuration for bootnodes](bootnodes.md), you do not need to specify any extra configuration when a validator is also a bootnode.
-
-If you remove a validator that is also a bootnode, ensure there are enough remaining bootnodes on the network.
-
-
-
-[vote validators in or out of the validator pool]: consensus/ibft.md#add-and-remove-validators
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/deploy/_category_.json b/versioned_docs/version-23.10.0/private-networks/how-to/deploy/_category_.json
deleted file mode 100644
index 5befebd2362..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/deploy/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Deploy for production",
- "position": 6
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/deploy/ansible.md b/versioned_docs/version-23.10.0/private-networks/how-to/deploy/ansible.md
deleted file mode 100644
index c8b9b82d5c1..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/deploy/ansible.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-sidebar_position: 2
-title: Use Ansible
-description: Deploying Hyperledger Besu with Ansible role on Galaxy
-tags:
- - private networks
----
-
-# Deploy Besu with Ansible
-
-To deploy Besu using Ansible, use the [Hyperledger Besu role](https://galaxy.ansible.com/consensys/hyperledger_besu) published on Galaxy.
-
-For more information, see the "Read Me" button on the [Ansible Galaxy Besu page](https://galaxy.ansible.com/consensys/hyperledger_besu).
-
-:::tip
-
-We strongly recommend automating network creation. Automating makes updates easier and ensures your configuration is synchronized across the network.
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/deploy/cloud.md b/versioned_docs/version-23.10.0/private-networks/how-to/deploy/cloud.md
deleted file mode 100644
index d3d6b36a97c..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/deploy/cloud.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Deploy to the cloud
-sidebar_position: 1
-description: Deploying Besu to the cloud
-tags:
- - private networks
----
-
-# Deploy Besu to the cloud
-
-When deploying Besu to the cloud:
-
-- Ensure you have enough spread across Availability Zones (AZs) and Regions, especially for bootnodes and validators.
-- If your network is a multi-region network, consider using VPC Peering to reduce latency.
-- Where required, use VPNs to connect to your on premise systems, or single private chains.
-- If deploying to Kubernetes, please refer to the [tutorial](../../tutorials/kubernetes/index.md).
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/deploy/ethstats.md b/versioned_docs/version-23.10.0/private-networks/how-to/deploy/ethstats.md
deleted file mode 100644
index a8a48610cc7..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/deploy/ethstats.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-sidebar_position: 4
-title: Use Ethstats network monitor
-description: Ethstats network monitor
-tags:
- - private networks
----
-
-# Connect to Ethstats network monitor
-
-Connect to [Ethstats](https://ethstats.dev) to display real time and historical [statistics](#statistics) about the network and nodes. You can connect to the Ethstats dashboard by [connecting to a client and server](#connect-through-a-client-and-server) or by [connecting through the command line](#connect-through-the-command-line).
-
-## Components
-
-Ethstats consists of:
-
-- A [server](https://github.com/goerli/ethstats-server), which consumes node data received from the client.
-- A [client](https://github.com/goerli/ethstats-client), which extracts data from the node and sends it to the server.
-- A [dashboard](https://github.com/goerli/ethstats-client#available-dashboards), which displays statistics.
-
-## Statistics
-
-Statistics displayed by Ethstats include:
-
-- Nodes in the network. Metrics for nodes include:
- - Information about the last received block such as block number, block hash, transaction count, uncle count, block time, and propagation time.
- - Connected peers, whether the node is mining, hash rate, latency, and uptime.
-- Charts for block time, block difficulty, block gas limit, block uncles, block transactions, block gas used, block propagation histogram, and top miners.
-- IP-based geolocation overview.
-- Node logs, which display the data sent by a node.
-- Block history, which provides the ability to go back in time and playback the block propagation through the nodes.
-
-## Connect through a client and server
-
-Refer to the external [Ethstats client](https://github.com/goerli/ethstats-client) and [Ethstats server](https://github.com/goerli/ethstats-server) documentation for installing those components and connecting to a dashboard.
-
-## Connect through the command line
-
-You can use command line options to connect a node directly to a [dashboard](https://github.com/goerli/ethstats-client#available-dashboards), without using a client.
-
-Start a node using the [`--ethstats`](../../../public-networks/reference/cli/options.md#ethstats) option to specify the Ethstats server URL. You can specify a contact email to send to the server using [`--ethstats-contact`](../../../public-networks/reference/cli/options.md#ethstats-contact).
-
-```bash
-besu --ethstats=Dev-Node-1:secret@127.0.0.1:3001 --ethstats-contact=contact@mail.com
-```
-
-:::note
-
-A server must be specified by `--ethstats` in order to use `--ethstats-contact`.
-
-:::
-
-Open the selected dashboard website. Find your node under the list of nodes to see the statistics for the node and the network.
-
-![dashboard](../../../assets/images/dashboard.png)
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/deploy/kubernetes.md b/versioned_docs/version-23.10.0/private-networks/how-to/deploy/kubernetes.md
deleted file mode 100644
index fe1a95bec41..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/deploy/kubernetes.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-sidebar_position: 3
-title: Use Kubernetes
-description: Deploying Hyperledger Besu with Kubernetes
-tags:
- - private networks
----
-
-# Deploy Besu with Kubernetes
-
-Use the [reference implementations](https://github.com/ConsenSys/quorum-kubernetes) to install private networks using Kubernetes (K8s). The repository has full support for cloud providers like AWS, Azure, GCP, and IBM, and has production setups that use of identities and cloud-native secret storage services like Azure KeyVault and AWS Secrets Manager.
-
-Refer to the [tutorial](../../tutorials/kubernetes/index.md) and familiarize yourself with the reference implementations, and customize them to your requirements.
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/index.md b/versioned_docs/version-23.10.0/private-networks/how-to/index.md
deleted file mode 100644
index 9884ebccd56..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/index.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-description: Private networks how to overview
-tags:
- - private networks
----
-
-# How to
-
-This section provides instructional content for private network features.
-
-The following features are shared with [public networks](../../public-networks/index.md) and the content can be found in the public networks section:
-
-- Configure and manage:
- - [Use a configuration file](../../public-networks/how-to/configuration-file.md)
- - [Configure high availability](../../public-networks/how-to/configure-ha/index.md)
- - [Configure mining](../../public-networks/how-to/use-pow/mining.md)
-- [Use the Besu API](../../public-networks/how-to/use-besu-api/index.md):
- - [Use JSON-RPC over HTTP, WS, and IPC](../../public-networks/how-to/use-besu-api/json-rpc.md)
- - [Use RPC Pub/Sub over WS](../../public-networks/how-to/use-besu-api/rpc-pubsub.md)
- - [Use GraphQL over HTTP](../../public-networks/how-to/use-besu-api/graphql.md)
- - [Authenticate JSON-RPC requests](../../public-networks/how-to/use-besu-api/authenticate.md)
- - [Access logs using JSON-RPC API](../../public-networks/how-to/use-besu-api/access-logs.md)
-- Find and connect to peers:
- - [Configure static nodes](../../public-networks/how-to/connect/static-nodes.md)
- - [Configure ports](../../public-networks/how-to/connect/configure-ports.md)
- - [Manage peers](../../public-networks/how-to/connect/manage-peers.md)
- - [Specify NAT method](../../public-networks/how-to/connect/specify-nat.md)
-- [Configure the Java Virtual Machine](../../public-networks/how-to/configure-jvm/index.md)
- - [Pass JVM options](../../public-networks/how-to/configure-jvm/pass-jvm-options.md)
- - [Manage JVM memory](../../public-networks/how-to/configure-jvm/manage-memory.md)
- - [Use Java Flight Recorder](../../public-networks/how-to/configure-jvm/java-flight-recorder.md)
-- Develop dapps:
- - [Use Hardhat](../../public-networks/how-to/develop/hardhat.md)
- - [Use client libraries](../../public-networks/how-to/develop/client-libraries.md)
-- Troubleshoot:
- - [Use EVM tool](../../public-networks/how-to/troubleshoot/evm-tool.md)
- - [Trace transactions](../../public-networks/how-to/troubleshoot/trace-transactions.md)
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/_category_.json b/versioned_docs/version-23.10.0/private-networks/how-to/monitor/_category_.json
deleted file mode 100644
index 8e8c27af9a7..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Monitor nodes",
- "position": 3
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/chainlens.md b/versioned_docs/version-23.10.0/private-networks/how-to/monitor/chainlens.md
deleted file mode 100644
index 0e5f507621f..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/chainlens.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: Use Chainlens Explorer
-sidebar_position: 7
-description: Use Chainlens Explorer on a privacy-enabled Besu network
-tags:
- - private networks
----
-
-# Use Chainlens Blockchain Explorer
-
-[Chainlens Blockchain Explorer](https://chainlens.com/) supports public and private EVM networks.
-This page describes how to use the free version of Chainlens with its built-in support for
-[privacy-enabled](../../concepts/privacy/index.md) Besu networks created using the
-[Developer Quickstart](../../tutorials/quickstart.md).
-
-Chainlens provides an overview of the entire network, including block information, contract
-metadata, transaction searches, and [more](https://chainlens.com/).
-
-:::note
-You must connect to one of the privacy nodes (for example, `member1besu`), not the dedicated RPC, to
-allow access for Besu [privacy API methods](../../reference/api/index.md#priv-methods).
-In production networks, you must [secure access](../../../public-networks/how-to/use-besu-api/authenticate.md)
-to RPC nodes.
-:::
-
-## Prerequisites
-
-[Docker and Docker Compose](https://docs.docker.com/compose/install/) installed.
-
-## Start Chainlens
-
-Clone the [Chainlens GitHub repository](https://github.com/web3labs/chainlens-free):
-
-```bash
-git clone https://github.com/web3labs/chainlens-free
-```
-
-The repository contains a `docker-compose` directory to allow Chainlens to start with a Developer
-Quickstart test network.
-From the `docker-compose` directory, run the following command:
-
-```bash
-NODE_ENDPOINT=http://rpcnode:8545 docker-compose -f docker-compose.yml -f chainlens-extensions/docker-compose-quorum-dev-quickstart.yml up
-```
-
-This command does two things:
-
-- Sets up the node endpoint
-- Tells Docker to run by using the two Docker Compose files provided
-
-The first `docker-compose.yml` file in the command contains all the services required for Chainlens.
-
-The second file named `docker-compose-quorum-dev-quickstart` contains the network settings required to start
-Chainlens on the same network as the Besu development node.
-
-Next, open `http://localhost/` on your browser.
-You’ll see the new initialization page while it boots up.
-This may take 5–10 minutes for the all services to start and the ingestion sync to complete.
-
-![`Chainlens_loading`](../../../assets/images/chainlens-loading.png)
-
-## View on Chainlens
-
-After starting Chainlens, you can view information about your network.
-
-:::note
-Screenshots in this section are taken from the [Chainlens Goerli network](https://goerli.chainlens.com/dashboard).
-:::
-
-The **Dashboard** page provides an aggregated view of network activities.
-
-![`Chainlens_dashboard`](../../../assets/images/chainlens-dashboard.png)
-
-The **Network** page provides an overview of the network status and connected peers.
-This page is disabled by default, and is only visible if you set `DISPLAY_NETWOR_TAB=enabled` using
-the following command:
-
-```bash
-NODE_ENDPOINT=http://member1besu:8545 DISPLAY_NETWORK_TAB=enabled docker-compose -f docker-compose.yml -f chainlens-extensions/docker-compose-quorum-dev-quickstart.yml up
-```
-
-The **Blocks** page shows a real-time view of the finalized blocks.
-
-![Chainlens blocks](../../../assets/images/chainlens-block.png)
-
-You can view a given block details by selecting a block hash or number.
-
-![Chainlens block details](../../../assets/images/chainlens-block-details.png)
-
-The **Transactions** page shows a paginated view of new and historical transactions.
-
-![Chainlens transactions](../../../assets/images/chainlens-transactions.png)
-
-If you select any transaction hash, you can get the **transaction details.**
-
-![Chainlens transaction_details](../../../assets/images/chainlens-transaction-details.png)
-
-The **Contracts** page shows all the smart contracts deployed on the network.
-
-![Chainlens contracts](../../../assets/images/chainlens-contracts.png)
-
-You can view a smart contract details by selecting the contract address.
-
-![Chainlens contract details](../../../assets/images/chainlens-contract-details.png)
-
-The **Events** page shows all the events generated on the network.
-
-![Chainlens events](../../../assets/images/chainlens-events.png)
-
-## Stop Chainlens
-
-To stop all the services from running, run the following command:
-
-```bash
-docker-compose down
-```
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/elastic-stack.md b/versioned_docs/version-23.10.0/private-networks/how-to/monitor/elastic-stack.md
deleted file mode 100644
index b74dd929dfd..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/elastic-stack.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Use Elastic Stack
-sidebar_position: 3
-description: Using Elastic Stack (ELK) with Hyperledger Besu
-tags:
- - private networks
----
-
-# Use Elastic Stack
-
-[Elastic Stack] (ELK) is an open-source log management platform that is available when using the [Developer Quickstart](../../tutorials/quickstart.md).
-
-The [Filebeat] configuration ingests logs and the [Metricbeat] configuration collects metrics from the nodes at regular defined intervals and outputs them to Redis for storage. Redis provides a highly available mechanism enabling storage by any of the Elastic Beats and pulled by Logstash as required.
-
-The [pipeline configuration] defines the JSON format used for Besu logs and automatically picks up any new log fields.
-
-:::note
-
-The pipeline configuration must match the your log format. If using the default log format, you can use the [grok plugin](https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok.html) to extract the log fields.
-
-:::
-
-To see the Besu Quickstart network logs in Kibana:
-
-1. [Start the Developer Quickstart with Besu](../../tutorials/quickstart.md), selecting ELK monitoring.
-1. Open the [`Kibana logs address`](http://localhost:5601/app/kibana#/discover) listed by the sample networks `list.sh` script. The logs display in Kibana.
-
- ![Kibana](../../../assets/images/KibanaQuickstart.png)
-
-
-
-[Filebeat]: https://github.com/ConsenSys/quorum-dev-quickstart/blob/b72a0f64d685c851bf8be399a8e33bbdf0e09982/files/common/filebeat/filebeat.yml
-[Metricbeat]: https://github.com/ConsenSys/quorum-dev-quickstart/blob/b72a0f64d685c851bf8be399a8e33bbdf0e09982/files/common/metricbeat/metricbeat.yml
-[pipeline configuration]: https://github.com/ConsenSys/quorum-dev-quickstart/blob/b72a0f64d685c851bf8be399a8e33bbdf0e09982/files/common/logstash/pipeline/20_besu.conf
-[Elastic Stack]: https://www.elastic.co/what-is/elk-stack
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/index.md b/versioned_docs/version-23.10.0/private-networks/how-to/monitor/index.md
deleted file mode 100644
index 08ff29aede2..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/index.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-description: Monitoring using metrics and logging
-tags:
- - private networks
----
-
-# Monitoring
-
-Use monitoring to identify node and network issues. In private networks, you can [configure metrics and logging](../../../public-networks/how-to/monitor/index.md) as in public networks.
-
-You can also use the following monitoring tools in private networks:
-
-- [Loki](loki.md)
-- [Elastic Stack](elastic-stack.md)
-- [Quorum Hibernate](quorum-hibernate.md)
-- [Splunk](splunk.md)
-- [OpenTelemetry](opentelemetry.md)
-- [Chainlens Explorer](chainlens.md)
-
-For an overview of monitoring Hyperledger Besu, view [this recording](https://www.youtube.com/watch?v=7BuutRe0I28&feature=youtu.be).
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/loki.md b/versioned_docs/version-23.10.0/private-networks/how-to/monitor/loki.md
deleted file mode 100644
index eabe6f0667b..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/loki.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Use Grafana Loki
-sidebar_position: 2
-description: Using Grafana Loki log management platform with Hyperledger Besu
-tags:
- - private networks
----
-
-# Grafana Loki
-
-[Grafana Loki] is an open-source log management platform that is available when using the [Developer Quickstart](../../tutorials/quickstart.md).
-
-The [Promtail configuration] ingests logs at regular defined intervals and outputs them to [Loki] for storage.
-
-The `pipeline configuration` in Promtail defines pipeline stages that can collate logs natively or using the JSON format.
-
-:::note
-
-If using the pipeline regex stage in `Promtail`, configuration must match your log format.
-
-:::
-
-To view the GoQuorum Quickstart network logs in Loki:
-
-1. [Start the Developer Quickstart with Besu](../../tutorials/quickstart.md), selecting Loki monitoring.
-2. Open the [`Grafana Loki address`](http://localhost:3000/d/Ak6eXLsPxFemKYKEXfcH/quorum-logs-loki?orgId=1&var-app=besu&var-search=&from=now-15m&to=now) listed by the sample networks `list.sh` script.
-
- The logs display in Loki.
-
- ![Loki logs](../../../assets/images/grafana_loki.png)
-
-
-
-[Promtail configuration]: https://github.com/ConsenSys/quorum-dev-quickstart/blob/master/files/common/promtail/promtail.yml
-[pipeline configuration]: https://github.com/ConsenSys/quorum-dev-quickstart/blob/master/files/common/promtail/promtail.yml
-[Loki]: https://github.com/ConsenSys/quorum-dev-quickstart/blob/master/files/common/loki/loki.yml
-[Grafana Loki]: https://grafana.com/oss/loki/
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/opentelemetry.md b/versioned_docs/version-23.10.0/private-networks/how-to/monitor/opentelemetry.md
deleted file mode 100644
index 185b61da3d5..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/opentelemetry.md
+++ /dev/null
@@ -1,176 +0,0 @@
----
-title: Use OpenTelemetry
-sidebar_position: 6
-description: Collect Besu information with the OpenTelemetry Collector
-tags:
- - private networks
----
-
-# Use OpenTelemetry
-
-You can use the OpenTelemetry monitoring and tracing service to gather node metrics and traces. To enable OpenTelemetry to access Hyperledger Besu, use the [`--metrics-enabled`](../../../public-networks/reference/cli/options.md#metrics-enabled) and [`--metrics-protocol=opentelemetry`](../../../public-networks/reference/cli/options.md#metrics-protocol) options. Use [Splunk](https://splunk.com) to visualize the collected data. A [Besu Sync example](https://github.com/splunk/splunk-connect-for-ethereum/tree/master/examples/besu-sync) is available.
-
-:::tip
-
-Use OpenTelemetry to monitor the sync time of your Besu node and show where time is spent internally and over the JSON-RPC interface.
-
-[This office hours recording](https://wiki.hyperledger.org/display/BESU/2021-01-19+Office+Hours+Notes) shows examples of monitoring Hyperledger Besu.
-
-:::
-
-## Install OpenTelemetry Collector
-
-Download and install the [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector-contrib/releases).
-
-:::tip
-
-You can also install exporters that send system metrics to OpenTelemetry to monitor non-Besu-specific items such as disk and CPU usage. The OpenTelemetry Collector can connect to additional applications, and may be deployed in Kubernetes environments as a daemonset.
-
-:::
-
-## Setting up and running OpenTelemetry with Besu
-
-1. Configure OpenTelemetry to accept data from Besu. For example, use the following configuration for your `otel-collector-config.yml` file, and send data to Splunk and Splunk APM:
-
- ```yml title="otel-collector-config.yml"
- receivers:
- otlp:
- protocols:
- grpc:
- http:
-
- exporters:
- splunk_hec/traces:
- # Splunk HTTP Event Collector token.
- token: "11111111-1111-1111-1111-1111111111113"
- # URL to a Splunk instance to send data to.
- endpoint: "https://:8088/services/collector"
- # Optional Splunk source: https://docs.splunk.com/Splexicon:Source
- source: "besu:traces"
- # Optional Splunk source type: https://docs.splunk.com/Splexicon:Sourcetype
- sourcetype: "otlp"
- # Splunk index, optional name of the Splunk index targeted.
- index: "traces"
- # Maximum HTTP connections to use simultaneously when sending data. Defaults to 100.
- max_connections: 20
- # Whether to disable gzip compression over HTTP. Defaults to false.
- disable_compression: false
- # HTTP timeout when sending data. Defaults to 10s.
- timeout: 10s
- # Whether to skip checking the certificate of the HEC endpoint when sending data over HTTPS. Defaults to false.
- # For this demo, we use a self-signed certificate on the Splunk docker instance, so this flag is set to true.
- insecure_skip_verify: true
- splunk_hec/metrics:
- # Splunk HTTP Event Collector token.
- token: "11111111-1111-1111-1111-1111111111113"
- # URL to a Splunk instance to send data to.
- endpoint: "https://:8088/services/collector"
- # Optional Splunk source: https://docs.splunk.com/Splexicon:Source
- source: "besu:metrics"
- # Optional Splunk source type: https://docs.splunk.com/Splexicon:Sourcetype
- sourcetype: "prometheus"
- # Splunk index, optional name of the Splunk index targeted.
- index: "metrics"
- # Maximum HTTP connections to use simultaneously when sending data. Defaults to 100.
- max_connections: 20
- # Whether to disable gzip compression over HTTP. Defaults to false.
- disable_compression: false
- # HTTP timeout when sending data. Defaults to 10s.
- timeout: 10s
- # Whether to skip checking the certificate of the HEC endpoint when sending data over HTTPS. Defaults to false.
- # For this demo, we use a self-signed certificate on the Splunk docker instance, so this flag is set to true.
- insecure_skip_verify: true
- # Traces
- sapm:
- access_token: "${SPLUNK_ACCESS_TOKEN}"
- endpoint: "https://ingest.${SPLUNK_REALM}.signalfx.com/v2/trace"
- # Metrics + Events
- signalfx:
- access_token: "${SPLUNK_ACCESS_TOKEN}"
- realm: "${SPLUNK_REALM}"
-
- processors:
- batch:
-
- extensions:
- health_check:
- pprof:
- zpages:
-
- service:
- extensions: [pprof, zpages, health_check]
- pipelines:
- traces:
- receivers: [otlp]
- exporters: [splunk_hec/traces, sapm]
- processors: [batch]
- metrics:
- receivers: [otlp]
- exporters: [splunk_hec/metrics, signalfx]
- processors: [batch]
- ```
-
- It is easiest to run the OpenTelemetry collector with Docker with the following command:
-
-
-
- # Syntax
-
- ```bash
- docker run -d \
- -v ./otel-collector-config.yml:/etc/otel/config.yaml \
- -e SPLUNK_ACCESS_TOKEN= \
- -e SPLUNK_REALM= \
- -p 4317:4317 \
- otel/opentelemetry-collector-contrib:latest
- ```
-
- # Example
-
- ```bash
- docker run -d \
- -v ./otel-collector-config.yml:/etc/otel/config.yaml \
- -e SPLUNK_ACCESS_TOKEN=abcdefg654 \
- -e SPLUNK_REALM=us1 \
- -p 4317:4317 \
- otel/opentelemetry-collector-contrib:latest
- ```
-
-
-
- You can also refer to this [Docker-compose example](https://github.com/splunk/splunk-connect-for-ethereum/blob/989dc2ccae7d8235bf3ce2a83a18cf0cd1713294/examples/besu-sync/full-sync/docker-compose.yaml).
-
-2. Start Besu with the [`--metrics-enabled`](../../../public-networks/reference/cli/options.md#metrics-enabled) and [`--metrics-protocol=opentelemetry`](../../../public-networks/reference/cli/options.md#metrics-protocol) options. For example, run the following command to start a single node:
-
-
-
- # Syntax
-
- ```bash
- OTEL_EXPORTER_OTLP_ENDPOINT=https://: besu --network=dev --miner-enabled --miner-coinbase --rpc-http-cors-origins="all" --rpc-http-enabled --metrics-enabled --metrics-protocol=opentelemetry
- ```
-
- # Example
-
- ```bash
- OTEL_EXPORTER_OTLP_ENDPOINT=https://localhost:4317 besu --network=dev --miner-enabled --miner-coinbase fe3b557e8fb62b89f4916b721be55ceb828dbd73 --rpc-http-cors-origins="all" --rpc-http-enabled --metrics-enabled --metrics-protocol=opentelemetry
- ```
-
-
-
- The [OpenTelemetry SDK](https://github.com/open-telemetry/opentelemetry-specification/blob/8f7cdb73618a0b3afa9532b8f8103d719e352781/specification/sdk-environment-variables.md) mandates how to configure the OpenTelemetry gRPC client, so data flows to the collector from Besu.
-
- You can use the following environment variables:
-
- | Name | Description | Required |
- | --- | --- | --- |
- | OTEL_EXPORTER_OTLP_ENDPOINT | OpenTelemetry Collector endpoint, of the form `https://host:port`. The default value is `https://localhost:4317` | Yes |
- | OTEL_EXPORTER_OTLP_INSECURE | Whether to allow insecure connections for OpenTelemetry data. False by default. | No |
-
-
-
-[Monitoring Besu synchronization to chain with Splunk]: https://github.com/splunk/splunk-connect-for-ethereum/tree/master/examples/besu-sync
-
-
-
-\*[APM]: Application Performance Monitoring
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/quorum-hibernate.md b/versioned_docs/version-23.10.0/private-networks/how-to/monitor/quorum-hibernate.md
deleted file mode 100644
index 2d6b6139db0..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/quorum-hibernate.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Use Quorum Hibernate
-sidebar_position: 4
-description: Use Quorum Hibernate with Hyperledger Besu
-tags:
- - private networks
----
-
-# Use Quorum Hibernate
-
-[Quorum Hibernate] is a proxy that monitors a node's API traffic and hibernates the node when inactive. This reduces infrastructure costs by ensuring only nodes receiving API requests or nodes required to establish consensus are running.
-
-Quorum Hibernate wakes up hibernating nodes:
-
-- When a new transaction or API request is received.
-- To allow it to periodically sync with the network.
-
-
-
-[Quorum Hibernate]: https://github.com/ConsenSys/quorum-hibernate
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/splunk.md b/versioned_docs/version-23.10.0/private-networks/how-to/monitor/splunk.md
deleted file mode 100644
index 2b749536740..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/monitor/splunk.md
+++ /dev/null
@@ -1,192 +0,0 @@
----
-title: Use Splunk
-sidebar_position: 5
-description: Send Hyperledger Besu logs to Splunk
-tags:
- - private networks
----
-
-# Use Splunk
-
-[Splunk](https://splunkbase.splunk.com/app/4866/) is a third-party monitoring solution compatible with Besu. A Splunk server can receive Besu logs and enable complex search, visualization, and analysis.
-
-Splunk can aggregate multiple logs in one place and run complex queries without being connected to the machine running Besu to read the standard output.
-
-Options for running Splunk and Besu are:
-
-- [Use Splunk](#use-splunk)
- - [Developer Quickstart with Splunk](#developer-quickstart-with-splunk)
- - [Splunk Connect for Ethereum Docker Compose](#splunk-connect-for-ethereum-docker-compose)
- - [Requirements](#requirements)
- - [Steps](#steps)
- - [Use Splunk Enterprise as a Docker container](#use-splunk-enterprise-as-a-docker-container)
- - [Prerequisites](#prerequisites)
- - [Steps](#steps-1)
- - [Run a Splunk Enterprise instance](#run-a-splunk-enterprise-instance)
- - [Prerequisites](#prerequisites-1)
- - [Steps](#steps-2)
- - [Splunk options reference](#splunk-options-reference)
-
-## Developer Quickstart with Splunk
-
-To view the Quickstart network logs in Splunk:
-
-1. [Start the Developer Quickstart with Besu](../../tutorials/quickstart.md), selecting Splunk monitoring.
-1. Open the [Splunk UI](http://localhost:8000).
-
-## Splunk Connect for Ethereum Docker Compose
-
-To run a development Besu node and connect it to Splunk Enterprise, use the Splunk Connect for Ethereum demonstration Docker Compose environment provided by Splunk.
-
-### Requirements
-
-- [Git](https://git-scm.com/)
-- [Docker and Docker-compose](https://docs.docker.com/compose/install/)
-
-:::info
-
-A Splunk license is not required to use the Splunk Connect for Ethereum demonstration.
-
-:::
-
-### Steps
-
-1. Clone the Splunk Connect for Ethereum repository:
-
- ```bash
- git clone https://github.com/splunk/splunk-connect-for-ethereum.git
- cd splunk-connect-for-ethereum
- ```
-
-1. Start the demonstration environment by following the Splunk Connect for Ethereum repository [README](https://github.com/splunk/splunk-connect-for-ethereum/tree/master/examples/besu).
-
- :::note
-
- Splunk enterprise takes some time to start.
-
- Run `docker ps` and wait for the `STATUS` of the 3 containers to be `Up [number] seconds (healthy)`.
-
- ```
- CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
- 127600dd1173 splunkdlt/ethlogger:latest "ethlogger" 53 seconds ago Up 51 seconds (healthy) ethlogger
- 88dfcee683c4 splunk/splunk:latest "/sbin/entrypoint.sh…" 53 seconds ago Up 52 seconds (healthy) 8065/tcp, 8088-8089/tcp, 8191/tcp, 9887/tcp, 9997/tcp, 0.0.0.0:18000->8000/tcp splunk
- 111b0c6d6072 hyperledger/besu:1.4.4 "besu" 53 seconds ago Up 52 seconds (healthy) 8545-8547/tcp, 30303/tcp besu
- ```
-
- :::
-
-## Use Splunk Enterprise as a Docker container
-
-### Prerequisites
-
-- [Docker](https://docs.docker.com/compose/install/)
-- [Besu 1.4.4](https://github.com/hyperledger/besu/blob/750580dcca349d22d024cc14a8171b2fa74b505a/CHANGELOG.md#144) or later [installed](../../get-started/install/binary-distribution.md)
-
-:::info
-
-A Splunk license is not required to use the trial version of the Splunk Docker image. The image is not suitable for production use and has [restrictions on daily log volume](https://www.splunk.com/).
-
-:::
-
-:::note
-
-If running [Besu as a Docker container](../../get-started/install/run-docker-image.md), consider using [Splunk Connect for Ethereum Docker Compose](#splunk-connect-for-ethereum-docker-compose) or [Kubernetes](../deploy/kubernetes.md) instead of the Splunk Enterprise trial container.
-
-:::
-
-### Steps
-
-1. Start the Splunk Enterprise container:
-
- ```bash
- docker run \
- -e SPLUNK_START_ARGS=--accept-license \
- -e SPLUNK_HEC_TOKEN=11111111-1111-1111-1111-1111111111113 \
- -e SPLUNK_PASSWORD=changeme \
- --rm \
- -p8080:8000 -p8088:8088 \
- -d \
- --name splunk-demo \
- splunk/splunk:latest
- ```
-
- Once the service is started, connect on [`http://localhost:8080/`](http://localhost:8080/) and login as the `admin` user with a password of `changeme`.
-
- :::tip
-
- To follow the logs of the Splunk container:
-
- ```bash
- docker logs -f splunk-demo
- ```
-
- :::
-
-2. Create the Besu index:
-
- 1. In the Splunk Web interface, navigate to the [index list in the settings](http://localhost:8080/en-US/manager/search/data/indexes).
- 2. [Create an event index] with an Index Name of `besu`.
- 3. Leave other fields with the default values.
- 4. Save the `besu` index.
-
-3. Run Besu. To start a Besu node running in development mode, run the following command:
-
- ```bash
- LOGGER=Splunk \
- SPLUNK_URL=https://localhost:8088 \
- SPLUNK_TOKEN=11111111-1111-1111-1111-1111111111113 \
- SPLUNK_SKIPTLSVERIFY=true \
- besu \
- --network=dev \
- --miner-coinbase=0xfe3b557e8fb62b89f4916b721be55ceb828dbd73 \
- --miner-enabled \
- --logging=trace
- ```
-
- The environment variables specified send the Besu logs to Splunk. Only `LOGGER`, `SPLUNK_URL`, `SPLUNK_TOKEN` and `SPLUNK_SKIPTLSVERIFY` are required in this example. The complete list of options is in the [Splunk options reference table](#splunk-options-reference).
-
-4. In the Splunk Web interface, navigate to the [search page](http://localhost:8080/en-US/app/search/search). Type `index="besu"` in the search field. Log events sent by Besu are displayed.
-
- Congratulations! You can now play with the search and other Splunk features to explore your Besu logs.
-
- ![Splunk search page](../../../assets/images/splunk-ui.png)
-
-5. Stop Besu with ++ctrl+c++. Stop the Splunk container with `docker stop splunk-demo`.
-
-## Run a Splunk Enterprise instance
-
-### Prerequisites
-
-- [Splunk Enterprise license](https://www.splunk.com/)
-- [Besu 1.4.4](https://github.com/hyperledger/besu/blob/master/CHANGELOG.md#144) or later [installed](../../get-started/install/binary-distribution.md)
-
-### Steps
-
-1. Follow the steps in the [Splunk Enterprise documentation](https://docs.splunk.com/Documentation/Splunk/8.0.4/Installation) to download, install, and run Splunk Enterprise.
-
-1. After logging into the Splunk Enterprise Web interface, navigate to the settings to:
-
- 1. [Create an HTTP Event Collector](https://docs.splunk.com/Documentation/Splunk/8.0.4/Data/UsetheHTTPEventCollector).
- 1. [Create an event index] named `besu`.
-
-1. Run Besu as in step 3 in [using Splunk on Docker](#use-splunk-enterprise-as-a-docker-container). Set the `SPLUNK_URL` value to match the HTTP Event Collector address and port.
-
- You can display logs and use the search engine as in step 4 in [using Splunk on Docker](#use-splunk-enterprise-as-a-docker-container).
-
-## Splunk options reference
-
-| Name | Description | Required |
-| --- | --- | --- |
-| LOGGER | Set to `Splunk` to activate sending logs to Splunk. | Yes |
-| HOST | Current host. If in a Docker environment, the default value is the docker container ID. Otherwise, the default value is `localhost`. | No |
-| SPLUNK_URL | URL of the Splunk HTTP Event Collector. For example, use `https://localhost:8088` | Yes |
-| SPLUNK_TOKEN | Authentication token, usually of the form `11111111-1111-1111-1111-111111111111` | Yes |
-| SPLUNK_INDEX | [Index](https://docs.splunk.com/Splexicon:Index) to store logs. Defaults to `besu` | No |
-| SPLUNK_SOURCE | [Source of the logs](https://docs.splunk.com/Splexicon:Source). Defaults to `besu` | No |
-| SPLUNK_SOURCETYPE | [Source type of the logs](https://docs.splunk.com/Splexicon:Sourcetype). Defaults to `besu` | No |
-| SPLUNK_BATCH_SIZE_BYTES | Size of a log batch in bytes. Defaults to `65536` | No |
-| SPLUNK_BATCH_SIZE_COUNT | Size of a log batch in number of events. Defaults to `1000` | No |
-| SPLUNK_BATCH_INTERVAL | Interval at which to send log batches. Defaults to `500` | No |
-| SPLUNK_SKIPTLSVERIFY | Whether to check the Splunk instance TLS certificate when sending data. Defaults to `false` | No |
-
-[Create an event index]: https://docs.splunk.com/Documentation/Splunk/8.0.4/Indexer/Setupmultipleindexes#Create_events_indexes
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/_category_.json b/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/_category_.json
deleted file mode 100644
index a663c5c6ed7..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Create and send transactions",
- "position": 2
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/concurrent-private-transactions.md b/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/concurrent-private-transactions.md
deleted file mode 100644
index a1fb71eb48a..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/concurrent-private-transactions.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Send concurrent private transactions
-description: Creating and sending concurrent private transactions with Hyperledger Besu
-sidebar_position: 2
-tags:
- - private networks
----
-
-# Send concurrent private transactions
-
-Private transaction processing involves two transactions, the private transaction and the [privacy marker transaction (PMT)](../../concepts/privacy/private-transactions/processing.md). The private transaction and the PMT each have their own [nonce](../../concepts/privacy/private-transactions/index.md#nonces).
-
-If your private transaction rate requires sending private transactions without waiting for the previous private transaction to be mined, using [`eth_getTransactionCount`](../../../public-networks/reference/api/index.md#eth_gettransactioncount) and [`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction) may result in [incorrect nonces](../../concepts/privacy/private-transactions/index.md#private-nonce-management).
-
-In this case, use [`priv_distributeRawTransaction`](private-transactions.md#priv_distributerawtransaction) instead of [`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction).
-
-:::note
-
-You can use [`priv_getTransactionCount`](../../reference/api/index.md#priv_gettransactioncount) or [`priv_getEeaTransactionCount`](../../reference/api/index.md#priv_geteeatransactioncount) to get the nonce for an account for the specified privacy group or participants.
-
-:::
-
-Send the corresponding PMT using [`eth_sendRawTransaction`](../../../public-networks/reference/api/index.md#eth_sendrawtransaction), specifying the public PMT nonce. This method allows you to create and send the PMT yourself rather than [`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction) handling the PMT.
-
-:::caution
-
-When using `priv_distributeRawTransaction` to distribute transactions with consecutive nonces for the same account, the corresponding PMTs must use one account with the nonces in the same order as the private transactions.
-
-This is to ensure that the private transactions are executed in the correct order.
-
-:::
-
-:::info
-
-The [web3js-quorum library](https://github.com/ConsenSys/web3js-quorum/tree/master/example/concurrentPrivateTransactions) includes an example of how to send concurrent private transactions. The example uses [offchain privacy groups](../../concepts/privacy/privacy-groups.md). Use [`priv_getPrivacyPrecompileAddress`](../../reference/api/index.md#priv_getprivacyprecompileaddress) to get the precompile address to specify in the `to` field when creating the PMT.
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/index.md b/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/index.md
deleted file mode 100644
index 3f9920a3d31..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Create and send transactions
-description: private networks send transactions overview
-tags:
- - private networks
----
-
-# Create and send transactions
-
-In private networks, you can create and [send regular transactions](../../../public-networks/how-to/send-transactions.md) as in public networks.
-
-You can also:
-
-- [Send private transactions](private-transactions.md).
-- [Send concurrent private transactions](concurrent-private-transactions.md).
-- [Include revert reason in transactions](revert-reason.md).
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/private-transactions.md b/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/private-transactions.md
deleted file mode 100644
index cdeb49aec37..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/private-transactions.md
+++ /dev/null
@@ -1,142 +0,0 @@
----
-title: Create and send private transactions
-description: Creating and sending private transactions with Hyperledger Besu
-sidebar_position: 1
-tags:
- - private networks
----
-
-# Create and send private transactions
-
-Create and send [private transactions](../../concepts/privacy/index.md) using:
-
-- [web3js-quorum client library](../use-privacy/web3js-quorum.md) or [web3j client library](https://github.com/web3j/web3j)
-- [`eea_sendTransaction` with EthSigner](https://docs.ethsigner.consensys.net/Reference/API-Methods#eea_sendtransaction)
-- [`eea_sendRawTransaction`](#eea_sendrawtransaction)
-- [`priv_distributeRawTransaction`](#priv_distributerawtransaction).
-
-All private transaction participants must be online for a private transaction to be successfully distributed. If any participants are offline when submitting the private transaction, the transaction is not attempted and you must resubmit the transaction.
-
-The `gas` and `gasPrice` specified when sending a private transaction are used by the [privacy marker transaction (PMT)](../../concepts/privacy/private-transactions/processing.md), not the private transaction itself.
-
-:::note
-
-Private transactions either deploy contracts or call contract functions. Ether transfer transactions cannot be private.
-
-:::
-
-## eea_sendRawTransaction
-
-[`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction) distributes the private transaction to the participating nodes, and signs and submits the PMT, as described in [Private transaction processing](../../concepts/privacy/private-transactions/processing.md).
-
-:::note
-
-If [sending concurrent transactions](concurrent-private-transactions.md), you must use [`priv_distributeRawTransaction`](#priv_distributerawtransaction) instead of [`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction).
-
-:::
-
-## priv_distributeRawTransaction
-
-Use [`priv_distributeRawTransaction`](../../reference/api/index.md#priv_distributerawtransaction) instead of [`eea_sendRawTransaction`](#eea_sendrawtransaction) when sending [concurrent private transactions](concurrent-private-transactions.md).
-
-[`priv_distributeRawTransaction`](../../reference/api/index.md#priv_distributerawtransaction) distributes the private transaction to the participating nodes but does not sign and submit the PMT. That is, it performs steps 1 to 5 of [private transaction processing](../../concepts/privacy/private-transactions/processing.md).
-
-If using [`priv_distributeRawTransaction`](../../reference/api/index.md#priv_distributerawtransaction) instead of [`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction), use the value returned by [`priv_distributeRawTransaction`](../../reference/api/index.md#priv_distributerawtransaction), which is the enclave key to the private transaction in [Tessera](https://docs.tessera.consensys.net/), in the `data` field of a call to [`eth_sendRawTransaction`](../../../public-networks/reference/api/index.md#eth_sendrawtransaction). Use the value returned by [`priv_getPrivacyPrecompileAddress`](../../reference/api/index.md#priv_getprivacyprecompileaddress), which is the address of the [privacy precompiled contract](../../concepts/privacy/private-transactions/processing.md), in the `to` field of the call.
-
-By using the [public Ethereum transaction](../../how-to/send-transactions/index.md), [`eth_sendRawTransaction`](../../../public-networks/reference/api/index.md#eth_sendrawtransaction), you are signing and submitting the PMT yourself instead of having it signed by the Besu node, giving you greater control over the PMT.
-
-:::warning
-
-If the PMT is not sent after distributing the private transaction, the distributed private transaction is not executed and the private states are not updated.
-
-:::
-
-```json title="Distribute private transaction using priv_distributeRawTransaction"
-{
- "jsonrpc": "2.0",
- "method": "priv_distributeRawTransaction",
- "params": [
- "0xf90198808203e8832dc6c08080b8fb608060405234801561001057600080fd5b5060dc8061001f6000396000f3006080604052600436106049576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680633fa4f24514604e57806355241077146076575b600080fd5b348015605957600080fd5b50606060a0565b6040518082815260200191505060405180910390f35b348015608157600080fd5b50609e6004803603810190808035906020019092919050505060a6565b005b60005481565b80600081905550505600a165627a7a723058202bdbba2e694dba8fff33d9d0976df580f57bff0a40e25a46c398f8063b4c003600291ba05393543d483654fd01d9ee818cddfc7527dd6e13e6ef7b45a61e2ca13ffb6b70a0452338873862803ffe04056aea98cd0e3417ff971dcb384e54fce8ca1756a665a09de8260dc3763f8383a6a9ffe96909d36cd3ff4c346e3846a6467c50feaf0119e1a0839f41993789227ec721c9eaf1541683287fa436ef6edd9ec8fd088bad1a0c3c8a72657374726963746564"
- ],
- "id": 1
-}
-```
-
-```json title="Enclave key to the private transaction in Tessera returned by priv_distributeRawTransaction"
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0xfd0d90ab824574abc19c0776ca0210e764561d0ef6d621f2bbbea316eccfe56b"
-}
-```
-
-Send the enclave key in the `data` field, and the [privacy precompile address](../../reference/api/index.md#priv_getprivacyprecompileaddress) in the `to` field of `eth_sendRawTransaction`:
-
-```json
-{
- "jsonrpc": "2.0",
- "method": "eth_sendRawTransaction",
- "params": [
- {
- "from": "0xfe3b557e8fb62b89f4916b721be55ceb828dbd73",
- "to": "0x000000000000000000000000000000000000007e",
- "data": "0xfd0d90ab824574abc19c0776ca0210e764561d0ef6d621f2bbbea316eccfe56b",
- "gas": "0x2E1800",
- "gasPrice": "0x9184e72a000"
- }
- ],
- "id": 1
-}
-```
-
-## EEA-compliant or Besu-extended privacy
-
-To create an [EEA-compliant private transaction], specify `privateFor` when creating the signed transaction passed as an input parameter to [`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction).
-
-To create a [Besu-extended private transaction], specify a `privacyGroupId` when creating the signed transaction passed as an input parameter to [`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction).
-
-## Unsigned and unencoded private transactions
-
-The [`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction) parameter is a signed RLP-encoded private transaction. Shown below are examples of unsigned and unencoded private transactions to create a contract.
-
-```json title="Unencoded and unsigned EEA-compliant private transaction"
-{
- "to": null,
- "from": "0xfe3b557e8fb62b89f4916b721be55ceb828dbd73",
- "gas": "0x7600",
- "gasPrice": "0x0",
- "data": "0x608060405234801561001057600080fd5b5060dc8061001f6000396000f3006080604052600436106049576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680633fa4f24514604e57806355241077146076575b600080fd5b348015605957600080fd5b50606060a0565b6040518082815260200191505060405180910390f35b348015608157600080fd5b50609e6004803603810190808035906020019092919050505060a6565b005b60005481565b80600081905550505600a165627a7a723058202bdbba2e694dba8fff33d9d0976df580f57bff0a40e25a46c398f8063b4c00360029",
- "nonce": "0x0",
- "privateFrom": "negmDcN2P4ODpqn/6WkJ02zT/0w0bjhGpkZ8UP6vARk=",
- "privateFor": [
- "g59BmTeJIn7HIcnq8VQWgyh/pDbvbt2eyP0Ii60aDDw=",
- "6fg8q5rWMBoAT2oIiU3tYJbk4b7oAr7dxaaVY7TeM3U="
- ],
- "restriction": "restricted"
-}
-```
-
-```json title="Unencoded and unsigned Besu-extended private transaction"
-{
- "to": null,
- "from": "0xfe3b557e8fb62b89f4916b721be55ceb828dbd73",
- "gas": "0x7600",
- "gasPrice": "0x0",
- "data": "0x608060405234801561001057600080fd5b5060dc8061001f6000396000f3006080604052600436106049576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680633fa4f24514604e57806355241077146076575b600080fd5b348015605957600080fd5b50606060a0565b6040518082815260200191505060405180910390f35b348015608157600080fd5b50609e6004803603810190808035906020019092919050505060a6565b005b60005481565b80600081905550505600a165627a7a723058202bdbba2e694dba8fff33d9d0976df580f57bff0a40e25a46c398f8063b4c00360029",
- "nonce": "0x0",
- "privateFrom": "negmDcN2P4ODpqn/6WkJ02zT/0w0bjhGpkZ8UP6vARk=",
- "privacyGroupId": "kAbelwaVW7okoEn1+okO+AbA4Hhz/7DaCOWVQz9nx5M=",
- "restriction": "restricted"
-}
-```
-
-:::tip
-
-The `example` directory in the [web3js-quorum client library](../use-privacy/web3js-quorum.md) contains examples of signing and encoding private transactions.
-
-:::
-
-
-
-[EEA-compliant private transaction]: ../../concepts/privacy/privacy-groups.md#enterprise-ethereum-alliance-privacy
-[Besu-extended private transaction]: ../../concepts/privacy/privacy-groups.md#besu-extended-privacy
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/revert-reason.md b/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/revert-reason.md
deleted file mode 100644
index da206b31e80..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/send-transactions/revert-reason.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-title: Include revert reason
-description: Including revert reason in transactions with Hyperledger Besu
-sidebar_position: 3
-tags:
- - private networks
----
-
-# Revert reason
-
-In smart contracts, the [`revert`](https://docs.soliditylang.org/en/v0.8.12/control-structures.html#revert) operation triggers an exception to flag an error and revert the current call. The EVM passes back to the client an optional string message containing information about the error.
-
-```sol
-pragma solidity ^0.8.4;
-
-contract VendingMachine {
- address owner;
- constructor() {
- owner = msg.sender;
- }
- error Unauthorized();
- function buy(uint amount) public payable {
- if (amount > msg.value / 2 ether)
- revert("Not enough Ether provided.");
- // Alternative way to do it:
- require(
- amount <= msg.value / 2 ether,
- "Not enough Ether provided."
- );
- // Perform the purchase.
- }
- function withdraw() public {
- if (msg.sender != owner)
- revert Unauthorized();
-
- payable(msg.sender).transfer(address(this).balance);
- }
-}
-```
-
-## Enable revert reason
-
-Use the [`--revert-reason-enabled`](../../../public-networks/reference/cli/options.md#revert-reason-enabled) command line option to include the revert reason in the transaction receipt and the [`trace`](../../../public-networks/reference/trace-types.md#trace) response in Hyperledger Besu.
-
-:::caution
-
-Enabling revert reason may use a significant amount of memory. We do not recommend enabling revert reason when connected to public Ethereum networks.
-
-:::
-
-## Where the revert reason is included
-
-With revert reason enabled, the transaction receipt returned by [`eth_getTransactionReceipt`](../../../public-networks/reference/api/index.md#eth_gettransactionreceipt) includes the revert reason as an ABI-encoded string.
-
-:::info
-
-The revert reason is not included in the transaction receipt's root hash. Not including the revert reason in the transactions receipt's root hash means the revert reason is only available to nodes that execute the transaction when importing the block. That is, the revert reason is not available if using fast synchronization ([`--sync-mode=FAST`](../../../public-networks/reference/cli/options.md#sync-mode)).
-
-:::
-
-```json title="Example of transaction receipt"
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "blockHash": "0xe7212a92cfb9b06addc80dec2a0dfae9ea94fd344efeb157c41e12994fcad60a",
- "blockNumber": "0x50",
- "contractAddress": null,
- "cumulativeGasUsed": "0x5208",
- "from": "0x627306090abab3a6e1400e9345bc60c78a8bef57",
- "gasUsed": "0x5208",
- "logs": [],
- "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
- "status": "0x1",
- "to": "0xf17f52151ebef6c7334fad080c5704d77216b732",
- "transactionHash": "0xc00e97af59c6f88de163306935f7682af1a34c67245e414537d02e422815efc3",
- "transactionIndex": "0x0",
- "revertReason": "0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000001a4e6f7420656e6f7567682045746865722070726f76696465642e000000000000"
- }
-}
-```
-
-With revert reason enabled, the list items in the [`trace`](../../../public-networks/reference/trace-types.md#trace) response returned by [`trace_replayBlockTransactions`](../../../public-networks/reference/api/index.md#trace_replayblocktransactions), [`trace_block`](../../../public-networks/reference/api/index.md#trace_block), and [`trace_transaction`](../../../public-networks/reference/api/index.md#trace_transaction) include the revert reason as an ABI-encoded string.
-
-```json title="Example of trace response list item"
-{
- "jsonrpc": "2.0",
- "id": 415,
- "result": [
- {
- "action": {
- "callType": "call",
- "from": "0xfe3b557e8fb62b89f4916b721be55ceb828dbd73",
- "gas": "0xffadea",
- "input": "0x",
- "to": "0x0110000000000000000000000000000000000000",
- "value": "0x0"
- },
- "blockHash": "0x220bc13dc4f1ed38dcca927a5be15eca16497d279f4c40d7b8fe9704eadf1464",
- "blockNumber": 18,
- "error": "Reverted",
- "revertReason": "0x7d88c1856cc95352",
- "subtraces": 0,
- "traceAddress": [],
- "transactionHash": "0xc388baa0e55e6b73e850b22dc7e9853700f6b995fd55d95dd6ccd5a13d63c566",
- "transactionPosition": 1,
- "type": "call"
- }
- ]
-}
-```
-
-By default, the error returned by [`eth_estimateGas`](../../../public-networks/reference/api/index.md#eth_estimategas) and [`eth_call`](../../../public-networks/reference/api/index.md#eth_call) includes the revert reason as an ABI-encoded string in the `data` field.
-
-```json title="Example of eth_estimateGas and eth_call error"
-{
- "jsonrpc": "2.0",
- "id": 3,
- "error": {
- "code": -32000,
- "message": "Execution reverted: ERC20: transfer amount exceeds balance",
- "data": "0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000001a4e6f7420656e6f7567682045746865722070726f76696465642e000000000000"
- }
-}
-```
-
-## Revert reason format
-
-As described in the [Solidity documentation], the revert reason is an ABI-encoded string consisting of:
-
-```bash
-0x08c379a0 // Function selector for Error(string)
-0x0000000000000000000000000000000000000000000000000000000000000020 // Data offset
-0x000000000000000000000000000000000000000000000000000000000000001a // String length
-0x4e6f7420656e6f7567682045746865722070726f76696465642e000000000000 // String data
-```
-
-```bash title="Example of revert reason string for 'Not enough Ether provided' "
-"0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000001a4e6f7420656e6f7567682045746865722070726f76696465642e000000000000"
-```
-
-## Dapp support
-
-Client libraries, such as web3j, do not support extracting the revert reason from the transaction receipt. To extract the revert reason your dapp must interact directly with Besu using a custom JSON -> Object converter.
-
-
-
-[Solidity documentation]: https://docs.soliditylang.org/en/v0.8.12/control-structures.html#revert
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/upgrade.md b/versioned_docs/version-23.10.0/private-networks/how-to/upgrade.md
deleted file mode 100644
index 9d985eeb6e4..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/upgrade.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Upgrade
-description: Upgrading protocol versions
-sidebar_position: 8
-tags:
- - private networks
----
-
-# Network and protocol upgrades
-
-:::info
-
-Node upgrades upgrade your Besu client to a later version. In private networks, you can [upgrade your node](../../public-networks/how-to/upgrade-node.md) as in public networks.
-
-:::
-
-Network upgrades are the mechanism for upgrading the Ethereum protocol. Protocol upgrades occur during the network upgrades.
-
-For Ethereum Mainnet and public testnets, the milestone block definitions are included in Besu. Upgrading your Besu client applies the network upgrade.
-
-For private networks, all network participants must agree on the protocol upgrades and coordinate the network upgrades. The genesis file specifies the milestone block at which to apply the protocol upgrade.
-
-## Upgrade the protocol
-
-To upgrade the protocol in a private network:
-
-1. Review included EIPs for breaking changes. A [meta EIP](https://eips.ethereum.org/meta) for each protocol upgrade lists included EIPs. For example, [Istanbul](https://eips.ethereum.org/EIPS/eip-1679).
-1. Network participants agree on the block number at which to upgrade.
-1. For each node in the network:
- 1. Add the [milestone block number](../../public-networks/reference/genesis-items.md#milestone-blocks) to the genesis file.
- 1. Restart the node before reaching milestone block.
-
-:::caution
-
-To avoid a forked network, all network participants must update their genesis file to include the agreed on milestone block and restart their node before reaching the milestone block.
-
-:::
-
-:::tip
-
-- For compatibility with future protocol upgrades, don't hardcode any gas price assumptions.
-- Implementing upgradeable contracts enables contracts to be upgraded if a protocol upgrade does include breaking changes.
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-permissioning/_category_.json b/versioned_docs/version-23.10.0/private-networks/how-to/use-permissioning/_category_.json
deleted file mode 100644
index cbca3cfba02..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-permissioning/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Use permissioning",
- "position": 5
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-permissioning/local.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-permissioning/local.md
deleted file mode 100644
index c1269a66d9e..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-permissioning/local.md
+++ /dev/null
@@ -1,191 +0,0 @@
----
-title: Use local permissioning
-sidebar_position: 1
-description: Hyperledger Besu local permissioning
-tags:
- - private networks
----
-
-# Use local permissioning
-
-[Local permissioning](../../concepts/permissioning/index.md#local) supports node and account allowlisting.
-
-## Node allowlisting
-
-You can allow access to specified nodes in the [permissions configuration file](#permissions-configuration-file). With node allowlisting enabled, communication is only between nodes in the allowlist.
-
-:::info
-
-Node allowlists [support domain names] in enode URLs as an early access feature. Use the `--Xdns-enabled` option to enable domain name support.
-
-If using Kubernetes, enable domain name support and use the `--Xdns-update-enabled` option to ensure that Besu can connect to a container after being restarted, even if the IP address of the container changes.
-
-:::
-
-:::info Nodes allowlist in the permissions configuration file
-
-`nodes-allowlist=["enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@192.168.0.9:4567","enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@192.169.0.9:4568"]`
-
-:::
-
-Node allowlisting is at the node level. That is, each node in the network has a [permissions configuration file](#permissions-configuration-file) file in the [data directory](../../../public-networks/reference/cli/options.md#data-path) for the node.
-
-Local permissioning doesn't check that the node using the permissions configuration file is listed in the allowlist, it only checks that the remote end of the connection is in the allowlist. Use [onchain permissioning] if you need to check both ends of the connection.
-
-### Specify bootnodes in the allowlist
-
-The nodes permissions list must include the [bootnodes](../configure/bootnodes.md) or Hyperledger Besu doesn't start with node permissions enabled.
-
-If you start Besu with specified bootnodes and have node permissioning enabled:
-
-```bash
---bootnodes="enode://7e4ef30e9ec683f26ad76ffca5b5148fa7a6575f4cfad4eb0f52f9c3d8335f4a9b6f9e66fcc73ef95ed7a2a52784d4f372e7750ac8ae0b544309a5b391a23dd7@127.0.0.1:30303","enode://2feb33b3c6c4a8f77d84a5ce44954e83e5f163e7a65f7f7a7fec499ceb0ddd76a46ef635408c513d64c076470eac86b7f2c8ae4fcd112cb28ce82c0d64ec2c94@127.0.0.1:30304","enode://7b61d5ee4b44335873e6912cb5dd3e3877c860ba21417c9b9ef1f7e500a82213737d4b269046d0669fb2299a234ca03443f25fe5f706b693b3669e5c92478ade@127.0.0.1:30305"
-```
-
-The `nodes-allowlist` in the [permissions configuration file](#permissions-configuration-file) must contain the specified bootnodes.
-
-:::tip
-
-If your node has two different IP addresses for ingress and egress (for example, if you use Kubernetes implementing a load balancer for ingress and a NAT gateway IP address for egress), add both addresses to the allowlist, using the same public key for each IP address. This will allow the node to connect.
-
-:::
-
-### Enable node allowlisting
-
-To enable node allowlisting, specify the [`--permissions-nodes-config-file-enabled`](../../reference/cli/options.md#permissions-nodes-config-file-enabled) option when starting Besu.
-
-The `PERM` API methods are not enabled by default. To enable the `PERM` API methods, use the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../public-networks/reference/cli/options.md#rpc-ws-api) options.
-
-### Update the node allowlist
-
-To update the nodes allowlist while the node is running, use the following JSON-RPC API methods:
-
-- [perm_addNodesToAllowlist](../../reference/api/index.md#perm_addnodestoallowlist)
-- [perm_removeNodesFromAllowlist](../../reference/api/index.md#perm_removenodesfromallowlist)
-
-You can also update the [`permissions_config.toml`](#permissions-configuration-file) file directly and then update the allowlist using the [`perm_reloadPermissionsFromFile`](../../reference/api/index.md#perm_reloadpermissionsfromfile) method.
-
-Updates to the permissions configuration file persist across node restarts.
-
-### View the node allowlist
-
-To view the nodes allowlist, use the [perm_getNodesAllowlist](../../reference/api/index.md#perm_getnodesallowlist) method.
-
-:::note
-
-Each node has a [permissions configuration file](#permissions-configuration-file), which means nodes can have different nodes allowlists. This means nodes might be participating in the network that are not on the allowlist of other nodes in the network. We recommend each node in the network has the same nodes allowlist.
-
-:::
-
-```bash Example of different node allowlists
-
-Node 1 Allowlist = [Node 2, Node 3]
-
-Node 2 Allowlist = [Node 3, Node 5]
-
-Node 5 is participating in the same network as Node 1 even though Node 1 does not have Node 5
-on their allowlist.
-```
-
-## Account allowlisting
-
-You can specify accounts in the accounts allowlist in the [permissions configuration file](#permissions-configuration-file). A node with account permissioning accepts transactions only from accounts in the accounts allowlist.
-
-:::info Accounts allowlist in the permissions configuration file
-
-`accounts-allowlist=["0x0000000000000000000000000000000000000009"]`
-
-:::
-
-Account allowlisting is at the node level. That is, each node in the network has a [permissions configuration file](#permissions-configuration-file) in the [data directory](../../../public-networks/reference/cli/options.md#data-path) for the node.
-
-:::caution Using account permissioning and privacy
-
-Account permissioning is incompatible with [random key signing](../use-privacy/sign-pmts.md) for [privacy marker transactions](../../concepts/privacy/private-transactions/processing.md).
-
-If using account permissioning and privacy, a signing key must be specified using the [`--privacy-marker-transaction-signing-key-file`](../../reference/cli/options.md#privacy-marker-transaction-signing-key-file) command line option and the corresponding public key included in the accounts allowlist.
-
-:::
-
-Transaction validation against the accounts allowlist occurs at the following points:
-
-- Submitted by JSON-RPC API method [`eth_sendRawTransaction`](../../../public-networks/reference/api/index.md#eth_sendrawtransaction)
-- Received via propagation from another node
-- Added to a block by a mining node
-
-After adding transactions to a block, the transactions are not validated against the allowlist when received by another node. That is, a node can synchronize and add blocks containing transactions from accounts that are not on the accounts allowlist of that node.
-
-The following diagram illustrates applying local and onchain permissioning rules.
-
-![Permissioning Flow](../../../assets/images/PermissioningFlow.png)
-
-```bash title="Example of different account allowlists"
-
-Node 1 Allowlist = [Account A, Account B]
-
-Node 2 Allowlist = [Account B, Account C]
-
-Mining Node Allowlist = [Account A, Account B]
-
-Account A submits a transaction on Node 1. Node 1 validates and propagates the transaction. The
-Mining Node receives the transaction, validates it is from an account in the Mining Node
-accounts allowlist, and includes the transaction in the block. Node 2 receives and adds
-the block created by the Mining Node.
-
-Node 2 now has a transaction in the blockchain from Account A, which is not on the accounts
-allowlist for Node 2.
-
-```
-
-:::note
-
-Each node has a [permissions configuration file](#permissions-configuration-file) which means nodes in the network can have different accounts allowlists. This means a transaction can be successfully submitted by Node A from an account in the Node A allowlist but rejected by Node B to which it's propagated if the account is not in the Node B allowlist. We recommend each node in the network has the same accounts allowlist.
-
-:::
-
-### Enable account allowlisting
-
-To enable account allowlisting, specify the [`--permissions-accounts-config-file-enabled`](../../reference/cli/options.md#permissions-accounts-config-file-enabled) option when starting Besu.
-
-The `PERM` API methods are not enabled by default. To enable the `PERM` API methods, use the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../public-networks/reference/cli/options.md#rpc-ws-api) options.
-
-### Update the account allowlist
-
-To update the accounts allowlist when the node is running, use the JSON-RPC API methods:
-
-- [`perm_addAccountsToAllowlist`](../../reference/api/index.md#perm_addaccountstoallowlist)
-- [`perm_removeAccountsFromAllowlist`](../../reference/api/index.md#perm_removeaccountsfromallowlist).
-
-You can also update the [`permissions_config.toml`](#permissions-configuration-file) file directly and use the [`perm_reloadPermissionsFromFile`](../../reference/api/index.md#perm_reloadpermissionsfromfile) method to update the allowlists.
-
-Updates to the permissions configuration file persist across node restarts.
-
-### View the account allowlist
-
-To view the accounts allowlist, use the [`perm_getAccountsAllowlist`](../../reference/api/index.md#perm_getaccountsallowlist) method.
-
-## Permissions configuration file
-
-The permissions configuration file contains the nodes and accounts allowlists. If the [`--permissions-accounts-config-file`](../../reference/cli/options.md#permissions-accounts-config-file) and [`--permissions-nodes-config-file`](../../reference/cli/options.md#permissions-nodes-config-file) options are not specified, the name of the permissions configuration file must be [`permissions_config.toml`](#permissions-configuration-file) and must be in the [data directory](../../../public-networks/reference/cli/options.md#data-path) for the node.
-
-You can specify the accounts and nodes allowlists in the same file or in separate files for accounts and nodes.
-
-To specify a permissions configuration file (or separate files for accounts and nodes) in any location, use the [`--permissions-accounts-config-file`](../../reference/cli/options.md#permissions-accounts-config-file) and [`--permissions-nodes-config-file`](../../reference/cli/options.md#permissions-nodes-config-file) options.
-
-:::note
-
-The [`--permissions-accounts-config-file`](../../reference/cli/options.md#permissions-accounts-config-file) and [`permissions-nodes-config-file`](../../reference/cli/options.md#permissions-nodes-config-file) options are not used when running Besu from the [Docker image](../../get-started/install/run-docker-image.md). Use a bind mount to [specify a permissions configuration file with Docker].
-
-:::
-
-```toml title="Sample permissions configuration file"
-accounts-allowlist=["0xb9b81ee349c3807e46bc71aa2632203c5b462032", "0xb9b81ee349c3807e46bc71aa2632203c5b462034"]
-
-nodes-allowlist=["enode://7e4ef30e9ec683f26ad76ffca5b5148fa7a6575f4cfad4eb0f52f9c3d8335f4a9b6f9e66fcc73ef95ed7a2a52784d4f372e7750ac8ae0b544309a5b391a23dd7@127.0.0.1:30303","enode://2feb33b3c6c4a8f77d84a5ce44954e83e5f163e7a65f7f7a7fec499ceb0ddd76a46ef635408c513d64c076470eac86b7f2c8ae4fcd112cb28ce82c0d64ec2c94@127.0.0.1:30304","enode://7b61d5ee4b44335873e6912cb5dd3e3877c860ba21417c9b9ef1f7e500a82213737d4b269046d0669fb2299a234ca03443f25fe5f706b693b3669e5c92478ade@127.0.0.1:30305"]
-```
-
-
-
-[specify a permissions configuration file with Docker]: ../../get-started/install/run-docker-image.md
-[support domain names]: ../../../public-networks/concepts/node-keys.md#domain-name-support
-[onchain permissioning]: ../../concepts/permissioning/onchain.md
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-permissioning/onchain.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-permissioning/onchain.md
deleted file mode 100644
index 4b177026a20..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-permissioning/onchain.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Use onchain permissioning
-sidebar_position: 2
-description: Use onchain permissioning allowlists
-tags:
- - private networks
----
-
-# Use onchain permissioning
-
-This page contains some extra info if you're using [onchain permissioning](../../concepts/permissioning/onchain.md).
-
-:::tip
-
-If your node has two different IP addresses for ingress and egress (for example, if you use Kubernetes implementing a load balancer for ingress and a NAT gateway IP address for egress), add both addresses to the allowlist, using the same public key for each IP address. This will allow the node to connect.
-
-:::
-
-:::important
-
-Node allowlists [support domain names] in enode URLs as an early access feature. Use the `--Xdns-enabled` option to enable domain name support.
-
-If using Kubernetes, enable domain name support and use the `--Xdns-update-enabled` option to ensure that Besu can connect to a container after being restarted, even if the IP address of the container changes.
-
-:::
-
-:::tip
-
-If you add a running node, the node does not attempt to reconnect to the bootnode and synchronize until peer discovery restarts. To add an allowlisted node as a peer without waiting for peer discovery to restart, use [`admin_addPeer`](../../../public-networks/reference/api/index.md#admin_addpeer).
-
-If you add the node to the allowlist before starting the node, using `admin_addPeer` is not required because peer discovery is run on node startup.
-
-:::
-
-:::tip
-
-If nodes are not connecting as expected, set the [log level to `TRACE`](../../../public-networks/reference/cli/options.md#logging) and search for messages containing `Node permissioning` to identify the issue.
-
-Ensure the [`--p2p-host`](../../../public-networks/reference/cli/options.md#p2p-host) command line option has been correctly configured for all nodes with the externally accessible address.
-
-If you change your network configuration, you may need to update the node allowlist.
-
-:::
-
-## Specify the permissioning contract interface version
-
-Use the [`--permissions-nodes-contract-version`](../../reference/cli/options.md#permissions-nodes-contract-version) command line option to specify the version of the [permissioning contract interface](../../concepts/permissioning/onchain.md#permissioning-contracts). The default is 1.
-
-Specify the contract interface version that maps to the version of the [Enterprise Ethereum Alliance Client Specification](https://entethalliance.org/technical-specifications/) the contract interface implements.
-
-| | EEA Client Specification | Contract interface |
-| :------ | :----------------------- | :----------------- |
-| Version | 5 | 1 |
-| Version | 6 | 2 |
-
-The permissioning contracts in the [`ConsenSys/permissioning-smart-contracts`](https://github.com/ConsenSys/permissioning-smart-contracts) repository implement the version 2 contract interface.
-
-[support domain names]: ../../../public-networks/concepts/node-keys.md#domain-name-support
-[projects release page]: https://github.com/ConsenSys/permissioning-smart-contracts/releases/latest
-[onchain permissioning tutorial]: ../../tutorials/permissioning/onchain.md
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/_category_.json b/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/_category_.json
deleted file mode 100644
index f2a1d4ca864..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Use privacy",
- "position": 4
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/access-private-transactions.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/access-private-transactions.md
deleted file mode 100644
index 611f57269a3..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/access-private-transactions.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Access private and privacy marker transactions
-description: Methods for accessing and managing private transactions and privacy groups in Hyperledger Besu
-sidebar_position: 6
-tags:
- - private networks
----
-
-# Access private and privacy marker transactions
-
-A Hyperledger Besu private transaction creates a [privacy marker transaction](../../concepts/privacy/private-transactions/processing.md) and the private transaction itself.
-
-## Transaction receipts
-
-With the transaction hash returned when submitting the private transaction, to get the transaction receipt for the:
-
-- Private transaction, use [`priv_getTransactionReceipt`](../../reference/api/index.md#priv_gettransactionreceipt).
-- Privacy marker transaction, use [`eth_getTransactionReceipt`](../../../public-networks/reference/api/index.md#eth_gettransactionreceipt).
-
-The transaction receipt includes a `status` indicating if the transaction failed (`0x0`), succeeded (`0x1`), or was invalid (`0x2`).
-
-:::note Private transaction failure example
-
-To deploy a private contract, you submit a transaction using [`eea_sendRawTransaction`](../send-transactions/private-transactions.md). If contract deployment fails because of insufficient gas, the privacy marker transaction receipt has a status of success and the private transaction receipt has a status of failure.
-
-:::
-
-## Transactions
-
-With the transaction hash returned when submitting the private transaction, to get the:
-
-- Private transaction, use [`priv_getPrivateTransaction`](../../reference/api/index.md#priv_getprivatetransaction).
-- Privacy marker transaction, use [`eth_getTransactionByHash`](../../../public-networks/reference/api/index.md#eth_gettransactionbyhash).
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/besu-extended.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/besu-extended.md
deleted file mode 100644
index 40c1c7d365e..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/besu-extended.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: Use Besu-extended privacy
-description: Hyperledger Besu-extended privacy
-sidebar_position: 2
-tags:
- - private networks
----
-
-# Use Besu-extended privacy
-
-Hyperledger Besu provides an extended implementation of privacy allowing you to [create a privacy group for a set of participants](../../concepts/privacy/privacy-groups.md). You must specify the privacy group ID when sending private transactions.
-
-To enable the [`PRIV` API methods](../../reference/api/index.md#priv-methods), use the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../public-networks/reference/cli/options.md#rpc-ws-api) command line options.
-
-To create the privacy group containing the recipients of a private transaction, use [`priv_createPrivacyGroup`](../../reference/api/index.md#priv_createprivacygroup).
-
-To create an EEA-compliant private transaction, specify `privacyGroupId` when creating the signed transaction passed as an input parameter to [`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction).
-
-## Privacy group type
-
-Privacy groups created using [`priv_createPrivacyGroup`](../../reference/api/index.md#priv_createprivacygroup) have a `BESU` privacy group type when returned by [`priv_findPrivacyGroup`](../../reference/api/index.md#priv_findprivacygroup).
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- {
- "privacyGroupId": "GpK3ErNO0xF27T0sevgkJ3+4qk9Z+E3HtXYxcKIBKX8=",
- "name": "Group B",
- "description": "Description of Group B",
- "type": "BESU",
- "members": [
- "negmDcN2P4ODpqn/6WkJ02zT/0w0bjhGpkZ8UP6vARk=",
- "g59BmTeJIn7HIcnq8VQWgyh/pDbvbt2eyP0Ii60aDDw="
- ]
- }
- ]
-}
-```
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/eea-compliant.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/eea-compliant.md
deleted file mode 100644
index 300c0b987fd..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/eea-compliant.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: Use EEA-compliant privacy
-description: Hyperledger Besu JSON-RPC methods to use for EEA-compliant privacy
-sidebar_position: 1
-tags:
- - private networks
----
-
-# Use EEA-compliant privacy
-
-When using Hyperledger Besu [EEA-compliant privacy](../../concepts/privacy/privacy-groups.md), the group of nodes specified by `privateFrom` and `privateFor` form a privacy group, to which Tessera assigns a unique privacy group ID.
-
-To enable the [`EEA` API methods](../../reference/api/index.md#eea-methods), use the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../public-networks/reference/cli/options.md#rpc-ws-api) command line options.
-
-To create an EEA-compliant private transaction, specify `privateFor` when creating the signed transaction passed as an input parameter to [`eea_sendRawTransaction`](../../reference/api/index.md#eea_sendrawtransaction).
-
-## Privacy group type
-
-Privacy groups created when specifying `privateFrom` and `privateFor` have a `LEGACY` privacy group type when returned by [`priv_findPrivacyGroup`](../../reference/api/index.md#priv_findprivacygroup).
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- {
- "privacyGroupId": "68/Cq0mVjB8FbXDLE1tbDRAvD/srluIok137uFOaClM=",
- "name": "legacy",
- "description": "Privacy groups to support the creation of groups by privateFor and privateFrom",
- "type": "LEGACY",
- "members": [
- "g59BmTeJIn7HIcnq8VQWgyh/pDbvbt2eyP0Ii60aDDw=",
- "negmDcN2P4ODpqn/6WkJ02zT/0w0bjhGpkZ8UP6vARk="
- ]
- }
- ]
-}
-```
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/flexible.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/flexible.md
deleted file mode 100644
index abf1892732b..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/flexible.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Use flexible privacy groups
-description: Use flexible privacy groups
-sidebar_position: 5
-tags:
- - private networks
----
-
-# Use flexible privacy groups
-
-Use the [`web3js-quorum` library](https://github.com/ConsenSys/web3js-quorum) to create and update membership of [flexible privacy groups](../../concepts/privacy/flexible-privacy.md).
-
-:::tip
-
-Because group membership for flexible privacy groups is stored in a smart contract, flexible privacy groups are also known as onchain privacy groups.
-
-:::
-
-:::info
-
-[Flexible privacy groups](../../concepts/privacy/flexible-privacy.md) are an early access feature. Don't use in production networks.
-
-The flexible privacy group interfaces may change between releases. There might not be an upgrade path from flexible privacy groups created using v1.5 or earlier to enable use of flexible privacy group functionality in future versions.
-
-We don't recommend creating flexible privacy groups in a chain with existing [offchain privacy groups](../../concepts/privacy/privacy-groups.md).
-
-:::
-
-## Enable flexible privacy groups
-
-Use the [`--privacy-flexible-groups-enabled`](../../reference/cli/options.md#privacy-flexible-groups-enabled) command line option to enable [flexible privacy groups](../../concepts/privacy/flexible-privacy.md). When flexible privacy groups are enabled, the [`priv_createPrivacyGroup`](../../reference/api/index.md#priv_createprivacygroup), [`priv_deletePrivacyGroup`](../../reference/api/index.md#priv_deleteprivacygroup), and [`priv_findPrivacyGroup`](../../reference/api/index.md#priv_findprivacygroup) methods for [offchain privacy groups](../../concepts/privacy/privacy-groups.md) are disabled.
-
-## Simple flexible privacy group example
-
-To create and find a [flexible privacy group](../../concepts/privacy/flexible-privacy.md) using the [`web3js-quorum` library](https://github.com/ConsenSys/web3js-quorum):
-
-1. Update the `example/keys.js` file to match your network configuration.
-
-1. Run:
-
- ```bash
- cd example/onchainPrivacy
- node simpleExample.js
- ```
-
- This script creates the flexible privacy group with two members. `findPrivacyGroup` finds and displays the created privacy group.
-
-:::tip
-
-The Tessera logs for Tessera 1 and Tessera 2 display `PrivacyGroupNotFound` errors. This is expected behavior because private transactions check offchain and onchain to find the privacy group for a private transaction.
-
-:::
-
-## Add and remove members
-
-To add and remove members from a [flexible privacy group](../../concepts/privacy/flexible-privacy.md), use the `addTo` and `removeFrom` methods in the [`web3js-quorum` library](https://github.com/ConsenSys/web3js-quorum) client library.
-
-:::note
-
-When adding a member, Besu pushes all existing group transactions to the new member and processes them. If there are a large number of existing transactions, adding the member may take some time.
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/performance-best-practices.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/performance-best-practices.md
deleted file mode 100644
index 5559d610189..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/performance-best-practices.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Performance best practices
-description: Performance best practices
-sidebar_position: 10
-tags:
- - private networks
----
-
-# Performance best practices
-
-This document collects deployment and usage tips to help you achieve high performance for private transactions. If transaction throughput or latency is not meeting your expectations, please consider the following before raising an issue.
-
-## General performance
-
-Private transactions use the same facilities as public ones. General Besu performance tunings apply. Specific approaches are out of scope of this document, except for the following, which strongly impacts performance:
-
-### Use fast, local, solid state storage
-
-Running EVM transactions creates a lot of random reads that are executed sequentially. The Besu data folder for high throughput nodes should be located on the fastest possible storage media.
-
-- Prefer [NVMe](https://cloud.google.com/compute/docs/disks/local-ssd#performance) attached SLC flash or Intel Optane.
-- Avoid network attached SSDs or cloud storage with limited input/output operations per second.
-- Do not use spinning disks under any circumstances.
-
-## Private transaction performance
-
-### Use concurrent submission
-
-When submitting a private transaction using [web3js-quorum](https://github.com/ConsenSys/web3js-quorum), the submit call will only return once the privacy marker transaction has been included in a block. This limits the throughput to at most one private transaction per block when submitting from a single thread. To increase throughput, use web3js-quorum from multiple concurrent threads or processes.
-
-### Co-locate Besu and Tessera
-
-Besu has to talk to its local Tessera node frequently while handling a block. While we do not recommend running them on the same node, minimizing the latency between Besu and Tessera will improve block processing times. Besu and Tessera should not be hosted in geographically distributed locations.
-
-### Optimize worst-case latency between Tessera nodes
-
-When distributing a new private transaction between Tessera nodes, the overall throughput is determined by the slowest Tessera nodes. Try to minimize network latency between Tessera nodes and do not mix different machine types when hosting Tessera.
-
-### Use stateful nonce management
-
-Management of public and private nonces in web3js-quorum is stateless: before a transaction is sent, web3js-quorum has to query for those nonces. This is increasing latency, the node's load, and is a source of fragility due to nonce collision when multiple senders try to use the same account concurrently.
-
-For performance and reliability it is advantageous to manage nonces in a stateful manner on the client side instead of querying them for every transaction. If custom code for this is not an option, [Orchestrate](https://consensys.net/codefi/orchestrate/) can be used.
-
-### Use random senders for privacy marker transactions
-
-To avoid public nonce management, privacy marker transactions can be sent using a [random account per transaction](https://besu.hyperledger.org/en/stable/Reference/CLI/CLI-Syntax/#privacy-marker-transaction-signing-key-file). This option is only available for zero gas networks.
-
-### Avoid queuing transactions in Tessera
-
-When Tessera is overloaded with transactions, the performance breaks down catastrophically due to unbounded growth of the request queue. Avoid sending more transactions to Tessera than it can handle. Sudden jumps in submission latency and submission failure rate should be answered with a load reduction on the client side, for example using a back-off scheme.
-
-Please note that this is not Tessera specific but a general issue in distributed systems. It just happens that if queueing discipline is not maintained, Tessera tends to be the first component to fail.
-
-### Limit the group size to reduce communication overhead
-
-Smaller groups need fewer communication for transaction propagation. If reducing the number of Tessera nodes involved in a transaction is an option, it will lead to slightly better tail latencies. Multi-tenancy Tessera can be used to have large groups with a small number of Tessera nodes (possibly only one).
-
-### Limit group membership changes and make them quick
-
-Groups are locked (prevented from executing transactions) during membership changes. Try to minimize the number of times the membership changes. When possible, spread load across multiple groups to always have some groups available while others are locked. Consider batching group membership changes if possible. Note however that this does not work with the default management contract, yet.
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/privacy-groups.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/privacy-groups.md
deleted file mode 100644
index 1b3f0fadf23..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/privacy-groups.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Create and manage privacy groups
-description: Create and manage privacy groups with Hyperledger Besu
-sidebar_position: 4
-tags:
- - private networks
----
-
-# Create and manage privacy groups
-
-Hyperledger Besu-extended privacy provides JSON-RPC API methods for creating and managing privacy groups:
-
-- [`priv_createPrivacyGroup`](../../reference/api/index.md#priv_createprivacygroup)
-- [`priv_findPrivacyGroup`](../../reference/api/index.md#priv_findprivacygroup)
-- [`priv_deletePrivacyGroup`](../../reference/api/index.md#priv_deleteprivacygroup).
-
-:::tip
-
-You can find and delete [EEA-compliant privacy groups](../../concepts/privacy/privacy-groups.md) using [`priv_findPrivacyGroup`](../../reference/api/index.md#priv_findprivacygroup) and [`priv_deletePrivacyGroup`](../../reference/api/index.md#priv_deleteprivacygroup).
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/sign-pmts.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/sign-pmts.md
deleted file mode 100644
index 7ad0029f5d1..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/sign-pmts.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: Sign privacy marker transactions
-description: How to sign a privacy marker transaction with Hyperledger Besu
-sidebar_position: 7
-tags:
- - private networks
----
-
-# Sign privacy marker transactions
-
-You can sign privacy marker transactions (PMTs) with either a random key or a specified key. To sign privacy marker transactions with a specified private key, use [`--privacy-marker-transaction-signing-key-file`](../../reference/cli/options.md#privacy-marker-transaction-signing-key-file) when starting Hyperledger Besu.
-
-:::note
-
-The private key file can be the same file used by [`--node-private-key-file`](#node-private-key-file), or a different key file to identify who signed the privacy marker transaction.
-
-:::
-
-In networks where you pay gas, you must specify a key and the associated account must contain adequate funds.
-
-In [free gas networks](../configure/free-gas.md), to provide further anonymity by signing each privacy marker transaction with a different random key, exclude the [`--privacy-marker-transaction-signing-key-file`](../../reference/cli/options.md#privacy-marker-transaction-signing-key-file) command line option when starting Besu.
-
-:::caution "Using account permissioning and privacy"
-
-You can't use [account permissioning] with random key signing.
-
-If using account permissioning and privacy, a signing key must be specified using the [`--privacy-marker-transaction-signing-key-file`](../../reference/cli/options.md#privacy-marker-transaction-signing-key-file) command line option and the corresponding public key included in the accounts allowlist.
-
-:::
-
-:::note
-
-Besu signs privacy marker transactions during the [private transaction process](../../concepts/privacy/private-transactions/processing.md).
-
-:::
-
-
-
-[account permissioning]: ../../concepts/permissioning/index.md#account-permissioning
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/tessera.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/tessera.md
deleted file mode 100644
index 02754f3fe8f..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/tessera.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Run Tessera with Besu
-description: Running ConsenSys Quorum Tessera with Hyperledger Besu
-sidebar_position: 3
-tags:
- - private networks
----
-
-# Run Tessera with Besu
-
-To enable [privacy functionality](../../concepts/privacy/index.md) in production systems, [Tessera](https://docs.tessera.consensys.net/) must be [highly available](#high-availability) and [run in a separate instance](#separate-instances) to Hyperledger Besu.
-
-![Besu-Tessera-High-Availability](../../../assets/images/Besu-Tessera-High-Availability.png)
-
-:::note
-
-You can also configure Besu for high availability using load balancers.
-
-:::
-
-## High availability
-
-Privacy requires you to [configure Tessera for high availability]. Besu also requires [`orion` mode](https://docs.tessera.consensys.net/HowTo/Configure/Orion-Mode) to be enabled in Tessera.
-
-To successfully distribute a private transaction, all private transaction participants must be online. If any participants are offline when submitting the private transaction, the transaction is not attempted and you need to resubmit the transaction.
-
-If a Tessera node is unavailable when Besu attempts to process a privacy marker transaction, the Besu node stops processing all new blocks until Tessera is available. The Besu node continually attempts to process the privacy marker transaction until Tessera is available again.
-
-:::caution
-
-If Tessera becomes available but has lost data, Besu resumes processing blocks and the private states in the Besu nodes might become inconsistent.
-
-:::
-
-## Separate instances
-
-For production systems, we recommend running Besu and Tessera in separate instances. If running Besu and Tessera in the same instance, restrict the amount of memory used by each JVM to ensure each has enough memory.
-
-
-
-[configure Tessera for high availability]: https://consensys.net/docs/goquorum//en/stable/configure-and-manage/configure/high-availability/
diff --git a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/web3js-quorum.md b/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/web3js-quorum.md
deleted file mode 100644
index 5538b3f9bc9..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/how-to/use-privacy/web3js-quorum.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: Use the web3js-quorum library
-description: web3js-quorum client library
-sidebar_position: 9
-tags:
- - private networks
----
-
-# Use the web3js-quorum client library
-
-[web3js-quorum](https://github.com/ConsenSys/web3js-quorum) is an Ethereum JavaScript library extending [web3.js](https://github.com/ethereum/web3.js/) that adds support for Besu-specific JSON-RPC APIs and features. Use the library to create and send RLP-encoded transactions using JSON-RPC.
-
-:::caution important
-web3js-quorum supports JSON-RPC over HTTP only.
-:::
-
-:::note
-
-web3js-quorum includes all [quorum.js](https://github.com/ConsenSys/quorum.js) and [web3js-eea](https://github.com/ConsenSys/web3js-eea) features.
-
-If migrating to web3js-quorum, update your JavaScript code as indicated in the following examples.
-
-[Read the migration guide for more information about updating your code.](https://consensys.github.io/web3js-quorum/latest/tutorial-Migrate%20from%20web3js-eea.html)
-
-:::
-
-## Prerequisites
-
-- [Node.js (version > 10)](https://nodejs.org/en/download/)
-- [The web3 library must be installed in your project](https://github.com/ChainSafe/web3.js#installation)
-
-## Add web3js-quorum to project
-
-```bash
-npm install web3js-quorum
-```
-
-## Initialize the web3js-quorum client
-
-Initialize your client where:
-
-- `` is the JSON-RPC HTTP endpoint of your Hyperledger Besu node. Specified by the [`--rpc-http-host`](../../../public-networks/reference/cli/options.md#rpc-http-host) and [`--rpc-http-port`](../../../public-networks/reference/cli/options.md#rpc-http-port) command line options.
-
-
-
-# Syntax
-
-```js
-const { Web3 } = require("web3");
-const Web3Quorum = require("web3js-quorum");
-const web3 = new Web3Quorum(new Web3(""));
-```
-
-# Example
-
-```js
-const { Web3 } = require("web3");
-const Web3Quorum = require("web3js-quorum");
-const web3 = new Web3Quorum(new Web3("http://localhost:8545"));
-```
-
-
-
-:::note
-
-When migrating from web3js-eea to web3js-quorum, use `Web3Quorum`. The constructor doesn't require the chain ID anymore. Chain ID is automatically retrieved from the chain using the specified JSON-RPC HTTP endpoint.
-
-:::
-
-## Deploy a contract with `generateAndSendRawTransaction`
-
-To deploy a private contract, you need the contract binary. You can use [Solidity](https://solidity.readthedocs.io/en/develop/using-the-compiler.html) to get the contract binary.
-
-```js title="Deploying a contract with 'web3.priv.generateAndSendRawTransaction'"
-const contractOptions = {
- data: `0x123`, // contract binary
- privateFrom: "tesseraNode1PublicKey",
- privateFor: ["tesseraNode3PublicKey"],
- privateKey: "besuNode1PrivateKey",
-};
-return web3.priv.generateAndSendRawTransaction(contractOptions);
-```
-
-`web3.priv.generateAndSendRawTransaction(contractOptions)` returns the transaction hash. To get the private transaction receipt, use `web3.priv.waitForTransactionReceipt(txHash)`.
-
-## web3js-quorum methods
-
-For more information about the web3js-quorum methods, see the [web3js-quorum reference documentation](https://consensys.github.io/web3js-quorum/latest/index.html).
diff --git a/versioned_docs/version-23.10.0/private-networks/index.md b/versioned_docs/version-23.10.0/private-networks/index.md
deleted file mode 100644
index 377c1af8e90..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/index.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Private networks
-sidebar_position: 1
-sidebar_label: Introduction
-id: index
-description: Private networks overview
-tags:
- - private networks
----
-
-# Hyperledger Besu for private networks
-
-You can use Besu to develop enterprise applications requiring secure, high-performance transaction processing in a private network.
-
-A private network is a network not connected to Ethereum Mainnet or an Ethereum testnet. Private networks typically use a different [chain ID](../public-networks/concepts/network-and-chain-id.md) and proof of authority consensus ([QBFT](how-to/configure/consensus/qbft.md), [IBFT 2.0](how-to/configure/consensus/ibft.md), or [Clique](how-to/configure/consensus/clique.md)).
-
-You can also [create a local development network](tutorials/ethash.md) using proof of work (Ethash).
-
-Besu supports enterprise features including [privacy](concepts/privacy/index.md) and [permissioning](concepts/permissioning/index.md).
-
-Get started with the [Developer Quickstart](tutorials/quickstart.md) to rapidly generate local blockchain networks.
-
-## Architecture
-
-The following diagram outlines the high-level architecture of Besu for private networks.
-
-![Private architecture](../assets/images/private-architecture.jpeg)
-
-If you have any questions about Besu for private networks, ask on the **besu** channel on
-[Hyperledger Discord](https://discord.gg/hyperledger).
diff --git a/versioned_docs/version-23.10.0/private-networks/reference/_category_.json b/versioned_docs/version-23.10.0/private-networks/reference/_category_.json
deleted file mode 100644
index 3ce2f2b757b..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/reference/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Reference",
- "position": 6
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/reference/accounts-for-testing.md b/versioned_docs/version-23.10.0/private-networks/reference/accounts-for-testing.md
deleted file mode 100644
index f32a1dbf8a1..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/reference/accounts-for-testing.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Accounts for testing
-sidebar_position: 3
-description: Ethereum accounts used for Hyperledger Besu testing only on private networks
-tags:
- - private networks
----
-
-import TestAccounts from '../../global/test_accounts.md';
-
-# Accounts for testing
-
-You can use existing accounts for testing by including them in the genesis file for a private network. Hyperledger Besu also provides predefined accounts for use in development mode.
-
-## Development mode
-
-When you start Besu with the [`--network=dev`](../../public-networks/reference/cli/options.md#network) command line option, Besu uses the `dev.json` genesis file by default.
-
-The `dev.json` genesis file defines the following accounts used for testing.
-
-
-
-## Genesis file
-
-To use existing test accounts, specify the accounts and balances in a genesis file for your test network. For an example of how to define accounts in the genesis file, see [`dev.json`](https://github.com/hyperledger/besu/blob/750580dcca349d22d024cc14a8171b2fa74b505a/config/src/main/resources/dev.json).
-
-To start Besu with the genesis file defining the existing accounts, use the [`--genesis-file`](../../public-networks/reference/cli/options.md#genesis-file) command line option .
diff --git a/versioned_docs/version-23.10.0/private-networks/reference/api/_category_.json b/versioned_docs/version-23.10.0/private-networks/reference/api/_category_.json
deleted file mode 100644
index 777d7bb818f..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/reference/api/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Besu API",
- "position": 2
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/reference/api/index.md b/versioned_docs/version-23.10.0/private-networks/reference/api/index.md
deleted file mode 100644
index 7ff104b9338..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/reference/api/index.md
+++ /dev/null
@@ -1,2157 +0,0 @@
----
-description: Hyperledger Besu private network JSON-RPC API methods reference
-tags:
- - private networks
----
-
-# Private network API methods
-
-:::warning
-
-- This reference contains API methods that apply to only private networks. For API methods that apply to both private and public networks, see the [public network API reference](../../../public-networks/reference/api/index.md).
-- All JSON-RPC HTTP examples use the default host and port endpoint `http://127.0.0.1:8545`. If using the [--rpc-http-host](../../../public-networks/reference/cli/options.md#rpc-http-host) or [--rpc-http-port](../../../public-networks/reference/cli/options.md#rpc-http-port) options, update the endpoint.
-
-:::
-
-## `CLIQUE` methods
-
-The `CLIQUE` API methods provide access to the [Clique](../../how-to/configure/consensus/clique.md) consensus engine.
-
-:::note
-
-The `CLIQUE` API methods are not enabled by default for JSON-RPC. To enable the `CLIQUE` API methods use the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../public-networks/reference/cli/options.md#rpc-ws-api) options.
-
-:::
-
-### `clique_discard`
-
-Discards a proposal to [add or remove a signer with the specified address].
-
-#### Parameters
-
-`address`: _string_ - 20-byte address of proposed signer
-
-#### Returns
-
-`result`: _boolean_ - indicates if the proposal is discarded
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"clique_discard","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"clique_discard","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": true
-}
-```
-
-
-
-### `clique_getSigners`
-
-Lists [signers for the specified block].
-
-#### Parameters
-
-`blockNumber`: _string_ - hexadecimal or decimal integer representing a block number or one of the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-#### Returns
-
-`result`: _array_ of _string_ - list of 20-byte addresses of signers
-
-
-
-# curl HTTP request
-
- ```bash
- curl -X POST --data '{"jsonrpc":"2.0","method":"clique_getSigners","params":["latest"], "id":1}' http://127.0.0.1:8545
- ```
-
-# wscat WS request
-
- ```bash
- {"jsonrpc":"2.0","method":"clique_getSigners","params":["latest"], "id":1}
- ```
-
-# JSON result
-
- ```json
- {
- "jsonrpc" : "2.0",
- "id" : 1,
- "result" : [ "0x42eb768f2244c8811c63729a21a3569731535f06", "0x7ffc57839b00206d1ad20c69a1981b489f772031", "0xb279182d99e65703f0076e4812653aab85fca0f0" ]
- }
- ```
-
-
-
-### `clique_getSignerMetrics`
-
-Provides the following validator metrics for the specified range:
-
-- Number of blocks from each validator
-
-- Block number of the last block proposed by each validator (if any proposed in the specified range)
-
-- All validators present in the last block
-
-#### Parameters
-
-- `fromBlockNumber`: _string_ - hexadecimal or decimal integer representing a block number or the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-- `toBlockNumber`: _string_ - hexadecimal or decimal integer representing a block number or one of the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-If you specify:
-
-- No parameters, the call provides metrics for the last 100 blocks, or all blocks if there are less than 100 blocks.
-
-- Only the first parameter, the call provides metrics for all blocks from the block specified to the latest block.
-
-#### Returns
-
-`result`: _array_ of _objects_ - list of validator objects
-
-:::note
-
-The proposer of the genesis block has address `0x0000000000000000000000000000000000000000`.
-
-:::
-
-
-
-# curl HTTP
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"clique_getSignerMetrics","params":["1", "100"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS
-
-```bash
-{"jsonrpc":"2.0","method":"clique_getSignerMetrics","params":["1", "100"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- {
- "address": "0x7ffc57839b00206d1ad20c69a1981b489f772031",
- "proposedBlockCount": "0x21",
- "lastProposedBlockNumber": "0x61"
- },
- {
- "address": "0x42eb768f2244c8811c63729a21a3569731535f06",
- "proposedBlockCount": "0x21",
- "lastProposedBlockNumber": "0x63"
- },
- {
- "address": "0xb279182d99e65703f0076e4812653aab85fca0f0",
- "proposedBlockCount": "0x21",
- "lastProposedBlockNumber": "0x62"
- }
- ]
-}
-```
-
-
-
-### `clique_getSignersAtHash`
-
-Lists signers for the specified block.
-
-#### Parameters
-
-`hash`: _string_ - 32-byte block hash
-
-#### Returns
-
-`result`: _array_ of _string_ - list of 20-byte addresses of signers
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"clique_getSignersAtHash","params":["0x98b2ddb5106b03649d2d337d42154702796438b3c74fd25a5782940e84237a48"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"clique_getSignersAtHash","params":["0x98b2ddb5106b03649d2d337d42154702796438b3c74fd25a5782940e84237a48"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- "0x42eb768f2244c8811c63729a21a3569731535f06",
- "0x7ffc57839b00206d1ad20c69a1981b489f772031",
- "0xb279182d99e65703f0076e4812653aab85fca0f0"
- ]
-}
-```
-
-
-
-### `clique_proposals`
-
-Returns [current proposals](../../how-to/configure/consensus/clique.md#add-and-remove-signers).
-
-#### Parameters
-
-None
-
-#### Returns
-
-`result`: _map_ of _strings_ to _booleans_ - map of account addresses to corresponding boolean values indicating the proposal for each account (if `true`, the proposal is to add a signer; if `false`, the proposal is to remove a signer.)
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"clique_proposals","params":[], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"clique_proposals","params":[], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "0x42eb768f2244c8811c63729a21a3569731535f07": false,
- "0x12eb759f2222d7711c63729a45c3585731521d01": true
- }
-}
-```
-
-
-
-### `clique_propose`
-
-Proposes to [add or remove a signer with the specified address].
-
-#### Parameters
-
-- `address`: _string_ - 20-byte address
-
-- `proposal`: _boolean_ - `true` to propose adding signer or `false` to propose removing signer
-
-#### Returns
-
-`result`: _boolean_ - `true`
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"clique_propose","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73", true], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"clique_propose","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73", true], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": true
-}
-```
-
-
-
-## `EEA` methods
-
-The `EEA` API methods provide functionality for [private transactions](../../concepts/privacy/private-transactions/index.md) and [privacy groups](../../concepts/privacy/privacy-groups.md).
-
-:::note
-
-The `EEA` API methods are not enabled by default for JSON-RPC. To enable the `EEA` API methods, use the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../public-networks/reference/cli/options.md#rpc-ws-api) options.
-
-:::
-
-### `eea_sendRawTransaction`
-
-Distributes the [private transaction](../../how-to/send-transactions/private-transactions.md), generates the [privacy marker transaction](../../concepts/privacy/private-transactions/processing.md) and submits it to the transaction pool, and returns the transaction hash of the [privacy marker transaction](../../concepts/privacy/private-transactions/processing.md).
-
-The signed transaction passed as an input parameter includes the `privateFrom`, [`privateFor` or `privacyGroupId`](../../how-to/send-transactions/private-transactions.md#eea-compliant-or-besu-extended-privacy), and `restriction` fields.
-
-The `gas` and `gasPrice` are used by the [privacy marker transaction](../../concepts/privacy/private-transactions/processing.md) not the private transaction itself.
-
-To avoid exposing your private key, create signed transactions offline and send the signed transaction data using `eea_sendRawTransaction`.
-
-:::important
-
-For production systems requiring private transactions, use a network with a consensus mechanism supporting transaction finality to make sure the private state does not become inconsistent with the chain. For example, [IBFT 2.0](../../how-to/configure/consensus/ibft.md) and [QBFT](../../how-to/configure/consensus/qbft.md) provide the required finality.
-
-Using private transactions with [pruning](../../../public-networks/concepts/data-storage-formats.md#pruning) or [fast sync](../../../public-networks/reference/cli/options.md#sync-mode) isn't supported.
-
-Besu doesn't implement [`eea_sendTransaction`](../../how-to/send-transactions/private-transactions.md).
-
-[EthSigner](https://docs.ethsigner.consensys.net/en/latest/) provides transaction signing and implements [`eea_sendTransaction`](https://docs.ethsigner.consensys.net/Reference/API-Methods#eea_sendtransaction).
-
-:::
-
-#### Parameters
-
-`transaction`: _string_ - signed RLP-encoded private transaction
-
-#### Returns
-
-`result`: _string_ - 32-byte transaction hash of the [privacy marker transaction](../../concepts/privacy/private-transactions/processing.md)
-
-:::tip
-
-If creating a contract, use [priv_getTransactionReceipt](#priv_gettransactionreceipt) to retrieve the contract address after the transaction is finalized.
-
-:::
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"eea_sendRawTransaction","params": ["0xf869018203e882520894f17f52151ebef6c7334fad080c5704d77216b732881bc16d674ec80000801ba02da1c48b670996dcb1f447ef9ef00b33033c48a4fe938f420bec3e56bfd24071a062e0aa78a81bf0290afbc3a9d8e9a068e6d74caa66c5e0fa8a46deaae96b0833"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"eea_sendRawTransaction","params": ["0xf869018203e882520894f17f52151ebef6c7334fad080c5704d77216b732881bc16d674ec80000801ba02da1c48b670996dcb1f447ef9ef00b33033c48a4fe938f420bec3e56bfd24071a062e0aa78a81bf0290afbc3a9d8e9a068e6d74caa66c5e0fa8a46deaae96b0833"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "id": 1,
- "jsonrpc": "2.0",
- "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
-}
-```
-
-
-
-## `IBFT` 2.0 methods
-
-The `IBFT` API methods provide access to the [IBFT 2.0](../../how-to/configure/consensus/ibft.md) consensus engine.
-
-:::note
-
-The `IBFT` API methods are not enabled by default for JSON-RPC. To enable the `IBFT` API methods, use the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../public-networks/reference/cli/options.md#rpc-ws-api) options.
-
-:::
-
-### `ibft_discardValidatorVote`
-
-Discards a proposal to [add or remove a validator] with the specified address.
-
-#### Parameters
-
-`address`: _string_ - 20-byte address of proposed validator
-
-#### Returns
-
-`result`: _boolean_ - indicates if the proposal is discarded
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_discardValidatorVote","params":["0xef1bfb6a12794615c9b0b5a21e6741f01e570185"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"ibft_discardValidatorVote","params":["0xef1bfb6a12794615c9b0b5a21e6741f01e570185"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": true
-}
-```
-
-
-
-### `ibft_getPendingVotes`
-
-Returns [votes](../../how-to/configure/consensus/ibft.md#add-and-remove-validators) cast in the current [epoch](../../how-to/configure/consensus/ibft.md#genesis-file).
-
-#### Parameters
-
-None
-
-#### Returns
-
-`result`: _map_ of _strings_ to _booleans_ - map of account addresses to corresponding boolean values indicating the vote for each account; if `true`, the vote is to add a validator. If `false`, the proposal is to remove a validator.
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_getPendingVotes","params":[], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"ibft_getPendingVotes","params":[], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "0xef1bfb6a12794615c9b0b5a21e6741f01e570185": true,
- "0x42d4287eac8078828cf5f3486cfe601a275a49a5": true
- }
-}
-```
-
-
-
-### `ibft_getSignerMetrics`
-
-Provides the following validator metrics for the specified range:
-
-- Number of blocks from each validator
-
-- Block number of the last block proposed by each validator (if any proposed in the specified range)
-
-- All validators present in the last block of the range
-
-#### Parameters
-
-- `fromBlockNumber`: _string_ - hexadecimal or decimal integer representing a block number or the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-- `toBlockNumber`: _string_ - hexadecimal or decimal integer representing a block number or one of the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-If you specify:
-
-- No parameters, the call provides metrics for the last 100 blocks, or all blocks if there are less than 100 blocks.
-
-- Only the first parameter, the call provides metrics for all blocks from the block specified to the latest block.
-
-#### Returns
-
-`result`: _array_ of _objects_ - list of validator objects
-
-:::note
-
-The proposer of the genesis block has address `0x0000000000000000000000000000000000000000`.
-
-:::
-
-
-
-# curl HTTP
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_getSignerMetrics","params":["1", "100"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS
-
-```bash
-{"jsonrpc":"2.0","method":"ibft_getSignerMetrics","params":["1", "100"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- {
- "address": "0x7ffc57839b00206d1ad20c69a1981b489f772031",
- "proposedBlockCount": "0x21",
- "lastProposedBlockNumber": "0x61"
- },
- {
- "address": "0x42eb768f2244c8811c63729a21a3569731535f06",
- "proposedBlockCount": "0x21",
- "lastProposedBlockNumber": "0x63"
- },
- {
- "address": "0xb279182d99e65703f0076e4812653aab85fca0f0",
- "proposedBlockCount": "0x21",
- "lastProposedBlockNumber": "0x62"
- }
- ]
-}
-```
-
-
-
-### `ibft_getValidatorsByBlockHash`
-
-Lists the validators defined in the specified block.
-
-#### Parameters
-
-`block`: _string_ - 32-byte block hash
-
-#### Returns
-
-`result`: _array_ of _strings_ - list of validator addresses
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_getValidatorsByBlockHash","params":["0xbae7d3feafd743343b9a4c578cab5e5d65eb735f6855fb845c00cab356331256"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"ibft_getValidatorsByBlockHash","params":["0xbae7d3feafd743343b9a4c578cab5e5d65eb735f6855fb845c00cab356331256"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- "0x42d4287eac8078828cf5f3486cfe601a275a49a5",
- "0xb1b2bc9582d2901afdc579f528a35ca41403fa85",
- "0xef1bfb6a12794615c9b0b5a21e6741f01e570185"
- ]
-}
-```
-
-
-
-### `ibft_getValidatorsByBlockNumber`
-
-Lists the validators defined in the specified block.
-
-#### Parameters
-
-- `blockNumber`: _string_ - hexadecimal or decimal integer representing a block number or one of the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-#### Returns
-
-`result`: _array_ of _strings_ - list of validator addresses
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_getValidatorsByBlockNumber","params":["latest"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"ibft_getValidatorsByBlockNumber","params":["latest"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- "0x42d4287eac8078828cf5f3486cfe601a275a49a5",
- "0xb1b2bc9582d2901afdc579f528a35ca41403fa85",
- "0xef1bfb6a12794615c9b0b5a21e6741f01e570185"
- ]
-}
-```
-
-
-
-### `ibft_proposeValidatorVote`
-
-Proposes to [add or remove a validator] with the specified address.
-
-#### Parameters
-
-- `address`: _string_ - account address
-
-- `proposal`: _boolean_ - `true` to propose adding validator or `false` to propose removing validator
-
-#### Returns
-
-`result`: _boolean_ - `true`
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_proposeValidatorVote","params":["42d4287eac8078828cf5f3486cfe601a275a49a5",true], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"ibft_proposeValidatorVote","params":["42d4287eac8078828cf5f3486cfe601a275a49a5",true], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": true
-}
-```
-
-
-
-## `PERM` (Permissioning) methods
-
-The `PERM` API methods provide permissioning functionality. Use these methods for [local permissioning](../../how-to/use-permissioning/local.md) only.
-
-:::important
-
-The `PERM` API methods are not enabled by default for JSON-RPC. To enable the `PERM` API methods, use the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../public-networks/reference/cli/options.md#rpc-ws-api) CLI options.
-
-:::
-
-### `perm_addAccountsToAllowlist`
-
-Adds accounts (participants) to the [accounts permission list](../../how-to/use-permissioning/local.md#account-permissioning).
-
-#### Parameters
-
-`addresses`: _array_ of _strings_ - list of account addresses
-
-:::note
-
-The parameters list contains a list which is why the account addresses are enclosed by double square brackets.
-
-:::
-
-#### Returns
-
-`result`: _string_ - `Success` or `error` (errors include attempting to add accounts already on the allowlist and including invalid account addresses.)
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_addAccountsToAllowlist","params":[["0xb9b81ee349c3807e46bc71aa2632203c5b462032", "0xb9b81ee349c3807e46bc71aa2632203c5b462034"]], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"perm_addAccountsToAllowlist","params":[["0xb9b81ee349c3807e46bc71aa2632203c5b462032", "0xb9b81ee349c3807e46bc71aa2632203c5b462034"]], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "Success"
-}
-```
-
-
-
-### `perm_addNodesToAllowlist`
-
-Adds nodes to the [nodes allowlist](../../how-to/use-permissioning/local.md#node-allowlisting).
-
-To use domain names in enode URLs, ensure you [enable DNS support](../../../public-networks/concepts/node-keys.md#domain-name-support) to avoid receiving a `request contains an invalid node` error.
-
-:::warning
-
-Enode URL domain name support is an early access feature.
-
-:::
-
-#### Parameters
-
-`enodes`: _array_ of _strings_ - list of [enode URLs](../../../public-networks/concepts/node-keys.md#enode-url)
-
-:::note
-
-The parameters list contains a list which is why the enode URLs are enclosed by double square brackets.
-
-:::
-
-#### Returns
-
-`result`: _string_ - `Success` or `error`; errors include attempting to add nodes already on the allowlist or including invalid enode URLs.
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_addNodesToAllowlist","params":[["enode://7e4ef30e9ec683f26ad76ffca5b5148fa7a6575f4cfad4eb0f52f9c3d8335f4a9b6f9e66fcc73ef95ed7a2a52784d4f372e7750ac8ae0b544309a5b391a23dd7@127.0.0.1:30303","enode://2feb33b3c6c4a8f77d84a5ce44954e83e5f163e7a65f7f7a7fec499ceb0ddd76a46ef635408c513d64c076470eac86b7f2c8ae4fcd112cb28ce82c0d64ec2c94@127.0.0.1:30304"]], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"perm_addNodesToAllowlist","params":[["enode://7e4ef30e9ec683f26ad76ffca5b5148fa7a6575f4cfad4eb0f52f9c3d8335f4a9b6f9e66fcc73ef95ed7a2a52784d4f372e7750ac8ae0b544309a5b391a23dd7@127.0.0.1:30303","enode://2feb33b3c6c4a8f77d84a5ce44954e83e5f163e7a65f7f7a7fec499ceb0ddd76a46ef635408c513d64c076470eac86b7f2c8ae4fcd112cb28ce82c0d64ec2c94@127.0.0.1:30304"]], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "Success"
-}
-```
-
-
-
-### `perm_getAccountsAllowlist`
-
-Lists accounts (participants) in the [accounts permissions list](../../how-to/use-permissioning/local.md#account-permissioning).
-
-#### Parameters
-
-None
-
-#### Returns
-
-`result`: _array_ of _strings_ - list of accounts (participants) in the accounts allowlist
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_getAccountsAllowlist","params":[], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"perm_getAccountsAllowlist","params":[], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- "0x0000000000000000000000000000000000000009",
- "0xb9b81ee349c3807e46bc71aa2632203c5b462033"
- ]
-}
-```
-
-
-
-### `perm_getNodesAllowlist`
-
-Lists nodes in the [nodes allowlist](../../how-to/use-permissioning/local.md#node-allowlisting).
-
-#### Parameters
-
-None
-
-#### Returns
-
-`result`: _array_ of _strings_ - [enode URLs](../../../public-networks/concepts/node-keys.md#enode-url) of nodes in the nodes allowlist
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_getNodesAllowlist","params":[], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"perm_getNodesAllowlist","params":[], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- "enode://7b61d5ee4b44335873e6912cb5dd3e3877c860ba21417c9b9ef1f7e500a82213737d4b269046d0669fb2299a234ca03443f25fe5f706b693b3669e5c92478ade@127.0.0.1:30305",
- "enode://2feb33b3c6c4a8f77d84a5ce44954e83e5f163e7a65f7f7a7fec499ceb0ddd76a46ef635408c513d64c076470eac86b7f2c8ae4fcd112cb28ce82c0d64ec2c94@127.0.0.1:30304"
- ]
-}
-```
-
-
-
-### `perm_reloadPermissionsFromFile`
-
-Reloads the accounts and nodes allowlists from the [permissions configuration file].
-
-#### Parameters
-
-None
-
-#### Returns
-
-`result`: _string_ - `Success`, or `error` if the permissions configuration file is not valid
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_reloadPermissionsFromFile","params":[], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"perm_reloadPermissionsFromFile","params":[], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "Success"
-}
-```
-
-
-
-### `perm_removeAccountsFromAllowlist`
-
-Removes accounts (participants) from the [accounts permissions list](../../how-to/use-permissioning/local.md#account-permissioning).
-
-#### Parameters
-
-`addresses`: _array_ of _strings_ - list of account addresses
-
-:::note
-
-The parameters list contains a list which is why the account addresses are enclosed by double square brackets.
-
-:::
-
-#### Returns
-
-`result`: _string_ - `Success` or `error` (errors include attempting to remove accounts not on the allowlist and including invalid account addresses.)
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_removeAccountsFromAllowlist","params":[["0xb9b81ee349c3807e46bc71aa2632203c5b462032", "0xb9b81ee349c3807e46bc71aa2632203c5b462034"]], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"perm_removeAccountsFromAllowlist","params":[["0xb9b81ee349c3807e46bc71aa2632203c5b462032", "0xb9b81ee349c3807e46bc71aa2632203c5b462034"]], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "Success"
-}
-```
-
-
-
-### `perm_removeNodesFromAllowlist`
-
-Removes nodes from the [nodes allowlist](../../how-to/use-permissioning/local.md#node-allowlisting).
-
-#### Parameters
-
-`enodes`: _array_ of _strings_ - list of [enode URLs](../../../public-networks/concepts/node-keys.md#enode-url)
-
-:::note
-
-The parameters list contains a list which is why the enode URLs are enclosed by double square brackets.
-
-:::
-
-#### Returns
-
-`result`: _string_ - `Success` or `error` (errors include attempting to remove nodes not on the allowlist and including invalid enode URLs.)
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_removeNodesFromAllowlist","params":[["enode://7e4ef30e9ec683f26ad76ffca5b5148fa7a6575f4cfad4eb0f52f9c3d8335f4a9b6f9e66fcc73ef95ed7a2a52784d4f372e7750ac8ae0b544309a5b391a23dd7@127.0.0.1:30303","enode://2feb33b3c6c4a8f77d84a5ce44954e83e5f163e7a65f7f7a7fec499ceb0ddd76a46ef635408c513d64c076470eac86b7f2c8ae4fcd112cb28ce82c0d64ec2c94@127.0.0.1:30304"]], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"perm_removeNodesFromAllowlist","params":[["enode://7e4ef30e9ec683f26ad76ffca5b5148fa7a6575f4cfad4eb0f52f9c3d8335f4a9b6f9e66fcc73ef95ed7a2a52784d4f372e7750ac8ae0b544309a5b391a23dd7@127.0.0.1:30303","enode://2feb33b3c6c4a8f77d84a5ce44954e83e5f163e7a65f7f7a7fec499ceb0ddd76a46ef635408c513d64c076470eac86b7f2c8ae4fcd112cb28ce82c0d64ec2c94@127.0.0.1:30304"]], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "Success"
-}
-```
-
-
-
-## `PRIV` methods
-
-The `PRIV` API methods provide functionality for [private transactions](../../concepts/privacy/private-transactions/index.md) and [privacy groups](../../concepts/privacy/privacy-groups.md).
-
-:::note
-
-The `PRIV` API methods are not enabled by default for JSON-RPC. To enable the `PRIV` API methods, use the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../public-networks/reference/cli/options.md#rpc-ws-api) options.
-
-:::
-
-### `priv_call`
-
-Invokes a private contract function locally and does not change the privacy group state.
-
-For private contracts, `priv_call` is the same as [`eth_call`](../../../public-networks/reference/api/index.md#eth_call) for public contracts.
-
-#### Parameters
-
-- `privacyGroupId`: _string_ - 32-byte [privacy Group ID](../../concepts/privacy/privacy-groups.md)
-
-- `call`: _object_ - [transaction call object](../../../public-networks/reference/api/objects.md#transaction-call-object)
-
-- `blockNumber`: _string_ - hexadecimal or decimal integer representing a block number or one of the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-#### Returns
-
-`result`: _data_ - return value of the executed contract
-
-
-
-# curl HTTP
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"priv_call","params":["tb8NVyQqZnHNegf/3mYsyB+HEud4SPWn90rz3GoskRw=", {"to":"0x69498dd54bd25aa0c886cf1f8b8ae0856d55ff13","data": "0x3fa4f245"}, "latest"],"id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS
-
-```bash
-{"jsonrpc":"2.0","method":"priv_call","params":["tb8NVyQqZnHNegf/3mYsyB+HEud4SPWn90rz3GoskRw=", {"to":"0x69498dd54bd25aa0c886cf1f8b8ae0856d55ff13","data": "0x3fa4f245"}, "latest"],"id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x0000000000000000000000000000000000000000000000000000000000000001"
-}
-```
-
-# curl GraphQL
-
-```bash
-curl -X POST -H "Content-Type: application/json" --data '{ "query": "{block {number call (data : {from : \"0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b\", to: \"0x69498dd54bd25aa0c886cf1f8b8ae0856d55ff13\", data :\"0x12a7b914\"}){data status}}}"}' http://localhost:8547/graphql
-```
-
-# GraphQL
-
-```bash
-{
- block {
- number
- call(data: {from: "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b", to: "0x69498dd54bd25aa0c886cf1f8b8ae0856d55ff13", data: "0x12a7b914"}) {
- data
- status
- }
- }
-}
-```
-
-# GraphQL result
-
-```json
-{
- "data": {
- "block": {
- "number": 17449,
- "call": {
- "data": "0x",
- "status": 1
- }
- }
- }
-}
-```
-
-
-
-### `priv_createPrivacyGroup`
-
-Creates a group of nodes, specified by their [Tessera](https://docs.tessera.consensys.net/) public key.
-
-#### Parameters
-
-`options`: _object_ - request options object with the following fields:
-
-- `addresses`: _array_ of _strings_ - list of nodes specified by [Tessera](https://docs.tessera.consensys.net/) public keys
-
-- `name`: _string_ - (optional) privacy group name
-
-- `description`: _string_ - (optional) privacy group description
-
-#### Returns
-
-`result`: _string_ - privacy group ID
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method": "priv_createPrivacyGroup", "params": [{"addresses":["sTZpbQhcOfd9ZaFDnC00e/N2Ofv9p4/ZTBbEeVtXJ3E=","quhb1pQPGN1w8ZSZSyiIfncEAlVY/M/rauSyQ5wVMRE="],"name":"Group A","description":"Description Group A"}],"id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method": "priv_createPrivacyGroup", "params": [{"addresses":["sTZpbQhcOfd9ZaFDnC00e/N2Ofv9p4/ZTBbEeVtXJ3E=","quhb1pQPGN1w8ZSZSyiIfncEAlVY/M/rauSyQ5wVMRE="],"name":"Group A","description":"Description Group A"}],"id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "ewuTVoc5nlvWMwTFdRRK/wvV0dcyQo/Pauvx5bNEbTk="
-}
-```
-
-
-
-### `priv_debugGetStateRoot`
-
-Returns the state root of the specified privacy group at the specified block.
-
-#### Parameters
-
-- `privacyGroupId`: _string_ - 32-byte [privacy Group ID](../../concepts/privacy/privacy-groups.md)
-
-- `blockNumber`: _string_ - hexadecimal or decimal integer representing a block number or one of the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-#### Returns
-
-`result`: _string_ - 32-byte state root
-
-
-
-# curl HTTP
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"priv_debugGetStateRoot","params":["xJdxvWOEmrs2MCkKWlgArTzWIXFfU/tmVxI3EKssVTk=","latest"],"id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS
-
-```bash
-{"jsonrpc":"2.0","method":"priv_debugGetStateRoot","params":["xJdxvWOEmrs2MCkKWlgArTzWIXFfU/tmVxI3EKssVTk=","latest"],"id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421"
-}
-```
-
-
-
-### `priv_deletePrivacyGroup`
-
-Deletes the specified privacy group.
-
-#### Parameters
-
-`privacyGroupId`: _string_ - privacy group ID
-
-#### Returns
-
-`result`: _string_ - deleted privacy group ID
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"priv_deletePrivacyGroup","params":["ewuTVoc5nlvWMwTFdRRK/wvV0dcyQo/Pauvx5bNEbTk="],"id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"priv_deletePrivacyGroup","params":["ewuTVoc5nlvWMwTFdRRK/wvV0dcyQo/Pauvx5bNEbTk="],"id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 53,
- "result": "ewuTVoc5nlvWMwTFdRRK/wvV0dcyQo/Pauvx5bNEbTk="
-}
-```
-
-
-
-### `priv_distributeRawTransaction`
-
-Distributes a signed, RLP encoded [private transaction](../../how-to/send-transactions/private-transactions.md).
-
-:::tip
-
-If you want to sign the [privacy marker transaction](../../how-to/use-privacy/sign-pmts.md) outside of Besu, use [`priv_distributeRawTransaction`](../../how-to/send-transactions/private-transactions.md#priv_distributerawtransaction) instead of [`eea_sendRawTransaction`](#eea_sendrawtransaction).
-
-:::
-
-#### Parameters
-
-`transaction`: _string_ - signed RLP-encoded private transaction
-
-#### Returns
-
-`result`: _string_ - 32-byte enclave key (the enclave key is a pointer to the private transaction in [Tessera](https://docs.tessera.consensys.net/).)
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"priv_distributeRawTransaction","params": ["0xf869018203e882520894f17f52151ebef6c7334fad080c5704d77216b732881bc16d674ec80000801ba02da1c48b670996dcb1f447ef9ef00b33033c48a4fe938f420bec3e56bfd24071a062e0aa78a81bf0290afbc3a9d8e9a068e6d74caa66c5e0fa8a46deaae96b0833"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"priv_distributeRawTransaction","params": ["0xf869018203e882520894f17f52151ebef6c7334fad080c5704d77216b732881bc16d674ec80000801ba02da1c48b670996dcb1f447ef9ef00b33033c48a4fe938f420bec3e56bfd24071a062e0aa78a81bf0290afbc3a9d8e9a068e6d74caa66c5e0fa8a46deaae96b0833"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0xfd0d90ab824574abc19c0776ca0210e764561d0ef6d621f2bbbea316eccfe56b"
-}
-```
-
-
-
-### `priv_findPrivacyGroup`
-
-Returns a list of privacy groups containing only the listed members. For example, if the listed members are A and B, a privacy group containing A, B, and C is not returned.
-
-#### Parameters
-
-`members`: _array_ of _strings_ - members specified by [Tessera](https://docs.tessera.consensys.net/) public keys
-
-#### Returns
-
-`result`: _array_ of _objects_ - privacy group objects containing only the specified members; privacy groups are [EEA-compliant](../../concepts/privacy/privacy-groups.md#enterprise-ethereum-alliance-privacy) or [Besu-extended](../../concepts/privacy/privacy-groups.md#besu-extended-privacy) with types:
-
-- `LEGACY` for EEA-compliant groups.
-
-- `PANTHEON` for Besu-extended groups.
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc": "2.0","method": "priv_findPrivacyGroup","params": [["negmDcN2P4ODpqn/6WkJ02zT/0w0bjhGpkZ8UP6vARk=", "g59BmTeJIn7HIcnq8VQWgyh/pDbvbt2eyP0Ii60aDDw="]],"id": 1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc": "2.0","method": "priv_findPrivacyGroup","params": [["negmDcN2P4ODpqn/6WkJ02zT/0w0bjhGpkZ8UP6vARk=", "g59BmTeJIn7HIcnq8VQWgyh/pDbvbt2eyP0Ii60aDDw="]],"id": 1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- {
- "privacyGroupId": "GpK3ErNO0xF27T0sevgkJ3+4qk9Z+E3HtXYxcKIBKX8=",
- "name": "Group B",
- "description": "Description of Group B",
- "type": "PANTHEON",
- "members": [
- "negmDcN2P4ODpqn/6WkJ02zT/0w0bjhGpkZ8UP6vARk=",
- "g59BmTeJIn7HIcnq8VQWgyh/pDbvbt2eyP0Ii60aDDw="
- ]
- }
- ]
-}
-```
-
-
-
-### `priv_getCode`
-
-Returns the code of the private smart contract at the specified address. Compiled smart contract code is stored as a hexadecimal value.
-
-#### Parameters
-
-- `privacyGroupId`: _string_ - 32-byte [privacy Group ID](../../concepts/privacy/privacy-groups.md)
-
-- `address`: _string_ - 20-byte contract address
-
-- `blockNumber`: _string_ - hexadecimal or decimal integer representing a block number or one of the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-#### Returns
-
-`result`: _data_ - code stored at the specified address
-
-
-
-# curl HTTP
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"priv_getCode","params":["1lJxSIP4JOp6uRn9wYsPeWwqoOP1c4nPQjylB4FExUA=", "0xeaf1c1bd00ef0bec5e39fba81740f1c5d05aa201", "latest"],"id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS
-
-```bash
-{"jsonrpc":"2.0","method":"priv_getCode","params":["1lJxSIP4JOp6uRn9wYsPeWwqoOP1c4nPQjylB4FExUA=", "0xeaf1c1bd00ef0bec5e39fba81740f1c5d05aa201", "latest"],"id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x60806040526004361060485763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416633fa4f2458114604d57806355241077146071575b600080fd5b348015605857600080fd5b50605f6088565b60408051918252519081900360200190f35b348015607c57600080fd5b506086600435608e565b005b60005481565b60008190556040805182815290517f199cd93e851e4c78c437891155e2112093f8f15394aa89dab09e38d6ca0727879181900360200190a1505600a165627a7a723058209d8929142720a69bde2ab3bfa2da6217674b984899b62753979743c0470a2ea70029"
-}
-```
-
-
-
-### `priv_getEeaTransactionCount`
-
-Returns the private transaction count for the specified account and [group of sender and recipients].
-
-::caution important
-If sending more than one transaction to be mined in the same block (that is, you are not
-waiting for the transaction receipt), you must calculate the private transaction nonce outside
-Besu instead of using `priv_getEeaTransactionCount`.
-:::
-
-#### Parameters
-
-- `address`: _string_ - account address
-
-- `sender`: _string_ - base64-encoded Tessera address of the sender
-
-- `recipients`: _array_ of _strings_ - base64-encoded Tessera addresses of recipients
-
-#### Returns
-
-`result`: _string_ - integer representing the number of private transactions sent from the address to the specified group of sender and recipients
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"priv_getEeaTransactionCount","params":["0xfe3b557e8fb62b89f4916b721be55ceb828dbd73", "GGilEkXLaQ9yhhtbpBT03Me9iYa7U/mWXxrJhnbl1XY=", ["KkOjNLmCI6r+mICrC6l+XuEDjFEzQllaMQMpWLl4y1s=","eLb69r4K8/9WviwlfDiZ4jf97P9czyS3DkKu0QYGLjg="]], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"priv_getEeaTransactionCount","params":["0xfe3b557e8fb62b89f4916b721be55ceb828dbd73", "GGilEkXLaQ9yhhtbpBT03Me9iYa7U/mWXxrJhnbl1XY=", ["KkOjNLmCI6r+mICrC6l+XuEDjFEzQllaMQMpWLl4y1s=","eLb69r4K8/9WviwlfDiZ4jf97P9czyS3DkKu0QYGLjg="]], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x1"
-}
-```
-
-
-
-### `priv_getFilterChanges`
-
-Polls the specified filter for a private contract and returns an array of changes that have occurred since the last poll.
-
-Filters for private contracts can only be created by [`priv_newFilter`](#priv_newfilter) so unlike [`eth_getFilterChanges`](../../../public-networks/reference/api/index.md#eth_getfilterchanges), `priv_getFilterChanges` always returns an array of log objects or an empty list.
-
-#### Parameters
-
-- `privacyGroupId`: _string_ - 32-byte [privacy Group ID](../../concepts/privacy/privacy-groups.md)
-
-- `filterId`: _string_ - filter ID
-
-#### Returns
-
-`result`: _array_ of _objects_ - list of [log objects](../../../public-networks/reference/api/objects.md#log-object), or an empty list if nothing has changed since the last poll
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc": "2.0","method": "priv_getFilterChanges","params": ["4rFldHM792LeP/e2WPkTXZedjwKuTr/KwCFTt6mBbkI=","0x4a35b92809d73f4f53a2355d62125442"],"id": 1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc": "2.0","method": "priv_getFilterChanges","params": ["4rFldHM792LeP/e2WPkTXZedjwKuTr/KwCFTt6mBbkI=","0x4a35b92809d73f4f53a2355d62125442"],"id": 1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- {
- "logIndex": "0x0",
- "removed": false,
- "blockNumber": "0x4d0",
- "blockHash": "0x1c8200667a869e99b945374c37277b5ee7a7ae67943e13c82563381387553dbb",
- "transactionHash": "0xb1966b9b372ba68952f48f3a3e78f036f5ae82ceca2de972a782d07fb88f6d88",
- "transactionIndex": "0x0",
- "address": "0x991cc548c154b2953cc48c02f782e1314097dfbb",
- "data": "0x",
- "topics": [
- "0x85bea11d86cefb165374e0f727bacf21dc2f4ea816493981ecf72dcfb212a410",
- "0x0000000000000000000000000000000000000000000000000000000000000002"
- ]
- }
- ]
-}
-```
-
-
-
-### `priv_getFilterLogs`
-
-Returns an array of [logs](../../../public-networks/concepts/events-and-logs.md) for the specified filter for a private contract.
-
-For private contracts, `priv_getFilterLogs` is the same as [`eth_getFilterLogs`](../../../public-networks/reference/api/index.md#eth_getfilterlogs) for public contracts except there's no [automatic log bloom caching](../../../public-networks/reference/cli/options.md#auto-log-bloom-caching-enabled) for private contracts.
-
-:::note
-
-`priv_getFilterLogs` is only used for filters created with [`priv_newFilter`](#priv_newfilter). To specify a filter object and get logs without creating a filter, use [`priv_getLogs`](#priv_getlogs).
-
-:::
-
-#### Parameters
-
-- `privacyGroupId`: _string_ - 32-byte [privacy Group ID](../../concepts/privacy/privacy-groups.md)
-
-- `filterId`: _string_ - filter ID
-
-#### Returns
-
-`result`: _array_ of _objects_ - list of [log objects](../../../public-networks/reference/api/objects.md#log-object)
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc": "2.0","method": "priv_getFilterLogs","params":["4rFldHM792LeP/e2WPkTXZedjwKuTr/KwCFTt6mBbkI=","0x4a35b92809d73f4f53a2355d62125442"],"id": 1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc": "2.0","method": "priv_getFilterLogs","params":["4rFldHM792LeP/e2WPkTXZedjwKuTr/KwCFTt6mBbkI=","0x4a35b92809d73f4f53a2355d62125442"],"id": 1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- {
- "logIndex": "0x0",
- "removed": false,
- "blockNumber": "0x493",
- "blockHash": "0xd9cb3a852e1e02c95f035a2e32d57f82c10cab61faa3e8f5c010adf979bb4786",
- "transactionHash": "0x78866dc51fdf189d8cca74f6a8fe54f172348fbd2163bbe80fa8b106cfc7deb4",
- "transactionIndex": "0x0",
- "address": "0x991cc548c154b2953cc48c02f782e1314097dfbb",
- "data": "0x",
- "topics": [
- "0x85bea11d86cefb165374e0f727bacf21dc2f4ea816493981ecf72dcfb212a410",
- "0x0000000000000000000000000000000000000000000000000000000000000001"
- ]
- },
- {
- "logIndex": "0x0",
- "removed": false,
- "blockNumber": "0x4d0",
- "blockHash": "0x1c8200667a869e99b945374c37277b5ee7a7ae67943e13c82563381387553dbb",
- "transactionHash": "0xb1966b9b372ba68952f48f3a3e78f036f5ae82ceca2de972a782d07fb88f6d88",
- "transactionIndex": "0x0",
- "address": "0x991cc548c154b2953cc48c02f782e1314097dfbb",
- "data": "0x",
- "topics": [
- "0x85bea11d86cefb165374e0f727bacf21dc2f4ea816493981ecf72dcfb212a410",
- "0x0000000000000000000000000000000000000000000000000000000000000002"
- ]
- }
- ]
-}
-```
-
-
-
-### `priv_getLogs`
-
-Returns an array of [logs](../../../public-networks/concepts/events-and-logs.md) matching a specified filter object.
-
-For private contracts, `priv_getLogs` is the same as [`eth_getLogs`](../../../public-networks/reference/api/index.md#eth_getlogs) for public contracts except there is no [automatic log bloom caching](../../../public-networks/reference/cli/options.md#auto-log-bloom-caching-enabled) for private contracts.
-
-#### Parameters
-
-- `privacyGroupId`: _string_ - 32-byte [privacy Group ID](../../concepts/privacy/privacy-groups.md)
-
-- `filterOptions`: _object_ - [filter options object](../../../public-networks/reference/api/objects.md#filter-options-object)
-
-#### Returns
-
-`result`: _array_ of _objects_ - list of [log objects](../../../public-networks/reference/api/objects.md#log-object)
-
-
-
-# curl HTTP
-
-```bash
-curl -X POST --data '{"jsonrpc": "2.0","method": "priv_getLogs","params":["vGy/TZgO6y8VPMVeJAQ99MF1NaTf5ohA3TFfzoEF71k=",{"fromBlock": "earliest","toBlock": "latest","addresses": ["0x630c507ff633312087dc33c513b66276abcd2fc3"],"topics": ["0x85bea11d86cefb165374e0f727bacf21dc2f4ea816493981ecf72dcfb212a410"]}],"id": 1}' http://127.0.0.1:8545
-```
-
-# wscat WS
-
-```bash
-{"jsonrpc": "2.0","method": "priv_getLogs","params":["vGy/TZgO6y8VPMVeJAQ99MF1NaTf5ohA3TFfzoEF71k=",{"fromBlock": "earliest","toBlock": "latest","addresses": ["0x630c507ff633312087dc33c513b66276abcd2fc3"],"topics": ["0x85bea11d86cefb165374e0f727bacf21dc2f4ea816493981ecf72dcfb212a410"]}],"id": 1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- {
- "logIndex": "0x0",
- "removed": false,
- "blockNumber": "0x342",
- "blockHash": "0xf5954f068fa2f2f7741281e8c753a8e92047e27ab3c4971836d2c89fab86d92b",
- "transactionHash": "0xa9ba5cffde9d4ad8997c5c4352d5d49eeea0e9def8a4ea69991b8837c49d4e4f",
- "transactionIndex": "0x0",
- "address": "0x630c507ff633312087dc33c513b66276abcd2fc3",
- "data": "0x",
- "topics": [
- "0x85bea11d86cefb165374e0f727bacf21dc2f4ea816493981ecf72dcfb212a410",
- "0x0000000000000000000000000000000000000000000000000000000000000001"
- ]
- },
- {
- "logIndex": "0x0",
- "removed": false,
- "blockNumber": "0x383",
- "blockHash": "0x91b73a47d53e3a88d62ed091a89a4be7557ad91b552e7ff7d86bf78977d5d45d",
- "transactionHash": "0xc2a185faf00e87434e55b7f70cc4c38be354c2128b4b96b5f5def0b54a2173ec",
- "transactionIndex": "0x0",
- "address": "0x630c507ff633312087dc33c513b66276abcd2fc3",
- "data": "0x",
- "topics": [
- "0x85bea11d86cefb165374e0f727bacf21dc2f4ea816493981ecf72dcfb212a410",
- "0x0000000000000000000000000000000000000000000000000000000000000002"
- ]
- }
- ]
-}
-```
-
-
-
-### `priv_getPrivacyPrecompileAddress`
-
-Returns the address of the [privacy precompiled contract](../../concepts/privacy/private-transactions/processing.md). The address is derived and based on the value of the [`privacy-flexible-groups-enabled`](../cli/options.md#privacy-flexible-groups-enabled) option.
-
-#### Parameters
-
-None
-
-#### Returns
-
-`result`: _string_ - address of the privacy precompile
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"priv_getPrivacyPrecompileAddress","params":[], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"priv_getPrivacyPrecompileAddress","params":[], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x000000000000000000000000000000000000007e"
-}
-```
-
-
-
-### `priv_getPrivateTransaction`
-
-Returns the private transaction if you are a participant, otherwise, `null`.
-
-#### Parameters
-
-`transaction`: _string_ - transaction hash returned by [`eea_sendRawTransaction`](#eea_sendrawtransaction) or [`eea_sendTransaction`](https://docs.ethsigner.consensys.net/Reference/API-Methods#eea_sendtransaction).
-
-#### Returns
-
-`result`: _object_ - [private transaction object](objects.md#private-transaction-object), or `null` if not a participant in the private transaction
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"priv_getPrivateTransaction","params":["0x623c4ce5275a87b91f4f1c521012d39ca19311c787bde405490f4c0426a71498"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"priv_getPrivateTransaction","params":["0x623c4ce5275a87b91f4f1c521012d39ca19311c787bde405490f4c0426a71498"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "from": "0xfe3b557e8fb62b89f4916b721be55ceb828dbd73",
- "gas": "0x2dc6c0",
- "gasPrice": "0x0",
- "hash": "0x623c4ce5275a87b91f4f1c521012d39ca19311c787bde405490f4c0426a71498",
- "input": "0x608060405234801561001057600080fd5b50336000806101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550610221806100606000396000f300608060405260043610610057576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680633fa4f2451461005c5780636057361d1461008757806367e404ce146100b4575b600080fd5b34801561006857600080fd5b5061007161010b565b6040518082815260200191505060405180910390f35b34801561009357600080fd5b506100b260048036038101908080359060200190929190505050610115565b005b3480156100c057600080fd5b506100c96101cb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6000600254905090565b7fc9db20adedc6cf2b5d25252b101ab03e124902a73fcb12b753f3d1aaa2d8f9f53382604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281526020019250505060405180910390a18060028190555033600160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6000600160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff169050905600a165627a7a723058208efaf938851fb2d235f8bf9a9685f149129a30fe0f4b20a6c1885dc02f639eba0029",
- "nonce": "0x0",
- "to": null,
- "value": "0x0",
- "v": "0xfe8",
- "r": "0x654a6a9663ca70bb13e27cca14b3777cc92da184e19a151cdeef2ccbbd5c6405",
- "s": "0x5dd4667b020c8a5af7ae28d4c3126f8dcb1187f49dcf0de9d7a39b1651892eef",
- "privateFrom": "negmDcN2P4ODpqn/6WkJ02zT/0w0bjhGpkZ8UP6vARk=",
- "privateFor": ["g59BmTeJIn7HIcnq8VQWgyh/pDbvbt2eyP0Ii60aDDw="],
- "restriction": "restricted"
- }
-}
-```
-
-
-
-### `priv_getTransactionCount`
-
-Returns the private transaction count for specified account and privacy group.
-
-:::important
-
-If sending more than one transaction to be mined in the same block (that is, you are not waiting for the transaction receipt), you must calculate the private transaction nonce outside Besu instead of using `priv_getTransactionCount`.
-
-:::
-
-#### Parameters
-
-- `address`: _string_ - account address
-
-- `privacyGroupId`: _string_ - privacy group ID
-
-#### Returns
-
-`result`: _string_ - integer representing the number of private transactions sent from the address to the specified privacy group
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"priv_getTransactionCount","params":["0xfe3b557e8fb62b89f4916b721be55ceb828dbd73", "kAbelwaVW7okoEn1+okO+AbA4Hhz/7DaCOWVQz9nx5M="], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"priv_getTransactionCount","params":["0xfe3b557e8fb62b89f4916b721be55ceb828dbd73", "kAbelwaVW7okoEn1+okO+AbA4Hhz/7DaCOWVQz9nx5M="], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x1"
-}
-```
-
-
-
-### `priv_getTransactionReceipt`
-
-Returns information about the private transaction after mining the transaction. Receipts for pending transactions are not available.
-
-#### Parameters
-
-`transaction`: _string_ - 32-byte hash of a transaction
-
-#### Returns
-
-`result`: _object_ - [private Transaction receipt object](objects.md#private-transaction-receipt-object), or `null` if no receipt found
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"priv_getTransactionReceipt","params":["0xf3ab9693ad92e277bf785e1772f29fb1864904bbbe87b0470455ddb082caab9d"],"id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"priv_getTransactionReceipt","params":["0xf3ab9693ad92e277bf785e1772f29fb1864904bbbe87b0470455ddb082caab9d"],"id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "blockHash": "0xe7212a92cfb9b06addc80dec2a0dfae9ea94fd344efeb157c41e12994fcad60a",
- "blockNumber": "0x50",
- "contractAddress": "0x493b76031593402e24e16faa81f677b58e2d53f3",
- "from": "0xfe3b557e8fb62b89f4916b721be55ceb828dbd73",
- "logs": [],
- "to": "0xf17f52151ebef6c7334fad080c5704d77216b732",
- "transactionHash": "0x36219e92b5f53d4150aa9ef7d2d793118cced523de6724100da5b534e3ceb4b8",
- "transactionIndex": "0x0",
- "output": "0x6080604052600436106049576000357c010000000000000000000000000000000000000000000
- 0000000000000900463ffffffff1680633fa4f24514604e57806355241077146076575b600080fd5b3480156059
- 57600080fd5b50606060a0565b6040518082815260200191505060405180910390f35b348015608157600080fd5b
- 50609e6004803603810190808035906020019092919050505060a6565b005b60005481565b8060008190555050560
- 0a165627a7a723058202bdbba2e694dba8fff33d9d0976df580f57bff0a40e25a46c398f8063b4c00360029",
- "commitmentHash": "0x79b9e6b0856db398ad7dc208f15b1d38c0c0b0c5f99e4a443a2c5a85510e96a5",
- "status": "0x1",
- "privateFrom": "negmDcN2P4ODpqn/6WkJ02zT/0w0bjhGpkZ8UP6vARk=",
- "privacyGroupId": "cD636RZlcqVSpoxT/ExbkWQfBO7kPAZO0QlWHErNSL8=",
- "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
- }
-}
-```
-
-
-
-### `priv_newFilter`
-
-Creates a [log filter](../../../public-networks/concepts/events-and-logs.md) for a private contract. To poll for logs associated with the created filter, use [`priv_getFilterChanges`](#priv_getfilterchanges). To get all logs associated with the filter, use [`priv_getFilterLogs`](#priv_getfilterlogs).
-
-For private contracts, `priv_newFilter` is the same as [`eth_newFilter`](../../../public-networks/reference/api/index.md#eth_newfilter) for public contracts.
-
-#### Parameters
-
-- `privacyGroupId`: _string_ - 32-byte [privacy Group ID](../../concepts/privacy/privacy-groups.md)
-
-- `filterOptions`: _object_ - [filter options object](../../../public-networks/reference/api/objects.md#filter-options-object)
-
-:::note
-
-`fromBlock` and `toBlock` in the filter options object default to `latest`.
-
-:::
-
-#### Returns
-
-`result`: _string_ - filter ID
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc": "2.0","method": "priv_newFilter","params": ["4rFldHM792LeP/e2WPkTXZedjwKuTr/KwCFTt6mBbkI=",{"fromBlock": "earliest","toBlock": "latest","addresses": ["0x991cc548c154b2953cc48c02f782e1314097dfbb"],"topics": ["0x85bea11d86cefb165374e0f727bacf21dc2f4ea816493981ecf72dcfb212a410"]}],"id": 1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc": "2.0","method": "priv_newFilter","params": ["4rFldHM792LeP/e2WPkTXZedjwKuTr/KwCFTt6mBbkI=",{"fromBlock": "earliest","toBlock": "latest","addresses": ["0x991cc548c154b2953cc48c02f782e1314097dfbb"],"topics": ["0x85bea11d86cefb165374e0f727bacf21dc2f4ea816493981ecf72dcfb212a410"]}],"id": 1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x4a35b92809d73f4f53a2355d62125442"
-}
-```
-
-
-
-### `priv_uninstallFilter`
-
-Uninstalls a filter for a private contract with the specified ID. When a filter is no longer required, call this method.
-
-Filters time out when not requested by [`priv_getFilterChanges`](#priv_getfilterchanges) or [`priv_getFilterLogs`](#priv_getfilterlogs) for 10 minutes.
-
-For private contracts, `priv_uninstallFilter` is the same as [`eth_uninstallFilter`](../../../public-networks/reference/api/index.md#eth_uninstallfilter) for public contracts.
-
-#### Parameters
-
-- `privacyGroupId`: _string_ - 32-byte [privacy group ID](../../concepts/privacy/privacy-groups.md)
-
-- `filterId`: _string_ - filter ID
-
-#### Returns
-
-`result`: _boolean_ - indicates if the filter is successfully uninstalled
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc": "2.0","method": "priv_uninstallFilter","params":["4rFldHM792LeP/e2WPkTXZedjwKuTr/KwCFTt6mBbkI=","0x4a35b92809d73f4f53a2355d62125442"],"id": 1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc": "2.0","method": "priv_uninstallFilter","params":["4rFldHM792LeP/e2WPkTXZedjwKuTr/KwCFTt6mBbkI=","0x4a35b92809d73f4f53a2355d62125442"],"id": 1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": true
-}
-```
-
-
-
-## `QBFT` methods
-
-The `QBFT` API methods provide access to the [QBFT](../../how-to/configure/consensus/qbft.md) consensus engine.
-
-:::note
-
-The `QBFT` API methods are not enabled by default for JSON-RPC. To enable the `QBFT` API methods, use the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) or [`--rpc-ws-api`](../../../public-networks/reference/cli/options.md#rpc-ws-api) options.
-
-:::
-
-### `qbft_discardValidatorVote`
-
-Discards a proposal to [add or remove a validator](../../how-to/configure/consensus/qbft.md#add-and-remove-validators) with the specified address.
-
-#### Parameters
-
-`address`: _string_ - 20-byte address of proposed validator
-
-#### Returns
-
-`result`: _boolean_ - indicates if the proposal is discarded
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_discardValidatorVote","params":["0xef1bfb6a12794615c9b0b5a21e6741f01e570185"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"qbft_discardValidatorVote","params":["0xef1bfb6a12794615c9b0b5a21e6741f01e570185"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": true
-}
-```
-
-
-
-### `qbft_getPendingVotes`
-
-Returns [votes](../../how-to/configure/consensus/qbft.md#add-and-remove-validators) cast in the current [epoch](../../how-to/configure/consensus/qbft.md#genesis-file).
-
-#### Parameters
-
-None
-
-#### Returns
-
-`result`: _map_ of _strings_ to _booleans_ - map of account addresses to corresponding boolean values indicating the vote for each account; if `true`, the vote is to add a validator. If `false`, the proposal is to remove a validator.
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getPendingVotes","params":[], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"qbft_getPendingVotes","params":[], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "0xef1bfb6a12794615c9b0b5a21e6741f01e570185": true,
- "0x42d4287eac8078828cf5f3486cfe601a275a49a5": true
- }
-}
-```
-
-
-
-### `qbft_getSignerMetrics`
-
-Provides the following validator metrics for the specified range:
-
-- Number of blocks from each validator
-
-- Block number of the last block proposed by each validator (if any proposed in the specified range)
-
-- All validators present in the last block of the range
-
-#### Parameters
-
-- `fromBlockNumber`: _string_ - hexadecimal or decimal integer representing a block number or the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-- `toBlockNumber`: _string_ - hexadecimal or decimal integer representing a block number or one of the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-If you specify:
-
-- No parameters, the call provides metrics for the last 100 blocks, or all blocks if there are less than 100 blocks.
-
-- Only the first parameter, the call provides metrics for all blocks from the block specified to the latest block.
-
-#### Returns
-
-`result`: _array_ of _objects_ - list of validator objects
-
-:::note
-
-The proposer of the genesis block has address `0x0000000000000000000000000000000000000000`.
-
-:::
-
-
-
-# curl HTTP
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getSignerMetrics","params":["1", "100"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS
-
-```bash
-{"jsonrpc":"2.0","method":"qbft_getSignerMetrics","params":["1", "100"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- {
- "address": "0x7ffc57839b00206d1ad20c69a1981b489f772031",
- "proposedBlockCount": "0x21",
- "lastProposedBlockNumber": "0x61"
- },
- {
- "address": "0x42eb768f2244c8811c63729a21a3569731535f06",
- "proposedBlockCount": "0x21",
- "lastProposedBlockNumber": "0x63"
- },
- {
- "address": "0xb279182d99e65703f0076e4812653aab85fca0f0",
- "proposedBlockCount": "0x21",
- "lastProposedBlockNumber": "0x62"
- }
- ]
-}
-```
-
-
-
-### `qbft_getValidatorsByBlockHash`
-
-Lists the validators defined in the specified block.
-
-#### Parameters
-
-`block`: _string_ - 32-byte block hash
-
-#### Returns
-
-`result`: _array_ of _strings_ - list of validator addresses
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockHash","params":["0xbae7d3feafd743343b9a4c578cab5e5d65eb735f6855fb845c00cab356331256"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockHash","params":["0xbae7d3feafd743343b9a4c578cab5e5d65eb735f6855fb845c00cab356331256"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- "0x42d4287eac8078828cf5f3486cfe601a275a49a5",
- "0xb1b2bc9582d2901afdc579f528a35ca41403fa85",
- "0xef1bfb6a12794615c9b0b5a21e6741f01e570185"
- ]
-}
-```
-
-
-
-### `qbft_getValidatorsByBlockNumber`
-
-Lists the validators defined in the specified block.
-
-#### Parameters
-
-- `blockNumber`: _string_ - hexadecimal or decimal integer representing a block number or one of the string tags `latest`, `earliest`, `pending`, `finalized`, or `safe`, as described in [block parameter](../../../public-networks/how-to/use-besu-api/json-rpc.md#block-parameter)
-
-#### Returns
-
-`result`: _array_ of _strings_ - list of validator addresses
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- "0x42d4287eac8078828cf5f3486cfe601a275a49a5",
- "0xb1b2bc9582d2901afdc579f528a35ca41403fa85",
- "0xef1bfb6a12794615c9b0b5a21e6741f01e570185"
- ]
-}
-```
-
-
-
-### `qbft_proposeValidatorVote`
-
-Proposes to [add or remove a validator](../../how-to/configure/consensus/qbft.md#add-and-remove-validators) with the specified address.
-
-#### Parameters
-
-- `address`: _string_ - account address
-
-- `proposal`: _boolean_ - `true` to propose adding validator or `false` to propose removing validator
-
-#### Returns
-
-`result`: _boolean_ - `true`
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_proposeValidatorVote","params":["42d4287eac8078828cf5f3486cfe601a275a49a5",true], "id":1}' http://127.0.0.1:8545
-```
-
-# wscat WS request
-
-```bash
-{"jsonrpc":"2.0","method":"qbft_proposeValidatorVote","params":["42d4287eac8078828cf5f3486cfe601a275a49a5",true], "id":1}
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": true
-}
-```
-
-
-
-
-
-[add or remove a signer with the specified address]: ../../how-to/configure/consensus/clique.md#add-and-remove-signers
-[signers for the specified block]: ../../how-to/configure/consensus/clique.md#adding-and-removing-signers
-[add or remove a validator]: ../../how-to/configure/consensus/ibft.md#add-and-remove-validators
-[permissions configuration file]: ../../how-to/use-permissioning/local.md#permissions-configuration-file
-[group of sender and recipients]: ../../concepts/privacy/privacy-groups.md#enterprise-ethereum-alliance-privacy
-
-\*[EEA]: Enterprise Ethereum Alliance
diff --git a/versioned_docs/version-23.10.0/private-networks/reference/api/objects.md b/versioned_docs/version-23.10.0/private-networks/reference/api/objects.md
deleted file mode 100644
index 747a50db098..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/reference/api/objects.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Private network API objects
-sidebar_position: 2
-description: Hyperledger Besu private network API objects reference
-tags:
- - private networks
----
-
-# Private network API objects
-
-The following objects are parameters for or returned by Besu private network API methods.
-
-:::warning
-
-This reference contains API objects that apply to only private networks. For API objects that apply to both private and public networks, see the [public network API objects reference](../../../public-networks/reference/api/objects.md).
-
-:::
-
-## Private transaction object
-
-Returned by [`priv_getPrivateTransaction`](index.md#priv_getprivatetransaction).
-
-| Key | Type | Value |
-| --- | :-: | --- |
-| `from` | Data, 20 bytes | Address of the sender. |
-| `gas` | Quantity | Gas provided by the sender. |
-| `gasPrice` | Quantity | Gas price, in Wei, provided by the sender. |
-| `input` | Data | The data to create or invoke a contract. |
-| `nonce` | Quantity | Number of transactions made by the sender to the privacy group before this one. |
-| `to` | Data, 20 bytes | `null` if a contract creation transaction, otherwise, the contract address. |
-| `value` | Quantity | `null` because private transactions cannot transfer Ether. |
-| `v` | Quantity | ECDSA Recovery ID. |
-| `r` | Data, 32 bytes | ECDSA signature r. |
-| `s` | Data, 32 bytes | ECDSA signature s. |
-| `privateFrom` | Data, 32 bytes | [Tessera](https://docs.tessera.consensys.net/) public key of the sender. |
-| `privateFor` | Array of Data, 32 bytes each | [Tessera](https://docs.tessera.consensys.net/) public keys of recipients. Not returned if using `privacyGroupId` to [send the transaction](../../../private-networks/concepts/privacy/privacy-groups.md#privacy-types). |
-| `privacyGroupId` | Data, 32 bytes | [Tessera](https://docs.tessera.consensys.net/) privacy group ID of recipients. Not returned if using `privateFor` to [send the transaction](../../../private-networks/concepts/privacy/privacy-groups.md#privacy-types). |
-| `restriction` | String | Must be [`restricted`](../../../private-networks/concepts/privacy/private-transactions/index.md). |
-
-## Private transaction receipt object
-
-Returned by [`priv_getTransactionReceipt`](index.md#priv_gettransactionreceipt).
-
-| Key | Type | Value |
-| --- | :-: | --- |
-| `blockHash` | Data, 32 bytes | Hash of block containing this transaction. |
-| `blockNumber` | Quantity | Block number of block containing this transaction. |
-| `contractAddress` | Data, 20 bytes | Contract address created if a contract creation transaction, otherwise, `null`. A failed contract creation transaction still produces a contract address value. |
-| `from` | Data, 20 bytes | Address of the sender. |
-| `logs` | Array | Array of [log objects](../../../public-networks/reference/api/objects.md#log-object) generated by this private transaction. |
-| `to` | Data, 20 bytes | Address of the receiver, if sending ether, otherwise, null. |
-| `transactionIndex` | Quantity, Integer | Index position of transaction in the block. |
-| `revertReason` | String | ABI-encoded string that displays the [reason for reverting the transaction](../../../private-networks/how-to/send-transactions/revert-reason.md). Only available if revert reason is [enabled](../cli/options.md#revert-reason-enabled). |
-| `output` | Data | RLP-encoded return value of a contract call if a value returns, otherwise, `null`. |
-| `commitmentHash` | Data, 32 bytes | Hash of the privacy marker transaction. |
-| `status` | Quantity | Either `0x1` (success) or `0x0` (failure). |
-| `privateFrom` | Data, 32 bytes | [Tessera](https://docs.tessera.consensys.net/) public key of the sender. |
-| `privateFor` or `privacyGroupId` | Array or Data, 32 bytes | [Tessera](https://docs.tessera.consensys.net/) public keys or privacy group ID of the recipients. |
-| `logsBloom` | Data, 256 bytes | Bloom filter for light clients to quickly retrieve related logs. |
diff --git a/versioned_docs/version-23.10.0/private-networks/reference/cli/_category_.json b/versioned_docs/version-23.10.0/private-networks/reference/cli/_category_.json
deleted file mode 100644
index bec3b04721b..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/reference/cli/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Besu CLI",
- "position": 1
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/reference/cli/options.md b/versioned_docs/version-23.10.0/private-networks/reference/cli/options.md
deleted file mode 100644
index 064549d46f2..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/reference/cli/options.md
+++ /dev/null
@@ -1,709 +0,0 @@
----
-title: Private network options
-sidebar_position: 1
-description: Hyperledger Besu private networks CLI reference
-tags:
- - private networks
----
-
-# Private network command line options
-
-This reference describes the syntax of the Hyperledger Besu private network command line interface (CLI) options.
-
-:::danger
-
-This reference contains options that apply to only private networks. For options that apply to both private and public networks, see the [public network options reference](../../../public-networks/reference/cli/options.md).
-
-:::
-
-## Specify options
-
-You can specify Besu options:
-
-- On the command line.
-
- ```bash
- besu [OPTIONS] [SUBCOMMAND]
- ```
-
-- As an environment variable. For each command line option, the equivalent environment variable is:
-
- - Uppercase.
- - `_` replaces `-`.
- - Has a `BESU_` prefix.
-
- For example, set `--miner-coinbase` using the `BESU_MINER_COINBASE` environment variable.
-
-- In a [configuration file](../../../public-networks/how-to/configuration-file.md).
-
-If you specify an option in more than one place, the order of priority is command line, environment variable, configuration file.
-
-If using Bash or Z shell, you can view option suggestions by entering `--` and pressing the Tab key twice.
-
-```bash
-besu --Tab+Tab
-```
-
-:::caution
-
-Characters such as smart quotes and long (em) hyphens don't work in Besu command line options. Ensure quotes aren't automatically converted to smart quotes, or double hyphens combined into em hyphens.
-
-:::
-
-## Options
-
-### `permissions-accounts-config-file`
-
-
-
-# Syntax
-
-```bash
---permissions-accounts-config-file=
-```
-
-# Example
-
-```bash
---permissions-accounts-config-file=/home/me/me_configFiles/myPermissionsFile
-```
-
-# Environment variable
-
-```bash
-BESU_PERMISSIONS_ACCOUNTS_CONFIG_FILE=/home/me/me_configFiles/myPermissionsFile
-```
-
-# Configuration file
-
-```bash
-permissions-accounts-config-file="/home/me/me_configFiles/myPermissionsFile"
-```
-
-
-
-The [accounts permissions configuration file]. The default is the `permissions_config.toml` file in the [data directory](../../../public-networks/reference/cli/options.md#data-path).
-
-:::tip
-
-`--permissions-accounts-config-file` and [`--permissions-nodes-config-file`](#permissions-nodes-config-file) can use the same file.
-
-:::
-
-### `permissions-accounts-config-file-enabled`
-
-
-
-# Syntax
-
-```bash
---permissions-accounts-config-file-enabled[=]
-```
-
-# Example
-
-```bash
---permissions-accounts-config-file-enabled=true
-```
-
-# Environment variable
-
-```bash
-BESU_PERMISSIONS_ACCOUNTS_CONFIG_FILE_ENABLED=true
-```
-
-# Configuration file
-
-```bash
-permissions-accounts-config-file-enabled=true
-```
-
-
-
-Enables or disables file-based account level permissions. The default is `false`.
-
-### `permissions-accounts-contract-address`
-
-
-
-# Syntax
-
-```bash
---permissions-accounts-contract-address=
-```
-
-# Example
-
-```bash
---permissions-accounts-contract-address=xyz
-```
-
-# Environment variable
-
-```bash
-BESU_PERMISSIONS_ACCOUNTS_CONTRACT_ADDRESS=xyz
-```
-
-# Configuration file
-
-```bash
-permissions-accounts-contract-address="xyz"
-```
-
-
-
-The contract address for [onchain account permissioning](../../concepts/permissioning/onchain.md).
-
-### `permissions-accounts-contract-enabled`
-
-
-
-# Syntax
-
-```bash
---permissions-accounts-contract-enabled[=]
-```
-
-# Example
-
-```bash
---permissions-accounts-contract-enabled=true
-```
-
-# Environment variable
-
-```bash
-BESU_PERMISSIONS_ACCOUNTS_CONTRACT_ENABLED=true
-```
-
-# Configuration file
-
-```bash
-permissions-accounts-contract-enabled=true
-```
-
-
-
-Enables or disables contract-based [onchain account permissioning](../../concepts/permissioning/onchain.md). The default is `false`.
-
-### `permissions-nodes-config-file`
-
-
-
-# Syntax
-
-```bash
---permissions-nodes-config-file=
-```
-
-# Example
-
-```bash
---permissions-nodes-config-file=/home/me/me_configFiles/myPermissionsFile
-```
-
-# Environment variable
-
-```bash
-BESU_PERMISSIONS_NODES_CONFIG_FILE=/home/me/me_configFiles/myPermissionsFile
-```
-
-# Configuration file
-
-```bash
-permissions-nodes-config-file="/home/me/me_configFiles/myPermissionsFile"
-```
-
-
-
-The [nodes permissions configuration file]. The default is the `permissions_config.toml` file in the [data directory](../../../public-networks/reference/cli/options.md#data-path).
-
-:::tip
-
-`--permissions-nodes-config-file` and [`--permissions-accounts-config-file`](#permissions-accounts-config-file) can use the same file.
-
-:::
-
-### `permissions-nodes-config-file-enabled`
-
-
-
-# Syntax
-
-```bash
---permissions-nodes-config-file-enabled[=]
-```
-
-# Example
-
-```bash
---permissions-nodes-config-file-enabled=true
-```
-
-# Environment variable
-
-```bash
-BESU_PERMISSIONS_NODES_CONFIG_FILE_ENABLED=true
-```
-
-# Configuration file
-
-```bash
-permissions-nodes-config-file-enabled=true
-```
-
-
-
-Enables or disables file-based node level permissions. The default is `false`.
-
-### `permissions-nodes-contract-address`
-
-
-
-# Syntax
-
-```bash
---permissions-nodes-contract-address=
-```
-
-# Example
-
-```bash
---permissions-nodes-contract-address=xyz
-```
-
-# Environment variable
-
-```bash
-BESU_PERMISSIONS_NODES_CONTRACT_ADDRESS=xyz
-```
-
-# Configuration file
-
-```bash
-permissions-nodes-contract-address="xyz"
-```
-
-
-
-The contract address for [onchain node permissioning](../../concepts/permissioning/onchain.md).
-
-### `permissions-nodes-contract-enabled`
-
-
-
-# Syntax
-
-```bash
---permissions-nodes-contract-enabled[=]
-```
-
-# Example
-
-```bash
---permissions-nodes-contract-enabled=true
-```
-
-# Environment variable
-
-```bash
-BESU_PERMISSIONS_NODES_CONTRACT_ENABLED=true
-```
-
-# Configuration file
-
-```bash
-permissions-nodes-contract-enabled=true
-```
-
-
-
-Enables or disables contract-based [onchain node permissioning](../../concepts/permissioning/onchain.md). The default is `false`.
-
-### `permissions-nodes-contract-version`
-
-
-
-# Syntax
-
-```bash
---permissions-nodes-contract-version=
-```
-
-# Example
-
-```bash
---permissions-nodes-contract-version=2
-```
-
-# Environment variable
-
-```bash
-BESU_PERMISSIONS_NODES_CONTRACT_VERSION=2
-```
-
-# Configuration file
-
-```bash
-permissions-nodes-contract-version=2
-```
-
-
-
-Version of the EEA [node permissioning interface](../../how-to/use-permissioning/onchain.md#specify-the-permissioning-contract-interface-version). The default is 1.
-
-### `privacy-enabled`
-
-
-
-# Syntax
-
-```bash
---privacy-enabled[=]
-```
-
-# Example
-
-```bash
---privacy-enabled=false
-```
-
-# Environment variable
-
-```bash
-BESU_PRIVACY_ENABLED=false
-```
-
-# Configuration file
-
-```bash
-privacy-enabled=false
-```
-
-
-
-Enables or disables [private transactions](../../concepts/privacy/index.md). The default is `false`.
-
-:::important
-
-Using private transactions with [pruning](../../../public-networks/concepts/data-storage-formats.md) or [fast sync](../../../public-networks/reference/cli/options.md#sync-mode) is not supported.
-
-:::
-
-### `privacy-marker-transaction-signing-key-file`
-
-
-
-# Syntax
-
-```bash
---privacy-marker-transaction-signing-key-file=
-```
-
-# Example
-
-```bash
---privacy-marker-transaction-signing-key-file=/home/me/me_node/myPrivateKey
-```
-
-# Environment variable
-
-```bash
-BESU_PRIVACY_MARKER_TRANSACTION_SIGNING_KEY_FILE=/home/me/me_node/myPrivateKey
-```
-
-# Configuration file
-
-```bash
-privacy-marker-transaction-signing-key-file="/home/me/me_node/myPrivateKey"
-```
-
-
-
-`` is the name of the private key file used to [sign privacy marker transactions](../../how-to/use-privacy/sign-pmts.md).
-
-:::note
-
-This can be the same file used by [`--node-private-key-file`](../../../public-networks/reference/cli/options.md#node-private-key-file), or a different key file to identify who signed the privacy marker transaction.
-
-:::
-
-You must specify this option if you're using:
-
-- a privacy network where you pay gas. Also, the associated account must contain adequate funds.
-- [account permissioning] and privacy. You must include the corresponding public key in the accounts allowlist.
-
-If you do not specify this option (for example, in a free gas network), Besu signs each transaction with a different randomly generated key.
-
-### `privacy-multi-tenancy-enabled`
-
-
-
-# Syntax
-
-```bash
---privacy-multi-tenancy-enabled[=]
-```
-
-# Example
-
-```bash
---privacy-multi-tenancy-enabled=false
-```
-
-# Environment variable
-
-```bash
-BESU_PRIVACY_MULTI_TENANCY_ENABLED=false
-```
-
-# Configuration file
-
-```bash
-privacy-multi-tenancy-enabled=false
-```
-
-
-
-Enables or disables [multi-tenancy](../../concepts/privacy/multi-tenancy.md) for private transactions. The default is `false`.
-
-### `privacy-flexible-groups-enabled`
-
-
-
-# Syntax
-
-```bash
---privacy-flexible-groups-enabled[=]
-```
-
-# Example
-
-```bash
---privacy-flexible-groups-enabled=true
-```
-
-# Environment variable
-
-```bash
-BESU_PRIVACY_FLEXIBLE_GROUPS_ENABLED=true
-```
-
-# Configuration file
-
-```bash
-privacy-flexible-groups-enabled=true
-```
-
-
-
-Enables or disables [flexible privacy groups](../../concepts/privacy/flexible-privacy.md). The default is `false`.
-
-Deprecated syntax for this option is `--privacy-onchain-groups-enabled`.
-
-### `privacy-public-key-file`
-
-
-
-# Syntax
-
-```bash
---privacy-public-key-file=
-```
-
-# Example
-
-```bash
---privacy-public-key-file=Tessera/nodeKey.pub
-```
-
-# Environment variable
-
-```bash
-BESU_PRIVACY_PUBLIC_KEY_FILE=Tessera/nodeKey.pub
-```
-
-# Configuration file
-
-```bash
-privacy-public-key-file="Tessera/nodeKey.pub"
-```
-
-
-
-The [public key of the Tessera node](https://docs.tessera.consensys.net/).
-
-:::important
-
-You cannot specify `privacy-public-key-file` when [`--privacy-multi-tenancy-enabled`](#privacy-multi-tenancy-enabled) is `true`
-
-:::
-
-### `privacy-tls-enabled`
-
-
-
-# Syntax
-
-```bash
---privacy-tls-enabled[=]
-```
-
-# Example
-
-```bash
---privacy-tls-enabled=false
-```
-
-# Environment variable
-
-```bash
-BESU_PRIVACY_TLS_ENABLED=false
-```
-
-# Configuration file
-
-```bash
-privacy-tls-enabled=false
-```
-
-
-
-Enables or disables [TLS on communication with the private transaction manager]. The default is false.
-
-### `privacy-tls-keystore-file`
-
-
-
-# Syntax
-
-```bash
---privacy-tls-keystore-file=
-```
-
-# Example
-
-```bash
---privacy--keystore-file=/home/me/me_node/key
-```
-
-# Environment variable
-
-```bash
-BESU_PRIVACY_TLS_KEYSTORE_FILE=/home/me/me_node/key
-```
-
-# Configuration file
-
-```bash
-privacy-tls-keystore-file="/home/me/me_node/key"
-```
-
-
-
-The keystore file (in PKCS #12 format) containing the private key and the certificate presented during authentication.
-
-You must specify `privacy-tls-keystore-file` if [`--privacy-tls-enabled`](#privacy-tls-enabled) is `true`.
-
-### `privacy-tls-keystore-password-file`
-
-
-
-# Syntax
-
-```bash
---privacy-tls-keystore-password-file=
-```
-
-# Example
-
-```bash
---privacy-tls-keystore-password-file=/home/me/me_node/password
-```
-
-# Environment variable
-
-```bash
-BESU_PRIVACY_TLS_KEYSTORE_PASSWORD_FILE=/home/me/me_node/password
-```
-
-# Configuration file
-
-```bash
-privacy-tls-keystore-password-file="/home/me/me_node/password"
-```
-
-
-
-The path to the file containing the password to decrypt the keystore.
-
-### `privacy-tls-known-enclave-file`
-
-
-
-# Syntax
-
-```bash
---privacy-tls-known-enclave-file=
-```
-
-# Example
-
-```bash
---privacy-tls-known-enclave-file=/home/me/me_node/knownEnclave
-```
-
-# Environment variable
-
-```bash
-BESU_PRIVACY_TLS_KNOWN_ENCLAVE_FILE=/home/me/me_node/knownEnclave
-```
-
-# Configuration file
-
-```bash
-privacy-tls-known-enclave-file="/home/me/me_node/knownEnclave"
-```
-
-
-
-The path to the file containing the hostnames, ports, and SHA256 certificate fingerprints of the [authorized privacy enclave](../../how-to/configure/tls/client-and-server.md#create-the-known-servers-file).
-
-### `privacy-url`
-
-
-
-# Syntax
-
-```bash
---privacy-url=
-```
-
-# Example
-
-```bash
---privacy-url=http://127.0.0.1:8888
-```
-
-# Environment variable
-
-```bash
-BESU_PRIVACY_URL=http://127.0.0.1:8888
-```
-
-# Configuration file
-
-```bash
-privacy-url="http://127.0.0.1:8888"
-```
-
-
-
-The URL on which the [Tessera node](../../tutorials/privacy/index.md#3-create-tessera-configuration-files) is running.
-
-
-
-[accounts permissions configuration file]: ../../how-to/use-permissioning/local.md#permissions-configuration-file
-[nodes permissions configuration file]: ../../how-to/use-permissioning/local.md#permissions-configuration-file
-[account permissioning]: ../../concepts/permissioning/index.md#account-permissioning
-[TLS on communication with the private transaction manager]: ../../concepts/privacy/index.md#private-transaction-manager
diff --git a/versioned_docs/version-23.10.0/private-networks/reference/cli/subcommands.md b/versioned_docs/version-23.10.0/private-networks/reference/cli/subcommands.md
deleted file mode 100644
index 5b8b07c4dbd..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/reference/cli/subcommands.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: Private network subcommands
-sidebar_position: 2
-description: Hyperledger Besu command line interface subcommands
-tags:
- - private networks
----
-
-# Private network subcommands
-
-This reference describes the syntax of the Hyperledger Besu private network command line interface (CLI) subcommands.
-
-:::danger
-
-This reference contains subcommands that apply to only private networks. For subcommands that apply to both private and public networks, see the [public network subcommands reference](../../../public-networks/reference/cli/subcommands.md).
-
-:::
-
-To start a Besu node using subcommands, run:
-
-```bash
-besu [OPTIONS] [SUBCOMMAND] [SUBCOMMAND OPTIONS]
-```
-
-If using Bash or Z shell, you can view subcommand suggestions by pressing the Tab key twice.
-
-```bash
-besu Tab+Tab
-```
-
-## `operator`
-
-Provides operator actions.
-
-### `generate-blockchain-config`
-
-
-
-# Syntax
-
-```bash
-besu operator generate-blockchain-config --config-file= --to= [--genesis-file-name=] [--private-key-file-name=] [--public-key-file-name=]
-```
-
-# Example
-
-```bash
-besu operator generate-blockchain-config --config-file=config.json --to=myNetworkFiles
-```
-
-
-
-Generates an [IBFT 2.0](../../how-to/configure/consensus/ibft.md#genesis-file) or [QBFT](../../how-to/configure/consensus/qbft.md#genesis-file) genesis file.
-
-The configuration file has two nested JSON nodes. The first is the `genesis` property defining the IBFT 2.0 or QBFT genesis file, except for the `extraData` string. The second is the `blockchain` property defining the number of key pairs to generate.
-
-## `rlp`
-
-Provides RLP related actions.
-
-### `encode`
-
-
-
-# Syntax
-
-```bash
-besu rlp encode [--from=] [--to=] [--type=]
-```
-
-# File example
-
- ```bash
- besu rlp encode --from=ibft_extra_data.json --to=extra_data_for_ibft_genesis.txt --type=IBFT_EXTRA_DATA
- ```
-
-# Standard input/output example
-
-```bash
-cat extra_data.json | besu rlp encode > rlp.txt
-```
-
-
-
-Encodes the RLP hexadecimal string for use in an [IBFT 2.0](../../how-to/configure/consensus/ibft.md#genesis-file) or [QBFT](../../how-to/configure/consensus/qbft.md#genesis-file) genesis file. The default type is `IBFT_EXTRA_DATA`.
-
-Supported types are:
-
-- `IBFT_EXTRA_DATA` - The IBFT 2.0 genesis file includes the `IBFT_EXTRA_DATA` type in the [`extraData`](../../how-to/configure/consensus/ibft.md#extra-data) property.
-
-- `QBFT_EXTRA_DATA` - The QBFT genesis file includes the `QBFT_EXTRA_DATA` type in the [`extraData`](../../how-to/configure/consensus/qbft.md#extra-data) property.
-
-## IBFT 2.0 extra data
-
-To generate the RLP encoded `extraData` string, specify a JSON input that is an array of validator addresses in ascending order.
-
-:::tip JSON Schema for IBFT_EXTRA_DATA
-
-Use the following JSON Schema to validate that your JSON data is well formed. To validate your JSON content, use an online validation tool, such as [JSON Schema Validator](https://www.jsonschemavalidator.net/).
-
-```json
-{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "$id": "http://org.hyperledger.besu/cli_rlp_ibft_extra_data.json",
- "type": "array",
- "definitions": {},
- "title": "IBFT extra data",
- "description": "JSON format used as input to generate an IBFT extra data RLP string",
- "items": {
- "$id": "#/address",
- "type": "string",
- "title": "Validator address",
- "description": "The validator node address",
- "default": "",
- "examples": [
- "be068f726a13c8d46c44be6ce9d275600e1735a4",
- "5ff6f4b66a46a2b2310a6f3a93aaddc0d9a1c193"
- ],
- "pattern": "^([0-9a-f]{40})$"
- }
-}
-```
-
-Example IBFT_EXTRA_DATA encoding
-
-
-
-# JSON input
-
-```json
-[
- "be068f726a13c8d46c44be6ce9d275600e1735a4",
- "5ff6f4b66a46a2b2310a6f3a93aaddc0d9a1c193"
-]
-```
-
-# RLP output
-
-```
-0xf853a00000000000000000000000000000000000000000000000000000000000000000ea94be068f726a13c8d46c44be6ce9d275600e1735a4945ff6f4b66a46a2b2310a6f3a93aaddc0d9a1c193808400000000c0
-```
-
-
diff --git a/versioned_docs/version-23.10.0/private-networks/reference/index.md b/versioned_docs/version-23.10.0/private-networks/reference/index.md
deleted file mode 100644
index 079ea80b12b..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/reference/index.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-description: private networks reference overview
-tags:
- - private networks
----
-
-# Reference
-
-This section provides reference material for private network features.
-
-The following features and resources are shared with [public networks](../../public-networks/index.md) and the content can be found in the public networks section:
-
-- Besu command line:
- - [Standard options](../../public-networks/reference/cli/options.md)
- - [Standard subcommands](../../public-networks/reference/cli/subcommands.md)
-- Besu API:
- - [Standard Besu API methods](../../public-networks/reference/api/index.md)
- - [Standard Besu API objects](../../public-networks/reference/api/objects.md)
-- [Genesis file items](../../public-networks/reference/genesis-items.md)
-- [EVM tool options](../../public-networks/reference/evm-tool.md)
-- [Transaction trace types](../../public-networks/reference/trace-types.md)
-- [Projects using Besu](../../public-networks/reference/projects-using-besu.md)
-- [Security disclosure policy](../../public-networks/reference/disclosure.md)
diff --git a/versioned_docs/version-23.10.0/private-networks/reference/plugin-api-interfaces.md b/versioned_docs/version-23.10.0/private-networks/reference/plugin-api-interfaces.md
deleted file mode 100644
index 54d4beda062..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/reference/plugin-api-interfaces.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Plugin API interfaces
-sidebar_position: 4
-description: Plugin interfaces
-tags:
- - private networks
----
-
-# Plugin API interfaces
-
-API interfaces in Hyperledger Besu allow users to [build plugins](../concepts/plugins.md) to extend Besu functionality.
-
-For more information about the available interfaces, see the [Plugin API Javadoc](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/index.html).
-
-:::note Javadoc issue
-
-The plugin API documentation is currently not being updated. We're working on a fix, but in the meantime, some links are temporarily pointing to wiki.hyperledger.org.
-
-:::
-
-## Core plugin classes
-
-The following table lists the interfaces providing core plugin classes.
-
-| Interface | Description |
-| --- | --- |
-| [**BesuContext**](https://wiki.hyperledger.org/display/BESU/BesuContext) | Allows plugins to access Besu services. |
-| [**BesuPlugin**](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/org/hyperledger/besu/plugin/BesuPlugin.html) | Used to manage the plugin lifecycle. |
-
-## Plugin services
-
-The following table lists interfaces providing services you can retrieve.
-
-| Interface | Description |
-| --- | --- |
-| [**BesuEvents**](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/org/hyperledger/besu/plugin/services/BesuEvents.html) | Allows plugins to attach to events during Besu operation. |
-| [**BesuConfiguration**](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/org/hyperledger/besu/plugin/services/BesuConfiguration.html) | Provides file system locations of Besu's storage. |
-| [**IbftQueryService**](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/org/hyperledger/besu/plugin/services/query/IbftQueryService.html) | Allows query of the IBFT 2.0 aspects of the blockchain. |
-| [**MetricCategoryRegistry**](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/org/hyperledger/besu/plugin/services/metrics/MetricCategoryRegistry.html) | Adds a new metrics category to the CLI. |
-| [**MetricsSystem**](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/org/hyperledger/besu/plugin/services/MetricsSystem.html) | Register metrics with the Prometheus endpoint. |
-| [**PoaQueryService**](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/org/hyperledger/besu/plugin/services/query/PoaQueryService.html) | Query the current state of Clique and IBFT 2.0 consensus protocols. |
-| [**PicoCLIOptions**](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/org/hyperledger/besu/plugin/services/PicoCLIOptions.html) | Adds CLI commands to the Besu command line. |
-| [**SecurityModuleService**](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/org/hyperledger/besu/plugin/services/SecurityModuleService.html) | Allows plugins to register a security module. |
-| [**StorageService**](https://javadoc.io/doc/org.hyperledger.besu/plugin-api/latest/org/hyperledger/besu/plugin/services/StorageService.html) | Allows plugins to register as a storage engine. For example, to connect to a hardware security module (HSM). |
-| [**PermissioningService**](https://wiki.hyperledger.org/display/BESU/PermissioningService) | Allows for fine grain control of node connection and node messaging permissioning. |
-| [**PrivacyPluginService**](https://wiki.hyperledger.org/display/BESU/PrivacyPluginService) | Provides a way to define how [privacy marker transactions] are created, and what private genesis to use. |
-| [**RpcEndpointService**](https://wiki.hyperledger.org/display/BESU/RpcEndpointService) | Register custom RPC endpoints. |
-
-To use the interfaces in your plugin, ensure the [Gradle build file](https://github.com/ConsenSys/PluginsAPIDemo/blob/957628b3c6f533f3c3f405e2a17e369cd1f02c31/build.gradle) contains the `https://hyperledger.jfrog.io/hyperledger/besu-maven` repository and the `plugin-api` dependency.
-
-:::warning Known issue
-
-As indicated in [issue #406](https://github.com/hyperledger/besu-docs/issues/406), plugins may need to access the parsed command line during registration, but the command line is not yet initialized at this stage.
-
-It's in our roadmap to improve lifecycle steps and provide additional visibility for some data. A workaround is to create a supplier during the `register` step and store it in memory.
-
-The `start` step can be ignored and your plugin module will be instantiated when the command line interface is parsed and available.
-
-:::
-
-[privacy marker transactions]: ../concepts/privacy/private-transactions/processing.md
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/_category_.json b/versioned_docs/version-23.10.0/private-networks/tutorials/_category_.json
deleted file mode 100644
index 25d3afe68ac..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/_category_.json
+++ /dev/null
@@ -1,8 +0,0 @@
-{
- "label": "Tutorials",
- "position": 5,
- "link": {
- "type": "generated-index",
- "slug": "private-networks/tutorials"
- }
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/azure.md b/versioned_docs/version-23.10.0/private-networks/tutorials/azure.md
deleted file mode 100644
index ab62e978fcc..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/azure.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: Deploy using Microsoft Azure
-sidebar_position: 10
-description: Deploy a private IBFT 2.0 network using Microsoft Azure.
-tags:
- - private networks
----
-
-# Deploy private network example on Azure
-
-The [Quorum Dev Quickstart on Azure Marketplace] enables deploying a private IBFT 2.0 network, which includes:
-
-- A bootnode.
-- An RPC node.
-- Three regular nodes.
-- A block explorer.
-- Prometheus and Grafana with the Besu dashboard installed.
-
-These are deployed on a single Azure VM in minutes.
-
-Once deployed, you can develop and test applications and connect to the Visual Studio Code (VSCode) plugin using the RPC endpoint `http:///jsonrpc`.
-
-## Overview
-
-The following is a high-level overview of the deployed network.
-
-![Image landing](../../assets/images/sampleNetworks-poa.png)
-
-## Deploy
-
-To deploy the private network example on Azure:
-
-1. Create a Resource Group in the [Azure Portal](https://portal.azure.com).
-
-1. Go to the [Quorum Dev Quickstart on Azure Marketplace].
-
-1. Click **Get It Now** and **Continue**. The Quickstart landing page is displayed.
-
- ![Image landing](../../assets/images/mp_0_landing.png)
-
-1. Click **Create**. The **Basics** page is displayed.
-
- ![Image basics](../../assets/images/mp_1_basics.png)
-
-1. Enter:
-
- - Details of the Resource Group you created earlier.
- - Basic user credentials to start a VM.
- - Prefix for your new VM and any other resources created.
- - Region to which you wish to deploy the VM.
-
-1. Click **Next: Size** and select the size of the VM you want to use.
-
-1. To start the deployment, click **Review + create** at the bottom left of the page.
-
- The deployment typically takes 3--5 minutes. The progress of your deployment is displayed.
-
- When the deployment is complete, the resources created are displayed.
-
-1. Click **Go to Resource**. Everything created in the deployment is displayed.
-
-1. Click on the VM name. The VM details such as the IP and DNS name are displayed. Use the IP and DNS name displayed to connect to the VM, either in browser or via RPC calls.
-
-## Block explorer
-
-To display the block explorer, open a new tab and enter either the IP of the VM or the DNS name.
-
-![Image be](../../assets/images/mp_8_block_explorer.png)
-
-## Metrics
-
-The deployment includes Prometheus metrics and Grafana with a custom Besu Dashboard installed. To display the dashboard:
-
-1. Open a new tab and enter the IP or DNS name appended with `/grafana`. For example: `http:///grafana`.
-
-1. Click on home and select the Besu dashboard.
-
- ![Grafana screenshot](../../assets/images/mp_9_grafana.png)
-
-The dashboard provides a visual way to monitor your network and nodes as the chain progresses. Alerting can also be configured.
-
-## Connect to VM RPC endpoint
-
-You can connect dapps or develop directly from the IDE by using VSCode and connecting to the VM RPC endpoint. The endpoint is the DNS name appended with `/jsonrpc`: `http:///jsonrpc`.
-
-## SSH
-
-You can SSH into the VM to see how everything is set up and working. Use the credentials from step 5 of [deployment](#deploy) and your preferred client:
-
-```bash
-ssh username@
-```
-
-To list all containers running, run `docker ps`. Find the complete setup in `/home//besu-quickstart`.
-
-![Image ssh](../../assets/images/mp_10_ssh.png)
-
-[Quorum Dev Quickstart on Azure Marketplace]: https://azuremarketplace.microsoft.com/en-us/marketplace/apps/consensys.quorum-dev-quickstart
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/clique.md b/versioned_docs/version-23.10.0/private-networks/tutorials/clique.md
deleted file mode 100644
index 5a92e40122f..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/clique.md
+++ /dev/null
@@ -1,272 +0,0 @@
----
-title: Create a Clique network
-sidebar_position: 4
-description: Create a private network using the Clique consensus protocol.
-tags:
- - private networks
----
-
-# Create a private network using Clique
-
-A private network provides a configurable network for testing. This private network uses the [Clique (proof of authority) consensus protocol].
-
-:::danger
-
-The steps in this tutorial create an isolated, but not protected or secure, Ethereum private network. We recommend running the private network behind a properly configured firewall.
-
-:::
-
-## Prerequisites
-
-- [Hyperledger Besu](../get-started/install/binary-distribution.md)
-- [Curl (or similar webservice client)](https://curl.haxx.se/download.html).
-
-## Steps
-
-Listed on the right-hand side of the page are the steps to create a private network using Clique.
-
-### 1. Create directories
-
-Each node requires a data directory for the blockchain data. When the node starts, Besu saves the [node key](../../public-networks/concepts/node-keys.md) in this directory.
-
-Create directories for your private network, each of the three nodes, and a data directory for each node:
-
-```bash
-Clique-Network/
-├── Node-1
-│ ├── data
-├── Node-2
-│ ├── data
-└── Node-3
- ├── data
-```
-
-### 2. Get the address for Node-1
-
-In Clique networks, you must include the address of at least one initial signer in the genesis file. For this Clique network, we'll use Node-1 as the initial signer. This requires obtaining the address for Node-1.
-
-To get the address for Node-1, in the `Node-1` directory, use the [`public-key export-address`](../../public-networks/reference/cli/subcommands.md#export-address) subcommand to write the node address to the specified file (`node1Address` in this example).
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data public-key export-address --to=data/node1Address
-```
-
-# Windows
-
-```bash
-besu --data-path=data public-key export-address --to=data\node1Address
-```
-
-
-
-### 3. Create the genesis file
-
-The genesis file defines the genesis block of the blockchain (that is, the start of the blockchain). The [Clique genesis file](../how-to/configure/consensus/clique.md#genesis-file) includes the address of Node-1 as the initial signer in the `extraData` field.
-
-All nodes in a network must use the same genesis file.
-
-Copy the following genesis definition to a file called `cliqueGenesis.json` and save it in the `Clique-Network` directory:
-
-```json
-{
- "config": {
- "chainId": 1337,
- "berlinBlock": 0,
- "clique": {
- "blockperiodseconds": 15,
- "epochlength": 30000
- }
- },
- "coinbase": "0x0000000000000000000000000000000000000000",
- "difficulty": "0x1",
-
- "extraData": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
- "gasLimit": "0xa00000",
- "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
- "nonce": "0x0",
- "timestamp": "0x5c51a607",
- "alloc": {
- "fe3b557e8fb62b89f4916b721be55ceb828dbd73": {
- "privateKey": "8f2a55949038a9610f50fb23b5883af3b4ecb3c3bb792cbcefbd1542c692be63",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "0xad78ebc5ac6200000"
- },
- "627306090abaB3A6e1400e9345bC60c78a8BEf57": {
- "privateKey": "c87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "90000000000000000000000"
- },
- "f17f52151EbEF6C7334FAD080c5704D77216b732": {
- "privateKey": "ae6ae8e5ccbfb04590405997ee2d52d2b330726137b875053c36d94e974d162f",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "90000000000000000000000"
- }
- }
-}
-```
-
-:::note
-
-We recommend specifying the latest [milestone](../../public-networks/reference/genesis-items.md#milestone-blocks) when creating the genesis file for a private network. This ensures you are using the most up-to-date protocol and have access to the most recent opcodes.
-
-:::
-
-In `extraData`, replace `` with the [address for Node-1](#2-get-the-address-for-node-1), excluding the 0x prefix.
-
-```json
-{
- ...
-"extraData":"0x0000000000000000000000000000000000000000000000000000000000000000b9b81ee349c3807e46bc71aa2632203c5b4620340000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
- ...
-}
-```
-
-:::warning
-
-Do not use the accounts in `alloc` in the genesis file on Mainnet or any public network except for testing. The private keys display, which means the accounts are not secure.
-
-:::
-
-### 4. Start the first node as the bootnode
-
-Start Node-1:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../cliqueGenesis.json --network-id 123 --rpc-http-enabled --rpc-http-api=ETH,NET,CLIQUE --host-allowlist="*" --rpc-http-cors-origins="all"
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\cliqueGenesis.json --network-id 123 --rpc-http-enabled --rpc-http-api=ETH,NET,CLIQUE --host-allowlist="*" --rpc-http-cors-origins="all"
-```
-
-
-
-The command line enables:
-
-- The JSON-RPC API using the [`--rpc-http-enabled`](../../public-networks/reference/cli/options.md#rpc-http-enabled) option
-- The ETH, NET, and CLIQUE APIs using the [`--rpc-http-api`](../../public-networks/reference/cli/options.md#rpc-http-api) option
-- All-host access to the HTTP JSON-RPC API using the [`--host-allowlist`](../../public-networks/reference/cli/options.md#host-allowlist) option
-- All-domain access to the node through the HTTP JSON-RPC API using the [`--rpc-http-cors-origins`](../../public-networks/reference/cli/options.md#rpc-http-cors-origins) option
-
-When the node starts, the [enode URL](../../public-networks/concepts/node-keys.md#enode-url) displays. Copy the enode URL to specify Node-1 as the bootnode in the following steps.
-
-![Node 1 Enode URL](../../assets/images/EnodeStartup.png)
-
-### 5. Start Node-2
-
-Start another terminal, change to the `Node-2` directory and start Node-2 specifying the Node-1 enode URL copied when starting Node-1 as the bootnode:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../cliqueGenesis.json --bootnodes= --network-id 123 --p2p-port=30304 --rpc-http-enabled --rpc-http-api=ETH,NET,CLIQUE --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8546
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\cliqueGenesis.json --bootnodes= --network-id 123 --p2p-port=30304 --rpc-http-enabled --rpc-http-api=ETH,NET,CLIQUE --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8546
-```
-
-
-
-The command line specifies:
-
-- A different port to Node-1 for P2P discovery using the [`--p2p-port`](../../public-networks/reference/cli/options.md#p2p-port) option.
-- A different port to Node-1 for HTTP JSON-RPC using the [`--rpc-http-port`](../../public-networks/reference/cli/options.md#rpc-http-port) option.
-- The enode URL of Node-1 using the [`--bootnodes`](../../public-networks/reference/cli/options.md#bootnodes) option.
-- The data directory for Node-2 using the [`--data-path`](../../public-networks/reference/cli/options.md#data-path) option.
-- Other options as for [Node-1](#4-start-the-first-node-as-the-bootnode).
-
-### 6. Start Node-3
-
-Start another terminal, change to the `Node-3` directory and start Node-3 specifying the Node-1 enode URL copied when starting Node-1 as the bootnode:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../cliqueGenesis.json --bootnodes= --network-id 123 --p2p-port=30305 --rpc-http-enabled --rpc-http-api=ETH,NET,CLIQUE --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8547
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\cliqueGenesis.json --bootnodes= --network-id 123 --p2p-port=30305 --rpc-http-enabled --rpc-http-api=ETH,NET,CLIQUE --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8547
-```
-
-
-
-The command line specifies:
-
-- A different port to Node-1 and Node-2 for P2P discovery using the [`--p2p-port`](../../public-networks/reference/cli/options.md#p2p-port) option.
-- A different port to Node-1 and Node-2 for HTTP JSON-RPC using the [`--rpc-http-port`](../../public-networks/reference/cli/options.md#rpc-http-port) option.
-- The data directory for Node-3 using the [`--data-path`](../../public-networks/reference/cli/options.md#data-path) option.
-- The bootnode as for [Node-2](#5-start-node-2).
-- Other options as for [Node-1](#4-start-the-first-node-as-the-bootnode).
-
-### 7. Confirm the private network is working
-
-Start another terminal, use curl to call the JSON-RPC API [`net_peerCount`](../../public-networks/reference/api/index.md#net_peercount) method and confirm the nodes are functioning as peers:
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' localhost:8545
-```
-
-The result confirms Node-1 has two peers (Node-2 and Node-3):
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x2"
-}
-```
-
-## Next steps
-
-Look at the logs displayed to confirm Node-1 is producing blocks and Node-2 and Node-3 are importing blocks.
-
-Use the [Clique API to add] Node-2 or Node-3 as a signer.
-
-:::note
-
-To add Node-2 or Node-3 as a signer you need the [node address as when specifying Node-1](#2-get-the-address-for-node-1) as the initial signer.
-
-:::
-
-Import accounts to MetaMask and send transactions, as described in the [Quickstart tutorial](quickstart.md#create-a-transaction-using-metamask).
-
-:::info
-
-Besu doesn't support [private key management](../../public-networks/how-to/send-transactions.md).
-
-:::
-
-## Stop the nodes
-
-When finished using the private network, stop all nodes using ++ctrl+c++ in each terminal window.
-
-:::tip
-
-To restart the Clique network in the future, start from [4. Start First Node as Bootnode](#4-start-the-first-node-as-the-bootnode).
-
-:::
-
-
-
-[Clique (proof of authority) consensus protocol]: ../how-to/configure/consensus/clique.md
-[Clique API to add]: ../how-to/configure/consensus/clique.md#add-and-remove-signers
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/_category_.json b/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/_category_.json
deleted file mode 100644
index 3ba8177fcc1..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Deploy a smart contract",
- "position": 8
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/index.md b/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/index.md
deleted file mode 100644
index 2b7d7f039cc..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/index.md
+++ /dev/null
@@ -1,275 +0,0 @@
----
-title: Deploy a smart contract
-sidebar_position: 1
-description: deploying smart contracts
-tags:
- - private networks
----
-
-# Deploy smart contracts to an Ethereum chain
-
-This tutorial shows you how to deploy smart contracts as transactions to a network.
-
-## Prerequisites
-
-This tutorial requires a local blockchain network. You can use the [Developer Quickstart](../quickstart.md) to rapidly generate one. If deploying a private contract, enable privacy on the network (public contracts can also be deployed on privacy-enabled networks).
-
-## Use `eth_sendSignedTransaction`
-
-To deploy a smart contract using [`eth_sendSignedTransaction`](https://web3js.readthedocs.io/en/v1.2.0/web3-eth.html#sendsignedtransaction), use an account's private key to sign and serialize the transaction, and send the API request.
-
-This example uses the [web3js](https://www.npmjs.com/package/web3) library to make the API calls.
-
-Using the [`SimpleStorage.sol`](https://github.com/ConsenSys/quorum-dev-quickstart/blob/1e8cc281098923802845cd829ec20c88513c2e1c/files/common/smart_contracts/privacy/contracts/SimpleStorage.sol) smart contract as an example, create a new file called `compile.js` with the following content:
-
-```js title="compile.js"
-const fs = require("fs").promises;
-const solc = require("solc");
-
-async function main() {
- // Load the contract source code
- const sourceCode = await fs.readFile("SimpleStorage.sol", "utf8");
- // Compile the source code and retrieve the ABI and bytecode
- const { abi, bytecode } = compile(sourceCode, "SimpleStorage");
- // Store the ABI and bytecode into a JSON file
- const artifact = JSON.stringify({ abi, bytecode }, null, 2);
- await fs.writeFile("SimpleStorage.json", artifact);
-}
-
-function compile(sourceCode, contractName) {
- // Create the Solidity Compiler Standard Input and Output JSON
- const input = {
- language: "Solidity",
- sources: { main: { content: sourceCode } },
- settings: { outputSelection: { "*": { "*": ["abi", "evm.bytecode"] } } },
- };
- // Parse the compiler output to retrieve the ABI and bytecode
- const output = solc.compile(JSON.stringify(input));
- const artifact = JSON.parse(output).contracts.main[contractName];
- return {
- abi: artifact.abi,
- bytecode: artifact.evm.bytecode.object,
- };
-}
-
-main().then(() => process.exit(0));
-```
-
-Run `compile.js` to get the smart contract's output JSON:
-
-```bash
-node compile.js
-```
-
-Run `solc` to get the contract's bytecode and ABI:
-
-```bash
-solc SimpleStorage.sol --bin --abi
-```
-
-Once you have the bytecode and ABI, you can rename the output files to make them easier to use; this tutorial refers to them as `SimpleStorage.bin` and `SimpleStorage.abi`.
-
-Create a new file named `public_tx.js` to send the transaction (or run the following commands in a JavaScript console). The Developer Quickstart provides an [example of a public transaction script](https://github.com/ConsenSys/quorum-dev-quickstart/blob/1e8cc281098923802845cd829ec20c88513c2e1c/files/besu/smart_contracts/privacy/scripts/public_tx.js).
-
-```js titl="public_tx.js"
-const web3 = new Web3(host);
-// use an existing account, or make an account
-const privateKey =
- "0x8f2a55949038a9610f50fb23b5883af3b4ecb3c3bb792cbcefbd1542c692be63";
-const account = web3.eth.accounts.privateKeyToAccount(privateKey);
-
-// read in the contracts
-const contractJsonPath = path.resolve(__dirname, "SimpleStorage.json");
-const contractJson = JSON.parse(fs.readFileSync(contractJsonPath));
-const contractAbi = contractJson.abi;
-const contractBinPath = path.resolve(__dirname, "SimpleStorage.bin");
-const contractBin = fs.readFileSync(contractBinPath);
-// initialize the default constructor with a value `47 = 0x2F`; this value is appended to the bytecode
-const contractConstructorInit =
- "000000000000000000000000000000000000000000000000000000000000002F";
-
-// get txnCount for the nonce value
-const txnCount = await web3.eth.getTransactionCount(account.address);
-
-const rawTxOptions = {
- nonce: web3.utils.numberToHex(txnCount),
- from: account.address,
- to: null, //public tx
- value: "0x00",
- data: "0x" + contractBin + contractInit, // contract binary appended with initialization value
- gasPrice: "0x0", //ETH per unit of gas
- gasLimit: "0x24A22", //max number of gas units the tx is allowed to use
-};
-console.log("Creating transaction...");
-const tx = new Tx(rawTxOptions);
-console.log("Signing transaction...");
-tx.sign(privateKey);
-console.log("Sending transaction...");
-var serializedTx = tx.serialize();
-const pTx = await web3.eth.sendSignedTransaction(
- "0x" + serializedTx.toString("hex").toString("hex"),
-);
-console.log("tx transactionHash: " + pTx.transactionHash);
-console.log("tx contractAddress: " + pTx.contractAddress);
-```
-
-`rawTxOptions` contains the following fields:
-
-- `nonce` - the number of transactions sent from an address.
-- `from` - address of the sending account. For example `0xfe3b557e8fb62b89f4916b721be55ceb828dbd73`.
-- `to` - address of the receiver. To deploy a contract, set to `null`.
-- `gas` - amount of gas provided by the sender for the transaction.
-- `gasPrice` - price for each unit of gas the sender is willing to pay.
-- `data` - binary of the contract (in this example there's also a constructor initialization value, so we append that to the binary value).
-- `value` - amount of Ether/Wei transferred from the sender to the recipient.
-
-Run the `public_tx.js` to send the transaction:
-
-```bash
-node public_tx.js
-```
-
-This example code creates the transaction `tx`, signs it with the private key of the account, serializes it, then calls `eth_sendSignedTransaction` to deploy the contract.
-
-## Use `eth_sendTransaction`
-
-You can use [`eth_sendTransaction`](https://ethereum.github.io/execution-apis/api-documentation) as an alternative to `eth_sendSignedTransaction`. However, Hyperledger Besu does not support the `eth_sendTransaction` API call and keeps account management separate for stronger security. Configure [EthSigner](https://docs.ethsigner.consensys.net/en/stable/) with your Besu node to make the `eth_sendTransaction` API call.
-
-An example can be found in the [Developer Quickstart](../quickstart.md) where the RPC node is paired with EthSigner. Refer to the [EthSigner documentation](https://docs.ethsigner.consensys.net/) for configuration details.
-
-Pass the following parameters to the [`eth_sendTransaction`](https://docs.ethsigner.consensys.net/Reference/API-Methods/#eth_sendtransaction) call to EthSigner; EthSigner then converts the request to an [`eth_sendRawTransaction`](../../../public-networks/reference/api/index.md#eth_sendrawtransaction) call that Besu uses:
-
-- `to` - address of the receiver. To deploy a contract, set to `null`.
-- `from` - address of the sender account. For example `0x9b790656b9ec0db1936ed84b3bea605873558198`.
-- `gas` - amount of gas provided by the sender for the transaction
-- `gasPrice` - price for each unit of gas the sender is willing to pay
-- `data` - one of the following:
- - For contract deployments (this use case) - compiled code of the contract
- - For contract interactions - hash of the invoked method signature and encoded parameters (see [Ethereum Contract ABI](https://solidity.readthedocs.io/en/develop/abi-spec.html))
- - For simple ether transfers - empty
-
-```json title="'eth_sendTransaction' parameters"
-params: {
- "to": null,
- "from": "0x9b790656b9ec0db1936ed84b3bea605873558198",
- "gas": "0x76c0",
- "gasPrice": "0x9184e72a000",
- "data": "0x608060405234801561001057600080fd5b5060405161014d38038061014d8339818101604052602081101561003357600080fd5b8101908080519060200190929190505050806000819055505060f38061005a6000396000f3fe6080604052348015600f57600080fd5b5060043610603c5760003560e01c80632a1afcd914604157806360fe47b114605d5780636d4ce63c146088575b600080fd5b604760a4565b6040518082815260200191505060405180910390f35b608660048036036020811015607157600080fd5b810190808035906020019092919050505060aa565b005b608e60b4565b6040518082815260200191505060405180910390f35b60005481565b8060008190555050565b6000805490509056fea2646970667358221220e6966e446bd0af8e6af40eb0d8f323dd02f771ba1f11ae05c65d1624ffb3c58264736f6c63430007060033"
-}
-```
-
-Make the request using `eth_sendTransaction`:
-
-```bash title="'eth_sendTransaction' curl HTTP request"
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{"from":"0x9b790656b9ec0db1936ed84b3bea605873558198", "to":null, "gas":"0x7600","gasPrice":"0x9184e72a000", "data":"0x608060405234801561001057600080fd5b5060405161014d38038061014d8339818101604052602081101561003357600080fd5b8101908080519060200190929190505050806000819055505060f38061005a6000396000f3fe6080604052348015600f57600080fd5b5060043610603c5760003560e01c80632a1afcd914604157806360fe47b114605d5780636d4ce63c146088575b600080fd5b604760a4565b6040518082815260200191505060405180910390f35b608660048036036020811015607157600080fd5b810190808035906020019092919050505060aa565b005b608e60b4565b6040518082815260200191505060405180910390f35b60005481565b8060008190555050565b6000805490509056fea2646970667358221220e6966e446bd0af8e6af40eb0d8f323dd02f771ba1f11ae05c65d1624ffb3c58264736f6c63430007060033"}], "id":1}'
-```
-
-## Use `eea_sendRawTransaction` for private contracts with web3js-quorum
-
-To deploy a private contract to another node or [privacy group](../../concepts/privacy/privacy-groups.md) member, use the [web3js-quorum](https://www.npmjs.com/package/web3js-quorum) library and the [`eea_sendRawTransaction`](../../../public-networks/reference/api/index.md#eea_sendrawtransaction) API call. You must use this API call instead of [`eth_sendTransaction`](https://ethereum.github.io/execution-apis/api-documentation) because Hyperledger Besu keeps account management separate for stronger security.
-
-The Developer Quickstart provides an [example of a private transaction script](https://github.com/ConsenSys/quorum-dev-quickstart/blob/1e8cc281098923802845cd829ec20c88513c2e1c/files/besu/smart_contracts/privacy/scripts/private_tx.js).
-
-This example uses the [web3js](https://www.npmjs.com/package/web3) library to make the API calls.
-
-Use [`web3.priv.generateAndSendRawTransaction`](https://consensys.github.io/web3js-quorum/latest/module-priv.html#~generateAndSendRawTransaction) by running the following commands in a JavaScript console, or by including them in a `private_tx.js` file and running `node private_tx.js`:
-
-```js title="'private_tx.js' using 'web3.priv.generateAndSendRawTransaction'"
-const Web3 = require("web3");
-const Web3Quorum = require("web3js-quorum");
-
-const bytecode =
- "608060405234801561001057600080fd5b5060405161014d38038061014d8339818101604052602081101561003357600080fd5b8101908080519060200190929190505050806000819055505060f38061005a6000396000f3fe6080604052348015600f57600080fd5b5060043610603c5760003560e01c80632a1afcd914604157806360fe47b114605d5780636d4ce63c146088575b600080fd5b604760a4565b6040518082815260200191505060405180910390f35b608660048036036020811015607157600080fd5b810190808035906020019092919050505060aa565b005b608e60b4565b6040518082815260200191505060405180910390f35b60005481565b8060008190555050565b6000805490509056fea2646970667358221220e6966e446bd0af8e6af40eb0d8f323dd02f771ba1f11ae05c65d1624ffb3c58264736f6c63430007060033";
-// initialize the default constructor with a value `47 = 0x2F`; this value is appended to the bytecode
-const contractConstructorInit =
- "000000000000000000000000000000000000000000000000000000000000002F";
-
-const chainId = 1337;
-const web3 = new Web3(clientUrl);
-const web3quorum = new Web3Quorum(web3, chainId);
-
-const txOptions = {
- data: "0x" + bytecode + contractConstructorInit,
- privateKey: fromPrivateKey,
- privateFrom: fromPublicKey,
- privateFor: [toPublicKey],
-};
-console.log("Creating contract...");
-const txHash = await web3quorum.priv.generateAndSendRawTransaction(txOptions);
-console.log("Getting contractAddress from txHash: ", txHash);
-
-const privateTxReceipt = await web3quorum.priv.waitForTransactionReceipt(
- txHash,
-);
-console.log("Private Transaction Receipt: ", privateTxReceipt);
-return privateTxReceipt;
-```
-
-`txOptions` contains the following field:
-
-- `data` - compiled code of the contract (in this example there's also a constructor initialization value, so we append that to the bytecode).
-
-The deployment process includes creating the client as in the previous examples, but rather than deploying the contract with `to: null`, it instead sends the transaction with `privateFor: [memberPublicKey/s]`. Once you make the API call, you receive a `transactionHash`, which you can use to get a `transactionReceipt` containing the contract's address.
-
-:::note
-
-This example doesn't use a privacy group and makes a simple node-to-node transaction. To use a privacy group:
-
-- Create the privacy group using the public keys of the nodes in the group.
-- Specify the `privacyGroupId` instead of the `privateFor` option in the txOptions above and then send the transaction.
-
-The Developer Quickstart provides an [example of a private transaction with a privacy group](https://github.com/ConsenSys/quorum-dev-quickstart/blob/b72a0f64d685c851bf8be399a8e33bbdf0e09982/files/besu/smart_contracts/privacy/scripts/private_tx_privacy_group.js).
-
-:::
-
-## Use `eea_sendRawTransaction` for private contracts with web3js-eea
-
-:::warning
-
-This web3js-eea library will be deprecated on December 31, 2021. Please use the [web3js-quorum](https://www.npmjs.com/package/web3js-quorum) library instead and refer to the previous section.
-
-:::
-
-To deploy a private contract to another [privacy group](../../concepts/privacy/privacy-groups.md) member, use the [web3js-quorum](https://consensys.github.io/web3js-quorum/latest/index.html) library and the [`eea_sendRawTransaction`](../../../public-networks/reference/api/index.md#eea_sendrawtransaction) API call. You must use this API call instead of [`eth_sendTransaction`](https://ethereum.github.io/execution-apis/api-documentation) because Hyperledger Besu keeps account management separate for stronger security.
-
-The Developer Quickstart provides an [example of a private transaction script](https://github.com/ConsenSys/quorum-dev-quickstart/blob/1e8cc281098923802845cd829ec20c88513c2e1c/files/besu/smart_contracts/privacy/scripts/private_tx.js).
-
-This example uses the [web3js](https://www.npmjs.com/package/web3) library to make the API calls.
-
-Use `eea_sendRawTransaction` by running the following commands in a JavaScript console, or by including them in a `private_tx.js` file and running `node private_tx.js`:
-
-```js title="'private_tx.js' using 'eea_sendRawTransaction'"
-const Web3 = require("web3");
-const EEAClient = require("web3-eea");
-
-const bytecode =
- "608060405234801561001057600080fd5b5060405161014d38038061014d8339818101604052602081101561003357600080fd5b8101908080519060200190929190505050806000819055505060f38061005a6000396000f3fe6080604052348015600f57600080fd5b5060043610603c5760003560e01c80632a1afcd914604157806360fe47b114605d5780636d4ce63c146088575b600080fd5b604760a4565b6040518082815260200191505060405180910390f35b608660048036036020811015607157600080fd5b810190808035906020019092919050505060aa565b005b608e60b4565b6040518082815260200191505060405180910390f35b60005481565b8060008190555050565b6000805490509056fea2646970667358221220e6966e446bd0af8e6af40eb0d8f323dd02f771ba1f11ae05c65d1624ffb3c58264736f6c63430007060033";
-// initialize the default constructor with a value `47 = 0x2F`; this value is appended to the bytecode
-const contractConstructorInit =
- "000000000000000000000000000000000000000000000000000000000000002F";
-
-const web3 = new Web3(clientUrl);
-const web3eea = new EEAClient(web3, 1337);
-const txOptions = {
- data: "0x" + bytecode + contractConstructorInit,
- privateKey: fromPrivateKey,
- privateFrom: fromPublicKey,
- privateFor: [toPublicKey],
-};
-console.log("Creating contract...");
-const txHash = await web3eea.eea.sendRawTransaction(txOptions);
-console.log("Getting contractAddress from txHash: ", txHash);
-
-const privateTxReceipt = await web3.priv.getTransactionReceipt(
- txHash,
- fromPublicKey,
-);
-// console.log("Private Transaction Receipt: ", privateTxReceipt);
-return privateTxReceipt;
-```
-
-`txOptions` contains the following field:
-
-- `data` - compiled code of the contract (in this example there's also a constructor initialization value, so we append that to the bytecode).
-
-The deployment process includes creating the client as in the previous examples, but rather than deploying the contract with `to: null`, it instead sends the transaction with `privateFor: [memberPublicKey/s]`. Once you make the API call, you receive a `transactionHash`, which you can use to get a `transactionReceipt` containing the contract's address.
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/interact.md b/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/interact.md
deleted file mode 100644
index 11da4b07e28..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/interact.md
+++ /dev/null
@@ -1,194 +0,0 @@
----
-title: Interact with a deployed contract
-sidebar_position: 2
-description: calling smart contracts functions
-tags:
- - private networks
----
-
-# Interact with deployed smart contracts
-
-You can get started with the [Developer Quickstart](../quickstart.md) to rapidly generate local blockchain networks.
-
-This tutorial shows you how to interact with smart contracts that have been deployed to a network.
-
-## Prerequisites
-
-- A network with a deployed smart contract as in the [deploying smart contracts tutorial](index.md)
-
-## Interact with public contracts
-
-This tutorial uses the [`SimpleStorage.sol`](https://github.com/ConsenSys/quorum-dev-quickstart/blob/1e8cc281098923802845cd829ec20c88513c2e1c/files/common/smart_contracts/privacy/contracts/SimpleStorage.sol) contract:
-
-```js
-pragma solidity ^0.7.0;
-
-contract SimpleStorage {
- uint public storedData;
-
- constructor(uint initVal) public {
- storedData = initVal;
- }
-
- function set(uint x) public {
- storedData = x;
- }
-
- function get() view public returns (uint retVal) {
- return storedData;
- }
-}
-```
-
-Once the contract is deployed, you can perform a read operation using the `get` function call and a write operation using the `set` function call. This tutorial uses the [web3js](https://www.npmjs.com/package/web3) library to interact with the contract. A [full example](https://github.com/ConsenSys/quorum-dev-quickstart/blob/1e8cc281098923802845cd829ec20c88513c2e1c/files/besu/smart_contracts/privacy/scripts/public_tx.js) of these calls can be found in the [Developer Quickstart].
-
-### 1. Perform a read operation
-
-To perform a read operation, you need the address that the contract was deployed to and the contract's ABI. The contract's ABI can be obtained from compiling the contract; see the [deploying smart contracts tutorial](index.md) for an example.
-
-Use the [`web3.eth.Contract`](https://web3js.readthedocs.io/en/v1.3.4/web3-eth-contract.html) object to create a new instance of the smart contract, then make the `get` function call from the contract's list of methods, which will return the value stored:
-
-```js
-async function getValueAtAddress(
- host,
- deployedContractAbi,
- deployedContractAddress,
-) {
- const web3 = new Web3(host);
- const contractInstance = new web3.eth.Contract(
- deployedContractAbi,
- deployedContractAddress,
- );
- const res = await contractInstance.methods.get().call();
- console.log("Obtained value at deployed contract is: " + res);
- return res;
-}
-```
-
-### 2. Perform a write operation
-
-To perform a write operation, send a transaction to update the stored value. As with the [`get` call](#1-perform-a-read-operation), you need to use the address that the contract was deployed to and the contract's ABI. The account address must correspond to an actual account with some ETH in it to perform the transaction. Because Besu doesn't manage accounts, this address is the address you use in [EthSigner](https://docs.ethsigner.consensys.net/en/stable/) (or equivalent) to manage your accounts.
-
-Make the `set` call passing in your account address, `value` as the updated value of the contract, and the amount of gas you are willing to spend for the transaction:
-
-```js
-// You need to use the accountAddress details provided to Besu to send/interact with contracts
-async function setValueAtAddress(
- host,
- accountAddress,
- value,
- deployedContractAbi,
- deployedContractAddress,
-) {
- const web3 = new Web3(host);
- const contractInstance = new web3.eth.Contract(
- deployedContractAbi,
- deployedContractAddress,
- );
- const res = await contractInstance.methods
- .set(value)
- .send({ from: accountAddress, gasPrice: "0xFF", gasLimit: "0x24A22" });
- return res;
-}
-```
-
-### 3. Verify an updated value
-
-To verify that a value has been updated, perform a `get` call after a `set` update call.
-
-## Interact with private contracts
-
-This private contracts example uses the same `SimpleStorage.sol` contract as in the [public contracts example](#interact-with-public-contracts), but it uses the [web3js-quorum](https://consensys.github.io/web3js-quorum/latest/index.html) library and the [`generateAndSendRawTransaction`](https://consensys.github.io/web3js-quorum/latest/module-priv.html#~generateAndSendRawTransaction) method to interact with the contract. Both read and write operations are performed using the `generateAndSendRawTransaction` API call. A [full example](https://github.com/ConsenSys/quorum-dev-quickstart/blob/1e8cc281098923802845cd829ec20c88513c2e1c/files/besu/smart_contracts/privacy/scripts/private_tx.js) can be found in the [Developer Quickstart].
-
-### 1. Perform a read operation
-
-As in the public contracts example, to perform a read operation, you need the address that the contract was deployed to and the contract's ABI. You also need your private and public keys and the recipient's public key.
-
-Use the [`web3.eth.Contract`](https://web3js.readthedocs.io/en/v1.3.4/web3-eth-contract.html) object to create a new instance of the smart contract, extract the signature of function's ABI for the `get` method, and then use this value as the `data` parameter for the `generateAndSendRawTransaction` transaction.
-
-The keys remain the same for the sender and recipient, and the `to` field is the contract's address. Once you make the request, you receive a `transactionHash`, which you can use to get a `transactionReceipt` containing the value stored:
-
-```js
-async function getValueAtAddress(
- clientUrl,
- address,
- contractAbi,
- fromPrivateKey,
- fromPublicKey,
- toPublicKey,
-) {
- const Web3 = require("web3");
- const Web3Quorum = require("web3js-quorum");
- const web3 = new Web3Quorum(new Web3("http://localhost:22000"));
- // eslint-disable-next-line no-underscore-dangle
- const functionAbi = contract._jsonInterface.find((e) => {
- return e.name === "get";
- });
- const functionParams = {
- to: address,
- data: functionAbi.signature,
- privateKey: fromPrivateKey,
- privateFrom: fromPublicKey,
- privateFor: [toPublicKey],
- };
- const transactionHash = await web3quorum.priv.generateAndSendRawTransaction(
- functionParams,
- );
- // console.log(`Transaction hash: ${transactionHash}`);
- const result = await web3quorum.priv.waitForTransactionReceipt(
- transactionHash,
- );
- console.log(
- "" + nodeName + " value from deployed contract is: " + result.output,
- );
- return result;
-}
-```
-
-### 2. Perform a write operation
-
-Performing a write operation is almost the same process as the read operation, except that you encode the new value to the `set` function's ABI, and then append these arguments to the `set` function's ABI and use this as the `data` field:
-
-```js
-async function setValueAtAddress(
- clientUrl,
- address,
- value,
- contractAbi,
- fromPrivateKey,
- fromPublicKey,
- toPublicKey,
-) {
- const Web3 = require("web3");
- const Web3Quorum = require("web3js-quorum");
- const web3 = new Web3Quorum(new Web3("http://localhost:22000"));
- // eslint-disable-next-line no-underscore-dangle
- const functionAbi = contract._jsonInterface.find((e) => {
- return e.name === "set";
- });
- const functionArgs = web3quorum.eth.abi
- .encodeParameters(functionAbi.inputs, [value])
- .slice(2);
- const functionParams = {
- to: address,
- data: functionAbi.signature + functionArgs,
- privateKey: fromPrivateKey,
- privateFrom: fromPublicKey,
- privateFor: [toPublicKey],
- };
- const transactionHash = await web3quorum.priv.generateAndSendRawTransaction(
- functionParams,
- );
- console.log(`Transaction hash: ${transactionHash}`);
- const result = await web3quorum.priv.waitForTransactionReceipt(
- transactionHash,
- );
- return result;
-}
-```
-
-### 3. Verify an updated value
-
-To verify that a value has been updated, perform a `get` call after a `set` update call.
-
-[Developer Quickstart]: ../quickstart.md
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/transfer-funds.md b/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/transfer-funds.md
deleted file mode 100644
index d2ae16ca8f4..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/contracts/transfer-funds.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-title: Transfer account funds
-sidebar_position: 1
-description: funds transfer transactions
-tags:
- - private networks
----
-
-# Transfer funds between accounts in a transaction
-
-You can get started with the [Developer Quickstart](../quickstart.md) to rapidly generate local blockchain networks.
-
-This tutorial shows you how to transfer funds (ETH) between accounts in a transaction.
-
-## Prerequisites
-
-- A [private network](../quickstart.md)
-
-## Use `eth_sendSignedTransaction`
-
-The simplest way to transfer funds between externally-owned accounts is using [`eth_sendSignedTransaction`](https://web3js.readthedocs.io/en/v1.2.11/web3-eth.html#sendsignedtransaction). This example uses `eth_sendSignedTransaction` and one of the [test accounts](../../reference/accounts-for-testing.md) to transfer funds to a newly created account.
-
-:::danger Do not use the test accounts on Ethereum Mainnet or any production network
-
-The private key is publicly displayed, which means the account is not secure.
-
-:::
-
-Before making the transaction, check the balances of both accounts to verify the funds transfer after the transaction.
-
-```js
-const web3 = new Web3(host);
-// Pre-seeded account with 90000 ETH
-const privateKeyA =
- "0xc87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3";
-const accountA = web3.eth.accounts.privateKeyToAccount(privateKeyA);
-var accountABalance = web3.utils.fromWei(
- await web3.eth.getBalance(accountA.address),
-);
-console.log("Account A has balance of: " + accountABalance);
-
-// Create a new account to transfer ETH to
-var accountB = web3.eth.accounts.create();
-var accountBBalance = web3.utils.fromWei(
- await web3.eth.getBalance(accountB.address),
-);
-console.log("Account B has balance of: " + accountBBalance);
-```
-
-Use the test account address (Account A) for the `from` parameter, the recipient account address (Account B) for the `to` parameter, and the amount of ETH to transfer between accounts for the `value` parameter. Sign the transaction with Account A's private key and send it using `eth_sendSignedTransaction`.
-
-```js
-// Send some ETH from A to B
-const rawTxOptions = {
- nonce: web3.utils.numberToHex(
- await web3.eth.getTransactionCount(accountA.address),
- ),
- from: accountA.address,
- to: accountB.address,
- value: "0x100", // Amount of ETH to transfer
- gasPrice: "0x0", // ETH per unit of gas
- gasLimit: "0x24A22", // Max number of gas units the tx is allowed to use
-};
-console.log("Creating transaction...");
-const tx = new Tx(rawTxOptions);
-console.log("Signing transaction...");
-tx.sign(Buffer.from(accountA.privateKey.substring(2), "hex"));
-console.log("Sending transaction...");
-var serializedTx = tx.serialize();
-const pTx = await web3.eth.sendSignedTransaction(
- "0x" + serializedTx.toString("hex").toString("hex"),
-);
-console.log("tx transactionHash: " + pTx.transactionHash);
-```
-
-Once it completes, you can see the updated balances.
-
-```js
-// After the transaction, there should be some ETH transferred
-var accountABalance = await getAccountBalance(host, accountA);
-console.log("Account A has an updated balance of: " + accountABalance);
-var accountBBalance = await getAccountBalance(host, accountB);
-console.log("Account B has an updatedbalance of: " + accountBBalance);
-}
-```
-
-A [full example](https://github.com/ConsenSys/quorum-dev-quickstart/blob/1e8cc281098923802845cd829ec20c88513c2e1c/files/besu/smart_contracts/privacy/scripts/eth_tx.js) can be found in the Developer Quickstart.
-
-## Use `eth_sendTransaction`
-
-An alternative to using `eth_sendSignedTransaction` is [`eth_sendTransaction`](https://web3js.readthedocs.io/en/v1.2.11/web3-eth.html#sendtransaction). However, Hyperledger Besu does not support the `eth_sendTransaction` API call and keeps account management separate for stronger security. Instead, Besu uses [EthSigner](https://docs.ethsigner.consensys.net/en/stable/) to make the `eth_sendTransaction` API call.
-
-An example can be found in the [Developer Quickstart](../quickstart.md) where the RPC node is paired with EthSigner. Refer to the [EthSigner documentation](https://docs.ethsigner.consensys.net/en/stable/) configuration details.
-
-Use `eth_sendTransaction` similarly to [using `eth_sendSignedTransaction`](#use-eth_sendsignedtransaction) (without the signing step which is done by EthSigner):
-
-```js
-const web3 = new Web3(host);
-// Pre-seeded account with 90000 ETH
-const privateKeyA = "0xc87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3";
-const accountA = web3.eth.accounts.privateKeyToAccount(privateKeyA);
-var accountABalance = web3.utils.fromWei(await web3.eth.getBalance(accountA.address));
-console.log("Account A has balance of: " + accountABalance);
-
-// Create a new account to transfer ETH to
-var accountB = web3.eth.accounts.create();
-var accountBBalance = web3.utils.fromWei(await web3.eth.getBalance(accountB.address));
-console.log("Account B has balance of: " + accountBBalance);
-
-// Send some ETH from A to B
-const txOptions = {
- from: accountA.address,
- to: accountB.address,
- value: "0x100", // Amount of ETH to transfer
- gasPrice: "0x0", // ETH per unit of gas
- gasLimit: "0x24A22" // Max number of gas units the tx is allowed to use
-};
-console.log("Creating transaction...");
-const pTx = await web3.eth.sendTransaction(txOptions);
-console.log("tx transactionHash: " + pTx.transactionHash);
-
-// After the transaction, there should be some ETH transferred
-var accountABalance = await getAccountBalance(host, accountA);
-console.log("Account A has an updated balance of: " + accountABalance);
-var accountBBalance = await getAccountBalance(host, accountB);
-console.log("Account B has an updatedbalance of: " + accountBBalance);
-}
-```
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/ethash.md b/versioned_docs/version-23.10.0/private-networks/tutorials/ethash.md
deleted file mode 100644
index ea464438383..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/ethash.md
+++ /dev/null
@@ -1,225 +0,0 @@
----
-title: Create an Ethash network
-sidebar_position: 5
-description: Create a private network using the Ethash consensus protocol.
-tags:
- - private networks
----
-
-# Create a private network using Ethash
-
-A private network provides a configurable network for testing. By configuring a low difficulty and enabling mining, this allows for fast block creation.
-
-You can test multi-block and multi-user scenarios on a private network before moving to one of the public testnets.
-
-:::danger
-
-The steps in this tutorial create an isolated, but not protected or secure, Ethereum private network. We recommend running the private network behind a properly configured firewall.
-
-:::
-
-## Prerequisites
-
-- [Hyperledger Besu](../get-started/install/binary-distribution.md)
-- [Curl (or similar webservice client)](https://curl.haxx.se/download.html).
-
-## Steps
-
-Listed on the right-hand side of the page are the steps to create a private network using Ethash.
-
-### 1. Create directories
-
-Each node requires a data directory for the blockchain data. When the node starts, Besu saves the [node key](../../public-networks/concepts/node-keys.md) in this directory.
-
-Create directories for your private network, each of the three nodes, and a data directory for each node:
-
-```bash
-Private-Network/
-├── Node-1
-│ ├── data
-├── Node-2
-│ ├── data
-└── Node-3
- ├── data
-```
-
-### 2. Create a genesis file
-
-The genesis file defines the genesis block of the blockchain (that is, the start of the blockchain). The genesis file includes entries for configuring the blockchain, such as the mining difficulty and initial accounts and balances.
-
-All nodes in a network must use the same genesis file. The [network ID](../../public-networks/concepts/network-and-chain-id.md) defaults to the `chainID` in the genesis file. The `fixeddifficulty` enables fast block mining.
-
-Copy the following genesis definition to a file called `privateNetworkGenesis.json` and save it in the `Private-Network` directory:
-
-```json
-{
- "config": {
- "berlinBlock": 0,
- "ethash": {
- "fixeddifficulty": 1000
- },
- "chainID": 1337
- },
- "nonce": "0x42",
- "gasLimit": "0x1000000",
- "difficulty": "0x10000",
- "alloc": {
- "fe3b557e8fb62b89f4916b721be55ceb828dbd73": {
- "privateKey": "8f2a55949038a9610f50fb23b5883af3b4ecb3c3bb792cbcefbd1542c692be63",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "0xad78ebc5ac6200000"
- },
- "f17f52151EbEF6C7334FAD080c5704D77216b732": {
- "privateKey": "ae6ae8e5ccbfb04590405997ee2d52d2b330726137b875053c36d94e974d162f",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "90000000000000000000000"
- }
- }
-}
-```
-
-:::note
-
-We recommend specifying the latest [milestone](../../public-networks/reference/genesis-items.md#milestone-blocks) when creating the genesis file for a private network. This ensures you are using the most up-to-date protocol and have access to the most recent opcodes.
-
-:::
-
-:::warning
-
-Don't use the accounts in `alloc` in the genesis file on Mainnet or any public network except for testing. The private keys display, which means the accounts are not secure.
-
-:::
-
-### 3. Start the first node as a bootnode
-
-Start Node-1:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../privateNetworkGenesis.json --miner-enabled --miner-coinbase fe3b557e8fb62b89f4916b721be55ceb828dbd73 --rpc-http-enabled --host-allowlist="*" --rpc-http-cors-origins="all"
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\privateNetworkGenesis.json --miner-enabled --miner-coinbase fe3b557e8fb62b89f4916b721be55ceb828dbd73 --rpc-http-enabled --host-allowlist="*" --rpc-http-cors-origins="all"
-```
-
-
-
-The command line enables:
-
-- Mining and specifies the account to pay mining rewards to using the [`--miner-enabled`](../../public-networks/reference/cli/options.md#miner-enabled) and [`--miner-coinbase`](../../public-networks/reference/cli/options.md#miner-coinbase) options.
-- JSON-RPC API using the [`--rpc-http-enabled`](../../public-networks/reference/cli/options.md#rpc-http-enabled) option.
-- All-host access to the HTTP JSON-RPC API using the [`--host-allowlist`](../../public-networks/reference/cli/options.md#host-allowlist) option.
-- All-domain access to the node through the HTTP JSON-RPC API using the [`--rpc-http-cors-origins`](../../public-networks/reference/cli/options.md#rpc-http-cors-origins) option.
-
-:::info
-
-The miner coinbase account is one of the accounts defined in the genesis file.
-
-:::
-
-When the node starts, the [enode URL](../../public-networks/concepts/node-keys.md#enode-url) displays. Copy the enode URL to specify Node-1 as the bootnode in the following steps.
-
-![Node 1 Enode URL](../../assets/images/EnodeStartup.png)
-
-### 4. Start Node-2
-
-Start another terminal, change to the `Node-2` directory and start Node-2 specifying the Node-1 enode URL copied when starting Node-1 as the bootnode:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../privateNetworkGenesis.json --bootnodes= --p2p-port=30304
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\privateNetworkGenesis.json --bootnodes= --p2p-port=30304
-```
-
-
-
-The command line specifies:
-
-- A different port to Node-1 for P2P discovery using the [`--p2p-port`](../../public-networks/reference/cli/options.md#p2p-port) option.
-- The enode URL of Node-1 using the [`--bootnodes`](../../public-networks/reference/cli/options.md#bootnodes) option.
-- A data directory for Node-2 using the [`--data-path`](../../public-networks/reference/cli/options.md#data-path) option.
-- A genesis file as for Node-1.
-
-### 5. Start Node-3
-
-Start another terminal, change to the `Node-3` directory and start Node-3 specifying the Node-1 enode URL copied when starting Node-1 as the bootnode:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../privateNetworkGenesis.json --bootnodes= --p2p-port=30305
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\privateNetworkGenesis.json --bootnodes= --p2p-port=30305
-```
-
-
-
-The command line specifies:
-
-- A different port to Node-1 and Node-2 for P2P discovery.
-- A data directory for Node-3 using the [`--data-path`](../../public-networks/reference/cli/options.md#data-path) option.
-- A bootnode and genesis file as for Node-2.
-
-### 6. Confirm the private network is working
-
-Start another terminal, use curl to call the JSON-RPC API [`net_peerCount`](../../public-networks/reference/api/index.md#net_peercount) method and confirm the nodes are functioning as peers:
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' localhost:8545
-```
-
-The result confirms Node-1 (the node running the JSON-RPC service) has two peers (Node-2 and Node-3):
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x2"
-}
-```
-
-## Next steps
-
-Import accounts to MetaMask and send transactions as described in the [Quickstart tutorial](quickstart.md#create-a-transaction-using-metamask).
-
-:::info
-
-Besu doesn't support [private key management](../../public-networks/how-to/send-transactions.md).
-
-:::
-
-Send transactions using `eth_sendRawTransaction` to [send ether or, deploy or invoke contracts](../how-to/send-transactions/index.md).
-
-Use the [JSON-RPC API](../../public-networks/how-to/use-besu-api/json-rpc.md).
-
-Start a node with the [`--rpc-ws-enabled`](../../public-networks/reference/cli/options.md#rpc-ws-enabled) option and use the [RPC Pub/Sub API](../../public-networks/how-to/use-besu-api/rpc-pubsub.md).
-
-## Stop the nodes
-
-When finished using the private network, stop all nodes using ++ctrl+c++ in each terminal window.
-
-:::tip
-
-To restart the private network in the future, start from [3. Start the first node as a bootnode](#3-start-the-first-node-as-a-bootnode).
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/ibft/_category_.json b/versioned_docs/version-23.10.0/private-networks/tutorials/ibft/_category_.json
deleted file mode 100644
index c90421ed03c..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/ibft/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Create an IBFT 2.0 network",
- "position": 3
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/ibft/index.md b/versioned_docs/version-23.10.0/private-networks/tutorials/ibft/index.md
deleted file mode 100644
index 92df0a3f9ae..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/ibft/index.md
+++ /dev/null
@@ -1,376 +0,0 @@
----
-description: Hyperledger Besu private network using the IBFT 2.0 (Proof of Authority) consensus protocol
-tags:
- - private networks
----
-
-# Create a private network using IBFT 2.0
-
-A private network provides a configurable network for testing. This private network uses the [IBFT 2.0 (proof of authority) consensus protocol](../../how-to/configure/consensus/ibft.md).
-
-:::danger
-
-The steps in this tutorial create an isolated, but not protected or secure, Ethereum private network. We recommend running the private network behind a properly configured firewall.
-
-This tutorial configures a private network using IBFT 2.0 for educational purposes only. IBFT 2.0 requires 4 validators to be Byzantine fault tolerant.
-
-:::
-
-## Prerequisites
-
-- [Hyperledger Besu](../../get-started/install/binary-distribution.md)
-- [Curl (or similar webservice client)](https://curl.haxx.se/download.html).
-
-## Steps
-
-Listed on the right-hand side of the page are the steps to create a private network using IBFT 2.0 with four nodes. The four nodes are all validators.
-
-### 1. Create directories
-
-Each node requires a data directory for the blockchain data.
-
-Create directories for your private network, each of the four nodes, and a data directory for each node:
-
-```bash
-IBFT-Network/
-├── Node-1
-│ ├── data
-├── Node-2
-│ ├── data
-├── Node-3
-│ ├── data
-└── Node-4
- ├── data
-```
-
-### 2. Create a configuration file
-
-The configuration file defines the [IBFT 2.0 genesis file](../../how-to/configure/consensus/ibft.md#genesis-file) and the number of node key pairs to generate.
-
-The configuration file has two nested JSON nodes. The first is the `genesis` property defining the IBFT 2.0 genesis file, except for the `extraData` string, which Besu generates automatically in the resulting genesis file. The second is the `blockchain` property defining the number of key pairs to generate.
-
-Copy the following configuration file definition to a file called `ibftConfigFile.json` and save it in the `IBFT-Network` directory:
-
-```json
-{
- "genesis": {
- "config": {
- "chainId": 1337,
- "berlinBlock": 0,
- "ibft2": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- }
- },
- "nonce": "0x0",
- "timestamp": "0x58ee40ba",
- "gasLimit": "0x47b760",
- "difficulty": "0x1",
- "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365",
- "coinbase": "0x0000000000000000000000000000000000000000",
- "alloc": {
- "fe3b557e8fb62b89f4916b721be55ceb828dbd73": {
- "privateKey": "8f2a55949038a9610f50fb23b5883af3b4ecb3c3bb792cbcefbd1542c692be63",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "0xad78ebc5ac6200000"
- },
- "627306090abaB3A6e1400e9345bC60c78a8BEf57": {
- "privateKey": "c87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "90000000000000000000000"
- },
- "f17f52151EbEF6C7334FAD080c5704D77216b732": {
- "privateKey": "ae6ae8e5ccbfb04590405997ee2d52d2b330726137b875053c36d94e974d162f",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "90000000000000000000000"
- }
- }
- },
- "blockchain": {
- "nodes": {
- "generate": true,
- "count": 4
- }
- }
-}
-```
-
-:::note
-
-We recommend specifying the latest [milestone](../../../public-networks/reference/genesis-items.md#milestone-blocks) when creating the configuration file for a private network. This ensures you are using the most up-to-date protocol and have access to the most recent opcodes.
-
-:::
-
-:::warning
-
-Do not use the accounts in `alloc` in the genesis file on Mainnet or any public network except for testing. The private keys display, which means the accounts are not secure.
-
-:::
-
-### 3. Generate node keys and a genesis file
-
-In the `IBFT-Network` directory, generate the node key and genesis file:
-
-```bash
-besu operator generate-blockchain-config --config-file=ibftConfigFile.json --to=networkFiles --private-key-file-name=key
-```
-
-Besu creates the following in the `networkFiles` directory:
-
-- `genesis.json` - The genesis file including the `extraData` property specifying the four nodes are validators.
-- A directory for each node named using the node address and containing the public and private key for each node.
-
-```bash
-networkFiles/
-├── genesis.json
-└── keys
- ├── 0x438821c42b812fecdcea7fe8235806a412712fc0
- │ ├── key
- │ └── key.pub
- ├── 0xca9c2dfa62f4589827c0dd7dcf48259aa29f22f5
- │ ├── key
- │ └── key.pub
- ├── 0xcd5629bd37155608a0c9b28c4fd19310d53b3184
- │ ├── key
- │ └── key.pub
- └── 0xe96825c5ab8d145b9eeca1aba7ea3695e034911a
- ├── key
- └── key.pub
-```
-
-### 4. Copy the genesis file to the IBFT-Network directory
-
-Copy the `genesis.json` file to the `IBFT-Network` directory.
-
-### 5. Copy the node private keys to the node directories
-
-For each node, copy the key files to the `data` directory for that node
-
-```bash
-IBFT-Network/
-├── genesis.json
-├── Node-1
-│ ├── data
-│ │ ├── key
-│ │ ├── key.pub
-├── Node-2
-│ ├── data
-│ │ ├── key
-│ │ ├── key.pub
-├── Node-3
-│ ├── data
-│ │ ├── key
-│ │ ├── key.pub
-├── Node-4
-│ ├── data
-│ │ ├── key
-│ │ ├── key.pub
-```
-
-### 6. Start the first node as the bootnode
-
-In the `Node-1` directory, start Node-1:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --rpc-http-enabled --rpc-http-api=ETH,NET,IBFT --host-allowlist="*" --rpc-http-cors-origins="all"
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --rpc-http-enabled --rpc-http-api=ETH,NET,IBFT --host-allowlist="*" --rpc-http-cors-origins="all"
-```
-
-
-
-The command line:
-
-- Specifies the data directory for Node-1 using the [`--data-path`](../../../public-networks/reference/cli/options.md#data-path) option.
-- Enables the JSON-RPC API using the [`--rpc-http-enabled`](../../../public-networks/reference/cli/options.md#rpc-http-enabled) option.
-- Enables the ETH, NET, and IBFT APIs using the [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api) option.
-- Enables all-host access to the HTTP JSON-RPC API using the [`--host-allowlist`](../../../public-networks/reference/cli/options.md#host-allowlist) option.
-- Enables all-domain access to the node through the HTTP JSON-RPC API using the [`--rpc-http-cors-origins`](../../../public-networks/reference/cli/options.md#rpc-http-cors-origins) option.
-
-When the node starts, the [enode URL](../../../public-networks/concepts/node-keys.md#enode-url) displays. Copy the enode URL to specify Node-1 as the bootnode in the following steps.
-
-![Node 1 Enode URL](../../../assets/images/EnodeStartup.png)
-
-### 7. Start Node-2
-
-Start another terminal, change to the `Node-2` directory and start Node-2 specifying the Node-1 enode URL copied when starting Node-1 as the bootnode:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --bootnodes= --p2p-port=30304 --rpc-http-enabled --rpc-http-api=ETH,NET,IBFT --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8546
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --bootnodes= --p2p-port=30304 --rpc-http-enabled --rpc-http-api=ETH,NET,IBFT --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8546
-```
-
-
-
-The command line specifies:
-
-- The data directory for Node-2 using the [`--data-path`](../../../public-networks/reference/cli/options.md#data-path) option.
-- A different port to Node-1 for P2P discovery using the [`--p2p-port`](../../../public-networks/reference/cli/options.md#p2p-port) option.
-- A different port to Node-1 for HTTP JSON-RPC using the [`--rpc-http-port`](../../../public-networks/reference/cli/options.md#rpc-http-port) option.
-- The enode URL of Node-1 using the [`--bootnodes`](../../../public-networks/reference/cli/options.md#bootnodes) option.
-- Other options as for [Node-1](#6-start-the-first-node-as-the-bootnode).
-
-### 8. Start Node-3
-
-Start another terminal, change to the `Node-3` directory and start Node-3 specifying the Node-1 enode URL copied when starting Node-1 as the bootnode:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --bootnodes= --p2p-port=30305 --rpc-http-enabled --rpc-http-api=ETH,NET,IBFT --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8547
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --bootnodes= --p2p-port=30305 --rpc-http-enabled --rpc-http-api=ETH,NET,IBFT --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8547
-```
-
-
-
-The command line specifies:
-
-- The data directory for Node-3 using the [`--data-path`](../../../public-networks/reference/cli/options.md#data-path) option.
-- A different port to Node-1 and Node-2 for P2P discovery using the [`--p2p-port`](../../../public-networks/reference/cli/options.md#p2p-port) option.
-- A different port to Node-1 and Node-2 for HTTP JSON-RPC using the [`--rpc-http-port`](../../../public-networks/reference/cli/options.md#rpc-http-port) option.
-- The bootnode as for [Node-2](#7-start-node-2).
-- Other options as for [Node-1](#6-start-the-first-node-as-the-bootnode).
-
-### 9. Start Node-4
-
-Start another terminal, change to the `Node-4` directory and start Node-4 specifying the Node-1 enode URL copied when starting Node-1 as the bootnode:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --bootnodes= --p2p-port=30306 --rpc-http-enabled --rpc-http-api=ETH,NET,IBFT --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8548
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\genesis.json --bootnodes= --p2p-port=30306 --rpc-http-enabled --rpc-http-api=ETH,NET,IBFT --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8548
-```
-
-
-
-The command line specifies:
-
-- The data directory for Node-4 using the [`--data-path`](../../../public-networks/reference/cli/options.md#data-path) option.
-- A different port to Node-1, Node-2, and Node-3 for P2P discovery using the [`--p2p-port`](../../../public-networks/reference/cli/options.md#p2p-port) option.
-- A different port to Node-1, Node-2, and Node-3 for HTTP JSON-RPC using the [`--rpc-http-port`](../../../public-networks/reference/cli/options.md#rpc-http-port) option.
-- The bootnode as for [Node-2](#7-start-node-2).
-- Other options as for [Node-1](#6-start-the-first-node-as-the-bootnode).
-
-### 10. Confirm the private network is working
-
-Start another terminal, use curl to call the JSON-RPC API [`ibft_getvalidatorsbyblocknumber`](../../reference/api/index.md#ibft_getvalidatorsbyblocknumber) method and confirm the network has four validators:
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_getValidatorsByBlockNumber","params":["latest"], "id":1}' localhost:8545
-```
-
-The result displays the four validators:
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": [
- "0x1e326b6da177ede2d3eb6d7247bd9f6901d40234",
- "0x4aaac297fefe4466ebcb0b23ab90c5f466b11556",
- "0xa267ead2e91e1673e0943b925176b51d9cd4f6d2",
- "0xe3e680bc0ff485d1d415a384721f19e0db65fea7"
- ]
-}
-```
-
-Look at the logs to confirm Besu is producing blocks:
-
-```bash
-2020-12-21 07:22:17.883+10:00 | EthScheduler-Workers-0 | INFO | PersistBlockTask | Imported #1 / 0 tx / 0 om / 0 (0.0%) gas / (0xde088192f27ca376eea969cb7a4a1de445bd923fde0444194c88e630f7705584) in 0.010s. Peers: 4
-2020-12-21 07:22:19.057+10:00 | pool-8-thread-1 | INFO | IbftRound | Importing block to chain. round=ConsensusRoundIdentifier{Sequence=2, Round=0}, hash=0x2ca2652fa79ae2b3b6aadcfb13d5d362ffd6207c3b5ae47971e04eb9d05deaa9
-2020-12-21 07:22:21.044+10:00 | pool-8-thread-1 | INFO | IbftRound | Importing block to chain. round=ConsensusRoundIdentifier{Sequence=3, Round=0}, hash=0x5d9a06cd17127712cfae7d1c25f705f302e146f4b64a73de3c814e1b5a3f9a16
-2020-12-21 07:22:23.049+10:00 | pool-8-thread-1 | INFO | IbftRound | Importing block to chain. round=ConsensusRoundIdentifier{Sequence=4, Round=0}, hash=0x843981375f4cb2bb0f33a09b647ac27da5df2c539d940d8344c907eede57829c
-2020-12-21 07:22:25.060+10:00 | pool-8-thread-1 | INFO | IbftRound | Importing block to chain. round=ConsensusRoundIdentifier{Sequence=5, Round=0}, hash=0x82b2069961d9185f7857cad1123de72d715729e122441335db486ea436834d6e
-```
-
-:::info
-
-If the key files were not copied to the correct directory in [step 5](#5-copy-the-node-private-keys-to-the-node-directories), the network will not start producing blocks.
-
-The logs for each node should indicate the public key was loaded from the `data/key` directory:
-
-```bash
-2020-12-21 07:16:18.360+10:00 | main | INFO | KeyPairUtil | Loaded public key 0xe143eadaf670d49afa3327cae2e655b083f5a89dac037c9af065914a9f8e6bceebcfe7ae2258bd22a9cd18b6a6de07b9790e71de49b78afa456e401bd2fb22fc from /IBFT-Network/Node-1/data/key
-```
-
-If the keys were not copied to the correct directory, Besu creates a key when starting up:
-
-```bash
-2020-12-21 07:33:11.458+10:00 | main | INFO | KeyPairUtil | Generated new public key 0x1a4a2ade5ebc0a85572e2492e0cdf3e96b8928c75fa55b4425de8849850cf9b3a8cad1e27d98a3d3afac326a5e8788dbe6cc40249715c92825aebb28abe3e346 and stored it to /IBFT-Network/Node-1/data/key
-```
-
-If a new key was created, the validator key specified in the configuration does not match the created key and the node cannot participate in creating blocks.
-
-:::
-
-## Next steps
-
-Use the [IBFT API](../../reference/api/index.md#ibft-20-methods) to remove or add validators.
-
-:::note
-
-To add or remove nodes as validators you need the node address. The directory [created for each node](#3-generate-node-keys-and-a-genesis-file) has the node address as the name.
-
-This tutorial configures a private network using IBFT 2.0 for educational purposes only. IBFT 2.0 requires four validators to be Byzantine fault tolerant.
-
-:::
-
-Import accounts to MetaMask and send transactions as described in the [Quickstart tutorial](../quickstart.md#create-a-transaction-using-metamask).
-
-:::info
-
-Besu doesn't support [private key management](../../../public-networks/how-to/send-transactions.md).
-
-:::
-
-## Stop the nodes
-
-When finished using the private network, stop all nodes using ++ctrl+c++ in each terminal window.
-
-:::tip
-
-To restart the IBFT 2.0 network in the future, start from [6. Start First Node as Bootnode](#6-start-the-first-node-as-the-bootnode).
-
-:::
-
-
-
-[IBFT 2.0 (proof of authority)consensus protocol]: ../../how-to/configure/consensus/ibft.md
-
-
-
-\*[Byzantine fault tolerant]: Ability to function correctly and reach consensus despite nodes failing or propagating incorrect information to peers.
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/ibft/validators.md b/versioned_docs/version-23.10.0/private-networks/tutorials/ibft/validators.md
deleted file mode 100644
index 1e74b04d01d..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/ibft/validators.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-title: Add and removing IBFT 2.0 validators
-sidebar_position: 1
-description: Adding and removing IBFT 2.0 validators
-tags:
- - private networks
----
-
-# Add and remove IBFT 2.0 validators
-
-This example walks through [adding and removing an IBFT 2.0 validator](../../how-to/configure/consensus/ibft.md#add-and-remove-validators).
-
-## Prerequisites
-
-- [IBFT 2.0 network as configured in the IBFT 2.0 tutorial](index.md)
-
-## Add a validator
-
-### 1. Create directories
-
-Create a working directory and a data directory for the new node that needs to be added:
-
-```bash
-mkdir -p Node-5/data
-```
-
-### 2. Start the node
-
-Change into the working directory for the new Node-5 and start the node, specifying the [Node-1 enode URL](index.md#6-start-the-first-node-as-the-bootnode) as the bootnode:
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --bootnodes= --p2p-port=30307 --rpc-http-enabled --rpc-http-api=ETH,NET,IBFT --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8549
-```
-
-The command line specifies:
-
-- The data directory for Node-5 using the [`--data-path`](../../../public-networks/reference/cli/options.md#data-path) option.
-- A different port to Node-1 for P2P discovery using the [`--p2p-port`](../../../public-networks/reference/cli/options.md#p2p-port) option.
-- A different port to Node-1 for HTTP JSON-RPC using the [`--rpc-http-port`](../../../public-networks/reference/cli/options.md#rpc-http-port) option.
-- The enode URL of Node-1 using the [`--bootnodes`](../../../public-networks/reference/cli/options.md#bootnodes) option.
-- Other options as for [Node-1](index.md#6-start-the-first-node-as-the-bootnode).
-
-### 3. Copy the address of the node
-
-Copy the address of the node. You can find the address in the logs when starting the new node:
-
-```bash
-2021-05-28 09:49:00.881+10:00 | main | INFO | DefaultP2PNetwork | Node address 0x90626e6a67445aabf1c0615410d108d4733aa90b
-```
-
-Or use the [`public-key export-address`](../../../public-networks/reference/cli/subcommands.md#export-address) subcommand:
-
-
-
-# Subcommand
-
-```bash
-besu --data-path=IBFT-Network/Node-5/data public-key export-address
-```
-
-# Output
-
-```bash
-0x90626e6a67445aabf1c0615410d108d4733aa90b
-```
-
-
-
-### 4. Propose adding the new validator
-
-Propose adding the new validator from more than half the number of current validators, using [`ibft_proposeValidatorVote`](../../../public-networks/reference/api/index.md#ibft_proposevalidatorvote), specifying the address of the proposed validator and `true`:
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_proposeValidatorVote","params":["0x90626e6a67445aabf1c0615410d108d4733aa90b", true], "id":1}' http://127.0.0.1:8545
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": true
-}
-```
-
-
-
-Repeat the proposal process for this candidate node from at least two of the other nodes.
-
-### 5. Verify the addition of the new validator
-
-Verify that the new validator is now in the list of validators using [`ibft_getValidatorsByBlockNumber`](../../../public-networks/reference/api/index.md#ibft_getvalidatorsbyblocknumber):
-
-
-
-# curl HTTP request
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"ibft_getValidatorsByBlockNumber","params":["latest"], "id":1}' http://127.0.0.1:8545
-```
-
-# JSON result
-
-```json
-[
- "0x189d23d201b03ae1cf9113672df29a5d672aefa3",
- "0x2aabbc1bb9bacef60a09764d1a1f4f04a47885c1",
- "0x44b07d2c28b8ed8f02b45bd84ac7d9051b3349e6",
- "0x4c1ccd426833b9782729a212c857f2f03b7b4c0d",
- "0x90626e6a67445aabf1c0615410d108d4733aa90b"
-]
-```
-
-
-
-The list of validators contains 5 addresses now.
-
-## Remove a validator
-
-The process for removing a validator is similar to [adding a validator](#add-a-validator) starting from step 2, except you specify `false` as the second parameter of [`ibft_proposeValidatorVote`](../../../public-networks/reference/api/index.md#ibft_proposevalidatorvote).
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/_category_.json b/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/_category_.json
deleted file mode 100644
index 5a498fa215c..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Deploy using Kubernetes",
- "position": 9
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/charts.md b/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/charts.md
deleted file mode 100644
index 259fe1d13d3..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/charts.md
+++ /dev/null
@@ -1,504 +0,0 @@
----
-title: Deploying Charts
-sidebar_position: 3
-description: Deploying Besu Helm Charts for a Kubernetes cluster
-tags:
- - private networks
----
-
-# Deploy charts
-
-You can deploy Besu Helm charts for a Kubernetes cluster.
-
-## Prerequisites
-
-- Clone the [Quorum-Kubernetes](https://github.com/ConsenSys/quorum-kubernetes) repository
-- A [running Kubernetes cluster](cluster.md)
-- Install [Kubectl](https://kubernetes.io/docs/tasks/tools/)
-- Install [Helm3](https://helm.sh/docs/intro/install/)
-
-## Provision with Helm charts
-
-Helm is a method of packaging a collection of objects into a chart which can then be deployed to the cluster. After you have cloned the [Quorum-Kubernetes](https://github.com/ConsenSys/quorum-kubernetes) repository, change the directory to `helm` for the rest of this tutorial.
-
-```bash
-cd helm
-```
-
-Each helm chart has the following key-map values which you will need to set depending on your needs. The `cluster.provider` is used as a key for the various cloud features enabled. Please specify only one cloud provider, not both. At present, the charts have full support for cloud native services in both AWS and Azure. Please note that if you use GCP, IBM etc please set `cluster.provider: local` and set `cluster.cloudNativeServices: false`.
-
-Please update the `aws` or `azure` map as shown below if you deploy to either cloud provider.
-
-```bash
-cluster:
- provider: local # choose from: local | aws | azure
- cloudNativeServices: false # set to true to use Cloud Native Services (SecretsManager and IAM for AWS; KeyVault & Managed Identities for Azure)
- reclaimPolicy: Delete # set to either Retain or Delete; note that PVCs and PVs will still exist after a 'helm delete'. Setting to Retain will keep volumes even if PVCs/PVs are deleted in kubernetes. Setting to Delete will remove volumes from EC2 EBS when PVC is deleted
-
-quorumFlags:
- privacy: false
- removeKeysOnDelete: false
-
-aws:
- # the aws cli commands uses the name 'quorum-node-secrets-sa' so only change this if you altered the name
- serviceAccountName: quorum-node-secrets-sa
- # the region you are deploying to
- region: ap-southeast-2
-
-azure:
- # the script/bootstrap.sh uses the name 'quorum-pod-identity' so only change this if you altered the name
- identityName: quorum-pod-identity
- # the clientId of the user assigned managed identity created in the template
- identityClientId: azure-clientId
- keyvaultName: azure-keyvault
- # the tenant ID of the key vault
- tenantId: azure-tenantId
- # the subscription ID to use - this needs to be set explictly when using multi tenancy
- subscriptionId: azure-subscriptionId
-```
-
-Setting the `cluster.cloudNativeServices: true`:
-
-- Stores keys in Azure Key Vault or AWS Secrets Manager.
-- Uses Azure Managed Identities or AWS Identity and Access Management for pod identity access.
-
-:::note
-
-You can customize any of the charts in this repository to suit your requirements, and make pull requests to extend functionality.
-
-:::
-
-### 1. Check that you can connect to the cluster with `kubectl`
-
-Verify kubectl is connected to cluster using: (use the latest version)
-
-```bash
-kubectl version
-```
-
-The result looks similar to:
-
-```bash
-Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.1", GitCommit:"86ec240af8cbd1b60bcc4c03c20da9b98005b92e", GitTreeState:"clean", BuildDate:"2021-12-16T11:41:01Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"}
-Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:35:25Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"linux/amd64"}
-```
-
-### 2. Create the namespace
-
-This tutorial isolates groups of resources (for example, StatefulSets and Services) within a single cluster.
-
-:::note
-
-The rest of this tutorial uses `besu` as the namespace, but you're free to pick any name when deploying, as long as it's consistent across the [infrastructure scripts](cluster.md) and charts.
-
-:::
-
-Run the following in a terminal window:
-
-```bash
-kubectl create namespace besu
-```
-
-### 3. Deploy the monitoring chart
-
-This chart deploys Prometheus and Grafana to monitor the metrics of the cluster, nodes and state of the network.
-
-Update the admin `username` and `password` in the [monitoring values file](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/values/monitoring.yml). Configure alerts to the receiver of your choice (for example, email or Slack), then deploy the chart using:
-
-```bash
-helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
-helm repo update
-helm install monitoring prometheus-community/kube-prometheus-stack --version 34.10.0 --namespace=besu --values ./values/monitoring.yml --wait
-kubectl --namespace besu apply -f ./values/monitoring/
-```
-
-Metrics are collected via a [ServiceMonitor](https://github.com/prometheus-operator/prometheus-operator/blob/7c77626e5e270a2530e187b185d45eeed8a773bf/Documentation/user-guides/getting-started.md) that scrapes each Besu pod, using given [`annotations`](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) which specify the port and path to use. For example:
-
-```bash
- template:
- metadata:
- annotations:
- prometheus.io/scrape: "true"
- prometheus.io/port: 9545
- prometheus.io/path: "/metrics"
-```
-
-:::warning
-
-For production use cases, configure Grafana with one of the supported [native auth mechanisms](https://grafana.com/docs/grafana/latest/auth/).
-
-:::
-
-![k8s-metrics](../../../assets/images/kubernetes-grafana.png)
-
-Optionally you can also deploy the [Elastic Stack](https://www.elastic.co/elastic-stack/) to view logs (and metrics).
-
-```bash
-helm repo add elastic https://helm.elastic.co
-helm repo update
-# if on cloud
-helm install elasticsearch --version 7.17.1 elastic/elasticsearch --namespace quorum --values ./values/elasticsearch.yml
-# if local - set the replicas to 1
-helm install elasticsearch --version 7.17.1 elastic/elasticsearch --namespace quorum --values ./values/elasticsearch.yml --set replicas=1 --set minimumMasterNodes: 1
-helm install kibana --version 7.17.1 elastic/kibana --namespace quorum --values ./values/kibana.yml
-helm install filebeat --version 7.17.1 elastic/filebeat --namespace quorum --values ./values/filebeat.yml
-```
-
-If you install `filebeat`, please create a `filebeat-*` index pattern in `kibana`. All the logs from the nodes are sent to the `filebeat` index. If you use The Elastic stack for logs and metrics, please deploy `metricbeat` in a similar manner to `filebeat` and create an index pattern in Kibana.
-
-![k8s-elastic](../../../assets/images/kubernetes-elastic.png)
-
-To connect to Kibana or Grafana, we also need to deploy an ingress so you can access your monitoring endpoints publicly. We use Nginx as our ingress here, and you are free to configure any ingress per your requirements.
-
-```bash
-helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
-helm repo update
-helm install quorum-monitoring-ingress ingress-nginx/ingress-nginx \
- --namespace quorum \
- --set controller.ingressClassResource.name="monitoring-nginx" \
- --set controller.ingressClassResource.controllerValue="k8s.io/monitoring-ingress-nginx" \
- --set controller.replicaCount=1 \
- --set controller.nodeSelector."kubernetes\.io/os"=linux \
- --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
- --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
- --set controller.service.externalTrafficPolicy=Local
-
-kubectl apply -f ../ingress/ingress-rules-monitoring.yml
-```
-
-Once complete, view the IP address listed under the `Ingress` section if you're using the Kubernetes Dashboard or on the command line `kubectl -n quorum get services quorum-monitoring-ingress-ingress-nginx-controller`.
-
-:::note
-
-We refer to the ingress here as `external-nginx` because it deals with monitoring endpoints specifically. We also deploy a second ingress called `network-ingress` which is for the blockchain nodes only in [step 8](#9-connect-to-the-node-from-your-local-machine-via-an-ingress)
-
-:::
-
-![`k8s-ingress-external`](../../../assets/images/kubernetes-ingress-ip.png)
-
-You can view the Besu dashboard by going to:
-
-```bash
-http:///d/XE4V0WGZz/besu-overview?orgId=1&refresh=10s
-```
-
-You can view the Kibana dashboard (if deployed) by going to:
-
-```bash
-http:///kibana
-```
-
-### 4. Deploy the genesis chart
-
-The genesis chart creates the genesis file and keys for the validators.
-
-:::warning
-
-It's important to keep the release names of the initial validator pool as per this tutorial, that is `validator-n`, where `n` is the node number. Any validators created after the initial pool can be named to anything you like.
-
-:::
-
-The override [values.yml](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/values/genesis-besu.yml) looks like below:
-
-```bash
----
-quorumFlags:
- removeGenesisOnDelete: true
-
-cluster:
- provider: local # choose from: local | aws | azure
- cloudNativeServices: false
-
-aws:
- # the aws cli commands uses the name 'quorum-node-secrets-sa' so only change this if you altered the name
- serviceAccountName: quorum-node-secrets-sa
- # the region you are deploying to
- region: ap-southeast-2
-
-azure:
- # the script/bootstrap.sh uses the name 'quorum-pod-identity' so only change this if you altered the name
- identityName: quorum-pod-identity
- # the clientId of the user assigned managed identity created in the template
- identityClientId: azure-clientId
- keyvaultName: azure-keyvault
- # the tenant ID of the key vault
- tenantId: azure-tenantId
- # the subscription ID to use - this needs to be set explictly when using multi tenancy
- subscriptionId: azure-subscriptionId
-
-# the raw Genesis config
-# rawGenesisConfig.blockchain.nodes set the number of validators/signers
-rawGenesisConfig:
- genesis:
- config:
- chainId: 1337
- algorithm:
- consensus: qbft # choose from: ibft2 | qbft | clique
- blockperiodseconds: 10
- epochlength: 30000
- requesttimeoutseconds: 20
- gasLimit: '0x47b760'
- difficulty: '0x1'
- coinbase: '0x0000000000000000000000000000000000000000'
- blockchain:
- nodes:
- generate: true
- count: 4
- accountPassword: 'password'
-```
-
-Please set the `aws`, `azure` and `cluster` keys are as per the [Provisioning](#provision-with-helm-charts) step. `quorumFlags.removeGenesisOnDelete: true` tells the chart to delete the genesis file when the chart is deleted. If you may wish to retain the genesis on deletion, please set that value to `false`.
-
-The last config item is `rawGenesisConfig` which has details of the chain you are creating, please edit any of the parameters in there to match your requirements. To set the number of initial validators set the `rawGenesisConfig.blockchain.nodes` to the number that you'd like. We recommend using the Byzantine formula of `N=3F+1` when setting the number of validators.
-
-One more thing to note is that when `cluster.cloudNativeServices: true` is set, the genesis job will not add the [Quickstart](../quickstart.md) test accounts into the genesis file.
-
-When you are ready deploy the chart with :
-
-```bash
-cd helm
-helm install genesis ./charts/besu-genesis --namespace besu --create-namespace --values ./values/genesis-besu.yml
-```
-
-Once completed, view the genesis and enodes (the list of static nodes) configuration maps that every Besu node uses, and the validator and bootnode node keys as secrets.
-
-![k8s-genesis-configmaps](../../../assets/images/kubernetes-genesis-configmaps.png)
-
-![k8s-genesis-secrets](../../../assets/images/kuberenetes-genesis-secrets.png)
-
-### 5. Deploy the bootnodes
-
-This is an optional but recommended step. In a production setup we recommend the use of two ore more bootnodes for best practices. Each Besu node has a map that tells the StatefulSet what to deploy and how to clean up. The default `values.yml` for the StatefulSet define the following flags which are present in all the override values files.
-
-```bash
----
-quorumFlags:
- privacy: false
- removeKeysOnDelete: true
- isBootnode: true # set this to true if this node is a bootnode
- usesBootnodes: true # set this to true if the network you are connecting to use a bootnode/s that are deployed in the cluster
-
-cluster:
- provider: local # choose from: local | aws | azure
- cloudNativeServices: false
- reclaimPolicy: Delete # set to either Retain or Delete; note that PVCs and PVs will still exist after a 'helm delete'. Setting to Retain will keep volumes even if PVCs/PVs are deleted in kubernetes. Setting to Delete will remove volumes from EC2 EBS when PVC is deleted
-
-aws:
- # the aws cli commands uses the name 'quorum-node-secrets-sa' so only change this if you altered the name
- serviceAccountName: quorum-node-secrets-sa
- # the region you are deploying to
- region: ap-southeast-2
-
-azure:
- # the script/bootstrap.sh uses the name 'quorum-pod-identity' so only change this if you altered the name
- identityName: quorum-pod-identity
- # the clientId of the user assigned managed identity created in the template
- identityClientId: azure-clientId
- keyvaultName: azure-keyvault
- # the tenant ID of the key vault
- tenantId: azure-tenantId
- # the subscription ID to use - this needs to be set explictly when using multi tenancy
- subscriptionId: azure-subscriptionId
-
-node:
- besu:
- metrics:
- serviceMonitorEnabled: true
- resources:
- cpuLimit: 1
- cpuRequest: 0.1
- memLimit: "2G"
- memRequest: "1G"
-```
-
-Please set the `aws`, `azure` and `cluster` keys are as per the [Provisioning](#provision-with-helm-charts) step. `quorumFlags.removeKeysOnDelete: true` tells the chart to delete the node's keys when the chart is deleted. If you may wish to retain the keys on deletion, please set that value to `false`.
-
-For the bootnodes only, set the `quorumFlags.isBootnode: true`. When using bootnodes you have to also set `quorumFlags.usesBootnodes: true` to indicate that all nodes on the network will use these bootnodes.
-
-:::note
-
-If you use bootnodes, you must set `quorumFlags.usesBootnodes: true` in the override values.yaml for every other node type, that is validators.yaml, txnode.yaml and reader.yaml
-
-:::
-
-```bash
-helm install bootnode-1 ./charts/besu-node --namespace besu --values ./values/bootnode.yml
-helm install bootnode-2 ./charts/besu-node --namespace besu --values ./values/bootnode.yml
-```
-
-Once complete, you see two StatefulSets, and the two bootnodes discover themselves and peer. Because there are no validators present yet, there are no blocks created, as seen in the following logs.
-
-![k8s-bootnode-logs](../../../assets/images/kubernetes-bootnode-logs.png)
-
-### 6. Deploy the validators
-
-The validators peer with the bootnodes and themselves, and when a majority of the validators have peered, blocks are proposed and created on the chain.
-
-These are the next set of nodes that we will deploy. The charts use four validators (default) to replicate best practices for a network. The override [values.yml](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/values/validator.yml) for the StatefulSet looks like below:
-
-```bash
----
-quorumFlags:
- privacy: false
- removeKeysOnDelete: false
- isBootnode: false # set this to true if this node is a bootnode
- usesBootnodes: true # set this to true if the network you are connecting to use a bootnode/s that are deployed in the cluster
-```
-
-Please set the `aws`, `azure` and `cluster` keys are as per the [Provisioning](#provision-with-helm-charts) step. `quorumFlags.removeKeysOnDelete: true` tells the chart to delete the node's keys when the chart is deleted. If you may wish to retain the keys on deletion, please set that value to `false`.
-
-:::warning
-
-Please note that if you delete a majority of the validators, the network will halt. Additionally, if the validator keys are deleted you may not be able to recover as you need a majority of the validators up to vote to add new validators into the pool
-
-:::
-
-When using bootnodes (if deployed in the previous step) you have to also set `quorumFlags.usesBootnodes: true` to indicate that all nodes on the network will use these bootnodes.
-
-For the initial validator pool we set all the node flags to `false` and then deploy.
-
-```bash
-helm install validator-1 ./charts/besu-node --namespace besu --values ./values/validator.yml
-helm install validator-2 ./charts/besu-node --namespace besu --values ./values/validator.yml
-helm install validator-3 ./charts/besu-node --namespace besu --values ./values/validator.yml
-helm install validator-4 ./charts/besu-node --namespace besu --values ./values/validator.yml
-```
-
-:::warning
-
-It's important to keep the release names of the validators the same as it is tied to the keys that the genesis chart creates. So we use `validator-1`, `validator-2`, etc. in the following command.
-
-:::
-
-Once completed, you may need to give the validators a few minutes to peer and for round changes, depending on when the first validator was spun up, before the logs display blocks being created.
-
-![k8s-validator-logs](../../../assets/images/kubernetes-validator-logs.png)
-
-### 7. Add/Remove additional validators to the validator pool
-
-To add (or remove) more validators to the initial validator pool, you need to deploy a node such as an RPC node (step 8) and then [vote](../../how-to/configure/consensus/ibft.md#add-and-remove-validators) that node in. The vote API call must be made on a majority of the existing pool and the new node will then become a validator.
-
-Please refer to the [Ingress Section](#9-connect-to-the-node-from-your-local-machine-via-an-ingress) for details on making the API calls from your local machine or equivalent.
-
-### 8. Deploy RPC or Transaction nodes
-
-An RPC node is simply a node that can be used to make public transactions or perform read heavy operations such as when connected to a chain explorer like [BlockScout](https://github.com/blockscout/blockscout).
-
-The RPC override [values.yml](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/values/reader.yml) for the StatefulSet looks identical to that of the validators above, and will create it's own node keys before the node starts.
-
-To deploy an RPC node:
-
-```bash
-helm install rpc-1 ./charts/besu-node --namespace besu --values ./values/reader.yml
-```
-
-A Transaction or Member node in turn is one which has an accompanying Private Transaction Manager, such as Tessera; which allow you to make private transactions between nodes.
-
-The Transaction override [values.yml](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/values/txnode.yml) for the StatefulSet looks identical to that of the validators above and only has `quorumFlags.privacy: true` to indicate that it is deploying a pair of GoQuorum and Tessera nodes.
-
-To deploy a Transaction or Member node:
-
-```bash
-helm install member-1 ./charts/besu-node --namespace besu --values ./values/txnode.yml
-```
-
-Logs for `member-1` resemble the following for Tessera:
-
-![`k8s-tx-tessera-logs`](../../../assets/images/kubernetes-tx-tessera-logs.png)
-
-Logs for Besu resemble the following:
-
-![`k8s-tx-Besu-logs`](../../../assets/images/kubernetes-tx-Besu-logs.png)
-
-:::note
-
-In these examples we use `member-1` and `rpc-1` as release names for the deployments. You can pick any release name that you'd like to use in place of those as per your requirements.
-
-:::
-
-### 9. Connect to the node from your local machine via an ingress
-
-In order to view the Grafana dashboards or connect to the nodes to make transactions from your local machine you can deploy an ingress controller with rules. We use the `ingress-nginx` ingress controller which can be deployed as follows:
-
-```bash
-helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
-helm repo update
-helm install quorum-network-ingress ingress-nginx/ingress-nginx \
- --namespace quorum \
- --set controller.ingressClassResource.name="network-nginx" \
- --set controller.ingressClassResource.controllerValue="k8s.io/network-ingress-nginx" \
- --set controller.replicaCount=1 \
- --set controller.nodeSelector."kubernetes\.io/os"=linux \
- --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
- --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
- --set controller.service.externalTrafficPolicy=Local
-```
-
-Use [pre-defined rules](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/ingress/ingress-rules-besu.yml) to test functionality, and alter to suit your requirements (for example, restrict access for API calls to trusted CIDR blocks).
-
-Edit the [rules](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/ingress/ingress-rules-besu.yml) file so that the service names match your release name. In the example, we deployed a transaction node with the release name `member-1` so the corresponding service is called `besu-node-member-1`. Once you have settings that match your deployments, deploy the rules as follows:
-
-```bash
-kubectl apply -f ../ingress/ingress-rules-besu.yml
-```
-
-Once complete, view the IP address listed under the `Ingress` section if you're using the Kubernetes Dashboard or on the command line `kubectl -n quorum get services quorum-network-ingress-ingress-nginx-controller`.
-
-![`k8s-ingress`](../../../assets/images/kubernetes-ingress-ip.png)
-
-The following is an example RPC call, which confirms that the node running the JSON-RPC service is syncing:
-
-
-
-# curl HTTP request
-
-```bash
-curl -v -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' http:///rpc
-```
-
-# JSON result
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x4e9"
-}
-```
-
-
-
-### 10. Blockchain explorer
-
-You can deploy [BlockScout](https://github.com/blockscout/blockscout) to aid with monitoring the blockchain. To do this, update the [BlockScout values file](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/values/blockscout-besu.yml) and set the `database` and `secret_key_base` values.
-
-:::important
-
-Changes to the database requires changes to both the `database` and the `blockscout` dictionaries.
-
-:::
-
-Once completed, deploy the chart using:
-
-```bash
-helm dependency update ./charts/blockscout
-helm install blockscout ./charts/blockscout --namespace quorum --values ./values/blockscout-goquorum.yaml
-```
-
-You can optionally deploy the [Quorum-Explorer](https://github.com/ConsenSys/quorum-explorer) as a lightweight blockchain explorer. The Quorum Explorer is not recommended for use in production and is intended for demonstration or Development purposes only. The Explorer can give an overview over the whole network, such as querying each node on the network for node or block information, voting (add/remove) validators from the network, demonstrating a SimpleStorage smart contract with privacy enabled, and sending transactions between wallets as you would do in MetaMask. Please see the [Explorer](quorum-explorer.md) page for details on how to use the application.
-
-:::warning
-
-The accounts listed in the file below are for test purposes only and should not be used on a production network.
-
-:::
-
-To deploy the application, update the [Explorer values file](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/values/explorer-besu.yaml) with details of your nodes and endpoints and then deploy.
-
-```bash
-helm install quorum-explorer ./charts/explorer --namespace besu --values ./values/explorer-besu.yaml
-```
-
-You will also need deploy the ingress (if not already done in [Monitoring](#3-deploy-the-monitoring-chart) to access the endpoint on `http:///explorer`
-
-![`k8s-explorer`](../../../assets/images/kubernetes-explorer.png)
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/cluster.md b/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/cluster.md
deleted file mode 100644
index ba2772510b6..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/cluster.md
+++ /dev/null
@@ -1,230 +0,0 @@
----
-title: Create a cluster
-sidebar_position: 2
-description: Create a cluster for deployment
-tags:
- - private networks
----
-
-# Create a cluster
-
-You can create a [local](#local-clusters) or [cloud](#cloud-clusters) cluster to deploy a Besu network using Kubernetes.
-
-## Prerequisites
-
-- Clone the [Quorum-Kubernetes](https://github.com/ConsenSys/quorum-kubernetes) repository
-- Install [Kubectl](https://kubernetes.io/docs/tasks/tools/)
-- Install [Helm3](https://helm.sh/docs/intro/install/)
-- Install [AWS CLI](https://aws.amazon.com/cli/) and [`eksctl`](https://eksctl.io/) for AWS EKS clusters
-- Install [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) for Azure AKS clusters
-- Install the cloud-specific CLI
-
-## Local Clusters
-
-Use one of several options to create a local cluster. Select one listed below, or another that you're comfortable with.
-
-### Minikube
-
-[Minikube](https://minikube.sigs.k8s.io/docs/start/) is one of the most popular options to spin up a local Kubernetes cluster for development. You can [install a version](https://minikube.sigs.k8s.io/docs/start/) based on your architecture.
-
-:::note
-
-We recommend at least 2 CPUs and 16GB of RAM.
-
-:::
-
-To start the cluster, run the following command:
-
-```bash
-minikube start --cpus 2 --memory 16384 --cni auto
-```
-
-### kind
-
-[kind (Kubernetes in Docker)](https://kind.sigs.k8s.io) is a lightweight tool for running local Kubernetes clusters. The [installation](https://kind.sigs.k8s.io/docs/user/quick-start#installation) is similar to [Minikube](#minikube).
-
-To start the cluster, run the following command:
-
-```bash
-kind create cluster
-```
-
-### Rancher
-
-[Rancher](https://github.com/rancher-sandbox/rancher-desktop/) is a lightweight open source desktop application for Mac, Windows, and Linux. It provides Kubernetes and container management, and allows you to choose the version of Kubernetes to run.
-
-It can build, push, pull, and run container images. Built container images can be run without needing a registry.
-
-:::note
-
-The official Docker-CLI is not supported but rather uses [nerdctl](https://github.com/containerd/nerdctl) which is a Docker-CLI compatible tool for containerd, and is automatically installed with Rancher Desktop.
-
-:::
-
-:::note
-
-For Windows, you must [install Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl/install) to install Rancher Desktop.
-
-Refer to the [official Rancher Desktop documentation](https://docs.rancherdesktop.io/) for system requirements and installation instructions.
-
-:::
-
-## Cloud clusters
-
-### AWS EKS
-
-[AWS Elastic Kubernetes Service (AWS EKS)](https://aws.amazon.com/eks/) is one of the most popular platforms to deploy Hyperledger Besu.
-
-To create a cluster in AWS, you must install the [AWS CLI](https://aws.amazon.com/cli/) and [`eksctl`](https://eksctl.io/).
-
-The [template](https://github.com/ConsenSys/quorum-kubernetes/tree/master/aws) comprises the base infrastructure used to build the cluster and other resources in AWS. We also use some native services with the cluster for performance and best practices, these include:
-
-- [Pod identities](https://github.com/aws/amazon-eks-pod-identity-webhook).
-- [Secrets Store CSI drivers](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html).
-- Dynamic storage classes backed by AWS EBS. The [volume claims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) are fixed sizes and can be updated as you grow via helm updates, and won't need to re-provision the underlying storage class.
-- [CNI](https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html) networking mode for EKS. By default, EKS clusters use `kubenet` to create a virtual network and subnet. Nodes get an IP address from a virtual network subnet. Network address translation (NAT) is then configured on the nodes, and pods receive an IP address "hidden" behind the node IP.
-
- :::note
-
- This approach reduces the number of IP addresses that you must reserve in your network space for pods, but constrains what can connect to the nodes from outside the cluster (for example, on-premise nodes or those on another cloud provider).
-
- :::
-
-AWS Container Networking Interface (CNI) provides each pod with an IP address from the subnet, and can be accessed directly. The IP addresses must be unique across your network space, and must be planned in advance. Each node has a configuration parameter for the maximum number of pods that it supports. The equivalent number of IP addresses per node are then reserved up front for that node. This approach requires more planning, and can lead to IP address exhaustion as your application demands grow, however makes it easier for external nodes to connect to your cluster.
-
-:::warning
-
-EKS clusters must not use 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16, or 192.0.2.0/24 for the Kubernetes service address range.
-
-:::
-
-To provision the cluster:
-
-1. Update [cluster.yml](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/aws/templates/cluster.yml)
-
-2. Deploy the template:
-
- ```bash
- eksctl create cluster -f ./templates/cluster.yml
- ```
-
-3. Your `.kube/config` should be connected to the cluster automatically, but if not, run the commands below and replace `AWS_REGION` and `CLUSTER_NAME` with details that are specific to your deployment.
-
- ```bash
- aws sts get-caller-identity
- aws eks --region AWS_REGION update-kubeconfig --name CLUSTER_NAME
- ```
-
-4. After the deployment completes, provision the EBS drivers for the volumes. While it is possible to use the in-tree `aws-ebs` driver that's natively supported by Kubernetes, it is no longer being updated and does not support newer EBS features such as the [cheaper and better gp3 volumes](https://stackoverflow.com/questions/68359043/whats-the-difference-between-ebs-csi-aws-com-vs-kubernetes-io-aws-ebs-for-provi). The `cluster.yml` file (from the steps above) that is included in this folder automatically deploys the cluster with the EBS IAM policies, but you need to install the EBS CSI drivers. This can be done through the AWS Management Console for simplicity, or via a CLI command as below. Replace `CLUSTER_NAME`, `AWS_REGION` and `AWS_ACCOUNT` with details that are specific to your deployment.
-
- ```bash
- eksctl create iamserviceaccount --name ebs-csi-controller-sa --namespace kube-system --cluster CLUSTER_NAME --region AWS_REGION --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy --approve --role-only --role-name AmazonEKS_EBS_CSI_DriverRole
-
- eksctl create addon --name aws-ebs-csi-driver --cluster CLUSTER_NAME --region AWS_REGION --service-account-role-arn arn:aws:iam::AWS_ACCOUNT:role/AmazonEKS_EBS_CSI_DriverRole --force
- ```
-
-5. Once the deployment is completed, provision the Secrets Manager IAM and CSI driver. Use `besu` (or equivalent) for `NAMESPACE` and replace `CLUSTER_NAME`, `AWS_REGION` and `AWS_ACCOUNT` with details that are specific to your deployment.
-
- ```bash
- helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts
- helm install --namespace kube-system --create-namespace csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver
- kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/deployment/aws-provider-installer.yaml
-
- POLICY_ARN=$(aws --region AWS_REGION --query Policy.Arn --output text iam create-policy --policy-name quorum-node-secrets-mgr-policy --policy-document '{
- "Version": "2012-10-17",
- "Statement": [ {
- "Effect": "Allow",
- "Action": ["secretsmanager:CreateSecret","secretsmanager:UpdateSecret","secretsmanager:DescribeSecret","secretsmanager:GetSecretValue","secretsmanager:PutSecretValue","secretsmanager:ReplicateSecretToRegions","secretsmanager:TagResource"],
- "Resource": ["arn:aws:secretsmanager:AWS_REGION:AWS_ACCOUNT:secret:besu-node-*"]
- } ]
- }')
-
- # If you have deployed the above policy before, you can acquire its ARN:
- POLICY_ARN=$(aws iam list-policies --scope Local \
- --query 'Policies[?PolicyName==`quorum-node-secrets-mgr-policy`].Arn' \
- --output text)
-
- eksctl create iamserviceaccount --name quorum-node-secrets-sa --namespace NAMESPACE --region=AWS_REGION --cluster CLUSTER_NAME --attach-policy-arn "$POLICY_ARN" --approve --override-existing-serviceaccounts
- ```
-
- :::warning
-
- The above command creates a service account called `quorum-node-secrets-sa` and is preconfigured in the helm charts override `values.yml` files, for ease of use.
-
- :::
-
-6. Optionally, deploy the [kubernetes dashboard](https://github.com/ConsenSys/quorum-kubernetes/tree/master/aws/templates/k8s-dashboard).
-
-7. You can now use your cluster and you can deploy [Helm charts](charts.md) to it.
-
-### Azure Kubernetes Service
-
-[Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) is another popular cloud platform that you can use to deploy Besu. To create a cluster in Azure, you must install the [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) and have admin rights on your Azure subscription to enable some preview features on AKS.
-
-The [template](https://github.com/ConsenSys/quorum-kubernetes/tree/master/azure) comprises the base infrastructure used to build the cluster and other resources in Azure. We also make use Azure native services and features after the cluster is created. These include:
-
-- [AAD pod identities](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity).
-- [Secrets Store CSI drivers](https://docs.microsoft.com/en-us/azure/key-vault/general/key-vault-integrate-kubernetes).
-- Dynamic storage classes backed by Azure Files. The [volume claims](https://docs.microsoft.com/en-us/azure/aks/azure-disks-dynamic-pv) are fixed sizes and can be updated as you grow via helm updates, and won't need to re-provision the underlying storage class.
-- [CNI](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni) networking mode for AKS. By default, AKS clusters use `kubenet`, to create a virtual network and subnet. Nodes get an IP address from a virtual network subnet. Network address translation (NAT) is then configured on the nodes, and pods receive an IP address "hidden" behind the node IP.
-
- :::note
-
- This approach reduces the number of IP addresses you must reserve in your network space for pods to use, but constrains what can connect to the nodes from outside the cluster (for example, on-premise nodes or other cloud providers).
-
- :::
-
-AKS Container Networking Interface (CNI) provides each pod with an IP address from the subnet, and can be accessed directly. These IP addresses must be unique across your network space, and must be planned in advance. Each node has a configuration parameter for the maximum number of pods that it supports. The equivalent number of IP addresses per node are then reserved up front for that node. This approach requires more planning, and can leads to IP address exhaustion as your application demands grow, however makes it easier for external nodes to connect to your cluster.
-
-:::warning
-
-Please do not create more than one AKS cluster in the same subnet. AKS clusters may not use `169.254.0.0/16`, `172.30.0.0/16`, `172.31.0.0/16`, or `192.0.2.0/24` for the Kubernetes service address range.
-
-:::
-
-To provision the cluster:
-
-1. Enable the preview features that allow you to use AKS with CNI, and a managed identity to authenticate and run cluster operations with other services. We also enable [AAD pod identities](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) which use the managed identity. This is in preview, so you must enable this feature by registering the `EnablePodIdentityPreview` feature:
-
- ```bash
- az feature register --name EnablePodIdentityPreview --namespace Microsoft.ContainerService
- ```
-
- This takes a little while and you can check on progress by running:
-
- ```bash
- az feature list --namespace Microsoft.ContainerService -o table
- ```
-
- Install or update your local Azure CLI with preview features:
-
- ```bash
- az extension add --name aks-preview
- az extension update --name aks-preview
- ```
-
-1. Create a resource group if you don't already have one:
-
- ```bash
- az group create --name BesuGroup --location "East US"
- ```
-
-1. Deploy the template:
-
- 1. Navigate to the [Azure portal](https://portal.azure.com), select **+ Create a resource** in the upper left corner.
- 1. Search for `Template deployment (deploy using custom templates)` and select **Create**.
- 1. Select **Build your own template in the editor**.
- 1. Remove the contents (JSON) in the editor and paste in the contents of [`azuredeploy.json`](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/azure/arm/azuredeploy.json)
- 1. Select **Save**.
- 1. Input provisioning parameters in the displayed user interface.
-
-1. Provision the drivers:
-
- 1. Run the [bootstrap](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/azure/scripts/bootstrap.sh) script.
- 1. Use `besu` for `AKS_NAMESPACE`, and update `AKS_RESOURCE_GROUP`, `AKS_CLUSTER_NAME`, and `AKS_MANAGED_IDENTITY` in the commands below to match your settings and deployed resources from step 3.
-
- ```bash
- ./scripts/bootstrap.sh "AKS_RESOURCE_GROUP" "AKS_CLUSTER_NAME" "AKS_MANAGED_IDENTITY" "AKS_NAMESPACE"
- ```
-
-1. You can now use your cluster and you can deploy [Helm charts](charts.md) to it.
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/index.md b/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/index.md
deleted file mode 100644
index bd1dea65869..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/index.md
+++ /dev/null
@@ -1,138 +0,0 @@
----
-title: Deploy a Hyperledger Besu private network with Kubernetes
-description: Deploying Hyperledger Besu with Kubernetes
-tags:
- - private networks
----
-
-# Deploy Besu using Kubernetes
-
-Use the [reference implementations](https://github.com/ConsenSys/besu-kubernetes) to install private networks using Kubernetes (K8s). Reference implementations are available using:
-
-- [Helm](https://github.com/ConsenSys/quorum-kubernetes/tree/master/helm).
-- [Helmfile](https://github.com/roboll/helmfile).
-- [`kubectl`](https://github.com/ConsenSys/besu-kubernetes/tree/master/playground/kubectl).
-
-Familiarize yourself with the reference implementations and customize them for your requirements.
-
-## Quorum-Kubernetes
-
-[Quorum-Kubernetes](https://github.com/ConsenSys/quorum-Kubernetes) is a repository containing Kubernetes manifests and Helm charts that you can customize and deploy on a local cluster or in the cloud.
-
-:::important
-
-We recommend starting with the [playground](https://github.com/ConsenSys/quorum-kubernetes/tree/master/playground) directory and working through the example setups before moving to the [`Helm charts`](https://github.com/ConsenSys/quorum-kubernetes/tree/master/helm/) directory.
-
-:::
-
-The `helm` directory contains charts for the various components, and each chart has a `cluster` map with features that you can toggle.
-
-```bash
-cluster:
- provider: local # choose from: local | aws | azure
- cloudNativeServices: false # set to true to use Cloud Native Services (SecretsManager and IAM for AWS; KeyVault & Managed Identities for Azure)
-```
-
-Setting `cluster.cloudNativeServices: true` stores keys in AWS Secrets Manager or Azure Key Vault instead of Kubernetes Secrets, and will also make use of AWS IAM or Azure Managed Identities for the pods.
-
-### Cloud support
-
-The repository's `helm` charts support on-premise and cloud providers such as AWS, Azure, GCP, IBM etc. You can configure the provider in the [values.yml](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/values/genesis-besu.yml) file of the respective charts by setting `cluster.provider` to `local`, `aws`, or `azure`. If you use GCP, IBM etc., please set `cluster.provider: local` and `cluster.cloudNativeServices: false`.
-
-The repository also contains [Azure ARM templates](https://github.com/ConsenSys/quorum-kubernetes/tree/master/azure) and [AWS `eksctl` templates](https://github.com/ConsenSys/quorum-kubernetes/tree/master/aws) to deploy the required base infrastructure.
-
-## Limitations
-
-When using multi-clusters, Kubernetes load balancers disallow TCP and UDP traffic on the same port, which inhibits discovery working natively for each pod. Use the following solutions to mitigate this limitation:
-
-- Disallow discovery and use static nodes to allow only TCP traffic. This isn't an issue for load balancers or exposing nodes publicly.
-- If you need to use discovery, use something such as [CNI](#cni) which is supported by all major cloud providers, and the cloud templates already have CNI implemented.
-
-### CNI
-
-With the traditional `kubenet` networking mode, nodes get an IP from the virtual network subnet. Each node in turn uses NAT to configure the pods so that they reach other pods on the virtual network. This limits where they can reach but also more specifically what can reach them. For example, an external VM which must have custom routes does not scale well.
-
-![without-CNI](../../../assets/images/kubernetes-1.jpeg)
-
-CNI, on the other hand, allows every pod to get a unique IP directly from the virtual subnet which removes this restriction. Therefore, it has a limit on the maximum number of pods that can be spun up, so you must plan ahead to avoid IP exhaustion.
-
-![with-CNI](../../../assets/images/kubernetes-2.jpeg)
-
-## Multi-cluster
-
-You must enable [CNI](#cni) to use multi-cluster, or to connect external nodes to an existing Kubernetes cluster. To connect multiple clusters, they must each have different CIDR blocks to ensure no conflicts, and the first step is to peer the VPCs or VNets together and update the route tables. From that point on you can use static nodes and pods to communicate across the cluster.
-
-The same setup also works to connect external nodes and business applications from other infrastructure, either in the cloud or on premise.
-
-![multi-cluster](../../../assets/images/kubernetes-3.png)
-
-## Concepts
-
-### Namespaces
-
-In Kubernetes, [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) provide a mechanism for isolating groups of resources within a single cluster. Both namespaces and resources (for example, Stateful Sets or Services) within a namespace must be unique, but resources across namespaces don't need to be.
-
-:::note
-
-Namespace-based scoping is not applicable for cluster-wide objects (for example, Storage Class or Persistent Volumes).
-
-:::
-
-### Nodes
-
-Consider using Stateful Sets instead of Deployments for Besu. The term 'client node' refers to bootnode, validator and member/RPC nodes. For Besu nodes, we only use CLI arguments to keep things consistent.
-
-### Role-based access controls
-
-We encourage using role-based access controls (RBACs) for access to the private key of each node, that is, only a specific pod or statefulset is allowed to access a specific secret.
-
-If you need to specify a Kube configuration file for each pod, use the `KUBE_CONFIG_PATH` variable.
-
-### Storage
-
-We use separate data volumes to store the blockchain data. This is similar to using separate volumes to store data when using docker containers natively or docker-compose. This is done for a few reasons:
-
-- Containers are mortal and we do not want to store data on them.
-- Kubernetes host nodes can fail and we want the chain data to persist.
-
-Ensure that you provide enough data storage capacity for all nodes on the cluster. Select the appropriate type of [Storage Class](https://kubernetes.io/docs/concepts/storage/storage-classes/) based on your cloud provider. In the templates, the size of the [volume claims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) is set to 20Gb by default; you can change this depending on your needs. If you have a different storage account than the one in the charts, you may edit those [Storage Classes](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/charts/besu-node/templates/node-storage.yaml).
-
-When using Persistent Volume Claims, set the `allowVolumeExpansion` to `true`. This helps keep costs low and enables growing the volume over time rather than creating new volumes and copying data across.
-
-### Monitoring
-
-We recommend deploying metrics to get an overview of the network, nodes, and volumes. You can also create alerts.
-
-Besu publishes metrics to Prometheus, and you can configure metrics using the kubernetes scraper configuration. We also have custom Grafana dashboards to monitor the blockchain.
-
-:::note
-
-Refer to `values/monitoring.yml` to configure the alerts per your requirements (for example slack or email).
-
-:::
-
-```bash
-cd helm
-helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
-helm repo update
-helm install monitoring prometheus-community/kube-prometheus-stack --version 34.10.0 --namespace=besu --create-namespace --values ./values/monitoring.yml --wait
-kubectl --namespace besu apply -f ./values/monitoring/
-```
-
-You can configure Besu to suit your environment. For example, use the Elastic charts to log to a file that you can parse using Logstash into an ELK cluster.
-
-```bash
-cd helm
-helm repo add elastic https://helm.elastic.co
-helm repo update
-# if on cloud
-helm install elasticsearch --version 7.17.1 elastic/elasticsearch --namespace besu --create-namespace --values ./values/elasticsearch.yml
-# if local - set the replicas to 1
-helm install elasticsearch --version 7.17.1 elastic/elasticsearch --namespace besu --create-namespace --values ./values/elasticsearch.yml --set replicas=1 --set minimumMasterNodes: 1
-helm install kibana --version 7.17.1 elastic/kibana --namespace besu --values ./values/kibana.yml
-helm install filebeat --version 7.17.1 elastic/filebeat --namespace besu --values ./values/filebeat.yml
-```
-
-### Ingress Controllers
-
-If you require the ingress controllers for the RPC calls or the monitoring dashboards, we have provided example [rules](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/ingress/ingress-rules-besu.yml) that are pre-configured for common use cases. Use these as a reference and develop solutions to match your network topology and requirements.
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/maintenance.md b/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/maintenance.md
deleted file mode 100644
index a32bf1a15b2..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/maintenance.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: Maintenance
-sidebar_position: 5
-description: Maintenance for Besu on a Kubernetes cluster
-tags:
- - private networks
----
-
-# Maintenance
-
-You can perform maintenance for Besu on a Kubernetes cluster.
-
-## Prerequisites
-
-- Clone the [Quorum-Kubernetes](https://github.com/ConsenSys/quorum-kubernetes) repository
-- A [running Kubernetes cluster](cluster.md) with a [network](charts.md)
-- Install [Kubectl](https://kubernetes.io/docs/tasks/tools/)
-- Install [Helm3](https://helm.sh/docs/intro/install/)
-
-## Update a persistent volume claim size
-
-Over time, as the chain grows, so will the amount of space used by the persistent volume claim (PVC). As of Kubernetes v1.11, [certain types of Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/#allow-volume-expansion) allow volume resizing. Production charts for Azure use Azure Files, and on AWS use EBS Block Store which allow for volume expansion.
-
-To update the volume size, you must update the override values file. For example, to increase the size on the transaction nodes volumes, add the following snippet to the [`txnode values.yml`](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/values/txnode.yml) file, with the new size limit (the following example uses 50Gi).
-
-```bash
-storage:
- sizeLimit: "50Gi"
- pvcSizeLimit: "50Gi"
-```
-
-Once complete, update the node via helm:
-
-```bash
-helm upgrade tx-1 ./charts/besu-node --namespace besu --values ./values/txnode.yml
-```
-
-## Update Besu versions
-
-:::important
-
-When updating Besu nodes across a cluster, perform the updates as a rolling update and not all at once, especially for the validator pool. If all the validators are taken offline, the chain halts, and you must wait for round changes to expire before blocks are created again.
-
-:::
-
-Updates for Besu can be done via Helm in exactly the same manner as other applications. Alternatively, this can be done via `kubectl`. This example updates a node called `besu-validator-3`:
-
-1. Set the update policy to use rolling updates (if not done already):
-
- ```bash
- kubectl patch statefulset besu-validator-3 --namespace besu -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
- ```
-
-2. Update the Besu version via Helm:
-
- ```bash
- helm upgrade bootnode-1 ./charts/besu-node --namespace besu --values ./values/bootnode.yml --set image.besu.tag=21.10.0
- ```
-
- Or via `kubectl`:
-
- ```bash
- kubectl patch statefulset besu-validator-3 --namespace besu --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"hyperledger/besu:21.10.0"}]'
- ```
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/nat-manager.md b/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/nat-manager.md
deleted file mode 100644
index 5a66ede1f48..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/nat-manager.md
+++ /dev/null
@@ -1,221 +0,0 @@
----
-title: Configure Kubernetes mode in NAT manager
-sidebar_position: 9
-description: Tutorial to configure Kubernetes mode for Hyperledger Besu Nat Manager
-tags:
- - private networks
----
-
-# Configure Kubernetes mode in NAT Manager
-
-Use [`--nat-method=AUTO`](../../../public-networks/how-to/connect/specify-nat.md#auto) or [`--nat-method=KUBERNETES`](../../../public-networks/how-to/connect/specify-nat.md#kubernetes) CLI options to let the Besu node automatically configure its IP address and ports.
-
-Use mode [`--nat-method=NONE`](../../../public-networks/how-to/connect/specify-nat.md#none) to be able to set your Besu ports and IP address manually.
-
-Default mode is [`AUTO`](../../../public-networks/how-to/connect/specify-nat.md#auto) but Besu will fallback to [`NONE`](../../../public-networks/how-to/connect/specify-nat.md#none) mode if automatic configuration fails.
-
-:::info The following log shows fallback to [`NONE`](../../../public-networks/how-to/connect/specify-nat.md#none) mode after an automatic detection failure.
-
- ```
- INFO | KubernetesNatManager | Starting kubernetes NAT manager.
- DEBUG | KubernetesNatManager | Trying to update information using Kubernetes client SDK.
- DEBUG | NatService | Nat manager failed to configure itself automatically due to the following reason Service not found. NONE mode will be used
- INFO | NetworkRunner | Starting Network.
- ```
-
-:::
-
-## Automatic configuration
-
-Follow 3 steps to configure Besu for automatic IP address and ports detection on Kubernetes:
-
-1. [Create a load balancer](#1-create-a-load-balancer)
-1. [Check if the load balancer is properly deployed](#2-check-if-the-load-balancer-is-properly-deployed)
-1. [Deploy Besu](#3-deploy-besu)
-
-### 1. Create a load balancer
-
-Deploy a `LoadBalancer` service for Besu to recover IP address and ports.
-
-Here is an example that you can customize with your own ports and routing rules.
-
-```yaml
----
-apiVersion: v1
-kind: Service
-metadata:
- labels:
- app.kubernetes.io/name: besu
- app.kubernetes.io/release: "1.0.0"
- name: besu
-spec:
- ports:
- - name: "json-rpc"
- port: 8545
- targetPort: 8545
- - name: "rlpx"
- port: 30303
- targetPort: 30303
- selector:
- app.kubernetes.io/name: besu
- app.kubernetes.io/release: "1.0.0"
- type: LoadBalancer
-```
-
-This service example lists the rules for the different ports used by Besu (`json-rpc` and` rlpx`). The default value is used for `discovery`.
-
-### 2. Check if the load balancer is properly deployed
-
-Verify the load balancer readiness before launching Besu.
-
-Run `kubectl describe services besu` to check the service status.
-
-The command should display the following information:
-
-```bash
-Name: besu
-Namespace: default
-Labels: app.kubernetes.io/name=besu
- app.kubernetes.io/release=1.0.0
-Annotations: kubectl.kubernetes.io/last-applied-configuration:
- {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/name":"besu","app.kubernetes.io/release":"1....
-Selector: app.kubernetes.io/name=besu,app.kubernetes.io/release=1.0.0
-Type: LoadBalancer
-IP: --------
-LoadBalancer Ingress: ******
-```
-
-The load balancer must have an IP address displayed in place of `******` on the `LoadBalancer Ingress` line to be ready.
-
-Run the `kubectl describe services besu` command again until the load balancer IP address appears in the output.
-
-### 3. Deploy Besu
-
-When steps 1 and 2 are completed, deploy Besu using the following YAML example:
-
-```yaml
----
-apiVersion: v1
-kind: ConfigMap
-metadata:
- name: besu-config
- labels:
- app.kubernetes.io/name: besu
- app.kubernetes.io/release: 1.0.0
-data:
- BESU_LOGGING: "INFO"
- BESU_NETWORK: "dev"
- BESU_P2P_ENABLED: "true"
- BESU_RPC_HTTP_ENABLED: "true"
- BESU_RPC_HTTP_APIS: "eth,net,web3,debug,admin"
- KUBE_CONFIG_PATH: "/opt/besu/shared/kube-config"
----
-apiVersion: extensions/v1beta1
-kind: Deployment
-metadata:
- name: besu
- labels:
- app.kubernetes.io/name: besu
- app.kubernetes.io/release: "1.0.0"
-spec:
- replicas: 1
- strategy: {}
- template:
- metadata:
- creationTimestamp: null
- labels:
- app.kubernetes.io/name: besu
- app.kubernetes.io/release: "1.0.0"
- spec:
- containers:
- - name: besu
- image: "hyperledger/besu:latest"
- imagePullPolicy: Always
- ports:
- - containerPort: 8545
- - containerPort: 30303
- envFrom:
- - configMapRef:
- name: besu-config
- restartPolicy: Always
-status: {}
-```
-
-## Automatic detection errors
-
-:::danger
-
-Automatic detection error messages do not prevent you to use Besu.
-
-Try the fix indicated for each error or use [`--nat-method=KUBERNETES`](../../../public-networks/how-to/connect/specify-nat.md#kubernetes) CLI option and [set IP address and port manually](../../../public-networks/how-to/connect/configure-ports.md).
-
-:::
-
-Possible errors messages for Kubernetes automatic detection failure:
-
-- [`Service not found`](#service-not-found-error-message)
-- [`Forbidden`](#forbidden-error-message)
-- [`Ingress not found`](#ingress-not-found-error-message)
-
-### `Service not found` error message
-
-- **Error message:** `Nat manager failed to configure itself automatically due to the following reason Service not found. NONE mode will be used`
-- **Cause:** load balancer did start correctly or has the incorrect name.
-- **Fix:** check and modify load balancer YAML configuration and restart service.
-
-:::info Example error log
-
- ```
- INFO | KubernetesNatManager | Starting kubernetes NAT manager.
- DEBUG | KubernetesNatManager | Trying to update information using Kubernetes client SDK.
- DEBUG | NatService | Nat manager failed to configure itself automatically due to the following reason Service not found. NONE mode will be used
- INFO | NetworkRunner | Starting Network.
- ```
-
-:::
-
-### `Forbidden` error message
-
-- **Error message:** `Nat manager failed to configure itself automatically due to the following reason Forbidden. NONE mode will be used`
-- **Cause:** Besu don't have permission to list the services via the Kubernetes API to retrieve IP address and ports from the load balancer.
-- **Fix:** Give it the required permissions using [Role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).
-
- If you can't manage permissions, define the IP address and ports manually with [`NONE`](../../../public-networks/how-to/connect/specify-nat.md#none) mode
-
-:::info Example error log
-
- ```
- INFO | KubernetesNatManager | Starting kubernetes NAT manager.
- DEBUG | KubernetesNatManager | Trying to update information using Kubernetes client SDK.
- DEBUG | NatService | Nat manager failed to configure itself automatically due to the following reason Forbidden. NONE mode will be used
- INFO | NetworkRunner | Starting Network.
- ```
-
-:::
-
-:::tip
-
-For development environment, the permission issue can be fixed by running `kubectl create clusterrolebinding myapp-view-binding --clusterrole=admin --serviceaccount=default:default`
-
-This command should only be used on development environment and not in production environment.
-
-In production environment, require a finer management of permissions using Kubernetes [Role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).
-
-:::
-
-### `Ingress not found` error message
-
-- **Error message:** `Nat manager failed to configure itself automatically due to the following reason Ingress not found. NONE mode will be used`
-- **Cause:** Load balancer did not finish to recover an IP address.
-- **Fix:** [Check that the load balancer is properly deployed](#2-check-if-the-load-balancer-is-properly-deployed) before launching Besu.
-
-:::info Example error log
-
- ```
- INFO | KubernetesNatManager | Starting kubernetes NAT manager.
- DEBUG | KubernetesNatManager | Trying to update information using Kubernetes client SDK.
- DEBUG | NatService | Nat manager failed to configure itself automatically due to the following reason Ingress not found. NONE mode will be used
- INFO | NetworkRunner | Starting Network.
- ```
-
-:::
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/playground.md b/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/playground.md
deleted file mode 100644
index 67962456a62..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/playground.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Local playground
-sidebar_position: 1
-description: Deploying a Hyperledger Besu private network locally with Kubernetes
-tags:
- - private networks
----
-
-# Deploy in a local environment
-
-The [playground](https://github.com/ConsenSys/quorum-kubernetes/tree/master/playground) was created to provide an opportunity to deploy [quorum-kubernetes](https://github.com/ConsenSys/quorum-kubernetes/) in a local environment before attempting in a live environment (such as in the cloud or on-premise). Local deployment can be done with any local Kubernetes tool. Minikube and Rancher Desktop have been tested to work, but any complete Kubernetes solution with support for `kubectl` should suffice.
-
-## Steps
-
-1. Navigate to the playground [`README`](https://github.com/ConsenSys/quorum-kubernetes/tree/master/playground).
-1. Ensure that your system meets the requirements specified.
-1. Choose your Ethereum client (Hyperledger Besu or GoQuorum): `quorum-besu` or `quorum-go`.
-1. Choose your consensus algorithm. The playground supports Clique, Ethash (PoW), and IBFT2 for Besu, and IBFT for GoQuorum.
-1. Follow the instructions from the `README` for the chosen client and consensus algorithm folder.
-
-## Important notes
-
-Consider the following when deploying and developing with the playground:
-
-- The playground is created specifically for developers and operators to become familiar with the deployment of Besu in a Kubernetes environment in preparation for going into a cloud or on-premise environment. Thus, it should **not** be deployed into a production environment.
-- The playground is not a complete reflection of the `helm` charts as it does not use `Helm`, but rather static or non-templated code that is deployed through `kubectl apply -f`. This means that without `Helm` there's a significant amount of repeated code. This is fine for development but not ideal for a production environment.
-- The playground uses static/hard-coded keys. Automatic key generation is only supported in `helm` charts.
-- As the playground is for local development, no cloud integration or lifecycle support is offered.
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/production.md b/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/production.md
deleted file mode 100644
index a9cd60d9da3..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/production.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: Production
-sidebar_position: 6
-description: Deploying Besu Helm Charts for production on a Kubernetes cluster
-tags:
- - private networks
----
-
-# Deploy for production
-
-You can deploy Besu for production on a Kubernetes cluster.
-
-## Prerequisites
-
-- Clone the [Quorum-Kubernetes](https://github.com/ConsenSys/quorum-kubernetes) repository
-- A [running Kubernetes cluster](cluster.md)
-- [Kubectl](https://kubernetes.io/docs/tasks/tools/)
-- [Helm3](https://helm.sh/docs/intro/install/)
-
-## Overview
-
-To get things production-ready, we'll use the same charts, and set a few of the values in the `cluster` map as in the [Deploy](#deploy-the-network) section.
-
-:::warning
-
-The following tutorial ONLY supports AWS and Azure currently. Other cloud providers will be added in time.
-
-:::
-
-:::warning
-
-We recommend using AWS RDS or Azure PostgreSQL in High Availability mode for any Tessera nodes that you use. The templates don't include that functionality. They can be provisioned with CloudFormation or Azure Resource Manager, respectively. Once created, please specify the connection details to the `values.yml`.
-
-:::
-
-## Deploy
-
-### Check that you can connect to the cluster with `kubectl`
-
-Once you have a [cluster running](cluster.md), verify `kubectl` is connected to cluster with:
-
-```bash
-kubectl version
-Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.1", GitCommit:"86ec240af8cbd1b60bcc4c03c20da9b98005b92e", GitTreeState:"clean", BuildDate:"2021-12-16T11:41:01Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"}
-Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:35:25Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"linux/amd64"}
-```
-
-### Deploy the network
-
-For the rest of this tutorial we use Helm charts. After you have cloned the [Quorum-Kubernetes](https://github.com/ConsenSys/quorum-kubernetes) repository, change the directory to `helm` for the rest of this tutorial.
-
-```bash
-cd helm
-```
-
-Each helm chart has the following keys that must be set.
-
-Specify either `aws` or `azure` for the `cluster.provider`. Additionally, set `cloudNativeServices: true` and `reclaimPolicy: Retain` so that it looks like the following for AWS:
-
-```bash
-cluster:
- provider: aws # choose from: aws | azure
- cloudNativeServices: true # set to true to use Cloud Native Services (SecretsManager and IAM for AWS; KeyVault & Managed Identities for Azure)
- reclaimPolicy: Retain # set to either Retain or Delete; note that PVCs and PVs will still exist after a 'helm delete'. Setting to Retain will keep volumes even if PVCs/PVs are deleted in kubernetes. Setting to Delete will remove volumes from EC2 EBS when PVC is deleted
-```
-
-Follow the steps outlined in the [deploy charts](charts.md) tutorial to deploy the network.
-
-## Best practices
-
-The most important thing is to plan your network out on paper first and then test it in a Dev cluster to make sure connectivity works with your applications and you get the required throughput in transactions per second (TPS). We also recommend you test the entire process, from provisioning infrastructure to updating nodes on a Dev cluster, prior to launching your production network.
-
-By default, the cloud Kubernetes clusters take care of availability and do multi-zones within a region. The scheduler also ensures that deployments are spread out across zones. Where possible, we recommend you use multiple bootnodes and static nodes to speed up peering.
-
-You can connect to APIs and services outside the cluster normally, but connecting into your network (such as adding an on-premise node to the network) might require more configuration. Please check the [limitations](index.md#limitations) and use CNI where possible. To connect an external node to your cluster, the easiest way is to use a VPN as seen in the following [multi-cluster](#multi-cluster-support) setup.
-
-Finally, we recommend setting up monitoring and alerting from the beginning, so you can get early warnings of issues rather than after failure. We have a monitoring chart which uses Grafana and you can use it with Alertmanager to create alerts or alternatively alert via Cloudwatch or Azure Monitoring.
-
-## Multi-cluster support
-
-When CNI is used, multi-cluster support is simple, but you have to cater for cross-cluster DNS names. Ideally, you want to create two separate VPCs (or VNets) and make sure they have different base CIDR blocks so that IP addresses don't conflict. Once done, peer the VPCs together and update the subnet route table, so they are effectively a giant single network.
-
-![multi-cluster](../../../assets/images/kubernetes-3.png)
-
-When you [spin up clusters](cluster.md), use [CNI](index.md#limitations) and CIDR blocks to match the subnet's CIDR settings. Then deploy the genesis chart on one cluster and copy across the genesis file and static nodes config maps. Depending on your DNS settings, they might be fine as is, or they might need to be actual IP addresses. That is, you can provision cluster B only after cluster A has Besu nodes up and running.
-
-Deploy the network on cluster A, and then on cluster B. Besu nodes on cluster A should work as expected, and Besu nodes on cluster B should use the list of peers provided to communicate with the nodes on cluster A.
-
-Keeping the list of peers on the clusters live and up to date can be challenging, so we recommend using the cloud service provider's DNS service such as Route 53 or Azure DNS and adapting the charts to create entries for each node when it comes up.
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/quorum-explorer.md b/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/quorum-explorer.md
deleted file mode 100644
index cd69831c806..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/kubernetes/quorum-explorer.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: Using the Quorum Explorer
-sidebar_position: 4
-description: Using the Quorum Explorer on a Kubernetes cluster
-tags:
- - private networks
----
-
-# Use the Quorum Explorer
-
-You can use the Quorum Explorer on a Kubernetes cluster.
-
-## Prerequisites
-
-- Clone the [Quorum-Kubernetes](https://github.com/ConsenSys/quorum-kubernetes) repository
-- A [running Kubernetes cluster](cluster.md)
-- [Kubectl](https://kubernetes.io/docs/tasks/tools/)
-- [Helm3](https://helm.sh/docs/intro/install/)
-- [Existing network](charts.md)
-
-## Deploy the Quorum Explorer helm chart
-
-[Quorum-Explorer](https://github.com/ConsenSys/quorum-explorer) as a lightweight blockchain explorer. The Quorum Explorer is **not** recommended for use in production and is intended for demonstration or development purposes only.
-
-The explorer can provide an overview over the whole network, such as block information, voting or removing validators from the network, and demonstrates using the `SimpleStorage` smart contract with privacy enabled, and sending transactions between wallets in one interface.
-
-To use the explorer, update the [Quorum-Explorer values file](https://github.com/ConsenSys/quorum-kubernetes/blob/5920caff6dd15b4ca17f760ad9e4d7d2e43b41a1/helm/values/explorer-besu.yaml) with your node details and endpoints, and then [deploy](charts.md).
-
-## Nodes
-
-The **Nodes** page provides an overview of the nodes on the network. Select the node you would like to interact with from the drop-down on the top right, and you'll get details of the node, block height, peers, queued transactions etc.
-
-![`k8s-explorer`](../../../assets/images/kubernetes-explorer.png)
-
-## Validators
-
-The **Validators** page simulates a production environment or consortium where each node individually runs API calls to vote to add a validator or remove an existing validator.
-
-When using the buttons to remove, discard pending validators, or proposing a validator, the app sends an API request to the selected node in the drop-down only. To add or remove a validator you need to select a majority of the existing validator pool individually, and perform the vote API call by clicking the button. Each node can call a discard on the voting process during or after the validator has been added.
-
-The vote calls made from non-validator nodes have no effect on overall consensus.
-
-![`k8s-explorer-validators`](../../../assets/images/kubernetes-explorer-validators.png)
-
-## Explorer
-
-The **Explorer** page gives you the latest blocks from the chain and the latest transactions as they occur on the network. In addition, you can search by block number or transaction hash using the respective search bar.
-
-![`k8s-explorer-explorer`](../../../assets/images/kubernetes-explorer-explorer.png)
-
-## Contracts
-
-Use the **Contracts** page to compile and deploy a smart contract. Currently, the only contract available for deployment through the app is the `SimpleStorage` contract. However, in time, we plan to add more contracts to that view.
-
-In this example, we deploy from `member-1` and select `member-1` and `member-3` in the **Private For** multi-select. Then click on `Compile` and `Deploy`
-
-![`k8s-explorer-contracts-1`](../../../assets/images/kubernetes-explorer-contracts-1.png)
-
-Once deployed, you can interact with the contract. As this is a new transaction, select `member-1` and `member-3` in **Interact** multi-select, and then click on the appropriate method call to `get` or `set` the value at the deployed contract address.
-
-![`k8s-explorer-contracts-set`](../../../assets/images/kubernetes-explorer-contracts-set.png)
-
-To test the private transaction functionality, select `member-2` from the drop-down on the top right, you'll notice that you are unable to interact with the contract because `member-2` was not part of the transaction. Only `members-1` and `member-3` responds correctly.
-
-## Wallet
-
-The **Wallet** page gives you the functionality to send simple ETH transactions between accounts by providing the account's private key, the recipient's address, and transfer amount in Wei.
-
-![`k8s-explorer-wallet`](../../../assets/images/kubernetes-explorer-wallet.png)
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/permissioning/_category_.json b/versioned_docs/version-23.10.0/private-networks/tutorials/permissioning/_category_.json
deleted file mode 100644
index da14c12d4b3..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/permissioning/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Create a permissioned network",
- "position": 7
-}
diff --git a/versioned_docs/version-23.10.0/private-networks/tutorials/permissioning/index.md b/versioned_docs/version-23.10.0/private-networks/tutorials/permissioning/index.md
deleted file mode 100644
index 054469e436d..00000000000
--- a/versioned_docs/version-23.10.0/private-networks/tutorials/permissioning/index.md
+++ /dev/null
@@ -1,497 +0,0 @@
----
-title: Create a permissioned network
-sidebar_position: 1
-description: Hyperledger Besu create a permissioned network
-tags:
- - private networks
----
-
-# Create a permissioned network
-
-The following steps set up a permissioned network with local node and account permissions. The network uses the [IBFT 2.0 proof of authority consensus protocol].
-
-:::danger
-
-A permissioned Ethereum network as described here is not protected against all attack vectors. We recommend applying defense in depth to protect your infrastructure.
-
-:::
-
-## Prerequisites
-
-- [Hyperledger Besu](../../get-started/install/binary-distribution.md)
-- [curl (or similar Web service client)](https://curl.haxx.se/download.html)
-
-## Steps
-
-### 1. Create folders
-
-Each node requires a data directory for the blockchain data.
-
-Create directories for your permissioned network and each of the three nodes, and a data directory for each node:
-
-```bash
-Permissioned-Network/
-├── Node-1
-│ ├── data
-├── Node-2
-│ ├── data
-└── Node-3
-│ ├── data
-└── Node-4
- ├── data
-```
-
-### 2. Create the configuration file
-
-The configuration file defines the [IBFT 2.0 genesis file](../../how-to/configure/consensus/ibft.md#genesis-file) and the number of node key pairs to generate.
-
-The configuration file has two nested JSON nodes. The first is the `genesis` property defining the IBFT 2.0 genesis file, except for the `extraData` string, which Besu generates automatically in the resulting genesis file. The second is the `blockchain` property defining the number of key pairs to generate.
-
-Copy the following configuration file definition to a file called `ibftConfigFile.json` and save it in the `Permissioned-Network` directory:
-
-```json
-{
- "genesis": {
- "config": {
- "chainId": 1337,
- "berlinBlock": 0,
- "ibft2": {
- "blockperiodseconds": 2,
- "epochlength": 30000,
- "requesttimeoutseconds": 4
- }
- },
- "nonce": "0x0",
- "timestamp": "0x58ee40ba",
- "gasLimit": "0x47b760",
- "difficulty": "0x1",
- "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365",
- "coinbase": "0x0000000000000000000000000000000000000000",
- "alloc": {
- "fe3b557e8fb62b89f4916b721be55ceb828dbd73": {
- "privateKey": "8f2a55949038a9610f50fb23b5883af3b4ecb3c3bb792cbcefbd1542c692be63",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "0xad78ebc5ac6200000"
- },
- "627306090abaB3A6e1400e9345bC60c78a8BEf57": {
- "privateKey": "c87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "90000000000000000000000"
- },
- "f17f52151EbEF6C7334FAD080c5704D77216b732": {
- "privateKey": "ae6ae8e5ccbfb04590405997ee2d52d2b330726137b875053c36d94e974d162f",
- "comment": "private key and this comment are ignored. In a real chain, the private key should NOT be stored",
- "balance": "90000000000000000000000"
- }
- }
- },
- "blockchain": {
- "nodes": {
- "generate": true,
- "count": 4
- }
- }
-}
-```
-
-:::danger Security warning
-
-Don't use the accounts in the genesis file on Mainnet or any public network except for testing. The private keys display, which means the accounts are not secure.
-
-:::
-
-### 3. Generate node keys and a genesis file
-
-In the `Permissioned-Network` directory, generate the node key and genesis file:
-
-```bash
-besu operator generate-blockchain-config --config-file=ibftConfigFile.json --to=networkFiles --private-key-file-name=key
-```
-
-Besu creates the following in the `networkFiles` directory:
-
-- `genesis.json` - The genesis file including the `extraData` property specifying the four nodes are validators.
-- A directory for each node named using the node address and containing the public and private key for each node.
-
-```bash
-networkFiles/
-├── genesis.json
-└── keys
- ├── 0x438821c42b812fecdcea7fe8235806a412712fc0
- │ ├── key
- │ └── key.pub
- ├── 0xca9c2dfa62f4589827c0dd7dcf48259aa29f22f5
- │ ├── key
- │ └── key.pub
- ├── 0xcd5629bd37155608a0c9b28c4fd19310d53b3184
- │ ├── key
- │ └── key.pub
- └── 0xe96825c5ab8d145b9eeca1aba7ea3695e034911a
- ├── key
- └── key.pub
-```
-
-### 4. Copy the genesis file to the Permissioned-Network directory
-
-Copy the `genesis.json` file to the `Permisssioned-Network` directory.
-
-### 5. Copy the node private keys to the node directories
-
-For each node, copy the key files to the `data` directory for that node
-
-```bash
-Permissioned-Network/
-├── genesis.json
-├── Node-1
-│ ├── data
-│ │ ├── key
-│ │ ├── key.pub
-├── Node-2
-│ ├── data
-│ │ ├── key
-│ │ ├── key.pub
-├── Node-3
-│ ├── data
-│ │ ├── key
-│ │ ├── key.pub
-├── Node-4
-│ ├── data
-│ │ ├── key
-│ │ ├── key.pub
-```
-
-### 6. Create the permissions configuration file
-
-The [permissions configuration file](../../how-to/use-permissioning/local.md#permissions-configuration-file) defines the nodes and accounts allowlists.
-
-Copy the following permissions configuration to a file called `permissions_config.toml` and save a copy in the `Node-1/data`, `Node-2/data`, `Node-3/data`, and `Node-4/data` directories:
-
-```toml title="permissions_config.toml"
-accounts-allowlist=["0xfe3b557e8fb62b89f4916b721be55ceb828dbd73", "0x627306090abaB3A6e1400e9345bC60c78a8BEf57"]
-
-nodes-allowlist=[]
-```
-
-The permissions configuration file includes the first two accounts from the genesis file.
-
-Use the [`perm_addNodesToAllowlist`](../../reference/api/index.md#perm_addnodestoallowlist) JSON-RPC API method to add permissioned nodes after starting the nodes.
-
-### 7. Start Node-1
-
-Use the following command:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --permissions-nodes-config-file-enabled --permissions-accounts-config-file-enabled --rpc-http-enabled --rpc-http-api=ADMIN,ETH,NET,PERM,IBFT --host-allowlist="*" --rpc-http-cors-origins="*"
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\genesis.json --permissions-nodes-config-file-enabled --permissions-accounts-config-file-enabled --rpc-http-enabled --rpc-http-api=ADMIN,ETH,NET,PERM,IBFT --host-allowlist="*" --rpc-http-cors-origins="*"
-```
-
-
-
-The command line allows you to enable:
-
-- Nodes and accounts permissions using [`--permissions-nodes-config-file-enabled`](../../reference/cli/options.md#permissions-nodes-config-file-enabled) and [`--permissions-accounts-config-file-enabled`](../../reference/cli/options.md#permissions-accounts-config-file-enabled).
-- The JSON-RPC API using [`--rpc-http-enabled`](../../../public-networks/reference/cli/options.md#rpc-http-enabled).
-- The `ADMIN`, `ETH`, `NET`, `PERM`, and `IBFT` APIs using [`--rpc-http-api`](../../../public-networks/reference/cli/options.md#rpc-http-api).
-- All-host access to the HTTP JSON-RPC API using [`--host-allowlist`](../../../public-networks/reference/cli/options.md#host-allowlist).
-- All-domain access to the node through the HTTP JSON-RPC API using [`--rpc-http-cors-origins`](../../../public-networks/reference/cli/options.md#rpc-http-cors-origins).
-
-When the node starts, the [enode URL](../../../public-networks/concepts/node-keys.md#enode-url) displays. You need the enode URL to specify Node-1 as a peer and update the permissions configuration file in the following steps.
-
-![Node 1 Enode URL](../../../assets/images/EnodeStartup.png)
-
-### 8. Start Node-2
-
-Start another terminal, change to the `Node-2` directory, and start Node-2:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --permissions-nodes-config-file-enabled --permissions-accounts-config-file-enabled --rpc-http-enabled --rpc-http-api=ADMIN,ETH,NET,PERM,IBFT --host-allowlist="*" --rpc-http-cors-origins="*" --p2p-port=30304 --rpc-http-port=8546
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\genesis.json --permissions-nodes-config-file-enabled --permissions-accounts-config-file-enabled --rpc-http-enabled --rpc-http-api=ADMIN,ETH,NET,PERM,IBFT --host-allowlist="*" --rpc-http-cors-origins="*" --p2p-port=30304 --rpc-http-port=8546
-```
-
-
-
-The command line specifies:
-
-- A different port to Node-1 for P2P discovery using [`--p2p-port`](../../../public-networks/reference/cli/options.md#p2p-port).
-- A different port to Node-1 for HTTP JSON-RPC using [`--rpc-http-port`](../../../public-networks/reference/cli/options.md#rpc-http-port).
-- A data directory for Node-2 using [`--data-path`](../../../public-networks/reference/cli/options.md#data-path).
-- Other options as for [Node-1](#7-start-node-1).
-
-When the node starts, the [enode URL](../../../public-networks/concepts/node-keys.md#enode-url) displays. You need the enode URL to update the permissions configuration file in the following steps.
-
-### 9. Start Node-3
-
-Start another terminal, change to the `Node-3` directory, and start Node-3:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --permissions-nodes-config-file-enabled --permissions-accounts-config-file-enabled --rpc-http-enabled --rpc-http-api=ADMIN,ETH,NET,PERM,IBFT --host-allowlist="*" --rpc-http-cors-origins="*" --p2p-port=30305 --rpc-http-port=8547
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\genesis.json --permissions-nodes-config-file-enabled --permissions-accounts-config-file-enabled --rpc-http-enabled --rpc-http-api=ADMIN,ETH,NET,PERM,IBFT --host-allowlist="*" --rpc-http-cors-origins="*" --p2p-port=30305 --rpc-http-port=8547
-```
-
-
-
-The command line specifies:
-
-- A different port to Node-1 and Node-2 for P2P discovery using [`--p2p-port`](../../../public-networks/reference/cli/options.md#p2p-port).
-- A different port to Node-1 and Node-2 for HTTP JSON-RPC using [`--rpc-http-port`](../../../public-networks/reference/cli/options.md#rpc-http-port).
-- A data directory for Node-3 using [`--data-path`](../../../public-networks/reference/cli/options.md#data-path).
-- Other options as for [Node-1](#7-start-node-1).
-
-When the node starts, the [enode URL](../../../public-networks/concepts/node-keys.md#enode-url) displays. You need the enode URL to update the permissions configuration file in the following steps.
-
-### 10. Start Node-4
-
-Start another terminal, change to the `Node-4` directory, and start Node-4:
-
-
-
-# MacOS
-
-```bash
-besu --data-path=data --genesis-file=../genesis.json --permissions-nodes-config-file-enabled --permissions-accounts-config-file-enabled --rpc-http-enabled --rpc-http-api=ADMIN,ETH,NET,PERM,IBFT --host-allowlist="*" --rpc-http-cors-origins="*" --p2p-port=30306 --rpc-http-port=8548
-```
-
-# Windows
-
-```bash
-besu --data-path=data --genesis-file=..\genesis.json --permissions-nodes-config-file-enabled --permissions-accounts-config-file-enabled --rpc-http-enabled --rpc-http-api=ADMIN,ETH,NET,PERM,IBFT --host-allowlist="*" --rpc-http-cors-origins="*" --p2p-port=30306 --rpc-http-port=8548
-```
-
-
-
-The command line specifies:
-
-- A different port to Node-1, Node-2, and Node-3 for P2P discovery using [`--p2p-port`](../../../public-networks/reference/cli/options.md#p2p-port).
-- A different port to Node-1, Node-2, and Node-3 for HTTP JSON-RPC using [`--rpc-http-port`](../../../public-networks/reference/cli/options.md#rpc-http-port).
-- A data directory for Node-4 using [`--data-path`](../../../public-networks/reference/cli/options.md#data-path).
-- Other options as for [Node-1](#7-start-node-1).
-
-When the node starts, the [enode URL](../../../public-networks/concepts/node-keys.md#enode-url) displays. You need the enode URL to update the permissions configuration file in the following steps.
-
-### 11. Add enode URLs for nodes to permissions configuration file
-
-Start another terminal and use the [`perm_addNodesToAllowlist`](../../reference/api/index.md#perm_addnodestoallowlist) JSON-RPC API method to add the nodes to the permissions configuration file for each node.
-
-Replace ``, ``, ``, and `` with the enode URL displayed when starting each node.
-
-
-
-# Node-1
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_addNodesToAllowlist","params":[["","","","EnodeNode4"]], "id":1}' http://127.0.0.1:8545
-```
-
-# Node-2
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_addNodesToAllowlist","params":[["","","","EnodeNode4"]], "id":1}' http://127.0.0.1:8546
-```
-
-# Node-3
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_addNodesToAllowlist","params":[["","","","EnodeNode4"]], "id":1}' http://127.0.0.1:8547
-```
-
-# Node-4
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"perm_addNodesToAllowlist","params":[["","","","EnodeNode4"]], "id":1}' http://127.0.0.1:8548
-```
-
-
-
-:::tip
-
-The curl call is the same for each node except for the JSON-RPC endpoint.
-
-:::
-
-### 12. Add nodes as peers
-
-Use the [`admin_addPeer`](../../../public-networks/reference/api/index.md#admin_addpeer) JSON-RPC API method to add Node-1 as a peer for Node-2, Node-3, and Node-4.
-
-Replace `` with the enode URL displayed when starting Node-1.
-
-
-
-# Node-2
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"admin_addPeer","params":[""],"id":1}' http://127.0.0.1:8546
-```
-
-# Node-3
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"admin_addPeer","params":[""],"id":1}' http://127.0.0.1:8547
-```
-
-# Node-4
-
-```bash
-curl -X POST --data '{"jsonrpc":"2.0","method":"admin_addPeer","params":[""],"id":1}' http://127.0.0.1:8548
-```
-
-
-
-:::tip
-
-The curl call is the same for each node except for the JSON-RPC endpoint.
-
-:::
-
-Replace `