Infrastructure Requirements
This document specifies the node infrastructure that a Network Access Provider (NAP) must deploy to participate in the ISBE Main Network. Two configurations are defined: Ideal and Minimum. Both are valid production configurations; the choice depends on the NAP's commercial tier, operational requirements, and available hardware.
1. Architecture principles
- All nodes run as pods on k3s (Kubernetes) on a single physical server per network.
- Each pod runs a Hyperledger Besu process. Roles are assigned per pod via Besu configuration flags.
- The ISBE client stack (
node-manager, middleware, proxy) runs as additional pods on the same server and must be used unmodified. - The Filtering Proxy embedded in
isbe-client proxyenforces GDPR logical deletion on all data entering the chain. It must not be bypassed. - Port 30303 TCP/UDP must be publicly reachable from the internet on the validator and boot node only.
2. Configuration comparison
| Ideal | Minimum | |
|---|---|---|
| Pods | 4 (validator · bootnode · execution · archive) | 2 (validator+bootnode · execution) |
| Validator | Dedicated pod | Combined pod |
| Boot node | Dedicated pod | Combined pod |
| Execution | Dedicated pod | Dedicated pod |
| Archive | Dedicated pod | Not included |
| RAM | 32 GB | 24 GB |
| CPU | 4–6 cores | 4 cores |
| Disk | 750 Gi NVMe | 320 Gi NVMe |
| Network | 1 Gbps | 1 Gbps |
| Full chain history | Yes — archive node | No |
| Operational resilience | Full isolation per role | Validator and boot share process |
| Recommended for | Professional / Enterprise tiers | Anchor / Standard tiers, initial deployment |
3. Ideal Configuration
4 dedicated pods — validator · bootnode · execution · archive.
Each node role runs in its own dedicated Besu pod, providing full operational isolation. The archive node stores the complete chain history, enabling full traceability and regulatory audit capability. Recommended for Professional and Enterprise tier NAPs.
3.1 Node composition and memory
| Pod / Node | RAM | Disk | Obligation / Notes |
|---|---|---|---|
| Validator | 4 Gi | 80 Gi | Mandatory — participates in QBFT consensus |
| Boot node | 4 Gi | 80 Gi | Mandatory — P2P peer discovery, port 30303 external |
| Execution | 4 Gi | 80 Gi | Mandatory — RPC and API endpoint for clients |
| Archive | 8 Gi | 200 Gi | Recommended — full chain history |
| OS + k3s | ~6 Gi | 100 Gi | — |
| ISBE client stack | ~1.3 Gi | — | node-manager · middleware · proxy |
| Total RAM | ~27 Gi → provision 32 GB |
3.2 Server summary
| Resource | Specification |
|---|---|
| RAM — total | 32 GB |
| CPU | 4–6 cores |
| Disk — nodes | 80 Gi × 3 nodes + 200 Gi archive = 440 Gi |
| Disk — OS + other | 100 Gi |
| Disk — total provisioned | 750 Gi NVMe |
| Network | 1 Gbps — port 30303 TCP/UDP publicly reachable on validator and boot node |
| Besu image | hyperledger/besu:26.1.0 |
4. Minimum Configuration
2 pods — validator+bootnode (combined) · execution.
The validator and boot node roles are combined into a single Besu pod. This reduces the server footprint while maintaining full participation in QBFT consensus and P2P discovery. No archive node is included. Suitable for Anchor and Standard tier NAPs and for initial production deployments.
The combined pod runs a single Besu process with both VALIDATOR and BOOTNODE roles active via configuration flags. Port 30303 TCP/UDP must be externally reachable on this pod. The 6 Gi RAM allocation accounts for the combined state of both roles.
4.1 Node composition and memory
| Pod / Node | RAM | Disk | Obligation / Notes |
|---|---|---|---|
| Validator + Boot node (combined) | 6 Gi | 80 Gi | Mandatory — QBFT consensus + P2P discovery, port 30303 external |
| Execution | 4 Gi | 80 Gi | Mandatory — RPC and API endpoint for clients |
| OS + k3s | ~6 Gi | 100 Gi | — |
| ISBE client stack | ~1.3 Gi | — | node-manager · middleware · proxy |
| Total RAM | ~17 Gi → provision 24 GB |
4.2 Server summary
| Resource | Specification |
|---|---|
| RAM — total | 24 GB |
| CPU | 4 cores |
| Disk — nodes | 80 Gi × 2 nodes = 160 Gi |
| Disk — OS + other | 100 Gi |
| Disk — total provisioned | 320 Gi NVMe |
| Network | 1 Gbps — port 30303 TCP/UDP publicly reachable on validator and boot node |
| Besu image | hyperledger/besu:26.1.0 |
5. Platform Services
ISBE client stack — identical across both configurations.
The following three components are provided by ISBE and run as additional pods on the same server. They must be deployed unmodified. Their resource profile is identical in both the Ideal and Minimum configurations.
| Component | RAM limit | RAM (observed) | CPU (observed) | Externally accessible |
|---|---|---|---|---|
| node-manager | 256 Mi | 72 Mi | 4m | No |
| isbe-client middleware | 512 Mi | 61 Mi | 8m | Yes |
| isbe-client proxy | 512 Mi | 5 Mi | 1m | Yes |
The isbe-client proxy implements the Filtering Proxy, which prevents personal data from being available on-chain (GDPR compliance by design). Any bypass or unauthorised modification constitutes a breach of the NAP service terms.
6. Network Requirements
Port matrix — Ideal configuration.
Ports marked External must be publicly reachable from the internet. Ports marked Internal are cluster-scoped only. The Minimum configuration omits the archive node row (port 8546).
| Component | Port | Protocol | Exposure | Purpose |
|---|---|---|---|---|
| Validator · Boot node | 30303 | TCP | External | P2P peering |
| Validator · Boot node | 30303 | UDP | External | P2P discovery |
| All Besu nodes | 8545 | HTTP | Internal | JSON-RPC |
| Archive node | 8546 | WS | Internal | WebSocket RPC |
| All Besu nodes | 9545 | HTTP | Internal | Prometheus metrics |
| node-manager | 8000 | HTTP | Internal | REST API |
| node-manager | 9100 | HTTP | Internal | Metrics endpoint |
| isbe-client middleware | 8000 | HTTP | External | Client API |
| isbe-client proxy | 8545 | HTTP | External | RPC proxy (Filtering Proxy) |
Port 30303 TCP+UDP must be publicly reachable from the internet on the validator node and the boot node (or on the combined validator+bootnode pod in the Minimum configuration). This is required for cross-cluster P2P peering. Execution and archive nodes do not require external exposure on this port.
7. Software Stack
Required versions — both configurations.
| Component | Specification |
|---|---|
| Hyperledger Besu | hyperledger/besu:26.1.0 — do not upgrade without ISBE validation |
| Orchestration | k3s (lightweight Kubernetes) — managed by the ISBE client deployment package |
| ISBE client | Provided by ISBE. Includes node-manager, isbe-client middleware, and isbe-client proxy. Must be used unmodified. |
| Operating system | Linux — NAP's choice; must be compatible with k3s and the Besu image above. A modern, actively supported distribution is recommended (Ubuntu 22.04+ LTS, Debian 12+, Rocky/AlmaLinux 9+). |
8. Information required before deployment
The NAP must define, before starting the deployment:
- Node/server name:
<Node_name> - Public IP:
<NODE_IP>(the one to be exposed on port 30303) - Data-path location for each pod
- Technical owner of the deployment
- Target ISBE environment: dev / pre / pro
This information is later used in the k3s deployment configuration and in the permissioning request process.
9. Best practices before deployment
- Use a server dedicated exclusively to the node infrastructure (do not mix with other workloads).
- Configure periodic backups of each pod's data volumes.
- Disable password-based SSH access; use public keys only.
- Keep k3s, the Besu images, and the ISBE client stack updated according to the versions validated by ISBE.
- Avoid slow disk mounts for the data-path (never NFS): use local NVMe.
10. Summary
| Category | Ideal | Minimum |
|---|---|---|
| Pods | 4 | 2 |
| RAM | 32 GB | 24 GB |
| CPU | 4–6 cores | 4 cores |
| Disk | 750 Gi NVMe | 320 Gi NVMe |
| Network | 30303/tcp+udp open to the Internet (validator/boot) | 30303/tcp+udp open to the Internet (combined pod) |
| Software | Besu 26.1.0 on k3s + ISBE client stack unmodified | Besu 26.1.0 on k3s + ISBE client stack unmodified |