Hyperledger indy validator-info basic explanation

Question

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

• What has happened with the number?
• What does the number mean?
• Is there some delay or why I needed to wait few minutes until (1) for Node2 disappeared.
• Even after 20+mins the (1) has not been assigned to any of the Reachable hosts. Why?

Answer 1

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

• What has happened with the number?

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.

• What does the number mean?

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.

• Is there some delay or why I needed to wait few minutes until (1) for Node2 disappeared.

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.

• Even after 20+mins the (1) has not been assigned to any of the Reachable hosts. Why?

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.

Answer 2

Unlike other BFT protocols, RBFT focuses more on the worst-case performance. As a result, it runs the f+1 instance of the BFT protocol. One such instance is called a master instance, and others are called backup instances. The node assigned (0) is the primary node of the master instance, and the node assigned (1) or other number is the primary node of the backup instance. In case there is a considerable difference in the performance of the primary of the master and backup instance, then a view change is called to change the primary node of all the instances.