The first PoD governance vote: Should the node penalty rules be adjusted? Nebulas Follow Feb 25 · 6 min read

Recently, the node penalty rules have ignited a discussion among node operators. As a result, a proposal was initiated: Marks Proposal: POD Block Generation Penalties (NIP199) https://go.nebulas.io/proposal/199

This proposal seeks to see if others in the community feel the current node penalties need to be modified.

The Nebulas Foundation decided to adopt the proposal and launch it as the first community vote this year. The Governance Committee will vote for this proposal next week.

Current penalty structure:

The rules of governing the network and subsequent penalties is a comprehensive problem. It is necessary to guarantee the stability and security of the main network thereby severely punishing the perpetrators. At the same time, we must protect the assets and benefits of node operators.

For a full overview, please refer to the Node Decentralization Plan Based on Proof of Devotion at: https://wiki.nebulas.io/en/latest/node-strategy/consensus.html#penalties

The current penalty rules are as follows:

Status of the testnet node penalties:

Since January 8, over 60 nodes have been involved in this phase with 52 nodes successfully deploying and generating blocks. Node operators include the Exchanges, Wallets, Blockchain Projects, Mining Pools, community members, Media, Community Organization and others. Among them, 9 nodes have had the situation of not producing blocks, when expected during a cycle leading to a low-security level penalty 6 times. In addition, there have been 11 times where a node triggered a medium-security penalty (not producing any blocks for a cycle).

Of course, the penalties currently incurred are all testnet assets. However, once the Node Decentralization Program is launched on the mainnet, actual Nebulas assets will be locked.

Problem:

The current design conflicts with the primary focus of minimizing node downtime. Once a node is not available for block generation when expected, it’s very likely for it to not be available for the remaining cycle (approximately 52 minutes). This leads to further downtime, the drop of the node Stability Index (SI) as well as assets being locked.

Currently, the SI rating due to missing blocks drops linearly, from the outage out to the restoration time. On average, it takes two days (because of the probability problem, time difference, inexact value) the SI rating to recover as well as a 5% penalty (about 1000NAS, according to the current currency value of about 600 US dollars). All nodes require a minimum of 20,000 NAS as collateral, however, when a node is hit with a penalty, the collateral level drops below the minimum. In this scenario, a node must deposit enough NAS to retain the 20,000 NAS level. Due to this loss, the network loses an active node thus being potentially less stable.

Existing solutions:

Currently, there are some functions for the above situation, to protect the interests of node operators. We believe that the best solution is to use a variety of monitoring services and early warning measures to avoid nodes potentially being punished. Emergency response is an important requirement when problems arise.

Active suspension of nodes:

If the node operator has special circumstances and needs to suspend the server operation, such as server relocation, they can temporarily disable it from the candidate pool via their node management control panel by selecting “Suspend Node” located at node.nebulas.io. Once suspended, the node enters a suspended state and the node details page will display the suspension flag. Community members can still cast NAX to the node, but the node will not participate in the candidate pool until the node suspension is canceled via the node operator. This period does not affect the stability index of the node.

However, if a node is actively participating in consensus, it cannot be paused. The pause state will begin from the next polling cycle.

Block and Penalty Message Reminders:

When a node misses a block or is punished, the registered mailbox of the node receives a notification. The contact email address is a mandatory requirement. All node operators must make sure the enter email address is correct.

Adding multiple contact email addresses is currently not supported. It is suggested that the node operator utilize an email accessible from a mobile for quicker response; email forwarding to a node support team is also a good idea.

Current node operators can also fill in social platform information, however, reminders via social platforms are not yet developed. This is due to different countries’ habits, such as WeChat and Telegram reminders. Community developers are invited to participate in the development of a notification widget.

Server Monitoring Configuration:

It is recommended that the node operator turn on the VPS/Bare Metal Service Provider Monitoring so that any downtime can be reduced to a minimum.

For example:

Status monitoring: Downtime, CPU, memory;

Alert configuration: For example, 90% of the memory is used for early warning, and the downtime is used for alarm.

Emergency measures: Such as an automatic restart of the node.

It is strongly recommended that automated emergency measures be set up to respond to issues in a timely manner. We have also organized help documents and give some recommended monitoring services.

Governance Mechanism — Unfreezing Penalty:

The node operator can publish a complaint at the voting stage of each governance cycle. The governance node will have the final say whether penalty funds should be returned.

Planned improvements:

In order to better monitor node status, in addition to existing features, information presentation will be enhanced and more tools will be added.

Node platform information display:

Real-world situations such as increasing CPU, memory, and transaction volume show that node operators and community members can clearly see the actual state of each node server.

Self-built log monitoring platform or data panel:

Open API interface, recommended use of telegraf, developers can build their own node monitoring platform, or build node-related data panels for communities.

More detailed error status display:

In the process of building the node, provide more detailed error state display, convenient node operator query. For example:

Node synchronization did not complete: Displays the synchronization height and current height;

Profile configuration error: The mining configuration is not opened and the mining address is configured correctly.

In summary, the current punishment rules and node monitoring measures ensure a stable network. If the PoD governance vote is passed next week, a proposal for new penalty rules will be launched on go.nebulas.io, Nebulas’ community collaboration platform. If the vote fails, the penalty rules will remain unchanged for the launch on the main network. Regardless of the results, the help documentation, API development, etc… mentioned above will continue.

The first governance committee will consist of the 51 consensus nodes that have produced the most blocks on the testnet during the PoD test phase. The node operators are invited to participate in the first PoD governance vote as to whether the current punishment rules need to be adjusted.

Community members are always encouraged to make recommendations on the Nebulas community collaboration platform go.nebulas.io. Whether you are a developer or not, you can give your valuable opinion.