以太坊交易中存在一个特殊的值nonce，此nonce并非计算block难度的nonce，此nonce仅仅表示发送账号发送交易的次数，从0开始，每发送一次交易+1，那么第一次发送nonce为0，第二次为1，以此类推。
nonce的存在可以用来防止重放攻击，也就是同一个交易只能被发送一次，下次发送同一个交易时，因为nonce值和最新的nonce不同，会被区块链拒绝。
我们来从代码层面看看这个nonce的生成和检测。

区块头定义位于libethcore\BlockHeader.h文件中，是一个非常简单的类，我们来看看它包含哪些重要数据：

交易队列的输入

交易队列的输入有两个，分别是接收到其他节点的广播交易和自身节点提交的交易。

以太坊有两大队列，分别是交易队列TransactionQueue和区块队列BlockQueue，在这里先介绍交易队列。
交易队列是用来缓存那些pending交易的，也就是尚未经过确认，未被区块链收录的交易。

以太坊交易类是Transaction，但是这个类几乎没有什么代码，主要代码都在父类TransactionBase中，因此这个类是我们研究的重点。

除了上面的同步形式外，区块链节点之间还存在另外两种特殊形式的同步，一种是交易同步，也就是当某个节点完成一笔交易后，需要向其他节点广播这个交易，另一种是矿工成功挖到一个区块，也要向其他节点广播这个新的区块。我们来看看这两种同步是怎么进行的。

onPeerBlockBodies()

BlockChainSync::requestBlocks()请求区块体后，如果对方有这些区块就会把数据返回回来，本节我们来看看接收区块体数据的处理。

继续上一节的内容，收到其他peer发过来的区块头之后，流程要怎么走了呢？还记得上一节BlockChainSync::onPeerBlockHeaders()函数的末尾是collectBlocks()和continueSync()两个函数吗？collectBlocks()由于没有可合并的区块，我们留到后面去讲，而continueSync()会调用syncPeer()这个函数，这次由于m_state状态已经是SyncState::Blocks，因此最终将会调用BlockChainSync::requestBlocks()函数。

经过前面的铺垫，现在我们可以来看看BlockChainSync::onPeerBlockHeaders()这个函数的实现了，这个函数是EthereumPeer接收到BlockHeadersPacket包时被调用的，用来处理接收到的区块头。
这个函数有点长，还是一段一段来看吧。

区块链同步的核心类是BlockChainSync，在继续深入了解同步流程之前，我们还是先来了解一下这个类有哪些重要成员吧。