我在玩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分钟(后，CCD_ 9的CCD_。
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
- 这个号码怎么了
- 这个数字是什么意思
- 是否有延迟或我需要等待的原因直到CCD_ 13的CCD_ 12消失
- 即使超过20分钟(1(还没有被分配给CCD_ 14中的任何一个。为什么
好吧，经过几个小时的git提交和INDY的jira历史调查，我找到了INDY-967票证。
有人要求提供一些额外的功能，以增强验证器信息的有用性。
请求：
指示作为当前主节点的节点。在详细的人类可读输出中，这可以通过作为主要节点的名称后面括号中的主要数字来表示，如下所示：
实际上有一个类似于我的OP的评论-为什么这个数字消失了。这个问题也有答案。
例如，如果节点是主节点，并且断开连接的时间超过2-3分钟，则整个实例将被删除。如果我们没有实例，我们就不能有它的主节点，所以不可访问的节点不是主节点。也有可能某些实例在视图更改期间没有主实例
- 这个数字怎么了
实例已断开连接，几分钟后，一致决定删除该实例，因此无需将节点保留为主节点。
- 这个数字是什么意思
该数字表示主节点。(0)是第一个BFT协议实例的主节点，(1)是第二个BFT方案实例的第二个主节点，类似于RBFT协议白皮书中定义的(0)的备份。
- 是否有延迟，或者为什么我需要等待几分钟，直到Node2的(1(消失
延迟是一段时间，直到与新的备份BFT协议实例达成一致。1应该被分配给另一个节点。
- 即使在20多分钟后，(1(也没有分配给任何可达主机。为什么
我目前的假设是，在主要BFT实例相同之前，共识和RBFT/Indy Plenum的RBFT不会运行新的"选举"，即主要实例的视图更改或BFT实例的"循环"分配。因此，如果不可用的节点有备份主副本，这无关紧要，也不需要更新BFT实例。
与其他BFT协议不同，RBFT更关注最坏情况下的性能。因此，它运行BFT协议的f+1实例。其中一个实例称为主实例，其他实例称为备份实例。分配的节点(0(是主实例的主节点，分配的节点或其他编号(1(是备份实例的主结点。如果主实例和备份实例的主节点的性能存在相当大的差异，则会调用视图更改来更改所有实例的主结点。