Building and Self-Hosting a Kusama Validator

Building and Self-Hosting a Kusama Validator

Posted on Sunday, 26 February 2023 Suggest An Edit
# Kusama # blockchain # validator # self-hosting # decentralization # hardware # performance

Introduction

In a world shackled by centralized control, the Kusama network rises as a beacon of hope, a canary network for Polkadot that challenges the status quo. With its increasing presence beyond the confines of traditional data centers, Kusama has become an emblem of decentralization and autonomy. In this guide, I’ll share how to build and self-host a Kusama validator that not only resists the oppressive chains of centralization but also meets the performance demands of a cutting-edge blockchain network.

Hardware: Fighting Centralization with Every Component

Kusama validators demand powerful resources, calling for at least 16GB of RAM, 1TB NVME, and 4 CPU cores. Our setup exceeds these requirements, creating a system capable of not only validating Kusama transactions but also running other decentralized services, empowering users to break free from the centralized control of Big Tech.

Components

components inside

  • CPU: AMD RYZEN 5 5600G 6-Core 3.7 GHz (4.6 GHz Max Boost) Socket AM4 65W
  • RAM: 2x32GB Hynix DDR4 3200MHz
  • Motherboard: MSI A550M-ITX/ac
  • SSD: 2x 2TB NVME Hanye ME70 7200Mb/s
  • PSU: 160W PicoPSU with 12V 10A AC/DC adapter
  • Case: Rgeek 200mm x 200mm x 80mm

Validator Nodes: A Testament to Decentralization

Our hardware configuration enables us to run up to four validator nodes per machine, showcasing the sheer power of our components. Both machines are equipped with 2x Hanye ME70 2TB 7200MB/s 800k IOPS NVME, providing ample storage and speed for the demanding tasks of a Kusama validator. mitx-hardware

Performance and Benchmarking: The Metrics of Rebellion

Using IOPS/latency measuring fio-(tool) and Polkadot benchmarking tools, we tested our hardware’s mettle against the oppressive demands of centralized systems. The results proved our machines were more than capable of resisting the chains of centralization, thanks to their high clock speeds and single-thread performance.

Benchmarking

Overall

XI01 xi02

CategoryFunctionScoreMinimumResult
CPUBLAKE2-2561.04 GiBs1.00 GiBs✅ Pass (103.1 %)
CPUSR25519-Verify655.02 KiBs666.00 KiBs✅ Pass ( 98.4 %)
MemoryCopy16.47 GiBs14.32 GiBs✅ Pass (115.0 %)
DiskSeq Write2.02 GiBs450.00 MiBs✅ Pass (458.5 %)
DiskRnd Write640.59 MiBs200.00 MiBs✅ Pass (320.3 %)

NVME memories used

Latency

Minimum: 601 ns Maximum: 40637 ns Mean: 1213.183773 ns Standard Deviation: 579.654872 ns 99.99th Percentile Read Latency: 302 ns The read latency meets the 2microseconds and lower QoS requirement.

Software: Crafting the Perfect Ecosystem for Decentralization

Boot Partition and Storage

To maximize reliability and performance, we run the boot partition on a USB stick while the host machine’s root is stored on a 100GB mdraid level1 RAID between 2x 2TB Hanye NVMEs on both machines. The blockchain databases and LXC-container root sections are installed in ZFS storage in RAID0 between the leftover space from mdraid roots (~1.9TB -> 3.8TB together).

Both validators

Security and Sustainability

We take additional steps to secure and optimize the validator nodes, including disabling SMT, disabling automatic NUMA balancing, and configuring Spectre/Meltdown mitigations. The BIOS is set to auto-start the machine, and we use a smart switch to measure power consumption, enabling CO2 emission compensation and supporting a more sustainable future.

By following this guide, you too can break the chains of centralization and build your own Kusama validator, joining the ranks of those fighting for a more decentralized and equitable world. Together, we can resist the oppressive power of centralization and create a more just, open, and free digital landscape.

Comments