Hi 游客

更多精彩,请登录!

比特池塘 区块链前沿 正文

P2P 网络的思考

韩氏王子韩hl
73 0 0
P2P网络综述, s& U+ B/ Z4 N
% H5 a2 p$ z! A. O  Q
    P2P网络中每个节点具有完全相同功能,既提供服务又提供客户端访问。这样做的好处是可扩展性非常强。可以随意增加或者减少节点,对整个网络服务不会有很大影响。P2P网络和现在Internet上大部分网络之间最大区别在于,现在大部分网站是C/S(Client/Server)架构,而C/S架构是有一个强依赖。如果中心节点挂掉,Client节点将无法工作。P2P和C/S架构区别就是P2P架构没有一个中心节点,每一个节点其实都是一个小中心,这样网络上只要存在节点,那么整个服务就能继续进行。, H& ~2 M9 i4 J

0 I7 D3 y+ _: V: X. i; `$ N1 b1 j1 N    比特币P2P网络; A7 S4 O# T% ~9 W; A7 q
% O' y  r* g' \4 J
    了解了P2P网络的定义之后,接下来开始讲解比特币P2P网络。按照顺序,我们从比特币节点启动开始,给大家讲解如何同步到最高高度、出块、转发交易。
! Z* t7 d7 H. P/ \; j2 F2 q0 ]( f, N& X) q* p* q6 M
    节点启动% U5 o+ E0 X8 P

- ^4 w5 U( R1 h" K    首先是启动,启动就有一个节点发现的过程。比特币客户端启动时,有四种选择来连接该网络。
! B5 `. {, y3 J6 ]/ y% ~) u( Y3 M- E. k3 u4 `% X- u
    用命令行强指定链接某个节点,那么就会去连接。+ ?+ D* U- W2 Z5 ~
; O# Z$ f1 `" [' l2 ~9 T" g: p
    如果没有命令行指定,就在本地节点查询是否有存储的、连接过的IP地址,如果有就尝试链接。连接不上那么会选择第三步。1 |7 v, L* i7 x- q
  w) K1 W0 x+ y3 h5 J- ^! F
    如果没有命令行指定也连接不上之前连接过的IP地址,那么在比特币每次发版时,在代码里面硬编码了一些DNS的服务器,这些服务器可以理解为我们现在Internet里,网址和IP对应的服务器。这个服务器本身可能是静态或者是动态的,如果节点查到有相应服务器的话,就向相应地址发起连接请求,如果还不能连接上,那么就到最后一步。
( M, I' a6 J3 _/ v  m) b/ c3 O; ?; B2 O- V; ^2 ]. T
    客户端维护了一个活跃节点列表,客户端和他们连接能够获取一些网络的信息。
; k3 Q1 |5 W: j' Z% `2 u, m) l6 O. r) a8 ^* S
    (这个感觉有点像你实在找不到人求救的时候还能打110的固定电话)
% e: y' p' Z: q/ S3 [" Q
- B4 z  f7 M1 i7 ~2 o* G2 ]    这就是比特币网络发现节点的过程,和普通的一些分布式应用节点发现类似,(在版本编码时)都有一个类似注册中心,如果没有直接指定,节点就会向注册中心发起一些查询工作来寻找可以连接的节点。  M3 V/ j% j$ w0 M
; W/ \) u$ d. e1 K9 V& w8 l) \6 p
    查询到可连接IP后
  _  k( v1 Q& Q" s% b( ^
" w  O' K/ w; g, T0 A6 O0 X    那么下一步,本地节点如果已经链接到可用的IP时候,会做什么?# U6 \( N& R. c2 e3 `

% b# p# A8 T5 V8 \; c9 E    首先,比特币知道IP时,将对远端节点发送Version消息,里面会有自己客户端的型号、版本号、类型(轻节点、全节点或者验证节点)。远端节点收到这个消息之后会根据自己的版本号、能够接受的消息来返回消息,如果这个消息验证结果是我能和这个节点通信,那么就会返回一个消息verack,远端节点也会同时向节点发布一个Version确定自己版本和节点类型。请求verack之后本地节点就向远端节点发送它记录的IP节点的list,就把活跃的list存在数据库,方便以后快速启动节点。, B+ H' b: o+ H8 ]6 f8 e3 o' R' |
" W4 J: B3 @9 w6 o! O( M) \
    同步策略* V6 P& j- e  o+ h. Z3 Y

+ o6 }: e' a' O* S# o    在新节点链接上网络时,本地是没有数据的,这时需要向远端节点请求一些历史数据,同步整个链的数据到本地,这里有两个策略。分别是版本0.9.3之前的Blocks-first策略,和0.10之后的Headers-first策略,对比图如下:
0 J( |( x* e+ A% u( f' h; a5 C& Z; ^+ F# B: ^5 ~( `
    实际上交互模式是一样的,首先是hash或者header。hash是每个块的hash,每个块的块头会有一个代表整个块的hash,headers-first则将每个块的headers拿过来。之后是用header或者hash向远端节点请求blocks,然后往复进行。看上去协议都差不多,为什么要这样做?1 i( f) H% k  ]$ `% l) I

/ t3 V8 |9 e8 u$ ~! G+ g7 e0 H    Blocks-first问题
0 }8 e* ^( ]+ C$ N* y0 Z+ z& Q" C# }# b2 \+ I' L4 B/ ~
    Blocks-first唯一优点是实现方便,但它存在下面几个问题:
+ K) r: y! |8 w2 b1 ~
! u. a, G$ ^5 e# W; \9 Q% z9 R    首先,我的节点连接到其他的节点,实际上如果没有断掉就会一直请求数据。那么如果这是一个故意做恶节点呢?它会返回一些不是最大工作量证明的hash,而本地节点是不知道hash里面是什么,只会根据返回的hashlist去请求。最后同步到什么状态呢?Bitcoin每到一定高度会有checkpoint的点,会检查你同步的块是最大工作量证明还是错误的块。如果连接的节点是恶意节点,那么,我的节点只有到checkpoint时,才会发现我同步的几块是错误的,这样导致我本地服务器的磁盘消耗会非常大,一般是几个甚至是几十个G之后发现这些是无效数据。( v: v: w) Y8 q2 A+ \" `
. v+ h+ f& H2 }, K& k1 H
    其次,是速度限制。Blocks-first协议规定,如果这个连接没有中断的话,将一直向同一个节点请求数据。如果远端节点上传和下载数据受到限制,本地节点同步的速度将受到限制。
. u5 ]; t$ a; s/ h' r8 z+ R) J+ C% Y% ?
  G# e4 y0 ^, C. c    最后,是高内存占用。Blocks-first策略请求的是块的hash,一个问题就是协议要求远端节点的hash是完全按照顺序发送的,如果没有按照顺序本地节点就会验证不了,从而导致乱序的块。这样的块如果找不到parentsblock,比特币就会把这些块定义为是孤儿块,会把它们临时存放在一个内存里面,直到请求到完整的parentsblock之后才会把parentsblock和孤儿块入库。这时候如果远端节点做恶的话,先给很多高度很高的块,前面的都不给(也就是没有parentsblocks),每个块需要几k,几十万个块就能把你的内存撑爆。3 f1 C2 S" U: C/ ^8 X
4 y9 ]5 b1 k. S: {1 u$ D4 a* m
    Headers-first策略
/ p6 d, @8 S/ t6 D# P7 H0 J: ?( W6 ^8 J  y
    Headers-first的策略闪亮登场。这个策略会把整个链的headers全部下载下来,headers里面包括所有block的hash以及parents的hash,可以用headers串起一条链。虽然不知道交易是什么,但是能够从headers里面确定链是连续的,不连续会扔掉孤儿块。并且根据官方验证,一个新的节点同步整个链的话,只需要30m的存储能够把整个链全部同步下来,磁盘消耗非常小。
+ j0 i% f' }7 g3 f+ n3 q7 _$ ]# L3 X7 K, e4 ?
    那么速度限制怎么解决?headers一次请求是2000个块的步长。如果请求验证没问题的话,就会把haederhash16个一组发送给所有能够连接到的节点,来验证是不是对的,然后把对应的header的block给他,这样同步的时候不会被某个节点的网络限制,可以获取一批blocks向四周发送同步请求。# b. b, m' W. N' R* T6 @

, U; u# Y( \7 @* }# f! j& u' b    这就是比特币的同步策略。相比于blocks-first策略,headers-first策略解决了1、速度限制;2、无效下载;3、高内存占用三个问题。
" P' }' D( m/ n" h. |3 s9 ]- z( C' `' w
    新块广播
8 @! c% T6 Q4 e
, X; k3 Q  A8 H' W- `5 s  g    接下来,同步到最高高度的时候,如果是挖矿节点就会涉及到挖矿广播的问题。我发现了下一个块的hash,我就会把块广播给我链接到的所有节点来获取奖励,这时候广播会有三种模式:' ]  Q1 t& e) l  o& M

# @/ l! B* p$ p7 P    1、推送式。这一种用的比较少。只要能连接上对方节点,那就把整个块推送过去,不管对方接不接受。2 }6 L4 I8 \/ b

7 w5 G. i! m# B' X8 o    2、标准转发模式,发现新块时,将新块的hash做一个消息推给周围所有人,如果对方返回消息说他需要hash具体数据,那么就将整个块给他,有一个通知→回复→再回复的过程。( g9 H! ^* n" Y* V$ J0 [1 Y6 H3 ^. r
' s! v: J$ q+ w1 |3 u& B  o- P
    3、0.10.0之后,出现了块头公告的模式。只要是headers-first策略的节点,启动时,会做一件事情告诉连接所有节点,我不要标准转发的模式,我需要的是发现新块时,直接把header给我。这样就能够省去一个「我给列表→你请求列表数据→然后再把数据给我」的整个过程。直接把header给他,然后他就可以向任何人请求headers对应的data。6 o  ^# f2 p4 l& x  t' T) j

2 G% H# n6 A9 n. j6 }* J. b1 q    这就是新块广播的过程。
8 d9 J: M) d$ `4 o1 E( a& G' P! [
    节点交易转发过程% _7 @9 A4 R; ?& [" i& \
. G  @- E8 t2 v/ n
    交易发送到任意能够接受的节点的时候,交易会存在当前节点的内存池里面,然后节点收到交易时,会做一个hash列表,发送给能够连接到的所有人。一个节点最多能够连接8个节点,如果别的节点发现内存池里面没有这个交易,那就返回getdata。那么对方收到的时候会把整个交易的内容转发过去。" S% D: {' U% v4 Y# |0 r

  o& q$ M  f) k    这里有一个问题,就是不要相信每个交易都会上链,因为交易是存在内存池里面的,并不上链。如果一个节点没有把交易发送出去就下线了,那么这笔交易就会丢失,这是很正常的一件事情。
' M9 q1 z2 k8 K. ^+ i& v0 H' Z5 A+ L+ K* F( _* x
    这就是交易的转发过程。4 [- s4 V8 l, s2 _- o" T" R
$ N9 G/ o5 C0 o+ f* \5 y
    到这里比特币的网络协议基本就是这样节点启动、同步、最高高度之后能够转发交易,能够运作。
* A, u# ?$ K( N1 o) i$ o8 J/ t7 g, ]9 }8 y
    公有许可链CITA& u. A  N6 ^; _1 ~, T

. V) {" j1 F6 _    比特币是区块链的鼻祖,但在性能上存在一个问题,10分钟一个块,6个块之后才能确认交易是放在主链上的。之后为了能够有更高的性能就出现了联盟链。CITA项目初创的时候是联盟链,我们讲一下当前状态的CITA联盟链是什么样的。
" D) T5 s# @: q/ v# G' ~
1 a* E; j# J* u; w/ F3 b5 w/ @    CITA网络综述7 b: J, y9 ]5 ]; D& K* s  |: H

$ N4 U' b2 P$ ~. r9 w    CITA的网络,和比特币不一样的地方就是CITA是N个进程结合在一起作为整个逻辑节点的。比特币是一个进程,CITA是微服务架构,所以有七个进程。CITA对外有节点间通信,对内还有每个服务之间的通信,所以会分为节点间的通信和节点内的通信。因为CITA刚开始时,作为联盟链,节点数在链的初始状态就确定了,也不会很多,所以在一开始就使用TCP全连接。; [: @+ r) N: `3 n$ |, n3 T. ]3 ?; [

. W. `! q& }7 \/ v/ i7 ?! n6 p8 C    这么做的好处是什么?即我的消息,只要是知道的,只需转发就点对点转发给我所知的所有节点,消息到达速度非常快。比特币消息转发给全世界需要时间,CITA作为联盟链的时候,每个节点之间都是有连接的,如果一个消息要广播给整个网络,只要他保留TCP所有连接,就能够一次性转发出去。节点之间的通信协议并没有比特币那么复杂,并没有Version、transaction、getdata等,而是最简单的协议,只有开始符、长度和数据。3 L1 Y* G( u/ z: [/ J/ m1 T
4 k$ k8 S& C+ I3 Z' W) q4 ]  O
    节点间同步
/ t0 ]- x& O1 I/ l! p  p. i- E8 e! |/ {; W* G" s  i- h! p& M) n  ^
    目前,CITA共识算法是PBFT,是确定性的、一定不会分叉的共识算法,做恶节点小于三分之一时即可保证不会分叉。所以CITA的同步不需要分叉判断,只需要判断块高。如果我这个节点发现我连接的整个网络块高比我高三个块左右时,就会随机选择一个节点,大概20个块一组去同步。同步的消息是整个块发过来的,而不是像比特币那样先发送一个列表、header之后再把整个块发过来。
1 X$ Y( u( h0 a2 U$ J6 K: R) Z# z5 H: H( Y3 s" q5 V
    交易转发
% t6 }5 A7 N; Q9 S
2 P. u) m9 Y. w8 Y3 }1 q4 d4 Q    关于交易的转发,因为CITA是全连接的,只要接到交易,验证通过之后,交易就会加入本地交易池,之后转发给所有能连接的节点,除了来源之外(转发交易给我的)所有节点都发一遍,在确保每个交易正常和网络正常的情况下,是不会拉下任何一个节点的。
* k, w* f8 t* U- W" c1 \
7 [. h) L$ I8 }, I3 g: U    共识提出" Z, u% l6 }( f" r& F* D/ E

' N. r+ ^4 R# D9 {4 m: v7 }% ?! b    在CITA中,共识的proposal提出的话,也是以广播的方式去发送的。CITA里面节点是分为共识节点和只读节点。共识节点有权发起投票,只读节点只能进行同步和交易的转发。虽然只读节点不能发起投票但是也能够收到proposal的消息,然后节点会判断自己能不能投票,如果不能投票就会放弃这个交易。这个是CITA节点之间的通信。对比特币来说,CITA节点通信简单了很多,因为网络环境比较简单,毕竟比特币是公网。
1 q- A9 u6 ?+ V/ Y+ @: H4 J, h, u& I! N3 b
    节点内部通讯
2 ~+ U$ F* v9 ~1 U$ z3 j: u; s. S1 P
    CITA节点内部的通信,每个微服务的通信都是异步的模式,即我(节点)发出消息之后,不管对方是否回复都先做自己的事情。这里有一个问题就是,如果我这个节点的消息你没有收到,另外一个微服务突然挂了,状态不一致的情况下,就有一个状态同步的问题。现阶段CITA分为共识进程,执行器进程,数据库进程以及网络进程,这些都是有状态的,以数据库为准。如果数据库说这个节点有100的高度,那么整个逻辑节点所有状态都是100的高度。如果不是,就是坏掉了。所以现在最复杂的问题是节点内部每个服务状态同步的问题,如果不一致会让整个节点出现异常。比如:出现对外表现不一致,或者因为状态不一样所以不能发器投票。因此节点内通信最重要的是状态的同步问题,如果我应该接收到的没有收到,就会发起一个request-response来确认状态,如果状态和数据库不一致的话,将调整状态。
+ C) g2 ?5 V: W& @4 c: e3 N) P$ p% l+ I4 j3 i( Z) D* Z; k
    未来可能性% \# @! d3 s$ Q: p2 e

7 a' H3 W, j5 q    如果CITA变成公网,我们会遇到的一个问题是网络连接质量下降,如何既保持开放又能为共识提供足够的网络速度?节点间的直连也许依然会是需要的一种方式,同时补充gossip网络协议,即在我发送消息时知道的所有节点中,随机找两个节点发出去,别人收到时也会随机选两个节点转发出去,全网最终能够达到一致的状态的,我的消息都能够传遍全网。这样能够大大降低服务器的网络开销。共识节点可以用直连的方式来保证出块和交易速度。
BitMere.com 比特池塘系信息发布平台,比特池塘仅提供信息存储空间服务。
声明:该文观点仅代表作者本人,本文不代表比特池塘立场,且不构成建议,请谨慎对待。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

成为第一个吐槽的人

韩氏王子韩hl 小学生
  • 粉丝

    0

  • 关注

    0

  • 主题

    6