以太坊源码分析—p2p节点发现与协议运行

187J3X1 · · 1114 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

前言

p2p(peer to peer)负责以太坊底层节点间的通信,主要包括底层节点发现(discover)和上层协议运行两大部分。

节点发现

节点发现功能主要涉及 Server Table udp 这几个数据结构,它们有独自的事件响应循环,节点发现功能便是它们互相协作完成的。其中,每个以太坊客户端启动后都会在本地运行一个Server,并将网络拓扑中相邻的节点视为Node,而TableNode的容器,udp则是负责维持底层的连接。这些结构的关系如下图
Server Table udp

Server

p2p/server.go
type Server struct {
    PrivateKey  *ecdsa.PrivateKey
    Protocols    []protocol
    StaticNodes[]  *discover.Node
    newTransport  func(net.Conn)  transport  
    ntab    disvocerTable    
    ourHandshake    *protoHandshake    

    addpeer    chan *conn
    ......
}

PrivateKey - 本节点的私钥,用于与其他节点建立时的握手协商
Protocols - 支持的所有上层协议
StaticNodes - 预设的静态Peer,节点启动时会首先去向它们发起连接,建立邻居关系
newTransport - 下层传输层实现,定义握手过程中的数据加密解密方式,默认的传输层实现是用newRLPX()创建的rlpx,这不是本文的重点
ntab - 典型实现是Table,所有peerNode的形式存放在Table
ourHandshake - 与其他节点建立连接时的握手信息,包含本地节点的版本号以及支持的上层协议
addpeer - 连接握手完成后,连接过程通过这个通道通知Server

Server.listenLoop()

Server的监听循环,启动底层监听socket,当收到连接请求时,Accept后调用setupConn()开始连接建立过程

Server.run()

Server的主要事件处理和功能实现循环

  • 进行主动的节点发现,详见之后的节点发现部分
  • posthandshake channel 接收已经完成第一阶段的连接,这些连接的身份已经被确认,但还需要验证
  • addpeer channel 接收已经完成第二阶段的连接,这些连接已经验证,调用runPeer()运行本节点与Peer连接上的协议

Node

Node唯一表示网络上的一个节点

p2p/discover/node.go
type Node struct {
    IP net.IP
    UDP, TCP uint16
    ID      NodeID
    sha    common.Hash
}

IP - IP地址
UDP/TCP - 连接使用的UDP/TCP端口号
ID - 以太坊网络中唯一标识一个节点,本质上是一个椭圆曲线公钥(PublicKey),与ServerPrivateKey对应。一个节点的IP地址不一定是固定的,但ID是唯一的。
sha - 用于节点间的距离计算


Table

Table主要用来管理与本节点与其他节点的连接的建立更新删除

p2p/discover/table.go
type Table struct {
    bucket   [nBuckets]* bucket
    refreshReq    chan chan struct{}
    ......
}

bucket - 所有peer按与本节点的距离远近放在不同的桶(bucket)中,详见之后的节点维护
refreshReq - 更新Table请求通道

Table.loop()

Table的主要事件循环,主要负责控制refreshrevalidate过程。
refresh.C - 定时(30s)启动Peer刷新过程的定时器
refreshReq - 接收其他线程投递到Table刷新Peer连接的通知,当收到该通知时启动更新,详见之后的更新邻居关系
revalidate.C - 定时重新检查以连接节点的有效性的定时器,详见之后的探活检测

udp

udp负责节点间通信的底层消息控制,是Table运行的Kademlia协议的底层组件

type udp struct {
    conn  conn
    addpending chan *pending
    gotreply  chan reply
    *Table
}

conn - 底层监听端口的连接
addpendingudp用来接收pending的channel。使用场景为:当我们向其他节点发送数据包后(packet)后可能会期待收到它的回复,pending用来记录一次这种还没有到来的回复。举个例子,当我们发送ping包时,总是期待对方回复pong包。这时就可以将构造一个pending结构,其中包含期待接收的pong包的信息以及对应的callback函数,将这个pengding投递到udp的这个channel。udp在收到匹配的pong后,执行预设的callback。
gotreply - udp用来接收其他节点回复的通道,配合上面的addpending,收到回复后,遍历已有的pending链表,看是否有匹配的pending。
Table - 和Server中的ntab是同一个Table

udp.loop()

udp的处理循环,负责控制消息的向上递交和收发控制

  • addpending 接收其他线程投递来的pending需求
  • gotreply 接收udp.readLoop()投递过来的pending的回复
udp.readLoop()

udp的底层接受数据包循环,负责接收其他节点的packet

  • 接受其他节点发送的packet并解析,如果是回复包则投递到udp.loop()

节点维护

以太坊使用Kademlia分布式路由存储协议来进行网络拓扑维护,了解该协议建议先阅读易懂分布式。更权威的资料可以查看wiki。总的来说该协议:

  • 使用UDP进行节点间消息通信,有 4 种消息

    • ping - 用于探测其他节点是否还存在
    • store - 接收者受到后,将信息中key/value对存储在本节点
    • findnode - 接受者向发送者返回 k 个它知道的与目标结点距离最近的节点
    • findvalue - 和findnode 差不多,区别是如果接收者本地存在与目标结点对应的value,那么就回复这个值给发送者。
  • 每个节点根据与邻居节点距离之间的距离(NodeID的差距),分别放到不同的桶(bucket)中。
本文说的距离,均是指两个节点NodeID的距离,计算方式可见p2p/discover/node.gologdist()方法

源码中由Table结构保存所有bucketbucket结构如下

p2p/discover/table.go
type bucket struct {
    entries  []*Node
    replacemenets   []*Node
    ips  netutil.DistinctNetSet
}
  • entries 数组中保存经过bond的节点,并且其顺序是越新bond通过了探活检测(Revalidate)的节点位置越靠前。
  • replacemenets数组中保存候补节点,如果entries 数组数量满了,之后的节点会被加入该数组

节点可以在entriesreplacements互相转化,一个entries节点如果Validate失败,那么它会被原本将一个原本在replacements数组的节点替换。

探活检测(Revalidate)

有效性检测就是利用ping消息进行探活操作。Table.loop()启动了一个定时器(0~10s),定期随机选择一个bucket,向其entries中末尾的节点发送ping消息,如果对方回应了pong,则探活成功。

举个栗子,假设某个bucket, entries最多保存2个节点,replacements最多保存4个节点。初始情况下entries=[A, B], replacements = [C, D, E],如果此时节点F加入网络,bond通过,由于entries已满,只能加入到replacements = [C, D, E, F]。 此时Revalidate定时器到期,则会对 B进行检测,如果通过,则entries=[B, A],如果不通过,则将随机选择replacements中的一项(假设为D)替换B的位置,最终entries=[A, D],replacements = [C, E, F]

更新邻居关系

Table.loop()会定期(定时器超时)或不定期(收到refreshReq)地进行更新邻居关系(发现新邻居),两者都调用doRefresh()方法,该方法对在网络上查找离自身和三个随机节点最近的若干个节点。

节点查找

Tablelookup()方法用来实现节点查找目标节点,它的实现就是Kademlia协议,通过节点间的接力,一步一步接近目标。

邻居初始化

当一个节点启动后,它会首先向配置的静态节点发起连接,发起连接的过程称为Dial,源码中通过创建dialTask跟踪这个过程

dialTask

dialTask表示一次向其他节点主动发起连接的任务

p2p/dial.go
type dialTask struct {
    flags    connFlag
    dest    *discover.Node
    ......
}

Server启动时,会调用newDialState()根据预配置的StaticNodes初始化一批dialTask, 并在Server.run()方法中,启动这些这些任务。

dialtask

Dial过程需要知道目标节点(dest)的IP地址,如果不知道的话,就要先使用 recolve()解析出目标的IP地址,怎么解析?就是先要用借助Kademlia协议在网络中查找目标节点。

resolve
当得到目标节点的IP后,下一步便是建立连接,这是通过dialTask.dial()建立连接

连接建立

连接建立的握手过程分为两个阶段,在在SetupConn()中实现
第一阶段为ECDH密钥建立

sequenceDiagram
Note left of Dialer: Calc token
Note left of Dialer: Generate Random Prikey\Nonce
Note left of Dialer: Sign
Dialer->>Receiver: AuthMsg
Note right of Receiver: Calc token
Note right of Receiver: Check Signature
Note right of Receiver: Generate Random Prikey\Nonce
Receiver->>Dialer: AuthResp

第二阶段为协议握手,互相交换支持的上层协议

sequenceDiagram
Dialer->>Receiver: protoHandshake
Receiver->>Dialer: protoHandshake

如果两次握手都通过,dialTask将向Serveraddpeer通道发送peer的信息

sequenceDiagram
participant Server.run()
participant dialTask
participant Remote Node
dialTask->>Remote Node:EncHandshake
Remote Node->>dialTask:EncHandshake
dialTask->>Server.run(): posthandshake
dialTask->>Remote Node:ProtoHandshake
Remote Node->>dialTask:ProtoHandshake
dialTask->>Server.run(): addpeer
Note over Server.run(): go runPeer()

协议运行

协议运行并不单单指某个特定的协议,准确地说应该是若干个独立的协议同时在两个节点间运行。在p2p节点发现提到过,节点间建立连接的时候会经过两次握手,其中的第二次握手,节点间会交换自身所支持的协议。最终两个节点间生效的协议为两个节点支持的协议的交集

功能主要涉及 Peer protoRW 这几个数据结构,其关系如图
Peer proto

Peer

  • rw - 节点间连接的底层信息,比如使用的socket以及对端节点支持的协议(capabilities)
  • running - 节点间生效运行的协议簇

Peer.run()负责连接建立后启动运行上层协议,它自身运行在一个独立的go routine,具有自己的事件处理循环,除此之外,它还会额外创建2+ngo routine, 其中2包括一个用于保活的pingLoop() go routine和一个用于接收协议数据的readLoop() go routine ,而 n 为运行于其上的n个协议的go routine,即每个协议调用自己的Run()方法运行在自己单独的go routine
run

protoRW

Run 每种协议自身的运行入口,以新的go routine形式启动.

总结

  • p2p主要由底层节点发现和上层协议运行两部分组成,节点发现负责管理以太坊网络中各个节点间的连接建立,更新和删除,Server是p2p功能的入口,Table负责记录peer节点信息, udp负责底层通信。而在底层的基础上,节点间可以运行多个独立的协议。
  • 以太坊使用Kademlia分布式路由存储协议来进行网络拓扑维护,将不同距离的peer节点放在不同的bucket中。

有疑问加站长微信联系(非本文作者)

本文来自:Segmentfault

感谢作者:187J3X1

查看原文:以太坊源码分析—p2p节点发现与协议运行

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1114 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传