死磕以太坊源码分析之区块和交易广播

死磕以太坊源码分析之区块和交易广播

ProtocolManager详解

ProtocolManager,从字面上看是协议管理器,负责着p2p通信协议的管理。它连接了p2p的逻辑层peer与顶层peer之间的调用,从顶层将协议传递至逻辑层,再从逻辑层得到message传递到顶层。

image-20201202142450663

  1. fastSync规定了同步的模式 ;
  2. acceptTxs是节点是否接受交易的阀门,只有当pm.acceptTxs == 1时,节点才会接受交易。这个操作只会在同步结束后再开始,即同步的时候节点是不会接受交易的;
  3. SubProtocols中是以太坊的通讯协议,通常只有一个值,即eth63
  4. downloader是一个下载器,用于主动从远程节点中获取hashesblocks
  5. fetcher则被动的收集网络其他以太坊节点发过来的同步通知,进行验证,并做出相应的处理。

ProtocolManager.Start()启动了四条go程,分别是交易订阅广播协程(txBroadcastLoop)、挖矿订阅协程(minedBroadcastLoop)、节点定期同步协程(syncer)和交易同步协程(txsyncLoop)

image-20201202143101376

  1. txBroadcastLoop:广播新出现的交易对象。txBroadcastLoop()会在txCh通道的收端持续等待,一旦接收到有关新交易的事件,会立即调用BroadcastTx()函数广播给那些尚无该交易对象的相邻个体。
  2. minedBroadcastLoop:广播新挖掘出的区块。minedBroadcastLoop()持续等待本节点的新挖掘出区块事件,然后立即广播给需要的相邻个体。当不再订阅新挖掘区块事件时,这个函数才会结束等待并返回。
  3. syncer:定时的和网络其他节点同步,并处理网络节点的相关通知。定时与相邻个体进行区块全链的强制同步。syncer()首先启动fetcher成员,然后进入一个无限循环,每次循环中都会向相邻peer列表中“最优”的那个peer作一次区块全链同步。发起上述同步的理由分两种:如果有新登记(加入)的相邻个体,则在整个peer列表数目大于5时,发起之;如果没有新peer到达,则以10s为间隔定时的发起之。这里所谓"最优"指的是peer中所维护区块链的TotalDifficulty(td)最高,由于Td是全链中从创世块到最新头块的Difficulty值总和,所以Td值最高就意味着它的区块链是最新的,跟这样的peer作区块全链同步,显然改动量是最小的,此即"最优"。
  4. txsyncLoop把新的交易均匀的同步给网路节点

广播的情形

  1. minedBroadcastLoop()监听到新区块事件后,把新区块和区块hash分别广播出去;
  2. 从远程节点同步完成后,将CurrentBlock广播出去,此时广播的是区块hash
  3. txBlockcastLoop()监听到区块池的新增交易事件时会广播交易;

广播区块及区块哈希

广播区块的入口在pm.minedBroadcastLoop(),进入到BroadcastBlock,这里的参数为bool值,如果传入的为true,则将区块block和总难度td发送给一部分节点,节点数为根号n;如果传入的为false,则将区块的hash发送给所有的节点。需要注意的是两个广播函数都执行

进入到true分支:代表只传播区块给一部分节点

①:首先计算一个临时的TD

if parent := pm.blockchain.GetBlock(block.ParentHash(),block.NumberU64()-1); parent != nil {
			td = new(big.Int).Add(block.Difficulty(),pm.blockchain.GetTd(block.ParentHash(),block.NumberU64()-1))
		} 

②:发送块到peers的子集

对节点数进行开方,16开方得4,然后取前4个节点。

transferLen := int(math.Sqrt(float64(len(peers))))
		if transferLen < minBroadcastPeers {
			transferLen = minBroadcastPeers
		}
		if transferLen > len(peers) {
			transferLen = len(peers)
		}
		transfer := peers[:transferLen]
		for _,peer := range transfer {
			peer.AsyncSendNewBlock(block,td) // 块传播
		}

执行完之后直接return出去,再次执行此函数,此时不会走ture分支,直接判断判断本地是否有区块,如果有则发送区区块哈希给剩下的节点,如果没有,则不做发送哈希的操作。

如果本地存在这个要广播的区块(很可能就是出块节点,或者接受块的节点已经插入到区块链中),那就还要像其他没有被广播到区块的节点发送区块哈希。

image-20201125150810051

如果本地不存在这个要广播的区块哈希(应该是还没接收到区块或者区块哈希的节点),那它只要向它的节点列表里发送区块即可。

image-20201125151546035

接下来就是重点分析AsyncSendNewBlockAsyncSendNewBlockHash两个函数了。

AsyncSendNewBlock

发送块到需要广播的节点的广播队列中

select {
	case p.queuedProps <- &propEvent{block: block,td: td}:
		p.knownBlocks.Add(block.Hash())
		for p.knownBlocks.Cardinality() >= maxKnownBlocks {
			p.knownBlocks.Pop()
		}

这里的queuedProps是用来存放要广播的块的队列,同时,要把广播的块标记为已知,还不能超过1024(maxKnownBlocks)个。超过就会弹出队列第一个propEvent() 。接下来就是处理队列中的块了。

eth/peer.go中,有个专门处理广播的循环brodcast

func (p *peer) broadcast() {
	for {
		select {
		case txs := <-p.queuedTxs:
			if err := p.SendTransactions(txs); err != nil {
				return
			}
			p.Log().Trace("Broadcast transactions","count",len(txs))

		case prop := <-p.queuedProps:
			if err := p.SendNewBlock(prop.block,prop.td); err != nil {
				return
			}
			p.Log().Trace("Propagated block","number",prop.block.Number(),"hash",prop.block.Hash(),"td",prop.td)

		case block := <-p.queuedAnns:
			if err := p.SendNewBlockHashes([]common.Hash{block.Hash()},[]uint64{block.NumberU64()}); err != nil {
				return
			}
			p.Log().Trace("Announced block",block.Number(),block.Hash())

		case <-p.term:
			return
		}
	}
}

广播新块到远程节点

p.SendNewBlock(prop.block,prop.td);

远程节点收到块后同样也会标记哈希存入队列,并且不会超过最大,同时发送一个NewBlockMsgmsgcode0x07,同时数据会被RLP编码。

p.knownBlocks.Add(block.Hash())
	for p.knownBlocks.Cardinality() >= maxKnownBlocks {
		p.knownBlocks.Pop()
	}
	return p2p.Send(p.rw,NewBlockMsg,[]interface{}{block,td})
func Send(w MsgWriter,msgcode uint64,data interface{}) error {
	size,r,err := rlp.EncodeToReader(data)
	if err != nil {
		return err
	}
	return w.WriteMsg(Msg{Code: msgcode,Size: uint32(size),Payload: r})
}

到此广播区块的过程结束,交由远程节点去处理NewBlockMsg消息。

AsyncSendNewBlockHash

广播哈希的过程跟广播区块的过程非常的类似,最终是由远程节点去处理NewBlockHashesMsg消息。

广播区块的过程完毕之后,会直接进入下一个阶段,调用fetcher模块去同步这些广播的区块,接下的文章会讲到。

广播交易

广播交易的入口在pm.txBroadcastLoop(),直接进入到pm.BroadcastTxs(event.Txs),大概做了以下几件事:

①:将交易广播给一批没有这个交易的节点

for _,tx := range txs {
		peers := pm.peers.PeersWithoutTx(tx.Hash())
		for _,peer := range peers {
			txset[peer] = append(txset[peer],tx)
		}
		log.Trace("Broadcast transaction",tx.Hash(),"recipients",len(peers))
	}

②:异步发送交易给这些节点

for peer,txs := range txset {
		peer.AsyncSendTransactions(txs)
	}

接着进入到AsyncSendTransactions:

将所有交易标记为已知交易,同时还要保证没有超过最大的已知交易(32768笔)

case p.queuedTxs <- txs:
		for _,tx := range txs {
			p.knownTxs.Add(tx.Hash())
		}
		for p.knownTxs.Cardinality() >= maxKnownTxs {
			p.knownTxs.Pop()
		}
	case txs := <-p.queuedTxs:
			if err := p.SendTransactions(txs); err != nil {
				return
			}
func (p *peer) SendTransactions(txs types.Transactions) error {
...
  return p2p.Send(p.rw,TxMsg,txs)
}

发送交易最终会发送一个TxMsg消息,接收到这个消息的节点会通过pm.txpool.AddRemotes(txs)处理交易。

消息处理(handleMsg)

handleMsg从对方连接中读取消息,根据消息码的不同进行处理,从而将广播和同步之间来回的消息进行处理。

func (pm *ProtocolManager) handleMsg(p *peer) error {
    msg,err := p.rw.ReadMsg()
    if err != nil {
        return err
    }
    if msg.Size > ProtocolMaxMsgSize {
        return errResp(ErrMsgTooLarge,"%v > %v",msg.Size,ProtocolMaxMsgSize)
    }
    defer msg.Discard()

    switch {
    case msg.Code == StatusMsg: ......
    case msg.Code == GetBlockHeadersMsg: ......
    case msg.Code == BlockHeadersMsg: ......
    case msg.Code == GetBlockBodiesMsg: ......
    case msg.Code == BlockBodiesMsg: ......
    case p.version >= eth63 && msg.Code == GetNodeDataMsg: ......
    case p.version >= eth63 && msg.Code == NodeDataMsg: ......
    case p.version >= eth63 && msg.Code == GetReceiptsMsg: ......
    case p.version >= eth63 && msg.Code == ReceiptsMsg: ......
    case msg.Code == NewBlockHashesMsg: ......
    case msg.Code == NewBlockMsg: ......
    case msg.Code == TxMsg: ......
    default: return errResp(ErrInvalidMsgCode,"%v",msg.Code)
    }
    return nil
}

参考

https://mindcarver.cn 最新发布

https://github.com/blockchainGuide/ 资料更新

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


文章浏览阅读903次。文章主要介绍了收益聚合器Beefy协议在币安智能链测试网网上的编译测试部署流程,以Pancake上的USDC-BUSD最新Curve版流动池的农场质押为例,详细介绍了完整的操作流程。_怎么在bsc网络上部署应用
文章浏览阅读952次。比特币的主要思路是,构建一个无中心、去信任的分布式记账系统。交易签名只能保证交易不是他人伪造的,却不能阻止交易的发起者自己进行多重交易,即交易的发起者将一个比特币同时转账给两个人,也就是所谓的双花。比特币应用的区块链场景也叫做公链,因为这个区块链对所有人都是公开的。除此之外,还有一种区块链应用场景,被称作联盟链。区块链的出现,使得低成本,去信任的跨组织合作成为可能,将重构组织间的关系,这个关系既包括企业间的关系,也包括政府和企业间的关系,还有政府部门间的关系。
文章浏览阅读2.5k次。虚拟人从最初的不温不火,到现在步入“出生高峰期”,元宇宙可以说是功不可没。此前,量子位发布了《虚拟数字人深度产业报告》,报告显示,到2030年我国虚拟数字人整体市场规模将达到2700亿元。其中,“身份型虚拟人”市场规模预计达到1750亿元,占主导地位,而“服务型虚拟人”总规模也将超过950亿元。得益于AI、VR/AR 等技术的发展,虚拟人的应用场景正在从传统的虚拟偶像等娱乐行业迈向更多元化的领域。_最喜欢的虚拟角色
文章浏览阅读1.3k次,点赞25次,收藏13次。通过调查和分析用户需求、兴趣和行为,你可以更好地定位你的目标受众,并在市场中找到你的定位。在设计你的Web3.0项目时,注重用户界面的友好性、交互流畅性和功能的创新性,以提供独特的用户体验。通过与有影响力的人或组织进行合作,推广你的Web3.0项目。通过与他们分享你的项目并抓住他们的推荐,可以迅速获得更多的关注度。通过优化你的网站和内容,将有助于提高你的排名,并增加有机流量。通过提供奖励激励计划,如空投、奖励机制等,激励用户参与你的Web3.0项目。的人或组织合作,可以增加你的项目的曝光度。
文章浏览阅读1.7k次。这个智能合约安全系列提供了一个广泛的列表,列出了在 Solidity 智能合约中容易反复出现的问题和漏洞。Solidity 中的安全问题可以归结为智能合约的行为方式不符合它们的意图。我们不可能对所有可能出错的事情做一个全面的列表。然而,正如传统的软件工程有常见的漏洞主题,如 SQL 注入、缓冲区超限和跨网站脚本,智能合约中也有反复出现的。_solidity安全漏洞
文章浏览阅读1.3k次。本文描述了比特币核心的编译与交互方法_编译比特币
文章浏览阅读884次。四水归堂,是中国建筑艺术中的一种独特形式。这种形式下,由四面房屋围出一个天井,房屋内侧坡向天井内倾斜,下雨时雨水会从东西南北四方流入天井,从而起到收集水源,防涝护屋的作用,寓意水聚天心,天人合一。在科技产业当中,很多时候我们需要学习古人的智慧与意蕴,尝试打通各个生态,聚四方之力为我所用,这样才能为最终用户带来最大化价值。随着数字化、智能化的发展,算力成为生产力的根基。在这一大背景下,算力需要贯通软..._超聚变csdn
文章浏览阅读1k次,点赞24次,收藏19次。云计算和区块链是当代科技领域两个备受关注的核心技术。本文将深入探讨云计算和区块链的发展历程,详细剖析其起初阶段的奠基、面临的问题、业务内容、当前研究方向、用到的技术、实际应用场景、未来发展趋势,并提供相关链接供读者深入了解。
文章浏览阅读1.5k次。融入对等网络的奥妙,了解集中式、全分布式和混合式对等网络的差异,以及区块链网络的结构与协议,让你跃入区块链的连结网络。揭开密码学的神秘面纱,探寻对称密码学、非对称密码学、哈希函数、数字签名等关键技术,让你了解信息安全的核心。解码共识算法的精髓,从理论到实践,从PoW、PoS到PBFT,让你深入了解区块链如何达成共识。探索智能合约的世界,从定义到生命周期,从执行引擎到开发与部署,带你进入无限可能的合约领域。了解令人惊叹的区块链世界,从概念到价值,从发展历程到政策法规,一篇章串联出区块链的精髓。
文章浏览阅读777次。8 月份,加密货币市场经历了明显的波动,比特币价格波动幅度较大。与此同时,NFT 市场出现大幅下跌,引发了人们对这一新兴行业未来发展趋势的担忧
文章浏览阅读8.8k次,点赞53次,收藏37次。近二十年来,我国信息科技发展日益成熟,出现的网络完全问题也是“百花齐放”。而元宇宙作为5G技术、AR/VR技术、云计算以及区块链等技术的组合体,其安全性指定会被人们所广泛关注。根据前面所讲,元宇宙融合了虚拟世界和现实世界,通过数据将现实世界的各种元素映射到数字化的虚拟世界中。所以没有数据,就等于没有元宇宙的一切;没有信息安全,元宇宙的社会生产、生活就不能正常有序地进行。所以足以可见数据安全、信息安全对元宇宙发展起到的重要作用!!_元宇宙 安全计算
文章浏览阅读1.4k次。最早使用历史 1991年采用 时间戳 追溯 数字文档,之后 2009年后创始人**中本聪** (satoshi nakamoto )日裔美国人,在设计比特币数字货币中将此理念写入应用程序中_web3.0学习
文章浏览阅读1.7k次。DeFi收益来源全面概述_drfi收益
文章浏览阅读941次,点赞17次,收藏21次。号外:教链内参1.28《从BTC现货ETF的近期数据看到的》隔夜BTC经历现货ETF通过后的情绪冷静,一度破位40k后又逐渐修复至42k上方。请珍惜42k的BTC吧。也许到下个周期,我们将不再有机会见到这个高度的BTC了。下面,让我们重温,42k的BTC,在过去四年穿越牛熊的过程中,带给我们的启迪吧。需要提醒的是,历史文字,自有历史局限性,回顾,也须带着批判性的目光阅读和审视。2021年2月8日,...
文章浏览阅读1.2k次,点赞23次,收藏21次。其实一开始我也是这么想的,但根据PoW算法机制,如果你的计算量不够大,是无法控制区块链的走向的,也就是说,即使你投入了大量的成本用于完成任务,也不能保证自己成功。例如,你持有100个币,总共持有了30天,那么,此时你的币龄就为3000,这个时候,如果你发现了一个PoS区块,那么你的币龄就会被减去一定的值,每减少365个币龄,将会从区块中获得0.05个币的利息(可理解为年利率5%),那么在这个案例中,利息=3000×5%/365=0.41个币。前面说过,谁的算力强,谁最先解决问题的概率就越大。
文章浏览阅读1.9k次。这里主要实现的部分继续下去,对 Blockchain 这个对象有一些修改,如果使用 TS 的话可能要修改对应的 interface,但是如果是 JS 的话就无所谓了。需要安装的依赖有:express现在的 express 已经不内置 body-parser,需要作为单独的依赖下载request不下载会报错,是使用 request-promise 所需要的依赖和已经 deprecated 了,具体 reference 可以参考。_js区块链
文章浏览阅读1k次,点赞19次,收藏19次。作者:Zach Pandl Grayscale编译:象牙山首席村民 碳链价值以太坊在2023年取得了丰厚的回报。但表现不如比特币以及其他一些智能合约公链代币。我们认为,这反映了今年比特币特有的积极因素以及以太坊链上活动的缓慢复苏。尽管以太坊的涨幅低于比特币,但从绝对值和风险调整值来看,今年以太坊的表现优于传统资产类别。以太坊不断增长的L2生态系统的发展可能会吸引新用户,并在2024年支撑以太币的...
文章浏览阅读908次,点赞20次,收藏20次。通证是以数字形式存在,代表的是一种权利、一种固有和内在的价值。徐教授告诉我:多年的职业经历,多年的为易货贸易的思考,认识到在处理贸易和经济领域的关系时,应以提高人民生活水平、保证社会成员充分就业、保证就业成员实际收入和有效需求的大幅稳定增长、实现世界资源的充分利用以及扩大货物的生产和交换为目的,期望通过达成互惠互利安排,实行公开、公平、公正的“三公原则”,开展国家与国家、企业与企业之间的易货贸易,规避因信用问题引起的各类风险,消除国际贸易中的歧视待遇,促进全球国家的经济发展,从而为实现上述目标做出贡献。
文章浏览阅读2.5k次。由于webase文档原因,查找起来比较局限,有时候想找一个api却又忘了在哪个模块的目录下,需要一步一步单独点,而利用文档自带的检索功能又因为查找文档全部信息,显得十分缓慢,所以整理了有关WeBASE的api列表但不可否认,现在只有列表,没有对应的页面跳转,文章目的也只是为了多了解webase的接口_webase私钥管理里获取
文章浏览阅读1.4k次,点赞28次,收藏21次。基于​openzeppelin来构建我们的NFT,并用一个例子来手把手的说明如何在opensea快速发布自己的NFT智能合约(ERC721)。