The only metric that matters, or rather that WILL matter going forward, is vote count.
Let’s back up a moment. The current state of community Nodes (Nodes other than the 176 Incognito-run Nodes) is the temporary solution to a decision back in 2019. That temporary solution was only supposed to last ~3 months. Briefly – while the network was bootstrapping from the genesis block, the Incognito team operated 176 Nodes that ensured network consensus across the 8 shards, while community Nodes came online in increasing numbers. These Nodes represent 2/3rds of the voting power, which is enough to achieve consensus for any transaction. Community Nodes fill the other 1/3rd of voting power. The intent was (and is) to ensure that unstable community resources (be it server specs, network infrastructure, the internet itself, etc) wouldn’t affect consensus during these early days. There is more to unpack, however I’m attempting to be brief here.
This means that for every validated block, all 350 of them per shard per epoch, any each shard’s committee will be awarded block rewards because consensus will always be achieved due to those team-run nodes. Each of the ten community Nodes per shard could be offline, have a flapping internet connection, run on VPS without enough resources to validate blocks, etc. Block rewards are awarded to the entire shard, then divided equally between the committee members. It is not apportioned out based on actual block voting (or lack thereof).
Thus right now, block rewards for community Nodes basically means your Node was successfully staked and indexed by the Incognito blockchain. That’s it. Your Node is not awarded block rewards because it was online during its assigned committee or that it voted during same. It is was awarded block rewards because it was successfully staked when you first brought it online and has been selected for committee. Participation in committee is not currently a factor.
The voting metric will be used by the soon-to-be-implemented slashing, which will begin removing Nodes that are not maintaining a vote percentage of at least 50%. A Node can only vote when both the beacon shard and the assigned committee shard are fully synced before committee participation. This is the reason once Nodes are selected for committee, they remain in a Pending role: they are syncing the assigned shard’s blockchain.
There are a number of reasons a Node may not be able to successfully vote.
- A Node may be powered off or fully disconnected from the internet.
- These nodes would have a 0 vote percentage.
- A Node may reside on a server than cannot validate blocks in the appropriate amount of time (~40 seconds).
- These nodes would have a zero to low vote percentage.
- A Node may be connected to the internet with an unstable connection that makes that Node unavailable at times.
- These nodes would have a vote percentage that would be less than 100%. It would be possible for one epoch to have a vote percentage above 50% and the next below 50%.
- A Node may not have fully synced the shard blockchain, despite being online with a solid internet connection.
- These nodes would have a vote percentage of zero, as they cannot vote until the shard blockchain is fully synced.
- Other reasons including but not limited to acts of war, deity, man and beast, etc.
Under the current “temporary” solution, these Nodes are each awarded block rewards when selected to committee. However under the forthcoming slashing rules, these Nodes would each be slashed – have their 1750 PRV stake forcibly unstaked, removing them from the large pool of waiting substitute candidates.
The first three reasons are easily within an operator’s control.
- Turn on your Node if it’s off.
- Bump up the host server specs if your vNode can’t verifying transactions in ~40 seconds. (pNodes shouldn’t have this issue)
- Change your internet provider or fix your network issues to improve network availability.
The team is currently working hard to resolve issues creating sync stalls between Nodes. Again there are several reasons for a stall. A Node server could have a failing or failed HD/SSD. The Node’s HD/SSD may be write locked due to running out of space. The internet connection may be flapping. There may be other issues with the software components (Docker, etc). Thus a sync issue may be up to the operator to resolve or it may be also be a more widespread network issue requiring intervention from the team.
The takeaway should be that a Node that has been earning block rewards is NOT guaranteed to earn block rewards once slashing is enabled. Pay attention the Voting metric on the Node Monitor. If it is less than 50% contact support. The more Node operators that take an active role in resolving sync stalls with support, the stronger the network will become.