Installation of an Execution Node in the ISBE Network

This document describes the standard procedure for deploying an execution (non-validator) Hyperledger Besu node within the ISBE network (dev, pre, or pro environments). Execution nodes allow a use case to connect to the network, deploy contracts, and send transactions.

Helm/Kubernetes deployment

The execution node is deployed as a Kubernetes pod using the besu-node Helm chart provided by ISBE, not via Docker Compose. This is consistent with the rest of the network infrastructure (see NAP Infrastructure Requirements), which also runs on Kubernetes/k3s.

Mandatory access via Filtering Proxy — no direct access to the node's port

Even if you deploy and operate your own execution node, your applications must not access the node's RPC port directly. All RPC access must go through a Filtering Proxy, which is what internally connects to the node's port. This is a mandatory GDPR compliance requirement, not a recommendation.

ISBE does not deploy the Filtering Proxy for you: you deploy it yourself, as part of the ISBE client stack (alongside the node-manager and middleware), following the same model as a NAP's infrastructure (see Infrastructure Requirements). Since you operate that Filtering Proxy, you are the one who determines and exposes the access URL for your own applications — ISBE does not assign it to you.

As a consequence, WebSocket is not available under any modality: the Filtering Proxy only exposes HTTP RPC. The node.besu.ws.enabled field in values.yaml must remain false.

The process consists of four phases:

1. Prepare access to the cluster and to ISBE's artifact registry.
2. Configure and deploy the Besu node's Helm chart.
3. Deploy the ISBE client stack (Filtering Proxy, middleware, and node-manager) alongside the node.
4. Request permissioning to join the node to ISBE's P2P network.

---

1. Prerequisites

Before starting the installation, the participant must have:

Access and tools

• A Kubernetes (or k3s) cluster where the node will be deployed, either self-managed or managed.
• Helm ≥ 3.x client installed and configured against that cluster.
• Access credentials to the private OCI chart and image registry provided by ISBE.

Recommended hardware (node pod)

• 4 Gi of RAM
• 40 Gi of persistent storage (PVC)
• No strict CPU limit (depending on cluster availability)

Cluster node operating system

• Linux 64-bit, compatible with Kubernetes/k3s

Network and ports

Port	Use
30303/tcp	P2P (ingress/egress)
30303/udp	Discovery
8545/tcp	HTTP RPC (if exposed)

IMPORTANT: For the execution node to join ISBE's P2P network, port 30303/tcp must be reachable from the Internet (typically via an Ingress/Load Balancer managed in the cluster).

---

2. Obtain the deployment artifacts

When onboarding the participant, ISBE provides:

• The besu-node Helm chart and its validated version, published in a private OCI registry.
• A reference values.yaml file for a non-validator node (node name, resources, RPC/P2P configuration).
• The genesis.json file corresponding to the target environment (dev/pre/pro).
• The static nodes list (static-nodes.json) with the enodes of the ISBE bootnodes the node must connect to.

Authenticate against the OCI registry indicated by ISBE:

helm registry login <isbe-provided-oci-registry>

---

3. Configure the node's values.yaml

Main parameters to review/adjust in the provided values.yaml:

Parameter	Reference value	Notes
fullnameOverride	<Node_Name>	Node/Helm release name
quorumFlags.isBootnode	false	An execution node is never a bootnode
quorumFlags.usesBootnodes	depends on environment	Indicates whether it connects to bootnodes deployed in the cluster itself
node.besu.resources.memLimit / memRequest	4Gi	Pod memory
node.besu.p2p.port	30303	P2P port
node.besu.p2p.staticNodes	/config/static/static-nodes.json	ISBE bootnode enodes
node.besu.p2p.maxPeers	25	Peer limit
node.besu.rpc.port	8545	HTTP RPC port
node.besu.rpc.api	["ETH","NET","QBFT"]	Enabled APIs
node.besu.ws.enabled	false	WebSocket — must remain disabled (not supported by the Filtering Proxy)
image.besu.tag	per environment	Besu version validated by ISBE
storage.pvcSizeLimit	40Gi	Node persistent storage

The ISBE team provides these files already adjusted to your environment to avoid configuration errors; you typically only need to customize the node name and, if applicable, public exposure (Ingress).

---

4. Deploy the node with Helm

helm install <Node_Name> oci://<isbe-provided-oci-registry>/isbe-helm-charts/besu-node \
  --version <version-indicated-by-isbe> \
  -f values-execution-node.yml

The chart automatically generates the node's key pair on deployment (persisted as a Kubernetes Secret). ISBE will indicate the procedure (kubectl logs / kubectl exec on the pod) to obtain your node's enode, required for the permissioning step.

---

5. Deploy the ISBE client stack (Filtering Proxy)

ISBE provides the chart/manifests for the ISBE client stack (node-manager, middleware, and isbe-client proxy — the Filtering Proxy), for you to deploy alongside your node, in the same cluster/namespace. It must be used unmodified.

This component enforces GDPR logical deletion on the data leaving your node, and is the only permitted RPC access point for your applications. You decide how to expose it (Ingress, internal Load Balancer, etc.) and, therefore, what the final URL your applications will use is — it is not something ISBE assigns to you.

Refer to the client stack deployment guide provided by ISBE for the specific values for your environment.

---

6. Verify pod status

kubectl get pods -l app.kubernetes.io/instance=<Node_Name>
kubectl logs -f <node-pod>

The node will not be able to sync or join the P2P network until ISBE authorizes its enode (see next section).

---

7. Request permissioning

Follow the procedure described in Permissioning Request, providing the enode obtained in step 4.

Once approved, the node:

1. Will be included in the authorized nodes list.
2. Will be able to connect to the bootnodes.
3. Will start syncing the chain.

---

8. Verification after permissioning

The following checks are for internal technical verification by the node operator (e.g., via kubectl exec within the cluster). They do not represent how an application should connect: that access always goes through the Filtering Proxy (see below).

Check P2P status:

curl http://localhost:8545 \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}'

It must return a number greater than zero when connected to the network.

Check block height:

curl http://localhost:8545 \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

The value should increase approximately every 2 seconds.

---

9. Subsequent use of the node

Once synced, the execution node allows:

• Deploying contracts.
• Reading on-chain state.
• Sending signed transactions.

Your applications must always connect through the Filtering Proxy you deployed in step 5 (never directly to the node's port). As the Network Provider, you are the one who defines and communicates that URL to your own applications.

The node remains under the operational responsibility of the use case:

• PVC backups (e.g., via Velero if the cluster supports it).
• Pod logs and monitoring.
• Security of the cluster/namespace where it is hosted.
• Updates to the Besu image and the chart, per the versions validated by ISBE.

The ISBE network only controls permissioning and P2P topology.