Mini-Server Architecture and Deployment Blueprint for 24/7 eCash Nodes

XolosArmy Podcast: Audio Companion to This Research

Explore an extended conversation about this mini-server and data center blueprint for eCash and RMZWallet. This podcast episode deepens the research narrative, covering design choices, resiliency tactics, and how sovereign hardware empowers the XolosArmy community.

1. Executive Summary: 24/7 Mini-Server Architecture for eCash

1.1 Architectural Design Principles

The proposed architecture is built around three core principles:

• Energy efficiency – low TDP CPUs minimize power draw and extend UPS autonomy.
• Logical I/O isolation – dual NVMe design separates heavy node writes from the hypervisor and auxiliary VMs.
• End-to-end resilience – from SSD endurance planning to automatic power-loss recovery and backup strategy.

I/O Isolation via Dual NVMe

The Mini-PC must provide two M.2 NVMe 2280 slots:

• 2 TB NVMe: dedicated ZFS dataset for the eCash node (full node + Chronik + Agora).
• 1 TB NVMe: Proxmox VE hypervisor, system services, and secondary VMs (RMZWallet backend, web, monitoring, etc.).

This separation reduces contention and shields the hypervisor and auxiliary services from the intense write patterns of the node’s database.

Electrical Efficiency and Resilience

Modern low-power CPUs (e.g., Ryzen 7 5825U / 7840HS class) combine:

• Very low idle consumption (around 10 W or less).
• Moderate peak loads (up to ~50 W for node + VMs).

Because total system draw is so low, a 1500 VA / ~900 W line-interactive UPS can keep the node alive for many hours during a power outage, or at the very least guarantee a clean, controlled shutdown in extended blackouts—critical for 24/7 blockchain uptime.

Hypervisor-Centric Management

A Type-1 hypervisor (Proxmox VE) is recommended as the base layer because it:

• Manages both KVM VMs (e.g. eCash node VM) and LXC containers (auxiliary services).
• Integrates ZFS, enabling robust datasets and snapshots.
• Provides an intuitive web UI for lifecycle management, backups, and resource allocation across 32–64 GB of RAM and multiple CPU cores.

2. Component Sourcing and Cost Analysis (Mexico)

2.1 Central Platform (Mini-PC)

Key selection criteria include:

• CPU: 6–8 cores, modern architecture (e.g., Ryzen 7 7840HS-class).
• RAM: minimum 32 GB DDR5, with an option to upgrade to 64 GB.
• Storage: dual M.2 2280 NVMe slots (strict requirement).

Specialized Mini-PCs such as models similar to the AOOSTAR MACO H255 (dual M.2, DDR5 support) or equivalent platforms meet the dual-NVMe requirement. Business-class ASUS NUC-style systems or small-form-factor workstations also qualify, but often at a higher cost.

Estimated price range (Mexico): Mini-PC (Ryzen 7, 32 GB RAM, dual NVMe support) – $9,000–$15,000 MXN (approximate).

2.2 Storage Subsystem (NVMe): Endurance and Performance

The storage layer is the primary vulnerability of this mini-server architecture due to:

• High write volume generated by the full node, Chronik, and Agora.
• Lack of RAID redundancy (only two slots available).

2.2.1 Endurance (TBW) Constraints

Experience with Bitcoin-class nodes suggests that yearly writes can exceed 300 TBW. Many consumer-grade 2 TB SSDs advertise:

• ~440 TBW (e.g., cheaper drives like Crucial P3).
• ~1,200 TBW for higher-end models (e.g., Samsung 990 Pro 2 TB).

Under continuous node workloads, lower-end drives may hit their TBW rating in a bit over a year; even high-end drives may need proactive replacement every 1–2 years. This makes planned replacement and SMART monitoring non-optional.

2.2.2 Recommended NVMe 2 TB for the Node

For the 2 TB node drive, the recommendation is:

• Samsung 990 Pro 2 TB or similar high-IOPS PCIe 4.0 SSD
  • Excellent random write performance (up to ~1,550K random write IOPS).
  • Widely available in Mexico in the $3,500–$4,500 MXN range (approx.).

Alternatives such as WD Black SN850X 2 TB are acceptable but generally offer lower random write IOPS. Enterprise SSDs (with multi-PB endurance) are usually unavailable in M.2 2280 form for Mini-PCs and are sized and priced for rack servers, so this architecture intentionally uses the strongest available consumer NVMe and compensates with operational discipline.

2.2.3 NVMe 1 TB for OS and VMs

The 1 TB NVMe (PCIe 4.0, good but not necessarily flagship performance) hosts:

• Proxmox VE.
• Secondary VMs (e.g. RMZWallet backend, analytics, monitoring).
• Local backups (with care, due to TBW limits).

Estimated price: $1,800–$2,500 MXN (approx.).

2.3 Power Backup and Operational Continuity (UPS)

A 1000–1500 VA UPS is appropriate; this report recommends 1500 VA with pure sine wave output:

• Compatible with Active PFC power supplies.
• Provides significantly more than the required wattage for a Mini-PC + router stack.
• Ensures long autonomy, often capable of several hours of runtime at 50–80 W load.

The UPS must support USB communication, allowing the Proxmox host to monitor battery state and trigger automated shutdown procedures.

Estimated price: $5,200–$7,000 MXN (approx.).

2.4 Network Infrastructure: WiFi 6 Router

The router will typically sit behind the ISP modem, ideally configured in bridge/AP mode:

• WiFi 6 (AX) capability for local wireless devices.
• Gigabit Ethernet on all LAN ports.
• Example class: TP-Link Archer AX6000-type routers (WAN 2.5 Gbps + multiple Gigabit LAN ports).

Critical configuration points:

• Place router in bridge / AP mode (avoid double NAT).
• Ensure DHCP is disabled on the router so the ISP modem remains the primary DHCP server.
• Assign a static IP in the ISP subnet to manage the router itself.

2.5 Estimated Total Cost (Mexico)

3. Deployment of the Hypervisor Layer (Proxmox VE)

3.1 Physical Assembly

Key practices during assembly:

• Install RAM in dual-channel configuration (e.g. 2×16 GB or 2×32 GB).
• Mount both NVMe drives securely with their retention screws.
• Avoid touching PCB contacts with bare fingers; use proper handling to prevent ESD damage.
• If the high-performance NVMe requires or includes a heatsink, install it to mitigate thermal throttling under sustained node load.

3.2 BIOS Configuration for Unattended Operation

Configure the Mini-PC firmware to recover automatically from power loss:

• Access BIOS/UEFI (commonly via F2 / DEL / F10 at boot).
• Enable AC Power Loss Recovery / Restore on AC Power Loss / Power On.

Once the UPS battery drains completely and power later returns, the Mini-PC will boot automatically, restoring Proxmox and all services without manual intervention.

3.3 Proxmox VE as the Base OS

Proxmox VE is chosen over a simple Linux+KVM manual setup because:

• It is purpose-built for virtualization, backed by Debian.
• Provides an integrated web console for VM/LXC lifecycle, storage, and backup.
• Natively supports ZFS, simplifying dataset creation, snapshots, and replication.

This stack aligns well with the eCash ecosystem (Chronik, Agora, RMZWallet backends), which are most stable on Linux.

3.4 Storage Architecture and ZFS Optimization

3.4.1 Storage Pools

Recommended logical layout:

• 1 TB NVMe:
  • Proxmox system install.
  • ZFS pool for secondary VMs (e.g., rpool-vm).
• 2 TB NVMe:
  • Dedicated ZFS pool for eCash node data (e.g., rpool-node).

Due to the constraint of only two NVMe slots, RAID-1 is not possible without sacrificing capacity. Each drive is therefore a single point of failure, which must be offset with strong backup and monitoring practices (see Section 4.3).

3.4.2 ZFS Parameters for Node Workloads

Default ZFS compression (LZ4) may offer limited benefit because many blockchain payloads are already compressed or compress poorly. Compression can increase write amplification, impacting SSD endurance.

It is reasonable to experiment with disabling compression on the node pool:

zfs set compression=off rpool-node

The operator should measure I/O behavior and stability with and without compression to determine the optimal setting for Chronik/Agora.

4. 24/7 Operation, Maintenance, and Resilience

4.1 eCash Node VM and Auxiliary VMs

4.1.1 Resource Allocation

For a Mini-PC with 32 GB RAM:

• Allocate 20–24 GB RAM to the eCash Node VM to:
  • Provide ample cache for the OS and database.
  • Support ZFS ARC if using ZFS inside or below the VM.

The remaining RAM is reserved for Proxmox, RMZWallet backend services, monitoring containers, and OS overhead.

A modern Linux server distribution (e.g., Ubuntu Server) should be used inside the VM, as it is the standard environment for eCash node software and Node.js components (Chronik, Agora).

4.1.2 Pruned Node Strategy (If Space Becomes a Bottleneck)

If projected blockchain growth threatens to exceed the 2 TB node drive capacity, XolosArmy operators can deploy pruned node mode:

• Keeps the node fully validating.
• Retains only a recent window of blocks (not full historical data).
• Reduces required disk space dramatically.

For maximal archival capabilities and index depth, a full node is ideal. However, in constrained environments, pruning is a viable compromise to maintain security participation without immediate hardware expansion.

4.2 Preventive Maintenance for SSD Endurance (TBW)

Given the intense I/O patterns and lack of RAID, preventing catastrophic SSD failure is a matter of predictive maintenance, not luck.

4.2.1 SMART Monitoring

Use smartctl (from the smartmontools package) on the Proxmox host to monitor:

• Percentage Used or Wear Leveling Count.
• Reallocated sectors or media errors.

Automated periodic checks should log endurance usage and alert when thresholds are crossed (e.g., at 70%, 80%, 90% of the rated TBW).

4.2.2 Planned Replacement

The operational rule for XolosArmy Network should be:

• When endurance reaches ~80–90% of the rated TBW, plan a controlled migration to a new NVMe drive.
• Schedule a short downtime window, replicate datasets, and replace the disk before failure.

For sustained node + index workloads, it is realistic to assume annual or biennial SSD replacement, depending on actual write volume.

4.3 Power Resilience and Backup Strategy

4.3.1 Graceful Shutdown via NUT

Resilience is a combination of hardware and software:

• Install Network UPS Tools (NUT) on the Proxmox host.
• Link NUT to the UPS via USB to monitor battery charge, remaining runtime, and power state.

Configure NUT to:

• Trigger a clean shutdown when estimated runtime falls below a safe threshold (for example, 10 minutes).
• Gracefully stop all VMs and containers.
• Export ZFS pools cleanly, preventing data corruption.

4.3.2 Backups with Proxmox Backup Server (PBS)

To mitigate the single-disk risk on each NVMe drive:

• Run Proxmox Backup Server (PBS) either:
  • On the same 1 TB NVMe (for short-term, fast backups), and/or
  • On an external DAS (see Section 5.1) for more durable redundancy.

PBS offers incremental, deduplicated backups of VMs and containers, efficient use of disk TBW, and faster recovery in the event of node corruption or SSD failure.

5. Future Scalability for XolosArmy Network

5.1 Scaling Up

As XolosArmy Network and RMZ-centric services grow, the following upgrades are recommended:

1. RAM Expansion to 64 GB
   Improves overall system responsiveness, expands ZFS ARC cache for faster reads across multiple VMs and datasets, and enables more simultaneous services: extra indexers, analytics dashboards, or experimental side projects.
2. External DAS for Long-Term Backups
   Use a USB 3.0 or USB4 Direct-Attached Storage enclosure to keep periodic full or incremental backups of critical VMs (eCash node, Chronik/Agora, RMZWallet backend, etc.), adding an extra layer of resilience against catastrophic NVMe failure or local file system issues.

6. Conclusions

Deploying a 24/7 mini-server for an eCash node with Chronik and Agora indexes in Mexico is both technically feasible and economically accessible, provided operators:

• Choose a dual-NVMe Mini-PC with sufficient CPU and RAM.
• Invest in a high-IOPS, high-TBW SSD (e.g., Samsung 990 Pro 2 TB) for the node dataset.
• Protect the system with a pure sine wave UPS (1500 VA) and robust NUT-based shutdown logic.
• Use Proxmox VE + ZFS as a flexible, hypervisor-centric platform to host the node, RMZWallet, and other XolosArmy services.
• Implement SMART monitoring, planned SSD replacement, and PBS-based backups to avoid data loss.

For XolosArmy Network, this architecture is not merely infrastructure—it is a sovereign digital altar where the eCash consensus, RMZ token, and community applications coexist under a single, operator-controlled node.

By following this blueprint, any community member or operator can stand up a robust, energy-efficient, and research-driven infrastructure that aligns with the long-term vision of XolosArmy Network: decentralized guardianship of value and culture, anchored in eCash and embodied by the RMZWallet temple.