死磕以太坊源码分析之Fetcher同步

Fetcher 功能概述

区块数据同步分为被动同步和主动同步:

  • 被动同步是指本地节点收到其他节点的一些广播的消息,然后请求区块信息。

  • 主动同步是指节点主动向其他节点请求区块数据,比如geth刚启动时的syning,以及运行时定时和相邻节点同步

Fetcher负责被动同步,主要做以下事情:

  • 收到完整的block广播消息(NewBlockMsg)
  • 收到blockhash广播消息(NewBlockHashesMsg)

这两个消息又是分别由 peer.AsyncSendNewBlockHashpeer.AsyncSendNewBlock 两个方法发出的,这两个方法只有在矿工挖到新的区块时才会被调用:

// 订阅本地挖到新的区块的消息
func (pm *ProtocolManager) minedBroadcastLoop() {
for obj := range pm.minedBlockSub.Chan() {
if ev, ok := obj.Data.(core.NewMinedBlockEvent); ok {
pm.BroadcastBlock(ev.Block, true) // First propagate block to peers
pm.BroadcastBlock(ev.Block, false) // Only then announce to the rest
}
}
}
func (pm *ProtocolManager) BroadcastBlock(block *types.Block, propagate bool) {
......
if propagate {
......
for _, peer := range transfer {
peer.AsyncSendNewBlock(block, td) //发送区块数据
}
}
if pm.blockchain.HasBlock(hash, block.NumberU64()) {
for _, peer := range peers {
peer.AsyncSendNewBlockHash(block) //发送区块哈希
}
}
}

所以,当某个矿工产生了新的区块、并将这个新区块广播给其它节点,而其它远程节点收到广播的消息时,才会用到 fetcher 模块去同步这些区块。


fetcher的状态字段

Fetcher 内部对区块进行同步时,会被分成如下几个阶段,并且每个阶段都有一个状态字段与之对应,用来记录这个阶段的数据:

  • Fetcher.announced:此阶段代表节点宣称产生了新的区块(这个新产生的区块不一定是自己产生的,也可能是同步了其它节点新产生的区块),Fetcher 对象将相关信息放到 Fetcher.announced 中,等待下载。
  • Fetcher.fetching:此阶段代表之前「announced」的区块正在被下载。
  • Fetcher.fetched:代表区块的 header 已下载成功,现在等待下载 body
  • Fetcher.completing:代表 body 已经发起了下载,正在等待 body 下载成功。
  • Fetcher.queued:代表 body 已经下载成功。因此一个区块的数据:header 和 body 都已下载完成,此区块正在等待写入本地数据库。

Fetcher 同步区块哈希

而新产生区块时,会使用消息 NewBlockHashesMsgNewBlockMsg 对其进行传播。因此 Fetcher 对象也是从这两个消息处发现新的区块信息的。先来看同步区块哈希的过程。

case msg.Code == NewBlockHashesMsg:
var announces newBlockHashesData
if err := msg.Decode(&announces); err != nil {
return errResp(ErrDecode, "%v: %v", msg, err)
}
// Mark the hashes as present at the remote node
// 将hash 标记存在于远程节点上
for _, block := range announces {
p.MarkBlock(block.Hash)
}
// Schedule all the unknown hashes for retrieval 检索所有未知哈希
unknown := make(newBlockHashesData, 0, len(announces))
for _, block := range announces {
if !pm.blockchain.HasBlock(block.Hash, block.Number) {
unknown = append(unknown, block) // 本地不存在的话就扔到unkonwn里面
}
}
for _, block := range unknown {
pm.fetcher.Notify(p.id, block.Hash, block.Number, time.Now(), p.RequestOneHeader, p.RequestBodies)
}

先将接收的哈希标记在远程节点上,然后去本地检索是否有这个哈希,如果本地数据库不存在的话,就放到unknown里面,然后通知本地的fetcher模块再去远程节点上请求此区块的headerbody。 接下来进入到fetcher.Notify方法中。

func (f *Fetcher) Notify(peer string, hash common.Hash, number uint64, time time.Time,
headerFetcher headerRequesterFn, bodyFetcher bodyRequesterFn) error {
block := &announce{
hash: hash,
number: number,
time: time,
origin: peer,
fetchHeader: headerFetcher,
fetchBodies: bodyFetcher,
}
select {
case f.notify <- block:
return nil
case <-f.quit:
return errTerminated
}

它构造了一个 announce 结构,并将其发送给了 Fetcher.notify 这个 channel。注意 announce 这个结构里带着下载 header 和 body 的方法: fetchHeaderfetchBodies 。这两个方法在下面的过程中会讲到。 接下来我们进入到fetcher.go的loop函数中,找到notify,分以下几个内容:

①:校验防止Dos攻击(限制为256个)

count := f.announces[notification.origin] + 1
if count > hashLimit {
log.Debug("Peer exceeded outstanding announces", "peer", notification.origin, "limit", hashLimit)
propAnnounceDOSMeter.Mark(1)
break
}

②:新来的块号必须满足 $chainHeight - blockno < 7$ 或者 $blockno - chainHeight < 32$

if notification.number > 0 {
if dist := int64(notification.number) - int64(f.chainHeight()); dist < -maxUncleDist || dist > maxQueueDist {
... }
}

③:准备下载headerfetching中存在此哈希则跳过

if _, ok := f.fetching[notification.hash]; ok {
break
}

④:准备下载bodycompleting中存在此哈希也跳过

if _, ok := f.completing[notification.hash]; ok {
break
}

⑤:当确定fetchingcompleting不存在此区块哈希时,则把此区块哈希放入到announced中,准备拉取headerbody

f.announced[notification.hash] = append(f.announced[notification.hash], notification)

⑥:如果 Fetcher.announced 中只有刚才新加入的这一个区块哈希,那么调用 Fetcher.rescheduleFetch 重新设置变量 fetchTimer 的周期

if len(f.announced) == 1 {
f.rescheduleFetch(fetchTimer)
}

拉取header

接下来就是到fetchTimer.C函数中:进行拉取header的操作了,具体步骤如下:

①:选择要下载的区块,从 announced 转移到 fetching

for hash, announces := range f.announced {
if time.Since(announces[0].time) > arriveTimeout-gatherSlack {
// 随机挑一个进行fetching
announce := announces[rand.Intn(len(announces))]
f.forgetHash(hash) // If the block still didn't arrive, queue for fetching
if f.getBlock(hash) == nil {
request[announce.origin] = append(request[announce.origin], hash)
f.fetching[hash] = announce //
}
}
}

②:发送下载 header 的请求

//发送所有的header请求
for peer, hashes := range request {
log.Trace("Fetching scheduled headers", "peer", peer, "list", hashes)
fetchHeader, hashes := f.fetching[hashes[0]].fetchHeader, hashes
go func() {
if f.fetchingHook != nil {
f.fetchingHook(hashes)
}
for _, hash := range hashes {
headerFetchMeter.Mark(1)
fetchHeader(hash)
}
}()
}

现在我们再回到f.notify函数中,找到p.RequestOneHeader,发送GetBlockHeadersMsg给远程节点,然后远程节点再通过case msg.Code == GetBlockHeadersMsg进行处理,本地区块链会返回headers,然后再发送回去。

origin = pm.blockchain.GetHeaderByHash(query.Origin.Hash)
...
p.SendBlockHeaders(headers)

这时候我们请求的headers被远程节点给发送回来了,又是通过新的消息BlockHeadersMsg来传递的,当请求的 header 到来时,会通过两种方式来过滤header :

  1. Fetcher.FilterHeaders 通知 Fetcher 对象
case msg.Code == BlockHeadersMsg:
....
filter := len(headers) == 1
if filter {
headers = pm.fetcher.FilterHeaders(p.id, headers, time.Now())
}

2.downloader.DeliverHeaders 通知downloader对象

if len(headers) > 0 || !filter {
err := pm.downloader.DeliverHeaders(p.id, headers)
...
}

downloader相关的放在接下的文章探讨。继续看FilterHeaders:

filter := make(chan *headerFilterTask)
select {
case f.headerFilter <- filter: ①
....
select {
case filter <- &headerFilterTask{peer: peer, headers: headers, time: time}: ②
...
select {
case task := <-filter: ③
return task.headers
...
}

主要分为3个步骤:

  1. 先发一个通信用的 channelheaderFilter
  2. 将要过滤的 headerFilterTask 发送给 filter
  3. 检索过滤后剩余的标题

主要的处理步骤还是在loop函数中的filter := <-f.headerFilter,在探讨处理前,先了解三个参数的含义:

  • unknown:未知的header
  • incomplete:header拉取完成,但是body还没有拉取
  • complete:headerbody都拉取完成,一个完整的块,可导入到数据库

接下来正式进入到for _, header := range task.headers {}循环中: 这是第一段重要的循环

①:判断是否是在fetching中的header,并且不是其他同步算法的header

if announce := f.fetching[hash]; announce != nil && announce.origin == task.peer && f.fetched[hash] == nil && f.completing[hash] == nil && f.queued[hash] == nil {
.....
}

②:如果传递的header与承诺的number不匹配,删除peer

if header.Number.Uint64() != announce.number {
f.dropPeer(announce.origin)
f.forgetHash(hash)
}

③:判断此区块在本地是否已存在,如果不存在且只有header(空块),直接放入complete以及f.completing中,否则就放入到incomplete中等待同步body

if f.getBlock(hash) == nil {
announce.header = header
announce.time = task.time if header.TxHash == types.DeriveSha(types.Transactions{}) && header.UncleHash == types.CalcUncleHash([]*types.Header{}) {
...
block := types.NewBlockWithHeader(header)
block.ReceivedAt = task.time complete = append(complete, block)
f.completing[hash] = announce
continue
}
incomplete = append(incomplete, announce) // 否则添加到需要完成拉取body的列表中

④:如果f.fetching中不存在此哈希,就放入到unkown

else {
// Fetcher doesn't know about it, add to the return list |fetcher 不认识的放到unkown中
unknown = append(unknown, header)
}

⑤:之后再把Unknownheader再通知fetcher继续过滤

select {
case filter <- &headerFilterTask{headers: unknown, time: task.time}:
case <-f.quit:
return
}

接着就是进入到第二个循环,要准备拿出incomplete里的哈希,进行同步body的同步

for _, announce := range incomplete {
hash := announce.header.Hash()
if _, ok := f.completing[hash]; ok {
continue
}
f.fetched[hash] = append(f.fetched[hash], announce)
if len(f.fetched) == 1 {
f.rescheduleComplete(completeTimer)
}
}

如果f.completing中存在,就表明已经在开始同步body了,直接跳过,否则把这个哈希放入到f.fetched,表示header同步完毕,准备body同步,由f.rescheduleComplete(completeTimer)完成。最后是安排只有header的区块进行导入操作.

for _, block := range complete {
if announce := f.completing[block.Hash()]; announce != nil {
f.enqueue(announce.origin, block)
}
}

重点分析completeTimer.C,同步body的操作,这步完成就是要准备区块导入到数据库流程了。

拉取body

进入completeTimer.C,从f.fetched获取哈希,如果本地区块链查不到的话就把这个哈希放入到f.completing中,再循环进行fetchBodies,整个流程就结束了,代码大致如下:

case <-completeTimer.C:
...
for hash, announces := range f.fetched {
....
if f.getBlock(hash) == nil {
request[announce.origin] = append(request[announce.origin], hash)
f.completing[hash] = announce
}
}
for peer, hashes := range request {
...
go f.completing[hashes[0]].fetchBodies(hashes)
}
...

关键的拉取body函数: p.RequestBodies,发送GetBlockBodiesMsg消息同步body。回到handler里面去查看对应的消息:

case msg.Code == GetBlockBodiesMsg:
// Decode the retrieval message
msgStream := rlp.NewStream(msg.Payload, uint64(msg.Size))
if _, err := msgStream.List(); err != nil {
return err
}
var (
hash common.Hash
bytes int
bodies []rlp.RawValue
)
for bytes < softResponseLimit && len(bodies) < downloader.MaxBlockFetch {
...
if data := pm.blockchain.GetBodyRLP(hash); len(data) != 0 {
bodies = append(bodies, data)
bytes += len(data)
}
}
return p.SendBlockBodiesRLP(bodies)

softResponseLimit返回的body大小最大为$2 * 1024 * 1024$,MaxBlockFetch表示每个请求最多128个body

之后直接通过GetBodyRLP返回数据通过SendBlockBodiesRLP发回给节点。

节点将会接收到新消息:BlockBodiesMsg,进入查看:

// 过滤掉filter请求的body 同步,其他的都交给downloader
filter := len(transactions) > 0 || len(uncles) > 0
if filter {
transactions, uncles = pm.fetcher.FilterBodies(p.id, transactions, uncles, time.Now())
} if len(transactions) > 0 || len(uncles) > 0 || !filter {
err := pm.downloader.DeliverBodies(p.id, transactions, uncles)
...
}

过滤掉filter请求的body 同步,其他的都交给downloaderdownloader部分之后的篇章讲。进入到FilterBodies

	filter := make(chan *bodyFilterTask)
select {
case f.bodyFilter <- filter: ①
case <-f.quit:
return nil, nil
}
// Request the filtering of the body list
// 请求过滤body 列表
select { ②
case filter <- &bodyFilterTask{peer: peer, transactions: transactions, uncles: uncles, time: time}:
case <-f.quit:
return nil, nil
}
// Retrieve the bodies remaining after filtering
select { ③:
case task := <-filter:
return task.transactions, task.uncles

主要分为3个步骤:

  1. 先发一个通信用的 channelbodyFilter
  2. 将要过滤的 bodyFilterTask 发送给 filter
  3. 检索过滤后剩余的body

现在进入到case filter := <-f.bodyFilter里面,大致做了以下几件事:

①:首先从f.completing中获取要同步body的哈希

for i := 0; i < len(task.transactions) && i < len(task.uncles); i++ {
for hash, announce := range f.completing {
...
}
}

②:然后从f.queued去查这个哈希是不是已经获取了body,如果没有并满足条件就创建一个完整block

if f.queued[hash] == nil {
txnHash := types.DeriveSha(types.Transactions(task.transactions[i]))
uncleHash := types.CalcUncleHash(task.uncles[i])
if txnHash == announce.header.TxHash && uncleHash == announce.header.UncleHash && announce.origin == task.peer {
matched = true if f.getBlock(hash) == nil {
block := types.NewBlockWithHeader(announce.header).WithBody(task.transactions[i], task.uncles[i])
block.ReceivedAt = task.time blocks = append(blocks, block)
}
}

③:最后对完整的块进行导入

for _, block := range blocks {
if announce := f.completing[block.Hash()]; announce != nil {
f.enqueue(announce.origin, block)
}
}

最后用一张粗略的图来大概的描述一下整个同步区块哈希的流程:


同步区块哈希的最终会走到f.enqueue里面,这个也是同步区块最重要的要做的一件事,下文就会讲到。

Fetcher 同步区块

分析完上面比较复杂的同步区块哈希过程,接下来就要分析比较简单的同步区块过程。从NewBlockMsg开始:

主要做两件事:

①:fetcher模块导入远程节点发过来的区块

pm.fetcher.Enqueue(p.id, request.Block)

②:主动同步远程节点

if _, td := p.Head(); trueTD.Cmp(td) > 0 {
p.SetHead(trueHead, trueTD)
currentBlock := pm.blockchain.CurrentBlock()
if trueTD.Cmp(pm.blockchain.GetTd(currentBlock.Hash(), currentBlock.NumberU64())) > 0 {
go pm.synchronise(p)
}
}

主动同步由Downloader去处理,我们这篇只讨论fetcher相关。

区块入队列

pm.fetcher.Enqueue(p.id, request.Block)
case op := <-f.inject:
propBroadcastInMeter.Mark(1)
f.enqueue(op.origin, op.block)

正式进入将区块送进queue中,主要做了以下几件事:

①: 确保新加peer没有导致DOS攻击

count := f.queues[peer] + 1
if count > blockLimit {
log.Debug("Discarded propagated block, exceeded allowance", "peer", peer, "number", block.Number(), "hash", hash, "limit", blockLimit)
propBroadcastDOSMeter.Mark(1)
f.forgetHash(hash)
return
}

②:丢弃掉过去的和比较老的区块

if dist := int64(block.NumberU64()) - int64(f.chainHeight()); dist < -maxUncleDist || dist > maxQueueDist {
f.forgetHash(hash)
}

③:安排区块导入

	if _, ok := f.queued[hash]; !ok {
op := &inject{
origin: peer,
block: block,
}
f.queues[peer] = count
f.queued[hash] = op
f.queue.Push(op, -int64(block.NumberU64()))
if f.queueChangeHook != nil {
f.queueChangeHook(op.block.Hash(), true)
}
log.Debug("Queued propagated block", "peer", peer, "number", block.Number(), "hash", hash, "queued", f.queue.Size())
}

到此为止,已经将区块送入到queue中,接下来就是要回到loop函数中去处理queue中的区块。

区块入库

loop函数在处理队列中的区块主要做了以下事情:

  1. 判断队列是否为空
  2. 取出区块哈希,并且和本地链进行比较,如果太高的话,就暂时不导入
  3. 最后通过f.insert将区块插入到数据库。

代码如下:

height := f.chainHeight()
for !f.queue.Empty() {
op := f.queue.PopItem().(*inject)
hash := op.block.Hash()
...
number := op.block.NumberU64()
if number > height+1 {
f.queue.Push(op, -int64(number))
...
break
}
if number+maxUncleDist < height || f.getBlock(hash) != nil {
f.forgetBlock(hash)
continue
}
f.insert(op.origin, op.block) //导入块
}

进入到f.insert中,主要做了以下几件事:

①:判断区块的父块是否存在,不存在则中断插入

		parent := f.getBlock(block.ParentHash())
if parent == nil {
log.Debug("Unknown parent of propagated block", "peer", peer, "number", block.Number(), "hash", hash, "parent", block.ParentHash())
return
}

②: 快速验证header,并在传递时广播该块

switch err := f.verifyHeader(block.Header()); err {
case nil:
propBroadcastOutTimer.UpdateSince(block.ReceivedAt)
go f.broadcastBlock(block, true)

③:运行真正的插入逻辑

if _, err := f.insertChain(types.Blocks{block}); err != nil {
log.Debug("Propagated block import failed", "peer", peer, "number", block.Number(), "hash", hash, "err", err)
return
}

④:导入成功广播此块

go f.broadcastBlock(block, false)

真正做区块入库的是f.insertChain,这里会调用blockchain模块去操作,具体细节会后续文章讲述,到此为止Fether模块的同步就到此结束了,下面是同步区块的流程图:


参考

https://mindcarver.cn

https://github.com/blockchainGuide

死磕以太坊源码分析之Fetcher同步的更多相关文章

  1. 死磕以太坊源码分析之downloader同步

    死磕以太坊源码分析之downloader同步 需要配合注释代码看:https://github.com/blockchainGuide/ 这篇文章篇幅较长,能看下去的是条汉子,建议收藏 希望读者在阅读 ...

  2. 死磕以太坊源码分析之Kademlia算法

    死磕以太坊源码分析之Kademlia算法 KAD 算法概述 Kademlia是一种点对点分布式哈希表(DHT),它在容易出错的环境中也具有可证明的一致性和性能.使用一种基于异或指标的拓扑结构来路由查询 ...

  3. 死磕以太坊源码分析之p2p节点发现

    死磕以太坊源码分析之p2p节点发现 在阅读节点发现源码之前必须要理解kadmilia算法,可以参考:KAD算法详解. 节点发现概述 节点发现,使本地节点得知其他节点的信息,进而加入到p2p网络中. 以 ...

  4. 死磕以太坊源码分析之rlpx协议

    死磕以太坊源码分析之rlpx协议 本文主要参考自eth官方文档:rlpx协议 符号 X || Y:表示X和Y的串联 X ^ Y: X和Y按位异或 X[:N]:X的前N个字节 [X, Y, Z, ... ...

  5. 死磕以太坊源码分析之Ethash共识算法

    死磕以太坊源码分析之Ethash共识算法 代码分支:https://github.com/ethereum/go-ethereum/tree/v1.9.9 引言 目前以太坊中有两个共识算法的实现:cl ...

  6. 死磕以太坊源码分析之txpool

    死磕以太坊源码分析之txpool 请结合以下代码阅读:https://github.com/blockchainGuide/ 写文章不易,也希望大家多多指出问题,交个朋友,混个圈子哦 交易池概念原理 ...

  7. 死磕以太坊源码分析之MPT树-上

    死磕以太坊源码分析之MPT树-上 前缀树Trie 前缀树(又称字典树),通常来说,一个前缀树是用来存储字符串的.前缀树的每一个节点代表一个字符串(前缀).每一个节点会有多个子节点,通往不同子节点的路径 ...

  8. 死磕以太坊源码分析之MPT树-下

    死磕以太坊源码分析之MPT树-下 文章以及资料请查看:https://github.com/blockchainGuide/ 上篇主要介绍了以太坊中的MPT树的原理,这篇主要会对MPT树涉及的源码进行 ...

  9. 死磕以太坊源码分析之state

    死磕以太坊源码分析之state 配合以下代码进行阅读:https://github.com/blockchainGuide/ 希望读者在阅读过程中发现问题可以及时评论哦,大家一起进步. 源码目录 |- ...

随机推荐

  1. @Transactional 注意事项、方法调用

    1.同一个类中,即A与B在同一类中,A()调用B()方法,A不加 @Transactional 事务注解,B加 @Transactional 事务注解,则B中的事务不起作用,A加事务,才会起作用,B中 ...

  2. 蒲公英 · JELLY技术周刊 Vol.28: Next.js 10 发布

    蒲公英 · JELLY技术周刊 Vol.28 前端应用到底该选 SSR 还是 CSR?每个项目技术栈决策的时候都会根据实际需求有自己的看法,而在不久前 React 17 发布之后,自然而然也会有同学好 ...

  3. How to Convert and Import VHD to VMDK (VMWare)

    VHD or Virtual Hard Disk is the disk image format used by Microsoft virtualization software such as ...

  4. SQL数据库表结构的修改(sql2005)

    一 .ALTER TABLE命令 ALTER TABLE 语句用于在已有的表中添加.修改或删除列. 二.添加列 语法 :ALTER TABLE table_name ADD column_name d ...

  5. 【linux】-Makefile简要知识+一个通用Makefile

    目录 Makefile Makefile规则与示例 为什么需要Makefile Makefile样式 先介绍Makefile的两个函数 完善Makefile 通用Makefile的使用 通用的Make ...

  6. Delphi ADO更新条件

    转https://blog.51cto.com/kinwar/1686710 代码将导致 ADO 在 WHERE 子句中包括的每个字段.如果您想确保所做的当前用户更新才会成功如果为表格中的行中的任何字 ...

  7. 经典c程序100例==51--60

    [程序51] 题目:学习使用按位与 & . 1.程序分析:0&0=0; 0&1=0; 1&0=0; 1&1=1 2.程序源代码: #include " ...

  8. psycopg2模块安装问题

    我的平台是win10(x64).python3.7,打算通过psycopg2模块来操作Greenplum数据库,我通过pip install psycopg2 安装了psycopg2模块,也提示安装成 ...

  9. 认识Redis集群——Redis Cluster

    前言 Redis集群分三种模式:主从模式.sentinel模式.Redis Cluster.之前没有好好的全面理解Redis集群,特别是Redis Cluster,以为这就是redis集群的英文表达啊 ...

  10. php大文件上传失败的解决方法

    1.打开php.ini 2.查找post_max_size:(修改上传大小限制) 表单提交最大数值,此项不是限制上传单个文件的大小,而是针对整个表单的提交数据进行限制的默认为8m,设置为自己需要的值, ...