在Corda2.0.0中,假设我有一些用作公证人的VM,并且每个VM都有相同的规范。
据我所研究,我有两种选择:
是利用Cora?公证性能的推荐方法
还有一些之后可能会出现的问题。
如属独立公证人
serviceHub.networkMapCache.notaryIdentities将根据法定名称(文档)获得公证名单,但我不知道哪个公证员剩下的资源最多。公证集群
发布于 2018-02-23 14:19:46
一般来说,一个独立的公证人会比一个公证人组做得更好。为什么?拥有集群的目的是提供容错,这涉及到复制每个事务提交到集群的所有(或大多数)成员。
例如,在Raft的情况下,所有客户端请求都由领导节点服务,并复制到跟随者。但是,在知道大多数追随者已经承认之前,领导者不能提交请求并向客户发送回复。在集群场景中,单个事务提交将需要多个通信往返,与单独公证情况下的单个往返相比。
现在,回到您的问题,您的第一选择将导致三个没有容错的公证服务,第二个在一个复制的公证服务。就纯性能而言,三个独立公证人的合并事务吞吐量可能是单一复制公证人的三倍以上。
但是,单个事务只能包含分配给单个公证人的状态。如果您想要与分配给不同公证人的状态一起构建事务,您必须首先将它们重新分配给同一个公证人。这涉及创建一个额外的“公证更改”事务,该事务只需更改状态的公证指针(更准确地说,它会消耗状态,并使用新的公证指针创建副本)。
撇开容错不说,三种公证方案的最佳效果是,如果有三组相当孤立的缔约方彼此间进行交易,而每一组得到不同的公证。然后可以并行处理来自不同组的事务。然而,跨组交易需要额外的“公证变更”交易成本,这将降低绩效效益。理论上,如果组间事务和组内事务一样频繁,那么拥有一个或三个公证服务的性能差异将是最小的。
对于事务处理发行版,出于上述原因,不期望或建议单个CorDapp使用多个公证。对于公证集群,来自客户的请求以循环方式分发给副本(取决于协商一致的算法,副本仍然可以将所有请求转发给领导者!)
崩溃容错协商一致算法(Raft,Paxos)几乎总是比拜占庭容错算法(PBFT/BFT-Smart,HoneyBadgerBFT,哈希图)更快,因为它们需要更少的通信步骤。
https://stackoverflow.com/questions/48930346
复制相似问题