我正在使用hyperledger indy,它是validator-info
,但是我真的找不到括号(节点别名旁边)中的数字是什么意思。
我相信它与主节点有关,但这只是我的假设,我从未在indy的文档中看到有关该数字的任何注释。有人可以解释一下节点别名旁边的数字是什么。 Node1 (0)
或Node2 (1)
是什么意思?
Reachable Hosts: 4/4
Node2 (1)
Node1 (0)
Node3
Node4
Unreachable Hosts: 0/4
当我停下Node2
时,我可以看到Node2
变得无法访问。如下所示,(1)
旁边仍然是Node2
的标志。
Reachable Hosts: 3/4
Node4
Node1 (0)
Node3
Unreachable Hosts: 1/4
Node2 (1)
但是,在几分钟(±5分钟)后,(1)
的数字Node2
消失了。
Reachable Hosts: 3/4
Node4
Node3
Node1 (0)
Unreachable Hosts: 1/4
Node2
当我再次启动Node2
时,它又可以访问,但是Node2
旁边的数字不在这里。
Reachable Hosts: 4/4
Node1 (0)
Node3
Node2
Node4
Unreachable Hosts: 0/4
(1)
的{{1}}消失了。 Node2
。为什么?答案 0 :(得分:1)
好吧,在调查了git commit和INDY的吉拉历史几小时后,我发现了INDY-967 ticket。
有人要求增加一些附加功能,以增强验证者信息的实用性。
请求:
指示当前主节点的节点。在冗长的人类可读输出中,可以通过以下方式在括号中的主要数字表示为主要节点的名称,以这种方式表示:
实际上,有一条与我的操作类似的评论-为什么数字消失了。这个问题也有答案。
例如,如果节点是主节点,并且断开连接超过2-3分钟,则将删除整个实例。如果我们没有实例,那么我们就不能拥有主节点,因此,预计无法访问的节点不是主节点。 在视图更改期间某些实例也可能没有主对象
该实例已断开连接,几分钟后,共识决定删除该实例,因此无需将该节点保留为主节点。
数字表示主要节点。 (0)
是第一个BFT协议实例的主节点,(1)
是第二个BFT协议实例的第二个主节点-类似于RBFT protocol white paper中定义的(0)
的备份。
延迟是一段时间,直到与新的备份BFT协议实例达成共识为止。 1
应该分配给另一个节点。
我目前的假设是,在主要BFT实例相同之前,共识和RBFT / Indy-Plenum的RBFT不会对主要实例运行新的“选举”,也就是对BFT实例进行“轮循”分配。因此,如果不可用的节点具有备份主副本,则没有关系,也不需要更新BFT实例。