Practical overview
When it fits
Use it during EOS block producer architecture planning, security reviews or audits, especially when deciding how to isolate RPC services and maintain communication during network disruption.
Who it is for
- EOS block producer operators planning or reviewing node infrastructure.
- Security reviewers assessing RPC exposure, host settings and backup communication paths.
Documented uses
- Plan a network layout with public nodes, private peer communication and VPN backup links.
- Review whether RPC services should be exposed and how an external RPC node should be configured.
- Check host, access-control and logging practices relevant to node operations.
Requirements & limits
The checklist is available in a public GitHub repository under the Apache-2.0 license.
- The repository provides security guidance rather than executable node infrastructure or an automated audit tool.
- Its recommendations include a layered communication design; private-node addresses are not guaranteed to remain undiscovered.
- The guide covers both service configuration and operational controls such as SSH restrictions and log collection.
Check current requirements in the official documentation. Source-based guidance does not mean OpenViST has run or independently tested this project.
Plan a resilient EOS block producer node network
Arrange public, private, and VPN-connected full nodes, with RPC infrastructure separated from block-producing servers.
Before you start
- EOS block producer node environment
- Public full nodes and private full nodes
- A VPN-connected virtual private network for trusted nodes
- Separate full node infrastructure for query RPC
Steps
Prepare at least two public full nodes for communication with Dapps and the main network.
Prepare at least two private full nodes, sharing their IP addresses only with selected trusted block producers.
Set up a VPN-encrypted path between trusted nodes as a fallback if public and private full-node connections become unavailable.
Keep the query RPC full node separate from block-producing servers and protect it from external attacks.
Expected outcome
A multi-path reference architecture with public communication nodes, restricted private nodes, a VPN fallback, and isolated query RPC infrastructure.
Guide limitations
- Private full-node IP addresses can still be discovered through broad network scanning.
- The guide describes a recommended architecture; it does not provide VPN setup instructions or verify an implementation.
Harden an externally accessible EOS RPC service
Configure an externally offered RPC service to use HTTPS and avoid loading plugins that expose wallet or producer controls.
Before you start
- An EOS node configuration file (config.ini)
- A certificate chain and private key in PEM format, with file permissions set to 600
Steps
In config.ini, comment out http-server-address or set it to 127.0.0.1:8888, and set https-server-address to 0.0.0.0:443.
Set https-certificate-chain-file and https-private-key-file to the certificate-chain and private-key paths; ensure both files are PEM and have permissions set to 600.
Do not load wallet_plugin or wallet_api_plugin when offering RPC externally.
Do not load producer_api_plugin when offering RPC externally.
Expected outcome
The guide's recommended RPC configuration uses HTTPS rather than externally accessible HTTP and excludes the named wallet and producer plugins.
Guide limitations
- The guide recommends disabling RPC exposure when it is unnecessary; this recipe applies only when RPC must be offered externally.
- It does not specify certificate issuance, plugin-removal commands, or how to test the resulting configuration.
Sources & review
Source record details
- Source availability
- Active
- Sources checked
- 16 October 2026
- Original website title
- slowmist/eos-bp-nodes-security-checklist · Official homepage title · retained in its source language