https://book.8btc.com/books/6/masterbitcoin2cn/_book/ch02.html

比特币P2P协议

一个全节点连接到对等节点之后,第一件要做的事情就是构建完整的区块链。如果该节点是一个全新节点,那么它就不包含任何区块链信息,它只知道一个区块——静态植入在客户端软件中的创世区块。新节点需要下载从0号区块(创世区块)开始的数十万区块的全部内容,才能跟网络同步、并重建全区块链。

一个全节点连接到对等节点之后,第一件要做的事情就是构建完整的区块链。如果该节点是一个全新节点,那么它就不包含任何区块链信息,它只知道一个区块——静态植入在客户端软件中的创世区块。新节点需要下载从0号区块(创世区块)开始的数十万区块的全部内容,才能跟网络同步、并重建全区块链。

同步区块链的过程从发送version消息开始,这是因为该消息中含有的BestHeight字段标示了一个节点当前的区块链高度(区块数量)。节点可以从它的对等节点中得到版本消息,了解双方各自有多少区块,从而可以与其自身区块链所拥 有的区块数量进行比较。对等节点们会交换一个getblocks消息,其中包含他们本地区块链的顶端区块哈希值(指纹)。如果某个对等节点识别出它接收到的哈希值并不属于顶端区块,而是属于一个非顶端区块的旧区块,那么它就能推断出:其自身的本地区块链比其他对等节点的区块链更长。

拥有更长区块链的对等节点比其他节点有更多的区块,可以识别出哪些区块们是其他节点需要“补充”的。它会识别出第 一批可供分享的500个区块,通过使用inv(inventory)消息把这些区块的哈希值传播出去。缺少这些区块的节点便可以 通过各自发送的getdata消息来请求得到全区块信息,用包含在inv消息中的哈希值来确认是否为正确的被请求的区块, 从而读取这些缺失的区块。

在下例中,我们假设某节点只含有创世区块。它收到了来自对等节点的inv消息,其中包含了区块链中后500个区块的哈希值。于是它开始向所有与之相连的对等节点请求区块,并通过分摊工作量的方式防止单一对等节点被批量请求所压垮。该节点会追踪记录其每个对等节点连接上“正在传输”(指那些它已经发出了请求但还没有接收到)的区块数量,并且检查该数量有没有超过上限( MAX_BLOCKS_IN_TRANSIT_PER_PEER )。用这种办法,如果一个节点需要更新大量区块,它会在上一请求完成后才发送对新区块的请求,从而允许对等节点控制更新速度,不至于压垮网络。每一个区块在被接收后就会被添加至区块链中,这一过程详见挖矿一章。随着本地区块链的逐步建立,越来越多的区块被请求和接收,整个过程将一直持续到该节点与全网络完成同步为止。

每当一个节点离线,不管离线时间有多长,这个与对等节点比较本地区块链并恢复缺失区块的过程就会被触发。如果一 个节点只离线几分钟,可能只会缺失几个区块;当它离线长达一个月,可能会缺失上千个区块。但无论哪种情况,它都 会从发送 getblocks 消息开始,收到一个inv响应,接着开始下载缺失的区块

新节点寻找等体

新节点如何找到对等体? 第一种方法是使用多个“DNS种子”来查询DNS,这些DNS服务器提供比特币节点的IP地址列表。 其中一些DNS种子提供了稳定的比特币侦听节点的静态IP地址列表。 一些DNS种子是BIND(Berkeley Internet Name Daemon)的自定义实现,它从搜索器或长时间运行的比特币节点收集的比特币节点地址列表中返回一个随机子集。 Bitcoin Core客户端包含五种不同DNS种子的名称。

不同DNS种子的所有权和多样性的多样性为初始引导过程提供了高水平的可靠性。 在Bitcoin Core客户端中,使用DNS种子的选项由选项switch -dnsseed控制(默认设置为1,以使用DNS种子)。

或者,不知道网络的引导节点必须被给予至少一个比特币节点的IP地址,之后可以通过进一步介绍来建立连接。 命令行参数-seednode可用于连接到一个节点,仅用于将其用作种子。 在使用初始种子节点形成介绍后,客户端将断开连接并使用新发现的对等体。

当建立一个或多个连接后,新节点将一条包含自身IP地址的addr消息发送给其相邻节点。相邻节点再将此条addr消息依 次转发给它们各自的相邻节点,从而保证新节点信息被多个节点所接收、保证连接更稳定。另外,新接入的节点可以向 它的相邻节点发送getaddr消息,要求它们返回其已知对等节点的IP地址列表。通过这种方式,节点可以找到需连接到 的对等节点,并向网络发布它的消息以便其他节点查找。图8-5描述了这种地址发现协议。

节点必须连接到若干不同的对等节点才能在比特币网络中建立通向比特币网络的种类各异的路径(path)。由于节点可以随时加入和离开,通讯路径是不可靠的。因此,节点必须持续进行两项工作:在失去已有连接时发现新节点,并在其他节点启动时为其提供帮助。节点启动时只需要一个连接,因为第一个节点可以将它引荐给它的对等节点,而这些节点又会进一步提供引荐。一个节点,如果连接到大量的其他对等节点,这既没必要,也是对网络资源的浪费。在启动完成 后,节点会记住它最近成功连接的对等节点;因此,当重新启动后它可以迅速与先前的对等节点网络重新建立连接。如果先前的网络的对等节点对连接请求无应答,该节点可以使用种子节点进行重启动

P2P网络

泛洪算法

交易从某个节点产生,接着广播到临近节点,临近节点一传十十传百,直至传播到全网。

这个条件是非常苛刻的,那么到底有没有一种方案可以自行建立映射呢?答案是:有,就是 NAT 技术和 UPnP 协议。

比特币和以太坊均使用了 UPnP 协议作为局域网穿透工具,只要局域网中的路由设备支持 NAT 网关功能、支持 UPnP 协议,即可将你的区块链节点自动映射到公网上。

工作量证明

给定一个初始字符,然后拼接整数,再进行hash当拼接字符hash得到00000xx时,表示成功,此时返回 得到的hash值,与拼接字符进行工作证明。

生成Coinbase交易,并与其他所有准备打包进区块的交易组成交易列表,通过Merkle Tree算法生成Merkle Root Hash 把Merkle Root Hash及其他相关字段组装成区块头,将区块头的80字节数据(Block Header)作为工作量证明的输入 不停的变更区块头中的随机数即nonce的数值,并对每次变更后的的区块头做双重SHA256运算(即SHA256(SHA256(Block_Header))),将结果值与当前网络的目标值做对比,如果小于目标值,则解题成功,工作量证明完成。

在比特币中,在单个区块中有成百上千的交易是非常普遍的,这些交易都会采用同样的方法归纳起来,产生一个仅仅32字节的数据作为Merkle根。

为了证明区块中存在某个特定的交易,一个节点只需要计算log~2~(N)个32字节的哈希值,形成一条从特定交易到树根的认证路径或者Merkle路径即可。随着交易数量的急剧增加,这样的计算量就显得异常重要,因为相对于交易数量的增长,以基底为2的交易数量的对数的增长会缓慢许多。这使得比特币节点能够高效地产生一条10或者12个哈希值(320~384字节)的路径,来证明了在一个巨量字节大小的区块中上千交易中的某笔交易的存在。

https://book.8btc.com/books/6/masterbitcoin2cn/_book/ch09.html

简单支付验证(SPV)节点

这种不需要维护一条完整的区块链的节点,又被称作简单支付验证(SPV)节点,它不需要下载整个区块而通过Merkle路径去验证交易的存在。

某几个节点验证了你的交易合法,然后广播到整个比特币节点网中,这种广播是不断验证再次广播的过程。直到这笔交易 A 被网络中大多数节点接收。

P2P技术原理:http://www.360doc.com/content/14/0305/17/8285430_357987074.shtml

P2P技术现状及发展未来:http://www.zte.com.cn/cndata/magazine/zte_communications/2007/6/magazine/200712

P2P原理及其常用的实现方式:http://www.cppblog.com/peakflys/archive/2013/01/25/197562.html

P2P对等网络技术原理整合:

https://blog.csdn.net/EricFantastic/article/details/49582731

p2p通信原理及实现:

https://blog.csdn.net/yunlianglinfeng/article/details/54018113

https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API

https://blog.csdn.net/erlib/article/details/79953019

golang实现p2p之UDP打洞 https://blog.csdn.net/qq_31967569/article/details/82704340

比特币的数据是通过levelDB存储的

搭建基于hyperledger fabric的联盟社区(一) --前言 https://www.cnblogs.com/preminem/p/7686829.html

Hyperledger Fabric实践:供应链金融案例 https://blog.csdn.net/oXiaoBuDing/article/details/84655511?utm_source=blogre

HyperLedger Fabric 多机部署(一) https://www.cnblogs.com/gzhlt/p/9599616.html

区块链开源实现hyperledger fabric架构详解 https://blog.csdn.net/russell_tao/article/details/80459698

http://cw.hubwiz.com/card/c