I have another question. I’ve been trying to fix my node registration over the last few days and have come across a strange phenomenon.
The BLSKey of the masternode and the BLSKey of the fallback node are not identical in PeerInfo. (https://klever-radar.de/klever/node/peerinfo)
In either case. This makes it impossible to record them accurately.
Addon: There is a bug in the peer list. When I address my known master and fallback nodes directly, I receive the correct BLSKeys.
Regarding the BLSKey difference in PeerInfo:
This is expected behavior due to the way Klever node redundancy (fallback) is designed. The fallback node intentionally uses a different BLS keypair (the “observer” key) while it is in standby mode. This is to ensure that only the active node (main or fallback, but never both at once) uses the registered BLS identity for consensus operations.
When the main node is active, the fallback node reports its observer BLSKey in PeerInfo.
If the fallback node takes over (because the main node failed), it switches to use the main BLSKey.
This separation is crucial for preventing issues like double-signing, consensus conflicts, and identity ambiguity in the network.
Regarding the Peer List:
When you query your nodes directly, you receive the correct BLSKeys for both the main and fallback nodes. The difference you see in the public peer list may be related to how the monitoring service collects or updates its data—such as caching or aggregation methods. If you need the most up-to-date information, direct queries to your nodes are always the most reliable.
Let me know if you need a deeper explanation or details about the implementation!
In the past few days, I noticed that some validators who have been recently jailed have no index parameter, while others still do have one – this only applies to elected validators.
Normally, every entry has an index, but there are inconsistencies in my Radar’s consensus calculation.
I really want to finally fix the issue with the red blocks on the Radar, which are being displayed even though they shouldn’t be there.
A few days ago, we had a unique situation:
Anamix was jailed because it was running an incorrect software version.
Compass, on the other hand, was also jailed, despite running the correct software.
In the peer list, you can see that one of the jailed validators has no index parameter, while the other still has one. The key question is why one jailed validator keeps an index, while the other does not.
The peer list from that time is attached to help illustrate the difference.