区块链设计模式系列(一)对等网络

CITA-Cloud的设计理念是尽量复用现有软件或者库来搭建区块链系统。
但是区块链系统和传统的软件一个非常显著的区别是,区块系统是一个对等网络,而传统软件一般都是C/S或者Master/Slave形态。
所以在区块链设计中就有一个常见的模式,把非对等形态的软件变为对等形态。

比较简单的做法就是所有节点都是Server,同时又是其他节点的Client。
比如,CITA-Cloud网络微服务的实现 GitHub - cita-cloud/network_direct。以及现有的CITA的早期的直连网络实现也是如此。
可以认为是把系统自带的网络库提供的Server/Client形态的功能转换为对等网络。

这个方案实现上其实比较简单,麻烦的是生成配置文件,以及后续增加删除节点时修改配置文件。
生成配置文件可以参见CITA-Cloud中生成网络的配置文件:
runner_k8s/create_k8s_config.py at master · cita-cloud/runner_k8s · GitHub
前提是需要提供已知的所有节点的ip和port信息。
遍历所有的peers,为每个peer生成一个net_config。
port是本节点的监听端口,用于启动Server。
peers是除自己之外的其他节点的信息,用于本节点作为Client去连接其他节点。

因为需要所有节点信息才能生成对应的配置文件,所以需要集中统一生成,但是对于联盟链来说问题不大,这些信息可以认为是对内公开的。
同样,增加删除节点的时候,也涉及到所有配置文件的修改,需要集中修改,生成新的配置文件,然后下发到所有的节点。

另外一个例子是 GitHub - cita-cloud/controller_poc,其中的同步模块使用了Syncthing。
Syncthing是一个文件同步工具,默认情况下是Master/Slave形态。
也是通过类似的方式,实现了一个对等模式的同步网络,任何一个节点增加的文件都会同步到其他节点去。
生成配置文件的代码参见
runner_k8s/create_k8s_config.py at master · cita-cloud/runner_k8s · GitHub

如果要解决这种集中生成/修改配置文件的情况,网络部分就需要P2P网络库。
其本质是跟上述解决方案类似,只是节点之间会相互转发配置信息。这样新增或者删除节点,只要发送相应的配置命令到任意一个节点上,该节点就会将相应的变动转发给其他节点。
一开始搭建网络的时候有多个初始节点的情况,也可以转换为初始只有一个节点,其他节点都视为是动态新增的方案。
这个对于公链这样的无权限区块链系统来说非常有必要。但是对于联盟链这样有权限的区块链系统来说,必要性没那么强。因为即便可以方便的动态增加删除节点,依然需要一个中心化的地方来修改相应的鉴权信息。比如用证书来实现节点网络的准入,那么增加/删除节点肯定需要在对应的CA处先颁发或者吊销相应节点的证书。

3赞

还有一种解决方案是选出一个leader,依然采用Master/Slave的形态。Slave节点也接收请求并转发给leader。
就像Raft和Paxos的区别,Raft是leader base的一致性算法,而Paxos是无leader的。Paxos的每个节点都可以处理客户端请求,Raft只有leader节点可以处理客户端请求。
但是Raft的Slave节点也可以接收客户端请求,然后内部转发给leader节点去处理,让表面看起来像是个对等网络。

P2P网络分为两大类:非结构化和结构化。参见 P2P综述 - lotushy - 博客园 (cnblogs.com)
非结构化一般采用gossip的方式传播信息,前面所述的全链接可以算是gossip的一个特例。
结构化一般采用 分布式散列表(DHT)方式,后面讲的Master/Slave加转发,可以认为是结构化方案的一个特例。