在Corda 2.0.0中，假设我有一些虚拟机用作公证人，每个虚拟机都有相同的规格。
据我所研究，我有两个选择：
在Cora中使用公证表现的推荐方法是什么？
并且，对于之后可能出现的一些问题。
[如果是独立公证人]：
serviceHub.networkMapCache.notaryIdentities将根据法定名称（doc）获取公证人名单，但我不知道哪个公证人资源最多。[如果是公证人群集]：
答案 0 :(得分：3)
一般而言，独立公证人的表现优于公证人群。为什么？拥有集群的目的是提供容错，并涉及将每个事务提交复制到集群的所有（或大多数）成员。
例如，在Raft的情况下，所有客户端请求都由领导节点提供服务，并复制到关注者。但是，领导者无法提交请求并向客户端发回响应，直到它知道大多数关注者已经确认它为止。单个事务提交将需要在集群方案中进行多次通信往返，而在单独公证的情况下则需要单个往返。
现在，回到你的问题，你的第一选择将导致三个没有容错的公证服务，第二个选择在一个复制的公证服务中。就纯粹的性能而言，三个独立公证人的合并交易吞吐量可能比单个复制公证人的合并交易吞吐量多三倍。
但是，单个事务只能包含分配给单个公证人的状态。如果要构建一个分配给不同公证人的状态的事务，则必须先将它们重新分配给同一个公证人。这涉及创建一个额外的公证变更＆＃34;有效地改变状态的公证指针的事务（更确切地说，它消耗状态，并使用新的公证指针创建副本）。
除了设置容错之外，如果有三个相当孤立的聚会团体主要在彼此之间进行交易，并且每个团队被分配了不同的公证人，则三个公证场景最有效。然后可以并行处理来自不同组的事务。但是，跨群体交易将产生额外的成本，需要额外的公证变更＆＃34;交易，这将减少性能的好处。从理论上讲，如果集团间交易与集团内部交易一样频繁，那么拥有一个或三个公证服务之间的业绩差异就会很小。
对于交易处理分配，由于上述原因，单个CorDapp不会预期或建议使用多个公证人。对于公证集群，来自客户端的请求以循环方式分发到副本（取决于一致性算法，副本仍然可以将所有请求转发给领导者！）。
崩溃容错一致性算法（Raft，Paxos）几乎总是比拜占庭容错的算法（PBFT / BFT-Smart，HoneyBadgerBFT，Hashgraph）更快，因为它们需要更少的通信步骤。