I am playing with hyperledger indy and it's validator-info
, but I really cannot find what does the number in brackets (next to a node alias) mean.
I believe it has something with primary node but it's just my assumption and I have never seen any note about the number in indy's documentation. Could somebody explain me what does the number next to node alias eg. Node1 (0)
or Node2 (1)
mean?
Reachable Hosts: 4/4
Node2 (1)
Node1 (0)
Node3
Node4
Unreachable Hosts: 0/4
When I stop the Node2
I can see the Node2
has become Unreachable. The sign (1)
is still next to Node2
as you can see below.
Reachable Hosts: 3/4
Node4
Node1 (0)
Node3
Unreachable Hosts: 1/4
Node2 (1)
However after couple of minutes (±5mins) number (1)
for Node2
has disappeared.
Reachable Hosts: 3/4
Node4
Node3
Node1 (0)
Unreachable Hosts: 1/4
Node2
When I start Node2
again it becomes reachable again but the number next to Node2
is not here.
Reachable Hosts: 4/4
Node1 (0)
Node3
Node2
Node4
Unreachable Hosts: 0/4
(1)
for Node2
disappeared. Reachable hosts
. Why?Alright, after several hours of investigating history of git commits and INDY's jira I've found INDY-967 ticket.
There was a request for few additional features that will enhance validator-info usefulness.
Request:
Indicate the nodes that are the current primaries. In the verbose human-readable output, this can be indicated by the primary number in parenthesis after the name of the nodes that are primaries, in this fashion:
Actually there is a comment similar to my OP - why the number has disappeared. And there is an answer for the question as well.
if node is primary for instance and it is disconnected for more than 2-3 min then whole instance is removed. if we do not have instance we cannot have primary for it, so it is expected that unreachable node is not a primary. also it is possible that some instance has no primary during view change
The instance has been disconnected and after few minutes consensus has decided to remove the instance so there is no need to keep the node as primary.
The number indicates primary nodes. The (0)
is primary node of 1st BFT protocol instance and (1)
is second primary node from second BFT protocol instance - something like backup of (0)
as it is defined in RBFT protocol white paper.
The delay is a period of time until consensus with new backup BFT protocol instance is reached. The 1
should be assigned to another node.
My current assumption is that until primary BFT instance is the same the consensus and RBFT / Indy-Plenum's RBFT doesn't run new "election" aka view-change for primary instance or "round-robin" assignment with BFT instances. So if the node which is not available had backup primary replica it doesn't matter and doesn't require update of BFT instances.