There are a number of new and changing rules being implemented in the Loki Hefty Heimdall hardfork, and Service Node operators should make sure they’re aware of the new requirements.
The following changes will be implemented on July 24 at block height 321,467.
Changing Rules:
- We have relaxed the Service Node deregistration rules in order to be more lenient on Service Nodes, particularly those that have previously demonstrated quality performance.
New Rules
- All Service Nodes must now run the Loki Storage Server to receive rewards.
- All Service Nodes must now have an accessible Public IP address and must open ports for the Loki Storage Server.
- There is now a penalty for Service Nodes that send their uptime proofs from different IP addresses.
More Detail:
Relaxed Deregistration:
After reviewing feedback from Service Node operators on Discord and Github over the past 6 months, the Loki team proposed a number of relaxations (included in Hefty Heimdall) with regard to how Service Nodes are deregistered when they fail to meet the expected requirements.
A few basic changes were made to implement the new system, including the introduction of a credit scheme and decommission/recommission transactions. The basic scheme is detailed below:
- Each Service Node starts with 2 hours of credit.
- Each Service Node earns 0.8 hours of credit per day of uninterrupted operation up to a maximum of 24 hours.
- If a Service Node has been assessed to be no longer meeting the standards of the network (for example, not submitting uptime proofs) the quorum looks to see if they have any credit.
- If the Service Node has 2 hours or more in credit, it will be decommissioned (instead of deregistered) for the amount of time it has in credit.
- When a Service Node is decommissioned, its funds are not locked for 30 days but it is removed from the rewards pool and cannot participate in normal network functions.
- If the Service Node starts sending uptime proofs again during the decommission period, the current quorum will detect this and submit a recommission transaction which will reset the Service Node’s credit balance to zero, and insert the decommissioned Service Node back to the bottom of the rewards list.
- If, during the decommission period, the Service Node’s credit runs out before it can successfully submit an uptime proof, it will be deregistered.
TL;DR Service Nodes now have a longer grace period which grows the longer your Service Node is up and performing well. Service Nodes that have been running without interruption for 30 days will now have 24 hours where they can be offline before they are deregistered and your funds are locked for 30 days.
Read the full details of the relaxed deregistration rules here: https://lokidocs.com/ServiceNodes/DeregistrationRules/
Loki Storage Server:
The Loki Storage Server is an application that exposes a public endpoint for Loki Messenger users to be able to store and retrieve messages on your Service Node. It is a necessary requirement for Loki Messenger.
Hefty Heimdall versions of lokid running in Service Node mode will look for a running Loki Storage Server on your machine. If lokid does not find a running Storage Server, it will refuse to start. Lokid will also periodically check to see if the Loki Storage Server is still running – if it isn’t, lokid will stop broadcasting uptime proofs.
You can easily manage lokid and the Loki Storage Server with the Loki Launcher, which sets up the required utilities. If you are an experienced system administrator, you can manage these utilities yourself – though we recommend you test your setup on testnet.
TL;DR You need to run the Loki Storage Server alongside lokid. Loki Launcher will do this automatically, otherwise binaries can be found here: https://github.com/loki-project/loki-storage-server
Public IP address and Open Ports:
All Service Nodes must now have a public IP address and open ports for lokid P2P and the Loki Storage Server. The default port for mainnet lokid P2P is 22022, and for the Loki Storage Server the default port is 23023.
If you are currently running your Service Node without any open ports or behind NAT, you will need to look into creating port forwarding rules in your router, and/or opening these ports in your firewall. If you are running a custom setup, you can change your default ports for Loki Storage Server and lokid P2P communications.
TL;DR You need to open ports in your firewall or router and have a public IP address.
IP Address Change Penalty:
We understand that many Service Node operators in the community are running backup servers which submit uptime proofs for their Service Node. Most operators have set up these backup servers by running another lokid with the –service-node flags on a seperate IP, but with the same Service Node key as their primary Service Node.
This setup creates a race between the two Service Nodes, which compete to send out the first uptime proof. Depending on the precise timing of when the separate lokids submit their uptime proofs, the relationship between the two Service Nodes can change. You may find one is master for a while, and then it switches. You may find the two Services Nodes swap on every announcement.
This race condition will be a problem in Hefty Heimdall because of the inclusion of the Service Node IP address in each uptime proof. Every time the server sending the uptime proof “wins”, it changes the IP on which the network tries to reach the Service Node’s Storage Server, and of course, the backup won’t have the same messages stored as the primary server.
Without modifying the Storage Server code to create a syncing channel between a master and backup Service Node, this problem is difficult to solve. Instead, the Loki team has implemented a punishment for Service Nodes that submit uptime proofs from different IP addresses. Each time your IP address changes, you will be dropped to the bottom of the rewards list losing your previous position.
From talking to Service Node operators, we found that one of the most common reasons they ran Service Node backups was because they didn’t have enough time to respond to outages on their Service Nodes. By addressing the core issue – which was the lack of forgiveness in the deregistration rules – we think there will be far fewer people wanting to run backup Service Nodes.
Although this change does not explicitly prevent the running of backup Service Nodes, Service Node operators who choose to run backup servers should ensure that they only send uptime proofs from the backup Service Node when it’s clear that the master server is actually down, rather than just setting up two Service Nodes and having both submit proofs at competing times.
TL;DR Running two Loki Service Nodes with the same SN key on two machines with different IP addresses will likely lead to your Service Node being dropped to the bottom of the rewards list regularly.
We are really excited to see these changes go live on mainnet on July 24. The Loki team and Loki community are always looking for ways to improve the stability and usefulness of the Service Node network, while maintaining a simple user experience so the Service Node network can continue to grow.