https://developers.eos.io/welcome/latest/protocol/network_peer_protocol

1 概述

在一个去中心化网络中，p2p网络的交互至关重要。

节点之间必须能够广播交易，同步块和状态信息。

同步状态的能力非常重要，决定最终是否能达成共识，即对块的不可逆状态达成共识。

基于此，p2p网络的基本目标就是同步区块，广播交易，以达成共识，并推进区块链状态。

1.1 目标

p2p网络的目标：速度和效率。即在有效的带宽下最大化交易吞吐量，同时降低网络和操作延时。

为了达到以上目标，以下策略被使用：

为了更好的规模经济，在一个块中装尽可能多的交易

在块和交易里面，最小化冗余数据

更有效的节点状态广播和同步

通过数据压缩和二进制编码，最小化负载信息

说明：以上策略大部分都已经在交易层被完全或部分实现。数据压缩是可选项，当发送对象实例和协议信息时，二进制编码被net serializer实现。

2 架构

主要由四个模块组成：

net plugin：定义块同步的协议，推送交易

chain controller：调度/管理收到的块和交易

net serializer：序列化消息，块，交易，为网络转发准备

local chain：维护区块链的本地备份数据，包括可逆块。

一个典型的消息流如下：

节点A通过net plugin发送消息给节点B

A的net serializer打包消息，并发送给B

B的net serializer解包消息，转发消息给net plugin

消息被B的net plugin处理，调度合适的操作

net plugin通过chain controller访问local chain，实现推送和获取块

2.1 local chain

如下图所示：

local chain是区块链数据在本地的备份。由不可逆块和可逆块组成。可逆块列表由Fork DB（分叉数据库）管理，chain controller将块推送到Fork DB中。

每个节点通过接受块和交易，同步状态信息，自行维护自己的local chain。可逆块是最新接收到还未变成不可逆状态的块。因此，不可逆块的分支都来自共同的祖先，即LIB（last irreversible block）。可逆块中的任何分支都可能成为最终区块链的一部分。

2.1.1 LIB

在一个节点中构造的所有不可逆块都应该与其他节点的不可逆块匹配(即不可逆块不应该有分支，就一条链)，直到最后一个不可逆块(LIB)。

最终，当LIB块后面的块到达终点时，LIB块通过其中一个分支向上移动链，同时赶上head block(HB)。

当LIB块前进时，不可逆的区块链有效地增长。

在这个过程中，根据接收到的潜在head block编号和它们的时间戳（不是最长链原则？），head block可能会多次切换分支，这些编号和时间戳最终作为是否是HB的关键因素。

2.2 chain controller

chain controller(cc) 管理块和交易的基本操作，改变local chain的状态，例如验证交易，执行交易，推送块等。

cc从net plugin接收命令，然后执行相应操作。

2.2.1 Fork DB(分叉数据库)

Fork DB为chain controller能对local chain执行操作提供内部接口。收到新的块时，chain controller将块推送到Fork DB。

这个过程可能会产生临时分叉。Fork DB有以下三个主要作用：

解决块应该基于哪个分支构建

推进head block，root block（此处应该是指可逆块中的root block，不是创始块）和lib block

消除无效的分支，消除孤立的块

个人理解，Fork DB就是上图中的reversible blocks，包含所有候选的块分支。lib块的选择最终决定哪个分支会被最终选择。未被选择的分支中的数据会被抛弃。

2.3 net plugin

net plugin定义节点之间p2p通信协议。主要目标是同步有效的块，转发交易。

net plugin包含以下几个功能模块：

sync manager：维护节点的块同步状态

dispatch manager：维护从其他节点发送来的块和交易列表

connection list：与自己连接的活跃节点列表

message handler：将协议调度到对应的handler处理

2.3.1 sync manager

sync manager实现节点之间同步块状态的功能。处理从其他节点发来的消息，基于和其他节点的lib，hb状态对比，执行实际的块同步操作。

一个节点处于以下同步状态的某一个：

lib catch-up：打算和另一个节点同步lib

head catch-up：打算和另一个节点同步hb

in-sync：打算和另一个节点同时同步lib和hb

例如，如果一个节点的lib或者hb落后于其他节点，将会生成一个同步请求消息，从其他节点获取缺失的块信息。类似，如果其他节点落后，节点将会通知落后的节点哪个块需要同步。

总之，就是节点之间不断的发“我有哪些块”，然后就能知道自己应该是“同步别人的块”还是告诉别人“来同步自己的块”。