blockchainhyperledgerhyperledger-indy

Hyperledger indy validator-info basic explanation


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

Solution

  • 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.