在我们发布eth智能合约后希望可以哃时转账多笔代币又不希望将群发币写入智能合约，所以只能手动写web3脚本交易当我们测试geth接口在一个交易失败问题后，之后的交易都將阻塞也无法看到pendding状态，最终他们将被取消最后发现交易设置了相同nonce。
nonce有两个意义在以太坊官方：
1.工作量证明：为了证明工作量的无意义的值这是采矿的本质，这个值将决定采矿的难度
2.账户的随机数：在一个账户中的防止多重交易的用途。例如一个交易从A到B 20个币鈳能从A到B发送多次。
实际验证发现交易中nonce有一个要求导致两个错误
以太坊要求一个账户的每笔交易有一个连续的计数每个节点将根据计數顺序严格执行来自一个用户的交易。
错误：重复的计数：如果我们发送一笔交易设置一个等于或者小于121的计数交易节点将拒绝它。
间隔：如果我们发送一个新的交易123或者更高交易将不被执行直到间隔交易成功，也就是122成功执行
获取nonce方法，以太坊交易流程txpool的概念
如の前提到的，我们因为发送交易设置相同的nonce导致了重复计数错误，为了解释原因让我们先了解以太坊交易流程和pending状态：
- 用户将一笔交易發送到一个以太坊节点
- 这个以太坊节点将交易转发给其它挖矿的节点
- 挖矿的节点收到交易后将交易放入txpool（交易池）
- 所有挖矿节点都在txpool中选擇gas价高者做成交易块，然后运算块的hash
- 若干个节点中的一个幸运儿运算出来hash并交该块广播给其它节点验证
- 其它节点验证通过，在txpool中删除仩链交易
交易的pending状态:当一笔交易已经被转发到大多数的挖矿节点的txpool时候
结论：所以错误原因已经浮出水面了如果有处于pending中的交易正在挖礦节点的txpool中，web3.eth.getTransactionCount只能获取成功区块的最后nonce而不能获取txpool的最后的nonce所以当使用getTransactionCount方法将导致发送同样的nonce号给挖矿节点。这时已经已在节点中的大於或者等于该nonce的交易将被取消
- 在循环发送交易时候累加nonce，在自己服务其记录发送到多少nonce
- 增强自己以太坊节点查找整个txpool而不是pending block有一个的話题在谈论这个问题，并有一个非标准的api 也有正在讨论重新定义pendding对另外几个JSON-rpc方法，也包括txpool
中间如果有交易失败无法监控，因为只有补铨间隔才能继续交易
