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