点对点网络是区块链中核心的技术之一,主要关注的方面是为区块链提供一个稳定的网络结构,用于广播未被打包的交易(交易池中的交易)以及共识过的区块,部分共识算法也需要点对点的网络支撑(如PBFT),另外一个辅助功能,如以太坊的消息网络,也需要点对点网络的支持。
P2P网络分为结构化和非结构化网络两类。结构化网络采用类似DHT算法来构建网络结构;非结构化网络是一种扁平的网络,每个节点都有一些邻居节点的地址。
点对点网络的主要职责有维护网络结构和发送信息这两个方面。网络结构要关注的是新节点的加入和网络更新这两个方面,而发送信息包括广播和单播两个方面
如何建立并维护点对点的整个网络?节点如何加入、退出?
网络结构的建立有两个核心的参数,一个是每个节点向外连接的节点数,第二个是最大转发数。
新节点对于整个网络一无所知,要么通过一个中心的服务获取网络中的一些节点去连接,要么去连接网络中的“种子”节点。
网络更新处理当有新节点加入或者节点退出,甚至原来一些节点网络不好,无法连接,过一段时间又活了,等等这些情况。一般通过节点已有的连接来广播这些路由表的变化。需要注意的是,因为点对点网络的特殊性,每个节点的路由表是不一样的(也叫partial view)
广播一般采用泛洪协议,即收到转发方式,使的消息在网络中扩散,一般要采用一些限制条件,比如一条消息要设置最大的转发数,避免网络的过渡负载。
单播需要结构化网络结构支持,一般是DHT,类似于DNS解析的方式,逐跳寻找目标节点地址,之后进行传输,并且更新本地路由表。
要想快速检索信息,有两种数据结构可以使用,一种是树类型,如AVL树、红黑树、B树等;另外一类是hash表。
哈希表的效率比树更高,但是需要占用更多的内存。
信息的表示采用键值对的方式,即一个键对应一个值,我们要查找的是key,值是附着的信息。
哈希表要解决的问题是如何均匀地为每一个key分配一个存储位置。
这里面有两个重点:1.是为key分配一个存储地点,这个分配算法是固定的,保证存储的时候和查找的时候使用同一个算法,不然存进去之后会找不到;2.是均匀地分配,不能有点地方存放数据多,有点放存放数据少。
一般语言里面的hashtable、map等结构使用这个技术来实现,哈希函数可以直接使用取模函数,key%n,这种方式,n代表有多少个地方,key是整数,如果key是其他类型,需要先进行一次哈希,将key转为整数。这种方式可以解决上面的两个需求,但是当n不够大的时候(小于要存储的数据),会产生冲突,一个地方一定会有两个key要存储,这时候,需要在这个地方放一个链表,将分配到同一地点、不同key,顺序摆放。当一个地点放的key太多后,链表的查找速度太慢,要转化为树类型结构(红黑树或者AVL树)。
上面说过,哈希表效率很高,但是占用内容,使用多台机器就可以解决这个限制。在分布式环境中,可以将上述的地点理解为计算机(后面成为节点),即如何将一个key映射到一个节点上,每个节点有一个节点ID,即key->node id的映射,这个映射算法也要固定。
这个算法还有一个非常重要的要求,即scalebility,当新节点加入和退出时候,需要迁移的key要尽量少。
这个映射算法有两种典型结构,一个是环形,一个是树形;环形的叫一致性哈希算法,树形的典型叫kademlia算法。
选点算法就是解决key->node id的映射算法,形象的来说就是为一个key选择它生命中的她(节点)。
假设我们使用32哈希,那么总共能容纳的key的数据量是2**32,称之为hash空间,把节点的ID映射成整数,key也映射成整数。把key哈希和节点哈希值接的差值的叫做距离(负数的话要取模,不用绝对值),比如一个key的哈希是100(整数表示),一个节点的哈希是105,则这两个的距离是105-100=5。当然使用其他距离表示也可以,比如反过来减,但是算法要固定。我们把key映射(放到)距离他最近的节点上。距离取模的话,看起来就是把节点和key放到一个环上,key归属到从顺时针角度离它最近的节点上。
kademlia算法的距离采用的是key哈希与节点哈希异或计算之后的数值来表示(整数),从左往右,拥有越多的“相同前缀”,则距离越近,越在左边位置不一样,距离越远。
树结构的体现是,将节点和key看成树的节点,这个算法支持的位数是160bit,即20个8字节,树的高度为160,每个边表示一位。
选点的算法和一致性哈希相同,从所有节点中,选择一个距离key距离最小的节点作为这个key的归宿。
由于是在分布式环境中,为了保证高可用,我们假设没有一个中心的路由表,没有这个可以看到全貌的路由表,带来了一些挑战,比如如何发现节点、查找节点?
在P2P网络中,常用的方法是每个节点维护一个部分路由表,即只包含部分节点的路由信息。在泛洪算法中,这些节点上随机的;在DHT算法中,这个路由表是有结构的,维护的节点也是有选择性的。那么如何合理的选择需要维护路由信息的节点呢?
一个朴素的做法是,每一个节点保存比他大的节点的信息,这样可以组成一个环,但是这样做的话,有一个大问题和一个小问题。大问题是,每个节点知道的信息太少(只有下一个节点的哈希和地址),当给出一个key时,它不知道网络中还有没有比它距离这个key距离还短的节点,所以它首先判断key是否属于自己和下一个节点,如果是,那么这个key就属于下一个节点,如果不是就调用下一个节点同样的方法,这个复杂度是N(节点数)。一个优化的方法是,每个节点i维护的其他节点有:i+21, i+22,…i+2**31,通过观察这个数据,发现由近到远,节点越来越稀疏。这样可以把复杂度降低到lgN
每个节点保存的其他节点的信息,包括,从左到右,每一位上与本节点不同的节点,最多选择k个(算法的超参数)。比如在节点00110上(为演示起见,选择5位),在要保存的节点路由信息是:
1****: xxx,…,xxx(k个)
01***: xxx,…,xxx(k个)
000**: xxx,…,xxx(k个)
0010*: xxx,…,xxx(k个)
00111: xxx,…,xxx(k个)
以上为一行称为k-bucket。形象的来看,也是距离自己越近,节点越密集,越远,节点越稀疏。这个路由查找、节点查找的算法也是lgN复杂度。