The research unit of Hong Kong-based crypto derivatives trading platform BitMEX has found a “potential bug” in its Ethereum Parity full node, as indicated in its blog post published March 13.
Concomitant with the launch of Nodestats.org, BitMEX Research’s new website developed in collaboration with TokenAnalyst, the exchange disclosed that it has discovered a bug during the website’s initial data analysis.
The website is designed to aggregate key data for two of the largest Ethereum node client implementations, Ethereum Parity and Ethereum Geth, and subsequently provides a point of comparison of requirements vis-à-vis CPU usage, bandwidth, storage space, as well as memory (RAM).
Following Nodestats.org data analysis of the Ethereum Parity full node on March 1, the team concluded that as of March 12, the node was still not completely synced with the Ethereum network. As detailed in the research, while the client was purportedly 450,000 blocks behind, “it should catch up with the main chain tip in a few days,” based on its current trajectory.
As the researchers noted:
“While the slow initial sync is a potential problem, at least for this system setup, Ethereum has not yet reached a point where the node cannot catch up, as the sync is faster than the rate of blockchain growth.”
But “despite being several hundred thousand blocks behind the chain tip,” BitMEX Research found that the Parity node “sometimes reports that it is in sync,” leading the team to conclude that the anomaly might be caused by a “potential bug.”
While it is “highly unlikely” that such a flaw could lead to an attack, the authors surmised that the bug can still be potentially exploited by attackers in certain circumstances, stressing that:
“One could argue the impact of this potential bug could be severe […] if exploited by an attacker in the right way. For example a user could accept an incoming payment or smart contract execution as verified, while their node claims to be at the network chain tip. […] The attacker would need to double spend at a height the vulnerable node wrongly thought was the chain tip, which could have a lower proof of work requirement than the main chain tip. Although successful execution of this attack is highly unlikely and users are not likely to be using the highest seen block feature anyway.”
As it stands, Nodestats is already linked to five different Ethereum nodes, harvesting data from each node every five seconds. As originally conceptualized, the project was piloted in an effort to provide metrics related to the required computational resources from each Ethereum node.