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

以太坊智能合约中，有一类特殊的回调函数，没有函数体，以大写字母开头，一般用来记录函数状态，这类回调函数称为事件event。事件event由合约函数调用，web3.js可以轻松监听此类event，并返回需要的数据。在网上搜索到的相关文章都是关于用web3.js来实现监听event的，今天我们就来从c++代码层面来看看怎么实现这个功能。

在以太坊数据结构中，Merkle Patricia Trie始终是个绕不过去的坎，世界状态，交易，交易收据等都是以这种树的形式存储在区块链数据库中，并将树root hash保存在区块头里。可以说不弄懂这种树的原理就没有办法真正明白以太坊的数据存储方式。

区块头定义位于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()函数。