Zhuang's Diary

Whisper是Ethereum P2P协议的一部分，可以让消息在同一个区块链内的用户之间传递。

• Whisper的使用场景==> link
• Whisper的介绍==> link
• Whisper的web3接口==> link

Whisper是独立于区块链之外的协议，智能合约不能够使用。

开启Whisper协议， geth -shh

节点默认不会回复消息。所以必须直连到接收人，否者消息将无法发送。

关于ethereum 中，nonce问题总结：

• Tx 中 nonce 过低（too low）时，Tx 立即被拒绝
• Tx 中 nonce 过高（too high）时，Tx 被放入交易池队列 transaction pool queue
• 如果 Tx 的 nonce 正好填补了最新的有效的 nonce 和过高的nonce之间的空隙，是的nonce的顺序完整连接时，交易池队列中的交易将被执行
• 当 Geth 被关掉或者重新启动时，交易池中的 Txs 将消失

nonce问题，详细介绍：

• 当 Tx 中 nonce 过低时，

1
2
3
4
5
6

> eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[1], value: web3.toWei(1, "ether"), nonce:0})
Nonce too low
    at InvalidResponse (<anonymous>:-81662:-106)
    at send (<anonymous>:-156322:-106)
    at sendTransaction (<anonymous>:-133322:-106)
    at <anonymous>:1:1

• 当 Tx 中 nonce 过高时，

1
2
3
4
5

> txpool.status
{
  pending: 0,
  queued: 1
}

• Geth 重启时，

1
2
3
4
5

> txpool.status
{
  pending: 0,
  queued: 0
}

解决方案

• 在应用本地保存nonce在数据库中，并且，数据库中的nonce值更新时需要访问锁保护。不建议将nonce保存在内存中，那样的话，在应用死机或者重启时，nonce将丢失。目前思考 Redis DB 是比较好的选择。

• 如果本地nonce出了问题，可以使用 web3.eth.getTransactionCount(ethAddress) 来恢复。但是 web3.eth.getTransactionCount(ethAddress) 是内存中的值，不是实时准确的，不建议实时使用。

另外：

• 即使交易池（queue）中有交易存在，nonce正确的交易仍然可以继续进行。

• 当共识停止工作了，nonce正确的交易进入到pending队列中，nonce较高的交易进入到queue队列中。当共识重新正常工作时，pending队列中的交易会被自动处理而清空。

• 同时节点具有每隔一个小时，重新处理一次本地交易的能力。（handle local transaction journal rotation）

参考链接 ==> https://ethereum.stackexchange.com/questions/2808/what-happens-when-a-transaction-nonce-is-too-high

参考代码 ==>

1
2
3
4
5

ethereum/go-ethereum/core/tx_pool.go 

func (pool *TxPool) loop() {
  ......
}

本问题调查过程中，使用到的命令==>

1
2
3
4
5
6
7
8
9
10
11
12
13

eth.getTransactionCount(eth.accounts[0])

personal.unlockAccount(eth.accounts[0],"1234",99999)

eth.sendTransaction({from:eth.accounts[0],to:eth.accounts[0],value:100,nonce:200})

txpool.status

eth.sendTransaction({from:eth.accounts[0],to:eth.accounts[0]})

txpool.status

./odyssey update_Validator localhost:26657 UpdateValidator:OA+kUHbBDxh6q2kqF1jNQFoPqjTYsTS2m17un4Z9vI0=*/*10000

开源是社会化协作的基础。随着软件越来越昂贵、风险越来越大，单靠一个企业内的合作已经不够了，需要全球供应链、全球生产链来共同生产软件、维护软件、交付软件。开源也是社会化生产的需要。经过20年的发展，开源已经今非昔比。20年前，开源是一种软件的开发和交付方式；2020年，开源已经演进发展为一种生态竞争的模式。

开源的生产交付模式已发展成熟。2019年，70%的财富50强企业为GitHub（代码托管网站）贡献了开源代码。开源已经形成了两种模式：基金会主导模式（Linux模式）和企业主导模式（Android模式）。码农数量激增，因为码农是数字社会先进生产力的代表。

总而言之，开源几乎是躲不掉的，99%的组织已经在其 IT系统中使用了开源软件。2019年，中国的代码贡献量上升了48%。在中国，过去，开源的核心是国际项目本土化，现在，国内开源的焦点是本土项目国际化。重要的是，要将风险管控前置来治理开源。

参考链接：

何宝宏：预见2020，拐点已至丨风向Talks

https://spdx.org/licenses/

go-ethereum 在 2019 年 7 月推出了 Geth v1.9.x 版本。

Geth 可以通过 --metrics 命令符收集运行状态信息。 Geth v1.9.x 有3套独立的监控体系，ExpVars，InfluxDB 和 Prometheus：

1. ExpVars

是将Golang系统公共指标暴露给到HTTP接口。Geth 用 pprof 来作为埋点暴露这些公共参数。

运行 Geth –metrics –pprof 将暴露指标成为ExpVars的格式，于地址

http://127.0.0.1:6060/debug/metrics。

ExpVars 有 Golang 非常好的支持。

2. Prometheus

同理 ExpVars，运行 Geth –metrics –pprof 将暴露指标成为Prometheus的格式，于地址

http://127.0.0.1:6060/debug/metrics/prometheus。

Prometheus更加接近业界的标准。

3. InfluxDB

ExpVars 和 Prometheus 是拉取pull数据的监控方式。InfluxDB 是推送push数据的监控方式。

InfluxDB的启用有些麻烦，请参见 geth help 中的 --metrics.influxdb 及其子标识。

参数可视化

推荐使用 Grafana，建议使用 geth-prometheus 项目中给出的图表，参考链接==> https://github.com/karalabe/geth-prometheus。效果如下图：

参考文档==> Geth v1.9.0 Six months distilled

具体功能如下：

• 节点进程监控
  • 节点的存活，进程中CPU、内存使用率，IO
• 区块链数据健康监控
  • 节点出块高度历史，出块时间，出块间隔趋势，交易量历史，TPS，磁盘占用，数据目录大小增长趋势
• 运行环境监控
  • 主机运行环境的系统负载、CPU、内存、磁盘空间使用情况、网络流量、TCP 连接数等
• 故障告警通知
  • 监控告警策略
  • 支持邮件通知、短信通知
• 节点网络监控
  • 连接节点数、网络拓扑、地理位置等

仪表板的监控指标：

• Summary Dashboard
  • 各节点最新块高
  • 各节点监控进程存活
  • 各节点 CPU 使用率变化
  • 节点列表
• Node Info Dashboard
  • Chain Meta Data - 链的配置信息，如 Chain Name、创建时间等
  • Chain Info - 链的最新块高、共识节点数、共识节点出块历史趋势
  • Node Info - 选定节点的详细信息，包括区块链数据、运行环境、运行软件信息
• Host Info Dashboard
  • 各节点运行主机的信息，包括系统负载、CPU、内存、硬盘使用率、网络流量
• Process Info Dashboard
  • 节点中进程（pprof）的历史情况、CPU、内存、IO 变化历史

关于PBFT的监控，已tendermint为例，已经具备 Prometheus 监控能力。

具体参数请参见 ==> https://docs.tendermint.com/master/tendermint-core/metrics.html

List of available metrics

The following metrics are available: