摘要： BitMEX 研究非常高兴宣布推出一个监控以太坊网络的新网站 Nodestats.org 。 该网站连接到五个不同的以太坊节点，并每五秒钟收集一次数据。 网站主要专注于提供与每个以太坊节点所需的计算资源相关的指标。 在分析某些指标时，我们可能已经识别出与节点报告的数据完整性有关的问题，这可能是某些以太坊用户所关注的问题。Nodestats.org 是与 TokenAnalyst 合作制作，该公司是 BitMEX 研究的以太坊网络数据和分析合作伙伴。
（截至 2019 年 3月 12 日的网站截图）
概述
Nodestats.org 通过整体采用来比较两个最大的以太坊节点客户端实现的统计数据—— Geth 和 Parity 。在这些客户端实现中，Nodestats.org 比较了不同节点配置的性能 ——快速、完整和归档节点。
Nodestats.org 的主要目的如下：
- 提供比较不同以太坊实现的计算效率的指标。 例如，通过比较与以下相关的要求：
- CPU 使用率
- 内存（RAM）
- 带宽
- 储存空间
- 比较运行以太坊节点软件和其他币（如比特币）之间的资源需求
- 通过查看关于节点是否足够快地处理区块以处于链端点，或差的区块传播是否导致节点在大部分时间不同步的指标，来评估以太坊 P2P 网络的实力和交易处理速度
Nodestats.org 在 2019 年 3 月初才开始收集数据，要作出任何确切结论还为时过早。 不过，我们正在保存数据，并希望稍后分析长期趋势。 Nodestats.org 数据是通过每五秒（每小时 720 次）查询一次我们的五个以太坊节点或运行节点的机器生成的，然后将结果存储在数据库中。此数据生成的各种滚动平均值和其他指标显示在 Nodestats.org 网站上。
Nodestats 指标的说明
| 名称 | 说明 | 初步调查结果 |
| 同步的时间百分比% |
这表示节点已验证并下载所有区块数据，到 P2P 网络通知节点是链端点的时间百分比
每小时指标通过确定节点是否每 5 秒处于端点来计算，其应该是每小时 720 次查询。 节点表示其处于端点的这些查询的比例是报告的指标。
该字段基于 web3 的 “isSyncing” 字段，我们认为该字段使用节点已看到的最高区块，即 “highestBlock” 字段，以确定该节点是否落后于其对等节点所看到的最高区块。 |
节点通常报告它们在 99.8% 的时间处于端点，这意味着在每小时 720 次查询中大约只有1次节点不是处于链端点。
唯一的例外是， Ethereum Parity （以太坊奇偶校验）完整节点，我们将在本报告后面讨论。
我们认为该指标的数据完整性很差，例如就 Parity 完整节点而言，所提供信息的完整性很弱，我们将在本报告后面解释。 展望未来，我们的目标是建立一种更有效的方法来计算这个指标。 |
| 在冲突链上的时间百分比 |
这表示节点在网站上跟随与其相对的节点的不同或冲突链的时间百分比。
这是通过在我们的数据库中存储所有区块哈希来确定的，如果节点在相同高度处拥有不同的区块哈希，则它们被认为是在不同链上。 |
通常， Nodestats.org 无法识别客户端跟随不同链的时间。因此，该指标通常为 0% 。（即一小时内 720 次中为 0 次） |
|
CPU使用率 |
这表示机器 CPU 资源的平均使用率百分比。
Nodestats.org 使用的所有机器 都拥有 “Xeon（R）CPU E5-2686 @ 2.30GHz” 处理单元，并且为双核。 例外情况是归档节点，其拥有 16 个核心。
所有节点都使用 AWS “i3.large” 机器，但归档节点除外，其运行 “i3.4xlarge” 。 |
一般来说，CPU 使用率往往在 0.01% 到 1.0% 之间。 Parity 往往达到 1% 的水平，而 Geth 似乎使用较少 CPU 性能。
Geth 的 CPU 使用率似乎不如 Parity 的稳定，Geth 的 CPU 需求偶尔会飙升至 1% 左右。 |
| 内存使用情况 |
Nodestats.org 每 5 秒从机器读取一次，这与以太坊客户端使用的内存量有关。
Nodestats.org 使用的所有机器都拥有 14GB 内存，但归档节点除外，它是一台 120GB 内存的机器。 |
一般来说，无论有多少内存可用，节点都会占用绝大部分内存（例如超过 95% ）。
客户端的内存需求似乎相当稳定。 |
| 对等者数量 | 节点每 5 秒向 Nodestats.org 提供一次网络对等者的数量。 |
Parity 往往拥有大约 450 个对等者，而 Geth 只有大约 8 个。
Geth 的对等者数量比 Parity 更不稳定，因为它似乎偶尔会下降到 6 个左右。 |
| 上行带宽 | Nodestats.org 每 5 秒从机器读取一次，这与服务器的总网络上行带宽有关。 |
具有更多对等者的Parity往往使用超过100KB /秒的带宽（在每个方向）。 相比之下，Geth往往只使用大约4KB /秒的带宽。
Geth的带宽需求往往比Parity更不稳定，偶尔会飙升至60KB /秒左右。 |
| 下行带宽 | Nodestats.org 每 5 秒从机器读取一次，这与服务器的总网络下行带宽有关。 | |
| 链数据大小 |
该指标表示专用于客户端的所有目录使用的总数据。
与其他指标不同，所公开的数字是绝对值，而不是滚动1小时平均值。 |
目前， Parity 需要大约 180GB ， Geth 使用不到 200GB ，完整归档节点需要 2.36TB 的数据。 |
Parity 完整节点仍在同步
Parity 完整节点于 2019 年 3 月 1 日开始，在撰写本文时（ 2019 年 3 月 12 日）它尚未完全与以太坊链同步。客户端大约落后 450,000 个区块，而根据其当前的轨迹，它应该在几天内赶上主链端点。由于初始同步缓慢， “同步的时间百分比” 指标显示为接近 0% ，因为客户端永远不会同步。
Ethereum Parity 完整节点机器的规格如下：
- 双核 2.3GHz
- 14GB 内存
- 固态硬盘
- 10 Gb/秒的互联网连接
事实上，具有上述规格的机器需要超过 12 天的同步可能表明，对于以太坊网络来说，初始同步问题可能比后同步问题（例如区块传播）更受关注。 虽然初始同步缓慢（至少对于这个系统设置而言）是一个潜在的问题，但以太坊尚未达到节点无法赶上的程度，因为同步速度比区块链增长速度快。
数据完整性问题
尽管落后于链端点数十万个区块，但Parity完整节点有时也报告它是同步的。例如，在本文开头的截图中，网站报告该节点有0.02%的时间是完全同步，表明该节点错误地认为其在某段时间内处于链端点。
如下面的 Parity 完整节点日志生成的图表所示，网络图上看到的最高区块（蓝色）似乎有可能不正确。在网络图上看到的最高区块的数值有时随着时间的推移而下降，并且始终远远落后于实际的链端点（以绿色显示）。有时这个有可能出错的数字朝着验证链的高度（橙色）下降，而我们的网站错误地报告该节点同步。这可能是一些以太坊用户关注的问题，因为Parity完整节点与网络有很多连接，因此这可能是一个错误。
以太坊 Parity 完整节点区块高度数据 —— 2019 年 3 月 11 日和 12 日（UTC 时间）
（资料来源： 以太坊 Parity 完整节点日志）
这个潜在错误可能会破坏我们网站的整个指标，即使对于其他节点也是如此，因为最高链端点的字段可能无法正常运行，以及我们的数字可能不准确。 不过，我们继续收录这个指标，因为 Nodestats.org 网站显示节点报告的数据，与我们对数据完整性的看法无关。 我们希望将来可以实施我们自己的改进指标。
有人可能会认为，如果攻击者以正确的方式利用这个潜在错误，其影响在某些有限情况下可能会很严重。 例如，用户可能会将收款或智能合约执行看作已经验证，而他们的节点声称处于网络链端点。 但是，客户端可能并不真正处于链端点，攻击者可能会利用此漏洞来欺骗收款人提供商品或服务。 攻击者将需要在易受攻击节点错误地认为是链端点的高度上花费多一倍功夫，其工作要求证明可能比主链端点低。 不过，成功执行此攻击的可能性极小，而用户也不太可能使用最高的区块功能。
总结
就像其同类网站 Forkmonitor.info 一样， Nodestats.org 还有很多工作需要改善。在未来几个月和几年内与 TokenAnalyst 的合作过程中，我们计划添加更多功能，例如：
- 通过减少对节点报告的内容的依赖并开发我们自己的计算方法，提高数据的完整性
- 用于分析长期趋势的图表和工具
- 改进数据的粒度
- 分叉检测系统
- 与其他对等者相关的数据
目前， Nodestats.org 提供了一个有用的工具来评估运行以太坊节点的大致系统要求。 在非常基础的层面上，它还提供了评估以太坊网络及其各种软件实施的可靠性的机制。 不过，我们承认 “同步的时间百分比” 指标可能不可靠，但它确实突出了潜在问题。
欢迎转载，请注明文章来自
BitMEX (www.bitmex.com)