fa2k.net are running a validator for EmpowerChain (https://www.empowerchain.io/). Helping make sure the plastic waste goes where it should – back into new products.

Validator name: FasGreenLife

We take validation seriously and are invested in the future of EmpowerChain!

💸Consider delegating to FasGreenLife for low commission and stable operation. We are not a professional business, so do keep an eye on the status.💸

Operations: see below

Validator information

Commission rate: 5 %

Address: empowervaloper1yux88ff7fx4a2mftakyace5vt5m4kdgqzaudcp

Exploreme validator details: https://empowerchain.exploreme.pro/validator/empowervaloper1yux88ff7fx4a2mftakyace5vt5m4kdgqzaudcp

Location: Oslo, Norway

Contact email: greenlife-admin@fa2k.net

🖥️Technical details

Hardware: Xeon E5-2697 v2. VM resources: 16 GB RAM / 8 cores. ZFS storage with 3 x 400 GB Intel SSD in RAID-Z.

Software: Kubernetes cluster with current mainnet Empowerchain running in a Docker container (see Related Projects below).

Connection: Residential 1250/50 Mbit.

☁️Climate impact

Because it’s running on quite old hardware, empowerd has increased the home power usage noticeably. On the other hand, reusing this hardware saves on manufacturing emissions.

The total home power usage is shown here in similar conditions (mainly the server and network equipment running). It seems to have increased by about 50 W, and become more variable, but a quantitative analysis has not been performed:

Figure: Total home power usage in Watts.

The electrical generation in Norway is primarily from hydro power (see for example https://www.iea.org/countries/norway). All the power used for FasGreenLife is certified renewable.

The waste heat of FasGreenLife contributes to home heating during about two thirds of the year when heaating is needed. The net impact of the added energy use is then zero, as the alternative is (unfortunately) resistive heating.

Related projects for node operation

Here is a custom node monitoring script we use to get an alert when the node is down: https://github.com/fa2k/cosmos-node-monitor/

Dockerfile to run empowerd in docker:
https://github.com/fa2k/dockerfiles/tree/main/empowerchain

Ops log

2024-01-12: Extensive testing and I/O optimisation. Rewriting the block database to try to improve storage efficiency. This caused a lot of missed blocks.

2024-01-08: Planned downtime for upgrading the HBAs to go from SATA 3Gb/s to 6Gb/s.

2024-01-04: There will be some downtime for upgrading the cable modem and reconfiguring the network.

2023-12-20: Upgraded to v2.0.0. We got the time of the upgrade wrong and missed many hours of blocks. Lesson learned: keep an eye on it or figure out Cosmovisor for next time.

2023-12-16: Voted yes for proposition 4 (version update, https://explorer.stavr.tech/Empower-Mainnet/gov/4) and prepared for the update.

2023-11-19: Disk replacement: The blockchain data are moved to a new small RAID of SSDs. The application rewrites the data frequently, making it very difficult to use caching solution (including some HDD storage for cold data). So now it’s a flat storage instead. This will hopefully improve the percentage of valid blocks.

2023-09-27: Server reboot due to maintenance of other workloads.

2023-09-13: Downtime of 1-2 hours due to maintenance at the ISP.

Notifications

If you have staked with FGL and would like to receive emails if we have trouble or are shutting down, you may leave a comment below. Include your MPWR address used for staking and your email address. We will send a confirmation that you will receive emails. The comment will not be publicly visible.

If you don’t want to leave your email, you can watch this website, or access the EmpowerChain Discord. We will notify the discord if we shutdown. https://discord.com/invite/DNB4z8EZD

Node operation notes

The node has huge requirements for I/O. It writes megabytes every second even when there’s just a single transaction executed every few seconds. Hopefully, this could be improved in future versions of the Cosmos SDK on which Empowerchain is based. I have high hopes for version 0.5.

It was useful to enable compression on the ZFS filesystem used for the node – specifically recordsize=4M and compression=zstd seems to reduce the IO load on the disks. Reducing block size relative to 64k could give better read latency, as it has to read and decompress smaller blocks. Due to compression efficiency and other unclear reasons, this increases the write load to ca. 140 MB/s at smaller blocks, vs 50 MB/s at 4M blocks. At the moment we prefer bigger blocks, to put less wear on the SSDs, preventing e-waste. More analysis is needed. The write rate can be more than halved by setting sync=disabled (ignoring fsync etc), but this is unsafe — as a validator we have to remember the blocks we signed even in the unlikely event of power loss. After a careful consideration of the risks, we disable the power loss protection and could thus risk losing a block or two of data in case of power loss or severe system crash. This will hopefully be fixed when the underlying Cosmos SDK is updated, and we also plan to experiment with other databases on the current version.

FasGreenLife has a motivation to perform in the top tier of nodes. At the moment, we’re not quite there… (see e.g. this page by ITRocket – https://mainnet.itrocket.net/empower/uptime).

The optimisation work is also reason that we had large downtimes in January, trying to fix the IT infrastructure. But as of now, there’s still a large number of missed blocks, and it’s not clear what the reason is from the logs.