Milestone for the XRPL Validator

Date: 11th June 2021

We have got our first 100% score under a 24 hour time frame!

Due to the expensive nature of using hosted solutions, I wanted to see if I could run an XRPL validator over a home broadband environment using refurbished equipment.

Well, it sure does looks like we can.

XRPL Specifications

On the 11th June 2021, the XRP server specifications are as follows:

• Operating System: Ubuntu, CentOS or RedHat Enterprise Linux at the latest releases
• CPU: 3 GHz processor with 4 cores and hyperthreading enabled (minimum)
• Disk: SSD with 10000+ IOPS
• RAM: 32 GB
• Gigabit network interface on the local LAN i.e. any switches and network cards must support at least 1 gigabit per second speed

Current specifications can be found here.

Dell Optiplex 7010 Server Specification

I decided to buy a refurbished Dell Optiplex 7010 SFF 64 bit with the following specifications:

• CPU: Core i3-3240
• 16 GB of RAM
• 250GB SATA Drive
• Kingston SSDNow A400 240GB SATA 3 Solid State Drive
• Ubuntu 20.04 64 bit

CPU: Core i3-3240

You can confirm the CPU settings using the cpuinfo command. Mine shows the following:

Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 36 bits physical, 48 bits virtual CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 58 Model name: Intel(R) Core(TM) i3-3240 CPU @ 3.40GHz Stepping: 9 CPU MHz: 2081.202 CPU max MHz: 3400.0000 CPU min MHz: 1600.0000 BogoMIPS: 6784.41 Virtualisation: VT-x L1d cache: 64 KiB L1i cache: 64 KiB L2 cache: 512 KiB L3 cache: 3 MiB NUMA node0 CPU(s): 0-3 Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Meltdown: Mitigation; PTI Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP conditional, RSB filling Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nons top_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp t pr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm arat pln pts md_clear flush_l1d

16 GB of RAM

The server came with 8 GB of RAM, so I bought an extra 2 x 8 GB of RAM. One word of caution, the motherboard on these servers appear to require the RAM to be evenly installed over the 4 slots – meaning I cannot mix and match RAM sizes.

So although Ripple recommend 32 GB of RAM, I have set it to 16 GB. My reasons for this is because my tests indicated that the amount of RAM being used was correlated to the amount of ledger history my server was storing and the database being used.

So by using the following settings in the Ripple configuration, I could manage the RAM usage:

• online_delete=2000
• advisory_delete=0
• [ledger_history]
• 1999

Setting Explained

• advisory_delete to 0 tells the server to delete history automatically.
• online_delete tells the server how many ledger version to keep available at any one time. The higher the value, the more RAM would be used.
• ledger_history is the amount of history the server would store. Notice it is lower than online delete. Again the more history is stored the more RAM and storage would be used.

250GB SATA Drive

This drive will primarily be used to store the operating system and have the system boot from. This saves space on the SSD drive, and allows me to switch out the drive in case of failure without losing my XRPL validator's database.

Kingston SSDNow A400 240GB SATA 3 SSD

Used to store the XRPL database for the validator to keep a ledger history.

There are two databases you could use to run your XRPL validator, RocksDB and NuDB.

RocksDB uses more RAM, but is more faster if you have enough RAM. If you dont have enough RAM, I found that my system would begin to use SWAP and slow down. RocksDB however, can work on none solid state drives.

NuDB on the other hand uses less RAM, but appears to work well on solid state drives, and so this is the database I chose. It is also the default database.

Ubuntu 20.04 64 bit

Well supported operating system continuously being updated and supported.

I did decrease the swappiness to 5, the default is 60.

A Good Validator

A good validator participates in the consensus votes on the XRPL in a timely manner - 24 hours a day 7 days a week, and its ownership is verified.

The above hardware and software specifications should be enough to run a decent validator providing you have a reliable and fast Internet connection, and an XRPL validator does not actually need a dedicated IP address in order to participate. However, you might need one if you want to allow API calls to your server.

If you are considering allowing API calls to your server, consider using Let's Encrypt SSL certificates here, they are free and improves security.

Domain Verification

Domain verification confirms who operates the XRPL validator. This is done by hosting a TOML file.

You can see our TOML file here also verified here.

You will notice that there is also a DNS text record set to a sub domain:

• _xrpl.sun-dara.co.uk

This DNS text record stores my XRPL validator's public key:

• nHDJ3J1WZDuD8K7zDUgHEup9dms4CP1YzaV2tj1MmMrYdVxszits

You can also use the "xrp-ledger.toml Checker" here to confirm.

Conclusions

After checking my server here daily, my scores were quite low, but I left the server running and did not change anything, as I had a feeling that it would take time for things to synchronise.

I had missed out on a lot of votes initially, it took about 2 weeks to get my first 100% score in 24 hours (Thursday, June 10, 2021)

A list of my scores are below, but you can see the most recent scores here.

Score List

• Thursday, June 10, 2021 Score: 1.00000
• Wednesday, June 9, 2021 Score: 0.91329*
• Tuesday, June 8, 2021 Score: 0.91269
• Monday, June 7, 2021 Score: 0.78238
• Sunday, June 6, 2021 Score: 0.95670
• Saturday, June 5, 2021 Score: 0.82649
• Friday, June 4, 2021 Score: 0.78273
• Thursday, June 3, 2021 Score: 0.91283
• Wednesday, June 2, 2021 Score: 0.91368
• Tuesday, June 1, 2021 Score: 0.82563
• Monday, May 31, 2021 Score: 0.95649
• Sunday, May 30, 2021 Score: 0.91249
• Saturday, May 29, 2021 Score: 0.95679
• Friday, May 28, 2021 Score: 0.70870
• Thursday, May 27, 2021 Score: 0.43526
• Wednesday, May 26, 2021 Score: 0.87128

So I do feel that the current infrastructure is fine, and the advantages of using such a set up:

• I did it for less than a 2 months worth of Amazon AWS hosting on the Amazon t3.2xlarge.
• I can potentially upgrade as I go – moving the solid state drive from one machine to another.
• I have recycled and made use of equipment that would have potentially been scrapped using up energy.
• I continuously learn to improve my network.

Acknowledgements

Special acknowledgements to:

• Leah Bolden and the team at seejanedrill here.
• Rex Krueger here.
• The Post Apocalyptic Inventor here.
• scooby1961 here.

The way these people think influenced the way I should think!